프록시

클라이언트가 서버에 직접 요청을 보내는 구조는 단순하지만, 서비스가 커질수록 여러 문제를 맞닥뜨립니다. 서버 IP가 직접 노출되면 보안 경계를 세우기 어렵고, 백엔드 서버가 여러 대인데 클라이언트가 개별 주소를 알아야 한다면 서버 구성이 바뀔 때마다 클라이언트 쪽도 바꿔야 합니다. 같은 정적 응답을 수천 번 반복해서 원본 서버가 직접 보내야 하는 것도 낭비고, 사내 직원이 외부에 어디든 접속할 수 있는 상태를 통제 없이 두는 것도 운영 위험입니다. 이런 문제를 개별 애플리케이션마다 해결하려 하면 코드 중복과 관리 포인트가 넘쳐나고, 정책 변경 시 모든 서비스를 일일이 수정해야 합니다. 프록시는 이 부담을 클라이언트와 서버 사이의 중간 계층 하나에 모아서 처리하는 구조입니다.

초기 웹에서는 클라이언트가 서버에 직접 연결하는 것이 전부였습니다. 하지만 사내 네트워크에서 직원의 인터넷 접속을 통제해야 하는 요구가 생기면서 포워드 프록시가 먼저 등장했습니다. 서버 쪽에서도 하나의 도메인 뒤에 여러 서비스를 두거나, 클라이언트에게 서버 구조를 숨기거나, TLS 인증서를 중앙에서 관리하고 싶은 필요가 커지면서 리버스 프록시가 자연스럽게 자리를 잡았습니다. 마이크로서비스 아키텍처가 확산되면서 프록시의 역할은 더 커졌습니다. 수십 개의 백엔드 서비스를 하나의 진입점에서 라우팅하고, 서비스 간 통신 정책을 중앙에서 적용하고, 서비스 메시에서 사이드카 프록시로 각 서비스의 네트워크 관심사를 분리하는 패턴이 일반화됐습니다. 프록시는 단순한 중계 장치에서, 현대 인프라의 트래픽 제어와 정책 적용의 허브로 진화한 셈입니다.

프록시는 클라이언트와 서버 사이에 끼어들어 요청과 응답을 대신 주고받는 중간 서버입니다. 크게 두 방향이 있습니다. 포워드 프록시는 클라이언트 쪽에 위치해 사용자가 외부로 나가는 요청을 대리합니다. 사내 네트워크에서 특정 사이트 접근을 차단하거나, 사용자의 실제 IP를 숨기거나, 반복 요청을 캐시해 대역폭을 줄이는 데 쓰입니다. 리버스 프록시는 반대로 서버 쪽에 위치해 외부에서 들어오는 요청을 대신 받습니다. 클라이언트는 리버스 프록시의 주소만 알면 되고, 뒤편에 서버가 몇 대 있는지, 어떤 경로를 어디로 보내는지는 프록시가 결정합니다. 리버스 프록시는 URL 경로나 호스트 헤더를 보고 적절한 백엔드로 라우팅하고, TLS 인증서를 한 곳에서 관리해 내부 서버는 평문 통신만 하면 되게 만들고, 자주 요청되는 응답을 캐시해 원본 서버 부하를 줄입니다. 이런 기능이 한 계층에 모여 있기 때문에, 백엔드 서비스를 추가하거나 교체해도 클라이언트가 보는 진입점은 바뀌지 않습니다. Nginx, HAProxy, Envoy 같은 도구가 리버스 프록시로 널리 쓰이는 이유가 여기에 있습니다.

프록시, 로드 밸런서, CDN은 모두 클라이언트와 서버 사이에서 트래픽을 중계한다는 공통점이 있고, 실제로 리버스 프록시가 로드 밸런싱과 캐싱을 함께 수행하는 경우도 흔합니다. 하지만 각각이 해결하려는 핵심 문제는 다릅니다. 프록시의 본질은 중계 자체입니다. 요청을 가로채서 검사하고, 변환하고, 라우팅하는 범용적인 중간 계층으로서 접근 제어, 프로토콜 변환, 헤더 수정 같은 유연한 정책 적용이 강점입니다. 로드 밸런서는 동일한 서비스의 여러 복제본에 요청을 고르게 나누는 데 특화되어 있고, 헬스 체크와 장애 우회가 핵심 가치입니다. CDN은 지리적으로 분산된 엣지에 콘텐츠를 캐시해서 물리적 거리에 의한 지연을 줄이는 데 초점을 맞춥니다. 작은 서비스에서 리버스 프록시 하나가 라우팅, TLS 종료, 간단한 분산까지 처리하는 것은 자연스럽지만, 서비스가 커지면 각 문제를 전담하는 계층으로 분리하는 편이 운영과 장애 격리에 유리합니다.

리버스 프록시는 백엔드 서비스가 2개 이상이거나, 하나의 도메인 뒤에서 경로별로 다른 서비스를 제공하거나, TLS 인증서를 한 곳에서 관리하고 싶을 때 거의 자연스럽게 등장합니다. 컨테이너 기반 배포 환경에서 인그레스 컨트롤러가 하는 일도 본질적으로 리버스 프록시입니다. 포워드 프록시는 사내 네트워크에서 외부 접속을 통제하거나, 테스트 환경에서 외부 API 호출을 가로채 모킹할 때 쓰이기도 합니다. 다만 프록시가 단일 장애 지점이 되지 않도록 이중화가 필요하고, 중간 계층이 하나 더 생기는 만큼 지연이 미세하게 추가됩니다. 또 프록시에 라우팅, 캐시, 인증, 속도 제한, 로깅 등 너무 많은 정책을 한꺼번에 쌓으면 설정이 복잡해지고 장애 원인을 좁히기 어려워질 수 있습니다. 프록시를 잘 운영하는 핵심은 많은 기능을 켜는 것이 아니라, 이 계층이 담당할 관심사를 명확히 정하고 나머지는 적절한 전담 인프라로 넘기는 데 있습니다.

다음에 볼 개념

함께 보면 좋은 개념