Proxy
프록시(Proxy)는 클라이언트와 서버가 직접 통신하지 않고 중간에 대리 서버를 두어 거치게 하는 구조입니다. 포워드 프록시는 클라이언트 측 앞단에서 외부 접근을 제어하고, 리버스 프록시는 서버 측에서 요청을 받아 뒤편의 여러 서버로 분배합니다. 이를 통해 캐시, 접근 제어, TLS 종료, 라우팅 같은 기능을 애플리케이션이 아닌 중간 계층에서 처리할 수 있게 해줍니다.
▶아키텍처 다이어그램
🔗 관계 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
백엔드 서버가 여러 대로 늘어나면 클라이언트가 개별 서버 주소를 모두 알아야 합니다. 서버 구성이 바뀔 때마다 클라이언트 설정도 같이 바꿔야 하고, 서버 IP가 직접 노출되면 보안 경계도 세우기 어렵습니다. TLS 인증서를 서버마다 따로 관리하거나, 동일한 정적 응답을 원본 서버가 수천 번 반복해서 보내는 것도 낭비입니다. 그렇다고 이 문제를 서비스마다 코드로 해결하면 관리 포인트가 각 애플리케이션으로 흩어지고, 정책 하나 바꿀 때마다 여러 서비스를 동시에 수정해야 합니다. 이 부담을 클라이언트와 서버 사이의 한 계층에 모으는 것이 프록시의 출발점입니다.
초기 인터넷과 웹에서는 클라이언트가 개별 서버에 직접 연결하는 구조가 기본이었습니다. 서버 수가 적고 서비스도 단순할 때는 큰 문제가 없었지만, 1990년대 기업 네트워크가 커지면서 직원들의 외부 웹 접근을 기록하고 제한해야 할 필요가 생겼습니다. 이 시기에 포워드 프록시가 널리 쓰이기 시작했습니다. 사용자가 직접 인터넷으로 나가게 두는 대신, 회사가 지정한 중간 서버를 통해서만 나가게 하면 접근 통제와 캐시를 한곳에서 처리할 수 있었기 때문입니다. 한편 1990년대 후반부터 2000년대 초반으로 넘어가며 웹 서비스 규모가 커지고, 하나의 도메인 뒤에서 여러 애플리케이션을 운영하거나 SSL 종료를 중앙화하려는 요구가 강해졌습니다. 이 흐름 속에서 Apache, Nginx, HAProxy 같은 소프트웨어가 리버스 프록시 역할을 맡으며 서버 앞단의 표준 계층으로 자리잡았습니다. 이후 클라우드와 마이크로서비스가 확산되자, 프록시는 단순히 요청을 넘기는 장치를 넘어 API 게이트웨이, 인그레스, 서비스 메시 사이드카처럼 트래픽 정책과 서비스 간 통신을 통제하는 핵심 인프라로 발전했습니다.
프록시는 클라이언트와 서버 사이에 끼어 요청과 응답을 대신 주고받는 중간 서버입니다. 방향이 두 가지입니다. 포워드 프록시는 클라이언트 쪽에서 사용자가 외부로 나가는 요청을 대리합니다. 특정 도메인 접근 차단, 사용자 IP 은닉, 반복 요청 캐싱이 주된 역할입니다. 리버스 프록시는 반대로 서버 쪽에 위치해 외부 요청을 받습니다. 클라이언트는 리버스 프록시 주소 하나만 알면 되고, 뒤편에 서버가 몇 대인지, 어떤 경로를 어디로 보내는지는 프록시가 결정합니다. 리버스 프록시는 URL 경로나 호스트 헤더를 보고 적절한 백엔드로 요청을 넘기고, TLS 인증서를 한 곳에서 관리해 내부 서버는 평문 통신만 하면 됩니다. 자주 요청되는 응답은 캐시해서 원본 서버에 가는 트래픽을 줄입니다. 백엔드를 추가하거나 교체해도 클라이언트가 보는 진입점은 바뀌지 않습니다.
리버스 프록시에서 경로별 라우팅과 TLS 종료
server {
listen 443 ssl;
server_name app.example.com;
ssl_certificate /etc/ssl/cert.pem;
ssl_certificate_key /etc/ssl/key.pem;
location /api/ {
proxy_pass http://api-service;
}
location / {
proxy_pass http://web-service;
}
}클라이언트는 `app.example.com` 하나만 보지만, 프록시는 TLS를 여기서 끝내고 경로에 따라 `/api`는 API 백엔드로, 나머지는 웹 백엔드로 넘깁니다. 구조 설명의 '단일 진입점, TLS 종료, 경로 기반 라우팅'이 설정 표면에서는 이렇게 드러납니다.
프록시, 로드 밸런서, CDN은 모두 클라이언트와 서버 사이에서 트래픽을 중계합니다. 리버스 프록시가 로드 밸런싱과 캐싱을 함께 하는 경우도 흔해서 경계가 흐릿하게 느껴지지만, 각각이 해결하는 핵심 문제는 다릅니다. 프록시의 본질은 요청을 가로채서 검사하고, 변환하고, 라우팅하는 범용 중계입니다. 접근 제어, 프로토콜 변환, 헤더 조작 같은 유연한 정책 적용이 강점입니다. 로드 밸런서는 동일 서비스의 복제본 여러 개에 요청을 고르게 나누는 데 특화되어 있고, 헬스 체크와 장애 우회가 핵심입니다. CDN은 지리적으로 분산된 엣지에 콘텐츠를 캐시해 물리적 거리에 따른 지연을 줄이는 데 집중합니다. 작은 서비스에서 리버스 프록시 하나가 라우팅, TLS, 간단한 분산까지 처리하는 것은 자연스럽습니다. 서비스가 커지면 각 문제를 전담하는 계층으로 분리하는 편이 장애 격리와 운영에 유리합니다. 프록시에 너무 많은 정책을 쌓으면 장애 원인을 좁히기 어려워지는 것도 한계입니다.
프록시를 두면 백엔드 변경과 정책 적용을 하나의 진입점에 모을 수 있다는 큰 이득이 생깁니다. TLS 종료, 경로 라우팅, 캐시, 접근 제어를 공통 계층으로 빼내면 개별 애플리케이션은 본연의 비즈니스 로직에 더 집중할 수 있습니다. 대신 이 계층 자체가 운영 복잡도의 중심이 됩니다. 프록시가 죽으면 앞단 전체가 영향을 받기 쉬워 이중화와 모니터링이 필요하고, 홉이 하나 늘어나는 만큼 지연도 조금 추가됩니다. 규모가 커질수록 '정책을 한곳에 모으는 이득'과 '너무 많은 책임이 한곳에 쌓이는 비용' 사이 균형을 봐야 합니다. 단일 진입점과 정책 중앙화가 중요한 환경에서는 프록시의 가치가 크지만, 작은 서비스에서 과도한 정책을 몰아넣으면 얻는 것보다 장애 분석 복잡도가 더 커질 수 있습니다.
리버스 프록시는 백엔드가 2개 이상이거나, 하나의 도메인 뒤에서 경로별로 다른 서비스를 제공하거나, TLS 인증서를 한 곳에서 관리하고 싶을 때 거의 자연스럽게 등장합니다. 컨테이너 환경에서 인그레스 컨트롤러가 하는 일도 본질적으로 리버스 프록시입니다. 포워드 프록시는 사내망에서 외부 접속을 통제하거나, 테스트 환경에서 외부 API 호출을 가로채 모킹할 때도 쓰입니다.