Route 53으로 도메인 연결 완벽 가이드

AWS Route 53을 사용하여 도메인을 등록하고 실제 서비스에 연결하는 전 과정을 실무 스토리와 함께 쉽게 배워봅니다. DNS의 기본 개념부터 레코드 설정, ELB 연결까지 초급 개발자도 쉽게 따라할 수 있도록 구성했습니다.

---

목차

1. DNS와_Route_53의_역할
2. Route_53에서_도메인_등록하기
3. 호스팅_영역_개념_이해하기
4. 레코드_타입_이해하기
5. ELB와_도메인_연결_실습
6. 도메인_전파_시간과_확인_방법

---

1. DNS와 Route 53의 역할

입사 2개월 차 신입 개발자 김개발 씨는 첫 번째 서비스 배포를 앞두고 있습니다. 열심히 개발한 웹사이트를 AWS EC2에 올렸는데, 접속하려면 54.123.45.67 같은 IP 주소를 입력해야 합니다.

팀장님이 다가와 물으셨습니다. "우리 서비스 도메인 myservice.com으로 연결해야 하는데, Route 53 설정 좀 해줄 수 있어요?"

DNS는 도메인 이름을 IP 주소로 변환해주는 인터넷의 전화번호부입니다. Route 53은 AWS에서 제공하는 DNS 서비스로, 도메인 등록부터 트래픽 라우팅까지 모두 관리할 수 있습니다.

마치 우체국이 주소를 보고 정확한 집을 찾아주듯이, Route 53은 도메인 이름을 보고 정확한 서버를 찾아줍니다. 전 세계에 분산된 DNS 서버를 통해 빠르고 안정적인 서비스를 제공합니다.

다음 코드를 살펴봅시다.

// AWS SDK로 Route 53 쿼리 예제
const AWS = require('aws-sdk');
const route53 = new AWS.Route53();

// 호스팅 영역 목록 조회
const params = {
  MaxItems: '10'
};

route53.listHostedZones(params, (err, data) => {
  if (err) {
    console.log('DNS 조회 실패:', err);
  } else {
    // 등록된 도메인 목록 출력
    console.log('등록된 호스팅 영역:', data.HostedZones);
    data.HostedZones.forEach(zone => {
      console.log(`도메인: ${zone.Name}, ID: ${zone.Id}`);
    });
  }
});

김개발 씨는 난감했습니다. DNS라는 말은 들어봤지만 정확히 어떻게 작동하는지 몰랐고, Route 53은 처음 들어보는 서비스였습니다.

어떻게 해야 할까요? 같은 팀 선배 박시니어 씨가 커피를 한 잔 건네며 자리에 앉았습니다.

"DNS부터 이해하면 쉬워질 거예요. 천천히 설명해드릴게요." DNS의 역할을 이해해봅시다 우리가 웹사이트에 접속할 때 www.google.com 같은 이름을 사용합니다.

하지만 컴퓨터는 이런 문자를 이해하지 못합니다. 컴퓨터는 오직 172.217.161.46 같은 숫자로 된 IP 주소만 이해할 수 있습니다.

바로 여기서 DNS가 필요합니다. DNS는 Domain Name System의 약자로, 마치 전화번호부처럼 도메인 이름과 IP 주소를 연결해주는 시스템입니다.

우리가 "김철수"라는 이름으로 전화번호를 찾듯이, DNS는 "google.com"이라는 이름으로 IP 주소를 찾아줍니다. Route 53은 무엇일까요 AWS Route 53은 아마존에서 제공하는 클라우드 기반 DNS 서비스입니다.

여기서 53이라는 숫자가 붙은 이유는 DNS가 53번 포트를 사용하기 때문입니다. Route 53은 단순히 DNS 조회만 하는 것이 아닙니다.

도메인 등록, 건강 체크, 트래픽 라우팅 정책 등 다양한 기능을 제공합니다. 마치 종합 교통 관제센터가 차량의 흐름을 관리하듯이, Route 53은 인터넷 트래픽을 최적의 서버로 안내합니다.

왜 Route 53을 사용해야 할까요 예전에는 도메인 등록 업체에서 도메인을 사고, 별도의 DNS 서비스를 설정해야 했습니다. 서로 다른 회사의 서비스를 연동하다 보니 설정이 복잡하고 문제가 생기면 책임 소재도 애매했습니다.

Route 53은 이 모든 과정을 하나로 통합했습니다. AWS 콘솔 하나에서 도메인 구매부터 DNS 설정, 서버 연결까지 모두 처리할 수 있습니다.

더 큰 장점은 AWS의 다른 서비스들과 완벽하게 연동된다는 점입니다. 실제로 어떻게 작동할까요 사용자가 브라우저에 myservice.com을 입력한다고 가정해봅시다.

그러면 다음과 같은 일이 벌어집니다. 먼저 사용자의 컴퓨터는 가까운 DNS 서버에 "myservice.com의 IP 주소가 뭐예요?"라고 물어봅니다.

이 DNS 서버가 모른다면 루트 DNS 서버에 물어보고, 루트 서버는 .com 담당 서버를 알려줍니다. 이렇게 단계별로 물어보며 최종적으로 Route 53에 도달합니다.

Route 53은 미리 설정해둔 레코드를 확인하고 "아, 이 도메인은 54.123.45.67 서버로 가야 하네요"라고 답변합니다. 이 정보를 받은 브라우저는 비로소 해당 IP 주소로 접속합니다.

전 세계에 분산된 인프라 Route 53의 강력한 점은 전 세계 여러 지역에 DNS 서버가 분산되어 있다는 것입니다. 한국 사용자는 한국에 있는 DNS 서버에서, 미국 사용자는 미국에 있는 DNS 서버에서 응답을 받습니다.

이렇게 분산되어 있으면 응답 속도가 빨라집니다. 또한 한 지역의 서버에 문제가 생겨도 다른 지역의 서버가 계속 작동하므로 안정성도 높습니다.

AWS는 이를 통해 100% SLA를 보장합니다. 비용 구조도 합리적입니다 Route 53은 사용한 만큼만 비용을 지불하는 구조입니다.

호스팅 영역 하나당 월 0.5달러, DNS 쿼리 100만 건당 0.4달러 정도입니다. 소규모 서비스라면 한 달에 1~2달러면 충분합니다.

개발자에게 친화적인 API 위의 코드 예제처럼 Route 53은 AWS SDK를 통해 프로그래밍 방식으로 제어할 수 있습니다. 도메인 등록, DNS 레코드 추가, 삭제, 수정 등 모든 작업을 코드로 자동화할 수 있습니다.

이는 인프라를 코드로 관리하는 IaC(Infrastructure as Code) 접근 방식과도 잘 맞습니다. 정리하면 박시니어 씨의 설명을 듣고 나니 김개발 씨의 머릿속이 정리되었습니다.

DNS는 도메인과 IP를 연결하는 시스템이고, Route 53은 AWS에서 제공하는 강력하고 편리한 DNS 서비스입니다. 이제 본격적으로 Route 53을 사용해서 도메인을 연결하는 방법을 배울 차례입니다.

다음 단계를 하나씩 따라가다 보면 어느새 전문가가 되어 있을 것입니다.

실전 팁

💡 - Route 53은 DNS 조회뿐만 아니라 헬스 체크, 트래픽 라우팅 정책 등 다양한 기능을 제공합니다

• 전 세계에 분산된 엣지 로케이션을 활용하여 빠른 DNS 응답 속도를 보장합니다
• AWS SDK를 활용하면 DNS 설정을 코드로 자동화할 수 있어 인프라 관리가 편리합니다

---

2. Route 53에서 도메인 등록하기

DNS의 개념을 이해한 김개발 씨는 이제 실제로 도메인을 등록해야 합니다. 팀장님이 승인해주신 예산으로 myawesomeservice.com이라는 도메인을 구매하기로 했습니다.

박시니어 씨가 옆에서 함께 화면을 보며 단계별로 알려줍니다.

도메인 등록은 인터넷에서 특정 이름을 독점적으로 사용할 수 있는 권리를 구매하는 것입니다. Route 53을 통해 도메인을 등록하면 DNS 설정까지 한 번에 처리할 수 있어 편리합니다.

도메인은 연간 단위로 구매하며, .com 도메인의 경우 보통 12~13달러 정도입니다. 등록 과정은 생각보다 간단하며, 자동으로 호스팅 영역까지 생성됩니다.

다음 코드를 살펴봅시다.

// AWS CLI로 도메인 가격 확인
aws route53domains get-domain-suggestions \
  --domain-name myawesomeservice \
  --suggestion-count 5

// 도메인 등록 가능 여부 확인
aws route53domains check-domain-availability \
  --domain-name myawesomeservice.com

// 도메인 등록 (JSON 형식)
aws route53domains register-domain \
  --domain-name myawesomeservice.com \
  --duration-in-years 1 \
  --admin-contact file://contact.json \
  --registrant-contact file://contact.json \
  --tech-contact file://contact.json

김개발 씨는 AWS 콘솔에 로그인했습니다. 서비스 목록에서 Route 53을 찾아 클릭합니다.

생각보다 인터페이스가 깔끔해서 안도의 한숨을 쉬었습니다. 도메인 등록 메뉴 찾기 Route 53 대시보드 왼쪽 메뉴를 보니 여러 항목이 있습니다.

호스팅 영역, 상태 확인, 트래픽 정책 등등. 박시니어 씨가 "도메인 등록" 메뉴를 클릭하라고 알려줍니다.

"도메인 등록" 버튼을 클릭하면 도메인 이름을 입력하는 화면이 나타납니다. 여기서 원하는 도메인 이름을 입력하면 됩니다.

김개발 씨는 myawesomeservice를 입력하고 검색 버튼을 눌렀습니다. 도메인 가용성 확인 검색 결과를 보니 myawesomeservice.com은 다행히 사용 가능합니다.

가격은 13달러로 표시됩니다. 하지만 .net 버전은 이미 누군가 사용 중이라고 나옵니다.

마치 아파트 호수를 선택하는 것과 비슷합니다. 101호가 비어있으면 선택할 수 있지만, 이미 다른 사람이 살고 있으면 선택할 수 없는 것처럼요.

도메인도 선착순입니다. 마음에 드는 도메인을 찾았다면 빨리 등록하는 것이 좋습니다.

도메인 확장자 선택의 지혜 .com, .net, .org, .io, .ai 등 다양한 확장자가 있습니다. 박시니어 씨가 조언합니다.

"서비스 특성에 맞는 확장자를 선택하세요. 일반적인 웹사이트는 .com이 좋고, 기술 스타트업은 .io도 인기 있어요." 가격도 확장자마다 다릅니다.

.com은 12~13달러지만 .io는 39달러 정도 합니다. .ai는 최근 인공지능 붐으로 인기가 높아져서 100달러가 넘기도 합니다.

예산과 브랜딩을 고려해서 선택해야 합니다. 연락처 정보 입력 도메인을 선택하고 나면 연락처 정보를 입력해야 합니다.

등록자, 관리자, 기술 담당자 세 가지 연락처가 필요합니다. 대부분의 경우 세 개 모두 같은 정보를 입력해도 됩니다.

여기서 중요한 점이 있습니다. 이메일 주소는 반드시 접근 가능한 실제 이메일이어야 합니다.

도메인 소유권 확인 메일이 이 주소로 발송되기 때문입니다. 확인하지 않으면 도메인이 정지될 수 있습니다.

개인정보 보호 옵션 연락처 입력 화면 아래를 보니 "Privacy Protection"이라는 옵션이 있습니다. 이것은 무엇일까요?

도메인 등록 정보는 공개되는 것이 원칙입니다. WHOIS 검색을 하면 누구나 도메인 소유자의 이름, 이메일, 전화번호를 볼 수 있습니다.

하지만 개인정보 보호 옵션을 활성화하면 이런 정보가 가려지고 대신 등록 대행사의 정보가 표시됩니다. 박시니어 씨가 조언합니다.

"개인 프로젝트라면 꼭 활성화하세요. 스팸 메일과 전화를 받고 싶지 않다면요." 다행히 Route 53은 대부분의 도메인에 대해 무료로 개인정보 보호를 제공합니다.

자동 갱신 설정 도메인은 1년 단위로 등록됩니다. 만약 갱신을 깜빡하면 어떻게 될까요?

도메인이 만료되고, 최악의 경우 다른 사람이 가져갈 수도 있습니다. 이를 방지하기 위해 자동 갱신 옵션이 있습니다.

체크박스 하나만 선택하면 매년 자동으로 결제되고 도메인이 갱신됩니다. 김개발 씨는 나중에 깜빡할까 봐 자동 갱신을 활성화했습니다.

결제 및 등록 완료 모든 정보를 입력하고 약관에 동의한 후 "구매" 버튼을 클릭합니다. AWS 계정에 등록된 신용카드로 결제가 진행됩니다.

13달러가 청구되었습니다. 등록이 완료되기까지는 몇 분에서 최대 3일까지 걸릴 수 있습니다.

보통 .com 도메인은 10분 이내에 완료됩니다. 하지만 일부 확장자는 수동 승인 과정이 필요해서 시간이 더 걸립니다.

이메일 확인 필수 잠시 후 김개발 씨의 이메일로 "도메인 소유권 확인" 메일이 도착했습니다. 메일 안의 링크를 클릭해서 15일 이내에 확인해야 합니다.

확인하지 않으면 도메인이 정지됩니다. 링크를 클릭하니 "확인되었습니다"라는 메시지가 나타납니다.

이제 myawesomeservice.com은 정식으로 김개발 씨의 소유가 되었습니다. 자동 생성된 호스팅 영역 Route 53 콘솔의 "호스팅 영역" 메뉴를 보니 myawesomeservice.com이라는 항목이 자동으로 생성되어 있습니다.

도메인을 등록하면 호스팅 영역이 자동으로 만들어집니다. 박시니어 씨가 설명합니다.

"이제 DNS 설정을 할 준비가 끝났어요. 다음 단계는 호스팅 영역에서 레코드를 추가하는 거예요." 정리 김개발 씨는 무사히 도메인 등록을 완료했습니다.

생각보다 간단했습니다. 중요한 것은 정확한 연락처 정보를 입력하고, 이메일 확인을 빠뜨리지 않는 것입니다.

이제 도메인을 소유했으니 실제 서버와 연결하는 작업이 남았습니다. 그 전에 호스팅 영역이 무엇인지 제대로 이해해야 합니다.

실전 팁

💡 - 도메인 소유권 확인 이메일은 15일 이내에 반드시 확인해야 도메인이 정지되지 않습니다

• 자동 갱신을 활성화해두면 도메인 만료로 인한 서비스 중단을 예방할 수 있습니다
• 개인정보 보호 옵션을 활성화하면 WHOIS 조회 시 개인정보가 노출되지 않습니다

---

3. 호스팅 영역 개념 이해하기

도메인 등록이 완료되자 Route 53 콘솔에 "호스팅 영역(Hosted Zone)"이라는 것이 자동으로 생성되었습니다. 김개발 씨는 이것이 무엇인지 궁금했습니다.

박시니어 씨가 화이트보드를 꺼내들며 설명을 시작합니다.

호스팅 영역은 특정 도메인에 대한 DNS 레코드를 모아놓은 컨테이너입니다. 마치 주소록이 연락처 정보를 모아두듯이, 호스팅 영역은 도메인의 모든 DNS 설정을 한곳에 모아둡니다.

하나의 도메인당 하나의 호스팅 영역이 필요하며, 여기에 A 레코드, CNAME 레코드 등을 추가합니다. 호스팅 영역에는 퍼블릭과 프라이빗 두 가지 유형이 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK로 호스팅 영역 생성
const AWS = require('aws-sdk');
const route53 = new AWS.Route53();

const params = {
  CallerReference: Date.now().toString(), // 고유 식별자
  Name: 'myawesomeservice.com', // 도메인 이름
  HostedZoneConfig: {
    Comment: '우리 서비스의 메인 도메인',
    PrivateZone: false // 퍼블릭 호스팅 영역
  }
};

route53.createHostedZone(params, (err, data) => {
  if (err) {
    console.log('호스팅 영역 생성 실패:', err);
  } else {
    console.log('호스팅 영역 ID:', data.HostedZone.Id);
    console.log('네임서버:', data.DelegationSet.NameServers);
  }
});

박시니어 씨가 화이트보드에 큰 상자를 그렸습니다. "호스팅 영역은 이 상자와 같아요.

도메인과 관련된 모든 DNS 정보를 이 안에 넣어두는 거죠." 호스팅 영역은 DNS 데이터의 집합소 쉽게 비유하자면 호스팅 영역은 도서관의 카탈로그 시스템과 같습니다. 도서관에 책이 많을 때 어떻게 찾을까요?

카탈로그를 보고 "컴퓨터 서적은 3층 B구역"이라는 정보를 얻습니다. 호스팅 영역도 마찬가지입니다.

"myawesomeservice.com으로 접속하면 어디로 가야 하나요?"라는 질문에 대한 답을 이 안에 정리해둡니다. "메인 페이지는 54.123.45.67 서버로, 이미지는 CDN으로" 같은 정보들이 모두 여기 들어 있습니다.

호스팅 영역을 열어보면 Route 53 콘솔에서 myawesomeservice.com 호스팅 영역을 클릭해봅니다. 안을 보니 이미 두 개의 레코드가 자동으로 생성되어 있습니다.

첫 번째는 NS 레코드입니다. NS는 Name Server의 약자로, 이 도메인의 DNS 정보를 어느 서버가 관리하는지 알려줍니다.

ns-123.awsdns-12.com 같은 주소 네 개가 나열되어 있습니다. 두 번째는 SOA 레코드입니다.

SOA는 Start of Authority의 약자로, 이 호스팅 영역의 기본 설정과 관리 정보를 담고 있습니다. 이 두 레코드는 자동으로 생성되며 함부로 수정하면 안 됩니다.

퍼블릭 vs 프라이빗 호스팅 영역 박시니어 씨가 중요한 개념을 짚어줍니다. "호스팅 영역에는 두 가지 종류가 있어요.

퍼블릭과 프라이빗입니다." 퍼블릭 호스팅 영역은 인터넷 전체에 공개되는 DNS 정보를 담습니다. 우리가 일반적으로 웹사이트를 만들 때 사용하는 것이 이것입니다.

전 세계 누구나 이 DNS 정보를 조회할 수 있습니다. 프라이빗 호스팅 영역은 AWS VPC 내부에서만 사용하는 DNS 정보를 담습니다.

예를 들어 회사 내부 시스템끼리만 통신하는 도메인 database.internal.company.com 같은 것을 설정할 때 사용합니다. 외부에서는 절대 접근할 수 없습니다.

네임서버의 역할 호스팅 영역을 만들면 네임서버 주소 네 개가 자동으로 할당됩니다. 이것이 왜 중요할까요?

도메인 등록 대행사에 이 네임서버 주소를 알려줘야 DNS가 작동합니다. 마치 우체국에 이사한 새 주소를 알려주는 것과 같습니다.

"myawesomeservice.com에 대한 정보는 이 네임서버에 물어보세요"라고 등록하는 것입니다. 다행히 Route 53에서 도메인을 등록했다면 이 과정이 자동으로 처리됩니다.

하지만 다른 곳에서 도메인을 샀다면 수동으로 네임서버를 변경해줘야 합니다. 호스팅 영역의 비용 호스팅 영역 하나당 월 0.5달러의 비용이 발생합니다.

작은 금액이지만 호스팅 영역을 여러 개 만들면 비용이 늘어나므로 주의해야 합니다. 김개발 씨가 걱정스럽게 물었습니다.

"그럼 서브도메인마다 호스팅 영역을 만들어야 하나요?" 박시니어 씨가 고개를 저었습니다. "아니요, 하나의 호스팅 영역 안에 여러 서브도메인 레코드를 추가할 수 있어요." 레코드 추가 준비 호스팅 영역은 비어있는 노트와 같습니다.

이제 여기에 실제 DNS 정보, 즉 레코드를 추가해야 합니다. "www.myawesomeservice.com은 여기로", "api.myawesomeservice.com은 저기로" 같은 정보를 하나씩 적어 넣는 것입니다.

여러 환경 관리하기 실무에서는 개발, 스테이징, 프로덕션 같은 여러 환경을 운영합니다. 각 환경마다 별도의 도메인을 사용할 수도 있습니다.

dev.myservice.com, staging.myservice.com, www.myservice.com 같은 식으로요. 이런 경우 모두 하나의 호스팅 영역에서 관리할 수 있습니다.

각각을 서브도메인으로 설정하면 되기 때문입니다. 굳이 호스팅 영역을 여러 개 만들 필요가 없습니다.

호스팅 영역 삭제 시 주의사항 테스트로 만든 호스팅 영역을 삭제할 때는 조심해야 합니다. NS와 SOA 레코드를 제외한 모든 레코드를 먼저 삭제해야 호스팅 영역을 삭제할 수 있습니다.

또한 삭제하면 바로 복구할 수 없습니다. 실수로 프로덕션 호스팅 영역을 삭제하면 서비스 전체가 마비됩니다.

IAM 권한 설정으로 중요한 호스팅 영역은 삭제하지 못하도록 보호하는 것이 좋습니다. 정리 김개발 씨는 이제 호스팅 영역이 무엇인지 확실히 이해했습니다.

도메인의 DNS 정보를 담는 컨테이너이고, 여기에 다양한 레코드를 추가해서 트래픽을 원하는 곳으로 보낼 수 있습니다. 다음 단계는 실제로 레코드를 추가하는 것입니다.

하지만 그 전에 레코드 타입이 무엇인지 알아야 합니다.

실전 팁

💡 - 하나의 호스팅 영역에서 여러 서브도메인을 관리할 수 있어 비용 효율적입니다

• 프라이빗 호스팅 영역을 사용하면 VPC 내부에서만 사용하는 도메인을 안전하게 관리할 수 있습니다
• 호스팅 영역 삭제 전에 반드시 모든 레코드를 삭제해야 하며, 실수 방지를 위해 IAM 권한으로 보호하세요

---

4. 레코드 타입 이해하기

호스팅 영역에서 "레코드 생성" 버튼을 누르자 레코드 유형을 선택하는 드롭다운이 나타났습니다. A, AAAA, CNAME, MX, TXT 등 알 수 없는 약자들이 가득합니다.

김개발 씨는 어떤 것을 선택해야 할지 막막했습니다.

DNS 레코드 타입은 도메인과 리소스를 연결하는 방식을 정의합니다. A 레코드는 도메인을 IPv4 주소로 연결하고, CNAME 레코드는 도메인을 다른 도메인으로 연결합니다.

각 레코드 타입마다 용도가 다르며, 상황에 맞게 적절한 타입을 선택해야 합니다. 가장 많이 사용하는 것은 A 레코드와 CNAME 레코드입니다.

다음 코드를 살펴봅시다.

// AWS SDK로 A 레코드 생성
const AWS = require('aws-sdk');
const route53 = new AWS.Route53();

const params = {
  HostedZoneId: '/hostedzone/Z1234567890ABC',
  ChangeBatch: {
    Changes: [{
      Action: 'CREATE',
      ResourceRecordSet: {
        Name: 'www.myawesomeservice.com',
        Type: 'A', // A 레코드 타입
        TTL: 300, // 5분 캐싱
        ResourceRecords: [{
          Value: '54.123.45.67' // 서버 IP 주소
        }]
      }
    }]
  }
};

route53.changeResourceRecordSets(params, (err, data) => {
  if (err) console.log('레코드 생성 실패:', err);
  else console.log('A 레코드 생성 완료:', data.ChangeInfo.Id);
});

박시니어 씨가 노트북을 열어 레코드 타입 목록을 보여줍니다. "걱정하지 마세요.

실무에서 자주 쓰는 건 몇 가지뿐이에요." A 레코드 - 가장 기본적인 레코드 A 레코드는 Address의 A입니다. 도메인 이름을 IPv4 주소로 연결합니다.

가장 기본적이고 가장 많이 사용하는 레코드 타입입니다. 예를 들어 www.myawesomeservice.com을 54.123.45.67로 연결하고 싶다면 A 레코드를 만듭니다.

사용자가 www.myawesomeservice.com을 입력하면 DNS는 "이 주소는 54.123.45.67입니다"라고 답변합니다. 마치 전화번호부에서 이름을 찾으면 전화번호가 나오는 것과 같습니다.

도메인 이름을 찾으면 IP 주소가 나오는 것이죠. AAAA 레코드 - IPv6 버전 AAAA 레코드는 A 레코드의 IPv6 버전입니다.

IPv6 주소는 2001:0db8:85a3::8a2e:0370:7334 같은 형식으로 훨씬 깁니다. 아직 대부분의 서비스가 IPv4를 사용하지만, 점차 IPv6로 전환되고 있습니다.

미래를 대비해서 A 레코드와 AAAA 레코드를 함께 설정하는 것이 좋습니다. CNAME 레코드 - 별명 만들기 CNAME은 Canonical Name의 약자로, 도메인의 별명을 만들 때 사용합니다.

A 레코드처럼 IP 주소를 직접 지정하는 대신 다른 도메인을 가리킵니다. 예를 들어 blog.myawesomeservice.com을 myawesomeservice.github.io로 연결하고 싶다면 CNAME 레코드를 사용합니다.

김개발 씨가 물었습니다. "왜 A 레코드로 직접 IP를 연결하지 않나요?" 박시니어 씨가 설명합니다.

"GitHub Pages 같은 서비스는 IP 주소가 수시로 바뀔 수 있어요. 하지만 도메인은 항상 유지됩니다.

CNAME으로 연결하면 IP가 바뀌어도 자동으로 따라갑니다." CNAME의 제약사항 중요한 규칙이 있습니다. 루트 도메인에는 CNAME을 사용할 수 없습니다. 예를 들어 myawesomeservice.com(www 없이)에는 CNAME을 설정할 수 없습니다.

오직 서브도메인에만 사용 가능합니다. 이것은 DNS 표준의 제약입니다.

루트 도메인에는 항상 A 레코드를 사용해야 합니다. 다행히 Route 53에는 이 문제를 해결하는 Alias 레코드라는 특별한 기능이 있습니다.

Alias 레코드 - Route 53의 특별한 기능 Alias 레코드는 Route 53만의 독특한 기능입니다. CNAME처럼 다른 리소스를 가리키지만 루트 도메인에도 사용할 수 있습니다.

더 좋은 점은 AWS 리소스를 가리킬 때 무료라는 것입니다. ELB, CloudFront, S3 웹사이트 등을 가리키는 Alias 레코드는 DNS 쿼리 비용이 들지 않습니다.

일반 CNAME은 쿼리당 비용이 발생하는 것과 대조적입니다. MX 레코드 - 이메일 설정 MX는 Mail eXchange의 약자로, 이메일 서버를 지정할 때 사용합니다.

도메인으로 이메일을 받으려면 MX 레코드가 필요합니다. 예를 들어 contact@myawesomeservice.com으로 메일을 받으려면 MX 레코드를 추가해야 합니다.

Gmail이나 Office 365 같은 서비스를 사용한다면 해당 서비스에서 제공하는 MX 레코드 값을 입력하면 됩니다. TXT 레코드 - 텍스트 정보 저장 TXT 레코드는 임의의 텍스트 정보를 저장합니다.

주로 도메인 소유권 확인이나 이메일 인증에 사용됩니다. 예를 들어 Google Search Console에 사이트를 등록하려면 "google-site-verification=xxxxx" 같은 TXT 레코드를 추가해야 합니다.

SPF, DKIM 같은 이메일 인증 정보도 TXT 레코드로 설정합니다. TTL - Time To Live 이해하기 모든 레코드에는 TTL 값이 있습니다.

이것은 DNS 정보를 얼마나 오래 캐싱할지 결정합니다. 단위는 초입니다.

TTL을 300으로 설정하면 5분 동안 캐싱됩니다. 이 시간 동안은 DNS 서버가 Route 53에 다시 묻지 않고 저장된 답변을 사용합니다.

TTL이 길면 DNS 쿼리 비용이 줄지만, 레코드를 변경했을 때 반영이 느립니다. 박시니어 씨가 조언합니다.

"평소에는 3600(1시간) 정도로 설정하고, 서버 IP를 변경할 계획이 있다면 미리 300(5분)으로 낮추세요." 실전에서 자주 쓰는 조합 대부분의 웹사이트는 다음과 같은 레코드 조합을 사용합니다. 루트 도메인(myawesomeservice.com)은 A 레코드로 서버 IP를 가리킵니다.

www 서브도메인은 CNAME으로 루트를 가리키거나, 별도의 A 레코드를 만듭니다. API 서버는 api.myawesomeservice.com으로 별도의 A 레코드를 만듭니다.

이미지나 정적 파일은 cdn.myawesomeservice.com으로 CloudFront를 가리키는 Alias 레코드를 만듭니다. 레코드 우선순위 MX 레코드처럼 일부 레코드는 우선순위 값을 가집니다.

숫자가 낮을수록 우선순위가 높습니다. 메일 서버가 여러 개일 때 어느 서버를 먼저 시도할지 결정하는 값입니다.

정리 김개발 씨는 이제 레코드 타입의 차이를 이해했습니다. IP 주소로 직접 연결할 때는 A 레코드, 다른 도메인으로 연결할 때는 CNAME, AWS 리소스를 가리킬 때는 Alias를 사용하면 됩니다.

이제 실제로 ELB에 도메인을 연결하는 실습을 해볼 차례입니다.

실전 팁

💡 - AWS 리소스를 가리킬 때는 Alias 레코드를 사용하면 DNS 쿼리 비용이 무료입니다

• 서버 IP 변경 전에 TTL을 미리 낮춰두면 빠르게 반영됩니다
• 루트 도메인에는 CNAME을 사용할 수 없지만 Alias 레코드로 해결 가능합니다

---

5. ELB와 도메인 연결 실습

드디어 실전입니다. 김개발 씨의 웹 애플리케이션은 AWS ELB(Elastic Load Balancer) 뒤에서 실행되고 있습니다.

현재는 myapp-elb-1234567890.ap-northeast-2.elb.amazonaws.com 같은 긴 주소로 접속해야 합니다. 이제 www.myawesomeservice.com으로 접속할 수 있게 만들어봅시다.

ELB에 도메인을 연결하는 것은 Route 53의 Alias 레코드를 사용하면 간단합니다. A 레코드를 만들면서 Alias 옵션을 활성화하고 ELB를 선택하면 됩니다.

이 방식은 IP 주소를 직접 입력하지 않아도 되고, ELB의 IP가 바뀌어도 자동으로 따라갑니다. 또한 DNS 쿼리 비용도 무료입니다.

다음 코드를 살펴봅시다.

// AWS SDK로 ELB Alias 레코드 생성
const AWS = require('aws-sdk');
const route53 = new AWS.Route53();

const params = {
  HostedZoneId: '/hostedzone/Z1234567890ABC',
  ChangeBatch: {
    Changes: [{
      Action: 'CREATE',
      ResourceRecordSet: {
        Name: 'www.myawesomeservice.com',
        Type: 'A', // A 레코드이지만
        AliasTarget: { // Alias로 설정
          HostedZoneId: 'Z12345ABCDEFGH', // ELB의 호스팅 영역 ID
          DNSName: 'myapp-elb-1234567890.ap-northeast-2.elb.amazonaws.com',
          EvaluateTargetHealth: true // 헬스 체크 활성화
        }
      }
    }]
  }
};

route53.changeResourceRecordSets(params, (err, data) => {
  if (err) console.log('Alias 레코드 생성 실패:', err);
  else console.log('ELB 연결 완료:', data.ChangeInfo.Id);
});

김개발 씨는 Route 53 콘솔에서 myawesomeservice.com 호스팅 영역을 열었습니다. "레코드 생성" 버튼이 눈에 들어옵니다.

클릭해봅니다. 레코드 생성 화면 살펴보기 레코드 이름을 입력하는 필드가 보입니다.

여기에 "www"를 입력합니다. 그러면 최종 도메인은 www.myawesomeservice.com이 됩니다.

만약 비워두면 루트 도메인인 myawesomeservice.com이 됩니다. 레코드 유형은 "A - IPv4 주소로 트래픽 라우팅"을 선택합니다.

그 아래를 보니 "별칭(Alias)" 스위치가 있습니다. 이것을 켭니다.

Alias 타겟 선택하기 Alias를 활성화하자 화면이 바뀌었습니다. IP 주소를 입력하는 대신 "트래픽 라우팅 대상"을 선택할 수 있습니다.

드롭다운을 열어보니 여러 옵션이 있습니다. "Application/Classic Load Balancer에 대한 별칭", "CloudFront 배포에 대한 별칭", "S3 웹사이트 엔드포인트에 대한 별칭" 등등.

김개발 씨는 첫 번째 옵션을 선택했습니다. 리전과 ELB 선택 리전을 선택하는 드롭다운이 나타났습니다.

김개발 씨의 ELB는 서울 리전(ap-northeast-2)에 있으므로 "아시아 태평양(서울)"을 선택합니다. 그러자 마법처럼 해당 리전의 모든 로드밸런서 목록이 나타났습니다.

myapp-elb가 보입니다. 클릭해서 선택합니다.

박시니어 씨가 감탄합니다. "Route 53이 자동으로 ELB를 찾아주니까 정말 편하죠?" 헬스 체크 옵션 아래쪽에 "대상 상태 평가" 체크박스가 있습니다.

이것은 무엇일까요? 박시니어 씨가 설명합니다.

"ELB는 자체적으로 헬스 체크를 합니다. 서버가 정상인지 확인하는 거죠.

이 옵션을 켜면 Route 53도 ELB의 헬스 체크 결과를 확인합니다. 만약 ELB가 비정상이면 DNS 쿼리에 응답하지 않습니다." 대부분의 경우 이 옵션을 켜는 것이 좋습니다.

서버에 문제가 있을 때 사용자를 보내지 않기 때문입니다. TTL은 어디 갔나요 김개발 씨는 이상한 점을 발견했습니다.

Alias 레코드에는 TTL 입력 필드가 없습니다. "TTL을 설정 안 해도 되나요?" 박시니어 씨가 답합니다.

"Alias 레코드는 TTL을 자동으로 설정해요. ELB의 경우 60초로 고정됩니다.

우리가 직접 조정할 수 없어요." 이것은 Alias 레코드의 특성입니다. AWS가 최적의 값으로 자동 관리하므로 신경 쓸 필요가 없습니다.

레코드 생성 완료 모든 설정을 마치고 "레코드 생성" 버튼을 클릭합니다. 잠시 후 "레코드가 생성되었습니다"라는 메시지가 나타납니다.

호스팅 영역 목록을 보니 새로운 A 레코드가 추가되었습니다. 이름은 www.myawesomeservice.com이고, 유형은 A, 값은 myapp-elb-1234567890.ap-northeast-2.elb.amazonaws.com입니다.

Alias 열에 "예"라고 표시되어 있습니다. 루트 도메인도 연결하기 www.myawesomeservice.com은 설정했는데, myawesomeservice.com(www 없이)으로 접속하면 어떻게 될까요?

아직 설정하지 않았으므로 접속되지 않습니다. 박시니어 씨가 제안합니다.

"루트 도메인도 같은 ELB로 연결하는 게 좋아요. 사용자들이 www를 빼먹고 입력하는 경우가 많거든요." 같은 방법으로 레코드를 하나 더 만듭니다.

이번에는 레코드 이름을 비워둡니다. 그러면 루트 도메인이 됩니다.

나머지 설정은 동일합니다. HTTPS를 위한 인증서 준비 ELB에 도메인을 연결했지만, HTTPS를 사용하려면 SSL/TLS 인증서가 필요합니다.

AWS Certificate Manager(ACM)에서 무료로 발급받을 수 있습니다. 인증서를 요청하면 도메인 소유권을 확인해야 합니다.

DNS 검증 방식을 선택하면 ACM이 Route 53 레코드를 자동으로 추가해줍니다. 정말 편리합니다.

여러 도메인을 하나의 ELB로 하나의 ELB에 여러 도메인을 연결할 수도 있습니다. 예를 들어 myawesomeservice.com과 myawesomeservice.net을 모두 같은 ELB로 보낼 수 있습니다.

각 도메인마다 Alias 레코드를 만들면 됩니다. ELB 리스너 규칙에서 호스트 헤더를 확인해 도메인별로 다른 처리를 할 수도 있습니다.

변경 사항 전파 확인 레코드를 생성했다고 바로 작동하는 것은 아닙니다. DNS 변경 사항이 전 세계로 전파되는 데 시간이 걸립니다.

Route 53은 보통 60초 이내에 전파되지만, 다른 DNS 서버의 캐시 때문에 완전히 반영되려면 최대 48시간까지 걸릴 수 있습니다. 하지만 실제로는 몇 분 안에 대부분의 지역에서 작동합니다.

김개발 씨는 5분 정도 기다린 후 브라우저에 www.myawesomeservice.com을 입력했습니다. 성공입니다 웹사이트가 정상적으로 열렸습니다.

주소창을 보니 www.myawesomeservice.com이라고 표시됩니다. 더 이상 긴 ELB 주소를 외울 필요가 없습니다.

김개발 씨는 감격했습니다. "드디어 제대로 된 도메인으로 서비스할 수 있게 됐어요!" 박시니어 씨가 축하의 박수를 보냅니다.

정리 Route 53의 Alias 레코드를 사용하면 ELB에 도메인을 매우 쉽게 연결할 수 있습니다. IP 주소를 신경 쓸 필요도 없고, 비용도 무료이며, 헬스 체크까지 지원합니다.

이제 마지막으로 도메인 전파 과정과 확인 방법을 알아보겠습니다.

실전 팁

💡 - Alias 레코드로 ELB를 연결하면 DNS 쿼리 비용이 무료입니다

• 대상 상태 평가 옵션을 활성화하면 ELB가 비정상일 때 트래픽을 보내지 않습니다
• 루트 도메인과 www 서브도메인을 모두 설정하면 사용자 편의성이 높아집니다

---

6. 도메인 전파 시간과 확인 방법

도메인 연결을 완료한 김개발 씨는 친구에게 자랑하려고 링크를 보냈습니다. 그런데 친구는 "접속이 안 되는데요?"라고 답했습니다.

김개발 씨의 컴퓨터에서는 잘 되는데 왜 그럴까요? 박시니어 씨가 "아, DNS 전파 때문이군요"라고 말합니다.

DNS 전파는 DNS 레코드 변경 사항이 전 세계의 DNS 서버에 퍼지는 과정입니다. Route 53에서 레코드를 변경하면 자체 네임서버에는 즉시 반영되지만, 다른 DNS 서버들이 이 정보를 가져가는 데 시간이 걸립니다.

TTL 값에 따라 캐시가 유지되고, 완전한 전파는 최대 48시간까지 걸릴 수 있습니다. dig, nslookup 같은 도구로 전파 상태를 확인할 수 있습니다.

다음 코드를 살펴봅시다.

// Node.js에서 DNS 조회하기
const dns = require('dns');

// A 레코드 조회
dns.resolve4('www.myawesomeservice.com', (err, addresses) => {
  if (err) {
    console.log('DNS 조회 실패:', err.message);
  } else {
    console.log('IP 주소:', addresses);
    // 예: ['54.123.45.67']
  }
});

// 모든 레코드 타입 조회
dns.resolveAny('myawesomeservice.com', (err, records) => {
  if (err) console.log('조회 실패:', err);
  else {
    console.log('DNS 레코드:', records);
    // NS, SOA, A, MX 등 모든 레코드 출력
  }
});

김개발 씨는 당황했습니다. 분명히 자기 컴퓨터에서는 잘 작동하는데 친구는 안 된다니요.

혹시 설정을 잘못했을까요? DNS 전파의 원리 박시니어 씨가 화이트보드에 그림을 그리며 설명합니다.

"DNS는 계층 구조로 되어 있어요. Route 53에서 레코드를 변경하면 Route 53의 네임서버에는 즉시 반영됩니다.

하지만 문제는 중간의 다른 DNS 서버들이에요." 인터넷에는 수많은 DNS 서버가 있습니다. ISP(인터넷 서비스 제공자)의 DNS 서버, 구글의 8.8.8.8, 클라우드플레어의 1.1.1.1 등등.

이 서버들은 성능 향상을 위해 DNS 응답을 캐싱합니다. TTL이 핵심입니다 바로 여기서 TTL이 중요해집니다.

앞서 배웠듯이 TTL은 DNS 레코드를 얼마나 오래 캐싱할지 결정합니다. 예를 들어 TTL이 3600초(1시간)이라면, DNS 서버는 1시간 동안 같은 답변을 계속 사용합니다.

그 사이에 Route 53에서 레코드를 변경해도 DNS 서버는 알 수 없습니다. 1시간이 지나야 다시 물어보고 새로운 값을 가져갑니다.

왜 친구는 접속이 안 될까요 김개발 씨는 레코드를 만든 직후 접속했으므로 최신 DNS 정보를 받았습니다. 하지만 친구의 ISP DNS 서버는 아직 이전 정보를 캐싱하고 있을 수 있습니다.

또는 친구의 컴퓨터 자체에서 DNS 캐시를 가지고 있을 수도 있습니다. 윈도우와 맥OS는 모두 로컬 DNS 캐시를 유지합니다.

전파 시간은 얼마나 걸릴까요 Route 53 자체는 매우 빠릅니다. 레코드를 변경하면 보통 60초 이내에 모든 Route 53 네임서버에 반영됩니다.

하지만 완전한 전파는 다릅니다. 업계에서는 "DNS 전파에 최대 48시간"이라고 말합니다.

실제로는 대부분 몇 시간 안에 완료됩니다. 하지만 극단적인 경우 이틀이 걸릴 수도 있습니다.

TTL 값에 따라 달라집니다. 전파 상태 확인하는 방법 터미널을 열어 dig 명령어를 사용해봅니다.

dig는 DNS 조회를 위한 강력한 도구입니다. dig www.myawesomeservice.com 결과를 보면 ANSWER SECTION에 현재 DNS 응답이 표시됩니다.

또한 Query time과 SERVER 정보로 어느 DNS 서버가 응답했는지 알 수 있습니다. 특정 네임서버에 직접 물어보기 Route 53 네임서버에 직접 물어볼 수도 있습니다.

이렇게 하면 최신 정보를 확인할 수 있습니다. dig @ns-123.awsdns-12.com www.myawesomeservice.com @ns-123.awsdns-12.com 부분은 호스팅 영역의 NS 레코드에서 확인할 수 있습니다.

이 명령은 Route 53 네임서버에 직접 질의하므로 항상 최신 정보를 받습니다. Windows에서는 nslookup 윈도우에서는 dig 대신 nslookup을 사용합니다.

nslookup www.myawesomeservice.com 결과가 dig보다 간단하지만 기본적인 정보는 확인할 수 있습니다. Server 부분을 보면 어느 DNS 서버가 응답했는지 알 수 있습니다.

온라인 DNS 전파 체크 도구 whatsmydns.net 같은 웹사이트를 사용하면 전 세계 여러 지역에서 DNS 조회를 동시에 테스트할 수 있습니다. 서울, 도쿄, 런던, 뉴욕 등 각 지역의 DNS 서버에서 어떤 응답이 오는지 한눈에 볼 수 있습니다.

초록색 체크 표시가 많을수록 전파가 잘 된 것입니다. 빨간색 X 표시가 있다면 아직 그 지역에는 전파되지 않은 것입니다.

로컬 DNS 캐시 비우기 컴퓨터의 DNS 캐시를 비우면 강제로 최신 정보를 가져올 수 있습니다. 맥OS에서는 터미널에서 다음 명령을 실행합니다.

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder 윈도우에서는 명령 프롬프트를 관리자 권한으로 열고 다음을 실행합니다. ipconfig /flushdns 이렇게 하면 컴퓨터가 DNS 캐시를 버리고 새로 조회합니다.

전파를 빠르게 하는 전략 중요한 서버 변경을 계획한다면 미리 TTL을 낮춰두는 것이 좋습니다. 예를 들어 현재 TTL이 3600(1시간)이라면, 변경 하루 전에 300(5분)으로 낮춥니다.

그러면 변경 시점에는 대부분의 DNS 서버가 5분짜리 캐시를 가지고 있으므로 빠르게 전파됩니다. 변경이 완료되고 안정화되면 다시 TTL을 올려도 됩니다.

정리 김개발 씨는 이제 DNS 전파의 원리를 이해했습니다. 친구에게 "몇 시간 후에 다시 시도해 보세요.

또는 DNS 캐시를 비워보세요"라고 답장을 보냈습니다. DNS는 분산 시스템이기 때문에 즉각적인 변경이 어렵습니다.

하지만 이 특성 덕분에 안정적이고 확장 가능한 시스템이 될 수 있었습니다. 조금의 인내심을 가지면 곧 전 세계 어디서나 도메인으로 접속할 수 있게 됩니다.

축하합니다 김개발 씨는 Route 53의 모든 핵심 개념을 마스터했습니다. DNS의 원리부터 도메인 등록, 호스팅 영역 관리, 레코드 타입 선택, ELB 연결, 그리고 전파 과정까지 모두 배웠습니다.

이제 자신감 있게 도메인을 관리할 수 있습니다.

실전 팁

💡 - 중요한 서버 변경 전에는 미리 TTL을 낮춰서 빠른 전파를 준비하세요

• dig나 nslookup으로 Route 53 네임서버에 직접 질의하면 최신 정보를 확인할 수 있습니다
• whatsmydns.net 같은 온라인 도구로 전 세계 전파 상태를 한눈에 확인하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!