Go 팬아웃/팬인 패턴으로 고루틴 기반 동시성 처리 구조 만들기

Go 언어는 간결하면서도 강력한 동시성(concurrency) 모델을 제공하는 것으로 유명합니다. 특히 고루틴(goroutine)과 채널(channel)은 Go를 고성능 네트워크 서비스나 데이터 파이프라인 구현에 적합하게 만드는 핵심 요소입니다. 이 글에서는 다수의 고루틴이 작업을 나누어 처리하고 그 결과를 하나의 흐름으로 통합하는 팬아웃(Fan-Out)/팬인(Fan-In) 패턴에 대해 심도 있게 살펴봅니다.

📌 목차

• 1. Go 언어의 동시성과 채널의 위력
• 2. 팬아웃(Fan-Out) 패턴이란 무엇인가?
• 3. 팬인(Fan-In) 패턴이란 무엇인가?
• 4. 팬아웃/팬인 통합 예제: 실전 코드로 이해하기
• 5. 주의해야 할 점: 동기화, 채널 닫기, 고루틴 누수
• 6. Go의 채널 버퍼링과 팬아웃/팬인의 관계
• 7. 결론: 팬아웃/팬인 패턴이 가져다주는 이점
• 8. 부록: 실전에서 응용할 수 있는 패턴 확장

1. Go 언어의 동시성과 채널의 위력

동시성은 현대 소프트웨어에서 필수적인 기능이 되었습니다. 네트워크 요청, 파일 입출력, 대량의 데이터 처리 등 대부분의 실무 작업에서는 동시에 여러 작업을 처리해야 하는 상황이 많습니다. 이런 작업을 효율적으로 다루기 위해 Go는 다른 언어들과 달리 고루틴(goroutine)과 채널(channel)을 언어 차원에서 지원합니다.

고루틴은 Go 런타임에서 관리되는 매우 가벼운 스레드로, 수천 개를 동시에 실행해도 성능 저하가 크지 않습니다. 반면 채널은 고루틴 간 통신을 위한 수단으로, 데이터를 안전하게 주고받는 데 사용됩니다. 이러한 구조 덕분에 복잡한 동기화나 뮤텍스 없이도 안정적인 병렬 처리를 구현할 수 있습니다.

이러한 Go의 동시성 모델은 특히 팬아웃/팬인(Fan-Out/Fan-In) 패턴을 구현하는 데 매우 적합합니다. 팬아웃은 하나의 작업을 여러 고루틴으로 분산하는 구조이며, 팬인은 분산된 결과를 다시 하나로 모으는 구조입니다. 이 두 가지를 조합하면 효율적이고 구조적인 병렬 처리를 설계할 수 있습니다. 이후 단락에서는 이 두 가지 패턴의 개념과 실제 구현 방법에 대해 순차적으로 살펴보겠습니다.

2. 팬아웃(Fan-Out) 패턴이란 무엇인가?

팬아웃(Fan-Out)은 하나의 입력 또는 명령을 여러 개의 고루틴으로 나누어 동시에 처리하게 하는 동시성 패턴입니다. 이 패턴은 CPU 자원을 최대한 활용하거나, 네트워크 요청 등 I/O 작업을 병렬로 수행할 때 유용합니다. 쉽게 말해, 하나의 생산자가 여러 소비자에게 작업을 위임하는 방식이라고 볼 수 있습니다.

예를 들어, 대규모 이미지 처리 시스템에서 수천 장의 이미지를 리사이징한다고 가정해 봅시다. 하나의 루틴이 모든 작업을 처리하면 병목이 생기지만, 팬아웃 패턴을 적용하여 여러 고루틴에 분산시킨다면 처리 속도가 비약적으로 향상됩니다.

팬아웃 패턴의 핵심은 작업을 병렬화하고, 각 고루틴이 독립적으로 동일한 작업 단위를 처리하도록 설계하는 것입니다. 아래는 Go에서 팬아웃 패턴을 구현한 간단한 예제입니다.

package main

import (
	"fmt"
	"time"
)

func worker(id int, jobs <-chan int) {
	for j := range jobs {
		fmt.Printf("Worker %d processing job %d\n", id, j)
		time.Sleep(time.Second)
	}
}

func main() {
	jobs := make(chan int, 10)

	// 팬아웃: 3개의 워커 고루틴 생성
	for w := 1; w <= 3; w++ {
		go worker(w, jobs)
	}

	// 작업 전송
	for j := 1; j <= 9; j++ {
		jobs <- j
	}
	close(jobs)
}

이 코드에서 `main` 함수는 1부터 9까지의 작업을 생성하고, 이를 `jobs` 채널을 통해 전달합니다. 세 개의 `worker` 고루틴이 팬아웃 구조로 동시에 작업을 분산 처리합니다. 각 워커는 자신에게 할당된 작업을 수행한 후 1초간 대기합니다. 이처럼 팬아웃은 동일한 처리 로직을 가진 고루틴을 여러 개 실행시켜 작업 처리 속도를 향상시킵니다.

하지만 팬아웃만으로는 작업 처리를 완료할 수 없습니다. 이로 인해 분산된 결과를 다시 하나로 모으는 과정이 필요하게 되며, 이는 다음 단락에서 소개할 팬인(Fan-In) 패턴으로 해결할 수 있습니다.

3. 팬인(Fan-In) 패턴이란 무엇인가?

팬인(Fan-In)은 팬아웃으로 분산 처리된 결과를 하나의 흐름으로 다시 통합하는 동시성 패턴입니다. 이는 마치 여러 갈래로 나뉜 물줄기가 다시 하나의 강으로 모이는 구조와 같습니다. 여러 고루틴에서 작업을 처리한 뒤, 그 결과를 한 곳에 모아야 할 때 팬인 패턴을 사용합니다.

이 패턴은 로그 집계 시스템, 데이터 수집 파이프라인, API 응답 취합 등 다양한 상황에서 활용됩니다. 팬인은 일반적으로 하나의 채널로 여러 고루틴의 출력을 통합하며, 이 과정을 통해 중앙 집중식 처리 또는 후속 처리 단계로 연결할 수 있습니다.

다음은 팬아웃과 결합된 팬인 패턴의 예제입니다. 각 워커가 작업을 수행하고 결과를 출력 채널로 전송한 뒤, 메인 루틴에서 이를 수신합니다.

package main

import (
	"fmt"
	"time"
)

func worker(id int, jobs <-chan int, results chan<- int) {
	for j := range jobs {
		time.Sleep(time.Second)
		fmt.Printf("Worker %d completed job %d\n", id, j)
		results <- j * 2 // 처리된 결과 전송
	}
}

func main() {
	jobs := make(chan int, 5)
	results := make(chan int, 5)

	// 팬아웃: 워커 생성
	for w := 1; w <= 3; w++ {
		go worker(w, jobs, results)
	}

	// 작업 전송
	for j := 1; j <= 5; j++ {
		jobs <- j
	}
	close(jobs)

	// 팬인: 결과 수신
	for a := 1; a <= 5; a++ {
		res := <-results
		fmt.Println("Result received:", res)
	}
}

위 코드에서는 세 개의 워커 고루틴이 팬아웃으로 작업을 병렬 처리하고, 각각의 결과를 `results` 채널로 전송합니다. 이후 메인 루틴에서 `results` 채널을 통해 결과를 순차적으로 수신하는 구조입니다. 팬인은 이처럼 여러 처리 단위를 하나의 흐름으로 통합하는 역할을 하며, 작업의 전체 흐름을 제어하는 데 중요한 역할을 합니다.

중요한 점은 팬아웃/팬인을 함께 사용할 때, 고루틴과 채널의 닫기 시점, 버퍼 용량, 병목 현상 등을 잘 조율해야 한다는 것입니다. 다음 단락에서는 팬아웃/팬인을 통합한 실전 예제를 통해 이 개념을 실제로 어떻게 적용할 수 있는지 살펴보겠습니다.

4. 팬아웃/팬인 통합 예제: 실전 코드로 이해하기

앞서 소개한 팬아웃과 팬인 패턴을 별도로 살펴보았다면, 이제는 두 패턴을 조합한 실전 예제를 통해 전체 흐름을 종합적으로 이해해보겠습니다. 본 예제에서는 웹 주소 리스트를 받아 각 URL에 HTTP 요청을 보내고, 그 응답 길이를 병렬로 처리한 후 결과를 수집하는 구조를 구현합니다. 이처럼 팬아웃은 네트워크 요청을 병렬로 실행하고, 팬인은 각각의 응답 데이터를 하나의 흐름으로 통합합니다.

package main

import (
	"fmt"
	"io/ioutil"
	"net/http"
	"sync"
)

func fetchURL(wg *sync.WaitGroup, url string, results chan<- string) {
	defer wg.Done()

	resp, err := http.Get(url)
	if err != nil {
		results <- fmt.Sprintf("Error fetching %s: %v", url, err)
		return
	}
	defer resp.Body.Close()

	body, err := ioutil.ReadAll(resp.Body)
	if err != nil {
		results <- fmt.Sprintf("Error reading %s: %v", url, err)
		return
	}

	results <- fmt.Sprintf("Fetched %s (%d bytes)", url, len(body))
}

func main() {
	urls := []string{
		"https://example.com",
		"https://golang.org",
		"https://httpbin.org/get",
		"https://api.github.com",
		"https://jsonplaceholder.typicode.com/posts/1",
	}

	results := make(chan string, len(urls))
	var wg sync.WaitGroup

	// 팬아웃: 각 URL 요청을 고루틴으로 실행
	for _, url := range urls {
		wg.Add(1)
		go fetchURL(&wg, url, results)
	}

	// 팬인: 모든 작업이 끝나면 채널 닫기
	go func() {
		wg.Wait()
		close(results)
	}()

	// 결과 수신
	for result := range results {
		fmt.Println(result)
	}
}

이 예제에서는 다음과 같은 흐름이 구성됩니다:

• 입력으로 URL 목록을 사용합니다.
• fetchURL 함수는 각 URL에 대해 HTTP GET 요청을 보내고 결과를 채널로 전달합니다.
• 각 URL 요청은 고루틴으로 병렬 실행되며, 이는 팬아웃 구조입니다.
• sync.WaitGroup을 이용해 모든 고루틴이 완료된 후 채널을 닫아 팬인을 안전하게 구현합니다.
• 메인 루틴은 results 채널로부터 각 응답 결과를 수신합니다.

이와 같이 팬아웃/팬인 패턴은 네트워크 요청, 파일 처리, 데이터 파이프라인 등에서 매우 유용하게 사용됩니다. 단순한 구조지만, 효율적인 병렬 처리와 결과 수집을 가능하게 하며, 확장성과 유지보수성을 높이는 데도 큰 장점이 있습니다.

다음 단락에서는 이 구조를 설계할 때 반드시 고려해야 할 요소들, 특히 채널 닫기, 고루틴 누수, 동기화 문제 등에 대해 다뤄보겠습니다.

5. 주의해야 할 점: 동기화, 채널 닫기, 고루틴 누수

팬아웃/팬인 패턴을 실무에 적용할 때는 단순한 코드 작성 외에도 여러 가지 주의할 점이 존재합니다. 이 패턴은 병렬성과 구조적 명확성이라는 장점을 제공하지만, 잘못 사용하면 오히려 예기치 않은 버그나 리소스 낭비를 초래할 수 있습니다. 이 단락에서는 가장 흔히 발생하는 문제와 이를 방지하는 방법을 설명합니다.

1. 채널 닫기 시점

Go에서 채널을 닫는 것은 단일 책임이어야 하며, 일반적으로 채널을 생성한 쪽이 닫아야 합니다. 고루틴이 작업을 마친 후 결과를 채널로 보낸다고 해서 그 고루틴이 채널을 닫아서는 안 됩니다. 채널을 너무 일찍 닫으면 panic이 발생하고, 너무 늦게 닫으면 메모리 누수나 무한 대기가 발생할 수 있습니다.

2. 고루틴 누수

팬아웃 구조에서 각 고루틴이 정상적으로 종료되지 않으면 고루틴 누수(goroutine leak)가 발생할 수 있습니다. 이는 시스템 리소스를 점점 잡아먹으며, 장기적으로 심각한 성능 저하로 이어집니다. 일반적으로 `select` 문에서 채널의 닫힘 여부를 감지하거나, 컨텍스트(context.Context)를 사용하여 타임아웃, 취소 신호 등을 활용하는 것이 좋습니다.

3. 동기화

sync.WaitGroup은 팬아웃/팬인 구조에서 매우 중요한 동기화 도구입니다. 작업이 끝났는지, 모두 완료되었는지 등을 판단할 때 반드시 사용해야 합니다. 팬인 단계에서 결과 채널을 닫기 전에 모든 고루틴이 종료되었는지 확인하지 않으면, 닫힌 채널에 데이터를 보내는 문제가 발생할 수 있습니다.

4. 팬아웃 수 조절

팬아웃 고루틴의 수를 과도하게 설정하면 시스템에 오히려 부담이 될 수 있습니다. 특히 CPU 사용량이 높은 작업이라면 고루틴 수를 논리 CPU 수에 맞춰 조절하는 것이 바람직합니다. 반면 I/O 중심의 작업이라면 더 많은 고루틴도 감당할 수 있습니다.

다음은 고루틴 누수를 방지하기 위해 context를 사용하는 간단한 예제입니다.

package main

import (
	"context"
	"fmt"
	"time"
)

func worker(ctx context.Context, id int, jobs <-chan int) {
	for {
		select {
		case <-ctx.Done():
			fmt.Printf("Worker %d exiting due to context cancellation\n", id)
			return
		case job, ok := <-jobs:
			if !ok {
				fmt.Printf("Worker %d: no more jobs\n", id)
				return
			}
			fmt.Printf("Worker %d processing job %d\n", id, job)
		}
	}
}

func main() {
	jobs := make(chan int, 5)
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()

	for i := 1; i <= 3; i++ {
		go worker(ctx, i, jobs)
	}

	for j := 1; j <= 10; j++ {
		jobs <- j
		time.Sleep(300 * time.Millisecond)
	}
	close(jobs)

	time.Sleep(3 * time.Second) // 컨텍스트 만료 대기
}

위 코드는 context.WithTimeout을 사용하여 일정 시간이 지나면 모든 고루틴이 자동으로 종료되도록 합니다. 이를 통해 고루틴 누수를 방지하고, 예측 가능한 리소스 관리가 가능해집니다.

이처럼 팬아웃/팬인을 구성할 때는 반드시 동기화, 고루틴 생명주기, 채널 관리에 대한 체계적인 설계를 병행해야 합니다. 다음 단락에서는 이러한 구조에 영향을 주는 또 하나의 중요한 요소인 채널 버퍼링에 대해 알아보겠습니다.

6. Go의 채널 버퍼링과 팬아웃/팬인의 관계

Go에서 채널을 생성할 때는 버퍼드 채널과 언버퍼드 채널 중 선택할 수 있습니다. 이 선택은 팬아웃/팬인 구조의 처리 방식과 성능에 큰 영향을 미칩니다. 적절한 채널 버퍼링은 병목 현상을 줄이고, 시스템의 반응성과 효율성을 향상시킵니다. 반면 잘못된 선택은 데이터가 채널에서 대기하거나 고루틴이 불필요하게 블로킹되는 결과를 초래합니다.

1. 언버퍼드 채널 (Unbuffered Channel)

언버퍼드 채널은 보낸 쪽과 받는 쪽이 동시에 준비되어 있어야 데이터를 전송할 수 있습니다. 이는 동기화 효과가 있어, 작업 흐름의 제어에는 좋지만 성능 면에서는 제한적일 수 있습니다.

2. 버퍼드 채널 (Buffered Channel)

버퍼드 채널은 일정 수의 데이터를 채널 내에서 대기시킬 수 있어, 비동기적으로 송수신이 가능합니다. 특히 팬아웃 구조에서 고루틴이 처리한 결과를 팬인 루틴이 수신하는 데 시간이 걸릴 경우, 버퍼가 없으면 결과를 보낼 때마다 고루틴이 블로킹됩니다. 버퍼를 설정하면 이러한 블로킹이 줄어들어 고루틴이 유연하게 동작할 수 있습니다.

구분	언버퍼드 채널	버퍼드 채널
전송 조건	송수신자가 동시에 준비되어야 함	송신자는 수신자가 없어도 일정 수량 전송 가능
성능	동기적 → 블로킹 발생 가능	비동기적 → 처리량 향상 가능
활용 시점	정밀한 동기화가 필요할 때	작업량이 많고 고루틴 간 비동기 처리가 필요할 때

팬아웃/팬인 구조에서는 일반적으로 버퍼드 채널을 사용하는 것이 유리합니다. 작업 처리량이 많고, 각 고루틴의 처리 시간이 다르기 때문에 버퍼가 있으면 고루틴이 자유롭게 결과를 전송하고 다음 작업으로 이동할 수 있습니다. 반면 팬인의 경우 결과 수집 루틴이 느릴 경우, 버퍼 크기를 충분히 확보해주는 것이 중요합니다.

버퍼 크기를 정할 때는 예상되는 작업량, 고루틴 수, 처리 시간 등을 고려하여 실험적으로 조정하는 것이 좋습니다. 무조건 크게 잡는다고 좋은 것은 아니며, 오히려 메모리 사용량이 급증할 수 있기 때문입니다.

이처럼 채널의 버퍼링은 팬아웃/팬인 패턴의 안정성과 성능에 핵심적인 역할을 하며, 적절한 설계를 통해 효율적인 병렬 처리가 가능합니다. 이제 이러한 요소들을 종합적으로 고려한 결론으로 글을 마무리해보겠습니다.

7. 결론: 팬아웃/팬인 패턴이 가져다주는 이점

Go의 팬아웃/팬인(Fan-Out/Fan-In) 패턴은 단순한 코드 이상의 가치를 지닙니다. 이 구조를 통해 우리는 다수의 고루틴을 사용하여 작업을 효율적으로 분산하고, 다시 정제된 형태로 수집할 수 있습니다. 이러한 흐름은 단순히 동시성을 구현하는 데 그치지 않고, 시스템 전체의 구조와 성능을 재설계할 수 있는 강력한 설계 도구가 됩니다.

팬아웃은 다량의 작업을 병렬로 처리하여 응답 속도를 높이고, 팬인은 분산된 데이터를 하나의 흐름으로 통합함으로써 데이터 처리의 일관성과 후속 처리의 용이성을 제공합니다. 두 구조의 조합은 파이프라인 기반의 아키텍처나 분산 처리 시스템에서 특히 빛을 발하며, 확장성과 유연성을 극대화하는 데 핵심적인 역할을 합니다.

하지만 이 모든 이점은 적절한 채널 관리, 고루틴 생명주기 제어, 그리고 동기화 전략이 뒷받침될 때만 실현됩니다. 팬아웃/팬인을 제대로 구현하기 위해서는 단순한 고루틴 활용을 넘어, 컨텍스트 사용, 버퍼 크기 조절, 고루틴 누수 방지 등 섬세한 고려가 필요합니다.

이제 우리는 Go의 팬아웃/팬인 패턴을 통해 단순한 병렬 처리를 넘어선, 구조적이고 체계적인 동시성 프로그래밍의 세계를 엿볼 수 있게 되었습니다. 이 패턴은 단순한 기법이 아니라, 변화하는 시스템 요구에 유연하게 대응할 수 있는 Go의 철학이자 실천 전략입니다. 바로 지금, 여러분의 Go 프로그램에 이 패턴을 적용해보며 더 나은 성능과 안정성을 직접 경험해보시길 바랍니다.

8. 부록: 실전에서 응용할 수 있는 패턴 확장

팬아웃/팬인 패턴은 단일 처리 흐름에만 머무르지 않고, 실전에서는 다양한 패턴과 결합하여 더욱 강력한 구조로 발전합니다. 이 마지막 단락에서는 팬아웃/팬인을 실무 시스템에 확장 적용하는 전략과 대표적인 활용 사례들을 간략히 살펴보겠습니다.

1. 워커 풀(Worker Pool)과의 결합

팬아웃 패턴의 확장형 중 하나가 워커 풀(Worker Pool)입니다. 워커 풀은 일정 수의 고루틴만을 유지하면서 작업을 처리하는 구조로, 팬아웃의 무한 고루틴 생성 문제를 방지합니다. 이는 시스템의 리소스를 예측 가능하게 관리할 수 있도록 돕습니다. 팬아웃에서 워커 풀을 활용하면 병렬성과 안정성을 동시에 확보할 수 있습니다.

2. 파이프라인 처리 구조와의 결합

여러 개의 팬아웃/팬인 단계를 연결하여 데이터를 단계적으로 처리하는 파이프라인 구조는 대규모 데이터 처리 시스템에서 매우 일반적인 형태입니다. 예를 들어, 첫 번째 단계에서 데이터를 수집하고, 두 번째 단계에서 변환하며, 세 번째 단계에서 저장하는 구조로 이어질 수 있습니다. 각 단계는 팬아웃/팬인 구조로 병렬화되어 전체 처리 성능을 비약적으로 향상시킵니다.

3. 비동기 이벤트 시스템 구축

팬아웃/팬인은 비동기 이벤트 처리에서도 유용하게 사용됩니다. 예를 들어, Kafka나 RabbitMQ와 같은 메시징 시스템과 결합하면, 수신된 메시지를 팬아웃으로 다양한 핸들러에 분배하고, 각 결과를 팬인 방식으로 수집하거나 다른 채널로 전달할 수 있습니다. 이는 이벤트 기반 마이크로서비스 아키텍처에서 특히 효과적입니다.

4. 활용 사례 요약

활용 영역	팬아웃/팬인 적용 방식
웹 크롤러	URL 목록을 팬아웃하여 병렬 크롤링 후 결과를 팬인
로그 집계 시스템	다양한 소스로부터 팬아웃된 로그를 중앙 채널로 팬인
파일 처리 파이프라인	입력 파일을 팬아웃하여 병렬 처리 후 하나의 출력으로 통합

이처럼 팬아웃/팬인은 고정된 패턴이 아닌, 다양한 시스템 아키텍처와 결합할 수 있는 유연한 도구입니다. 각각의 상황에 맞게 설계하고 확장한다면, Go의 고루틴과 채널이 제공하는 강력한 동시성 모델을 최대한 활용할 수 있습니다. 이제 이 패턴은 단순한 코드 예시를 넘어서, 여러분의 시스템에 전략적으로 도입될 준비가 되어 있습니다.