L4 vs L7 로드밸런서 — 패킷을 어디까지 여는가

L4, L7 을 로드밸런서의 종류로 외우면 헷갈립니다. 이건 결정을 내리려고 패킷을 얼마나 열어보느냐의 차이입니다. 그 한 가지에서 나머지가 전부 따라 나옵니다.

얼마나 열어보느냐로 갈리는 계층

L3  →  IP 주소만 본다          →  어느 서버로 (라우팅)
L4  →  IP + Port + Protocol   →  어느 프로세스로 / 통과시킬까
L7  →  HTTP 헤더 · URL · Body  →  어떤 조건으로 어디로 보낼까

L4 는 IP 와 포트까지만 보고 그 안의 HTTP 헤더나 URL 은 안 여는 반면, L7 은 그 위로 HTTP 메서드·Host·경로·쿠키까지 열어서 봅니다.

결정적 차이 — L7의 연결 종료·재수립

• L4 — 들어온 TCP 연결을 그대로 백엔드로 넘깁니다(포워딩/NAT). 연결이 클라이언트와 서버 사이에 계속 이어집니다.
• L7 — 클라이언트의 TCP 연결을 자기가 종료하고, 백엔드로 새 연결을 맺습니다. 중간에서 프록시로 앉는 겁니다.

이 하나에서 두 가지가 따라 나옵니다.

TLS passthrough 는 L4 만 됩니다. L7 은 라우팅하려면 HTTP 를 봐야 하고, HTTPS 면 내용을 봐야 하니 반드시 TLS 를 종료(복호화)합니다. 암호화된 채로 뒤로 넘기는 passthrough 는 L4 만 할 수 있습니다.

클라이언트 IP 가 보이는 방식이 다릅니다. L4 는 연결을 그대로 넘기니 서버가 클라이언트의 실제 IP 를 직접 봅니다. L7 은 연결을 새로 맺으니, 서버가 보는 소스 IP 는 로드밸런서의 IP 입니다. 원래 IP 는 X-Forwarded-For 헤더에 실려 옵니다.

AWS로 보면

	NLB (L4)	ALB (L7)
보는 것	IP·포트·프로토콜	+ HTTP Host·경로·헤더
TLS	passthrough 가능	반드시 종료
클라이언트 IP	서버가 직접 확인	X-Forwarded-For
라우팅	4-튜플 기반	Host·경로·헤더 기반
속도	극저지연(거의 안 엶)	파싱·복호화만큼 느림

ALB 뒤의 nginx 에서 진짜 클라이언트 IP 를 로그에 남기려면 real_ip_header 를 X-Forwarded-For 로 잡아야 합니다. 안 그러면 $remote_addr 에 ALB 내부 IP 만 찍힙니다.

그래서 무엇을 고르나

• DB 커넥션·고정 IP 화이트리스트·mTLS passthrough → L4(NLB). 내용을 안 봐도 되고, 원본 IP·암호화를 그대로 보존해야 하는 경우.
• Host/경로 기반 HTTP 라우팅·WAF 연동 → L7(ALB). 요청 내용으로 분기해야 하는 경우.

결국 “내용을 봐야 하느냐” 로 먼저 가르면 되는데, 봐야 하면 L7 이고 안 봐도 되면 L4 입니다. L7 이 더 많은 걸 해 주는 대신 연결을 끊고 복호화하는 비용과 passthrough 불가라는 제약이 따라옵니다.