ALBNLBCLBAWS로드밸런서ELB트래픽고가용성

AWS 로드밸런서 완전 정복: CLB, ALB, NLB — 트래픽 분배의 모든 것

서버 1대로 버티던 시절은 끝났다. 사용자가 늘면 서버를 늘려야 하고, 서버를 늘리면 트래픽을 나눠야 한다. CLB에서 ALB, NLB까지 — 로드밸런서의 역사, 작동 원리, 세 가지 타입의 차이, 실전 선택 가이드를 비유와 사례로 풀어본다.

코어닷투데이2026-02-2528분

들어가며: 서버 1대로는 버틸 수 없다

서비스가 성장하면 반드시 만나는 벽이 있다. 단일 서버의 한계.

웹 서버 1대가 동시에 처리할 수 있는 요청은 한정적이다. Node.js 서버라면 수천 건, Java 서버라면 수백 건. 사용자가 그 이상 몰리면 응답이 느려지다가, 결국 서버가 죽는다.

해법은 두 가지다:

수직 확장(Scale Up): 서버를 더 크고 강력한 것으로 교체 (CPU 4코어 → 32코어)
수평 확장(Scale Out): 같은 서버를 여러 대로 늘리고, 트래픽을 분배

수직 확장에는 한계가 있다 (세상에서 가장 큰 서버도 한계가 있다). 수평 확장이 클라우드 시대의 표준이다. 그런데 서버가 5대가 됐다면 — 사용자의 요청을 어떤 서버로 보내야 할까?

이것이 로드밸런서(Load Balancer) 의 역할이다.

1. 로드밸런서의 역사

하드웨어 로드밸런서 시대 (1990~2000년대)

인터넷 초창기, 대형 웹사이트들은 전용 하드웨어 로드밸런서를 사용했다. F5 Networks의 BIG-IP, Citrix의 NetScaler 같은 물리 장비를 데이터센터에 설치했다.

수천만~수억 원 하드웨어 LB 가격 F5 BIG-IP 엔터프라이즈

수 주 도입 소요 시간 구매 → 설치 → 설정

전문 인력 운영 요구 F5 자격증 보유자

소프트웨어 로드밸런서 (2000년대~)

HAProxy(2000)와 NGINX(2004)가 소프트웨어 로드밸런서의 시대를 열었다. 일반 서버에 설치하여 로드밸런싱이 가능해졌다. 비용은 대폭 줄었지만, 여전히 직접 설치·설정·관리해야 했다.

AWS Elastic Load Balancing (2009~)

2009년, AWS가 Elastic Load Balancing(ELB) 을 출시했다. 관리형 로드밸런서 — 설치·패치·확장을 AWS가 알아서 한다.

2009

Classic Load Balancer (CLB)

AWS 최초의 관리형 LB. L4+L7 기본 기능. 단순하지만 제한적

2016.8

Application Load Balancer (ALB)

HTTP/HTTPS 전문. 경로·호스트 기반 라우팅, WebSocket, HTTP/2 지원

2017.9

Network Load Balancer (NLB)

초고성능 L4. 초당 수백만 요청, 마이크로초 지연, 고정 IP

2023~CLB 사용 중단 권고
AWS가 CLB 대신 ALB/NLB 사용을 공식 권장. 신규 생성 비권장

2. 로드밸런서의 작동 원리

L4 vs L7: OSI 모델로 이해하기

로드밸런서를 이해하는 핵심: 어떤 계층(Layer)에서 동작하는가.

L4 로드밸런서 (전송 계층)

TCP/UDP 수준에서 동작

IP 주소와 포트 번호만 봄

패킷 내용(HTTP 헤더 등)은 모름

매우 빠름 (단순한 판단)

비유: 우체국 — 주소만 보고 배달

L7 로드밸런서 (애플리케이션 계층)

HTTP/HTTPS 수준에서 동작

URL 경로, 헤더, 쿠키까지 봄

요청 내용 기반 라우팅 가능

L4보다 약간 느림 (더 많이 분석)

비유: 호텔 컨시어지 — 요청 내용을 이해하고 안내

헬스체크: 죽은 서버에 트래픽을 보내지 않기

로드밸런서의 가장 중요한 기능 중 하나: 헬스체크(Health Check).

주기적으로 백엔드 서버에 "살아있니?"를 물어본다. 응답이 없거나 에러를 반환하면 해당 서버를 목록에서 제외하고, 나머지 서버로만 트래픽을 보낸다. 서버가 복구되면 다시 목록에 추가한다.

ALB가 서버 A에 GET /health → 200 OK ✓

ALB가 서버 B에 GET /health → 200 OK ✓

ALB가 서버 C에 GET /health → 타임아웃 ✗

↓

서버 C를 제외하고 A, B에만 트래픽 분배

✅

헬스체크 실전 팁: /health 엔드포인트는 단순히 200을 반환하는 것이 아니라, DB 연결, 캐시 연결, 필수 의존성을 확인하고 응답해야 한다. 서버 프로세스는 살아있지만 DB 연결이 끊어진 경우, 단순 200 응답은 "정상"으로 판단해 장애 트래픽을 계속 보내게 된다.

3. CLB, ALB, NLB: 세 가지 로드밸런서 비교

Classic Load Balancer (CLB) — 원조, 하지만 은퇴 시기

2009년 출시된 AWS 최초의 로드밸런서. L4와 L7을 모두 지원하지만 기능이 제한적이다.

CLB의 한계:

하나의 CLB = 하나의 애플리케이션 (경로 기반 라우팅 불가)
WebSocket, HTTP/2 미지원
Lambda 타겟 불가
컨테이너(ECS)와의 통합이 제한적

AWS는 2023년부터 CLB 대신 ALB/NLB를 공식 권장하며, 신규 생성을 비권장한다.

Application Load Balancer (ALB) — 웹 서비스의 표준

2016년 출시. HTTP/HTTPS 트래픽에 특화된 L7 로드밸런서. 이 시리즈에서 계속 등장한 ALB가 바로 이것이다.

ALB의 핵심 기능:

1. 경로 기반 라우팅:

/api/*     → API 서버 타겟 그룹
/admin/*   → 관리자 서버 타겟 그룹
/static/*  → S3 (리다이렉트)
/*         → 웹 서버 타겟 그룹

하나의 ALB로 여러 서비스에 트래픽을 분배할 수 있다. CLB에서는 서비스마다 별도 LB가 필요했다.

2. 호스트 기반 라우팅:

api.example.com  → API 타겟 그룹
www.example.com  → 웹 타겟 그룹
admin.example.com → 관리 타겟 그룹

하나의 ALB에서 여러 도메인을 처리할 수 있다.

3. 다양한 타겟:

EC2 인스턴스
ECS 태스크 (Fargate 포함)
Lambda 함수
IP 주소 (온프레미스 서버 포함)

4. SSL/TLS 종료: HTTPS 암호화/복호화를 ALB에서 처리. 백엔드 서버는 HTTP로 통신하면 되므로, 서버의 CPU 부담이 줄어든다. ACM(AWS Certificate Manager)에서 무료 SSL 인증서를 발급하여 ALB에 연결.

5. 스티키 세션: 같은 사용자의 요청을 항상 같은 서버로 보내는 기능. 세션 기반 웹 앱에서 필요. (하지만 가능하면 세션을 서버 외부(Redis, DynamoDB)에 저장하는 것이 더 좋은 설계)

Network Load Balancer (NLB) — 극한의 성능

2017년 출시. TCP/UDP/TLS 트래픽에 특화된 L4 로드밸런서.

ALB와 NLB의 가장 큰 차이:

	ALB	NLB
계층	L7 (HTTP/HTTPS)	L4 (TCP/UDP/TLS)
성능	초당 수만 요청	초당 수백만 요청
지연시간	밀리초	마이크로초 (~100μs)
IP	동적 IP	고정 IP (Elastic IP 할당 가능)
SSL 종료	ALB에서	NLB에서 또는 백엔드에서
프로토콜	HTTP, HTTPS, WebSocket	TCP, UDP, TLS
콘텐츠 라우팅	경로, 호스트, 헤더 기반	포트 기반만
주요 용도	웹 API, 웹사이트	게임 서버, IoT, 금융 거래
비용	NLCU 기반	NLCU 기반 (보통 ALB보다 저렴)

💡

NLB의 고정 IP가 중요한 이유: 일부 시스템은 "이 IP에서 오는 트래픽만 허용"이라는 방화벽 규칙을 가지고 있다. ALB는 IP가 동적으로 바뀌므로 이런 규칙에 맞지 않는다. NLB는 Elastic IP를 할당하여 고정된 IP로 서비스할 수 있다. 금융 기관, 파트너 연동에서 자주 요구된다.

세 가지 LB 한눈에 비교

기준	CLB	ALB	NLB
출시	2009	2016	2017
계층	L4 + L7 (제한적)	L7	L4
경로 라우팅	✗	✓	✗
호스트 라우팅	✗	✓	✗
WebSocket	✗	✓	✓ (TCP)
HTTP/2	✗	✓	✗
gRPC	✗	✓	✓ (TCP)
고정 IP	✗	✗	✓
Lambda 타겟	✗	✓	✗
성능	낮음	중간	매우 높음
지연시간	ms	ms	μs
현재 상태	비권장	표준	특수 용도

4. 로드밸런서 선택 가이드

무엇을 로드밸런싱하는가?

↓

HTTP/HTTPS 웹 API → ALB

TCP (게임, IoT, gRPC) → NLB

UDP (DNS, 미디어) → NLB

고정 IP 필요 → NLB

극도의 저지연 필요 → NLB

Lambda를 타겟으로 → ALB

✅

80%의 답: 웹 서비스를 만들고 있다면 ALB가 정답이다. NLB는 TCP/UDP 프로토콜이 필요하거나, 고정 IP가 필수이거나, 초저지연이 요구되는 특수한 경우에만 사용한다. CLB는 더 이상 사용하지 마라.

5. 로드밸런서와 보안

DDoS 방어의 첫 번째 방어선

로드밸런서는 DDoS 공격의 첫 번째 방어선 역할을 한다. 모든 외부 트래픽이 LB를 거치므로, 여기서 악성 트래픽을 차단할 수 있다.

AWS Shield Standard: ALB/NLB에 무료로 통합. L3/L4 DDoS 자동 방어
AWS WAF: ALB에 연동하여 L7 공격(SQL 인젝션, XSS, 봇) 차단
Connection Draining: 서버를 안전하게 제거할 때 진행 중인 요청을 완료할 시간을 줌

로드밸런서 관련 보안 사고

2016

Dyn DNS DDoS 공격

Mirai 봇넷이 DNS 서비스 Dyn을 공격. Twitter, Netflix, GitHub 등 마비. LB 자체가 아닌 LB의 의존 서비스(DNS)가 공격 대상이 됨

2020

AWS ALB 취약점 (ALBeast)

ALB의 인증 기능 설정 미흡으로 인증을 우회할 수 있는 취약점 발견. AWS가 패치 및 가이드 업데이트

2023

HTTP/2 Rapid Reset 공격

HTTP/2 프로토콜의 취약점을 이용한 DDoS. ALB를 포함한 모든 HTTP/2 지원 LB가 영향. AWS가 자동 패치

🔒

보안 체크리스트: (1) ALB 리스너는 HTTPS(443)만 열고, HTTP(80)는 HTTPS로 리다이렉트, (2) 보안 그룹에서 ALB만 백엔드에 접근 가능하게 설정, (3) WAF를 ALB에 연동하여 L7 공격 방어, (4) 접근 로그를 S3에 활성화하여 감사 추적.

6. ALB 비용 구조

과금 요소

항목	비용 (서울)	설명
시간당 비용	$0.0252/시간 (~$ 18.14/월)	LB가 존재하는 시간
LCU (Load Balancer Capacity Unit)	$0.008/LCU-시간	실제 사용량 기반

LCU는 다음 4가지 중 가장 높은 값으로 계산된다:

새 연결 수 (초당 25)
활성 연결 수 (3,000)
처리 데이터 (1GB/시간)
규칙 평가 수 (1,000/초)

⚠️

비용 함정 — 사용하지 않아도 과금: ALB는 트래픽이 0이어도 시간당 $0.0252가 과금된다 (월 ~$18). 개발/테스트 환경에 ALB를 켜놓고 잊으면 매달 $18씩 나간다. 사용하지 않는 환경은 ALB를 삭제하거나, API Gateway(요청 없으면 비용 0)로 대체를 고려하라.

ALB vs API Gateway vs NLB 비용 비교

시나리오	ALB	API Gateway (HTTP)	NLB
기본 비용 (트래픽 0)	~$18/월	$0/월	~$18/월
월 100만 요청	~$19	~$1	~$18.5
월 1억 요청	~$25	~$100	~$20
월 10억 요청	~$80	~$1,000	~$40

소규모: API Gateway가 가장 저렴 (트래픽 없으면 0원) 중규모: ALB가 균형 잡힌 선택 대규모: NLB가 가장 저렴, ALB가 그 다음. API Gateway는 비쌈

7. ALB 실전 아키텍처 패턴

패턴 1: ECS/EKS + ALB (가장 흔한 패턴)

이 시리즈에서 반복 등장한 패턴:

CloudFront → ALB → ECS Service (타겟 그룹)

ALB가 ECS 태스크를 타겟 그룹에 자동으로 등록/해제한다. 태스크가 스케일 아웃되면 자동으로 타겟에 추가, 종료되면 자동 제거.

패턴 2: 마이크로서비스 라우팅

하나의 ALB로 여러 마이크로서비스에 라우팅:

ALB 경로 기반 마이크로서비스 라우팅

사용자

ALB 경로 기반 라우팅 규칙

/api/users/* 사용자 서비스

/api/orders/* 주문 서비스

/api/products/* 상품 서비스

패턴 3: 블루/그린 배포

새 버전(그린)을 별도 타겟 그룹에 배포하고, ALB의 리스너 규칙에서 트래픽 가중치를 조절하여 점진적으로 전환:

그린 타겟 그룹에 새 버전 배포
가중치: 블루 90%, 그린 10% → 카나리 테스트
문제 없으면: 블루 0%, 그린 100% → 전환 완료
문제 발견 시: 블루 100%, 그린 0% → 즉시 롤백

패턴 4: NLB + ALB 조합

고정 IP가 필요하면서 HTTP 라우팅도 필요한 경우:

파트너 시스템 → NLB (고정 IP) → ALB (HTTP 라우팅) → ECS

NLB가 고정 IP를 제공하고, 뒤의 ALB가 HTTP 수준의 라우팅을 처리한다.

8. 실제 사례

Netflix: 초당 수십만 요청 분배

Netflix는 ALB + NLB 조합으로 전 세계 수억 사용자의 트래픽을 처리한다. 스트리밍 트래픽은 NLB(TCP 수준, 대용량), API 트래픽은 ALB(HTTP 라우팅)로 분리한다.

Slack: ALB로 실시간 메시징

Slack의 WebSocket 기반 실시간 메시지 전달은 ALB의 WebSocket 지원을 활용한다. 수백만 동시 연결을 ALB가 분배하고, 연결이 끊어지면 자동으로 다른 서버에 재연결한다.

한국 기업 사례

쿠팡: ALB로 수백 개 마이크로서비스 라우팅. 블랙프라이데이 트래픽 폭증에 자동 대응
토스: NLB로 금융 거래 시스템 (고정 IP + 초저지연 필수). 파트너 금융기관과의 연동에 고정 IP 제공
카카오: ALB로 카카오 서비스 API 라우팅. WAF 연동으로 L7 공격 방어

9. 자주 묻는 질문

"CloudFront와 ALB, 둘 다 필요한가?"

예. 역할이 다르다.

CloudFront: 전 세계 사용자에게 가까운 엣지에서 콘텐츠 제공 + 캐싱 + DDoS 방어
ALB: VPC 안에서 백엔드 서비스에 트래픽 분배 + 헬스체크 + 라우팅

전형적 구성: 사용자 → CloudFront → ALB → ECS/EC2

"ALB 하나로 여러 서비스를 처리해도 되나?"

된다. 경로 기반 + 호스트 기반 라우팅으로 수십 개의 서비스를 하나의 ALB에서 처리할 수 있다. ALB당 최대 100개의 규칙을 설정할 수 있다. 비용 면에서도 서비스마다 ALB를 만드는 것보다 유리하다.

"CLB를 아직 쓰고 있는데 바꿔야 하나?"

바꿔야 한다. AWS가 공식적으로 CLB 사용 중단을 권고한다. AWS 콘솔에서 마이그레이션 마법사를 제공하므로 비교적 수월하게 전환할 수 있다.

마치며: 로드밸런서는 "보이지 않는 교통경찰"이다

이 시리즈에서 구축한 아키텍처를 다시 보면, ALB는 모든 곳에 있다:

ECS/EKS 앞: 컨테이너에 트래픽 분배
API Gateway 뒤: 때로는 API Gateway 대신 ALB가 더 효율적
CloudFront 뒤: CDN 캐시 미스 시 ALB로 전달
블루/그린 배포: 무중단 배포의 핵심 메커니즘

로드밸런서는 사용자에게 보이지 않는다. 사용자는 https://api.example.com에 요청을 보낼 뿐, 그 뒤에서 5대의 서버 중 가장 여유 있는 서버로 트래픽이 분배되고, 죽은 서버는 자동으로 제외되고, 새 서버가 추가되면 자동으로 포함되는 — 이 모든 것이 ALB가 조용히 처리하는 일이다.

코어닷투데이의 AI 서비스에서도 ALB는 필수 인프라다. AI 추론 API에 대한 요청이 ALB를 통해 여러 ECS 태스크에 분배되고, 헬스체크로 비정상 태스크가 자동 제외되며, 트래픽 급증 시 ECS Auto Scaling과 연동하여 자동 확장된다. 보이지 않지만, 없으면 안 되는 교통경찰.