쉬운 설명
사용자가 yoursite.com에 접속할 때, 그 요청이 곧장 앱 서버에 가지 않고 보통 그 앞단의 리버스 프록시(NGINX·HAProxy·Envoy 등)에 먼저 도달합니다. 리버스 프록시는 그 요청을 분석해서 '이건 결제 서비스로, 이건 검색 서비스로'처럼 알맞은 서버에 넘겨 줍니다.
중간에 한 단계 서는 대신 많은 일을 한 번에 할 수 있습니다. ① 로드 밸런싱(여러 서버에 분산), ② HTTPS 종료(LB에서 SSL을 풀고 내부는 평문), ③ 캐싱(자주 요청되는 응답을 보관), ④ 압축(응답 본문을 작게), ⑤ 인증 검사(토큰 유효성 확인), ⑥ 속도 제한(rate limiting), ⑦ DDoS 완화, ⑧ 로그 수집. 그래서 거의 모든 실서비스 앞에는 어떤 형태로든 리버스 프록시가 있다고 봐도 무방합니다.
참고로 '프록시'라는 단어는 두 가지 다른 위치를 가리킬 수 있습니다. ① 포워드 프록시는 클라이언트 쪽 — 회사 네트워크의 사내 프록시처럼 사용자가 인터넷에 나갈 때 거치는 중간. ② 리버스 프록시는 서버 쪽 — 인터넷에서 서비스로 들어올 때 거치는 중간. 둘 다 '중간에 끼는 것'은 같지만, 누구를 보호·관리하는지가 반대입니다.
현대 아키텍처에서는 리버스 프록시의 역할이 더 정교해졌습니다. API 게이트웨이(Kong·Tyk·AWS API Gateway), 서비스 메시의 사이드카(Envoy), CDN의 엣지 노드까지 — 모두 '중간에 서서 트래픽을 다루는' 프록시의 변형입니다. 마이크로서비스 시대의 인프라는 사실상 프록시의 다층 구조라고 봐도 됩니다.
주의: 프록시가 한 대면 단일 장애 지점이 됩니다. 그래서 보통 여러 대를 두고 DNS·Anycast로 분산합니다. 또 프록시 설정이 잘못되면 모든 트래픽에 영향을 주니, 변경은 신중히 단계적으로 적용합니다. 작은 설정 하나가 전체 사이트를 다운시키는 일이 흔하니, 변경 전 dry-run·자동화·롤백 절차가 필수입니다.
비유로 보면
리버스 프록시는 큰 회사의 안내 데스크와 같습니다. 방문자가 회사에 들어오면 먼저 안내 데스크에 도착하고, 거기서 '결제팀은 3층, 영업팀은 5층'으로 안내받습니다. 안내 데스크는 방문 기록도 남기고, 출입증·예약 확인 같은 보안 절차도 한곳에서 처리합니다.
어디에서 만나나
모든 실서비스의 앞단(NGINX·HAProxy가 표준), API 게이트웨이, CDN 엣지 노드, 쿠버네티스 Ingress, 서비스 메시(Envoy·Linkerd). 현대 클라우드 아키텍처의 거의 모든 입출구에 어떤 형태로든 프록시가 들어 있습니다.
작은 예시
회사 사이트의 결제·로그인·블로그가 각각 다른 서비스로 떨어져 있어도, 사용자는 모두 같은 yoursite.com 한 주소로 접속합니다. 그 한 주소에 도착한 요청을 리버스 프록시가 '/checkout은 결제 서비스, /login은 인증 서비스, /blog는 블로그 서비스'로 라우팅해 보내 줍니다.
자주 하는 오해
한 줄 정리
리버스 프록시의 진짜 가치는 '여러 서비스 앞에 한 곳의 입출구를 만든다'에 있습니다. 그 한 곳에서 보안·성능·관찰이 한꺼번에 해결됩니다.