드디어 마지막 편입니다. 여기까지 오면 서버(EC2)도, 여러 서버 앞에서 교통정리를 하는 로드밸런서(ALB)도, 자물쇠(SSL 인증서)도 다 준비가 됐어요. 그런데 딱 하나가 비어 있습니다. 바로 주소예요. 지금 내 서비스에 접속하려면 13.125.xxx.xxx 같은 숫자 덩어리(IP)나, 아니면 my-alb-1234567890.ap-northeast-2.elb.amazonaws.com 같은 외계어 주소를 외워야 합니다. 이걸 누가 기억하나요? 저도 못 외웁니다.
그래서 사람이 외울 수 있는 도메인(예: myapp.com)이 필요합니다. AWS에서는 Route 53이라는 서비스가 그 역할을 합니다. 이름부터 재미있는데요, DNS의 표준 포트 번호가 53번이라서 "길을 안내한다(Route)"는 뜻을 붙여 Route 53이라고 지었다고 해요. 오늘은 이 마지막 퍼즐 조각을 맞춰서, 정말 '내 주소를 가진' 서비스를 완성해 보겠습니다.
서버를 올리는 것이 '집을 짓는 일'이었다면, 도메인을 연결하는 것은 그 집에 '문패와 도로명 주소를 붙이는 일'입니다. 주소가 있어야 손님이 찾아옵니다.
도메인과 DNS, 대체 뭔가요? — 인터넷의 전화번호부
가장 먼저 겁부터 빼고 갑시다. 도메인과 DNS는 어렵게 느껴지지만, 원리는 우리가 매일 쓰는 휴대폰 전화번호부와 똑같습니다.
여러분, 친구에게 전화 걸 때 010-1234-5678이라는 번호를 외워서 누르시나요? 아니죠. 연락처에서 "엄마", "김부장"이라고 이름을 찾아서 누릅니다. 그러면 휴대폰이 알아서 그 이름에 저장된 번호로 전화를 걸어줍니다. 즉 '사람이 기억하기 쉬운 이름'과 '기계가 실제로 쓰는 번호'를 이어주는 장부가 바로 전화번호부예요.
인터넷도 완전히 똑같습니다. 모든 서버(컴퓨터)에는 IP 주소라는 숫자 번호가 붙어 있어요. 13.125.100.200 같은 식입니다. 컴퓨터끼리는 이 숫자로만 서로를 찾습니다. 하지만 사람이 13.125.100.200을 외우고 다닐 수는 없죠. 그래서 naver.com, myapp.com 같은 사람이 외우기 쉬운 이름(도메인)을 붙여 두고, "이 이름은 실제로 어떤 IP 번호야?"를 대신 찾아주는 장부를 만들었습니다.
DNS(Domain Name System)는 한마디로 '인터넷의 전화번호부'입니다. 도메인 이름(myapp.com)을 IP 주소(13.125.100.200)로 바꿔주는 거대한 번호 안내 시스템이에요.
정리하면 이렇습니다. 우리는 브라우저 주소창에 myapp.com이라고 이름을 칩니다. 그러면 인터넷 어딘가의 DNS가 "아, 그 이름은 13.125.100.200이라는 번호로 가면 돼"라고 번호를 알려주고, 브라우저는 그 번호로 찾아가서 우리 서비스를 화면에 띄웁니다. 이 모든 게 눈 깜짝할 사이(보통 0.1초 미만)에 일어나기 때문에 우리는 그 과정을 느끼지도 못하는 거예요.
왜 IP를 직접 안 쓰고 도메인을 쓰나요?
초보분들이 자주 하는 질문입니다. "그냥 IP 주소 알려주면 안 되나요?" 세 가지 이유가 있어요.
- 외우기 쉬워요.
myapp.com과13.125.100.200중 뭐가 기억하기 좋나요? 당연히 이름이죠. - 번호가 바뀌어도 이름은 그대로예요. 서버를 옮기거나 IP가 바뀌어도, 전화번호부(도메인)의 번호만 새로 고쳐주면 손님은 아무 변화도 못 느낍니다. 이사 가도 이름(문패)은 안 바뀌는 것과 같아요.
- 신뢰와 브랜드가 됩니다. 명함에 IP 숫자를 적을 순 없잖아요. 사람이 읽을 수 있는 주소는 그 자체로 브랜드입니다.
클릭 한 번이 서버까지 가는 길 — DNS 동작 흐름
말로만 하면 감이 안 오니, 여러분이 주소창에 myapp.com을 치고 엔터를 누른 그 순간부터 무슨 일이 벌어지는지 흐름으로 그려보겠습니다.
사용자가
myapp.com 입력
"이 이름의
번호가 뭐야?"
"ALB로 가!"
IP를 알려줌
로드밸런서가
서버로 분배
내 앱이
브라우저에 뜸
단계별로 풀어볼게요. 어렵지 않습니다.
- 주소 입력 — 손님이
myapp.com을 주소창에 칩니다. - DNS 조회 — 브라우저는 "이 이름의 진짜 번호가 뭐지?" 하고 전화번호부에 물어봅니다. 이때 여러 단계의 DNS 서버를 거쳐 결국 우리 도메인을 관리하는 Route 53까지 질문이 도착해요.
- Route 53 응답 — Route 53이 우리가 등록해 둔 레코드를 보고 "이 이름은 이 로드밸런서(ALB)로 가면 돼"라고 실제 주소를 알려줍니다.
- ALB 도착 — 브라우저는 그 주소로 찾아가고, 앞 편에서 만든 로드밸런서가 트래픽을 받아 뒤에 있는 서버(EC2)들에게 골고루 나눠줍니다.
- 화면 표시 — 서버가 응답한 내용이 브라우저에 그려지고, 손님은 우리 앱을 봅니다. 끝!
Route 53에서 도메인 사기 — 단계별 실전 가이드
이제 실제로 화면에서 무엇을 누르는지 하나씩 따라가 봅시다. 저는 실제로 이 순서 그대로 .com 도메인을 샀고, 몇 분 만에 '내 이름'을 가졌어요.
Route 53 콘솔에 들어가 이름 검색하기
AWS 콘솔 검색창에 'Route 53'을 치고 들어갑니다. 왼쪽 메뉴에서 Registered domains(등록된 도메인) → Register domains(도메인 등록)을 누르고, 갖고 싶은 이름(예: myapp.com)을 검색해요. 초록색 Available(사용 가능)이 뜨면 아무도 안 쓰는 이름이라 살 수 있다는 뜻입니다.
장바구니에 담고 결제 정보 입력하기
원하는 이름을 Add to cart(장바구니 담기). 그다음 소유자 연락처(이름·이메일·주소)를 입력합니다. 이건 도메인 소유자 등록에 필요한 국제 규칙이라 꼭 넣어야 해요. 개인정보 노출이 걱정되면 Privacy protection(개인정보 보호) 옵션을 켜두면 됩니다(대부분 무료 제공).
자동 갱신 확인하고 결제하기
.com 도메인은 보통 연 14달러 안팎입니다(끝자리 TLD마다 다르니 결제 화면의 실제 금액을 꼭 확인하세요). Auto-renew(자동 갱신)는 켜두길 권합니다. 깜빡하고 갱신을 놓쳐 애써 키운 도메인을 남에게 뺏기는 사고가 은근히 많거든요. 결제하면 등록 요청이 접수됩니다.
호스팅 영역이 자동으로 생기는 걸 확인하기
Route 53에서 도메인을 사면, 그 이름의 전화번호부인 호스팅 영역(Hosted Zone)이 자동으로 함께 만들어집니다. 왼쪽 메뉴 Hosted zones에 내 도메인이 보이면 성공이에요. 우리는 이 장부 안에 "이 주소로 오면 어디로 보내라"는 안내문을 적을 겁니다.
레코드 추가 — ALIAS로 ALB에 연결하기
호스팅 영역을 열고 Create record(레코드 생성)를 누릅니다. 레코드 이름은 비워두면 myapp.com 자체, www를 넣으면 www.myapp.com이 됩니다. 타입은 A를 고르고, Alias(별칭) 토글을 켠 뒤 연결 대상으로 앞 편에서 만든 로드밸런서(ALB)를 목록에서 선택합니다. 저장!
전파(propagation)를 기다리고 접속 확인하기
저장했다고 세상 모든 전화번호부가 즉시 바뀌진 않아요. 전 세계로 정보가 퍼지는 전파(propagation)에 보통 몇 분~수십 분(길면 최대 48시간)이 걸립니다. 조금 기다린 뒤 브라우저에 https://myapp.com을 쳐서 자물쇠 걸린 내 앱이 뜨면 완성입니다. 🎉
www.myapp.com과 myapp.com 둘 다 되길 원합니다. 방법은 간단해요. 5번을 한 번 더 반복하되, 이번엔 이름 칸에 www를 넣고 똑같이 ALB에 ALIAS로 연결하면 됩니다. 두 주소 모두 같은 서비스로 도착합니다.레코드 종류 — 어떤 걸 언제 쓰나요?
호스팅 영역(전화번호부)에는 안내문을 여러 종류로 적을 수 있는데, 이걸 레코드(record)라고 부릅니다. 종류가 많아 보여도, 개인 서비스에서 실제로 자주 쓰는 건 몇 개 안 돼요. 겁먹지 말고 표로 보시죠.
| 레코드 타입 | 역할(쉽게) | 언제 쓰나 |
|---|---|---|
| A | 이름 → IP 주소(숫자)로 직접 연결 | 고정 IP를 가진 서버에 바로 붙일 때 |
| ALIAS (별칭) | 이름 → AWS 자원(ALB·CloudFront 등)으로 연결. AWS 전용 편의 기능 | ALB에 연결할 때(우리 경우!) |
| CNAME | 이름 → 다른 이름으로 연결(별명의 별명) | 서브도메인을 다른 도메인으로 넘길 때 |
| MX | 이 도메인의 메일을 어느 서버로 보낼지 지정 | 도메인으로 이메일을 받을 때 |
| TXT | 임의의 텍스트 메모. 소유권 증명 등에 사용 | 도메인 인증·SPF 설정 등 |
| NS | 이 도메인을 어느 DNS 서버가 관리하는지 | 보통 자동 생성(건드릴 일 적음) |
왜 ALB에는 ALIAS를 쓰나요? — A와 ALIAS의 차이
여기가 초보분들이 가장 헷갈려하는 지점이라 콕 집어 설명할게요. 우리 로드밸런서(ALB)는 고정된 IP 번호가 없습니다. AWS가 트래픽 상황에 따라 뒤에서 IP를 바꿔가며 운영하거든요. 그래서 A 레코드로 "이 IP로 가!"라고 숫자를 박아버리면, 내일 그 IP가 바뀌는 순간 우리 사이트는 접속 불가가 됩니다.
반면 ALIAS는 숫자를 박는 게 아니라 "저 ALB라는 이름표로 가"라고 가리키기만 합니다. 그래서 AWS가 뒤에서 IP를 아무리 바꿔도, 우리는 손 하나 댈 필요가 없어요. 항상 최신 번호로 자동 연결됩니다. 게다가 ALIAS는 조회 요금도 안 붙어서 더 저렴해요.
👍 ALIAS로 ALB 연결 (권장)
- ALB의 IP가 바뀌어도 자동으로 따라감 — 손 볼 일 없음
- 루트 도메인(
myapp.com)에도 바로 사용 가능 - ALIAS 조회는 추가 요금 없음
- AWS 자원끼리라 설정이 목록 선택으로 간단
👎 A 레코드로 IP 직접 연결
- ALB는 IP가 수시로 바뀌어 곧 접속 불가 위험
- IP가 바뀔 때마다 수동으로 고쳐야 함
- 관리 부담·장애 위험이 큼
- 고정 IP를 가진 단일 서버에나 적합
한 줄 요약: ALB에 붙일 땐 무조건 ALIAS. "IP 숫자를 박지 말고, ALB라는 이름표를 가리켜라." 이 한 문장만 기억하시면 됩니다.
비용 이야기 — 도메인은 얼마나 드나요?
돈 이야기를 빼놓을 수 없죠. 클라우드에서 제일 무서운 건 '나도 모르게 새는 요금'이니까요. Route 53 도메인 관련 비용은 다행히 단순하고 예측 가능한 편입니다.
| 항목 | 대략 비용 | 설명 |
|---|---|---|
| 도메인 등록비 | .com 연 14달러 안팎 | 1년에 한 번 내는 이름 사용료. TLD(.com/.io/.dev 등)마다 다름 |
| 호스팅 영역 | 월 $0.50 가량 | 전화번호부 한 권을 유지하는 기본료. 도메인당 부과 |
| DNS 조회 요금 | 아주 소액 | 조회 건수에 따라 조금씩. 개인 사이트 수준이면 거의 무시할 정도 |
즉 개인 서비스라면 1년에 도메인값 약 14달러 + 매달 0.50달러 남짓이 사실상 전부입니다. 커피 몇 잔 값으로 '내 주소'를 갖는 셈이죠. 앞서 배운 것처럼 ALIAS 레코드 조회는 추가 요금이 없어서 여기서도 아낄 수 있습니다.
.io, .ai 같은 인기 TLD는 .com보다 몇 배 비쌀 수 있습니다.전파(propagation) — "왜 아직 안 떠요?"
레코드를 저장하자마자 브라우저에 주소를 쳤는데 안 뜬다고 당황하는 분이 정말 많습니다. 저도 처음엔 "뭘 잘못 눌렀나?" 하고 30분 동안 설정을 뒤졌어요. 알고 보니 아무 문제가 없었습니다. 그냥 전파를 기다리면 되는 거였어요.
전파(propagation)가 뭐냐면, 우리가 Route 53 장부를 고쳐도 그 정보가 전 세계 곳곳의 DNS 서버로 퍼지는 데 시간이 걸리는 현상입니다. 전화번호부가 한 권만 있는 게 아니라 세계 각지에 사본이 있고, 각 사본은 "이 번호는 몇 시간 동안은 안 바뀌겠지" 하고 잠시 기억(캐시)해 두기 때문이에요. 이 기억이 만료되어야 새 정보를 다시 읽어옵니다.
비유하자면, 새 명함을 만들었다고 이미 남들이 지갑에 넣어둔 옛 명함이 즉시 사라지진 않는 것과 같아요. 옛 명함을 버리고 새 명함으로 바꾸는 데 시간이 걸립니다.
- 보통 몇 분~수십 분이면 대부분 반영됩니다.
- 드물게 최대 48시간까지 걸릴 수 있다고 안내되지만, 요즘은 대개 훨씬 빨라요.
- 내 컴퓨터에만 안 뜬다면, 휴대폰 데이터(다른 네트워크)로 접속해 보세요. 되면 전파가 진행 중이라는 뜻입니다.
자주 묻는 질문(FAQ)
Q. 도메인은 꼭 Route 53에서 사야 하나요? 다른 데서 산 도메인도 되나요?
A. 됩니다. 가비아·후이즈·GoDaddy 같은 다른 업체에서 산 도메인도 AWS에 연결할 수 있어요. 다만 그 경우엔 '어느 전화번호부(네임서버)를 쓸지'를 그 업체 화면에서 Route 53 쪽으로 바꿔줘야 해서 한 단계가 더 늘어납니다. 처음이라 헷갈린다면 Route 53에서 사고 관리까지 한곳에서 하는 게 제일 편해요.
Q. 도메인을 사면 바로 사이트가 뜨나요?
A. 아니요. 도메인은 '이름'을 산 것뿐이고, 그 이름을 우리 서버(ALB)로 연결하는 레코드 추가(5단계)를 해야 합니다. 이름만 사고 연결을 안 하면 아무 데도 도착하지 않아요.
Q. 자물쇠(https)는 어떻게 되나요?
A. SSL 인증서는 앞 편에서 ALB에 붙여뒀죠. 도메인을 ALB에 ALIAS로 연결하면, 그 자물쇠가 우리 새 도메인에도 그대로 적용됩니다. 단, 인증서를 발급할 때 우리 도메인 이름이 인증서에 포함돼 있어야 https://myapp.com에서 자물쇠가 정상으로 보입니다.
Q. 도메인을 안 쓰게 되면 요금이 계속 나가나요?
A. 호스팅 영역이 남아 있으면 월 $0.50가량이 계속 부과됩니다. 완전히 정리하려면 호스팅 영역을 삭제하세요. 도메인 등록 자체는 1년 단위라, 자동 갱신을 꺼두면 만료 후 더는 청구되지 않습니다.
Q. 이름을 잘못 정했어요. 나중에 바꿀 수 있나요?
A. 이미 산 도메인의 '철자'는 바꿀 수 없어요(그건 새로 사는 겁니다). 하지만 그 도메인이 어디로 연결되는지는 레코드만 고치면 언제든 바꿀 수 있습니다. 이름은 고정, 목적지는 자유롭게.
초보가 흔히 하는 실수 & 해결법
제가 직접 겪었거나, 수강생분들에게 가장 많이 받은 질문을 모았습니다. 미리 알면 30분 삽질을 아낄 수 있어요.
실수 1 — 전파를 안 기다리고 "안 된다"고 판단
저장하자마자 안 뜬다고 설정을 다 뒤엎는 경우가 1위입니다. 대부분 설정은 멀쩡하고 전파 대기 중일 뿐이에요. 해결: 최소 10~30분 기다려 보고, 모바일 데이터로 교차 확인부터 하세요.
실수 2 — ALB인데 A 레코드에 IP를 직접 박음
ALB는 IP가 바뀌므로 오늘 되더라도 내일 끊깁니다. 해결: A 타입을 고르되 반드시 Alias 토글을 켜고 목록에서 ALB를 선택하세요. 숫자를 직접 입력하지 마세요.
실수 3 — 루트 도메인에 CNAME을 사용
myapp.com(맨 앞에 www 없는 루트)에는 표준상 CNAME을 못 씁니다. 모르고 CNAME으로 만들면 오류가 나요. 해결: 루트에는 ALIAS를 쓰면 이 문제를 깔끔히 피할 수 있습니다.
실수 4 — www와 루트 중 하나만 연결
myapp.com은 되는데 www.myapp.com은 안 된다(또는 반대)는 문의가 많습니다. 해결: 두 이름에 대해 레코드를 각각 만들어 주세요. 하나 만든다고 나머지가 자동으로 되지 않습니다.
실수 5 — 자동 갱신을 꺼두고 만료를 방치
1년 뒤 갱신을 놓쳐 도메인을 잃고, 남이 채가는 사고가 있습니다. 해결: Auto-renew를 켜두고 결제 카드가 유효한지 가끔 확인하세요. 애정을 쏟은 이름일수록 더 그렇습니다.
실수 6 — 인증서에 도메인이 빠져 자물쇠 경고
연결은 됐는데 https에서 "안전하지 않음" 경고가 뜨는 경우입니다. 해결: ALB에 붙인 SSL 인증서에 새 도메인 이름이 포함돼 있는지 확인하고, 없으면 인증서에 도메인을 추가해 재발급/적용하세요.
마지막 점검 — 접속 전 체크리스트
레코드를 다 만들었다면, 브라우저에 주소를 치기 전에 아래를 하나씩 확인해 보세요. 여기까지 전부 ✅면 거의 확실히 성공입니다.
- ✅ Route 53에서 도메인을 등록(결제)했나요?
- ✅ 호스팅 영역이 내 도메인 이름으로 생성돼 있나요?
- ✅ 레코드를 만들 때 타입을 A + Alias 토글 ON으로 하고 ALB를 선택했나요?
- ✅
myapp.com과www.myapp.com둘 다 레코드를 만들었나요? - ✅ ALB에 붙은 SSL 인증서에 내 도메인이 포함돼 있나요?
- ✅ 전파 시간(몇 분~수십 분)을 기다렸나요?
- ✅ 안 될 때 모바일 데이터로 교차 확인해 봤나요?
- ✅ 자동 갱신을 켜두었나요?
시리즈 대장정 완주 — EC2부터 도메인까지 한눈에
축하합니다. 이 글로 AWS 배포 시리즈가 끝납니다. 처음엔 '클라우드'라는 단어만 들어도 막막했을 텐데, 지금 여러분은 서비스 한 채를 통째로 지어 올린 겁니다. 우리가 걸어온 길을 마지막으로 되짚어 볼게요.
서버 켜기
트래픽 분배
데이터 저장
자물쇠(https)
내 주소 완성
전 과정을 완주했는지 마지막으로 도장을 찍어봅시다.
- ✅ EC2로 나만의 서버 컴퓨터를 클라우드에 켰다
- ✅ 로드밸런서(ALB)로 트래픽을 여러 서버에 나눠 안정성을 확보했다
- ✅ 데이터베이스를 붙여 사용자 데이터를 안전하게 저장했다
- ✅ SSL 인증서로 자물쇠(https)를 걸어 통신을 암호화했다
- ✅ 도메인을 사서 ALB에 연결해, 사람이 외우는 '내 주소'를 완성했다
마침표 — 내 손으로 올린 서비스
그 주소를 브라우저에 치자 자물쇠 걸린 내 앱이 떠올랐을 때, 묘한 기분이 들었습니다. 코딩을 몰라도, EC2부터 로드밸런서·데이터베이스·SSL·도메인까지 내 손으로 하나하나 연결해 하나의 서비스를 완성한 거예요. 화면에 뜬 그 주소는 이제 세상 누구에게나 보낼 수 있는, 온전히 내 것이 된 공간입니다.
처음 시리즈를 시작할 때만 해도 '서버', 'DNS', '레코드' 같은 단어가 외국어처럼 들렸을 겁니다. 그런데 지금 여러분은 그 단어들을 직접 다뤄봤어요. 그 차이는 생각보다 큽니다. 앞으로 어떤 클라우드 서비스를 만나도 "아, 이건 그때 그거랑 비슷하겠네" 하고 감이 올 거예요.
이 과정 전체를 사주앱이라는 실제 예제로, 기획부터 배포·도메인 연결까지 처음부터 끝까지 손을 잡고 따라가는 것이 제 책입니다. 오늘 이 시리즈로 감을 잡으셨다면, 책에서는 화면 캡처와 함께 훨씬 더 촘촘하게, 막히는 지점마다 손을 내밀어 드립니다. 클라우드가 막막했다면, 거기서부터 시작해 보세요. 여러분의 다음 서비스가 기대됩니다.
코딩을 몰라도 괜찮습니다. 중요한 건 '내 손으로 끝까지 올려봤다'는 경험이에요. 그 경험 하나가 다음 도전의 자신감이 됩니다. — 멘토 김부장
※ 본문의 요금·화면 구성은 2026년 8월 기준으로 작성했습니다. AWS 콘솔 UI와 요금은 수시로 바뀌니, 실제 결제·설정 전 공식 페이지에서 최신 정보를 꼭 확인하세요.
← 기술 블로그 목록으로