프록시 서버 알아보기

HTTPS로 서비스를 띄우기 위해서는 웹 서버가 필요하다. 내가 사용하고 있는 개발 도구는 Spring Boot이고, 내장 웹 서버로 Tomcat을 사용하고 있다. Tomcat과 Spring Boot는 자체적으로 HTTPS를 지원하지만, 실무 환경에서는 애플리케이션이 직접 HTTPS를 처리하는 방식보다는 프록시 웹 서버를 앞단에 두는 구조가 더 일반적으로 사용된다고 한다. 이는 Spring Boot가 HTTPS를 지원하지 못해서가 아니라, TLS(암호화) 처리를 애플리케이션에서 분리하여 인증서 관리, 성능 부담, 운영 복잡도를 줄이기 위함이다. 그렇다면 프록시 웹 서버는 어떻게 HTTPS 요청을 받아서 내부의 Spring Boot 애플리케이션과 통신하게 될까? 이 글에서는 프록시 웹 서버가 HTTPS 연결을 종료하고, 내부로는 HTTP 요청을 전달하는 흐름을 중심으로 그 동작 원리를 정리해보려고 한다.

프록시 서버란 무엇일까?

프록시 서버는 대리 서버를 뜻한다고 합니다. 그렇다면 왜 프록시 서버가 필요할까요? 프론트엔드와 백엔드를 분리하여 개발하는 환경에서는 외부 클라이언트와 백엔드 사이의 통신 책임을 분리할 필요가 있으며, 이 역할을 수행하기 위해 프록시 서버가 사용됩니다.

프록시 서버가 사용하지 않는다면?

프론트도 백도 각각 서버가 존재할겁니다. 그러면 프론트를 실행을 시킨다음 백도 실행을 시키고 프론트에서 API를 쏴야 할겁니다.
그렇게 되면 프론트에서 백의 실질적인 주소도 알고 있어야 하죠.

다음과 같은 문제들이 존재한다고 합니다. 대표적인 문제 2개만 살펴보도록 하죠.

문제 ① 변경에 취약해진다 (Change Coupling)

백엔드는 실제 운영 환경에서 자주 변경됩니다. 예를 들면 다음과 같은 상황들이 발생할 수 있습니다.

• 서버 이전
• 트래픽 증가로 인한 스케일 아웃
• 장애로 인한 인스턴스 교체
• 환경별 주소 차이 (local / dev / prod)

프론트엔드가 백엔드의 실제 API 주소를 알고 있는 구조라면, 백엔드의 주소가 변경될 때마다 프론트엔드 역시 함께 수정·재배포되어야 합니다.이는 단순히 배포 비용이 증가하는 문제를 넘어, 운영 중 주소 불일치나 설정 누락으로 인해 장애로 직결될 가능성도 높아집니다.

즉, 백엔드의 변경이 프론트엔드까지 전파되는 구조가 되며, 변경 영향도가 불필요하게 커지게 됩니다.

문제 ② 보안 경계가 깨진다 (Security Boundary)

프론트엔드는 본질적으로 신뢰할 수 없는 환경입니다. 브라우저에서 실행되기 때문에, F12 개발자 도구를 통해 네트워크 요청, API 주소, 헤더 정보 등을 누구나 확인할 수 있습니다. 프론트엔드가 백엔드의 실제 주소를 알고 있는 경우, 공격자는 프론트를 거치지 않고 백엔드 AP를 직접 호출할 수 있게 됩니다.

이러한 구조에서는 다음과 같은 문제가 발생합니다.

• 인증/인가 검증
• 비정상 요청 필터링
• 트래픽 차단 및 방어 로직

과 같은 모든 방어 책임을 백엔드가 직접 떠안게 됩니다.

즉, 백엔드는 비즈니스 로직뿐만 아니라 외부 요청에 대한 1차 방어선 역할까지 수행해야 하며, 이는 보안 경계를 약화시키고 공격 표면을 크게 만드는 결과로 이어집니다.

이를 다른 용어로 비유하면

손님(프론트) ─── 주방(백엔드)

손님이 주방에 직접 주문하는 구조입니다. 이 경우 주방은 요리를 하는 동시에 주문을 받고,
이상한 요청을 걸러내고, 몰려드는 주문을 통제해야 합니다.

즉, 주방이 요리 + 응대 + 통제까지 모두 담당하는 구조가 됩니다. 이렇게 되면 주방 입장에서는 매우 피곤하고, 본래의 역할인 '요리'에 집중하기 어려워집니다. 그래서 일반적으로는 다음과 같은 구조를 사용합니다.

그래서 일반적으로는 다음과 같은 구조를 사용합니다.

손님(프론트) ─── 카운터(프록시) ─── 주방(백엔드)

카운터가 주문을 먼저 받아 정리하고, 문제가 없는 요청만 주방으로 전달합니다. 주방은 더 이상 손님을 직접 상대하지 않고
요리에만 집중할 수 있게 됩니다. 프록시 서버 역시 이와 유사한 역할을 수행합니다. 프론트엔드와 백엔드 사이에서 요청을 대신 받아
통신, 제어, 보호의 책임을 분리해주는 중간 계층입니다.

프록시 서버는 프론트엔드로부터 들어오는 모든 요청을 먼저 받아, 해당 요청이 어떤 백엔드로, 어떤 규칙에 따라 전달되어야 하는지를 결정한 뒤 백엔드로 전달하는 역할을 합니다. 이를 통해 프록시는 프론트엔드와 백엔드가 직접 통신하지 않도록 하고, 요청의 흐름과 통신 규칙을 한 곳에서 관리하는 질서의 역할을 수행합니다.

프록시 서버를 학습하면 따라오는 용어가 두 가지가 존재합니다. 프론트 프록시 서버와 리버스 프록시 서버입니다. 
이 친구들은 어떤 역할을 하는 친구들일까요?

프론트 프록시 서버와 리버스 프록시 서버

이 둘은 어디에 서서 누구를 대신하는지에 있습니다. 프론트 프록시 서버같은 경우는 프론트를 대신하는 서버이고 
리버스 프록시 서버는 서버를 대신해서 사용하는 서버라고 합니다.

프론트 프록시 서버

프론트 프록시 서버는 클라이언트 쪽에 위치하여, 외부 서버로 나가는 요청을 통제하는 프록시입니다. 즉, 내부 → 외부 트래픽의 출구를 관리하는 역할을 하며, 클라이언트가 외부와 직접 통신하지 않도록 중간에서 요청을 검사하고 제어합니다.

현실 세계로 비유하면, 외부로 나가기 전 반드시 거쳐야 하는 출입 통제소에 가깝습니다. 이로 인해 조직 내부의 클라이언트들을 중앙에서 통제할 수 있으며, 이러한 이유로 기업이나 학교 기관 네트워크에서 주로 사용됩니다.

개별 클라이언트를 관리하는 게 아니라, 클라이언트들을 '네트워크 단위' 로 묶어서 관리하는 장치입니다. 
웹 프록시 서버로는 부적절해보입니다. 왜냐하면 웹은 클라이언트를 특정할 수 없기 때문입니다.

리버스 프록시 서버

리버스 프록시 서버는 서버 측에 위치하여, 외부 클라이언트로부터 들어오는 요청을 통제하는 프록시입니다. 즉, 외부 → 내부 트래픽의 진입 지점을 관리하는 역할을 합니다. 이를 통해 백엔드 서버를 외부로부터 보호할 수 있으며, 클라이언트는 실제 백엔드 서버의 주소나 구조를 직접 알 필요가 없습니다.

웹 서비스 환경에서는 클라이언트를 네트워크 단위로 신뢰하기 어렵기 때문에, 서버 입구를 통제하는 리버스 프록시 구조가 특히 적합하다고 볼 수 있습니다.

프론트 프록시와 리버스 프록시는 구현 방식보다, 무엇을 통제하기 위해 존재하는지를 기준으로 바라보는 것이 중요합니다.
이 관점에서 보면 두 프록시의 차이는 비교적 명확하게 드러납니다.

간단하게 표로 확인해봅시다.

구분	프론트 프록시	리버스 프록시
위치	클라이언트 쪽	서버 앞단
통제 방향	내부 → 외부	외부 → 내부
주 목적	사용자/네트워크 통제	서버 보호/구조 분리
서버 보호	❌	⭕
실무 빈도	낮음	매우 높음

 

이렇게 프록시 서버에 대해 학습을 진행하였는데 게이트 웨이라고 존재합니다. 특히 리버스 프록시 서버의 역할은 게이트웨이와 유사한 느낌이 드는데요. 실제로 같은지 확인해봅시다.

프록시 vs 게이트 웨이

결론부터 말씀드리자면, 프록시와 게이트웨이는 전혀 다릅니다.

리버스 프록시와 게이트웨이는 위치와 역할이 유사해 보이지만, 책임 범위에서 차이가 있습니다. 리버스 프록시는 외부 요청의 진입 지점을 관리하는 데 초점을 두는 반면, 게이트웨이는 요청의 의미를 기준으로 서비스 접근을 통제합니다. 따라서 게이트웨이는 리버스 프록시의 확장된 형태로 이해할 수 있습니다.

마무리

문득 프록시 서버가 뭔지 궁금해서 한번 정리해봤습니다. 엄청나게 자세하게 설명한 글은 아니지만 적어도 프론트 프록시가 무엇인지 리버스 프록시가 무엇인지 알게 되었습니다.