참고

https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/
https://www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/
https://www.nginx.com/resources/glossary/application-server-vs-web-server/

1 웹서버가 필요한 이유

1.1 웹서버의 정의

웹서버(Web Server)란 클라이언트로부터의 요청에 대해 정적인 콘텐츠(예: HTML, 이미지, CSS, JS 파일 등)를 직접 제공하는 서버다. 반면, 사용자 입력이나 실시간 계산 결과에 따라 응답이 달라지는 콘텐츠, 즉 동적인 콘텐츠는 애플리케이션 서버(Application Server)가 처리한다.

단순히 정적 파일을 서빙하는 것을 넘어서 최근의 웹서버는 프록시, 로드밸런싱, 보안 처리(SSL Termination), 심지어는 서비스 디스커버리 같은 복합적 역할을 수행하고 있다.

1.2 웹서버가 필요한 이유

1.2.1 웹서버를 도입해야 하는 이유

예를 들어, Java Spring 기반의 API 서버를 직접 만들어서 운영한다고 하자.
클라이언트의 요청(GET /index.html, GET /image/1.jpg)에 대해 항상 애플리케이션 서버가 응답해야 한다면, 불필요한 계산 로직을 거치며 처리 시간이 늘어나게 된다. 그러나 /index.html이나 /logo.png처럼 변하지 않는 정적 리소스에 대해서는 매번 로직을 거칠 이유가 없다.

이러한 고민 끝에 나온 접근 방식이 바로 웹서버를 애플리케이션 서버 앞에 두는 구조다. 웹서버는 정적 콘텐츠를 빠르게 응답하고, 동적 요청에 대해서만 애플리케이션 서버에 요청을 전달(Proxy)하는 방식이다.

이 구조의 장점은 다음과 같다:

• 응답 속도 향상: 정적 파일은 웹서버에서 즉시 응답 가능
• 애플리케이션 서버 부하 감소: 불필요한 요청을 차단
• 네트워크 효율화: 캐싱 및 SSL 오프로딩 등 공통 작업 선처리

또한, 웹서버는 Reverse Proxy 역할도 수행한다. 클라이언트는 직접 애플리케이션 서버와 통신하지 않고, 웹서버를 통해 요청/응답을 주고받는다. 이는 보안 및 확장성 측면에서도 유리하다.

1.2.2 웹서버가 필요 없는 경우

하지만 모든 상황에서 웹서버가 필수적인 것은 아니다. 다음과 같은 경우 웹서버 없이도 효율적인 운영이 가능하다:

• 정적 콘텐츠가 CDN으로 처리되는 경우: 예를 들어 AWS CloudFront 등
• 모든 요청이 동적이고, API 위주인 경우
• 소규모 트래픽의 서비스: 예를 들어 하루 방문자가 10명 수준이라면 오히려 불필요한 자원 소모, 지연, 운영 복잡성을 초래할 수 있다.

1.2.3 요즘 웹서버

현대의 웹서버는 단순 정적 콘텐츠 제공을 넘어 다음과 같은 역할까지 포괄하고 있다:

• API Gateway 역할
• 분산환경 지원 (Service Mesh의 일부로 사용)
• 로드 밸런서
• 클라우드 네이티브 아키텍처 통합

이러한 흐름 속에서 웹서버와 API Gateway 간의 경계가 점점 희미해지고 있는 추세다

1.3 웹서버의 종류들

1.3.1 Apache (HTTP server)

Apache (HTTP server) 는 오픈소스 웹서버의 원조로 불린다. 호환하는 OS의 종류가 가장 많다. 초기에는 요청에 대해서 synchronous 하게 처리하는 아키텍처였다. NGINX 도 Apache 를 대항하고자 만들기 시작했다. NGINX 와의 성능차이가 많이 나면서부터 인기가 시들었지만, 아직도 사용하는 곳이 많다.

1.3.2 NGINX

오픈소스로 된 Web Server 중 가장 대중적인 제품. Apache 를 대항하기 위해 나왔고, C10K 문제를 해결한 최초의 웹서버 중 하나이다. 비동기로 요청을 처리하는 아키텍처 덕분이다. NGINX 이후로 대부분의 웹서버들이 비동기로 처리를 지원하기 시작했다. 비동기 이벤트 기반 아키텍처와 멀티 프로세스를 활용해 동시에 다수의 요청을 처리한다. C로 구현되어있다.

C10K 문제 : 동시 접속 10,000건 처리 문제

1.3.3 Caddy

Golang으로 만들어진 Web Server 이다. 운영체제에 따른 native library에 대한 dependency 없이 동작한다는 것을 장점으로 내세운다. 이 외에도 NGINX의 단점을 극복하기 위한 설계와 여러 기능이 있다.
1. easy configuration
2. modular architecture

1.3.4 Envoy

Micro Service Architecture(MSA)를 지원하기 위해 설계된 고성능 분산 프록시 제품이다. NGINX보다 추상화 수준이 높으며, Service Discovery, Circuit Breaker 등 MSA 구성을 위한 기능을 기본적으로 내장하고 있다. C++로 구현되어있다.

1.3.5 그밖에

참고: 최근에는 Kong, Traefik, HAProxy 등도 프록시/게이트웨이 솔루션으로 각광받고 있다.
위에 언급한 것 외에도 성능이 좋고 기능이 풍부한 다른 웹서버들이 많다. 뿐만 아니라 위에 언급한 것처럼 웹서버와 API Gateway의 구분이 없어지면서 사실상 proxy, router 성격을 가진 제품들이 모두 비교 대상이 된다.

1.4 왜 NGINX를 배우나?

NGINX는 웹서버이자 프록시, 로드밸런서, API 게이트웨이 등 다양한 역할을 수행할 수 있어 학습할 가치가 충분하다.

1. 성능이 좋다.
2. 레퍼런스가 많다.
3. 오픈소스 버전을 무료로 사용할 수 있다.
4. NGINX를 사용하는 기업이 많으며, 약 30%의 웹서비스가 NGINX 기반으로 구축되어 있다.
5. 전통적인 웹서버의 아키텍처, 설정의 방식을 가지고 있어서 이해가 쉽다.
6. Kubernetes(K8S)의 공식 ingress/egress controller이다.

초기부터 레거시 없이 구축하고, 간단한 설정과 필요한 기능만 사용하는 구조를 원한다면 Caddy나 Envoy 등 새로운 웹서버 제품도 좋은 선택이 될 수 있다.