프록시와 로드 밸런싱

프록시(proxy)는 클라이언트와 서버 사이에서 요청과 응답을 대신 전달하는 중간 서버다. 클라이언트 편에 서면 포워드 프록시(forward proxy), 서버 편에 서면 리버스 프록시(reverse proxy)라고 부른다. 서비스 규모가 커지면 서버 여러 대 앞에 요청을 나눠 주는 로드 밸런서(load balancer)를 두는데, 요청의 어느 층까지 보고 나누느냐에 따라 4계층과 7계층으로 갈린다.

한눈에 보는 구성

다이어그램 로딩…

포워드 프록시와 리버스 프록시

두 프록시는 하는 일이 비슷해 보이지만 누구를 대신하느냐가 다르다.

기준	포워드 프록시	리버스 프록시
서는 쪽	클라이언트 쪽	서버 쪽
누구를 숨기나	클라이언트	뒤쪽 서버
쓰는 곳	사내망 인터넷 출구, 접속 제한	웹 서비스 입구
예	기업·학교 프록시	nginx, 클라우드 로드 밸런서

포워드 프록시는 클라이언트 대신 외부 서버에 요청하는 프록시다. 조직은 모든 인터넷 요청을 이 프록시로 보내게 해서 접속할 수 있는 사이트를 제한하거나 기록을 남긴다. 외부 서버 입장에서는 요청이 프록시에서 온 것으로 보이므로, 클라이언트의 실제 주소가 드러나지 않는다.

리버스 프록시는 서버 앞에 서서 클라이언트 요청을 받아 뒤쪽의 실제 서버로 넘겨 주는 프록시다. 클라이언트는 리버스 프록시만 보고, 그 뒤에 서버가 몇 대인지 어디에 있는지 모른다. 그래서 뒤쪽 서버를 바꾸거나 늘려도 클라이언트 쪽은 달라질 것이 없다.

리버스 프록시가 해 주는 일

리버스 프록시는 모든 요청이 지나는 입구라서, TLS(Transport Layer Security, 전송 계층 보안) 암호화를 푸는 일처럼 서버마다 따로 하던 공통 작업을 한곳에 모을 수 있다.

• TLS 종료: HTTPS(HTTP Secure, 보안 HTTP) 연결의 암호화를 리버스 프록시에서 풀고, 뒤쪽 서버와는 내부망에서 암호화하지 않은 평문(plaintext)이나 별도 암호화로 통신한다. 인증서(certificate)를 프록시 한곳에서만 관리하면 되고, 뒤쪽 서버는 암호 계산 부담을 덜어 낸다.
• 캐시(cache): 자주 요청되는 응답을 프록시에 저장해 두고 뒤쪽 서버까지 가지 않고 바로 돌려준다.
• 압축: 응답을 gzip 같은 방식으로 압축해 전송량을 줄인다.
• 보안과 제한: 뒤쪽 서버의 주소를 숨기고, 초당 요청 수를 제한하거나 악성 요청을 걸러 낸다.

프록시를 거치면 뒤쪽 서버에는 모든 요청이 프록시 주소에서 온 것으로 보인다. 그래서 리버스 프록시는 원래 클라이언트의 IP(Internet Protocol, 인터넷 프로토콜) 주소를 X-Forwarded-For 같은 헤더(header)에 담아 넘긴다. 뒤쪽 서버는 이 값으로 접속 기록을 남기고, 사용자별로 요청 수를 제한한다.

로드 밸런서

로드 밸런서는 들어오는 요청을 여러 서버에 나눠 보내 한 서버에 부하가 몰리지 않게 하는 장비나 소프트웨어다. 리버스 프록시의 대표적인 쓰임이기도 하다. 서버 한 대가 죽어도 나머지가 요청을 받으므로, 부하 분산과 함께 장애 대비 효과가 있다.

로드 밸런서는 요청의 어느 층까지 보고 판단하느냐에 따라 둘로 나뉜다. 기준은 OSI(Open Systems Interconnection, 개방형 시스템 상호 연결) 모델의 계층 번호다. 4계층은 연결과 포트(port) 번호를 다루는 전송 계층(transport layer)이고, 7계층은 HTTP 같은 요청 내용을 다루는 응용 계층(application layer)이다.

4계층 로드 밸런서는 TCP(Transmission Control Protocol, 전송 제어 프로토콜)나 UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜) 연결 단위로 IP 주소와 포트만 보고 서버를 고른다. 7계층 로드 밸런서는 HTTP 메시지를 해석해 경로나 쿠키(cookie)에 따라 서버를 고른다. 대신 메시지를 읽어야 하므로 할 일이 더 많다.

기준	4계층(L4)	7계층(L7)
보는 정보	IP 주소, 포트, TCP·UDP	URL 경로, 헤더, 쿠키
판단 예	443번(HTTPS) 포트로 온 연결을 서버 A·B에 나눔	/api는 API 서버로, /img는 이미지 서버로
장점	내용을 안 봐서 빠르다	요청 내용에 따라 세밀하게 나눈다
조건	TLS를 풀지 않고 암호화된 채로 넘긴다	HTTPS면 TLS를 풀어야 내용을 본다

이어지는 내용은 프록시와 로드 밸런싱 2에서 다룬다. 로드 밸런서가 서버를 고르는 방식과 장애 서버를 빼는 방법, 서버를 늘릴 때 로그인 상태를 지키는 방법, 사용자 가까이에 사본을 두는 방식을 본다.

면접 포인트

• "포워드 프록시와 리버스 프록시 차이는?" → 포워드는 클라이언트 대리(클라이언트 숨김·접속 통제), 리버스는 서버 대리(서버 숨김·TLS 종료·캐시·분산).
• "리버스 프록시 뒤의 서버는 클라이언트 IP를 어떻게 아나요?" → 프록시가 원래 IP를 X-Forwarded-For 같은 헤더에 담아 넘긴다.
• "L4와 L7 로드 밸런싱 차이는?" → L4는 IP·포트만 보고 빠름, L7은 URL·헤더·쿠키까지 보고 세밀하지만 TLS를 풀어야 함.