회사 PC의 외부 웹 접속을 통제하는 장비와 고객의 요청을 웹 서버로 전달하는 장비는 모두 프록시로 불릴 수 있다. 하지만 두 장비의 정책을 같은 방식으로 설계하면 사용자를 식별하지 못하거나 내부 서버가 외부에 그대로 노출되는 문제가 생긴다. 구분의 출발점은 설치 위치보다 ‘누구를 대신해 요청을 중계하는가’다.
포워드 프록시는 사용자의 요청을 중계
프록시는 통신 중간에서 요청과 응답을 전달하는 중계자다. 일상적으로 ‘프록시 서버’라고 부를 때는 포워드 프록시를 뜻하는 경우가 많지만, 넓게 보면 리버스 프록시도 프록시의 한 종류다. RFC 9110은 HTTP 중계자를 설명하면서 프록시와 게이트웨이, 터널을 구별한다. [1]
포워드 프록시는 클라이언트가 외부 서비스에 접근할 때 사용하는 중계 지점이다. 명시적 프록시 구성에서는 브라우저나 운영체제에 프록시 사용을 설정하고, 프록시가 목적지 서버와 통신한다. 기업에서는 사용자별 외부 접속 정책과 접속 기록을 한곳에서 관리하는 데 활용할 수 있다. 다만 사용자 인증·필터링·캐시는 제품과 설정에 따라 제공되는 기능이며, 프록시라는 이름만으로 모두 보장되지는 않는다. [2]
예를 들어 직원의 특정 외부 사이트 이용을 허용할지 판단하려면 사용자와 목적지 정보를 연결해야 한다. 브라우저만 프록시를 사용하고 다른 프로그램이 직접 통신한다면 정책 범위에 빈틈이 생길 수 있다. 따라서 어떤 애플리케이션이 프록시를 지원하며 외부 직접 접속은 어떻게 관리할지 함께 정해야 한다.
리버스 프록시는 서비스의 진입점을 담당
리버스 프록시는 서비스 운영자가 웹·애플리케이션 서버 앞에 두는 중계 지점이다. 사용자는 공개된 서비스 주소로 접속하고, 리버스 프록시는 요청을 설정된 내부 서버로 전달한다. 브라우저에 별도의 프록시 설정을 입력하는 방식이 일반적인 사용 조건은 아니다. Apache 공식 문서도 리버스 프록시를 서버 측 게이트웨이로 설명한다. [2]
이 지점에서 호스트명이나 URL 경로에 따라 요청을 분배하고 TLS 연결을 처리할 수 있다. 여러 서버로 부하를 분산하거나 캐시를 사용하는 구성도 가능하지만 별도 설정이 필요하다. 리버스 프록시를 설치했다는 사실만으로 WAF 기능이나 서비스 이중화가 완성되는 것은 아니다.
| 비교 기준 | 포워드 프록시 | 리버스 프록시 |
|---|---|---|
| 주로 대신하는 대상 | 외부에 접속하는 클라이언트 | 요청을 처리하는 서비스 서버 |
| 관리하려는 흐름 | 관리 대상 사용자의 외부 접속 | 공개 서비스로 들어오는 요청 |
| 목적지 선택 | 클라이언트가 요청한 외부 목적지 | 운영자가 정한 내부 서버·경로 |
| 대표 활용 | 외부 접속 정책, 사용자별 이용 기록 | 서비스 라우팅, TLS 처리, 부하 분산 |
| 먼저 확인할 사항 | 사용자 식별과 정책 적용 범위 | 원본 서버 접근 제한과 전달 정보 신뢰 |
이 표의 외부·내부 구분은 일반적인 기업 배치 기준이다. 같은 네트워크 안에도 리버스 프록시를 둘 수 있으므로, 단순히 트래픽 방향만 보고 종류를 결정하면 안 된다.
HTTPS는 중계 방식에 따라 보이는 범위 차이
포워드 프록시를 거친다고 HTTPS 본문을 자동으로 읽을 수 있는 것은 아니다. HTTP CONNECT를 이용하는 일반적인 터널 구성에서는 프록시가 연결을 마련하고 암호화된 데이터를 전달하며, TLS는 클라이언트와 목적지 서버 사이에 유지된다. 별도 TLS 검사 구성이 없다면 프록시는 그 터널의 HTTP 본문을 평문으로 검사하지 못한다. [1]
리버스 프록시가 TLS를 종료하는 구성에서는 클라이언트와의 암호화 연결이 프록시에서 끝나고, 내부 서버까지는 별도의 연결이 만들어진다. 이 구간도 HTTPS를 사용한다면 인증서 검증과 서버 이름 설정을 점검해야 한다. NGINX 문서는 프록시의 업스트림 TLS 검증을 별도 설정 항목으로 다룬다. [3]
따라서 ‘HTTPS를 사용한다’는 설명만으로 전체 경로가 같은 수준으로 보호된다고 판단하지 말아야 한다. 외부 연결, 프록시의 처리 지점, 내부 서버 연결을 나누어 암호화·인증서·접근 권한을 확인하는 편이 정확하다.
기업 적용 예시와 운영 점검 기준
다음은 가상 예시다. 한 기업이 직원의 외부 SaaS 이용을 관리하면서 고객용 주문 서비스를 운영한다고 가정하자. 직원의 외부 접속에는 포워드 프록시를 검토하고, 고객용 서비스 앞에는 리버스 프록시를 배치할 수 있다. 두 요구는 함께 존재하며 서로 대체되지 않는다.
운영 설계에서는 다음 항목을 확인한다.
- 정책 적용 범위: 관리 대상 프로그램과 통신이 프록시를 거치는지 확인하고, 예외 연결의 승인·만료 기준을 기록한다.
- 원본 서버 접근: 고객 요청이 프록시를 거치도록 설계했다면 내부 서버의 직접 외부 접근도 제한한다. 주소를 숨기는 것만으로 접근통제가 되지는 않는다.
- 실제 사용자 IP: 애플리케이션이 프록시의 IP만 기록하는지 확인한다. 전달된 IP 헤더를 사용할 때는 신뢰하는 프록시 주소 범위를 지정하고, 외부에서 받은 값을 무조건 신뢰하지 않는다. NGINX의 realip 모듈도 신뢰할 송신자를 별도로 지정한다. [4]
- 캐시와 개인정보: 로그인 후 개인화 응답을 공용 캐시에 저장해도 되는지 검토한다. 캐시는 성능 옵션인 동시에 응답 격리와 관련된 설정이다.
- 장애와 변경: 프록시 중단 시 영향 범위, 인증서 갱신, 시간 제한, 긴 요청 처리, 설정 복구 절차를 시험한다.
이 목록은 제품별 기본값을 대신하는 설정 템플릿이 아니다. 실제 트래픽과 데이터 성격에 맞춰 검증할 운영 항목이다.
실무자 관점: 기능 목록보다 신뢰 경계를 먼저 설정
도입 검토에서 ‘캐시 지원’, ‘SSL 지원’ 같은 기능 목록만 비교하면 실제 책임 범위가 빠지기 쉽다. 운영 관점에서는 어떤 연결을 허용하는지, 누가 인증하는지, 전달 헤더를 어디까지 믿는지, 장애 때 어떤 업무가 멈추는지를 먼저 문서화하는 편이 유용하다.
리버스 프록시 뒤의 애플리케이션도 자체 권한 검사를 유지해야 한다. 앞단을 통과했다는 이유만으로 모든 요청을 신뢰하면 프록시의 잘못된 라우팅이나 설정 변경이 권한 문제로 이어질 수 있다. 포워드 프록시 역시 사용자 인증이 없다면 접속 기록만으로 개인을 정확히 식별하기 어렵다.
결론
직원의 외부 접속을 관리하려면 클라이언트 측 중계와 정책 적용 범위를, 공개 서비스를 제공하려면 서버 측 진입점과 원본 서버 보호를 중심으로 설계한다. 구성 검토는 ‘프록시가 있는가’에서 끝내지 말고 HTTPS 처리 구간, 전달 정보의 신뢰 범위, 장애 시 업무 영향까지 실제 요청 경로를 따라 확인해야 한다.