Node.js 성능 최적화의 실제 — 느린 지점을 찾고 고치는 순서

Node.js에서 병렬화하자는 말은 생각보다 선택지가 많다. 같은 프로세스 안에서 Worker Threads로 나눌 수도 있고, cluster로 프로세스를 여러 개 띄울 수도 있고, 아예 메시지 큐 뒤로 빼서 비동기 작업으로 돌릴 수도 있다. 여기서 중요한 건 정답을 외우는 게 아니라 비용 구조를 이해하는 거다.

Worker Threads는 CPU 집약 작업을 메인 이벤트 루프에서 떼어낼 때 가장 직선적인 선택지다. 이미지 처리, 대형 CSV 파싱, 암호화처럼 계산이 분명한 작업에 잘 맞는다. 다만 데이터 전달 비용을 과소평가하면 금방 실망한다. 작업 본문은 빨라졌는데 직렬화와 복사 비용으로 전체 시간은 그대로인 경우가 실제로 많다.

cluster는 HTTP 요청 자체를 여러 프로세스에 분산하고 싶을 때 유효하다. 다만 이건 계산을 병렬화한다기보다 수용량을 늘리는 전략에 가깝다. 메모리도 프로세스마다 복제되고, in memory cache는 자연스럽게 분산된다. 그래서 세션, 캐시, rate limit을 어디에 둘지 같이 설계하지 않으면 운영 복잡도가 확 올라간다.

메시지 큐나 별도 worker service는 응답 시간과 작업 완료 시간을 분리하고 싶을 때 강하다. 사용자는 즉시 202 응답을 받고, 무거운 작업은 뒤에서 처리한다. 대신 시스템은 더 복잡해진다. 재시도, 멱등성, dead letter, 순서 보장 같은 문제가 새로 생긴다. 빠르게 만든 작은 비동기 시스템이 나중에 제일 많이 괴롭히는 경우도 많이 봤다.

그래서 제 기준은 이렇다. 사용자 요청 경로에서 즉시 계산이 꼭 필요하면 Worker Threads, 수평 확장이 먼저면 cluster 혹은 컨테이너 레벨 스케일 아웃, 완료를 늦춰도 되면 queue다. 한 가지로 통일하는 것보다 작업 유형별로 다르게 고르는 편이 낫다. 저는 Node.js 성능 문제를 런타임 문제로만 안 본다. 아키텍처 선택 문제이기도 하다.

> 💡 **다음 챕터**: 문제를 고쳤다고 생각했는데 더 위험해지는 순간이 있다. 다음 챕터에서는 현장에서 자주 보는 최적화 역효과를 정리한다.

Node.js 성능 최적화 Ch5 — Worker Threads, cluster, queue를 어떻게 고를까

// COMMENTS

ON THIS PAGE