Worker 수를 몇 개로 설정해야 할까

적정 워커 수를 결정하는 전략적인 가이드

소프트웨어 개발이나 서버 운영을 하다 보면 누구나 한 번쯤 마주하는 고민이 있습니다. 바로 시스템의 성능을 최적화하기 위해 워커(Worker) 수를 몇 개로 설정해야 하는가 하는 문제입니다. 워커는 작업을 처리하는 일꾼과 같습니다. 일꾼이 너무 적으면 작업이 밀려 병목 현상이 발생하고, 너무 많으면 서로 자원을 차지하려고 싸우거나 관리 비용이 늘어나 오히려 효율이 떨어집니다. 이 가이드에서는 시스템의 성능을 극대화할 수 있는 적정 워커 수 산정 원칙과 실무적인 팁을 상세히 다룹니다.

워커의 개념과 시스템 성능의 관계

워커란 컴퓨터 시스템에서 특정 작업을 수행하기 위해 할당된 프로세스나 스레드를 의미합니다. 웹 서버를 예로 들면, 클라이언트로부터 들어오는 요청을 처리하는 것이 바로 워커의 역할입니다. 워커 수가 적절하다는 것은 시스템의 CPU와 메모리 자원을 낭비하지 않으면서도 대기 시간을 최소화한다는 뜻입니다.

성능 최적화의 핵심은 ‘처리량(Throughput)’과 ‘지연 시간(Latency)’ 사이의 균형을 맞추는 것입니다. 워커 수를 무작정 늘린다고 해서 성능이 무한히 좋아지지 않습니다. 오히려 컨텍스트 스위칭(Context Switching)이라는 비용이 발생합니다. CPU는 한 번에 처리할 수 있는 작업의 양이 정해져 있는데, 워커가 너무 많으면 CPU가 작업을 처리하는 시간보다 일꾼들 사이를 오가며 상태를 저장하고 불러오는 데 더 많은 시간을 쏟게 됩니다.

작업의 유형에 따른 워커 설정 전략

워커 수를 결정할 때는 현재 처리하려는 작업이 어떤 성격을 띠고 있는지 파악하는 것이 가장 중요합니다. 크게 CPU 집약적인 작업과 입출력 집약적인 작업으로 나뉩니다.

CPU 집약적인 작업

이미지 처리, 영상 인코딩, 복잡한 수학 계산처럼 CPU를 100% 활용해야 하는 작업입니다. 이런 경우에는 워커 수를 CPU 코어 수와 비슷하게 맞추는 것이 가장 좋습니다. 코어 수보다 워커가 많아지면 CPU는 계속해서 작업을 전환해야 하므로 오히려 전체 속도가 느려집니다. 일반적으로 코어 수와 동일하게 설정하거나, 약간 적게 설정하여 시스템의 다른 프로세스가 숨 쉴 틈을 주는 것이 좋습니다.

입출력 집약적인 작업

데이터베이스 조회, 외부 API 호출, 파일 읽기 쓰기처럼 CPU 보다는 네트워크나 디스크의 응답을 기다리는 시간이 많은 작업입니다. 이런 작업은 CPU가 일을 하지 않고 대기하는 시간이 깁니다. 따라서 워커 수를 코어 수보다 훨씬 많이 설정해도 괜찮습니다. CPU가 대기하는 동안 다른 워커가 작업을 처리할 수 있기 때문입니다. 보통 코어 수의 2배에서 4배, 혹은 그 이상을 설정하기도 합니다.

적정 워커 수를 계산하는 실무 공식

수학적인 접근을 통해 워커 수를 산출하는 공식이 존재합니다. 가장 널리 알려진 공식은 다음과 같습니다.

워커 수 = CPU 코어 수 * (1 + 대기 시간 / 처리 시간)

이 공식에서 대기 시간은 작업이 입출력 등을 기다리는 시간이고, 처리 시간은 CPU가 실제로 작업을 수행하는 시간입니다. 예를 들어, 어떤 작업이 1초 동안 실행되는데 그중 0.5초는 CPU를 쓰고 0.5초는 DB를 기다린다면, 대기 시간/처리 시간의 비율은 1이 됩니다. 이 경우 워커 수는 코어 수의 2배가 적당하다는 계산이 나옵니다. 이 공식을 적용하려면 자신의 시스템에서 모니터링 도구를 통해 실제 대기 시간과 처리 시간을 측정해보는 과정이 반드시 필요합니다.

흔한 오해와 사실 관계

워커 설정과 관련하여 많은 개발자가 오해하는 부분들이 있습니다. 이를 바로잡아야 효율적인 운영이 가능합니다.

• 오해 1: 워커가 많을수록 무조건 빠르다. 사실이 아닙니다. 앞서 언급했듯 컨텍스트 스위칭 비용이 증가하여 시스템 전체 성능이 급격히 저하되는 ‘스래싱(Thrashing)’ 현상이 발생할 수 있습니다.
• 오해 2: 메모리가 충분하면 워커를 많이 띄워도 된다. 메모리 용량은 워커의 개수를 결정하는 하나의 요소일 뿐입니다. 워커가 많아지면 메모리 점유율도 높아지지만, 그보다 먼저 CPU 자원이나 파일 디스크립터(File Descriptor) 제한에 걸릴 가능성이 큽니다.
• 오해 3: 서버 사양이 좋아지면 워커 수도 무조건 늘려야 한다. 사양이 좋아졌다면 워커 개수를 늘리는 것보다, 병렬 처리가 가능한 아키텍처로 개선하거나 비동기 처리를 도입하는 것이 더 근본적인 해결책입니다.

비용 효율적인 워커 운영 팁

클라우드 환경에서 서버를 운영한다면 비용 관리도 중요한 요소입니다. 워커 수를 무리하게 늘려 서버 스펙을 올리는 것보다, 다음과 같은 방법을 우선 고려해보세요.

• 오토스케일링 활용: 트래픽이 많을 때만 워커가 늘어나고, 적을 때는 줄어들도록 설정하세요. 이는 클라우드 비용을 획기적으로 줄여줍니다.
• 비동기 처리 도입: 시간이 오래 걸리는 작업은 워커가 직접 처리하게 하지 말고, 메시지 큐(Message Queue)를 활용하여 별도의 워커 풀에서 처리하도록 분리하세요. 이렇게 하면 웹 서버의 워커는 응답 속도를 빠르게 유지할 수 있습니다.
• 프로파일링: 어떤 부분에서 병목이 발생하는지 모니터링 도구로 분석하세요. DB 연결 대기 때문인지, 메모리 부족 때문인지 원인을 정확히 알아야 워커 수를 늘릴지, 쿼리를 최적화할지 결정할 수 있습니다.

전문가가 제안하는 검증 방법

이론적인 계산도 중요하지만, 실제 환경에서의 검증은 필수입니다. 전문가들은 ‘부하 테스트(Load Test)’를 강력히 권장합니다. Apache JMeter나 k6, Locust 같은 도구를 사용하여 실제 운영 환경과 유사한 트래픽을 발생시켜 보세요.

처음에는 코어 수의 1배부터 시작하여, 워커 수를 단계적으로 늘려가며 응답 시간과 CPU 사용률을 그래프로 그려보세요. 어느 지점부터 응답 시간이 급격히 길어지거나 CPU 사용률이 포화 상태에 도달하는지 확인하는 것이 가장 정확한 방법입니다. 그 지점이 바로 당신의 시스템에서 설정할 수 있는 최대 워커 수입니다. 안전을 위해 그 지점의 80% 정도를 운영 수치로 잡는 것이 좋습니다.

자주 묻는 질문과 답변

Q: CPU 코어 수를 어떻게 확인하나요?

리눅스 환경이라면 명령줄에 ‘nproc’을 입력하거나 ‘/proc/cpuinfo’ 파일을 확인하면 됩니다. 클라우드 환경이라면 해당 인스턴스의 사양 페이지에서 vCPU 개수를 확인하세요.

Q: 워커 수 설정 시 메모리 부족 현상이 발생합니다. 어떻게 해야 할까요?

워커당 메모리 점유율이 높다면, 워커 수를 줄이고 비동기 프로그래밍 방식(Node.js의 이벤트 루프나 Python의 Asyncio 등)을 검토하세요. 혹은 더 가벼운 프로세스 모델을 사용하는 서버 엔진(예: Gunicorn 대신 uWSGI 등)으로 교체하는 것도 방법입니다.

Q: 데이터베이스 연결 풀(Connection Pool)과 워커 수는 어떤 관계인가요?

매우 밀접합니다. 워커가 100개인데 DB 커넥션 풀이 10개라면, 90개의 워커는 DB를 쓰지 못해 대기하게 됩니다. 워커 수와 커넥션 풀의 크기는 비례하거나, 적어도 워커가 대기하지 않을 정도로 충분한 커넥션 풀이 확보되어야 합니다.

시스템 최적화의 핵심은 관찰

워커 수를 결정하는 정답은 시스템마다 모두 다릅니다. 어떤 환경에서는 4개가 최적이지만, 다른 환경에서는 50개가 필요할 수도 있습니다. 중요한 것은 고정된 숫자를 정해두고 잊어버리는 것이 아니라, 시스템의 변화와 트래픽의 흐름을 지속해서 관찰하는 습관입니다. 모니터링을 통해 얻은 데이터를 바탕으로 조금씩 조정해 나가는 과정 자체가 시스템 운영의 실력입니다.

처음에는 보수적으로 시작하세요. 시스템이 안정적으로 돌아가는 것을 확인한 뒤, 단계적으로 워커 수를 늘리며 성능 향상을 꾀하는 방식이 가장 안전합니다. 시스템의 자원을 효율적으로 사용하는 것은 단순히 비용을 절감하는 것을 넘어, 사용자에게 더 빠르고 쾌적한 서비스를 제공하는 가장 확실한 방법입니다.