백그라운드 작업에서의 Go: 워커 풀 vs 작업당 고루틴

우리가 해결하려는 문제는 무엇인가요?

대부분의 Go 서비스는 HTTP 요청에 응답하는 것 이상을 합니다. 이메일 발송, 이미지 리사이징, 인보이스 생성, 데이터 동기화, 이벤트 처리, 검색 인덱스 재구성 같은 백그라운드 작업도 실행합니다. 일부 작업은 빠르고 독립적입니다. 다른 것들은 각 단계가 앞선 단계에 의존하는 긴 워크플로를 이룹니다(카드를 결제하고 확인을 기다린 뒤 고객에게 알리고 리포팅을 업데이트하는 식).

사람들이 "Go 워커 풀 vs 작업당 고루틴"을 비교할 때 보통 해결하려는 운영상의 문제는 하나입니다: 서비스가 느려지거나 비용이 커지거나 불안정해지지 않도록 많은 백그라운드 작업을 어떻게 실행할지.

영향은 몇 군데에서 느껴집니다:

• 지연(Latency): 백그라운드 작업이 CPU, 메모리, DB 연결, 네트워크 대역폭을 빼앗아 사용자 요청 성능을 저하시킬 수 있습니다.
• 비용: 제어되지 않은 동시성은 더 큰 머신, 더 많은 DB 용량, 혹은 더 높은 큐/API 비용으로 밀어낼 수 있습니다.
• 안정성: 임시 급증(임포트, 마케팅 발송, 재시도 폭주)이 타임아웃, OOM 크래시, 연쇄 실패를 유발할 수 있습니다.

실제 트레이드오프는 단순성 대 제어입니다. 작업당 고루틴을 만드는 것은 작성이 쉽고, 트래픽이 적거나 자연스럽게 제한될 때는 잘 동작합니다. 워커 풀은 구조를 제공해 동시성 고정, 명확한 한계, 타임아웃/재시도/메트릭을 적용할 자연스러운 장소를 만들어 줍니다. 대가는 추가 코드와 시스템이 바쁠 때 작업을 기다리게 할지, 거부할지, 다른 곳에 저장할지 결정해야 한다는 점입니다.

여기서는 일상적인 백그라운드 처리: 처리량, 메모리, 백프레셔(과부하 방지)에 대해 다룹니다. 모든 큐 기술, 분산 워크플로 엔진, 혹은 정확히 한 번 처리(Exactly-once) 같은 특성은 포함하지 않습니다.

AppMaster 같은 플랫폼으로 백그라운드 로직이 있는 전체 앱을 빌드할 때도 같은 질문이 빠르게 나타납니다. 비즈니스 프로세스와 통합은 DB, 외부 API, 이메일/SMS 공급자 주변에 한계가 필요합니다. 하나의 바쁜 워크플로가 다른 모든 것을 느리게 만들면 안 되기 때문입니다.

두 가지 흔한 패턴을 쉽게 설명하면

작업당 고루틴 (Goroutine-per-task)

가장 단순한 접근입니다: 작업이 도착하면 그 작업을 처리할 고루틴을 바로 띄웁니다. "큐"는 채널 수신기나 HTTP 핸들러의 직접 호출처럼 작업을 트리거하는 무엇이든 될 수 있습니다.

전형적인 형태는: 작업을 받으면 go handle(job)을 실행하는 것입니다. 때로는 채널을 핸드오프 포인트로 쓰지만 제한장치로는 사용하지 않을 수 있습니다.

작업이 대부분 I/O(HTTP 호출, DB 쿼리, 업로드)를 기다리고, 작업량이 적거나 급증이 작고 예측 가능할 때 잘 작동합니다.

단점은 동시성이 명확한 상한 없이 커질 수 있다는 것입니다. 이로 인해 메모리가 급증하거나 연결이 너무 많이 열리거나 하위 서비스가 과부하될 수 있습니다.

워커 풀

워커 풀은 고정된 수의 워커 고루틴을 시작하고 버퍼된 인메모리 채널 같은 큐에서 작업을 공급합니다. 각 워커는 루프를 돌며 작업을 가져와 처리하고 반복합니다.

핵심 차이는 제어입니다. 워커 수는 명확한 동시성 한계입니다. 작업이 워커보다 빠르게 도착하면 작업은 큐에서 기다리거나(큐가 가득 차면 거부될 수 있음) 합니다.

워커 풀은 작업이 CPU 집약적일 때(이미지 처리, 리포트 생성), 자원 사용을 예측 가능하게 유지해야 할 때, 또는 DB나 서드파티 API를 폭주로부터 보호해야 할 때 적합합니다.

큐의 위치

두 패턴 모두 인메모리 채널을 사용할 수 있습니다. 이는 빠르지만 재시작 시 사라집니다. "절대 잃으면 안 되는" 작업이나 긴 워크플로의 경우 큐는 보통 프로세스 밖으로 이동합니다(DB 테이블, Redis, 메시지 브로커 등). 그 환경에서도 여전히 작업당 고루틴과 워커 풀 중 선택할 수 있지만, 이제는 외부 큐의 소비자로서 실행됩니다.

간단한 예로 시스템이 갑자기 10,000개의 이메일을 보내야 한다면 작업당 고루틴은 모두 동시에 발송하려고 시도할 수 있습니다. 풀은 한 번에 50개만 보내고 나머지는 제어된 방식으로 대기하게 합니다.

처리량(Throughput): 무엇이 변하고 무엇이 변하지 않는가

워커 풀과 작업당 고루틴 사이에 큰 처리량 차이가 있을 것이라고 기대하는 경우가 많습니다. 대부분의 경우 원시 처리량은 고루틴을 어떻게 시작하느냐가 아니라 다른 무엇에 의해 제한됩니다.

처리량은 보통 가장 느린 공유 자원에서 상한에 도달합니다: DB 또는 외부 API 한계, 디스크나 네트워크 대역폭, CPU 집약 작업(JSON/PDF/이미지 리사이징), 락과 공유 상태, 또는 부하에 약한 하위 서비스 등.

공유 자원이 병목이라면 고루틴을 더 띄운다고 작업이 빨리 끝나지 않습니다. 대신 같은 병목에서 더 많은 기다림이 발생합니다.

작업당 고루틴은 작업이 짧고 대부분 I/O에 묶여 있으며 공유 한계에서 경쟁하지 않을 때 유리할 수 있습니다. 고루틴 시작 비용은 싸고 Go 스케줄러는 많은 고루틴을 잘 다룹니다. "가져와서 파싱하고 한 행을 쓰기" 같은 루프에서는 CPU를 바쁘게 유지하고 네트워크 지연을 숨기기 좋습니다.

워커 풀은 값비싼 자원을 제한해야 할 때 이깁니다. 각 작업이 DB 연결을 점유하거나 파일을 열거나 큰 버퍼를 할당하거나 API 쿼터를 소진한다면 고정 동시성은 서비스를 안정적으로 유지하면서 안전한 최대 처리량에 도달하게 해줍니다.

지연(특히 p99)은 차이가 자주 드러나는 곳입니다. 작업당 고루틴은 낮은 부하에서는 좋아 보이다가 너무 많은 작업이 쌓이면 급격히 성능이 떨어질 수 있습니다. 풀은 큐잉 지연을 도입하지만 동일한 한계를 놓고 벌어지는 쓰나미 같은 경쟁을 피하므로 동작이 더 안정적입니다.

간단한 사고 모델:

• 작업이 가볍고 독립적이면 더 많은 동시성이 처리량을 올릴 수 있습니다.
• 작업이 공유 한계로 막혀 있다면 더 많은 동시성은 대부분 대기만 늘립니다.
• p99를 신경 쓴다면 큐 대기 시간을 처리 시간과 별도로 측정하세요.

메모리와 자원 사용

워커 풀 대 작업당 고루틴 논쟁의 많은 부분은 사실 메모리에 관한 것입니다. CPU는 보통 수직/수평 확장으로 해결할 수 있지만 메모리 장애는 더 갑작스럽고 서비스 전체를 끌어낼 수 있습니다.

고루틴은 싸지만 공짜는 아닙니다. 각 고루틴은 깊이 호출하거나 큰 지역 변수를 보유할 때 증가하는 작은 스택으로 시작합니다. 스케줄러와 런타임 오버헤드도 있습니다. 만 명의 고루틴은 괜찮을 수 있지만 십만 명은 각자가 큰 작업 데이터를 참조하면 놀랄 수 있습니다.

더 큰 숨은 비용은 종종 고루틴 자체가 아니라 그것이 유지하는 참조입니다. 작업이 끝나는 속도보다 도착 속도가 빠르면 작업당 고루틴은 무한한 백로그를 만듭니다. 큐는 암묵적일 수도 있고(락이나 I/O를 기다리는 고루틴) 명시적일 수도 있습니다(버퍼된 채널, 슬라이스, 인메모리 배치). 어쨌든 메모리는 백로그와 함께 증가합니다.

워커 풀은 한도를 강제하기 때문에 도움이 됩니다. 고정 워커와 유한 큐를 사용하면 실제 메모리 상한과 명확한 실패 모드가 생깁니다: 큐가 가득 차면 블록하거나, 로드를 버리거나, 상류로 역압(force backpressure)을 보내는 등의 동작을 합니다.

대충 계산해 보면:

• 피크 고루틴 수 = 워커 + 처리 중(in-flight) 작업 + 생성해 둔 대기 작업
• 작업당 메모리 = 페이로드(바이트) + 메타데이터 + 참조하는 모든 것(요청, 디코딩된 JSON, DB 행 등)
• 피크 백로그 메모리 ~= 대기 작업 수 * 작업당 메모리

예: 각 작업이 200KB 페이로드를 참조하고 5,000개의 작업이 쌓이면 약 1GB가 페이로드로만 필요합니다. 고루틴이 마법처럼 무료여도 백로그는 무시할 수 없습니다.

백프레셔(Backpressure): 시스템이 녹지 않게 하기

백프레셔는 간단합니다: 작업이 처리 속도보다 빨리 도착하면 시스템은 조용히 쌓이게 두지 않고 제어된 방식으로 밀어냅니다. 그렇지 않으면 단순히 느려지는 것을 넘어 타임아웃, 메모리 증폭, 복제하기 어려운 실패가 발생합니다.

부재를 보통 버스트(임포트, 이메일, 내보내기)가 메모리가 올라가도 떨어지지 않거나 큐 대기 시간이 늘어나는데 CPU는 바쁘게 보이는 현상, 관련 없는 요청의 지연 급증, 재시도 폭주, "too many open files" 같은 오류와 연결 풀 고갈 등에서 알아차립니다.

실용적인 도구는 유한 채널입니다: 몇 개의 작업만 대기할 수 있게 제한하세요. 채널이 가득하면 생산자가 블록되어 작업 생성 자체를 늦춥니다.

블록킹이 항상 정답은 아닙니다. 선택적 작업이라면 과부하 시 예측 가능한 정책을 고르세요:

• 버리기(Drop): 낮은 가치 작업(중복 알림 등)을 버립니다.
• 배치(Batch): 작은 작업 여러 개를 하나의 쓰기나 API 호출로 묶습니다.
• 지연(Delay): 재시도 폭주를 피하려면 지터를 섞어 지연합니다.
• 위임(Defer): 영구 큐로 작업을 옮기고 빠르게 반환합니다.
• 부하 분산(Shed load): 이미 과부하일 때 명확한 오류를 반환합니다.

레이트 리미팅과 타임아웃도 백프레셔 도구입니다. 레이트 리미트는 의존성(이메일 제공자, DB, 서드파티 API)에 도달하는 속도를 제한합니다. 타임아웃은 워커가 묶여 있는 시간을 제한합니다. 둘을 함께 쓰면 느린 의존성이 전체 아웃리지를 일으키는 것을 막습니다.

예: 월말 명세서 생성. 10,000건의 요청이 동시에 들어오면 무한 고루틴은 10,000개의 PDF 렌더링과 업로드를 유발할 수 있습니다. 유한 큐와 고정 워커를 두면 안전한 속도로 렌더링하고 재시도할 수 있습니다.

워커 풀을 단계별로 만드는 방법

워커 풀은 고정된 워커 수를 운영하고 큐에서 작업을 공급해 동시성을 제한합니다.

1) 안전한 동시성 한계 정하기

작업이 어디에 시간을 쓰는지부터 시작하세요.

• CPU 중심 작업은 워커를 CPU 코어 수와 가깝게 유지하세요.
• I/O 중심 작업(DB, HTTP, 스토리지)은 더 높게 설정할 수 있지만 의존성이 타임아웃하거나 쓰로틀링하기 시작하면 멈추세요.
• 혼합형 작업은 측정하고 조정하세요. 보통 CPU 코어의 2배에서 10배 사이에서 시작해 튜닝합니다.
• 공유 한계를 존중하세요. DB 풀이 20 연결이면 워커 200은 그 20을 놓고 싸우게 될 뿐입니다.

2) 큐와 크기 선택

버퍼드 채널은 내장되어 있고 이해하기 쉬워서 흔히 사용됩니다. 버퍼는 버스트를 흡수하는 충격 흡수기입니다.

작은 버퍼는 과부하를 빨리 드러냅니다(발생자가 더 빨리 블록됨). 큰 버퍼는 스파이크를 완화하지만 문제를 숨기고 메모리와 지연을 증가시킬 수 있습니다. 버퍼 크기를 목적에 맞게 정하고 가득 찼을 때의 동작을 결정하세요.

3) 모든 작업을 취소 가능하게 만들기

각 작업에 context.Context를 전달하고 작업 코드가 이를 사용하도록 하세요(DB, HTTP 등). 이렇게 하면 배포나 종료, 타임아웃 시 깔끔하게 중단할 수 있습니다.

func StartPool(ctx context.Context, workers, queueSize int, handle func(context.Context, Job) error) chan<- Job {
    jobs := make(chan Job, queueSize)
    for i := 0; i < workers; i++ {
        go func() {
            for {
                select {
                case <-ctx.Done():
                    return
                case j := <-jobs:
                    _ = handle(ctx, j)
                }
            }
        }()
    }
    return jobs
}

(코드 블록은 변경하지 않았습니다.)

4) 실제로 쓸 메트릭 추가

몇 가지 핵심 수치만 추적하세요:

• 큐 깊이(얼마나 밀려있는가)
• 워커 바쁨 비율(풀이 얼마나 포화 상태인지)
• 작업 소요 시간(p50, p95, p99)
• 에러율(재시도 횟수 포함)

이 정도로 워커 수와 큐 크기를 증거 기반으로 조정할 수 있습니다.

흔한 실수와 함정들

대부분의 팀은 잘못된 패턴 선택으로 큰 피해를 보지 않습니다. 오히려 작은 기본값들이 트래픽 급증 시 인시던트로 커집니다.

고루틴이 불어나버릴 때

클래식한 함정은 버스트 중에 작업당 고루틴을 무분별하게 띄우는 것입니다. 수백 개는 괜찮지만 수십만 개는 스케줄러, 힙, 로그, 소켓을 범람시킬 수 있습니다. 각 고루틴이 작아도 총 비용은 쌓이고 이미 진행 중인 작업 때문에 회복에 시간이 걸립니다.

또 다른 실수는 거대한 버퍼드 채널을 "백프레셔"로 오해하는 것입니다. 큰 버퍼는 단지 숨겨진 큐일 뿐입니다. 시간을 벌어줄 수는 있지만 메모리 벽에 도달할 때까지 문제를 숨깁니다. 큐가 필요하다면 크기를 의도적으로 정하고 가득 찼을 때의 동작을 정하세요(블록, 드롭, 나중에 재시도, 영구 저장 등).

숨겨진 병목

많은 백그라운드 작업은 CPU 바운드가 아닙니다. 하위 시스템에 의해 제한됩니다. 그런 한계를 무시하면 빠른 생산자가 느린 소비자를 압도합니다.

흔한 함정들:

• 취소나 타임아웃이 없어 워커가 API 요청이나 DB 쿼리에 영구히 블록됨
• DB 연결, 디스크 I/O, 서드파티 레이트 캡 같은 실제 한계를 확인하지 않고 워커 수를 정함
• 재시도가 부하를 증폭시킴(실패한 1,000개 작업을 즉시 재시도)
• 모든 것을 직렬화하는 하나의 락 또는 단일 트랜잭션
• 가시성 부족: 큐 깊이, 작업 오래됨, 재시도 수, 워커 활용률 같은 메트릭 없음

예: 야간 내보내기가 20,000개의 "알림 전송" 작업을 만들면 각 작업이 DB와 이메일 제공자를 호출해 연결 풀이나 쿼터를 넘기기 쉽습니다. 워커 50개와 작업별 타임아웃, 작은 큐가 있다면 한계가 분명합니다. 작업당 고루틴과 거대한 버퍼는 시스템이 멀쩡해 보이다가 갑자기 무너집니다.

예시: 버스트성 내보내기와 알림

지원 팀이 감사를 위해 데이터를 내보내야 한다고 합시다. 한 사람이 "Export" 버튼을 누르고 몇 명의 동료가 따라 누르면 1분 내에 5,000개의 내보내기 작업이 생성될 수 있습니다. 각 내보내기는 DB에서 읽고 CSV를 만들고 파일을 저장한 뒤 준비되면 이메일(또는 Telegram)로 알립니다.

작업당 고루틴 방식에서는 처음엔 시스템이 좋아 보입니다. 5,000개의 작업이 거의 동시에 시작되어 큐가 빠르게 비워지는 것처럼 보입니다. 하지만 곧 비용이 드러납니다: 수천 개의 동시 DB 쿼리가 연결을 놓고 경쟁하고, 작업이 동시에 버퍼를 잡아 메모리가 올라가며, 타임아웃이 늘어납니다. 빠르게 끝날 수 있었던 작업들이 재시도와 느린 쿼리 뒤에 막혀버립니다.

워커 풀에서는 시작은 느려도 전체적으로는 안정적입니다. 워커 50개라면 한 번에 50개의 내보내기만 무거운 작업을 합니다. DB 사용은 예측 가능한 범위에 있고 버퍼는 더 자주 재사용됩니다. 총 완료 시간도 추정하기 쉬워집니다: 대략 (작업 수 / 워커 수) * 평균 작업 시간, 약간의 오버헤드 포함.

차이는 풀 때문에 작업이 마법처럼 빨라지는 것이 아닙니다. 버스트 동안 시스템이 스스로를 망가뜨리지 못하게 막는 것입니다. 제어된 50개 동시 처리가 서로 싸우는 5,000개보다 종종 더 빨리 끝납니다.

어디에 백프레셔를 적용할지는 보호하고 싶은 대상에 따라 다릅니다:

• API 레이어에서 시스템이 바쁠 때 새 내보내기 요청을 거부하거나 지연하세요.
• 큐에서 요청을 받아 안전한 속도로 작업을 비우세요.
• 워커 풀에서 비용이 큰 부분(DB 읽기, 파일 생성, 알림 전송)의 동시성을 제한하세요.
• 자원별로 한계를 분리하세요(예: 내보내기는 40워커, 알림은 10워커).
• 외부 호출에는 이메일/SMS/Telegram 레이트 리미터를 걸어 차단당하지 않게 하세요.

배포 전 빠른 체크리스트

프로덕션에서 백그라운드 작업을 실행하기 전에 한 번 한계를 확인하고 가시성 및 실패 처리 방안을 점검하세요. 대부분의 사고는 "느린 코드"보다 트래픽 급증이나 의존성 불안정 시 가드레일이 없어서 발생합니다.

• 의존성별 최대 동시성 설정. 모든 것을 하나의 전역 숫자로 해결하려 들지 마세요. DB 쓰기, 외부 HTTP 호출, CPU 집약 작업을 별도로 제한하세요.
• 큐를 유한하고 관찰 가능하게 만드세요. 대기 작업 수에 실질적인 한계를 두고 몇 가지 메트릭(큐 깊이, 가장 오래된 작업의 나이, 처리율)을 노출하세요.
• 지터가 포함된 재시도와 데드레터 경로 추가. 선택적으로 재시도하고 재시도를 분산시키며 N번 실패 후 데드레터 큐나 "failed" 테이블로 옮겨 재생성할 수 있게 하세요.
• 종료 동작 검증: 드레인, 취소, 안전한 재개. 배포나 크래시 시 어떻게 할지 결정하세요. 작업을 멱등하게 만들고(다시 처리해도 안전), 긴 워크플로의 진행을 저장하세요.
• 타임아웃과 서킷 브레이커로 시스템 보호. 모든 외부 호출에 타임아웃을 걸고, 의존성이 다운되면 빨리 실패하거나 인테이크를 멈추게 하세요.

실용적인 다음 단계

정상적인 날의 시스템 모습에 맞는 패턴을 고르세요. 버스트(업로드, 내보내기, 이메일 폭발)가 있다면 유한 큐가 있는 고정 워커 풀이 보통 더 안전한 기본값입니다. 작업이 안정적이고 각 작업이 작다면 작업당 고루틴이 괜찮습니다. 단, 어디선가 한계는 반드시 걸어두세요.

성공하는 선택은 보통 실패를 지루하게 만드는 것입니다. 풀은 한계를 명확히 합니다. 작업당 고루틴은 첫 번째 실제 급증까지 한계를 잊기 쉽습니다.

간단하게 시작하고 한계와 가시성을 더하세요

단순한 것으로 시작하되 초기에 두 가지 제어를 추가하세요: 동시성 한계와 큐잉 및 실패를 볼 수 있는 방법.

실용적 롤아웃 계획:

• 워크로드 형태 정의: 버스트성, 안정적, 혼합형(피크는 어떤 수준인지).
• 인플라이트 작업에 대한 하드 캡 설정(풀 크기, 세마포어, 유한 채널).
• 캡이 찼을 때 동작 결정: 블록, 드롭, 명확한 오류 반환.
• 기본 메트릭 추가: 큐 깊이, 큐에서의 시간, 처리 시간, 재시도 및 데드레터.
• 예상 피크의 5배에 해당하는 버스트로 부하 테스트를 수행하고 메모리와 지연을 관찰하세요.

풀만으로 부족할 때

워크플로가 분 단위에서 일 단위까지 걸리면 단순 풀은 힘들 수 있습니다. 작업이 단순히 "한 번 처리"가 아니기 때문입니다. 상태, 재시도, 재개 가능성이 필요합니다. 보통 진행 상태를 영구화하고, 멱등한 단계로 구성하고, 백오프를 적용해야 합니다. 큰 작업을 더 작은 단계로 분리해 충돌 후 안전하게 재개할 수 있도록 하는 것도 방법입니다.

완전한 백엔드를 워크플로와 함께 더 빨리 내고 싶다면 AppMaster (appmaster.io) 같은 도구가 실용적일 수 있습니다: 데이터를 시각적으로 모델링하고 실제 Go 코드를 생성해 동시성 한계, 큐잉, 백프레셔 관리를 직접 연결하지 않고도 유지할 수 있습니다.