Intro

지난 7월 12일에 진행된 Ausg 9기 면접에서 Reverse Proxy에 대해 제대로 답변하지 못하여. 그걸 기념(?)하기 위해 미루고 미루던 Proxy에 대해 이번 기회를 통해 블로그 글을 써서 정리해 보려 합니다.

Proxy

프록시(Proxy)는 단어 뜻 그대로 ‘대리인’ 또는 ‘중개자’ 를 의미합니다. 웹의 세계에서 프록시는 클라이언트와 서버라는 두 주체 사이에서, 둘 사이의 HTTP 통신을 대리하는 중개인입니다. 클라이언트와 서버 사이에 있다는 특징 때문에 Proxy는 클라이언트로부터 요청을 받고 응답을 반환하는 웹 서버인 동시에, 서버로 요청을 보내고 응답을 받는 웹 클라이언트로서의 이중적 성격을 가집니다. 프록시는 단순히 메시지를 전달만 하는 배달부가 아닙니다. 오히려 통행하는 모든 트래픽을 검문하고, 최적의 경로를 안내하며, 심지어 내용을 바꿔 전달하기도 하는 만능 관제탑에 가깝습니다.

Why Use Proxy?

앞서 프록시를 ‘만능 관제탑’에 비유했습니다. 그렇다면 이 관제탑은 왜 필요한 걸까요? 단순히 메시지를 전달하는 것 이상의 어떤 가치를 제공하기에, 우리는 기꺼이 TCP/IP 아키텍처의 복잡성을 감수하고 프록시를 도입하는 걸까요?

중요한 점은, 지금부터 설명할 대부분의 기능은 트래픽의 방향에 따라 포워드 프록시와 리버스 프록시 양쪽에서 모두 적용된다는 것입니다.

보안 강화

• 방화벽(Firewall): 프록시는 네트워크의 경계에서 외부로 나가거나 내부로 들어오는 트래픽을 관리하는 방화벽 역할을 합니다. 특정 종류의 악성 요청을 차단하고 내부 네트워크를 보호하는 단일 방어 지점이 될 수 있습니다.
• 접근 제어 및 필터링: 학교나 회사에서 특정 웹사이트 접근을 막는 것이 바로 프록시의 역할입니다. 부적절한 콘텐츠를 필터링하고, 특정 리소스에 대한 접근 권한을 중앙에서 관리하며 모든 접근 기록을 남길 수 있습니다.
• 익명화(Anonymization): 프록시는 사용자의 요청을 대신해서 서버에 요청을 보내기 때문에 사용자의 IP주소, 브라우저 정보, 쿠키 등 개인을 식별할 수 있는 정보를 HTTP Header또는 Body에서 제거하여 개인정보 보호와 익명성을 강화할 수 있습니다.

성능 최적화

• 웹 캐싱(Web Caching): 프록시의 강력한 기능 중 하나입니다. 자주 요청되는 콘텐츠(ex: logo, CSS File등)의 복사본을 프록시 서버에 저장해두고. 이후 동일한 요청이 들어오면 멀리 있는 원본 서버까지 가지 않고 캐시된 데이터를 즉시 전달하여 속도를 높이고 서버까지 가는 트래픽을 줄일 수 있습니다.
• 부하 분산 (Load Balancing): 대규모 서비스에서는 여러 대의 웹 서버가 동시에 운영됩니다. 프록시는 들어오는 요청을 여러 서버에 골고루 분산하여 특정 서버에 과부하가 걸리는 것을 막고 전체 시스템의 안정성과 효율성을 높입니다.
• 서버 가속(Reverse Proxy): 웹서버 바로 앞에 위치하여 스스로를 웹 서버처럼 위장하는 프록시를 리버스 프록시(Reverse Proxy) 또는 서로게이트(Surrogate) 라고 합니다. SSL 암호화 처리, 정적 콘텐츠 캐싱등 무거운 작업을 대신 처리하여 실제 웹 서버가 핵심적인 비즈니스 로직 처리에만 집중할 수 있도록 만들어 줍니다.

콘텐츠 변환 및 라우팅

프록시는 단순 전달을 넘어, 콘텐츠를 가공(Transcoding) 하거나 요청에 따라 목적지를 바꾸는 라우팅도 가능합니다.

• 콘텐츠 변환(Transcoding): 프록시는 콘텐츠를 클라이언트에게 전달하기 전에 그 형식을 바꿀 수 있습니다. 예를 들어, 고화질 이미지를 모바일 기기에 맞게 저용량 JPEG 파일로 변환하거나, 복잡한 웹페이지를 단순한 텍스트로 변환하여 전송할 수 있습니다.
• 콘텐츠 라우팅: 요청의 내용에 따라 트래픽의 목적지를 바꿀 수 있습니다. ‘/api’로 시작하는 요청은 애플리케이션 서버로, ‘/video’ 요청은 미디어 스트리밍 서버로 보내는 식의 제어가 가능합니다.

Where Do Proxies Go?

프록시는 네트워크상 다양한 위치에 배포되어 각기 다른 목적을 수행합니다. 프록시의 위치와 트래픽을 유도하는 방식에 따라 그 역할과 기능이 결정됩니다. 다시말해, 프록시의 위치가 곧 프록시의 역할과 기능을 정의하는 셈입니다.

프록시 서버의 다양한 배포 위치

프록시는 트래픽의 흐름을 제어하기 위해 전략적으로 배치됩니다.

• Egress Proxy: 로컬 네트워크의 출구에 위치합니다. 주로 기업이나 기관에서 내부 사용자들이 인터넷으로 보내는 트래픽을 제어할 목적으로 사용됩니다. 인터넷 대역폭 비용을 절감하고, 직원들이 유해 사이트에 접속하는 것을 막는 콘텐츠 필터링, 바이러스 차단 등 보안 강화 목적으로 배치됩니다.
• Access / Ingress Proxy: ISP(Internet Service Provider)의 접속 지점에 위치하여, 수 많은 고객들로부터 오는 요청을 종합적으로 처리합니다. 주된 목적은 인기 있는 콘텐츠를 캐싱하여 사용자들의 다운로드 속도를 개선하고, 인터넷 대역폭 비용을 절감하는 것입니다.
• Surrogate / Reverse Proxy: 웹 서버 바로 앞, 즉 네트워크의 끝단에 위치합니다. 웹 서버인 것처럼 동작하여 모든 요청을 먼저 받습니다. 이를 통해 DDos 공격 방어 또는 자주 요청되는 콘텐츠를 캐싱하여 실제 웹 서버의 부하를 줄여 성능을 크게 향상시킵니다. CDN(Content Delivery Network)이 리버스 프록시의 대표적인 예시입니다.

프록시 계층 구조

프록시는 단독으로 쓰이기도 하지만, 여러 프록시가 사슬처럼 연결된 계층 구조(Hierarchy) 를 이루기도 합니다. 요청 메시지(HTTP Requeset)는 최종 목적지인 원본 서버에 도달할 때까지 여러 프록시를 순차적으로 거쳐갈 수 있습니다. 이때, 요청이 전달되는 경로에서 다음 프록시를 ‘부모’, 이전 프록시를 ‘자식’ 이라고 부릅니다.

How Proxies Get Traffic

웹 브라우저(ex: safari, google chrome, arc)는 일반적으로 웹 서버와 직접 통신하기 때문에 HTTP 트래픽이 프록시를 거쳐가는 방법을 먼저 설정해야 합니다. 아무리 강력한 프록시라도, 트래픽이 프록시를 거치지 않고 그냥 지나쳐간다면 아무 소용이 없습니다. 프락시가 제 역할을 하려면 클라이언트의 웹 트래픽이 프록시를 거치도록 만들어야 합니다. 이 트래픽을 유도하는 방식은 크게 서버 측에서 제어하는 방식과 클라이언트/네트워크에서 제어하는 방식으로 나눌 수 있습니다.

이번 글에서는 특히 서버 측 제어 방식을 더 자세히 살펴보겠습니다.

DNS 수정

리버시 프록시(또는 서로게이트)가 트래픽을 받는 가장 일반적인 방법입니다. 핵심 원리는 리버스 프록시가 실제 웹 서버의 신원(identity)을 이어받는 것입니다.

작동 방식은 다음과 같습니다.

1. DNS 레코드 설정: 관리자는 웹사이트의 호스트 명(예: jinmu.me)에 대한 DNS 레코드를 설정할 때, 실제 웹 서버의 IP 주소가 아닌 리버스 프록시의 IP 주소를 등록합니다.
2. 클라이언트의 DNS 조회: 사용자가 브라우저에 jinmu.me을 입력하면, 클라이언트의 컴퓨터는 DNS 서버에 이 도메인의 IP 주소를 물어봅니다.
3. 프록시 IP 주소 반환: DNS 서버는 설정된 대로 리버스 프록시의 IP 주소를 응답으로 돌려줍니다.
4. 프록시로 요청 전송: 클라이언트는 이 IP 주소가 프록시의 것이라는 사실을 전혀 알지 못한 채, 해당 주소로 HTTP 요청을 보냅니다. 클라이언트로서는 프록시가 바로 jinmu.me 웹 서버 그 자체인 셈입니다.

만약 DNS의 동작에 대해 알고 싶으시다면 제가 작성한 DNS Series를 보시는 것도 추천해 드립니다!

이 방식 덕분에, 클라이언트는 아무것도 몰라도 되고 서버 아키텍처는 자유롭게 변경될 수 있습니다.

HTTP Redirection

웹 서버가 직접 클라이언트에게 프록시를 사용하라고 ‘지시’하는 방법도 있습니다.

1. 클라이언트가 웹 서버에 리소스를 요청합니다.
2. 웹 서버는 요청을 바로 처리하는 대신, 305 Use Proxy라는 특별한 HTTP 상태 코드와 함께 응답을 보냅니다.
3. 이 응답의 Location 헤더에는 클라이언트가 사용해야 할 프록시 서버의 주소가 포함되어 있습니다.
4. 이 응답을 받은 클라이언트는 동일한 요청을 Location 헤더에 명시된 프록시 서버를 통해 다시 보내야 합니다.

하지만 이 305 상태 코드는 현재는 거의 사용되지 않으며, 많은 최신 브라우저에서 보안상의 이유로 지원이 중단되었습니다. 악의적인 서버가 사용자의 트래픽을 감시할 수 있는 프록시로 유도할 수 있는 잠재적 위험 때문입니다. 따라서 개념적으로는 존재하지만, 실제 환경에서는 보기 드문 방식입니다.

클라이언트 및 네트워크 측 제어 방식

이번엔 반대로, 트래픽의 시작점인 클라이언트나 중간 경로인 네트워크에서 직접 교통 흐름을 제어하는 방식입니다. 주로 포워드 프록시에서 사용됩니다.

• 직접 경로 설정 (클라이언트 설정): 가장 고전적인 방법입니다. 웹 브라우저 설정에 들어가 “이 프록시 서버를 경유해서 인터넷에 접속해라”라고 수동으로 지정하는 것입니다. 또는 특정 규칙이 담긴 스크립트(PAC 파일)를 사용하여 URL에 따라 프록시 사용 여부를 동적으로 결정할 수도 있습니다.

• 네트워크 수정 (투명 프록시): 클라이언트나 사용자는 전혀 모르는 사이에, 길목에 있는 네트워크 장비(라우터, 스위치)가 보이지 않는 그물을 쳐서 HTTP 트래픽을 강제로 프록시 서버로 보내는 방식입니다. 사용자에게는 보이지 않는다고 하여 ‘투명(Transparent) 프록시’ 라고도 불립니다.

단점

이렇게 강력한 기능을 제공하는 프록시지만, 모든 기술이 그렇듯 빛이 있으면 그림자도 있는 법입니다. ‘모든 것을 통제한다’라는 말은 ‘모든 것이 그에게 의존한다’라는 뜻이기도 하니까요. 프록시를 아키텍처에 도입할 때 반드시 고려해야 할 몇 가지 단점들이 존재합니다.

단일 장애 지점 (Single Point of Failure, SPOF)

프록시의 가장 치명적인 약점입니다. 모든 트래픽이 프록시를 거쳐야 한다는 것은, 만약 프록시 서버가 다운된다면 전체 서비스가 마비되는 결과를 초래할 수 있다는 의미입니다. 클라이언트와 서버 사이의 유일한 통로가 막혀버리는 셈이죠. 이 때문에 실제 운영 환경에서는 프록시 서버를 여러 대 두어 이중화(Redundancy)하거나, 클라우드 환경의 로드 밸런서처럼 자체적으로 고가용성을 보장하는 서비스를 사용하는 것이 사실상 필수적입니다.

성능 병목 및 복잡성

프록시는 요청을 중간에서 처리하고 전달하는 과정에서 아주 약간의 지연(Latency)을 추가합니다. 대부분의 경우 이는 무시할 수 있는 수준이지만, 만약 프록시 서버의 사양이 부족하거나 설정이 최적화되지 않았다면 오히려 전체 시스템의 성능을 저하시키는 병목이 될 수 있습니다. 또한, 프록시 계층 구조나 복잡한 라우팅 규칙은 아키텍처의 복잡도를 높여 설정하고 관리하는 것을 굉장히 까다롭게 만듭니다.

보안 및 개인정보 문제

보안 강화를 위해 도입한 프록시가 역설적으로 보안의 허점이 될 수도 있습니다. 모든 트래픽이 집중되는 만큼, 프록시 서버 자체가 해킹당하면 시스템 전체가 위험에 노출됩니다. 특히 SSL/TLS 트래픽을 복호화(SSL Termination)하여 내용을 검사하는 경우, 프록시는 암호화되지 않은 민감한 데이터를 모두 들여다볼 수 있게 됩니다. 이는 관리자에게 큰 책임감을 요구하며, 프록시 서버 자체의 보안을 철저히 관리해야 하는 또 다른 숙제를 안겨줍니다.

Outro

이렇게 프록시의 정의부터 시작해, 사용하는 이유(Why), 다양한 위치(Where), 그리고 트래픽을 제어하는 방식(How) 그리고 마지막으로 단점까지 정리해 봤습니다. AUSG 면접에서 리버스 프록시에 대해 제대로 답변하지 못했던 아쉬움으로 시작된 포스팅이었지만. 단순히 ‘리버스 프록시는 웹 서버 앞에 두는 것’이라는 표면적인 이해를 넘어, 왜 그것이 거기에 있어야만 하는지, 어떤 원리로 클라이언트가 자신도 모르게 프록시와 통신하게 되는지를 알 수 있었던 시간이었습니다. 글을 쓰기 위해 자료를 찾고 문장을 다듬는 과정이야말로 가장 확실한 공부 방법이라는 것을 다시 한번 깨닫게 되네요.

이 글이 과거의 저처럼 프록시에 대해 막연하게 알고 있었던 분들에게 도움이 되길 바랍니다. 감사합니다.

Reference

• Http definitive guide

[10분 테코톡] 🐿 제이미의 Forward Proxy, Reverse Proxy, Load Balancer

🙋‍♀️ 우아한테크코스의 크루들이 진행하는 10분 테크토크입니다. 🙋‍♂️’10분 테코톡’이란 우아한테크코스 과정을 진행하며 크루(수강생)들이 동료들과 학습한 내용을 공유하고 이야기하는 시간입니다. 서로가 성장하기 위해 지식을 나누고 대화하며 생각해보는 시간으로 자기 주도적인…

프록시를 알려드림

#개발자 #Proxy #몰컴⭐️ 코드팩토리 통합링크 (모든 강의 및 서적) ⭐️https://links.codefactory.ai👉 NestJS 마스터클래스https://bit.ly/fcnestjs👉 플터터 초급https://inf.run/Sjuw👉 플터터 중급https://…