프록시

백엔드 서버가 여러 대로 늘어나면 클라이언트가 개별 서버 주소를 모두 알아야 합니다. 서버 구성이 바뀔 때마다 클라이언트 설정도 같이 바꿔야 하고, 서버 IP가 직접 노출되면 보안 경계도 세우기 어렵습니다. TLS 인증서를 서버마다 따로 관리하거나, 동일한 정적 응답을 원본 서버가 수천 번 반복해서 보내는 것도 낭비입니다. 그렇다고 이 문제를 서비스마다 코드로 해결하면 관리 포인트가 각 애플리케이션으로 흩어지고, 정책 하나 바꿀 때마다 여러 서비스를 동시에 수정해야 합니다. 이 부담을 클라이언트와 서버 사이의 한 계층에 모으는 것이 프록시의 출발점입니다.

초기 웹에서는 클라이언트가 서버에 직접 연결하는 것이 전부였습니다. 사내 네트워크가 커지면서 직원의 인터넷 접속을 통제해야 하는 요구가 생겼고, 이것이 포워드 프록시의 시작이었습니다. 서버 쪽에서도 하나의 도메인 뒤에 여러 서비스를 두거나, 내부 구조를 외부에 노출하지 않으면서 TLS 인증서를 중앙에서 관리하고 싶은 필요가 쌓이면서 리버스 프록시가 자리를 잡았습니다. 마이크로서비스가 확산된 뒤에는 수십 개 백엔드를 하나의 진입점으로 라우팅하거나, 서비스 간 통신 정책을 사이드카 프록시로 분리하는 패턴이 보편화됐습니다. 단순한 중계 장치가 현대 인프라에서 트래픽 제어의 허브가 된 셈입니다.

프록시는 클라이언트와 서버 사이에 끼어 요청과 응답을 대신 주고받는 중간 서버입니다. 방향이 두 가지입니다. 포워드 프록시는 클라이언트 쪽에서 사용자가 외부로 나가는 요청을 대리합니다. 특정 도메인 접근 차단, 사용자 IP 은닉, 반복 요청 캐싱이 주된 역할입니다. 리버스 프록시는 반대로 서버 쪽에 위치해 외부 요청을 받습니다. 클라이언트는 리버스 프록시 주소 하나만 알면 되고, 뒤편에 서버가 몇 대인지, 어떤 경로를 어디로 보내는지는 프록시가 결정합니다. 리버스 프록시는 URL 경로나 호스트 헤더를 보고 적절한 백엔드로 요청을 넘기고, TLS 인증서를 한 곳에서 관리해 내부 서버는 평문 통신만 하면 됩니다. 자주 요청되는 응답은 캐시해서 원본 서버에 가는 트래픽을 줄입니다. 백엔드를 추가하거나 교체해도 클라이언트가 보는 진입점은 바뀌지 않습니다.

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

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