Apache httpd와 Nginx 차이점

2026. 7. 3. · ApacheNginxWeb ServerMiddlewareLinuxAI-assisted

Written with AI assistance. 실제 적용 전에는 공식 문서와 운영 환경의 설정을 함께 확인해야 합니다.

Apache httpd와 Nginx는 둘 다 대표적인 Web Server다. 둘 다 정적 파일을 제공할 수 있고, HTTPS를 처리할 수 있고, 뒤쪽 WAS나 애플리케이션 서버로 요청을 넘기는 Reverse Proxy 역할도 할 수 있다.

그런데 운영 문서나 장애 분석 글을 보다 보면 둘을 꽤 다르게 설명한다.

Apache httpd는 모듈이 많고 설정이 유연한 Web Server
Nginx는 이벤트 기반 구조로 동시 연결 처리와 Reverse Proxy에 강한 Web Server

처음에는 이 설명이 조금 추상적으로 느껴진다. 둘 다 80/443 포트를 열고 HTTP 요청을 받는 서버인데, 무엇이 그렇게 다른 걸까?

핵심 차이는 “요청과 연결을 어떻게 처리하도록 설계되었는가”에 있다.

먼저 이름부터 구분하기

여기서 말하는 Apache는 Apache HTTP Server, 흔히 httpd라고 부르는 웹 서버다.

Apache Tomcat과는 다르다.

이름	역할
Apache HTTP Server, httpd	Web Server
Apache Tomcat	Java Servlet Container / WAS
Nginx	Web Server / Reverse Proxy

Apache httpd와 Nginx는 Web Server 계층에 있고, Tomcat은 Java 애플리케이션을 실행하는 WAS에 가깝다.

Client
  -> Apache httpd or Nginx
  -> Tomcat / Node.js / PHP-FPM / other backend
  -> Application
  -> DB

한 줄로 보는 차이

Apache httpd는 오랜 기간 다양한 환경에서 쓰이며 모듈 생태계와 디렉터리 단위 설정에 강점이 있는 웹 서버다.

Nginx는 많은 동시 연결을 적은 리소스로 처리하는 데 초점을 두고 설계되었고, Reverse Proxy와 정적 파일 처리에 강점이 있는 웹 서버다.

둘 중 하나가 항상 더 좋다는 뜻은 아니다. 운영 관점에서는 “어느 쪽이 더 빠른가”보다 현재 시스템에서 어떤 역할로 쓰이고 있는지를 먼저 봐야 한다.

Apache httpd의 특징

Apache httpd는 역사가 긴 만큼 기능과 모듈 생태계가 넓다. mod_ssl, mod_proxy, mod_rewrite, mod_jk, mod_auth 계열처럼 필요한 기능을 모듈로 붙여 쓰는 구조다.

대표적인 설정 단위는 VirtualHost다.

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html

    ProxyPass "/" "http://127.0.0.1:8080/"
    ProxyPassReverse "/" "http://127.0.0.1:8080/"

    ErrorLog logs/example-error.log
    CustomLog logs/example-access.log combined
</VirtualHost>

Apache httpd를 볼 때 자주 확인하는 것은 다음과 같다.

확인 항목	예시
설정 파일	`httpd.conf`, `apache2.conf`, `conf.d/.conf`, `sites-enabled/`
가상 호스트	`VirtualHost`, `ServerName`, `DocumentRoot`
모듈	`mod_ssl`, `mod_proxy`, `mod_rewrite`, `mod_jk`
로그	`access_log`, `error_log`
처리 모델	MPM: `prefork`, `worker`, `event`

Apache httpd를 설명할 때 “요청마다 프로세스나 스레드를 생성한다”고 단순화하는 경우가 많다. 큰 틀에서는 프로세스/스레드 모델로 이해해도 되지만, 실제로는 MPM(Multi-Processing Module)에 따라 동작 방식이 달라진다.

MPM	특징
`prefork`	스레드 없이 여러 프로세스로 요청 처리
`worker`	프로세스와 스레드를 함께 사용
`event`	keep-alive 연결 처리를 개선한 이벤트 기반 MPM

그래서 “Apache는 무조건 느리다”라고 말하면 부정확하다. 다만 많은 동시 연결을 오래 붙잡고 있는 환경에서는 프로세스/스레드 기반 모델이 리소스 부담으로 이어질 수 있고, 이 지점에서 Nginx와 비교가 자주 나온다.

Nginx의 특징

Nginx는 처음부터 많은 동시 연결을 효율적으로 처리하는 방향으로 설계된 웹 서버다. 기본 구조는 master process와 worker process로 설명한다.

nginx master process
  -> worker process
  -> worker process
  -> worker process

master process는 설정을 읽고 worker를 관리한다. worker process는 실제 요청을 처리한다. Nginx의 worker는 하나의 요청에 프로세스나 스레드를 길게 붙이는 방식이 아니라, 이벤트 기반으로 여러 연결을 동시에 처리하는 구조에 가깝다.

대표적인 설정 단위는 server와 location이다.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nginx를 볼 때 자주 확인하는 것은 다음과 같다.

확인 항목	예시
설정 파일	`nginx.conf`, `conf.d/.conf`, `sites-enabled/`
가상 서버	`server`, `server_name`, `listen`
경로 매칭	`location`
backend 그룹	`upstream`
프록시 설정	`proxy_pass`, `proxy_set_header`, timeout
로그	`access.log`, `error.log`

Nginx는 앞단에서 Reverse Proxy, 정적 파일 제공, 로드밸런싱, TLS termination 역할로 많이 사용된다. Tomcat, Node.js, Spring Boot, PHP-FPM 같은 뒤쪽 서버를 직접 외부에 노출하지 않고, Nginx가 앞에서 요청을 받아 내부로 넘기는 구조가 흔하다.

요청 처리 방식의 차이

가장 근본적인 차이는 요청과 연결을 다루는 방식이다.

항목	Apache httpd	Nginx
기본 관점	요청을 처리할 실행 단위를 프로세스/스레드 중심으로 구성	worker가 이벤트 기반으로 많은 연결을 처리
처리 모델	MPM에 따라 `prefork`, `worker`, `event` 사용	master/worker + event-driven 구조
동시 연결	연결 수가 늘면 프로세스/스레드 리소스 영향을 크게 받을 수 있음	많은 idle connection이나 동시 연결 처리에 강점
설정 단위	`VirtualHost`, `Directory`, `Location`, `.htaccess`	`server`, `location`, `upstream`
확장 방식	다양한 모듈 생태계	Reverse Proxy, 정적 파일, upstream 처리에 단순하고 강한 구조
디렉터리별 설정	`.htaccess` 사용 가능	`.htaccess` 없음. 중앙 설정 파일에서 관리

이 차이는 평소에는 잘 안 보이고, 장애가 나면 드러난다.

예를 들어 접속이 느려지거나 502/503이 발생했을 때 Apache httpd라면 MPM 설정, worker 수, keep-alive, 모듈 로그, backend 연결 상태를 같이 본다.

Nginx라면 worker connection, upstream 상태, proxy_pass 대상, timeout, error log의 upstream 메시지를 먼저 보게 된다.

설정 구조의 차이

Apache httpd는 디렉터리 단위 설정이 강하다. 특히 .htaccess를 사용하면 특정 디렉터리 아래에서 rewrite, 인증, 접근 제어 같은 설정을 애플리케이션 배포 단위에 가깝게 둘 수 있다.

이 방식은 공유 호스팅이나 레거시 PHP 애플리케이션 환경에서 유용했다. 애플리케이션별로 설정을 분리하기 쉽고, 서버 전체 설정을 수정하지 않아도 일부 동작을 바꿀 수 있기 때문이다.

대신 요청마다 디렉터리 설정을 확인해야 하므로 성능이나 관리 측면에서는 부담이 될 수 있다. 운영 환경에서는 .htaccess 사용 여부와 AllowOverride 설정을 확인해야 한다.

Nginx는 .htaccess 같은 디렉터리별 런타임 설정 파일을 사용하지 않는다. 보통 nginx.conf나 conf.d/*.conf 같은 중앙 설정 파일에 server, location, upstream을 명시한다.

이 방식은 설정 위치가 명확하다. 대신 애플리케이션 담당자가 디렉터리 안에 파일 하나 넣어서 웹 서버 동작을 바꾸는 방식은 통하지 않는다. 설정 변경 후에는 nginx -t로 문법을 확인하고 reload하는 흐름이 일반적이다.

Reverse Proxy 관점의 차이

둘 다 Reverse Proxy가 가능하다.

Apache httpd에서는 mod_proxy, mod_proxy_http, mod_proxy_ajp, mod_jk 같은 모듈을 통해 backend로 요청을 넘긴다.

ProxyPass "/" "http://127.0.0.1:8080/"
ProxyPassReverse "/" "http://127.0.0.1:8080/"

Nginx에서는 proxy_pass와 upstream을 사용한다.

upstream app_backend {
    server 127.0.0.1:8080;
}

server {
    listen 80;

    location / {
        proxy_pass http://app_backend;
    }
}

둘 다 외부 요청을 내부 WAS로 전달할 수 있지만, Nginx는 Reverse Proxy와 upstream 문법이 단순해서 자주 쓰인다. 그래서 현대적인 구성에서는 Nginx를 앞단에 두고 뒤쪽에 Tomcat, Spring Boot, Node.js, PHP-FPM 등을 두는 구성이 흔하다.

Apache httpd는 기존 Apache 기반 서비스, .htaccess, 특정 모듈, AJP 연동, 레거시 설정과의 호환성이 필요한 환경에서 계속 많이 쓰인다.

정적 파일 처리 관점

정적 파일은 실행 로직 없이 그대로 내려주는 파일이다.

/index.html
/static/app.css
/images/logo.png
/assets/main.js

Nginx는 정적 파일 제공과 많은 동시 연결 처리에 강점이 있어 이미지, CSS, JavaScript, 다운로드 파일을 앞단에서 처리하는 데 자주 쓰인다.

Apache httpd도 정적 파일을 제공할 수 있고 실제로 많이 사용된다. 다만 “정적 파일 + Reverse Proxy + 높은 동시 연결” 조합에서는 Nginx를 선호하는 경우가 많다.

중요한 것은 이름보다 역할 분리다.

Client
  -> Web Server: 정적 파일, TLS, routing
  -> WAS: 동적 애플리케이션 로직
  -> DB: 데이터 조회/저장

정적 파일 요청까지 모두 WAS로 보내면 WAS는 애플리케이션 로직 외의 일까지 떠안게 된다. 그래서 Web Server 앞단에서 처리할 수 있는 것은 앞단에서 처리하고, 동적 요청만 WAS로 넘기는 구성이 운영상 유리하다.

같은 질문, 다른 문법

명령어만 따로 외우면 금방 헷갈린다. 운영에서 마주치는 질문은 두 서버가 같고, 문법만 다르다. 그래서 질문 기준으로 보는 편이 낫다.

질문	Apache httpd	Nginx
설정 문법은 정상인가?	`httpd -t`, `apachectl configtest`	`nginx -t`
어떤 도메인을 받는가?	`VirtualHost`, `ServerName`	`server`, `server_name`
어떤 경로를 어디로 보내는가?	`ProxyPass`, `RewriteRule`, `Location`	`location`, `proxy_pass`
backend는 어디인가?	`ProxyPass` 대상, `workers.properties`	`upstream`, `proxy_pass`
요청이 도착했는가?	`access_log`	`access.log`
왜 실패했는가?	`error_log`, module log	`error.log`, upstream error
실제 클라이언트 IP는 남는가?	`LogFormat`, XFF header	`real_ip_header`, XFF header
reload 전에 검증했는가?	`httpd -t` 후 reload	`nginx -t` 후 reload

장애 대응에서는 “Apache냐 Nginx냐”보다 다음 순서가 중요하다.

Web Server까지 요청이 도착했는가?
Web Server가 어떤 설정으로 요청을 매칭했는가?
backend WAS로 요청을 넘겼는가?
backend가 정상 응답했는가?
에러 페이지는 Web Server, WAS, LB 중 누가 만든 것인가?

그래서 무엇을 선택해야 하나

새 시스템을 설계한다면 Nginx를 앞단 Reverse Proxy로 두는 구성이 많이 쓰인다. 설정이 단순하고, 정적 파일 처리와 동시 연결 처리, upstream 전달에 강점이 있기 때문이다.

반대로 기존 서비스가 Apache httpd 모듈이나 .htaccess, AJP 연동, 레거시 PHP 환경에 의존하고 있다면 Apache httpd를 유지하거나 Apache 기반으로 구성하는 것이 더 현실적일 수 있다.

선택 기준은 단순히 “어느 쪽이 더 빠른가”가 아니다.

기준	Apache httpd가 자연스러운 경우	Nginx가 자연스러운 경우
기존 환경	Apache 모듈, `.htaccess`, 레거시 설정 의존	새로 구성하는 Reverse Proxy 앞단
동시 연결	연결 수가 크지 않고 기존 설정 호환이 중요	많은 동시 연결과 정적 파일 처리가 중요
설정 방식	디렉터리별 설정, 다양한 모듈 활용	중앙 설정 파일로 명확하게 관리
WAS 연동	`mod_proxy`, `mod_jk`, AJP 연동	`proxy_pass`, `upstream` 기반 HTTP proxy

정리

Apache httpd와 Nginx는 둘 다 Web Server지만 설계 방향이 다르다.

Apache httpd는 모듈 생태계, VirtualHost, .htaccess, 레거시 호환성에 강점이 있다. 요청 처리 방식은 MPM에 따라 달라지며, 운영에서는 MPM 설정, 모듈, 로그, backend 연동을 함께 봐야 한다.

Nginx는 master/worker와 이벤트 기반 구조를 바탕으로 많은 동시 연결을 효율적으로 처리하는 데 강점이 있다. 운영에서는 server, location, upstream, proxy_pass, timeout, access/error log를 중심으로 본다.

결국 봐야 할 건 서버 이름이 아니라 요청 흐름이다.

Client
  -> Apache httpd or Nginx
  -> WAS
  -> Application
  -> DB

요청이 어디까지 왔고, 어느 설정에 걸렸고, 어디로 넘어갔는지. 이 세 가지를 추적할 수 있으면 Apache냐 Nginx냐는 문법 차이일 뿐이다.

참고 자료

Middleware 가이드 (docs) — 전체 요청 흐름(WEB–WAS–DB) 관점의 학습 경로
Web Server 역할 (docs) — 이 글의 상위 개념 정리
Apache HTTP Server MPM
Apache HTTP Server VirtualHost
Apache HTTP Server .htaccess
Apache Module mod_proxy
NGINX Beginner’s Guide
NGINX ngx_http_proxy_module
NGINX ngx_http_upstream_module