HTTP는 클라이언트(브라우저, 앱)와 서버 간의 요청-응답 프로토콜이다. 그 중심에는 웹 서버(Web Server)가 있다. 웹 서버는 단순히 정적 파일을 내려주는 역할을 넘어서 동적 애플리케이션 실행, 보안 관리, 캐싱, 로드 밸런싱 등 웹 서비스의 핵심 엔진으로 동작한다. 이번에 「HTTP 완벽 가이드」에서 정리한 웹 서버 부분을 학습하며 서버의 구조와 동작 원리를 체계적으로 이해할 수 있었다.
웹 서버의 주요 역할
1. HTTP 요청 처리
웹 서버는 먼저 클라이언트로부터 TCP 연결을 받아들인 뒤 들어온 HTTP 요청 메시지를 읽어 파싱한다. 요청 라인(메서드, 경로, 프로토콜 버전)과 헤더, 그리고 바디를 분석해 어떤 자원을 요구하는지 해석한다. 이 과정에서 요청이 올바르지 않은 경우에는 400 Bad Request와 같은 오류 응답을 반환하기도 한다.
2. 자원 매핑(Resource Mapping)
파싱된 요청은 실제 서버의 자원과 연결된다. 정적 자원의 경우 요청된 URL을 서버 파일 시스템 경로로 매핑해 /images/logo.png 같은 경로를 /www/images/logo.png와 연결한다. 반대로 동적 요청이라면 PHP, JSP, Servlet, Spring 같은 애플리케이션 모듈로 전달해 필요한 로직을 실행하고 결과를 생성한다.
3. 응답 생성
요청된 자원이 존재한다면 서버는 200 OK 같은 HTTP 상태 코드와 함께 응답 본문을 클라이언트에 전달한다. 자원이 없을 경우 404 Not Found, 권한이 없으면 403 Forbidden처럼 상황에 맞는 오류 응답을 생성한다. 또한 콘텐츠 협상(예: Accept-Language 헤더에 따라 한국어 페이지 제공)을 통해 클라이언트 환경에 맞는 응답을 내려주기도 한다.
4. 접속 관리
웹 서버는 단순히 요청과 응답만 처리하는 것이 아니라 연결을 어떻게 유지할지도 관리한다. Connection: keep-alive 옵션을 활용하면 여러 요청을 하나의 TCP 커넥션에서 처리할 수 있어 효율적이다. 동시에 들어오는 다수의 요청을 처리하기 위해 서버는 스레드 풀, 멀티 프로세스 모델, 이벤트 루프와 같은 다양한 동시성 기법을 사용한다. 최근에는 HTTP/2 멀티플렉싱처럼 한 연결에서 여러 요청과 응답을 동시에 처리할 수 있는 기술도 널리 활용되고 있다.
웹 서버의 종류
단일 스레드 서버
단일 스레드 서버는 하나의 요청을 처리하는 동안 다른 요청을 받을 수 없는 구조다. 요청이 들어오면 해당 스레드가 응답을 완료할 때까지 다음 요청은 대기해야 한다. 구현이 단순하고 리소스 소모가 적다는 장점이 있지만 동시에 여러 요청이 들어오는 상황에서는 처리 지연이 발생한다. 따라서 학습용이나 소규모 테스트 환경에는 적합하지만 실제 대규모 트래픽이 발생하는 운영 환경에서는 거의 사용되지 않는다.
멀티프로세스/멀티스레드 서버
멀티프로세스 서버는 요청마다 새로운 프로세스를 생성해 처리하고 멀티스레드 서버는 하나의 프로세스 안에서 스레드를 여러 개 두어 동시에 요청을 처리한다. 이 방식은 병렬 처리가 가능해 단일 스레드의 한계를 극복할 수 있고 각 요청이 독립적으로 실행되므로 안정성이 높다. 하지만 프로세스/스레드를 무작정 늘리면 컨텍스트 스위칭 비용이 커지고 메모리 사용량도 증가한다. 따라서 보통 스레드 풀같은 자원 관리 기법을 함께 사용해 효율성을 확보한다. Apache HTTP Server는 전통적으로 멀티프로세스/멀티스레드 모델을 채택해왔다.
이벤트 기반 서버 (비동기 I/O)
이벤트 기반 서버는 하나의 프로세스와 소수의 스레드로도 수많은 요청을 동시에 처리할 수 있도록 설계되었다. 이벤트 루프를 중심으로 동작하며 요청이 들어오면 이벤트 큐에 등록하고 비동기 I/O를 통해 작업이 완료되면 콜백을 실행하는 방식이다. 이 모델은 요청마다 새로운 스레드를 만들지 않기 때문에 자원 소모가 적고 대규모 동시 접속을 처리하는 데 매우 유리하다. 다만 이벤트 루프 설계와 비동기 프로그래밍 모델이 복잡하다는 단점이 있다. 대표적인 예시가 Nginx와 Node.js 기반 서버다.
추가 기능
웹 서버는 요청을 받아 응답을 내려주는 기본 기능 외에도 실제 운영 환경에서 필요한 다양한 부가 기능을 제공한다.
첫 번째로 접근 제어 기능이 있다. 특정 IP 주소를 차단하거나 인증·인가 과정을 거쳐야만 자원에 접근할 수 있도록 설정할 수 있다. 이를 통해 보안을 강화하고 관리자가 허용한 사용자만 서버 자원에 접근하도록 제어할 수 있다.
두 번째는 캐싱이다. 자주 요청되는 정적 리소스(이미지, CSS, JS 등)를 메모리나 디스크에 캐싱해 두면 같은 요청이 다시 들어왔을 때 디스크 I/O나 애플리케이션 호출 없이 바로 응답할 수 있다. 이로써 서버 부하가 줄고 응답 속도가 크게 향상된다.
세 번째는 로깅이다. 웹 서버는 모든 요청과 응답, 발생한 오류를 로그 파일에 기록한다. 이 기록은 문제 발생 시 원인을 추적하거나 트래픽 패턴을 분석하는 데 매우 중요한 데이터가 된다. 실제 운영에서는 로그를 수집해 ELK(Elasticsearch, Logstash, Kibana)나 Grafana 같은 모니터링 시스템과 연계해 분석하기도 한다.
마지막으로 웹 서버는 프록시 및 게이트웨이 역할도 수행할 수 있다. 리버스 프록시로 동작하면서 여러 애플리케이션 서버로 요청을 분산하는 로드밸런서 역할을 하거나 캐싱 프록시로 동작해 원 서버의 부담을 줄여줄 수도 있다. 이러한 기능은 단순한 요청-응답을 넘어서 서비스 전체의 확장성과 안정성을 뒷받침한다.
예시: 단순 HTTP 응답
HTTP/1.1 200 OK
Date: Tue, 02 Sep 2025 12:00:00 GMT
Server: Apache/2.4.54 (Unix)
Content-Type: text/html
Content-Length: 137
<html>
<head><title>Hello</title></head>
<body>
<h1>Hello, World!</h1>
</body>
</html>배운점
웹 서버는 단순한 파일 제공자가 아니라 네트워크, 운영체제, 보안, 애플리케이션을 연결하는 핵심 허브라는 사실을 다시 느꼈다. 특히 이벤트 기반 모델과 멀티스레드 모델의 차이를 이해하니 왜 대규모 서비스에서 Nginx 같은 서버가 널리 쓰이는지 알 수 있었다.
또한 로깅·캐싱 같은 보조 기능들이 실제 운영에서 얼마나 중요한지 체감할 수 있었고, 내가 사용하는 Spring Boot 내장 톰캣도 결국 같은 원리를 가진 HTTP 서버라는 점이 흥미로웠다.
