프록시(Proxy)와 로드밸런서(Load Balancer), L4/L7 한 번에 비교 정리

업무하다 보면 인프라와 관련한 여러 가지 용어가 들린다.

프록시, 로드밸런서, L4/L7, 게이트웨이 등등...

무시하기 힘든 위 용어들이 더 어렵게 느껴지는 이유는

서로 다른 축(관점)의 용어가 한 문장에 섞여 쓰이기 때문이었다. 차례대로 정리해 보자.

---

각 개념들의 분류

일단 자주 들리는 각 개념들을 분류해 보자.

각 항목이 무엇을 의미하고 어떤 역할을 하는지는 순서대로 풀어 보겠다.

객체	관점	내용
L4/L7	능력/계층	판단 기준이 무엇인가?
LB/Proxy/Gateway/Ingress	역할/기능	무슨 역할을 하는가?

 

 

Load Balancer, Proxy 에서의 L4 vs L7

로드밸런서(Load Balancer, LB)나 프록시(Proxy)가 무엇인지를 얘기하기 전에 함께 자주 사용되는 용어를 알아보자.

이 L4나 L7 앞에 붙은 'L'은 'Layer'를 의미한다. 학교 다닐 때 봤었던 OSI 7계층에서 말하는 그 계층이 맞다. 쉽게 말해, L4/L7은 "OSI에서의 4층/7층 관점에서의 동작"에 해당하는 개념이다.

(TCP/IP 모델을 쓴다고 해도 "L4/L7" 같은 표현은 계속 OSI 용어로 살아있는 것 같다)

객체	어떤 내용을 보고 판단하는가?
L4 기반(전송)	1. IP + TCP/UDP + 포트(Port) 정도까지만 보고 분산/중계 2. HTTP 내용(URI, 헤더 등)은 보통 해석하지 않음
L7 기반(응용)	L4 기능 + HTTP 요청 정보(Host/Path/Header/Cookie 등)까지 확인 및 조작 가능 예) /api는 서비스1, /auth는 서비스2 또는 api.example.com 이면 A로, web.example.com 이면 B로

가장 헷갈렸던 점은 LB(Load Balancer)랑 L4가 혼용되어서 언급되다 보니까, 자연스럽게 L4 = LB 인걸로 넘어갔었다.

 

L4는 LB에 딱 맞는 최소 기능이었기에 전통적으로 L4 장비를 쓰는 게 매우 일반적이었어서 그런 거라고는 하지만, 어쨌든 공부하는 입장에서 위 표처럼 굳이 따지고 보면 로드밸런서는 기능(부하 분산)이고, L4/L7은 판단 기준(어디까지 해석하느냐) 또는 방식에 가깝다. "무엇을 보고 라우팅/제어하느냐"가 핵심인 것이다.

 

참고로 L7은 HTTP(URI, 헤더, 쿠키 등)를 이해(해석)하기 때문에 정책/라우팅이 풍부하다는 장점이 있지만 더 강력한 만큼 비용/복잡도가 크다는 특징이 있다. 그래서 인증/인가 연계/캐시 등의 애플리케이션 레벨인 Ingress나 게이트웨이(Gateway)로써의 기능은 L7이 더 쓰이게 된다고 한다. 포인트는 위와 같은 이유로 LB 얘기하면 L4가 더 자주 나오긴 하지만, 로드밸런서든 프록시든 기능(역할)은 일의 범위가 달라질 뿐 'L4 방식'으로도, 'L7 방식'으로도 구현될 수 있다는 것이다.

 

 

프록시(Proxy) 와 로드밸런서(Load Balancer, LB)

프록시(Proxy)의 뜻을 영어사전에 찾아보면 "대리인"이다. 무엇을 대신할까?

네트워크 적으로 이 단어는 '클라이언트와 서버 사이에서 요청/응답을 대신 받아서! 대신 통신!'한다는 의미이자 역할을 나타낸다. 즉, 요청이 처음부터 끝까지 클라이언트와 서버가 "직접 붙어 통신"을 완료하는 것 대신 중간에 "Proxy를 거쳐 통신"하게 만드는 구성이라는 것이다.

 

이런 구성의 필요 이유이자 주된 목적 중 하나는 바로 프록시를 앞세워서 요청 출발지로부터 목적지의 IP 등을 숨기기/추상화하는 것이고, 여기에 라우팅·보안같은 정책을 얹기 좋기 때문이다. API 요청을 예시로 보면 Proxy가 중간에서 내부 서버로 포워딩해주기 때문에 클라이언트는 실제 백엔드 서버 자원의 실제 IP나 어떤 구성으로 되어있는지를 알 수 없게 되고 또 몰라도 되게 된다.

 

그리고 다음으로 로드밸런서(Load Balancer)는 사전에 찾아보면.. 없지만 어쨌든 들어오는 트래픽을 여러 엔드포인트(서버)로 분산해 처리량/가용성을 높이는 역할을 한다고 정의된다. 정리하면 둘 모두 "앞에서 요청을 대신 받아서 뒤로 보낸다"는 형태는 비슷하지만 의도가 다른 것이다.

1. 프록시= 대리인(정책/통제 중심)이자 문지기/통제자
2. 로드밸런싱 = 분배기(성능/가용성 중심)

하지만 현실적으로 한 제품이 두 기능을 다 하는 경우가 많아 그게 그거인 상황이라 더 헷갈리는 것이었다.

표로 정리해봤다.

구분	Proxy(프록시)	Load Balancer(로드밸런서)
핵심 목적	요청을 '거쳐가게' 만들어서 정책을 걸기 좋다. 클라이언트와 서버 사이에서 대신 통신하며 통제/보안/변환한다.	여러 서버로 트래픽을 분산해 처리량/가용성 확보. 즉, 부하를 분산해서 서비스가 버티게 한다.
중심 질문	요청/응답에서 무엇을 숨기고(노출을 줄이고)/어떤 정책을 적용할까?	어느 서버에 얼마나 나눠 보낼까
대표 기능	헤더/경로 변환, 인증 연계, 캐시, (L7에서) WAF	분산, 장애 서버 제외, 정책 기반 라우팅(IP/Port/경로/호스트 등)
관계	Proxy는 LB 기능(분산)을 포함할 수 있음 (L4/L7 모두 가능)	LB는 Proxy 형태로 동작할 수 있음 (L4/L7 모두 가능)

이처럼 LB가 Proxy처럼 동작하거나 프록시가 LB 기능(분산)을 포함하는 경우가 일반적이다.

그래서 아키텍처를 이해하고자 할 때 "Proxy냐 LB냐?"보다 이 컴포넌트는 L4에서 분산하는지, L7에서 라우팅/정책까지 하는지를 봐보려고 하면 조금 더 도움이 될 것 같다.

 

 

Reverse Proxy와 Forward Proxy의 차이

프록시의 기능을 '직접 통신' 대신 '프록시를 거쳐 통신'하게 만드는 구성이라고 했었다.

근데 Proxy만큼 Reverse Proxy라는 표현도 함께 자주 들리곤 한다. 이유는 운영에서 Proxy라고 말할 때 이는 곧 리버스 프록시(Reverse Proxy)를 지칭하는 일이 많기 때문이다.

Reverse Proxy와 Forward Proxy의 구분 핵심은 "클라이언트 ↔ 서버 사이 경로에서 누굴 대신하느냐(누굴 숨기느냐)"이다.

구분	Reverse Proxy(리버스 프록시)	Forward Proxy(포워드 프록시)
구분 방법	서버(서비스) 측 네트워크 앞단에 붙어서 외부 클라이언트 요청이 내 서비스로 들어올 때 먼저 프록시가 받고 내부 서버로 전달합니다.	클라이언트(사용자) 측 네트워크에 붙어서 클라이언트가 외부 서버로 나갈 때 프록시가 대신 요청을 보냅니다.
예시	클라이언트 입장에서는 '뒤에 실제 서버들이 여러 대/여러 개'인 것을 몰라도 됨 (서버가 숨겨짐) 예) 사용자는 www.example.com만 알면 되고, 뒤에는 프록시 역할을 하는 Nginx/Ingress가 여러 서비스로 나눠준다.	사용자별 인증/감사 로그, 사내망에서 인터넷 접근 통제 등 예) 회사 PC로는 직접 google.com 시도하려고 하면 회사의 포워드 프록시 정책에 의해 접속 불가.

쉽게 말해서, Reverse Proxy는 밖(클라이언트)이 내 서비스로 들어올 때의 문지기/분배기이고, Forward Proxy는 '내(클라이언트)가 밖으로 나갈 때 대리인'으로 이해하면 쉽다.

 

정리하면, LB/Proxy 같은 용어는 "무슨 역할을 하느냐" 이고 L4/L7은 "무엇을 보고 판단하느냐"이다.

다음 글에서는 같은 관점으로 클라우드 환경에서 자주 쓰이는 Ingress/Gateway/WAF 등의 개념들을 이어서 정리해 보겠습니다.