웹 개발 좀 해봤다 하는 사람치고 Nginx(엔진엑스라고 읽는다) 이름을 못 들어본 사람은 없을 거다. 마치 웹 서버계의 아이돌 같은 존재랄까? 근데 Nginx가 정확히 뭐 하는 친구고, 왜 이렇게 인기가 많은 걸까? 그리고 항상 같이 언급되는 Apache(아파치)와는 도대체 뭐가 다른 걸까?

오늘은 웹 서버계의 양대 산맥, Nginx와 Apache를 비교하며 Nginx의 매력을 집중 탐구해보는 시간을 가져보려 한다.

Nginx, 넌 대체 누구니? (만능 재주꾼 소개)

Nginx는 단순히 웹 서버 역할만 하는 것이 아니라, 다양한 재주를 가진 만능 엔터테이너다. 주요 역할만 해도 이 정도다:

  • 웹 서버 (Web Server): 기본적인 역할. HTML, CSS, Javascript, 이미지 파일 같은 정적 콘텐츠(Static Contents)를 클라이언트(웹 브라우저)에게 슝슝 보내준다.
  • 리버스 프록시 (Reverse Proxy): 클라이언트 요청을 직접 처리하지 않고, 뒤에 숨어있는 실제 서버(WAS 등)들에게 전달해주고 응답을 받아 다시 클라이언트에게 전달하는 중간 대리인 역할. 보안 강화, 캐싱, 로드 밸런싱 등 다양한 부가 효과는 덤!
  • 로드 밸런서 (Load Balancer): 여러 대의 서버에게 들어오는 요청(트래픽)을 골고루 나눠주는 교통정리 역할. 특정 서버에 과부하가 걸리는 것을 막아 서비스 안정성을 높인다.
  • HTTP 캐시 (HTTP Cache): 자주 요청되는 콘텐츠를 미리 저장해두었다가 빠르게 응답해주는 똑똑한 창고 역할. 서버 부담을 줄이고 응답 속도를 높인다.
  • 메일 프록시 (Mail Proxy): 이메일 관련 프로토콜(SMTP, POP3, IMAP)을 위한 프록시 기능도 제공한다. (이건 좀 덜 유명하지만…)

한마디로 웹 서비스를 위한 온갖 궂은일(?)을 도맡아 하는 멀티플레이어라고 할 수 있다.

Apache vs Nginx: 세기의 라이벌, 뭐가 다를까?

Nginx 이야기를 할 때 절대 빼놓을 수 없는 존재가 바로 Apache다. 오랫동안 웹 서버 시장의 절대 강자였던 Apache와 신흥 강자 Nginx는 처리 방식에서 근본적인 차이를 보인다. 이게 바로 성능 차이로 이어지는 핵심 포인트다!

Apache: 전통의 강호, “한 요청엔 한 일꾼!” (프로세스/스레드 기반)

Apache는 전통적으로 요청(Request) 하나당 프로세스 또는 스레드 하나를 할당하는 방식으로 동작한다. 마치 손님 한 명당 전담 직원 한 명을 붙여주는 식당 같다고 할까?

  • 작동 방식:
    • 클라이언트 요청이 들어오면 새로운 프로세스나 스레드를 생성해서 처리한다. (MPM 방식에 따라 조금씩 다르지만 기본 원리는 비슷)
    • Prefork MPM: 요청마다 프로세스를 복제. 안정적이지만 메모리 소모가 크다.
    • Worker MPM: 여러 스레드가 요청을 나눠 처리. 메모리 효율성은 좋지만 스레드 간 동기화 문제가 있을 수 있다.
    • Event MPM: Worker 방식에 비동기 처리 개념을 더함. (Nginx와 비슷해지려는 노력!)
  • 장점:
    • 오랜 역사만큼 다양한 기능과 모듈(Module)을 지원한다. 호환성이 좋다.
    • 기능 추가나 설정 변경이 비교적 쉽다.
    • 요청 처리가 완료될 때까지 연결을 유지하는 방식에 적합하다.
  • 단점:
    • 동시 접속자 수가 많아지면 성능이 급격히 저하된다. 요청마다 프로세스/스레드를 생성하는 비용(메모리, CPU)이 만만치 않기 때문이다.
    • 소위 C10K 문제(동시 접속 1만 개 처리 문제)에 취약하다.

Apache 처리 방식 예시

Nginx: 떠오르는 신성, “혼자서도 열 요청 거뜬!” (이벤트 기반 비동기)

Nginx는 Apache와 전혀 다른 접근 방식을 택했다. 바로 Event-Driven(이벤트 기반) 아키텍처다. 마치 혼자서 여러 테이블 손님 주문을 동시에 능숙하게 받는 베테랑 직원 같다고 할까?

  • 작동 방식:
    • 미리 정해진 **적은 수의 프로세스(Worker Process)**만 생성한다.
    • 각 프로세스는 하나의 스레드로 동작하며, **여러 개의 연결(Connection)**을 동시에 처리한다.
    • 실제 작업(I/O 등)은 비동기 논블로킹(Asynchronous Non-blocking) 방식으로 처리한다. 즉, 작업이 완료될 때까지 마냥 기다리는 게 아니라, 작업 요청만 해놓고 바로 다른 이벤트를 처리하러 간다. 작업이 완료되면 그때 알려달라고(Callback) 하는 식이다.
  • 장점:
    • 매우 적은 자원(메모리, CPU)으로 높은 동시 접속 처리 성능을 보여준다. C10K 문제 해결사!
    • 비동기 방식으로 동작하여 I/O 작업이 많은 웹 환경에 최적화되어 있다.
    • 정적 파일 처리 속도가 매우 빠르다.
  • 단점:
    • Apache만큼 다양한 모듈을 지원하지는 않는다. (물론 핵심 기능은 충분!)
    • 동적으로 기능을 추가하거나 설정을 변경하는 것이 Apache보다 조금 더 복잡할 수 있다.

Nginx 이벤트 기반 처리 방식 예시

비동기 논블로킹 I/O, 그게 뭔데?

Nginx 성능의 핵심인 Event-Driven과 비동기 논블로킹 I/O를 좀 더 쉽게 이해해보자. Node.js도 이 방식을 사용해서 유명해졌다.

  1. 이벤트 발생 (Event Emit): 클라이언트 요청(Request), 파일 읽기 완료 등 다양한 이벤트가 발생한다. 마치 식당에 손님이 들어오거나, 주방에서 요리가 완성되는 것과 같다.

  2. 이벤트 루프 (Event Loop) 출동: 이벤트 루프는 끊임없이 “뭔 일 없나?” 하고 지켜보다가 이벤트가 발생하면 재빨리 감지한다. 그리고 이 이벤트를 처리할 담당자(Handler)에게 작업을 넘긴다.

  3. 논블로킹 (Non-blocking) 방식의 작업 요청: 만약 처리해야 할 작업이 시간이 오래 걸리는 I/O 작업(파일 읽기/쓰기, 네트워크 통신, 데이터베이스 조회 등)이라면 더욱 Nginx의 진가가 드러날 거다.

    • 기다리지 않는다! (Non-blocking): Nginx(담당 Handler)는 운영체제에게 “이 파일 좀 읽어줘!” 또는 “저 서버에 데이터 좀 보내줘!” 라고 요청만 하고, 그 작업이 끝날 때까지 기다리지 않는다. 마치 주방에 “파스타 하나요!” 라고 주문만 넣고 바로 다른 테이블 주문 받으러 가는 웨이터처럼 이것이 바로 논블로킹이다. 즉, 함수(작업 요청)를 호출했을 때, 작업 완료 여부와 상관없이 즉시 반환되어 다음 코드를 실행할 수 있게 된다.
    • (vs 블로킹 (Blocking)): 만약 블로킹 방식이었다면, 파일 읽기가 다 끝나거나 데이터 전송이 완료될 때까지 그 자리에서 하염없이 기다려야 한다. 그동안 다른 손님(요청)은 아무도 못 받는 거다.

  4. 제어권 반환 & 다른 이벤트 처리: 논블로킹 방식으로 I/O 작업을 요청한 Nginx(담당 Handler)는 프로그램의 실행 흐름(Control, 제어권)을 즉시 이벤트 루프에게 돌려준다. “나는 요청했으니, 이제 다른 일 할게!” 라는 뜻이다.

    • 제어권이란? 프로그램 코드가 순차적으로 실행되는 ‘흐름’을 의미한다. 싱글 스레드 환경에서는 이 실행 흐름이 하나뿐이다. 블로킹 작업은 이 실행 흐름을 멈추고 기다리게 만들지만, 논블로킹 작업은 실행 흐름을 멈추지 않고 계속 이어갈 수 있게 해준다.
    • 제어권을 돌려받은 이벤트 루프는 쉬지 않고 다음 대기 중인 다른 이벤트가 있는지 확인하고 처리한다. 덕분에 하나의 스레드만으로도 여러 요청을 동시에 처리하는 것처럼 보이는 것이 가능하다.

  5. 비동기 (Asynchronous) 방식의 결과 처리: 아까 요청했던 I/O 작업이 드디어 완료되면 어떻게 될까?

    • 알아서 알려준다! (Asynchronous): 운영체제가 “아까 시킨 파일 다 읽었어!” 라고 이벤트 루프에게 알려준다. Nginx가 계속 “다 됐니?” 하고 물어볼 필요가 없다. 이것이 바로 비동기 방식이다. 작업 완료 시점을 Nginx가 신경 쓰지 않고, 완료되면 나중에 통보받는 구조다.
    • 콜백 실행 (Callback): 작업 완료 알림을 받은 이벤트 루프는 해당 작업과 연결된 콜백 함수를 실행 대기열(Task Queue)에 넣는다. 그리고 이벤트 루프는 적절한 시점에 이 콜백 함수를 실행시켜 작업 결과를 처리하거나 다음 작업을 진행한다. “파스타 나왔습니다~” 하고 알려주면, 웨이터가 서빙하는 것과 같다.

결론: 논블로킹은 작업을 기다리지 않고 바로 다음 일을 할 수 있게 해주고, 비동기는 작업 완료를 나중에 통보받아 처리하는 방식이다. 이 둘의 조합 덕분에 Nginx는 CPU가 직접 일하지 않는 I/O 대기 시간 동안 다른 요청들을 효율적으로 처리할 수 있고, 적은 스레드로도 수많은 동시 요청을 감당할 수 있게 되는 것이다. Apache처럼 요청마다 일꾼(프로세스/스레드)을 늘릴 필요가 없으니 자원도 아끼고 성능도 좋아진다.

(참고로 CPU 자원을 많이 사용하는 계산 위주의 작업(CPU-bound)은 이런 비동기 방식의 이점을 크게 누리기 어렵다. Nginx는 웹 서버 특성상 네트워크 I/O가 대부분이므로 이 방식이 매우 효과적이다.)

블로킹? 논블로킹? 동기? 비동기? 헷갈리는 개념 정리!

앞서 논블로킹-비동기 조합이 Nginx의 핵심이라고 했는데, 여기서 잠깐! 블로킹이니 동기니 하는 용어들이 머릿속을 뒤죽박죽 만들 수 있다. 특히 논블로킹과 비동기가 찰떡궁합처럼 같이 쓰이다 보니 더더욱 비슷하게 느껴지기도 한다.

하지만 이 용어들은 서로 다른 관점에서 나온 개념이다. 이 기회에 네 가지 조합이 어떻게 다른지, 그리고 왜 특정 조합이 잘 안 쓰이는지 식당 웨이터 비유를 통해 확실히 정리하고 가자!

  • 블로킹 (Blocking) vs 논블로킹 (Non-blocking): 이 둘은 함수(작업)를 호출한 쪽(호출자, Caller)의 관점이다.

    • 블로킹: 호출한 함수가 작업을 끝낼 때까지 호출자가 그 자리에서 기다리는 것 (실행 흐름 멈춤).
    • 논블로킹: 호출한 함수가 작업 완료 여부와 관계없이 일단 바로 리턴되는 것 (실행 흐름 안 멈춤). “접수 완료!“하고 바로 다음 일 하러 감.

  • 동기 (Synchronous) vs 비동기 (Asynchronous): 이 둘은 호출된 함수(작업)의 결과나 완료를 어떻게 신경 쓰고 통지받는지에 대한 관점이다.

    • 동기: 호출자가 스스로 작업 완료 여부를 계속 확인하거나, 작업이 끝나면 그 순서에 맞춰 결과가 바로 리턴되는 방식. 나가 직접 챙겨야 함.
    • 비동기: 호출자는 작업 완료를 신경 끄고, 작업이 끝나면 다른 누군가(OS, 이벤트 루프 등)가 알아서 콜백이나 이벤트로 알려주는 방식. 나중에 통보받음.

자, 이제 웨이터 등판! 네 가지 조합을 살펴보자.

1. 블로킹 (Blocking) - 동기 (Synchronous): (가장 흔하고 직관적)

  • 동작: 웨이터가 주문(함수 호출)을 받고 주방(호출된 함수)에 전달. 웨이터는 주방 앞에서 요리 나올 때까지 멍때리며 기다림 (블로킹). 요리 완성! 웨이터가 직접 받아서(동기적 결과 반환) 서빙.
  • 설명: 함수 호출하면 그 함수 작업(특히 I/O) 끝날 때까지 스레드가 멈춘다. 작업 끝나면 결과 리턴되고 멈췄던 흐름이 다시 이어진다.
  • 장단점: 코드 짜기 쉽고 이해도 쉽다. 하지만 스레드가 노는 시간이 많아 비효율적 (특히 손님 많을 때).

2. 논블로킹 (Non-blocking) - 동기 (Synchronous):

  • 동작: 웨이터가 주문 전달. 주방에 “다 됐어요?” 바로 물어봄 (논블로킹 호출). 아직이면 일단 다른 테이블 잠깐 봄. 근데 요리 나올 때까지 계속 주방 가서 “다 됐어요??” 들락날락 확인해야 함 (동기적 확인). 요리 완성! 그때 받아옴.
  • 설명: 함수 호출하면 일단 바로 리턴 (예: “아직이요~”). 근데 호출자가 결과 받으려면 계속 함수 다시 호출해서 “다 됐니?” 물어봐야 함 (Polling). 실행 흐름이 멈추진 않지만 계속 물어보느라 바쁨.
  • 장단점: 스레드가 멈추진 않지만, 계속 상태 확인(Polling)하느라 CPU 자원 낭비. 코드도 복잡해짐.

3. 비동기 (Asynchronous) - 블로킹 (Blocking): (이론상으론 가능…?)

  • 동작: 웨이터가 주문 넣고 “다 되면 알려주세요 (비동기 알림 요청)”. 근데 다른 일 안 하고 식당 입구에서 알림 벨만 뚫어져라 쳐다보며 기다림 (블로킹). 사람의 일로 비유하니 이게 뭐지 싶다..
  • 설명: 일반적으론 잘 없다. 함수 호출(이벤트 등록)은 바로 리턴될 수 있는데, 그 결과(이벤트 통지)를 기다리는 다른 특정 지점에서 블로킹될 수 있다 (select, poll 등). 작업 완료는 비동기로 통지되지만, 그걸 기다리는 과정에서 블로킹이 끼어드는 애매한 상황. ‘비동기’의 장점인 ‘기다리지 않음’을 활용 못 함.
  • 장단점: 비동기 장점 상실. 복잡한데 효율은 별로라 거의 안 씀.

4. 논블로킹 (Non-blocking) - 비동기 (Asynchronous): (Nginx, Node.js 최애 방식)

  • 동작: 웨이터가 주문 넣고 “다 되면 알려주세요 (비동기 알림 요청)”. 그리고 바로 다른 테이블 주문받으러 감 (논블로킹). 나중에 주방에서 “딩동! 요리 완료!” 알림(콜백) 오면, 그때 가서 요리 받아 서빙.
  • 설명: 함수 호출하면 일단 바로 리턴 (논블로킹). 호출자는 작업 완료 신경 끄고 다른 일 함. 작업 완료되면 나중에 OS나 이벤트 루프가 알아서 콜백 함수 호출 등을 통해 알려줌 (비동기).
  • 장단점: 스레드 대기 시간 최소화! 자원 효율 끝판왕. 동시 요청 처리에 최적. 단점은 콜백 지옥 가능성 (Promise, async/await 등으로 극복 시도 중).

이제 논블로킹-비동기 조합이 왜 Nginx의 빠른 성능 비결인지 감이 좀 더 올 것이다!

그래서 뭘 써야 할까? (정답은 없다!)

“와, Nginx 짱인데? 그럼 무조건 Nginx 쓰면 되는 거 아냐?” 라고 생각할 수 있지만, 세상만사 그렇듯 정답은 없다.

  • Nginx가 빛을 발하는 경우:

    • 높은 동시 접속 처리가 필요한 서비스 (대규모 트래픽 예상)
    • 정적 파일 서빙이 많은 경우 (이미지, CSS, JS 등)
    • 리버스 프록시, 로드 밸런서 역할이 중요한 경우
    • 제한된 서버 자원으로 최대한의 성능을 뽑아내야 할 때

  • Apache가 여전히 매력적인 경우:

    • 다양한 서드파티 모듈을 활용해야 하는 복잡한 기능 구현
    • .htaccess 파일을 통한 유연한 설정 변경이 필요한 경우 (웹 호스팅 등)
    • 개발 편의성이나 기존 시스템과의 호환성이 더 중요할 때
    • 동시 접속자 수가 많지 않고 안정성이 더 중요할 때

물론 요즘 대세는 Nginx를 리버스 프록시로 앞단에 두고, 실제 애플리케이션 로직은 Apache나 다른 WAS(Tomcat, Node.js 등)가 처리하는 조합이다. 각자의 장점을 살리는 현명한 방법이다.

대세는 Nginx? (점유율 변화)

예전에는 Apache가 웹 서버 시장을 압도했지만, Netcraft 같은 웹 서버 조사 기관 자료를 보면 최근 몇 년간 Nginx의 점유율이 가파르게 상승하여 Apache를 앞지르거나 팽팽한 경쟁을 벌이고 있다. (2020년 데이터는 조금 오래되었으니 최신 자료를 찾아보는 것도 좋다!) 이는 대규모 트래픽 처리 능력과 효율성이 중요한 현대 웹 환경의 요구와 Nginx의 특징이 잘 맞아떨어졌기 때문으로 보인다.

결론: 상황에 맞는 현명한 선택이 중요!

Nginx는 Event-Driven 비동기 방식으로 동작하여 적은 자원으로 높은 동시 접속 처리 성능을 내는 매력적인 웹 서버다. 특히 리버스 프록시, 로드 밸런서 등으로 활약하며 현대 웹 서비스 아키텍처의 핵심 요소로 자리 잡았다.

하지만 Apache 역시 오랜 역사와 풍부한 기능, 높은 호환성이라는 장점을 가지고 있다. 결국 어떤 기술이든 만능은 없다(No silver bullet!). 내가 만들려는 서비스의 특징, 예상되는 트래픽 규모, 서버 자원, 개발 편의성 등을 종합적으로 고려하여 상황에 맞는 최적의 도구를 선택하는 것이 중요하다 하겠다.

References