웹 서버란 무엇인가?

웹 페이지를 불러올 때마다, 무언가가 응답해야 한다. 브라우저는 인터넷을 통해 요청을 보낸다—사실상 하나의 질문이다—그리고 어딘가에서 소프트웨어가 그 질문을 받아 당신이 무엇을 원하는지 파악하고 답을 돌려보낸다. 그 소프트웨어가 바로 웹 서버다.

당신이 지금까지 방문한 모든 웹사이트—모든 검색, 모든 구매, 모든 동영상—은 정확히 이 역할을 하는 소프트웨어를 통해 전달되었다: 당신의 요청을 기다리다가 응답하는 것.

"웹 서버"는 물리적인 기계를 가리킬 때도 있지만, 기술적인 맥락에서는 소프트웨어 자체를 의미한다: HTTP 요청을 수신하고 HTTP 응답을 보내는 프로그램.

요청-응답 주기

웹 서버는 본질적으로 다음 여섯 가지 동작을 끊임없이 반복한다:

수신. 서버는 네트워크 포트를 감시한다—일반적으로 HTTP는 포트 80, HTTPS는 포트 443—누군가가 연결할 때를 기다리며.

수락. 브라우저가 연결을 시작하면, 서버는 이를 수락하여 양방향 채널을 구성한다.

파싱. 서버는 HTTP 요청을 읽는다: 어떤 URL을 요청하는가? 어떤 메서드(GET, POST)인가? 어떤 헤더가 포함되어 있는가?

처리. 여기서 실제 작업이 이루어진다. 정적 파일이라면 서버가 디스크에서 파일을 찾는다. 동적 요청이라면 코드를 실행하거나, 데이터베이스를 조회하거나, 다른 서비스를 호출할 수 있다.

응답. 서버는 HTTP 응답을 보낸다—상태 코드, 헤더, 그리고 실제 콘텐츠(HTML, JSON, 이미지 등 요청한 것).

기록. 서버는 발생한 일을 기록하여, 관리자가 상황을 파악할 수 있는 접근 로그와 오류 로그를 생성한다.

이것이 전부다. 이 단순한 주기가 수백만 개의 서버에서 하루에 수십억 번 반복되며 웹을 움직이는 메커니즘이다.

정적 vs. 동적 콘텐츠

웹 서버는 근본적으로 다른 두 가지 작업을 처리한다.

정적 콘텐츠는 파일 제공이다. 이미지, CSS 파일, 또는 HTML 문서를 요청하면 서버는 디스크에서 파일을 읽어 변경 없이 그대로 전송한다. 항상 같은 파일, 같은 내용이다. 이는 빠르다—서버는 본질적으로 정교한 파일 전송 프로그램이다. 정적 콘텐츠는 적극적으로 캐싱할 수 있고, 한 번 압축해서 재사용할 수 있으며, 전 세계 CDN에 배포할 수 있다.

동적 콘텐츠는 각 요청마다 새로 생성된다. 이메일을 확인하거나 소셜 미디어 피드를 볼 때, 서버는 파일을 가져오는 것이 아니라—당신의 데이터와 애플리케이션의 현재 상태를 기반으로 지금 이 순간 당신만을 위한 응답을 만들어내는 것이다.

동적 콘텐츠의 경우, 웹 서버는 애플리케이션 코드와 연동한다. 웹 서버가 요청을 받아 애플리케이션(PHP, Python, JavaScript 등으로 작성된)에 전달하고, 애플리케이션이 HTML을 생성할 때까지 기다린 다음, 생성된 응답을 클라이언트에게 돌려보낸다.

주요 웹 서버

Apache HTTP Server는 초기 웹을 이끌었다. 1995년에 출시되어 지금도 널리 사용되고 있다. Apache의 아키텍처는 각 연결에 별도의 프로세스나 스레드를 할당한다—간단하지만 높은 부하에서는 리소스를 많이 소비한다. 강점은 유연성이다: 모듈을 통해 거의 모든 기능을 추가할 수 있고, 수십 년간 축적된 문서가 거의 모든 상황을 다룬다.

Nginx("엔진엑스")는 Apache가 많은 동시 연결을 처리하는 데 어려움을 겪었기 때문에 2004년에 특별히 설계되었다. Nginx는 이벤트 기반 아키텍처를 사용하여 소수의 워커 프로세스가 수천 개의 연결을 동시에 처리할 수 있다. 마치 세 명의 웨이터가 쉬지 않고 움직이며 만 개의 테이블을 효율적으로 서빙하는 레스토랑 같다. Nginx는 고트래픽 환경에서 지배적이며, 정적 파일 제공, SSL 처리, 로드 밸런싱을 담당하기 위해 애플리케이션 서버 앞에 배치되는 경우가 많다.

Microsoft IIS는 Windows용 웹 서버로, Windows 생태계와 긴밀하게 통합되어 있다. .NET 애플리케이션을 운영한다면 IIS가 자연스러운 선택이다.

Caddy는 현대적인 웹 서버로, 별도의 설정 없이 SSL 인증서를 자동으로 발급하고 갱신한다. 단순함 덕분에 빠른 배포에 적합해 인기를 얻고 있다.

필수 설정

가상 호스트는 하나의 서버로 여러 웹사이트를 호스팅할 수 있게 한다. 서버는 각 요청의 Host 헤더를 읽어 어떤 사이트를 원하는지 판단한다—이것이 공유 호스팅의 원리이며, 하나의 서버에서 여러 도메인을 운영하는 방법이다.

SSL/TLS는 HTTPS를 가능하게 한다. 서버에는 인증서, 적절한 암호화 설정, 그리고 최신 프로토콜 버전이 필요하다. 잘못 설정하면 사용자가 위험에 노출된다.

접근 제어는 누가 무엇에 접근할 수 있는지를 결정한다. IP 제한, 비밀번호 보호, 인증 연동.

로깅은 모든 요청과 모든 오류를 기록한다. 로그 없이는 눈을 감고 운전하는 것과 같다.

성능 튜닝—타임아웃, keep-alive 설정, 버퍼 크기, 압축—은 서버가 얼마나 많은 사용자를 처리할 수 있고 얼마나 빠르게 응답할 수 있는지를 결정한다.

보안

웹 서버는 인터넷에 직접 노출되어 있다. 누구의 입력도 받아들인다. 그래서 보안은 선택이 아니다.

소프트웨어를 최신 상태로 유지하라. 취약점은 정기적으로 발견된다. 오래된 소프트웨어를 실행한다는 것은 이미 알려진 취약점을 가진 소프트웨어를 실행하는 것이다.

파일 접근을 제한하라. 웹 서버는 제공해야 하는 파일만 읽어야 한다. 잘못된 설정으로 수많은 민감한 파일이 공개 인터넷에 노출되었다.

최신 SSL/TLS를 사용하라. 오래된 설정은 HTTPS를 사용하고 있다고 생각하더라도 공격자가 트래픽을 가로챌 수 있게 한다.

요청 속도를 제한하라. 단일 클라이언트가 보낼 수 있는 요청 수를 제한하여 남용을 방지하라. 이는 서비스 거부 공격과 무차별 대입 공격으로부터 보호한다.

버전 정보를 숨겨라. 공격자에게 정확히 어떤 소프트웨어 버전을 사용하고 있는지 알려주지 마라.

웹 서버 vs. 애플리케이션 서버

현대 시스템은 종종 두 역할을 모두 결합하기 때문에 이 용어들이 혼란을 일으킨다.

웹 서버는 HTTP를 처리한다. 네트워크 연결, 파일 제공, SSL 종료, HTTP 프로토콜 이해에 탁월하다.

애플리케이션 서버는 코드를 실행한다. 데이터베이스에 연결하고, 비즈니스 로직을 처리하고, 동적 응답을 생성한다.

많은 배포 환경에서 두 가지를 함께 사용한다: Nginx가 들어오는 요청을 처리하고, 정적 파일을 제공하며, 동적 요청을 뒤에서 실행 중인 애플리케이션 서버(Node.js, Django, Rails)로 전달한다. 각 구성 요소가 자신이 잘하는 일을 한다.

하지만 경계는 흐려진다. Express를 사용하는 Node.js는 단일 프로세스에서 두 역할을 모두 수행한다. 이 구분은 아키텍처적이라기보다 개념적이다—반드시 별개의 프로그램이어야 하는 것이 아니라 소프트웨어가 어떤 역할을 하는지에 관한 것이다.

성능

연결 처리 방식은 크게 다르다. 연결당 프로세스(Apache의 전통적인 모델)는 높은 부하에서 확장성을 제약하는 오버헤드가 생긴다. 이벤트 기반(Nginx)은 최소한의 리소스로 많은 연결을 처리한다.

정적 파일 최적화는 압축(gzip, Brotli), 브라우저가 파일을 로컬에 저장할 수 있게 하는 캐시 헤더, 그리고 매 요청마다 디스크를 읽는 대신 메모리에서 제공하는 것을 의미한다.

Keep-alive 연결은 여러 요청이 하나의 TCP 연결을 공유할 수 있게 하여, 반복적인 핸드셰이크 오버헤드를 없앤다. keep-alive 타임아웃은 균형이 중요하다: 너무 길면 리소스를 낭비하고, 너무 짧으면 이점을 잃는다.

로드 밸런싱은 여러 웹 서버 인스턴스에 요청을 분산한다. 이는 처리 용량을 늘리고 이중화를 제공한다—하나의 서버가 장애를 일으켜도 다른 서버들이 계속 서비스를 제공한다.

웹 서버에 관한 자주 묻는 질문

웹 서버와 웹사이트의 차이는 무엇인가?

웹사이트는 콘텐츠다—당신이 상호작용하는 페이지, 이미지, 기능. 웹 서버는 그 콘텐츠를 브라우저에 전달하는 소프트웨어다. 웹사이트는 당신이 보는 것이고, 웹 서버는 그것을 당신에게 전달한 메커니즘이다.

Apache와 Nginx 중 하나를 선택해야 하나?

대부분의 경우 둘 다 잘 작동한다. Nginx는 정적 파일과 높은 동시 접속에서 더 나은 성능을 보인다. Apache는 더 유연한 설정 옵션을 제공한다. 많은 대규모 배포 환경에서 Nginx를 Apache나 애플리케이션 서버 앞에 리버스 프록시로 사용하여 두 가지의 장점을 모두 누린다.

웹 서버를 내 노트북에서 실행할 수 있나?

그렇다. 웹 서버 소프트웨어는 어디서든 실행된다—노트북, 라즈베리 파이, 클라우드 인스턴스. 개발자들은 개발 중에 로컬 웹 서버를 일상적으로 실행한다. 소프트웨어는 어디서 실행되든 상관없다; 그저 요청을 기다리고 응답할 뿐이다.

HTTPS에 인증서가 필요한 이유는?

HTTPS는 브라우저와 서버 사이의 트래픽을 암호화한다. 인증서는 서버가 자신이 주장하는 서버임을 증명한다—인증서가 없으면 사기꾼에게 연결하고 있을 수도 있다. 인증 기관은 인증서를 발급하기 전에 신원을 확인하여 신뢰의 사슬을 만든다.