Nginx가 대량 동시접속에 강한 진짜 이유
"Nginx가 Apache보다 빠르다"는 말은 자주 듣지만, 정확히 어느 지점에서 얼마나 빠른지 설명할 수 있는 사람은 드뭅니다. 실제로는 "항상 빠르다"가 아니라 "동시접속이 많을 때 압도적으로 유리하다"가 정확한 표현입니다. 그 차이는 CPU 성능이 아니라 각 서버가 연결(connection) 하나를 처리하는 방식 자체가 다르기 때문에 생깁니다. 이 가이드는 두 아키텍처의 근본 차이를 숫자로 확인합니다.
1. Apache의 전통 모델: 연결마다 실행 단위 하나
Apache의 기본 MPM(Multi-Processing Module)인 prefork·worker 방식은 클라이언트 연결이 들어올 때마다 프로세스 또는 스레드를 하나씩 배정합니다. 연결이 유휴 상태로 대기 중이어도 그 프로세스/스레드는 메모리를 점유한 채 계속 살아 있습니다. 동시접속 1만 개가 들어오면 이론상 1만 개의 실행 단위가 동시에 존재해야 하고, 이는 곧 1만 번의 컨텍스트 스위칭 후보가 생긴다는 뜻입니다. 프로세스 하나당 메모리 사용량이 수 MB 수준이라면, 동시접속이 늘어날수록 서버 메모리가 선형적으로 바닥나는 구조입니다.
2. Nginx의 이벤트 루프: 연결이 아니라 이벤트를 처리한다
Nginx는 반대로 접근합니다. 적은 수의 워커 프로세스(보통 CPU 코어 수만큼)가 각각 하나의 이벤트 루프를 돌면서, epoll(Linux)·kqueue(BSD) 같은 OS 커널의 논블로킹 I/O 알림 메커니즘을 이용해 수천 개의 연결을 동시에 감시합니다. 연결 하나에 스레드를 배정하는 게 아니라, "이 소켓에 읽을 데이터가 생겼다"는 이벤트가 발생할 때만 해당 작업을 처리하고 즉시 다음 이벤트로 넘어갑니다. 유휴 연결은 사실상 커널이 대신 감시해주므로 워커 프로세스의 메모리·CPU를 거의 쓰지 않습니다. 그 결과 동일한 하드웨어에서 Nginx는 Apache prefork 대비 훨씬 적은 메모리로 훨씬 많은 동시접속을 버틸 수 있습니다. 이 아키텍처 차이가 Nginx가 리버스 프록시·정적 파일 서빙·로드밸런서로 널리 쓰이는 핵심 이유입니다.
3. worker_processes와 worker_connections: 이벤트 모델의 실제 손잡이
Nginx의 이벤트 모델을 실제로 제어하는 두 지시문은 nginx.conf 최상단(main context)의 worker_processes와 events {} 블록 안의 worker_connections입니다. worker_processes auto;로 두면 CPU 코어 수만큼 워커를 띄우고, worker_connections는 워커 하나가 동시에 열 수 있는 최대 연결 수(기본값 1024)를 정합니다. 즉 이 서버가 이론상 처리 가능한 최대 동시접속 수는 worker_processes × worker_connections로 계산됩니다. 코어 4개에 worker_connections 4096이면 이론상 16,384개 동시 연결까지 버틸 수 있다는 뜻입니다(단, OS의 파일 디스크립터 한도인 ulimit도 함께 늘려야 실제로 그만큼 열립니다).
다만 이 두 지시문은 서버 전체에 적용되는 main/events 컨텍스트 설정이라, 도메인별 SSL·리버스 프록시·Gzip을 조립하는 Nginx 설정 생성기가 만들어주는 server 블록 출력물에는 포함되지 않습니다. 이벤트 모델 자체를 조정하려면 생성기가 만든 server 블록과는 별도로 nginx.conf 최상단을 직접 편집해야 합니다 — 이 구분을 모르고 server 블록 안에서 worker_connections를 찾다가 "설정이 없다"고 헤매는 경우가 흔합니다.
4. 그럼 Apache는 왜 아직도 쓰이나
동시접속 처리 성능만 보면 Nginx가 유리하지만, Apache는 요청마다 독립된 프로세스/스레드가 있다는 바로 그 특성 덕분에 .htaccess를 통한 디렉토리별 동적 설정 변경, mod_php 같은 인프로세스 모듈 확장이 유연합니다. 정적 파일과 리버스 프록시 앞단은 Nginx, 레거시 PHP 애플리케이션이나 공유 호스팅 환경은 Apache라는 조합이 실무에서 흔히 쓰이는 이유입니다. Apache 설정 생성기와 .htaccess 생성기로 두 방식의 설정 문법 차이를 직접 비교해볼 수 있습니다.
5. 실전 체크: 내 서버가 이벤트 모델의 이점을 받고 있는가
Nginx를 앞단에 뒀다고 자동으로 빨라지는 것은 아닙니다. worker_connections가 기본값(1024)에 머물러 있거나, Keep-Alive 타임아웃이 지나치게 길어 유휴 연결이 오래 점유되거나, gzip·정적 캐싱이 꺼져 있으면 이벤트 루프의 이점을 충분히 못 살립니다. 응답 헤더와 캐시 정책이 실제로 적용되고 있는지는 HTTP 헤더 체커로, 전반적인 응답 속도는 웹사이트 속도 측정기로 확인하는 것이 빠릅니다.
자주 묻는 질문
Q. Nginx는 항상 Apache보다 빠른가요?
아닙니다. 단일 요청 처리 속도 자체는 큰 차이가 없거나 콘텐츠 종류에 따라 달라집니다. Nginx가 확실히 유리한 지점은 "동시접속 수가 많을 때 메모리·CPU를 얼마나 적게 쓰며 버티는가"입니다.
Q. worker_processes를 무조건 높게 설정하면 좋은가요?
아닙니다. CPU 코어 수보다 많은 워커는 오히려 컨텍스트 스위칭 비용만 늘립니다. 공식 권장값은 auto(코어 수만큼)이며, 코어 수를 넘겨 늘려도 성능이 비례해서 좋아지지 않습니다.
Q. Nginx 설정 생성기로 만든 파일에 이벤트 모델 설정도 포함되나요?
아닙니다. 생성기는 도메인별 server 블록(SSL·프록시·Gzip·헤더·캐싱)만 조립합니다. worker_processes·worker_connections는 nginx.conf 최상단 main/events 컨텍스트에 속하는 서버 전역 설정이라 별도로 직접 편집해야 합니다.
Q. epoll·kqueue는 무엇인가요?
둘 다 OS 커널이 제공하는 I/O 이벤트 알림 메커니즘입니다. epoll은 Linux, kqueue는 BSD 계열(macOS 포함)에서 쓰이며, Nginx는 이를 이용해 수천 개 소켓의 상태 변화를 적은 오버헤드로 감시합니다.