웹 아키텍처는 단순히 클라이언트와 서버가 직접 연결되는 구조로 끝나지 않는다. 실제 서비스에서는 다양한 네트워크 경계, 보안 요건, 프로토콜 차이를 넘기 위해 중간 장치(intermediary)들이 존재한다. 이번 장에서 다루는 게이트웨이, 터널, 릴레이는 그런 통합점 역할을 한다. 각각은 모두 “중간에서 요청을 이어주는 역할”을 하지만 왜 존재하는지와 어떻게 동작하는지에 따라 성격이 달라진다.
게이트웨이(Gateway)
게이트웨이는 말 그대로 다른 세상으로 들어가는 관문이다. 클라이언트가 직접 접근할 수 없는 서버에 대신 접근해주는 서버 역할을 하며 단순 중계기 이상의 변환기 기능을 수행한다.
특징
게이트웨이는 클라이언트와 서버 사이에서 프로토콜을 변환하거나 보안 정책을 적용한다. 예를 들어, 클라이언트가 HTTP만 이해할 수 있는데 서버는 FTP만 지원한다면 게이트웨이가 HTTP 요청을 FTP로 변환해 서버에 전달하고 다시 HTTP 응답으로 바꿔 클라이언트에게 전달한다. 클라이언트 입장에서는 게이트웨이가 최종 서버처럼 보이므로 내부 구조를 알 필요가 없다. 또한 방화벽 뒤에 숨겨진 서버를 외부로부터 직접 노출하지 않고 게이트웨이가 대신 요청을 처리하도록 하여 보안 경계를 만든다.
게이트웨이는 종종 대리 서버(surrogate)로 불리며 서버 측 게이트웨이(리버스 프록시)는 요청을 내부 서버로 분산시키고 클라이언트 측 게이트웨이는 서로 다른 프로토콜을 변환하는 역할을 한다.
예시
1. HTTP → FTP 게이트웨이
클라이언트가 HTTP로 ftp://files.example.com 자원을 요청하면 게이트웨이는 FTP 서버와 통신하여 응답을 HTTP로 변환 후 반환한다.
2. 리버스 프록시(Reverse Proxy)
www.example.com 게이트웨이가 내부적으로 app01:8080, app02:8080 같은 서버로 요청을 분산한다.
게이트웨이 구조
[Client] --HTTP--> [Gateway] --FTP--> [FTP Server]터널(Tunnel)
터널은 중간을 열어주는 뚫린 파이프 같은 존재다. 게이트웨이처럼 데이터를 변환하지 않고, 릴레이처럼 메시지를 단순히 복사해서 전달하지도 않는다. 오히려 데이터를 아예 열어보지도 않고 그대로 목적지까지 통과시킨다.
터널은 보통 임시적인 연결로 유지되며 요청이 끝나면 닫힌다. 터널이 열려 있는 동안 프록시는 단순히 데이터를 전달만 하므로 캐싱, 로그 분석, 접근 제어 같은 HTTP 레벨 기능은 사용할 수 없다는 제약이 있다.
특징
터널은 주로 보안이 중요한 환경에서 사용된다. 가장 대표적인 사례는 HTTPS다. 클라이언트가 프록시 서버를 통해 HTTPS 연결을 하고 싶을 때 CONNECT 메서드를 사용해 “나와 목적지 서버 사이에 터널을 뚫어 달라”고 요청한다. 프록시는 단순히 TCP 연결을 만들어주고 그 이후의 SSL/TLS 암호화 통신은 클라이언트와 서버가 직접 수행한다. 이 구조 덕분에 프록시는 암호화된 내용을 볼 수 없으며 프라이버시와 무결성이 보장된다.
예시
클라이언트가 CONNECT www.bank.com:443 HTTP/1.1 요청을 보내면 프록시는 200 Connection Established로 응답하고 그 순간부터는 클라이언트와 은행 서버 간에 암호화된 데이터가 그대로 흐른다. 이때 프록시는 파이프 역할만 하며 안을 들여다볼 수 없다. 결과적으로 터널은 보안이 중요한 상황에서 반드시 필요한 존재다.
클라이언트가 은행 서버와 HTTPS 연결을 원할 때
CONNECT www.bank.com:443 HTTP/1.1
Host: www.bank.com:443프록시 응답
HTTP/1.1 200 Connection Established터널 구조
[Client] ==암호화된 데이터== [Proxy Tunnel] ==암호화된 데이터== [Server]릴레이(Relay)
릴레이는 단순 중계기다. 프록시와 비교했을 때 특별한 부가 기능이 없고 그저 받은 메시지를 거의 그대로 옆으로 전달하는 역할을 한다.
특징
릴레이는 메시지를 가공하지 않기 때문에 캐싱, 필터링, 인증 같은 부가 기능을 제공하지 않는다. 따라서 설계가 단순하고 구현도 쉽지만 복잡한 웹 서비스보다는 SMTP, NNTP 같은 과거의 메시지 기반 프로토콜에서 더 많이 쓰였다. HTTP 환경에서는 프록시가 대부분 릴레이의 역할까지 대체했기 때문에 오늘날 릴레이는 거의 역사적인 개념으로 남아 있다.
릴레이는 흔히 맹목적 포워더(blind forwarder)라고 불리며 메시지를 거의 그대로 전달한다. 다만 필요에 따라 Date나 Via 같은 hop-by-hop 헤더만 최소한으로 수정한다.
예시
메일 서버 체인을 떠올리면 이해하기 쉽다. 사용자가 보낸 메일은 여러 릴레이 서버를 거쳐 최종 목적지로 전달된다. 각 릴레이 서버는 단순히 메일을 다음 hop으로 전달할 뿐 내용을 해석하거나 변환하지 않는다. 이는 일종의 우편 집배원과 비슷하다.
메일 릴레이 체인
[Mail Client] → [Relay #1] → [Relay #2] → [Relay #3] → [Destination Server]게이트웨이, 터널, 릴레이 비교
| 구분 | 게이트웨이 | 터널 | 릴레이 |
|---|---|---|---|
| 역할 | 프로토콜 변환, 보안 경계 | 단순 연결 파이프 | 단순 메시지 전달 |
| 동작 방식 | 요청을 변환/처리 후 전달 | 바이트 스트림 그대로 전달 | 메시지를 거의 그대로 전달 |
| 사용 예 | HTTP-FTP 변환, 방화벽 우회 | HTTPS, SSL 연결 | SMTP/NNTP 중계 |
| 인식 | 최종 서버처럼 보임 | 그냥 통로 | 단순 중계 노드 |
| 제약 | 보안/부하 증가 | HTTP 기능 불가 | 기능 없음 |
📝 배운점
이번 장을 통해 단순히 프록시라는 하나의 개념으로 뭉뚱그려 생각했던 중간 서버들이 사실 역할에 따라 세밀하게 구분된다는 걸 알게 되었다.
- 게이트웨이는 세상을 이어주는 통역사이자 때로는 대리 서버(surrogate)로 동작하며 클라이언트는 실제 서버를 보지 못하고 게이트웨이만 상대한다.
- 터널은 투명한 파이프 역할로, 특히 HTTPS 환경에서 신뢰성과 프라이버시를 보장하는 핵심이다. 터널이 없으면 오늘날의 안전한 온라인 금융 서비스는 불가능했을 것이다. 다만 터널이 열려 있는 동안에는 프록시 기능(캐싱, 로깅, 제어)을 활용할 수 없다는 제약도 따른다.
- 릴레이는 맹목적 포워더로서 오늘날에는 자주 쓰이지 않지만, 인터넷 초창기 시절 다양한 메시지 프로토콜을 이어주던 중요한 구성 요소였다.
즉, HTTP 아키텍처에서의 중간 서버들은 단순히 트래픽을 우회하는 장치가 아니라 보안, 확장성, 프로토콜 호환성을 책임지는 필수 요소라는 점을 다시 깨닫게 되었다. 앞으로 시스템 설계를 할 때 “이 중간 지점에서 어떤 역할이 필요한가?”라는 관점에서 게이트웨이, 터널, 릴레이를 적절히 구분해 적용해야 한다고 느꼈다.
