Apache·IIS·NGINX 비교: 웹 서버를 고르는 실무 기준

Apache HTTP Server, Microsoft IIS, NGINX 중 하나가 언제나 가장 빠르거나 안전한 것은 아니다. 정적 파일 제공, reverse proxy, 애플리케이션 hosting, 운영체제 통합 중 어떤 책임을 맡길지와 팀이 익숙한 운영 방식을 먼저 정해야 한다.

빠르게 고르면 다음과 같다.

우선 조건	먼저 검토할 선택지
.htaccess, 풍부한 module, 기존 Apache 운영 자산	Apache HTTP Server
Windows Server, Active Directory, IIS application pool, ASP.NET Core 통합	IIS
event-driven reverse proxy, 정적 파일, upstream routing	NGINX

이 표는 출발점일 뿐이다. 실제 성능은 TLS, HTTP version, dynamic upstream, cache, compression, worker 설정, logging, payload와 동시 연결 패턴에 따라 달라진다.

세 제품의 처리 모델

Apache HTTP Server

Apache httpd는 module 구조와 Multi-Processing Module(MPM)로 동작 방식을 선택한다. Unix 계열에서는 event, worker, prefork를 사용할 수 있고 현대적인 환경에서는 대체로 event MPM이 기본이다.

그래서 “Apache는 요청마다 무조건 process 하나를 만들어 느리다”는 비교는 정확하지 않다. prefork인지 threaded·event MPM인지, PHP 같은 runtime을 어디서 실행하는지에 따라 자원 사용과 동시성 특성이 달라진다.

Apache가 어울리는 경우는 다음과 같다.

• 오래 운영한 module·rewrite·virtual host 설정을 이어 가야 한다.
• 디렉터리별 설정 같은 Apache 고유 운영 모델이 필요하다.
• 조직에 httpd 관찰·패치·장애 대응 경험이 충분하다.

NGINX

NGINX는 master process가 설정과 worker를 관리하고, worker process가 event 기반으로 connection을 처리한다. 정적 파일 제공과 reverse proxy가 대표적인 용도다.

다만 “event 기반이므로 모든 workload에서 가장 빠르다”는 결론은 낼 수 없다. upstream 애플리케이션이 병목이거나 TLS·compression·disk·network 설정이 다르면 결과가 바뀐다. module을 추가하는 방식과 동적 module 호환성도 Apache와 다르므로 필요한 기능을 먼저 확인해야 한다.

IIS

IIS는 Windows의 HTTP.sys, Windows Process Activation Service(WAS), worker process와 application pool을 중심으로 요청을 처리한다. application pool은 애플리케이션을 process boundary로 분리하고 identity, recycling, resource 설정을 관리하는 운영 단위다.

ASP.NET Core는 IIS 안에서 in-process로 실행하거나 ASP.NET Core Module을 통해 별도 process로 전달하는 hosting model을 선택할 수 있다. .NET이 cross-platform이라는 사실과 IIS가 Windows의 server role이라는 사실은 구분해야 한다.

IIS가 어울리는 경우는 다음과 같다.

• Windows Server와 기존 인증·권한·관리 도구에 깊게 통합해야 한다.
• application pool 격리와 GUI·PowerShell 기반 운영 자산을 활용한다.
• ASP.NET 계열 서비스의 배포·진단 절차가 이미 표준화되어 있다.

성능은 제품명이 아니라 요청 경로를 측정한다

웹 서버 benchmark에서 자주 생기는 오류는 한 제품은 정적 파일만 제공하고 다른 제품은 dynamic runtime까지 포함해 비교하는 것이다. 최소한 다음 조건을 맞춰야 한다.

• 같은 hardware·OS 자원과 network path
• 같은 TLS version·cipher와 keep-alive 조건
• 같은 response size와 cache hit 조건
• 같은 logging·compression 설정
• warm-up 뒤 latency percentile, throughput, error rate, CPU, memory 함께 관찰
• 정상 부하뿐 아니라 upstream 지연과 connection 급증 상황 포함

평균 응답 시간 하나보다 p95·p99 latency와 오류율을 함께 봐야 한다. 운영 선택이라면 재시작·reload 때 connection이 어떻게 처리되는지, 설정 rollback과 log correlation이 쉬운지도 성능만큼 중요하다.

보안은 오픈소스 여부로 결정되지 않는다

“오픈소스는 community가 빨리 고치고 IIS는 Microsoft가 고치므로 어느 쪽이 더 안전하다”는 식의 비교는 실무 판단에 도움이 되지 않는다. 세 제품 모두 다음 운영이 빠지면 취약해질 수 있다.

• 지원되는 version을 사용하고 security advisory와 patch 주기를 관리한다.
• 쓰지 않는 module·handler·sample site를 끈다.
• worker identity와 filesystem 권한을 최소화한다.
• TLS policy, request/body limit, timeout을 서비스 특성에 맞춘다.
• access·error log를 중앙 수집하고 민감 정보가 기록되지 않게 한다.
• 관리 endpoint를 외부에 노출하지 않고 configuration을 review한다.

Web Application Firewall이나 CDN을 앞에 둬도 원본 서버 patch와 접근 제어 책임은 사라지지 않는다.

Reverse proxy와 application server를 구분한다

NGINX나 Apache가 앞단에서 TLS termination과 routing을 담당하고, 뒤에서 Java·Node.js·Python application server가 business logic을 실행하는 구성이 흔하다. IIS도 ASP.NET Core hosting과 reverse proxy 역할을 함께 맡을 수 있다.

이때 장애를 분석하려면 계층을 나눠 본다.

Client
  → CDN / Load Balancer
  → Apache·IIS·NGINX
  → Application runtime
  → Database·외부 API

502·504가 보인다고 웹 서버 자체가 원인이라고 단정하면 안 된다. upstream connection, timeout, DNS, application saturation을 함께 확인해야 한다.

선택 체크리스트

1. 이 서버가 정적 파일, reverse proxy, dynamic hosting 중 무엇을 맡는가?
2. Windows 통합이나 Apache module처럼 대체하기 어려운 요구가 있는가?
3. 팀이 patch, configuration review, logging, reload를 안정적으로 운영할 수 있는가?
4. 필요한 HTTP·TLS·module 기능이 지원되는가?
5. 실제 workload와 실패 조건으로 benchmark했는가?

새 프로젝트라면 익숙한 제품명만으로 결정하기보다 작은 동일 workload를 세 후보에 올려 운영 복잡도까지 비교하는 편이 낫다. 기존 서비스라면 이론적인 성능 차이보다 migration 위험과 관찰 가능성이 더 큰 비용일 수 있다.

공식 문서와 관련 글

• Apache HTTP Server MPM
• NGINX Beginner's Guide
• Microsoft IIS application pools
• Host ASP.NET Core on Windows with IIS
• 네트워크 진단 명령어를 흐름으로 쓰는 법