Fan-out과 Fan-in이란?
대용량 데이터를 빠르게 처리해야 하는 시스템에서는 하나의 작업을 여러 개로 쪼개서 동시에 처리하고, 그 결과를 다시 모으는 구조가 자주 등장합니다. 이때 작업을 여러 갈래로 분산시키는 과정을 Fan-out이라 하고, 분산된 작업 결과를 하나로 취합하는 과정을 Fan-in이라고 부릅니다. 이름 그대로 부채를 펼치듯(Fan-out) 퍼졌다가, 다시 접듯(Fan-in) 모이는 구조를 떠올리면 이해하기 쉽습니다.
이 패턴은 특정 언어나 프레임워크에 종속된 기술이 아니라, 분산 시스템 전반에서 활용되는 설계 개념입니다. 메시지 큐, 서버리스 함수, 마이크로서비스 아키텍처, 심지어 고루틴(goroutine)이나 스레드 풀을 활용한 병렬 처리에서도 동일한 원리가 적용됩니다.
동작 원리와 예시
대형 식당의 주방을 예로 들어보겠습니다. 손님 한 명이 코스 요리를 주문하면, 주방장은 이 주문을 여러 조리 파트(그릴, 샐러드, 디저트)로 나눠서 동시에 조리를 지시합니다. 이것이 Fan-out입니다. 각 파트가 요리를 완성하면, 플레이팅 담당자가 모든 요리를 하나의 접시(혹은 코스 순서)로 모아 손님에게 내보냅니다. 이것이 Fan-in입니다.
실제 시스템에서는 다음과 같은 흐름으로 나타납니다.
- Fan-out: 하나의 요청을 여러 워커(worker)나 서비스에 동시에 전달
- 병렬 처리: 각 워커가 독립적으로 작업을 수행
- Fan-in: 모든 결과가 도착하면 하나의 응답이나 데이터셋으로 병합
예를 들어 AWS Lambda에서 하나의 이벤트가 여러 개의 함수를 트리거하고, 그 결과가 SQS나 DynamoDB에 모여 후처리되는 구조, 혹은 Go 언어에서 채널(channel)을 이용해 여러 고루틴에 작업을 분배하고 결과를 다시 채널로 수집하는 코드가 대표적인 Fan-out/Fan-in 구현 사례입니다.
실무에서 왜 쓰는가
Fan-out과 Fan-in 패턴을 사용하는 가장 큰 이유는 처리 속도와 확장성입니다. 대량의 이미지 리사이징, 로그 분석, 배치 데이터 처리처럼 개별 작업 단위가 독립적인 경우, 순차 처리 대신 병렬 처리를 적용하면 전체 처리 시간을 획기적으로 줄일 수 있습니다.
또한 이 구조는 장애 격리에도 유리합니다. 하나의 워커가 실패하더라도 전체 파이프라인이 멈추지 않고, 실패한 부분만 재시도하거나 별도로 처리할 수 있기 때문입니다. 다만 Fan-in 단계에서는 모든 결과가 도착할 때까지 기다려야 하므로, 가장 느린 작업(straggler)이 전체 응답 시간을 좌우한다는 점은 설계 시 반드시 고려해야 할 부분입니다.