카테고리 없음

포워드 프록시(Forward Proxy)와 리버스 프록시(Reverse Proxy)의 개념과 실무 활용 - 5

지기(ZIGI) 2026. 2. 21. 15:18

today key : 포워드, 리버스, 프록시, forward, reverse, proxy, 보안, 정책, policy, 통제, 개념

3.2 HTTPS(암호화) 트래픽은 어떻게 다루는가?

  서비스 트래픽도 대부분 HTTPS이기 때문에, 리버스 프록시에서 중요한 선택은 “TLS를 어디서 종료(termination)할 것인가?”입니다. 실무에서는 보통 다음 두 가지 방식으로 접근합니다.

(1) 패스스루(SSL/TLS Passthrough): “복호화하지 않고 그대로 전달”

리버스 프록시가 TLS를 해석하지 않고, 암호화된 세션을 내부 서버까지 그대로 전달하는 방식입니다. 이 경우 프록시는 L4 수준의 중계 역할에 가까워져, 경로 기반 라우팅이나 WAF 같은 L7 기능 적용이 제한될 수 있습니다.

(2) TLS 종료(TLS Termination): “리버스 프록시에서 복호화 후 처리”

리버스 프록시가 인증서를 가지고 TLS를 종료한 뒤, 복호화된 HTTP 요청에 대해 라우팅/인증/WAF/캐시 같은 기능을 적용합니다. 이후 내부 서버로는 HTTP로 전달하거나, 보안 요구에 따라 내부 구간도 다시 TLS로 암호화(재암호화)할 수 있습니다.

  • 장점: L7 기능을 적극 활용할 수 있고, 인증서 관리(갱신/배포)도 입구에서 일원화하기 쉬움
  • 고려사항: “어디까지를 신뢰 구간으로 볼 것인가”, 내부 구간 암호화 필요 여부, 인증서/키 관리 책임 등 운영 설계가 필요

정리하면, 패스스루는 구조가 단순한 대신 기능이 제한되고, TLS 종료는 통제와 최적화에 유리하지만 운영 설계가 더 중요해집니다.



3.3 리버스 프록시의 이점

 리버스 프록시의 장점은 “서비스 앞단에 공통 기능을 모아” 보안과 운영을 동시에 단순화한다는 데 있습니다. 먼저 외부에서 내부 서버가 직접 보이지 않도록 숨길 수 있어(오리진 은닉), 공격 표면을 줄이는 효과가 있습니다. 동시에 서비스 입구에서 인증/접근 제어/WAF/레이트 리밋 같은 정책을 적용해, 애플리케이션이 모든 방어 기능을 직접 떠안지 않도록 역할을 분리할 수 있습니다.

 가용성 측면에서도 효과가 큽니다. 여러 대의 서버를 하나의 서비스처럼 묶고, 헬스체크를 기반으로 장애 서버를 자동으로 제외하거나 우회할 수 있습니다. 트래픽이 늘어나면 백엔드를 수평 확장하고, 리버스 프록시가 그 앞에서 자연스럽게 분산을 수행합니다. 캐시, 압축, 연결 최적화 같은 성능 기능도 입구에서 적용할 수 있어 사용자 체감 성능을 끌어올리는 데 도움이 됩니다.


3.4 리버스 프록시의 대표 활용

 실무에서 리버스 프록시는 보통 “서비스 입구의 표준 구성 요소”로 사용됩니다. 가장 전형적인 형태는 웹 서비스 앞단에 리버스 프록시를 두고, 내부의 여러 웹/애플리케이션 서버로 트래픽을 분산하는 방식입니다. 이 과정에서 경로 기반 라우팅으로 API와 웹을 분리하거나, 특정 경로에만 인증/정책을 강화하는 구성도 흔합니다.

 또한 외부 공격을 먼저 받아내기 위해 WAF나 DDoS 방어 계층과 함께 배치하거나, 정적 콘텐츠는 캐시/CDN으로 분리하고 동적 요청만 리버스 프록시를 통해 오리진으로 보내는 구조도 많이 사용됩니다. 마이크로서비스나 컨테이너 환경에서는 “서비스 메시/인그레스”의 형태로 발전해, 서비스 라우팅과 인증을 표준화하는 역할을 맡기도 합니다.

 마지막으로, 배포 관점에서도 유용합니다. 블루/그린, 카나리처럼 트래픽 일부만 새 버전으로 보내는 방식은 애플리케이션을 크게 바꾸지 않더라도 입구(리버스 프록시)의 라우팅 정책으로 구현할 수 있어, 운영 리스크를 줄이는 데 도움이 됩니다.

 

저작자표시 비영리 변경금지 (새창열림)