로드밸런서(ALB) 구축하기
— 트래픽을 나눠주는
문지기

서버 한 대만 있으면, 손님이 몰릴 때 느려지거나 그 서버가 멈추면 사이트 전체가 멈춥니다. 그래서 다음으로 둔 게 로드밸런서(Load Balancer)예요. 이름은 거창하지만, 하는 일은 딱 하나입니다. "들어오는 손님(트래픽)을 여러 서버로 알아서 나눠주는 것." 오늘은 이 문지기를 AWS에서 직접 세워 보겠습니다.

손님이 줄 서면 빈 창구로 나눠 안내하는 마트의 "문지기" — 딱 그 역할입니다.

저는 처음 이 단어를 들었을 때 뭔가 엄청난 네트워크 장비를 사서 서버실에 꽂아야 하는 줄 알았습니다. 그런데 막상 해 보니, AWS에서는 몇 번의 클릭으로 이 문지기를 세울 수 있더라고요. 물론 개념을 모르고 버튼만 누르면 "왜 사이트가 안 열리지?" 하고 반나절을 헤맵니다(제가 그랬습니다). 그래서 이번 편은 버튼 순서만이 아니라 "왜 그렇게 하는지"까지 최대한 쉽게 풀어 드릴게요. 비개발자여도 겁먹지 마세요. 마트 문지기 이야기만 계속 떠올리시면 됩니다.

단일 서버의 위험 — 문 하나짜리 마트를 상상해 보세요

로드밸런서가 왜 필요한지 이해하려면, 먼저 "그게 없을 때 무슨 일이 벌어지는지"를 봐야 합니다. 서버 한 대로만 운영하는 상태를 저는 "문 하나짜리 마트"라고 부릅니다. 평소 손님이 뜸할 땐 아무 문제가 없어요. 그런데 세일 날 손님이 몰리면 어떻게 될까요?

• 문 앞에 줄이 길어집니다. 서버 한 대가 처리할 수 있는 양은 정해져 있어서, 접속이 몰리면 페이지가 느려지고 심하면 "빙글빙글" 로딩만 돌다가 안 열립니다.
• 그 문이 고장 나면 마트 전체가 닫힙니다. 서버가 재부팅되거나, 배포하다 잠깐 멈추거나, 예기치 못한 오류로 죽으면 — 손님은 아예 들어올 수가 없습니다. 사이트 전체가 다운되는 거죠.
• 손볼 때도 문을 닫아야 합니다. 서버 하나뿐이면, 소프트웨어를 업데이트하려고 그 서버를 잠깐 껐다 켜는 순간 그 시간만큼 사이트가 멈춥니다.

정리하면 단일 서버는 "몰리면 느려지고, 하나 죽으면 전부 죽는다"는 두 가지 약점을 안고 있습니다. 개인 블로그나 방문자가 거의 없는 토이 프로젝트라면 괜찮습니다. 하지만 손님을 실제로 받는 서비스라면, 이 약점은 언젠가 반드시 사고로 돌아옵니다.

문이 하나면 그 문이 병목이자 약점입니다. 문을 여러 개 두고, 그 앞에 손님을 나눠 보내는 안내원을 세우세요. 그 안내원이 로드밸런서입니다.

로드밸런서가 하는 일 — 안내원의 두 가지 역할

이유는 두 가지였습니다. 첫째, 서버를 여러 대 두고 트래픽을 골고루 나누기 위해서. 둘째, 서버 하나가 고장 나면 자동으로 멀쩡한 서버로만 손님을 보내주기 위해서예요. 이 두 가지를 마트 안내원의 일로 바꿔 보면 이렇습니다.

이 두 번째 역할이 정말 중요합니다. 서버가 3대 있는데 그중 1대가 새벽에 조용히 죽었다고 해 봅시다. 로드밸런서가 없으면 그 서버로 간 손님들은 에러 페이지를 보게 됩니다. 하지만 로드밸런서가 있으면, "어? 이 서버 답이 없네" 하고 알아서 나머지 2대로만 손님을 돌립니다. 여러분은 다음 날 아침에 여유롭게 죽은 서버를 살리면 되고, 그동안 손님은 아무 불편을 못 느낍니다. 이걸 어려운 말로 고가용성(High Availability, 잘 안 멈추는 성질)이라고 부르는데, 용어는 잊으셔도 됩니다. "하나 죽어도 서비스는 안 죽는다" — 이거면 충분합니다.

AWS에서 웹사이트용으로 흔히 쓰는 건 ALB(Application Load Balancer)입니다. 이 글의 실전 파트도 전부 ALB 기준으로 진행합니다.

로드밸런서 3형제 — ALB / NLB / CLB 비교

AWS 콘솔에서 로드밸런서를 만들려고 하면, 세 가지 선택지가 나와서 초보자를 당황하게 합니다. ALB, NLB, CLB. 이름만 봐도 헷갈리죠. 결론부터 말하면 일반적인 웹사이트/웹앱이라면 고민할 필요 없이 ALB입니다. 그래도 왜 그런지는 알아 두면 마음이 편하니, 표로 정리해 드릴게요.

정리하면, 이 글을 읽는 분의 99%는 ALB를 고르면 됩니다. "웹사이트를 위한 로드밸런서 = ALB"라고만 기억해 두세요. 나중에 트래픽이 어마어마해지거나 아주 특수한 실시간 서비스를 만들 때가 오면 그때 NLB를 다시 공부해도 늦지 않습니다.

가용영역(AZ) 분산 — 마트를 여러 동네에 두기

여기서 한 단계만 더 나가 볼게요. 서버를 여러 대 두는 것까진 이해하셨을 겁니다. 그런데 그 서버들을 어디에 둘지도 중요합니다. AWS에는 가용영역(Availability Zone, 줄여서 AZ)이라는 개념이 있어요.

가용영역은 쉽게 말해 "물리적으로 떨어진 별도의 데이터센터 구역"입니다. 예를 들어 서울 리전(지역)에는 여러 개의 AZ가 있는데, 각각은 다른 건물, 다른 전력, 다른 네트워크를 씁니다. 왜 이렇게 나눠 놨을까요? 한 건물에 사고(정전, 화재, 침수)가 나도 다른 건물은 멀쩡하게 하기 위해서입니다.

같은 건물 2층·3층에 계산대를 나눠 둬도, 그 건물이 정전되면 다 멈춥니다. 그래서 아예 다른 동네에도 마트 지점을 하나 더 둡니다. 이게 AZ 분산입니다.

그래서 실전에서는 서버(EC2)를 최소 2개의 서로 다른 AZ에 나눠서 배치하고, 로드밸런서가 그 두 AZ로 손님을 골고루 보내게 합니다. 이렇게 하면 AZ 하나가 통째로 문제가 생겨도, 다른 AZ의 서버가 손님을 계속 받습니다. 실제로 ALB를 만들 때 "어느 AZ를 쓸지" 최소 2개를 반드시 선택하게 되어 있어요. AWS가 아예 안전하게 설계하도록 강제하는 셈이죠.

위 그림처럼, 손님은 무조건 로드밸런서라는 하나의 정문으로 들어옵니다. 그러면 로드밸런서가 살아 있는 서버들 — 그것도 서로 다른 AZ에 있는 서버들 — 로 손님을 나눠 보냅니다. 손님 입장에선 주소 하나만 알면 되고, 뒤에 서버가 몇 대인지, 어느 AZ에 있는지는 전혀 몰라도 됩니다. 이 "복잡한 뒤를 숨겨 주는" 점도 로드밸런서의 큰 장점입니다.

핵심 용어 세 가지만 — 대상 그룹 · 헬스 체크 · 리스너

ALB를 만들려면 반드시 만나게 되는 세 단어가 있습니다. 이 셋만 확실히 잡으면 나머지는 다 곁가지예요. 하나씩, 마트 비유와 함께 깊게 보겠습니다.

① 대상 그룹(Target Group) — "손님을 받을 창구 명단"

대상 그룹은 트래픽을 받을 서버들의 명단입니다. 앞서 만든 EC2를 여기에 등록해요. 마트로 치면 "지금 영업 중인 계산대 번호 목록"입니다. 안내원(로드밸런서)은 이 명단을 보고 "1번·2번·3번 창구로 손님을 보내면 되는구나" 하고 판단합니다.

• 대상 그룹에는 서버를 여러 개 등록할 수 있습니다. 나중에 서버를 추가하고 싶으면 이 명단에 한 줄 더 넣기만 하면 돼요.
• 반대로 특정 서버를 잠시 빼고 싶으면(예: 점검) 명단에서 등록 해제하면 됩니다. 그 서버로는 손님이 안 갑니다.
• 대상 그룹은 "무엇을 대상으로 하느냐"를 Instances(EC2 서버), IP 주소, Lambda 등에서 고르는데, 초보 웹 배포라면 Instances를 고르면 됩니다.

② 헬스 체크(Health Check) — "너 살아있니?" 하는 안부 전화

헬스 체크는 로드밸런서가 주기적으로 각 서버에게 "너 살아있니?" 물어보고, 답이 없는 서버엔 손님을 안 보내는 기능입니다. 앞에서 말한 "아픈 창구 걸러내기"를 실제로 담당하는 부분이죠.

동작 방식은 이렇습니다. 로드밸런서가 몇 초마다 한 번씩 각 서버의 특정 주소(예: / 또는 /health)에 접속을 시도합니다. 서버가 정상 응답(보통 HTTP 200)을 주면 "건강함(healthy)"으로, 몇 번 연속 응답이 없거나 에러를 주면 "아픔(unhealthy)"으로 표시하고 손님을 안 보냅니다. 그러다 다시 정상 응답이 돌아오면 자동으로 명단에 복귀시킵니다.

• 헬스 체크 경로(Path): 어느 주소로 안부를 물을지. 기본값은 /인데, 그 주소가 정상 페이지를 반환하는지 꼭 확인해야 합니다. (이게 초보들이 가장 많이 틀리는 부분이라 아래 "흔한 실수"에서 다시 짚습니다.)
• 정상 기준 코드: 보통 200. 서버가 200을 돌려줘야 "건강"으로 봅니다.
• 간격/횟수: 몇 초마다 물어볼지, 몇 번 실패하면 아픈 걸로 볼지 정할 수 있습니다. 초반엔 기본값을 그대로 두어도 무방합니다.

헬스 체크는 안내원이 창구마다 인터폰으로 "거기 영업하세요?"라고 계속 물어보는 것과 같습니다. 대답 없는 창구엔 손님을 절대 안 보내죠. 손님은 그 덕에 늘 열린 창구만 안내받습니다.

③ 리스너(Listener) — "몇 번 문으로 온 손님을 받을지"

리스너는 "몇 번 문으로 들어오는 손님을 받을지" 정하는 규칙입니다. 보통 80번으로 들어온 사람을 443(https)으로 보내줍니다. 여기서 80번, 443번이라는 숫자는 포트(port)라고 부르는데, 인터넷 세계에서 "몇 번 출입문"을 뜻하는 번호라고 생각하면 됩니다.

• 80번 포트 = HTTP = 자물쇠 없는 일반 문(주소가 http://). 정보가 암호화되지 않아 안전하지 않습니다.
• 443번 포트 = HTTPS = 자물쇠 달린 안전한 문(주소가 https://). 정보가 암호화됩니다.

리스너는 "이 포트로 온 손님을 어떻게 처리할지"를 정합니다. 가장 기본은 "80으로 온 손님을 → 대상 그룹으로 보내기"입니다. 그런데 실무에서는 여기에 한 가지 규칙을 더 붙입니다. "80(자물쇠 없는 문)으로 온 손님은 → 443(자물쇠 있는 문)으로 안내(리다이렉트)하기." 이 부분은 다음 편 SSL과 직접 연결되는 내용이라, 아래에서 따로 설명하겠습니다.

ALB 만들기 — 단계별 실전 가이드

이제 실제로 만들어 봅시다. AWS 콘솔(웹 관리 화면)에서 순서대로 따라 하시면 됩니다. 화면 문구는 AWS 업데이트에 따라 조금씩 다를 수 있지만, 큰 흐름은 그대로예요. 저는 이 순서를 노트에 적어 두고 새 프로젝트마다 그대로 씁니다.

EC2 보안 그룹까지 손봐야 진짜 연결됩니다

초보자가 여기서 가장 자주 막힙니다. 로드밸런서용 보안 그룹은 만들었는데, 정작 뒤에 있는 EC2 서버가 로드밸런서의 접속을 안 받아 주면 헬스 체크가 계속 실패합니다. 마트로 치면, 정문 안내원은 세웠는데 계산대 직원이 "안내원이 보낸 손님은 안 받아요" 하고 문을 잠가 둔 격이죠.

그래서 EC2 서버의 보안 그룹에서, 인바운드로 로드밸런서의 보안 그룹이 보내는 트래픽(80번 포트)을 허용해 줘야 합니다. 소스(출처)에 IP 대신 "로드밸런서 보안 그룹"을 지정하는 방식이 가장 깔끔합니다. 이렇게 하면 "이 안내원이 보낸 손님만 받는다"가 되어 안전하면서도 잘 연결됩니다.

HTTP(80)→HTTPS(443) 리다이렉트 — 다음 편 SSL로 가는 다리

앞에서 잠깐 언급한 "80으로 온 손님을 443으로 안내하기"를 조금 더 풀어 볼게요. 왜 이걸 로드밸런서에서 하느냐가 핵심입니다.

요즘 브라우저는 http:// 주소로 들어가면 "안전하지 않음"이라는 경고를 띄웁니다. 손님이 이걸 보면 불안해서 나가 버리죠. 그래서 우리는 손님이 실수로 http://(80번)로 들어와도, 자동으로 https://(443번, 자물쇠)로 돌려보내 줘야 합니다. 이 "돌려보내기"를 리다이렉트(redirect)라고 합니다.

로드밸런서의 80번 리스너에 "이 문으로 온 손님은 무조건 443번 문으로 안내(HTTP → HTTPS redirect)"라는 규칙을 걸어 두면, 손님이 어떤 주소로 오든 결국 안전한 자물쇠 문으로 들어오게 됩니다. 여기서 중요한 점 — 자물쇠(SSL/TLS 인증서)를 서버마다 하나하나 설치하지 않고, 로드밸런서 한 곳에만 붙이면 된다는 것입니다.

서버가 3대여도 자물쇠는 정문(로드밸런서)에 딱 하나만 달면 됩니다. 손님은 정문에서 이미 안전하게 들어왔으니, 뒤쪽 창구까지 매번 자물쇠를 채울 필요가 없죠. 관리가 훨씬 간단해집니다.

바로 이 점 때문에, 저는 "SSL을 깔끔하게 붙이려면 로드밸런서를 먼저 두는 게 낫다"고 말합니다. 다음 편에서 무료로 SSL 인증서(AWS Certificate Manager, ACM)를 발급받아 이 로드밸런서의 443 리스너에 연결하는 과정을 다룹니다. 오늘 만든 로드밸런서가 그 자물쇠를 걸 "문틀" 역할을 하는 셈이에요.

요금 이야기 — 얼마나 나오나요?

로드밸런서는 편리한 만큼 공짜는 아닙니다. 시간당 요금 + 사용량(LCU) 요금이 붙어 대략 월 2만 원대부터 나올 수 있습니다. 구조를 조금만 이해하면 마음이 놓입니다.

• 시간당 기본요금: 로드밸런서가 켜져 있는 시간만큼 붙는 고정 성격의 요금입니다. 손님이 없어도 켜 두면 시간당 과금돼요.
• LCU(Load balancer Capacity Unit) 요금: 실제로 처리한 트래픽 양(접속 수, 데이터 양 등)에 비례해 붙는 사용량 요금입니다. 많이 쓰면 늘어납니다.

즉 "켜 두기만 해도 최소 요금이 발생하고, 손님이 많으면 조금 더 붙는" 구조입니다. 이 둘을 합쳐 실제 청구서는 대략 월 2만 원대부터 시작한다고 보시면 됩니다.

정리하면, 개인 토이 프로젝트라면 초기엔 생략했다가 트래픽이 늘면 도입해도 됩니다. 저도 처음 연습용 사이트에는 로드밸런서를 안 붙였습니다. 방문자가 늘고 "이제 진짜 서비스구나" 싶을 때 도입해도 전혀 늦지 않아요. 다만 SSL을 제대로 붙이고 싶다면, 요금을 감수하고 미리 두는 것도 충분히 합리적인 선택입니다.

자주 묻는 질문(FAQ)

Q. 서버가 1대뿐인데 로드밸런서를 써도 되나요?
A. 됩니다. 손님을 "나눌" 서버는 1대뿐이라 분산 효과는 없지만, 헬스 체크로 서버 상태를 관리하고 SSL 자물쇠를 로드밸런서에 붙이는 이점은 그대로 누릴 수 있습니다. 다만 요금은 똑같이 나오니, 그 값어치가 있는지 판단하세요.

Q. 로드밸런서 주소가 ...elb.amazonaws.com 처럼 길고 못생겼어요. 이대로 써야 하나요?
A. 아니요. 이 긴 DNS 이름은 내 도메인(예: www.example.com)에 연결해서 예쁜 주소로 바꿀 수 있습니다. 도메인 연결(Route 53 등) 편에서 이 주소를 가리키게 설정하면 됩니다. 로드밸런서 자체 주소는 "내부용 실제 주소"라고 생각하세요.

Q. 헬스 체크가 자꾸 unhealthy로 나옵니다. 서버는 멀쩡한데요?
A. 십중팔구 두 가지 중 하나입니다. ① 헬스 체크 경로(/health 등)가 서버에 실제로 없어서 404가 나거나, ② EC2 보안 그룹이 로드밸런서의 접속(80번)을 안 받아 주는 경우. 아래 "흔한 실수"에서 자세히 다룹니다.

Q. ALB랑 NLB 중 뭘 골라야 할지 아직도 모르겠어요.
A. 일반 웹사이트·웹앱·API면 무조건 ALB입니다. "초당 수십만 접속이 몰리는 게임 서버나 실시간 통신을 만든다"가 아니라면 NLB는 고민할 필요조차 없습니다.

Q. 로드밸런서를 잠깐 껐다 켤 수 있나요? 안 쓸 때 요금을 아끼려고요.
A. EC2처럼 "중지" 버튼은 없습니다. 요금을 완전히 멈추려면 로드밸런서를 삭제해야 합니다. 연습용으로 잠깐 만들었다면, 실습이 끝난 뒤 삭제해서 불필요한 시간당 요금이 계속 붙지 않게 하세요.

Q. 서버를 나중에 더 추가하면 로드밸런서를 다시 만들어야 하나요?
A. 전혀요. 새 EC2를 만든 다음, 기존 대상 그룹에 그 서버를 등록하기만 하면 됩니다. 로드밸런서는 그대로 두고 명단만 늘리는 거예요. 손님을 나눠 받는 창구가 하나 더 열리는 셈입니다.

초보가 흔히 하는 실수 & 해결법

제가 직접 겪었거나, 주변에서 반복해서 본 실수들입니다. 이 목록만 미리 봐도 반나절은 아낄 수 있어요.

구축 전·후 체크리스트

실제로 만들기 전, 그리고 만든 직후에 이 목록을 한 번씩 훑어보세요. 저는 새 프로젝트마다 이 리스트를 그대로 씁니다.

• ✅ 손님을 받을 EC2 서버가 준비되어 있고, 웹앱이 실제로 돌고 있나요?
• ✅ 로드밸런서 종류로 ALB를 골랐나요? (웹이면 ALB)
• ✅ Scheme을 Internet-facing으로 두었나요?
• ✅ 서로 다른 AZ 2개 이상을 선택했나요?
• ✅ 로드밸런서 보안 그룹에 80·443 인바운드를 열었나요?
• ✅ 대상 그룹을 Instances 유형으로 만들고 EC2를 등록했나요?
• ✅ 헬스 체크 경로가 실제로 200을 반환하나요?
• ✅ EC2 보안 그룹이 로드밸런서의 80번 접속을 허용하나요?
• ✅ 리스너의 전달 대상에 대상 그룹이 연결됐나요?
• ✅ 생성 후 상태가 Active, 대상이 healthy로 바뀌었나요?
• ✅ 로드밸런서 DNS 주소로 사이트가 실제로 열리나요?
• ✅ (연습용이라면) 실습 후 삭제해서 요금이 계속 붙지 않게 했나요?

느껴본 점 — 그리고 다음 편으로

사실 1인 프로젝트에서는 반드시 필요한 건 아닙니다. 하지만 로드밸런서를 두면 다음 편의 SSL 인증서를 깔끔하게 붙일 수 있어서, 저는 "자물쇠(https)"를 제대로 달기 위해서라도 두길 잘했다고 생각합니다. 처음엔 "이걸 왜 이렇게 복잡하게 하나" 싶었는데, 막상 서버 한 대가 새벽에 죽었을 때 손님들이 아무 불편 없이 사이트를 쓰는 걸 보고 나서 마음이 완전히 바뀌었어요. 문지기 하나가 그렇게 든든할 줄은 몰랐습니다.

오늘 배운 걸 한 문장으로 요약하면 이렇습니다. "로드밸런서(ALB)는 여러 서버 앞에 서서, 손님을 골고루 나눠 보내고(대상 그룹), 아픈 서버를 걸러내며(헬스 체크), 어느 문으로 온 손님을 어떻게 받을지 정하는(리스너) 문지기다." 이 세 용어와 마트 비유만 기억하시면, 어느 프로젝트에서든 흔들리지 않으실 겁니다.

그리고 오늘 세운 이 문지기가, 다음 편에서 SSL 자물쇠를 거는 문틀이 됩니다. 80으로 온 손님을 443으로 안전하게 안내하는 그 마지막 퍼즐 조각을 다음 편에서 맞춰 볼게요. 그 이야기는 4편에서 이어갑니다.

(2026년 7월 기준 작성 — AWS 콘솔 화면과 요금은 시점에 따라 달라질 수 있으니, 실제 설정과 결제 전에는 반드시 공식 문서와 요금 페이지를 확인하세요.)

← 기술 블로그 목록으로