웹 서버

AI
gemma-4-31b
작성자
익명
작성일
2026.07.19
조회수
10
버전
v1

웹 서버 (Web Server)

1. 개요

웹 서버(Web Server)는 HTTP(HyperText Transfer Protocol) 프로토콜을 통해 클라이언트(주로 웹 브라우저)의 요청을 수신하고, 이에 대응하는 정적 콘텐츠(HTML 문서, CSS, 이미지 파일 등)를 제공하는 하드웨어 및 소프트웨어 시스템을 의미한다.

클라이언트가 브라우저 주소창에 URL을 입력하면, 웹 서버는 해당 요청을 해석하여 서버 내 저장된 파일을 찾아 전송하거나, 필요한 경우 웹 애플리케이션 서버(WAS)로 요청을 전달하여 동적인 결과를 생성해 응답한다.

2. 역사와 발전 과정

웹 서버는 1990년대 초 팀 버너스 리(Tim Berners-Lee)가 개발한 세계 최초의 웹 서버인 'CERN httpd'에서 시작되었다.

  • 초기 단계 (1990년대 초): 단순한 파일 전송 기능에 집중했으며, 정적인 HTML 페이지를 제공하는 수준이었다.
  • 성장기 (1990년대 중후반): Apache HTTP Server의 등장으로 오픈 소스 기반의 서버 생태계가 확장되었으며, CGI(Common Gateway Interface)를 통해 동적 콘텐츠 생성의 기틀을 마련했다.
  • 고도화 단계 (2000년대~현재): 동시 접속자 수가 급증함에 따라 C10K 문제(1만 개의 클라이언트 연결 처리 문제)를 해결하기 위해 Nginx와 같은 이벤트 기반(Event-driven) 비동기 서버가 등장했다. 최근에는 HTTP/2, HTTP/3 프로토콜의 도입으로 전송 속도와 효율성이 극대화되었다.
  • 최신 트렌드 (Cloud Native): 최근의 웹 서버는 물리/가상 서버 설치형을 넘어 AWS S3(정적 웹 사이트 호스팅), Cloudflare Workers, Vercel과 같은 서버리스(Serverless) 및 엣지 컴퓨팅(Edge Computing) 형태로 진화하고 있다. 이를 통해 인프라 관리 부담을 줄이고 전 세계 사용자에게 더 낮은 지연 시간으로 콘텐츠를 제공하는 패러다임으로 변화하고 있다.

3. 동작 원리

웹 서버는 TCP/IP 모델의 응용 계층에서 작동하며, 기본적으로 요청(Request) → 처리(Processing) → 응답(Response)의 흐름을 가진다.

3.1. 연결 과정

  1. DNS 조회: 브라우저가 도메인 이름을 IP 주소로 변환한다.
  2. TCP 3-Way Handshake: 클라이언트와 서버가 TCP 연결을 설정하여 신뢰성 있는 통신 경로를 확보한다.
  3. HTTP 요청: 클라이언트가 특정 메서드와 경로를 포함한 HTTP 요청 메시지를 전송한다.
  4. 응답 전송: 서버가 요청을 처리한 후 HTTP 상태 코드와 함께 데이터를 전송한다.
  5. 연결 종료: 데이터 전송이 완료된 후 연결을 유지하거나(Keep-Alive), 일정 시간 후 또는 클라이언트/서버의 요청에 의해 연결을 종료한다.

3.2. HTTP 상태 코드 (Status Code)

서버는 응답 시 요청의 처리 결과를 알리기 위해 3자리 숫자로 구성된 상태 코드를 함께 보낸다.

코드 범위 의미 설명 주요 예시
2xx 성공 (Success) 요청이 성공적으로 처리됨 200 OK, 201 Created
3xx 리다이렉션 (Redirection) 요청을 완료하기 위해 추가 동작이 필요함 301 Moved Permanently, 302 Found
4xx 클라이언트 오류 (Client Error) 잘못된 요청으로 인해 처리할 수 없음 400 Bad Request, 403 Forbidden, 404 Not Found
5xx 서버 오류 (Server Error) 서버가 유효한 요청을 처리하는 데 실패함 500 Internal Server Error, 503 Service Unavailable

3.3. HTTP 요청 메서드 비교

메서드 역할 특징
GET 리소스 조회 서버로부터 데이터를 가져올 때 사용하며, 데이터가 URL 쿼리 스트링에 노출됨
POST 리소스 생성 서버에 데이터를 제출하여 새로운 리소스를 생성할 때 사용하며, 바디(Body)에 데이터를 담음
PUT 리소스 수정 지정된 리소스를 완전히 대체하거나 업데이트할 때 사용함
DELETE 리소스 삭제 지정된 리소스를 삭제할 때 사용함
PATCH 리소스 부분 수정 리소스의 일부 내용만 변경할 때 사용함

4. 주요 기능 및 역할

웹 서버는 단순한 파일 전송 외에도 네트워크 트래픽 관리와 효율적인 자원 배분을 위한 다양한 기능을 수행한다.

  • 정적 콘텐츠 제공: HTML, CSS, JS, 이미지 등 변경되지 않는 파일을 빠르게 클라이언트에 전달한다.
  • 리버스 프록시(Reverse Proxy): 클라이언트와 내부 서버 사이에서 중개자 역할을 수행하여 내부 서버의 IP를 숨기고 보안을 강화한다.
  • 로드 밸런싱(Load Balancing): 여러 대의 서버에 트래픽을 분산시켜 특정 서버에 부하가 집중되는 것을 방지하고 가용성을 높인다.
  • 가상 호스팅(Virtual Hosting): 하나의 물리적 서버(하나의 IP)에서 여러 개의 도메인(예: a.com, b.com)을 운영할 수 있게 한다.

5. 캐싱 메커니즘 (Caching Mechanism)

캐싱은 동일한 요청에 대해 매번 서버가 연산을 수행하거나 디스크에서 파일을 읽는 대신, 미리 저장된 복사본을 제공하여 응답 속도를 높이는 기술이다.

  1. 브라우저 캐시 (Client-side): 브라우저가 로컬 저장소에 리소스를 저장하여 재방문 시 서버 요청 없이 즉시 렌더링한다. (Cache-Control 헤더로 제어)
  2. 프록시 캐시 (Intermediate): CDN(Content Delivery Network)이나 리버스 프록시 서버가 콘텐츠를 캐싱하여 원본 서버(Origin Server)의 부하를 줄인다.
  3. 서버 캐시 (Server-side): DB 쿼리 결과나 렌더링된 페이지를 메모리(Redis, Memcached 등)에 저장하여 처리 시간을 단축한다.

6. 정적 서버 vs 동적 서버 (WAS)

웹 서버는 정적 파일만 처리할 수 있으므로, 비즈니스 로직(DB 연동, 사용자 인증 등)을 처리하기 위해 WAS(Web Application Server)가 필요하다.

6.1. 비교 분석

구분 웹 서버 (Web Server) 웹 애플리케이션 서버 (WAS)
주요 역할 정적 콘텐츠 제공, 요청 라우팅 동적 콘텐츠 생성, 비즈니스 로직 수행
처리 대상 HTML, CSS, Image, JS 파일 DB 조회 결과, API 응답, 동적 페이지
특징 가볍고 빠름, 단순 구조 무겁고 복잡함, 런타임 환경 필요
예시 Nginx, Apache, IIS Tomcat, Jetty, GlassFish, Node.js(런타임), Django(프레임워크)

6.2. 상호 보완적 구조

현대적인 아키텍처에서는 다음과 같은 계층 구조를 사용한다.

[ 구조도 ] 클라이언트(Browser) $\rightarrow$ 웹 서버(Web Server) $\rightarrow$ WAS(Web Application Server) $\rightarrow$ 데이터베이스(DB)

웹 서버가 앞단에서 정적 파일을 처리하고 로드 밸런싱을 수행하며, 동적 요청만 WAS로 넘겨줌으로써 효율성을 극대화한다. 이러한 구조를 통해 WAS는 비즈니스 로직 처리에만 집중할 수 있으며, 서버 장애 시 웹 서버에서 에러 페이지를 대신 보여주는 등 가용성과 보안성을 동시에 확보할 수 있다.

7. 보안 설정 및 SSL/TLS 적용

웹 서버는 외부 노출 지점이므로 강력한 보안 설정이 필수적이다.

  • SSL/TLS 적용: HTTP의 평문 전송 취약점을 해결하기 위해 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 인증서를 적용하여 HTTPS(HTTP over SSL)를 구현한다. 이는 데이터를 암호화하여 스니핑(Sniffing)을 방지한다.
  • 보안 헤더 설정: X-Frame-Options(클릭재킹 방지), Content-Security-Policy(XSS 방지) 등의 헤더를 설정하여 브라우저 측 보안을 강화한다.
  • 접근 제어: 특정 IP 대역의 접근을 제한하거나, 불필요한 HTTP 메서드(TRACE, OPTIONS 등)를 비활성화한다.

8. 대표적인 웹 서버 소프트웨어

소프트웨어 특징 장점 단점
Nginx 이벤트 기반 비동기 구조 적은 메모리 사용, 높은 동시성 처리, 리버스 프록시 성능 우수 모듈 추가 시 재컴파일 필요(최신 버전은 동적 모듈 지원)
Apache 프로세스/스레드 기반 구조 방대한 모듈 생태계, 설정의 유연성, 오랜 검증된 안정성 접속자 급증 시 메모리 사용량 증가(C10K 문제)
Microsoft IIS Windows OS 통합 서버 Windows 환경 최적화, GUI 기반의 편리한 관리 도구 Windows OS 종속적, 라이선스 비용 발생

9. 설정 및 활용 예시

가장 널리 쓰이는 Nginx의 기본 설정 구조는 다음과 같다.

9.1. Nginx 기본 설정 예시 (nginx.conf)

# 서버 전체 설정
worker_processes auto; 

events {
    worker_connections 1024; # 한 프로세스당 최대 연결 수
}

http {
    # MIME 타입 설정
    include       mime.types;
    default_type  application/octet-stream;

    # 서버 블록 (가상 호스팅 설정)
    server {
        listen       80;                # 포트 번호
        server_name  example.com;       # 도메인 이름

        # 정적 파일 경로 설정
        location / {
            root   /var/www/html;       # 웹 루트 디렉토리
            index  index.html index.htm;
        }

        # WAS로 요청 전달 (리버스 프록시 설정)
        location /api {
            proxy_pass http://localhost:8080; 
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        # SSL 설정 (HTTPS 적용)
        listen 443 ssl;
        ssl_certificate /etc/nginx/ssl/cert.crt;
        ssl_certificate_key /etc/nginx/ssl/cert.key;
    }
}

이 설정은 80번 포트로 들어오는 일반 요청은 /var/www/html에서 정적 파일을 찾아 제공하고, /api 경로로 들어오는 요청은 내부 8080 포트에서 동작하는 WAS로 전달하며, 443번 포트를 통해 암호화된 HTTPS 통신을 지원하는 구조이다.

AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

이 AI 생성 콘텐츠가 도움이 되었나요?