[CS] 프록시(Proxy)와 리버스 프록시(Reverse Proxy)

네트워크 인프라를 다루다 보면 프록시(Proxy)라는 개념을 자주 마주치게 된다. nginx를 리버스 프록시로 구성하거나, 사내 프록시를 거쳐 인터넷에 접속하거나, VPN과 프록시의 차이를 따져야 하는 상황이 빈번하다. 이 글에서는 프록시의 기본 개념부터 포워드 프록시와 리버스 프록시의 차이, 관련 개념과의 비교, 실무 활용까지 살펴본다.

TL;DR

• 프록시: 클라이언트와 서버 사이에서 요청과 응답을 중계하는 대리인
• 포워드 프록시: 클라이언트를 대신하여 서버에 요청. 클라이언트가 감춰짐
• 리버스 프록시: 서버를 대신하여 클라이언트 요청을 수신. 서버가 감춰짐
• 주요 차이: 포워드 프록시는 클라이언트 측에 위치하고, 리버스 프록시는 서버 측에 위치
• 포워드 프록시 용도: 접근 제한, 캐싱, 클라이언트 IP 익명화, 접속 우회
• 리버스 프록시 용도: 로드 밸런싱, 서버 보안, 캐싱, SSL Termination
• 실무 예시: 포워드 → 사내 프록시, VPN / 리버스 → nginx, HAProxy, AWS ALB, Ingress Controller

프록시란

개념

프록시(Proxy)는 클라이언트와 서버 사이에서 요청과 응답을 중계하는 대리인 역할을 하는 서버다.

클라이언트가 서버에 직접 요청하는 대신, 프록시 서버가 그 요청을 대신 전달하고 응답을 받아 클라이언트에게 돌려준다. 이 과정에서 보안, 성능, 안정성 등의 이점을 얻을 수 있다.

프록시의 두 가지 방향

프록시는 어디에 위치하는지, 어느 방향으로 요청을 중계하는지에 따라 포워드 프록시와 리버스 프록시로 나뉜다.

포워드 프록시: 클라이언트 → [프록시] → 인터넷 → 서버
리버스 프록시: 클라이언트 → 인터넷 → [프록시] → 서버

• 포워드 프록시(Forward Proxy): 클라이언트 바로 뒤에 위치하여, 클라이언트의 요청을 받아 인터넷을 통해 서버에 전달
• 리버스 프록시(Reverse Proxy): 서버 앞에 위치하여, 인터넷을 통해 들어오는 클라이언트의 요청을 받아 뒤쪽 서버에 전달

일반적으로 “프록시”라고 하면 포워드 프록시를 의미한다.

포워드 프록시와 리버스 프록시 비교

구분	포워드 프록시 (Forward Proxy)	리버스 프록시 (Reverse Proxy)
위치	클라이언트 바로 뒤쪽	인터넷 뒤, 서버 앞쪽
방향	클라이언트 → 프록시 → 인터넷 → 서버	클라이언트 → 인터넷 → 프록시 → 서버
역할	클라이언트의 요청을 대신 전달	서버로 들어오는 요청을 대신 수신
감춰지는 대상	클라이언트 (서버는 프록시만 봄)	서버 (클라이언트는 프록시만 봄)
누구의 대리인	클라이언트의 대리인	서버의 대리인
엔드포인트	클라이언트가 요청하는 주소는 실제 서버 도메인	클라이언트가 요청하는 주소는 프록시의 도메인
통신 구간	클라이언트 ↔ 프록시	프록시 ↔ 내부 서버
네트워크 방향	내부망 → 외부망	외부망 → 내부망
실무 예시	사내 프록시, VPN	nginx, HAProxy, AWS ALB, Ingress Controller

정리하면, 포워드 프록시는 클라이언트의 요청을 받아 서버 쪽으로 밀어주는(forward) 것이고, 리버스 프록시는 클라이언트의 요청을 받아 배후(reverse)의 서버로 전달하는 것이다.

포워드 프록시

^{https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/}

포워드 프록시는 클라이언트에게 요청을 받아, 인터넷을 통해 서버에 요청하고, 서버의 응답 결과를 클라이언트에게 전달한다.

• 클라이언트는 프록시에 연결하고, 타겟 서버의 주소를 프록시에 전달한다
• 프록시가 대신 서버에 요청하고, 응답을 클라이언트 쪽으로 전달한다
• 클라이언트가 감춰진다: 서버 입장에서는 프록시의 IP만 보인다

사용 목적

클라이언트 보안

네트워크 내 클라이언트들의 인터넷 접근을 제한하여 보안을 강화한다. 방화벽 개념으로, 특정 사이트로의 접속을 차단하거나 허용하는 정책을 적용할 수 있다.

캐싱

프록시 서버가 한 번 가져온 리소스를 캐싱하여, 동일한 리소스를 요청할 때 서버까지 가지 않고 프록시에서 바로 응답할 수 있다.

• 다른 클라이언트가 이미 요청한 적 있는 리소스를 요청할 때, 캐시된 리소스를 반환
• 인터넷 너머 서버의 부하를 줄이고, 클라이언트에게 빠른 응답 제공

참고: 다만, 프록시를 거치는 만큼 경유 지점이 추가되므로, 캐시 적중률이 낮은 경우에는 오히려 응답이 느려질 수도 있다. 많은 사용자가 동일한 페이지를 반복 조회하는 경우에 효과적이다.

클라이언트 IP 익명화

프록시를 거치면 서버에는 프록시의 IP만 전달되므로, 클라이언트의 실제 IP를 숨길 수 있다.

참고: 프록시 체이닝

클라이언트의 IP를 더 강력하게 숨기기 위해 여러 프록시 서버를 경유하는 기술이다. Client → Proxy 1 → Proxy 2 → ... → Server 형태로 구성되며, 프록시 서버를 계속 추적하면 클라이언트를 알아낼 수는 있지만, 여러 국가의 프록시를 경유하면 추적이 매우 어렵다.

접속 우회

접속이 차단된 사이트에 프록시를 통해 우회 접속할 수 있다. 프록시 서버가 차단되지 않은 네트워크에 위치해 있다면, 클라이언트는 프록시를 거쳐 차단된 사이트에 접근할 수 있다.

로그 관리

프록시 서버에서 클라이언트의 접속 기록을 관리할 수 있다. 어떤 클라이언트가 어디로 접속하려 하는지 기록하고 모니터링할 수 있다.

포워드 프록시 유형

프록시 서버는 클라이언트의 정보를 얼마나 노출하는지에 따라 분류된다.

유형	HTTP_X	HTTP_X_FORWARDED_FOR	설명
Transparent Proxy	원래 IP	원래 IP	프록시 사용 사실과 원래 IP가 모두 노출됨
Simple Anonymous Proxy	프록시 IP	프록시 IP	프록시 사용 사실은 알려지지만, 원래 IP는 숨겨짐
Distorting Proxy	프록시 IP	랜덤 값	프록시 사용 사실은 알려지지만, 원래 IP는 랜덤 값으로 대체됨
High Anonymity Proxy (Elite)	헤더 없음	헤더 없음	프록시 사용 여부 자체를 알 수 없음. 유료 서비스로 제공되기도 함

리버스 프록시

^{https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/}

리버스 프록시는 클라이언트의 요청을 받아, 배후의 서버에 요청을 전달한다.

• 클라이언트는 인터넷을 통해 프록시에 요청한다
• 프록시는 뒤쪽의 실제 서버에 요청을 전달하고, 응답을 클라이언트에게 돌려준다
• 서버가 감춰진다: 클라이언트는 프록시의 주소만 알 뿐, 뒤에 있는 실제 서버의 존재를 모른다

“Reverse”의 의미: Reverse는 “반대”라기보다 “배후”라는 뜻에 가깝다. Forward Proxy가 클라이언트 앞에서 클라이언트를 대리하는 것이라면, Reverse Proxy는 서버 앞에서 서버를 대리하는, 즉 클라이언트 기준 배후에서 동작하는 프록시다.

사용 목적

로드 밸런싱

여러 대의 서버를 두고 트래픽을 분산한다. 리버스 프록시가 들어오는 요청을 뒤쪽 서버들에 적절히 나누어 전달함으로써, 특정 서버에 트래픽이 집중되는 것을 방지한다. 이 경우 리버스 프록시가 각 웹 페이지의 URL을 재작성(URL rewrite)해야 할 수도 있다.

서버 보안

실제 서버의 IP를 외부에 노출하지 않는다. 클라이언트는 리버스 프록시의 주소만 알고 서비스를 이용하며, 서버 네트워크 단으로 들어오는 트래픽을 프록시에서 검사하고 차단할 수도 있다.

서비스 서버들이 모두 DMZ(비무장 지대) 상에 직접 노출될 경우 보안 문제가 생길 수 있으므로, 리버스 프록시를 앞에 두고 실제 서비스 서버는 내부 네트워크에 숨겨서 운영하는 것이 일반적이다.

캐싱

리버스 프록시에 캐싱된 데이터를 제공하여 서비스 응답 속도를 향상시킨다. 정적 파일(이미지, CSS, JS 등)을 프록시에서 직접 응답하면, 뒤쪽 서버의 부하를 줄일 수 있다.

SSL Termination

리버스 프록시에서 SSL/TLS 암호화를 처리하여 뒤쪽 서버의 암호화 부하를 해소한다.

방식	설명
SSL Termination	프록시에서 HTTPS를 복호화한 후, 뒤쪽 서버에는 HTTP(평문)로 전달
SSL Passthrough	프록시가 암호화를 해제하지 않고, 암호화된 채로 뒤쪽 서버에 전달

SSL Termination을 사용하면 뒤쪽 서버는 암호화/복호화 작업을 하지 않아도 되므로 연산 부하가 줄어든다. 다만, 프록시와 서버 사이 구간은 평문이므로 내부 네트워크의 보안이 보장되어야 한다.

원본 정보 전달

리버스 프록시를 거치면 뒤쪽 서버 입장에서는 클라이언트의 원본 정보(IP, 호스트명 등)를 직접 알 수 없다. 이를 보완하기 위해 프록시가 HTTP 헤더에 원본 정보를 실어 보내는 것이 일반적이다.

헤더	설명
X-Real-IP	클라이언트의 실제 IP 주소
X-Forwarded-For	클라이언트 IP와 경유한 프록시 IP 목록
X-Forwarded-Proto	클라이언트가 사용한 프로토콜 (http 또는 https)
Host	클라이언트가 요청한 원래 호스트명

nginx에서는 proxy_set_header 지시어로 이 헤더들을 설정한다.

location / {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

관련 개념 비교

리버스 프록시 vs 리다이렉트

프록시와 리다이렉트는 모두 요청을 다른 곳으로 보내는 것이지만, 동작 방식이 근본적으로 다르다.

구분	리버스 프록시	리다이렉트
동작	프록시가 대신 요청을 전달하고 응답을 받아옴	클라이언트에게 다른 주소로 가라고 알려줌
URL 변경	클라이언트의 URL이 바뀌지 않음	클라이언트의 URL이 새 주소로 변경됨
클라이언트 인지	뒤쪽 서버의 존재를 모름	새 주소를 알게 됨
뒤쪽 서버 접근성	뒤쪽 서버가 외부에서 접근 불가능해도 됨	새 주소가 클라이언트에서 접근 가능해야 함

리버스 프록시:
  Client → Proxy → Backend    (Client는 Backend을 모름)

리다이렉트:
  Client → Server A → "301, go to Server B"
  Client → Server B            (Client가 Server B를 알아야 함)

프록시 vs VPN

프록시와 VPN은 모두 내부 네트워크와 인터넷 사이를 중개하는 역할을 하지만, 동작 계층과 보안 수준에 차이가 있다.

구분	프록시	VPN
동작 계층	애플리케이션 레이어 (HTTP 등)	네트워크 레이어
범위	특정 앱의 트래픽만 처리	모든 트래픽을 처리
암호화	일반적으로 암호화 없음 (트래픽 소스 익명화)	모든 트래픽 암호화 (IP + 데이터 모두)
보안 수준	낮음 (트래픽 내용이 노출될 수 있음)	높음 (인증되지 않은 사용자는 데이터를 읽을 수 없음)
활용	트래픽 분산, 캐싱, 접속 우회	원격 접속, 보안 통신, 지역 제한 우회

VPN은 본질적으로 데이터를 암호화하는 포워드 프록시라고 볼 수 있다. 클라이언트의 모든 트래픽을 암호화하여 VPN 서버로 보내고, VPN 서버가 IP 주소를 익명화한 뒤 목적지로 전달한다.

리버스 프록시 vs API Gateway

API Gateway는 리버스 프록시의 기능을 포함하면서, 추가적인 기능을 제공하는 상위 개념이다.

구분	리버스 프록시	API Gateway
핵심 기능	요청 전달, 로드 밸런싱	요청 전달 + 인증/인가 + Rate Limiting + 요청 변환 + 모니터링
관심사	트래픽 라우팅과 분산	API 수명주기 관리
예시	nginx, HAProxy	Kong, AWS API Gateway, Traefik

모든 API Gateway는 리버스 프록시를 포함하지만, 리버스 프록시가 모두 API Gateway인 것은 아니다. 단순한 트래픽 분산이 목적이라면 리버스 프록시로 충분하고, API 관리까지 필요하다면 API Gateway를 고려하면 된다.

실무 활용

리버스 프록시 구성 예시

실무에서 가장 흔한 리버스 프록시 구성은 nginx를 사용하는 것이다.

단일 구성

nginx가 리버스 프록시로서 클라이언트 요청을 뒤쪽 애플리케이션 서버로 전달하는 기본 구성이다.

Client → nginx (80/443) → App Server (8080)

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

로드 밸런싱 구성

여러 대의 백엔드 서버에 트래픽을 분산하는 구성이다.

Client → nginx (80/443) → App Server 1 (8080)
                        → App Server 2 (8080)
                        → App Server 3 (8080)

upstream backend {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
    }
}

다단 프록시 구성

온프레미스 환경에서는 리버스 프록시가 여러 단으로 구성되는 경우가 있다. L7 진입점에서 SSL을 처리하고, 뒤쪽의 앱 레벨 프록시에서 라우팅을 담당하는 구조다.

Client → L7 LB / nginx (443, SSL Termination)
       → App nginx (80, 라우팅)
       → App Server (8080)

이 구성에서는 앞단 nginx가 SSL Termination을 담당하고, 뒤쪽 nginx가 요청 경로에 따라 적절한 애플리케이션 서버로 라우팅한다. 각 단계에서 proxy_set_header로 원본 정보를 전달하는 것이 중요하다.

어떤 것을 선택할지

상황	선택
내부 클라이언트의 인터넷 접근을 제한/모니터링하고 싶다	포워드 프록시
클라이언트 IP를 익명화하고 싶다	포워드 프록시 또는 VPN
모든 트래픽을 암호화하고 싶다	VPN
서버 앞에서 트래픽을 분산하고 싶다	리버스 프록시
서버의 실제 IP를 숨기고 싶다	리버스 프록시
SSL 처리를 서버에서 분리하고 싶다	리버스 프록시
API 인증, Rate Limiting 등까지 필요하다	API Gateway

정리

프록시는 클라이언트와 서버 사이에서 요청과 응답을 중계하는 대리인이다. 위치와 방향에 따라 포워드 프록시와 리버스 프록시로 나뉘며, 각각의 목적과 활용 방식이 다르다.

개념	설명
프록시	클라이언트와 서버 사이의 중계 서버
포워드 프록시	클라이언트 측에 위치. 클라이언트를 감추고, 접근 제한·캐싱·IP 익명화에 사용
리버스 프록시	서버 측에 위치. 서버를 감추고, 로드 밸런싱·보안·SSL Termination에 사용
리다이렉트와의 차이	프록시는 대신 가져다주고, 리다이렉트는 다른 곳으로 가라고 알려줌
VPN과의 차이	프록시는 앱 레이어에서 특정 트래픽만, VPN은 네트워크 레이어에서 모든 트래픽을 암호화
API Gateway	리버스 프록시 + 인증/인가 + Rate Limiting 등 API 관리 기능

참고 자료

• Reverse proxy - Cloudflare - 포워드/리버스 프록시 개념 설명
• Proxy server - Wikipedia - 프록시 서버 전반
• Forward Proxy vs Reverse Proxy - NGINX - nginx 관점에서의 리버스 프록시