HTTP 완벽 가이드 - 프락시(Proxy)

서비스를 운영하다 보면 직접 클라이언트와 서버가 붙지 않고 중간에 뭔가가 개입되는 경우가 많다. 보안, 캐싱, 필터링, 로드밸런싱 같은 이유 때문이다. 그 역할을 맡는 것이 바로 프락시(Proxy)다. 단순히 중계자에 불과해 보이지만 웹 트래픽의 성능·보안·운영 효율성에 큰 영향을 준다. 이번 장을 읽으면서 프락시가 단순 리다이렉트 장치가 아니라 트래픽을 제어하는 핵심 컴포넌트라는 걸 알게 됐다.

프락시란 무엇인가?

프락시는 클라이언트와 서버 사이에 위치한 중개 서버를 뜻한다. 클라이언트는 서버에 직접 요청하지 않고 프락시를 거쳐 요청을 전달하며 서버 응답 역시 프락시를 통해 클라이언트로 돌아온다. 이때 프락시는 단순히 메시지를 전달만 할 수도 있고 캐싱이나 보안 정책을 적용해 트래픽을 가공하고 제어할 수도 있다. 즉, 프락시는 클라이언트 입장에서는 서버처럼 보이고 서버 입장에서는 클라이언트처럼 보이는 독특한 역할을 한다.

프락시의 주요 활용 사례

1. 보안

프락시는 방화벽처럼 내부 네트워크와 외부 인터넷 사이의 안전한 경계로 활용된다. 내부 사용자가 외부에 접근할 때 허용된 요청만 통과시키고, 반대로 외부에서 들어오는 악성 요청을 차단한다. 또한 X-Forwarded-For 헤더를 제거하거나 변경하여 클라이언트의 실제 IP를 숨김으로써 익명성을 제공할 수 있다. 이런 방식은 개인정보 보호나 기업 내부망 보안에서 널리 사용된다.

2. 성능 최적화

자주 요청되는 정적 리소스(이미지, CSS, JS 등)는 프락시 서버에 캐싱해두면 서버까지 가지 않고 빠르게 응답할 수 있다. 이렇게 하면 대역폭 절약, 서버 부하 감소, 응답 시간 단축이라는 세 마리 토끼를 동시에 잡을 수 있다. CDN(Content Delivery Network)이 대표적인 성능 최적화 프락시 활용 사례다.

3. 정책 적용

프락시는 특정 URL이나 도메인에 대한 접근을 차단하거나 업무 시간 동안 소셜 미디어 접속을 제한하는 등 기업 정책을 강제할 수 있다. 학교나 회사에서 특정 사이트를 막아본 경험이 있다면 그 뒤에는 프락시가 있었다고 생각하면 된다. 또한 성인물 차단, 악성 사이트 차단 같은 콘텐츠 필터링도 이 영역에 포함된다.

4. 인프라 운영

대규모 서비스에서는 프락시가 로드밸런서로 동작하여 여러 서버로 트래픽을 분산시킨다. 또한 SSL/TLS 복호화를 서버 대신 프락시에서 처리(SSL termination)하여 서버 부담을 줄이기도 한다. 이런 역할 덕분에 서버는 더 단순하게 애플리케이션 로직만 처리할 수 있고 운영자는 인프라를 효율적으로 확장할 수 있다.

프락시 동작 구조

위 그림처럼 프락시는 클라이언트와 서버 사이의 중계자로 동작한다. 클라이언트 요청은 프락시를 거쳐 서버로 전달되고 서버 응답 역시 프락시를 통해 클라이언트에 도착한다. 이 단순한 구조 안에서 프락시는 캐싱, 보안 검사, 트래픽 로드밸런싱 등 다양한 역할을 수행한다. 즉, 단순 패스스루가 아니라 트래픽을 제어하는 제어 지점(Control Point)으로서 기능한다.

주요 프락시 종류

포워드 프락시(Forward Proxy)

클라이언트 앞단에 위치하여 내부 사용자의 요청을 대신 서버에 전달하는 구조다. 클라이언트는 프락시 주소를 명시적으로 설정해야 하며 서버는 실제 요청자가 누구인지 알 수 없다. 주로 내부망에서 외부 인터넷 접근 제어, 캐싱, 익명화 목적으로 활용된다.

리버스 프락시(Reverse Proxy)

서버 앞단에 위치하여 클라이언트 요청을 대신 받아 서버로 전달하는 구조다. 클라이언트는 서버와 직접 통신한다고 생각하지만 실제로는 리버스 프락시를 거친다. 보통 로드밸런싱, SSL 종료, 캐싱에 활용되며 서버 구조를 감추고 트래픽을 효율적으로 분산시키는 데 큰 장점이 있다. Nginx, Apache HTTP Server, HAProxy가 대표적인 리버스 프락시다.

Nginx 리버스 프락시 설정 예시

리버스 프락시는 클라이언트가 서버에 직접 붙는 대신 Nginx 같은 중간 계층이 요청을 받아 내부 애플리케이션 서버(Spring Boot 등)로 전달한다. 실제로 api.moomoo-gift.com 도메인을 EC2에 설정했을 때의 예시를 정리하면 아래와 같다.

# HTTP -> HTTPS 리다이렉션 (포트 80)
server {
    listen 80;
    server_name api.moomoo-gift.com;

    # 모든 요청을 HTTPS로 리다이렉션
    return 301 https://$host$request_uri;
}

# HTTPS 서버 블록 (포트 443)
server {
    listen 443 ssl;
    server_name api.moomoo-gift.com;

    # SSL 인증서 경로 (Let's Encrypt / Certbot에서 발급받은 파일)
    ssl_certificate     /etc/letsencrypt/live/api.moomoo-gift.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.moomoo-gift.com/privkey.pem;

    # 리버스 프락시 설정: Nginx → 내부 Spring Boot 서버(8080)
    location / {
        proxy_pass http://127.0.0.1:8080;

        # 클라이언트의 실제 요청 정보를 내부 서버로 전달하기 위한 헤더 설정
        proxy_set_header Host $host;                # 원본 Host 헤더 유지
        proxy_set_header X-Real-IP $remote_addr;    # 실제 클라이언트 IP 전달
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 프락시 체인을 통한 클라이언트 IP 추적
        proxy_set_header X-Forwarded-Proto $scheme; # 요청이 http/https 중 무엇인지 전달
    }
}

위 설정으로 클라이언트는 https://api.moomoo-gift.com 으로 요청을 보내지만 실제 처리는 내부 8080 포트에서 동작하는 Spring Boot 애플리케이션이 담당한다. 프락시가 중간에서 SSL 종료, 헤더 전달, 트래픽 제어를 담당하면서 클라이언트는 내부 구조를 알 필요가 없다.

투명 프락시(Transparent Proxy)

클라이언트나 서버가 프락시 존재를 의식하지 못하는 형태로 동작한다. 요청과 응답을 거의 수정하지 않고 그대로 전달하기 때문에 “투명”하다고 부른다. 주로 ISP(인터넷 서비스 제공자)가 트래픽 모니터링이나 캐싱 목적으로 사용한다.

프락시 종류 비교

구분	위치	주요 목적	사용 사례
포워드 프락시	클라이언트 앞단	내부 사용자 제어, 캐싱, 익명화	기업 내부망, 학교 인터넷 차단
리버스 프락시	서버 앞단	로드밸런싱, SSL 종료, 보안	Nginx, HAProxy, CDN
투명 프락시	네트워크 중간	모니터링, 캐싱	ISP 트래픽 관리, 캐시 서버

메시지 수정

프락시는 단순 패스스루(pass-through)가 아니라 메시지를 가공할 수도 있다.

• 요청 헤더 추가/삭제 (Via, X-Forwarded-For)
• 응답 헤더 변경 (캐싱 제어, 보안 헤더 삽입)

GET /index.html HTTP/1.1
Host: www.example.com
Via: 1.1 proxy1.example.com
X-Forwarded-For: 203.0.113.5

📝 배운점

이번 장을 통해 프락시는 단순 중계기가 아니라 보안, 성능, 정책, 운영을 모두 책임지는 핵심 인프라 컴포넌트라는 걸 깨달았다. 특히 포워드 프락시와 리버스 프락시의 차이를 명확하게 이해한 것이 큰 수확이었다. 서비스 운영에서 캐싱, 로드밸런싱, SSL 처리 같은 기능을 구현할 때 단순 애플리케이션 로직만으로 해결할 수 없는 이유가 바로 여기에 있었다. 앞으로 인프라 아키텍처를 설계할 때 프락시 계층을 어디에 두고 어떤 역할을 맡길지를 먼저 고려하는 습관을 가져야겠다.