로드밸런서 (L4 vs L7, 세션 관리, HAProxy)

L4 vs L7, 세션 관리, HAProxy

처음 서버를 두 대로 늘리던 날, 저는 완전히 예상 밖의 문제를 맞닥뜨렸습니다. 트래픽은 잘 분산되는데 로그인이 요청마다 풀리는 겁니다. 로드밸런서를 단순히 "트래픽을 나눠주는 장치"로만 생각했던 게 문제였습니다. 이 글은 그 경험을 바탕으로 L4와 L7의 차이, 그리고 세션 관리 전략까지 실제로 써보며 느낀 것들을 정리한 내용입니다.

L4 vs L7, 뭐가 다른가

로드밸런서는 OSI 모델에서 어느 계층에서 동작하느냐에 따라 크게 두 가지로 나뉩니다. 여기서 OSI 모델이란 네트워크 통신을 7개 계층으로 분류한 표준 모델로, L4는 4번째 전송 계층, L7은 7번째 응용 계층에 해당합니다.

L4 로드밸런싱은 TCP/UDP 수준에서 소스·목적지 IP와 포트 정보만 보고 트래픽을 분산합니다. 패킷 내부 내용을 들여다보지 않기 때문에 처리 속도가 매우 빠르고, HTTP든 게임 소켓이든 프로토콜에 관계없이 작동합니다. AWS NLB나 Linux IPVS가 대표적인 구현체입니다.

반면 L7 로드밸런싱은 HTTP/HTTPS 연결을 직접 종료한 뒤, URL 경로·헤더·쿠키·HTTP 메서드 같은 애플리케이션 계층 정보를 분석해 라우팅을 결정합니다. 여기서 SSL 종료(SSL termination)란 클라이언트와 로드밸런서 사이의 암호화 구간을 로드밸런서에서 끊어내고, 내부 서버와는 평문으로 통신하는 방식을 말합니다. 덕분에 /api 경로는 API 서버로, /static 경로는 CDN으로 분기하는 콘텐츠 기반 라우팅이 가능해집니다. NGINX, HAProxy의 L7 모드, AWS ALB가 여기에 해당합니다.

"L7이 기능이 많으니 무조건 L7 쓰면 되는 거 아닌가"라고 생각하는 분들도 있는데, 저는 그 시각에 조금 다른 입장입니다. L7은 HTTP 파싱과 SSL 종료에 CPU를 소모하기 때문에, 초당 수십만 패킷을 처리해야 하는 게임 서버나 실시간 스트리밍 환경에서는 L4 방식이 오히려 더 적합할 수 있습니다. 실제로 많은 프로덕션 시스템이 L4와 L7을 조합한 하이브리드 구조를 채택합니다. TCP 대용량 트래픽은 L4로 받고, HTTP 기반 세밀한 라우팅은 L7에서 처리하는 방식입니다.

분산 알고리즘도 선택이 갈리는 지점입니다. 제가 처음 접했던 것은 Round Robin이었는데, 이는 서버에 순서대로 요청을 균등하게 배분하는 방식으로 모든 서버 성능이 비슷할 때 무난합니다. 하지만 처리 시간이 들쭉날쭉한 환경이라면 현재 연결 수가 가장 적은 서버로 보내는 Least Connections 방식이 더 효율적입니다. 주요 알고리즘을 정리하면 다음과 같습니다.

• Round Robin: 순서대로 균등 배분. 서버 스펙이 동일할 때 기본 선택지
• Least Connections: 현재 활성 연결이 가장 적은 서버 우선. 응답 시간 편차가 클 때 유리
• IP Hash: 클라이언트 IP를 해시해 항상 같은 서버로 연결. 세션 유지가 중요한 환경에 사용
• Least Response Time: 응답 속도가 가장 빠른 서버를 선택. 성능 편차가 있는 이기종 서버 환경에 적합

HAProxy 공식 문서에 따르면 이 알고리즘들은 백엔드 특성에 따라 성능 차이가 크게 벌어질 수 있어, 서비스 성격에 맞는 선택이 중요합니다(출처: HAProxy 공식 문서).

세션 관리와 HAProxy, 직접 겪어봐야 아는 것들

제가 직접 써봤는데, NGINX upstream에 두 서버를 Round Robin으로 등록하고 나서 얼마 지나지 않아 민원이 들어왔습니다. 로그인이 자꾸 풀린다는 것이었습니다. 세션 정보가 각 서버의 로컬 파일 시스템에 저장되어 있었기 때문에, 요청이 다른 서버로 넘어가는 순간 세션을 찾지 못하는 문제였습니다.

해결 방안으로 두 가지를 검토했습니다. 첫 번째는 NGINX의 ip_hash 디렉티브를 적용하는 것이었습니다. IP Hash 방식은 클라이언트 IP를 기반으로 해시값을 계산해 항상 같은 서버로 연결을 고정하는 방식입니다. 구현이 단순하다는 장점이 있지만, 클라이언트 다수가 NAT(Network Address Translation) 뒤에 있을 경우, 즉 여러 사용자가 하나의 공인 IP를 공유할 경우 특정 서버에 트래픽이 몰릴 수 있다는 단점이 있습니다.

두 번째는 Redis 세션 스토어를 도입하는 것이었습니다. Redis란 메모리 기반의 키-값 저장소로, 세션 데이터를 모든 서버가 공유할 수 있게 중앙화하는 역할을 합니다. 결국 저는 Redis를 선택했고, 이후 어느 서버로 요청이 가든 동일한 세션 데이터를 참조할 수 있게 됐습니다. 이 경험에서 배운 게 있다면, 로드밸런싱은 트래픽을 나누는 설정 하나로 끝나는 게 아니라 애플리케이션 상태 관리 전략과 함께 설계해야 한다는 점입니다.

이후 HAProxy를 도입하면서 또 다른 가치를 발견했습니다. HAProxy의 헬스 체크(health check) 기능인데, 이는 로드밸런서가 주기적으로 백엔드 서버의 상태를 확인해 응답이 없는 서버를 자동으로 풀(pool)에서 제외하는 기능입니다. 솔직히 이건 예상 밖이었습니다. 테스트 중에 서버 한 대를 강제로 종료했더니, 별도의 개입 없이 HAProxy가 해당 서버를 제거하고 나머지 서버로 트래픽을 자동 이전하는 걸 실시간으로 확인했습니다. 그 순간 "이래서 HAProxy 쓰는 구나"를 실감했습니다.

HAProxy stats 페이지도 운영 관점에서 매우 유용합니다. 초당 요청 수, 에러율, 활성 연결 수를 별도 도구 없이 브라우저에서 바로 확인할 수 있어서, 장애 대응 시간이 눈에 띄게 줄었습니다. HAProxy와 NGINX를 비교하는 시각도 있는데, 제 경험상 HAProxy는 원시 성능과 세밀한 제어가 필요한 환경에, NGINX는 설정이 단순하고 정적 콘텐츠 서빙까지 함께 처리해야 할 때 더 어울립니다.

클라우드 환경으로 넘어가면 이야기가 조금 달라집니다. Kubernetes 환경에서는 Ingress Controller가, 서비스 메시 환경에서는 Envoy나 Istio가 기존 로드밸런서의 역할을 상당 부분 흡수하는 추세입니다. OneUptime의 분석에 따르면 L4와 L7의 경계가 클라우드 네이티브 환경에서 점점 서비스 레이어 안으로 내재화되고 있습니다(출처: OneUptime).

로드밸런서를 처음 설정할 때는 "그냥 트래픽 분산 장치"로 가볍게 봤다가 세션 문제로 꽤 고생했습니다. 지금 생각해보면 그 시행착오가 가장 빠른 공부였습니다. HAProxy든 NGINX든 AWS ALB든, 도구 선택 전에 내 서비스의 상태 관리 구조를 먼저 파악하는 것이 순서라고 봅니다. 온프레미스 환경의 HAProxy와 NGINX를 한 번이라도 직접 다뤄본 경험이 있다면, 클라우드 관리형 로드밸런서를 쓸 때도 내부 동작이 훨씬 명확하게 보입니다.

---

참고:

• OneUptime — L4 vs L7 Load Balancing: https://oneuptime.com/blog/post/2026-01-27-load-balancing-l4-vs-l7/view
• LogicMonitor — What Is HAProxy: https://www.logicmonitor.com/blog/what-is-haproxy-and-what-is-it-used-for
• TechInterview.org — Load Balancer Architecture: https://www.techinterview.org/post/3233474140
• Xurrent — Top Load Balancers 2026: https://www.xurrent.com/blog/top-load-balancers
• HAProxy 공식 문서: https://www.haproxy.org/download/2.9/doc/configuration.txt