Route 53 DNS 관리 완벽 가이드

AWS Route 53을 활용한 DNS 관리 방법을 초급 개발자를 위해 쉽게 설명합니다. 도메인 등록부터 레코드 설정, 네임서버 구성까지 실무에 필요한 모든 내용을 담았습니다.

1. Route 53 소개

이번 상황을 살펴봅시다. 김개발 씨는 처음으로 회사의 새로운 서비스를 배포하게 되었습니다.

EC2 인스턴스도 띄웠고, 애플리케이션도 잘 동작합니다. 그런데 선배가 물었습니다.

"IP 주소 말고 도메인으로 접속하게 해야 하는데, DNS 설정 해봤어요?"

Route 53 소개 Route 53은 AWS에서 제공하는 DNS 웹 서비스입니다. 마치 전화번호부가 이름을 보고 전화번호를 찾아주듯이, 도메인 이름을 IP 주소로 변환해줍니다.

이를 통해 사용자들은 복잡한 IP 주소 대신 기억하기 쉬운 도메인 이름으로 서비스에 접속할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK를 이용한 Route 53 클라이언트 초기화
const AWS = require('aws-sdk');

// Route 53 클라이언트 생성
const route53 = new AWS.Route53({
  region: 'us-east-1',
  accessKeyId: process.env.AWS_ACCESS_KEY_ID,
  secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
});

// 호스팅 영역 목록 조회
route53.listHostedZones({}, (err, data) => {
  if (err) console.log(err);
  else console.log('호스팅 영역:', data.HostedZones);
});

실무에서 DNS를 만나다 김개발 씨는 지금까지 localhost나 IP 주소로만 서비스를 테스트해왔습니다. 그런데 실제 서비스를 운영하려면 myservice.com 같은 도메인이 필요하다는 것을 알게 되었습니다.

선배 개발자 박시니어 씨가 설명을 시작했습니다. "김개발 씨, 사용자들이 우리 서비스에 접속할 때 192.168.1.100 같은 IP 주소를 외워서 입력한다고 상상해보세요.

얼마나 불편할까요?" DNS란 무엇인가 DNS는 Domain Name System의 약자입니다. 쉽게 비유하자면, 인터넷의 전화번호부라고 할 수 있습니다.

우리가 친구에게 전화할 때 번호를 직접 외우지 않고 이름으로 검색하듯이, DNS는 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환해줍니다. 예를 들어 사용자가 브라우저에 www.example.com을 입력하면, DNS 서버가 이것을 실제 서버의 IP 주소인 203.0.113.1로 바꿔줍니다.

이 모든 과정이 눈 깜짝할 사이에 일어납니다. 왜 Route 53인가 AWS가 제공하는 여러 서비스 중에서도 Route 53은 특별합니다.

이름이 재미있는데, 53번 포트가 DNS에서 사용하는 표준 포트 번호이기 때문에 붙여진 이름입니다. Route 53은 단순히 DNS 서비스만 제공하는 것이 아닙니다.

도메인 등록, 헬스 체크, 트래픽 라우팅 정책 등 다양한 기능을 제공합니다. 특히 AWS의 다른 서비스들과 완벽하게 통합된다는 점이 큰 장점입니다.

Route 53 없이 개발하던 시절 옛날에는 DNS 설정이 복잡했습니다. 별도의 DNS 호스팅 업체를 찾아야 했고, 설정 변경이 반영되는 데 몇 시간씩 걸리기도 했습니다.

문제가 생겨도 어디서 발생한 건지 찾기 어려웠습니다. 더 큰 문제는 확장성이었습니다.

트래픽이 급증하면 DNS 서버가 버티지 못해 서비스 전체가 마비되는 일도 있었습니다. 백업 DNS를 따로 구성하는 것도 만만치 않은 작업이었습니다.

Route 53의 등장 Route 53은 이런 문제들을 깔끔하게 해결했습니다. 먼저 높은 가용성을 제공합니다.

AWS의 글로벌 인프라를 활용하여 전 세계 어디서든 빠른 응답 속도를 보장합니다. 설정 변경도 거의 즉시 반영됩니다.

콘솔에서 클릭 몇 번이면 레코드를 추가하거나 수정할 수 있습니다. API를 통한 자동화도 쉽습니다.

위의 코드처럼 AWS SDK를 사용하면 프로그래밍 방식으로 DNS를 관리할 수 있습니다. 코드 분석 위의 예제 코드를 살펴보겠습니다.

먼저 AWS SDK를 불러온 후, Route 53 클라이언트를 생성합니다. 이때 리전과 인증 정보를 설정해야 합니다.

listHostedZones 메서드는 현재 계정에 생성된 모든 호스팅 영역을 조회합니다. 호스팅 영역은 하나의 도메인에 대한 DNS 레코드들을 담는 컨테이너라고 생각하면 됩니다.

예를 들어 example.com 도메인을 관리한다면, 이 도메인을 위한 호스팅 영역이 하나 생성됩니다. 실무에서의 활용 실제 현업에서는 어떻게 사용할까요?

예를 들어 쇼핑몰 서비스를 운영한다고 가정해봅시다. 메인 사이트는 www.shopping.com, API 서버는 api.shopping.com, 관리자 페이지는 admin.shopping.com으로 분리하여 운영할 수 있습니다.

Route 53을 사용하면 이 모든 서브도메인을 하나의 호스팅 영역에서 관리할 수 있습니다. 각 서브도메인마다 다른 서버로 연결할 수도 있고, 로드 밸런서를 연결할 수도 있습니다.

비용 절감 효과 많은 사람들이 놀라는 부분이 바로 비용입니다. Route 53은 사용한 만큼만 비용을 지불하는 종량제입니다.

호스팅 영역 하나당 월 0.5달러, DNS 쿼리 100만 건당 0.4달러 정도로 매우 저렴합니다. 게다가 AWS 내부 서비스 간 통신에는 DNS 쿼리 비용이 발생하지 않습니다.

EC2 인스턴스가 같은 VPC 내의 다른 서비스를 도메인으로 호출해도 무료입니다. 주의할 점 초보 개발자들이 흔히 하는 실수가 있습니다.

Route 53에서 도메인을 등록하거나 레코드를 설정했다고 해서 바로 작동하는 것은 아닙니다. DNS 변경사항이 전 세계로 전파되는 데 시간이 걸립니다.

이를 **TTL(Time To Live)**이라고 합니다. 급하게 설정을 바꿨는데 반영이 안 된다고 당황하지 마세요.

보통 몇 분에서 최대 48시간 정도 걸릴 수 있습니다. 물론 실제로는 대부분 몇 분 내에 반영됩니다.

다시 김개발 씨의 이야기로 박시니어 씨의 설명을 들은 김개발 씨는 이해했다는 표정을 지었습니다. "그러니까 Route 53은 도메인과 서버를 연결해주는 다리 역할을 하는 거네요!" 정확합니다.

Route 53을 제대로 이해하면 안정적이고 확장 가능한 서비스 인프라를 구축할 수 있습니다. 다음 섹션에서는 실제로 도메인을 등록하는 방법을 알아보겠습니다.

실전 팁

💡 실전 팁

Route 53은 99.99%의 SLA를 보장하므로 프로덕션 환경에서도 안심하고 사용할 수 있습니다.
AWS Certificate Manager와 함께 사용하면 무료 SSL 인증서를 쉽게 발급받을 수 있습니다.
CloudWatch와 연동하여 DNS 쿼리를 모니터링하고 이상 징후를 빠르게 감지할 수 있습니다.

2. 도메인 등록

첫 도메인 구매하기 김개발 씨는 Route 53의 개념을 이해했습니다. 이제 실제로 도메인을 등록해야 합니다.

박시니어 씨가 물었습니다. "어떤 도메인 이름으로 하실 건가요?

도메인은 한 번 정하면 바꾸기 어려우니 신중하게 선택해야 해요."

도메인 등록하기 도메인 등록은 원하는 도메인 이름을 구매하여 소유권을 얻는 과정입니다. Route 53에서는 도메인 검색부터 결제까지 모든 과정을 한 곳에서 처리할 수 있습니다.

등록된 도메인은 보통 1년 단위로 갱신되며, 자동 갱신을 설정할 수도 있습니다.

다음 코드를 살펴봅시다.

// Route 53에서 도메인 가용성 확인
const checkDomainParams = {
  DomainName: 'myawesomeservice.com'
};

route53domains.checkDomainAvailability(checkDomainParams, (err, data) => {
  if (err) {
    console.log('에러 발생:', err);
  } else {
    console.log('도메인 사용 가능 여부:', data.Availability);
    // AVAILABLE: 구매 가능
    // UNAVAILABLE: 이미 사용 중
    // RESERVED: 예약됨
  }
});

도메인 이름의 중요성 김개발 씨는 고민에 빠졌습니다. 도메인 이름을 어떻게 정해야 할까요?

박시니어 씨가 조언을 시작했습니다. "도메인은 서비스의 얼굴입니다.

짧고 기억하기 쉬우면서도 서비스의 성격을 잘 드러내야 해요." 좋은 도메인 이름은 비즈니스의 성공에 큰 영향을 미칩니다. google.com, facebook.com처럼 간단하고 발음하기 쉬운 이름이 좋습니다.

철자가 복잡하거나 숫자와 하이픈이 많이 들어간 도메인은 피하는 것이 좋습니다. 도메인 확장자 선택 도메인은 확장자도 중요합니다.

.com이 가장 보편적이지만, 요즘은 .io, .dev, .app 등 다양한 확장자가 있습니다. 개발자 커뮤니티에서는 .io가 인기가 많고, 앱 서비스라면 .app도 좋은 선택입니다.

국내 서비스라면 .kr 도메인도 고려해볼 만합니다. 다만 .kr 도메인은 등록 절차가 조금 더 복잡할 수 있습니다.

Route 53에서는 수백 가지 확장자를 지원하므로 원하는 것을 선택할 수 있습니다. Route 53에서 도메인 검색 AWS 콘솔에 로그인한 후 Route 53 서비스로 이동합니다.

왼쪽 메뉴에서 도메인 등록을 선택하면 도메인 검색 화면이 나타납니다. 원하는 도메인 이름을 입력하고 검색 버튼을 클릭합니다.

위의 코드처럼 API를 사용할 수도 있지만, 처음에는 콘솔을 이용하는 것이 더 편리합니다. 검색 결과에서 사용 가능한 도메인과 가격을 한눈에 볼 수 있습니다.

도메인 가격 이해하기 도메인 가격은 확장자마다 다릅니다. .com 도메인은 보통 연간 12달러 정도이고, .io는 39달러 정도입니다.

인기 있는 확장자일수록 가격이 높은 편입니다. 첫해 등록 가격과 갱신 가격이 다른 경우도 있으니 주의해야 합니다.

어떤 도메인은 첫해에는 저렴하지만 갱신할 때는 가격이 크게 오르기도 합니다. Route 53 콘솔에서 갱신 가격도 함께 확인하세요.

등록 과정 사용 가능한 도메인을 찾았다면 장바구니에 담습니다. 다음으로 연락처 정보를 입력해야 합니다.

이름, 이메일, 주소 등을 정확히 입력하세요. 이 정보는 WHOIS 데이터베이스에 등록됩니다.

개인정보 보호가 걱정된다면 프라이버시 보호 옵션을 활성화하세요. Route 53은 대부분의 도메인에 대해 무료로 프라이버시 보호를 제공합니다.

이 옵션을 켜면 WHOIS 조회 시 실제 연락처 대신 대리 정보가 표시됩니다. 자동 갱신 설정 도메인은 기본적으로 자동 갱신이 활성화되어 있습니다.

이는 매우 중요한 설정입니다. 도메인이 만료되면 서비스가 중단될 수 있기 때문입니다.

실제로 많은 기업들이 도메인 갱신을 깜빡해서 큰 손해를 본 사례가 있습니다. 자동 갱신을 켜두면 만료 전에 자동으로 결제되어 이런 위험을 막을 수 있습니다.

만료 45일 전, 30일 전, 7일 전에 이메일 알림도 받게 됩니다. 결제 및 확인 모든 정보를 입력했다면 결제를 진행합니다.

Route 53은 등록된 AWS 계정의 결제 수단을 사용합니다. 신용카드가 등록되어 있는지 확인하세요.

결제가 완료되면 도메인 등록이 시작됩니다. 대부분의 도메인은 몇 분 내에 등록이 완료되지만, 일부 국가별 도메인(.kr, .jp 등)은 추가 인증 절차로 인해 시간이 더 걸릴 수 있습니다.

등록 완료 후 도메인 등록이 완료되면 이메일로 확인 메시지를 받게 됩니다. ICANN 규정에 따라 이메일 인증을 요구하는 경우도 있습니다.

받은 메일의 링크를 클릭하여 이메일 주소를 인증해야 도메인이 정상적으로 작동합니다. Route 53 콘솔의 도메인 섹션에서 등록된 도메인을 확인할 수 있습니다.

상태가 'Available'이면 모든 준비가 완료된 것입니다. 김개발 씨의 선택 김개발 씨는 신중하게 고민한 끝에 'devjourney.dev'라는 도메인을 선택했습니다.

개발자들의 여정을 함께한다는 의미를 담았고, .dev 확장자로 개발 관련 서비스임을 명확히 했습니다. "좋은 선택이에요." 박시니어 씨가 고개를 끄덕였습니다.

"이제 이 도메인을 실제 서버와 연결해야겠죠. 그러려면 호스팅 영역을 만들어야 합니다."

실전 팁

💡 실전 팁

도메인 이름을 정할 때는 상표권 침해 여부를 먼저 확인하세요.
비슷한 철자의 도메인도 함께 구매하면 사용자 유입을 늘릴 수 있습니다.
도메인 만료 알림 이메일을 받을 수 있도록 정확한 이메일 주소를 등록하세요.

3. 호스팅 영역 생성

DNS 레코드의 집 김개발 씨가 물었습니다. "도메인은 등록했는데, 이걸 어떻게 서버와 연결하나요?" 박시니어 씨가 화면을 가리키며 말했습니다.

"호스팅 영역을 만들어야 해요. 호스팅 영역은 DNS 레코드들을 보관하는 컨테이너 같은 거예요."

호스팅 영역의 역할 호스팅 영역은 특정 도메인에 대한 모든 DNS 레코드를 담는 공간입니다. 마치 파일을 정리하는 폴더처럼, 하나의 도메인에 관련된 모든 DNS 설정을 한곳에 모아둡니다.

Route 53에서 도메인을 등록하면 호스팅 영역이 자동으로 생성되지만, 외부에서 구매한 도메인을 사용할 때는 직접 만들어야 합니다.

다음 코드를 살펴봅시다.

// 호스팅 영역 생성
const createHostedZoneParams = {
  Name: 'devjourney.dev',
  CallerReference: Date.now().toString(), // 고유 식별자
  HostedZoneConfig: {
    Comment: '개발자 여정 서비스를 위한 호스팅 영역',
    PrivateZone: false // 퍼블릭 호스팅 영역
  }
};

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

호스팅 영역이란 김개발 씨는 처음 듣는 용어에 혼란스러웠습니다. 박시니어 씨가 쉽게 설명했습니다.

"예를 들어볼게요. 도서관을 상상해보세요.

도서관 전체가 Route 53이라면, 호스팅 영역은 특정 주제의 책들을 모아둔 서가입니다." 하나의 호스팅 영역에는 example.com이라는 도메인에 대한 모든 정보가 들어갑니다. www.example.com은 어디로 연결되는지, api.example.com은 어디로 연결되는지, 이메일은 어느 서버로 보내야 하는지 등의 정보가 모두 여기에 담깁니다.

퍼블릭 vs 프라이빗 호스팅 영역에는 두 가지 유형이 있습니다. 퍼블릭 호스팅 영역은 인터넷 전체에 공개되는 DNS 레코드를 담습니다.

일반적인 웹사이트는 모두 퍼블릭 호스팅 영역을 사용합니다. 반면 프라이빗 호스팅 영역은 AWS VPC 내부에서만 사용됩니다.

외부에서는 접근할 수 없고, VPC 안의 리소스들끼리만 도메인으로 통신할 때 사용합니다. 예를 들어 내부 데이터베이스를 db.internal.mycompany.com 같은 프라이빗 도메인으로 접근하게 할 수 있습니다.

자동 생성되는 레코드 호스팅 영역을 만들면 두 가지 레코드가 자동으로 생성됩니다. 먼저 NS(Name Server) 레코드입니다.

이것은 이 도메인의 DNS 정보를 어느 네임서버에서 관리하는지 알려줍니다. 다음은 SOA(Start of Authority) 레코드입니다.

이것은 호스팅 영역의 기본 정보를 담고 있습니다. DNS 갱신 주기, 재시도 간격 등의 설정이 들어있습니다.

이 두 레코드는 삭제하면 안 됩니다. 콘솔에서 생성하기 AWS 콘솔에서 Route 53으로 이동한 후 호스팅 영역 메뉴를 클릭합니다.

오른쪽 상단의 '호스팅 영역 생성' 버튼을 누릅니다. 도메인 이름을 입력합니다.

Route 53에서 등록한 도메인이라면 이미 호스팅 영역이 있을 것입니다. 외부에서 구매한 도메인을 사용한다면 새로 만들어야 합니다.

유형은 '퍼블릭 호스팅 영역'을 선택합니다. 코드로 생성하기 위의 코드는 API를 통해 호스팅 영역을 만드는 예제입니다.

CallerReference는 중복 생성을 방지하기 위한 고유 값입니다. 현재 시간을 밀리초로 변환한 값을 사용하면 충돌을 피할 수 있습니다.

PrivateZone을 false로 설정하면 퍼블릭 호스팅 영역이 생성됩니다. 만약 VPC 내부용 프라이빗 호스팅 영역을 만들려면 true로 설정하고 VPC ID를 함께 지정해야 합니다.

네임서버 정보 확인 호스팅 영역이 생성되면 네임서버 목록을 받게 됩니다. 보통 4개의 네임서버가 할당됩니다.

예를 들어 이런 형태입니다. ns-123.awsdns-12.com ns-456.awsdns-45.net ns-789.awsdns-78.org ns-012.awsdns-01.co.uk 이 네임서버 정보는 매우 중요합니다.

도메인 등록 업체에서 네임서버를 이 주소들로 변경해야 Route 53의 DNS 설정이 적용되기 때문입니다. 호스팅 영역 비용 호스팅 영역은 월 0.5달러의 비용이 발생합니다.

많은 레코드를 만들어도 호스팅 영역 자체의 비용은 동일합니다. 추가로 DNS 쿼리 비용이 발생하는데, 이것은 사용량에 따라 달라집니다.

만약 사용하지 않는 호스팅 영역이 있다면 삭제하는 것이 좋습니다. 단, 호스팅 영역을 삭제하면 그 안의 모든 레코드도 함께 사라지므로 주의해야 합니다.

여러 도메인 관리 하나의 AWS 계정에서 여러 호스팅 영역을 만들 수 있습니다. example.com, example.org, example.net처럼 여러 도메인을 운영한다면 각각에 대해 별도의 호스팅 영역을 만들면 됩니다.

서브도메인도 별도의 호스팅 영역으로 분리할 수 있습니다. 예를 들어 blog.example.com을 다른 팀에서 관리하게 하려면, 이것만을 위한 호스팅 영역을 따로 만들 수 있습니다.

주의할 점 초보자들이 자주 하는 실수가 있습니다. 호스팅 영역을 만들었는데 도메인이 작동하지 않는 경우입니다.

이것은 보통 네임서버 설정을 하지 않았기 때문입니다. 호스팅 영역은 단지 DNS 레코드를 담는 컨테이너일 뿐입니다.

실제로 이 DNS 정보가 사용되려면 도메인의 네임서버를 Route 53의 네임서버로 변경해야 합니다. 다음 섹션에서 이 부분을 자세히 다루겠습니다.

김개발 씨의 호스팅 영역 김개발 씨는 devjourney.dev 도메인을 위한 호스팅 영역을 성공적으로 만들었습니다. 화면에는 NS 레코드와 SOA 레코드가 보였습니다.

"이제 진짜 DNS 설정을 할 차례네요." 박시니어 씨가 미소 지었습니다. 호스팅 영역은 DNS 관리의 시작점입니다.

이제 여기에 실제 레코드들을 추가하여 도메인을 서버와 연결할 수 있습니다.

실전 팁

💡 실전 팁

호스팅 영역 이름은 정확히 입력해야 하며, 마침표는 자동으로 추가되므로 입력하지 않아도 됩니다.
테스트용 호스팅 영역을 만들었다면 사용 후 바로 삭제하여 불필요한 비용을 방지하세요.
프라이빗 호스팅 영역을 사용하면 VPC 내부 통신에서 공인 IP 없이도 도메인을 사용할 수 있습니다.

4. A, CNAME 레코드

도메인과 서버 연결하기 김개발 씨가 EC2 인스턴스의 IP 주소를 메모장에 적었습니다. "이 IP를 도메인과 연결하려면 어떻게 해야 하나요?" 박시니어 씨가 답했습니다.

"A 레코드를 만들면 됩니다. DNS의 가장 기본적인 레코드예요."

A와 CNAME 레코드 A 레코드는 도메인 이름을 IPv4 주소로 연결합니다. CNAME 레코드는 도메인을 다른 도메인으로 연결하는 별칭입니다.

A 레코드는 실제 서버의 IP를 가리키고, CNAME은 이미 존재하는 도메인을 재사용할 때 사용합니다. 두 레코드는 DNS의 핵심이며, 대부분의 웹사이트 설정에 필수적입니다.

다음 코드를 살펴봅시다.

// A 레코드 생성 - 도메인을 IP 주소로 연결
const createARecordParams = {
  HostedZoneId: '/hostedzone/Z1234567890ABC',
  ChangeBatch: {
    Changes: [{
      Action: 'CREATE',
      ResourceRecordSet: {
        Name: 'www.devjourney.dev',
        Type: 'A',
        TTL: 300, // 5분
        ResourceRecords: [{ Value: '203.0.113.10' }]
      }
    }]
  }
};

// CNAME 레코드 생성 - 도메인을 다른 도메인으로 연결
const createCNAMEParams = {
  HostedZoneId: '/hostedzone/Z1234567890ABC',
  ChangeBatch: {
    Changes: [{
      Action: 'CREATE',
      ResourceRecordSet: {
        Name: 'blog.devjourney.dev',
        Type: 'CNAME',
        TTL: 300,
        ResourceRecords: [{ Value: 'www.devjourney.dev' }]
      }
    }]
  }
};

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

DNS 레코드의 양대 산맥 김개발 씨는 호스팅 영역에 레코드를 추가하려고 했습니다. 그런데 레코드 타입이 너무 많았습니다.

A, AAAA, CNAME, MX, TXT... 박시니어 씨가 설명했습니다.

"처음에는 A 레코드와 CNAME만 알면 됩니다. 나머지는 필요할 때 배우면 돼요." DNS 레코드는 마치 주소록과 같습니다.

각 레코드는 "이 이름을 찾으면 여기로 가세요"라고 알려주는 표지판입니다. 그중에서도 A 레코드와 CNAME 레코드가 가장 자주 사용됩니다.

A 레코드의 원리 A 레코드는 Address의 약자입니다. 도메인 이름을 실제 서버의 IP 주소로 변환해줍니다.

예를 들어 www.example.com이라는 도메인에 A 레코드를 만들어 203.0.113.10이라는 IP를 지정하면, 사용자가 www.example.com을 입력했을 때 해당 IP의 서버로 연결됩니다. 비유하자면, A 레코드는 친구의 이름을 보고 전화번호를 찾는 것과 같습니다.

"김철수"를 검색하면 "010-1234-5678"이 나오는 것처럼, "www.example.com"을 검색하면 "203.0.113.10"이 나옵니다. A 레코드 만들기 Route 53 콘솔에서 호스팅 영역을 열고 '레코드 생성' 버튼을 클릭합니다.

레코드 이름에 www를 입력하고, 레코드 타입은 A를 선택합니다. 값 필드에는 EC2 인스턴스나 서버의 퍼블릭 IP 주소를 입력합니다.

TTL은 Time To Live의 약자로, DNS 정보를 캐시에 얼마나 오래 보관할지 결정합니다. 300초(5분)가 적당합니다.

자주 변경되는 서버라면 짧게, 안정적인 서버라면 길게 설정할 수 있습니다. 루트 도메인 설정 www 없이 example.com만으로 접속하게 하려면 어떻게 할까요?

레코드 이름을 비워두면 됩니다. 빈 이름은 루트 도메인을 의미합니다.

많은 사이트들이 www 버전과 루트 도메인 버전 두 개를 모두 설정합니다. 실무에서는 보통 www.example.com과 example.com 모두에 A 레코드를 만듭니다.

사용자가 어떤 방식으로 입력하든 접속할 수 있게 하기 위해서입니다. CNAME 레코드란 CNAME 레코드는 Canonical Name의 약자입니다.

한 도메인을 다른 도메인의 별칭으로 만듭니다. 예를 들어 blog.example.com을 www.example.com의 CNAME으로 만들면, blog.example.com에 접속하면 자동으로 www.example.com의 IP로 연결됩니다.

CNAME은 실제 IP 주소를 가리키지 않고, 다른 도메인 이름을 가리킵니다. 마치 "김철수의 번호를 알고 싶으면 김영희한테 물어봐"라고 하는 것과 같습니다.

CNAME의 실용성 왜 CNAME을 사용할까요? 예를 들어 여러 서브도메인이 모두 같은 서버를 가리킨다고 가정해봅시다.

A 레코드로 각각 설정하면 IP가 바뀔 때마다 모든 레코드를 수정해야 합니다. 하지만 CNAME을 사용하면 하나의 A 레코드만 수정하면 됩니다.

www.example.com에만 A 레코드를 만들고, 나머지는 모두 www.example.com을 가리키는 CNAME으로 만들면 관리가 훨씬 쉬워집니다. CNAME 제약사항 CNAME에는 중요한 제약이 있습니다.

루트 도메인에는 CNAME을 사용할 수 없습니다. 예를 들어 example.com에는 CNAME 레코드를 만들 수 없고, 반드시 A 레코드를 사용해야 합니다. 이것은 DNS 표준 규약입니다.

루트 도메인에는 NS 레코드와 SOA 레코드가 있는데, CNAME은 다른 레코드와 함께 있을 수 없기 때문입니다. 서브도메인에만 CNAME을 사용할 수 있습니다.

코드로 레코드 만들기 위의 코드는 A 레코드와 CNAME 레코드를 API로 생성하는 예제입니다. changeResourceRecordSets 메서드는 레코드를 생성, 수정, 삭제할 때 모두 사용됩니다.

Action을 CREATE, UPSERT, DELETE 중 선택하면 됩니다. UPSERT는 UPDATE + INSERT의 합성어로, 레코드가 없으면 생성하고 있으면 수정합니다.

실무에서는 UPSERT를 자주 사용합니다. 레코드 존재 여부를 확인할 필요 없이 바로 적용할 수 있기 때문입니다.

실전 시나리오 쇼핑몰을 운영한다고 가정해봅시다. 메인 사이트는 www.shop.com, 모바일은 m.shop.com, API는 api.shop.com입니다.

모두 같은 로드 밸런서를 사용합니다. 이 경우 www.shop.com에만 A 레코드를 만들고, m.shop.com과 api.shop.com은 www.shop.com을 가리키는 CNAME으로 만들 수 있습니다.

로드 밸런서 IP가 바뀌어도 A 레코드 하나만 수정하면 됩니다. 주의할 점 초보자들이 자주 하는 실수가 있습니다.

EC2 인스턴스를 재시작하면 퍼블릭 IP가 바뀔 수 있다는 점입니다. IP가 바뀌면 A 레코드도 수정해야 합니다.

이를 방지하려면 Elastic IP를 사용하세요. Elastic IP는 고정 IP 주소로, EC2 인스턴스를 재시작해도 변하지 않습니다.

또는 다음 섹션에서 배울 Alias 레코드를 사용하는 것도 좋은 방법입니다. 김개발 씨의 성공 김개발 씨는 www.devjourney.dev에 A 레코드를 만들었습니다.

몇 분 후 브라우저에서 도메인을 입력하자 서버의 웹 페이지가 나타났습니다. "와, 정말 되네요!" 김개발 씨가 감탄했습니다.

"축하합니다." 박시니어 씨가 말했습니다. "이제 AWS 리소스를 더 쉽게 연결하는 방법을 알려드릴게요.

Alias 레코드라는 게 있습니다."

실전 팁

💡 실전 팁

개발 환경에서는 TTL을 짧게(60초) 설정하여 변경사항이 빠르게 반영되도록 하세요.
프로덕션 환경에서는 TTL을 길게(3600초 이상) 설정하여 DNS 쿼리 비용을 절감할 수 있습니다.
CNAME 체인(CNAME이 또 다른 CNAME을 가리키는 것)은 성능 저하를 일으키므로 피하세요.

5. Alias 레코드

AWS 리소스 연결의 비밀 무기 박시니어 씨가 화면을 가리켰습니다. "김개발 씨, 로드 밸런서나 CloudFront를 사용하시나요?

그렇다면 A 레코드 대신 Alias 레코드를 사용하는 게 훨씬 좋습니다." 김개발 씨는 고개를 갸우뚱했습니다. "Alias요?

별칭이라는 뜻 아닌가요?"

Alias 레코드의 특별함 Alias 레코드는 Route 53의 특별한 기능으로, AWS 리소스를 직접 가리킬 수 있는 레코드입니다. A 레코드처럼 동작하지만 IP 주소 대신 AWS 리소스를 지정합니다.

CloudFront, ELB, S3, API Gateway 등을 연결할 때 사용하며, DNS 쿼리 비용이 무료이고 자동으로 IP 변경을 추적한다는 큰 장점이 있습니다.

다음 코드를 살펴봅시다.

// CloudFront 배포를 가리키는 Alias 레코드 생성
const createAliasRecordParams = {
  HostedZoneId: '/hostedzone/Z1234567890ABC',
  ChangeBatch: {
    Changes: [{
      Action: 'CREATE',
      ResourceRecordSet: {
        Name: 'www.devjourney.dev',
        Type: 'A',
        AliasTarget: {
          HostedZoneId: 'Z2FDTNDATAQYW2', // CloudFront의 호스팅 영역 ID
          DNSName: 'd1234abcd.cloudfront.net',
          EvaluateTargetHealth: false
        }
      }
    }]
  }
};

// Application Load Balancer를 가리키는 Alias 레코드
const createALBAliasParams = {
  HostedZoneId: '/hostedzone/Z1234567890ABC',
  ChangeBatch: {
    Changes: [{
      Action: 'CREATE',
      ResourceRecordSet: {
        Name: 'api.devjourney.dev',
        Type: 'A',
        AliasTarget: {
          HostedZoneId: 'Z35SXDOTRQ7X7K', // 리전별로 다름
          DNSName: 'my-alb-1234567890.ap-northeast-2.elb.amazonaws.com',
          EvaluateTargetHealth: true // ALB 헬스 체크 활성화
        }
      }
    }]
  }
};

route53.changeResourceRecordSets(createAliasRecordParams, (err, data) => {
  if (err) console.log('Alias 레코드 생성 실패:', err);
  else console.log('Alias 레코드 생성 성공');
});

Route 53의 숨은 보석 김개발 씨는 궁금했습니다. "A 레코드로도 연결할 수 있는데 왜 Alias를 따로 사용하나요?" 박시니어 씨가 웃으며 답했습니다.

"좋은 질문이에요. Alias는 AWS 환경에서만 쓸 수 있는 특별한 기능입니다." Alias 레코드는 표준 DNS 사양에는 없는 Route 53만의 확장 기능입니다.

하지만 외부에서 보면 일반 A 레코드처럼 동작합니다. 이것이 Alias의 마법입니다.

왜 Alias가 필요한가 AWS 리소스는 IP 주소가 자주 바뀝니다. CloudFront는 전 세계에 수백 개의 엣지 서버를 가지고 있고, 로드 밸런서도 트래픽에 따라 자동으로 확장됩니다.

이런 리소스들을 A 레코드로 관리하는 것은 사실상 불가능합니다. 예전에는 개발자들이 스크립트를 만들어 주기적으로 IP를 확인하고 DNS 레코드를 업데이트했습니다.

번거롭고 오류가 발생하기 쉬운 방식이었습니다. Alias 레코드는 이 모든 과정을 자동화합니다.

Alias vs CNAME "그럼 CNAME이랑 뭐가 다른가요?" 김개발 씨가 물었습니다. 중요한 차이가 있습니다.

CNAME은 루트 도메인에 사용할 수 없지만, Alias는 루트 도메인에도 사용할 수 있습니다. 예를 들어 example.com(www 없이)을 CloudFront에 연결하고 싶다면 CNAME으로는 불가능합니다. 반드시 Alias를 사용해야 합니다.

이것은 실무에서 매우 중요한 차이입니다. 무료 DNS 쿼리 Alias 레코드의 또 다른 장점은 비용입니다.

일반 A 레코드나 CNAME 레코드는 DNS 쿼리마다 비용이 발생합니다. 하지만 Alias 레코드로 AWS 리소스를 가리키면 DNS 쿼리 비용이 무료입니다.

트래픽이 많은 사이트라면 이 차이가 큽니다. 하루에 수백만 건의 DNS 쿼리가 발생하는 서비스에서는 Alias 레코드를 사용하는 것만으로도 상당한 비용을 절감할 수 있습니다.

CloudFront 연결하기 CloudFront는 AWS의 CDN 서비스입니다. 정적 파일을 전 세계에 빠르게 제공할 때 사용합니다.

CloudFront를 도메인에 연결하려면 Alias 레코드가 필수입니다. 위의 코드에서 보듯이, CloudFront의 호스팅 영역 ID는 항상 'Z2FDTNDATAQYW2'입니다.

전 세계 모든 CloudFront 배포가 이 호스팅 영역 ID를 사용합니다. DNSName에는 CloudFront 배포의 도메인 이름을 입력합니다.

로드 밸런서 연결하기 Application Load Balancer나 Network Load Balancer를 사용한다면 Alias 레코드로 연결하세요. 로드 밸런서의 IP는 자동으로 변경될 수 있으므로 A 레코드로는 안정적으로 운영할 수 없습니다.

로드 밸런서의 호스팅 영역 ID는 리전마다 다릅니다. 서울 리전(ap-northeast-2)의 ALB는 'Z35SXDOTRQ7X7K'를 사용합니다. AWS 문서에서 각 리전의 호스팅 영역 ID를 확인할 수 있습니다.

헬스 체크 기능 Alias 레코드에는 EvaluateTargetHealth라는 옵션이 있습니다. 이것을 true로 설정하면 대상 리소스의 헬스 체크 결과를 DNS 응답에 반영합니다.

예를 들어 로드 밸런서가 비정상 상태라면, Route 53은 해당 엔드포인트로 트래픽을 보내지 않습니다. 장애 조치를 자동화할 수 있는 강력한 기능입니다.

CloudFront는 자체 헬스 체크가 없으므로 보통 false로 설정합니다. S3 정적 웹사이트 S3 버킷을 정적 웹사이트로 호스팅할 때도 Alias 레코드를 사용합니다.

버킷 이름과 도메인 이름이 정확히 일치해야 합니다. 예를 들어 www.example.com 도메인을 사용한다면 버킷 이름도 www.example.com이어야 합니다.

S3의 호스팅 영역 ID는 리전마다 다릅니다. 서울 리전은 'Z3W03O7B5YMIYP'를 사용합니다.

DNSName에는 S3 웹사이트 엔드포인트를 입력합니다. 예: www.example.com.s3-website.ap-northeast-2.amazonaws.com 콘솔에서 설정하기 Route 53 콘솔에서 Alias 레코드를 만드는 것은 매우 쉽습니다.

레코드 생성 화면에서 Alias 스위치를 켭니다. 그러면 트래픽 라우팅 대상을 선택하는 드롭다운이 나타납니다.

CloudFront 배포, ELB, S3 버킷 등이 자동으로 목록에 표시됩니다. 원하는 리소스를 선택하기만 하면 됩니다.

호스팅 영역 ID나 DNS 이름을 수동으로 입력할 필요가 없습니다. 제약사항 Alias 레코드는 AWS 리소스에만 사용할 수 있습니다.

외부 서비스나 타사 CDN을 연결할 때는 일반 CNAME을 사용해야 합니다. 또한 Alias로 연결할 수 있는 리소스 타입이 정해져 있습니다.

CloudFront, ELB, S3, API Gateway, Elastic Beanstalk, VPC 엔드포인트 등은 가능하지만, EC2 인스턴스는 직접 연결할 수 없습니다. EC2는 A 레코드를 사용해야 합니다.

실전 활용 실무에서는 여러 레코드를 조합하여 사용합니다. 예를 들어 www.example.com은 CloudFront를 가리키는 Alias, api.example.com은 ALB를 가리키는 Alias, admin.example.com은 EC2 IP를 가리키는 A 레코드로 설정할 수 있습니다.

이렇게 하면 각 서비스의 특성에 맞는 최적의 DNS 구성을 만들 수 있습니다. 비용도 절감하고 관리도 쉬워집니다.

김개발 씨의 깨달음 "아, 이제 이해했어요!" 김개발 씨가 말했습니다. "AWS 리소스를 연결할 때는 Alias를 쓰면 자동으로 관리되고 비용도 안 나가는 거네요." 박시니어 씨가 고개를 끄덕였습니다.

"정확합니다. 이제 마지막으로 네임서버 설정만 하면 모든 준비가 끝납니다."

실전 팁

💡 실전 팁

Alias 레코드는 Zone Apex(루트 도메인)에 사용할 수 있는 유일한 방법입니다.
CloudFront 배포는 여러 도메인에서 Alias로 가리킬 수 있지만, 배포 설정에서 해당 도메인들을 Alternate Domain Names에 추가해야 합니다.
Alias 레코드로 다른 호스팅 영역의 레코드를 가리킬 수도 있어, 복잡한 DNS 구조를 만들 수 있습니다.

6. 네임서버 설정

마지막 퍼즐 조각 김개발 씨는 모든 레코드를 완벽하게 설정했습니다. 그런데 브라우저에서 도메인을 입력해도 여전히 연결되지 않았습니다.

"왜 안 되는 거죠?" 박시니어 씨가 웃으며 말했습니다. "가장 중요한 단계를 빠뜨렸네요.

네임서버 설정이에요."

네임서버의 역할 네임서버는 도메인의 DNS 정보가 어디에 저장되어 있는지 알려주는 서버입니다. 도메인 등록 업체에서 네임서버를 Route 53의 네임서버로 변경해야 Route 53에서 설정한 DNS 레코드들이 실제로 작동합니다.

네임서버 설정은 DNS 체인의 시작점이며, 이것 없이는 아무리 완벽한 레코드를 만들어도 소용이 없습니다.

다음 코드를 살펴봅시다.

// Route 53 호스팅 영역의 네임서버 조회
const getNameServersParams = {
  Id: '/hostedzone/Z1234567890ABC'
};

route53.getHostedZone(getNameServersParams, (err, data) => {
  if (err) {
    console.log('호스팅 영역 조회 실패:', err);
  } else {
    console.log('네임서버 목록:');
    data.DelegationSet.NameServers.forEach((ns, index) => {
      console.log(`${index + 1}. ${ns}`);
    });
    console.log('\n이 네임서버들을 도메인 등록 업체에 설정하세요.');
  }
});

// 출력 예시:
// 네임서버 목록:
// 1. ns-123.awsdns-12.com
// 2. ns-456.awsdns-45.net
// 3. ns-789.awsdns-78.org
// 4. ns-012.awsdns-01.co.uk

DNS의 시작점 김개발 씨는 혼란스러웠습니다. "Route 53에서 다 설정했는데 왜 안 되는 거죠?" 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다.

"DNS는 계층 구조로 되어 있어요. 네임서버 설정이 그 시작점입니다." 사용자가 브라우저에 도메인을 입력하면 컴퓨터는 먼저 루트 DNS 서버에 물어봅니다.

"이 도메인은 어디서 관리하나요?" 루트 서버는 도메인 등록 업체에 설정된 네임서버 정보를 알려줍니다. 그제야 컴퓨터는 해당 네임서버에 접속하여 실제 IP 주소를 받아옵니다.

네임서버가 중요한 이유 네임서버 설정이 잘못되면 DNS 전체가 작동하지 않습니다. 마치 우편물의 주소가 잘못된 것과 같습니다.

아무리 집 안에 우편함이 잘 준비되어 있어도, 주소가 틀리면 우편물이 도착하지 않습니다. Route 53에서 완벽한 레코드를 만들어도 네임서버가 다른 곳을 가리키고 있다면 아무 소용이 없습니다.

인터넷은 도메인 등록 업체에 설정된 네임서버만 신뢰하기 때문입니다. Route 53 네임서버 확인 호스팅 영역을 만들면 Route 53이 자동으로 4개의 네임서버를 할당합니다.

콘솔에서 호스팅 영역을 열면 NS 레코드에서 확인할 수 있습니다. 위의 코드처럼 API로도 조회할 수 있습니다.

네임서버는 보통 이런 형태입니다. ns-123.awsdns-12.com, ns-456.awsdns-45.net, ns-789.awsdns-78.org, ns-012.awsdns-01.co.uk.

4개의 서버가 서로 다른 최상위 도메인(.com, .net, .org, .uk)을 사용하는 것을 볼 수 있습니다. 이는 이중화를 위한 것입니다.

도메인 등록 업체에서 설정하기 이제 도메인을 등록한 업체의 관리 페이지로 이동합니다. GoDaddy, Namecheap, 가비아 등 어디서 구매했든 네임서버 설정 메뉴가 있습니다.

보통 'DNS 설정', '네임서버 관리', 'Name Servers' 같은 이름으로 되어 있습니다. 기존 네임서버를 삭제하고 Route 53에서 받은 4개의 네임서버를 입력합니다.

순서는 상관없지만, 4개를 모두 정확히 입력해야 합니다. 하나라도 빠뜨리면 안정성이 떨어집니다.

Route 53에서 도메인을 구매한 경우 Route 53에서 직접 도메인을 구매했다면 이 과정이 자동으로 완료됩니다. 도메인 등록과 동시에 호스팅 영역이 만들어지고, 네임서버도 자동으로 설정됩니다.

추가 작업 없이 바로 DNS 레코드를 사용할 수 있습니다. 이것이 Route 53에서 도메인을 구매하는 큰 장점입니다.

모든 것이 한곳에서 관리되어 실수할 여지가 없습니다. 전파 시간 기다리기 네임서버를 변경하면 전파 시간이 필요합니다.

전 세계의 DNS 서버들이 새로운 네임서버 정보를 업데이트하는 데 시간이 걸립니다. 보통 몇 분에서 최대 48시간까지 소요될 수 있습니다.

대부분의 경우 1-2시간 내에 완료됩니다. 급하게 확인하고 싶다면 dig나 nslookup 명령어로 직접 Route 53 네임서버에 쿼리를 보내볼 수 있습니다.

이렇게 하면 전파 완료 여부와 관계없이 즉시 결과를 확인할 수 있습니다. 네임서버 변경 확인 네임서버가 제대로 변경되었는지 확인하려면 터미널에서 이 명령어를 실행합니다.

dig NS example.com 또는 nslookup -type=NS example.com 결과에서 Route 53의 네임서버가 나타나면 성공입니다. 아직 이전 네임서버가 보인다면 조금 더 기다려야 합니다.

흔한 실수들 초보자들이 자주 하는 실수가 있습니다. 첫째, 네임서버를 일부만 입력하는 것입니다.

4개를 모두 입력해야 합니다. 둘째, 앞뒤 공백이나 마침표를 잘못 입력하는 것입니다.

정확히 복사하여 붙여넣으세요. 셋째, 네임서버를 변경하고 몇 분 내에 작동하지 않는다고 실패했다고 판단하는 것입니다.

전파 시간을 고려하여 최소 1시간은 기다려보세요. DNS 캐시 때문에 본인 컴퓨터에서만 안 될 수도 있으니, 다른 네트워크에서도 테스트해보는 것이 좋습니다.

서브도메인 위임 고급 기술로 서브도메인 위임이 있습니다. 예를 들어 example.com은 Route 53에서 관리하지만, blog.example.com은 다른 팀이 다른 DNS 서비스에서 관리하게 할 수 있습니다.

이때 example.com 호스팅 영역에 blog.example.com을 위한 NS 레코드를 만들고, 다른 DNS 서비스의 네임서버를 지정합니다. 이렇게 하면 blog.example.com에 대한 쿼리는 지정된 네임서버로 위임됩니다.

보안 고려사항 네임서버는 DNS의 핵심이므로 보안이 중요합니다. 도메인 등록 업체 계정에는 2단계 인증을 반드시 설정하세요.

계정이 해킹되면 공격자가 네임서버를 변경하여 트래픽을 가로챌 수 있습니다. 또한 도메인 잠금(Domain Lock) 기능을 활성화하세요.

이것은 네임서버 변경 등 중요한 설정을 보호합니다. 잠금을 해제하지 않으면 변경할 수 없어, 무단 수정을 막을 수 있습니다.

DNSSEC 고려 더 높은 보안을 원한다면 DNSSEC을 고려할 수 있습니다. DNSSEC은 DNS 응답의 진위를 암호학적으로 검증합니다.

Route 53은 DNSSEC을 지원하며, 호스팅 영역에서 활성화할 수 있습니다. 다만 DNSSEC은 설정이 복잡하고 도메인 등록 업체에서도 지원해야 합니다.

일반적인 서비스에서는 필수는 아니지만, 금융 서비스나 보안이 중요한 사이트에서는 고려할 만합니다. 김개발 씨의 완성 김개발 씨는 도메인 등록 업체 사이트에서 네임서버를 변경했습니다.

1시간 후 다시 확인했을 때, devjourney.dev 도메인이 완벽하게 작동했습니다. "드디어 됐어요!" 김개발 씨가 환호했습니다.

박시니어 씨가 미소 지었습니다. "축하합니다.

이제 Route 53의 기본은 마스터했어요. DNS는 보이지 않지만 인터넷의 기초입니다.

잘 이해하고 계시네요." 김개발 씨는 뿌듯했습니다. 도메인 등록부터 네임서버 설정까지, Route 53의 전체 과정을 이해했습니다.

이제 어떤 서비스든 자신 있게 배포할 수 있을 것 같았습니다.

실전 팁

💡 실전 팁

네임서버 변경 전에 현재 설정을 스크린샷으로 저장해두면 문제 발생 시 되돌릴 수 있습니다.
여러 도메인을 운영한다면 모두 같은 DNS 서비스로 통일하면 관리가 편리합니다.
중요한 서비스는 네임서버 변경 후 최소 24시간 동안 모니터링하여 문제가 없는지 확인하세요.

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

#AWS#Route53#DNS#DomainManagement#NetworkConfiguration

Route 53 DNS 관리 완벽 가이드

# Route 53 DNS 관리 완벽 가이드 AWS Route 53을 활용한 DNS 관리 방법을 초급 개발자를 위해 쉽게 설명합니다. 도메인 등록부터 레코드 설정, 네임서버 구성까지 실무에 필요한 모든 내용을 담았습니다. --- ## 목차 1. [Route 53 소개](#route-53-소개) 2. [도메인 등록](#도메인-등록) 3. [호스팅 영역 생성](#호스팅-영역-생성) 4. [A, CNAME 레코드](#a,-cname-레코드) 5. [Alias 레코드](#alias-레코드) 6. [네임서버 설정](#네임서버-설정) --- ## 1. Route 53 소개 이번 상황을 살펴봅시다. 김개발 씨는 처음으로 회사의 새로운 서비스를 배포하게 되었습니다. EC2 인스턴스도 띄웠고, 애플리케이션도 잘 동작합니다. 그런데 선배가 물었습니다. "IP 주소 말고 도메인으로 접속하게 해야 하는데, DNS 설정 해봤어요?" Route 53 소개 **Route 53**은 AWS에서 제공하는 DNS 웹 서비스입니다. 마치 전화번호부가 이름을 보고 전화번호를 찾아주듯이, 도메인 이름을 IP 주소로 변환해줍니다. 이를 통해 사용자들은 복잡한 IP 주소 대신 기억하기 쉬운 도메인 이름으로 서비스에 접속할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK를 이용한 Route 53 클라이언트 초기화 const AWS = require('aws-sdk'); // Route 53 클라이언트 생성 const route53 = new AWS.Route53({ region: 'us-east-1', accessKeyId: process.env.AWS_ACCESS_KEY_ID, secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY }); // 호스팅 영역 목록 조회 route53.listHostedZones({}, (err, data) => { if (err) console.log(err); else console.log('호스팅 영역:', data.HostedZones); }); ``` 실무에서 DNS를 만나다 김개발 씨는 지금까지 localhost나 IP 주소로만 서비스를 테스트해왔습니다. 그런데 실제 서비스를 운영하려면 myservice.com 같은 도메인이 필요하다는 것을 알게 되었습니다. 선배 개발자 박시니어 씨가 설명을 시작했습니다. "김개발 씨, 사용자들이 우리 서비스에 접속할 때 192.168.1.100 같은 IP 주소를 외워서 입력한다고 상상해보세요. 얼마나 불편할까요?" DNS란 무엇인가 DNS는 Domain Name System의 약자입니다. 쉽게 비유하자면, 인터넷의 전화번호부라고 할 수 있습니다. 우리가 친구에게 전화할 때 번호를 직접 외우지 않고 이름으로 검색하듯이, DNS는 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환해줍니다. 예를 들어 사용자가 브라우저에 www.example.com을 입력하면, DNS 서버가 이것을 실제 서버의 IP 주소인 203.0.113.1로 바꿔줍니다. 이 모든 과정이 눈 깜짝할 사이에 일어납니다. 왜 Route 53인가 AWS가 제공하는 여러 서비스 중에서도 **Route 53**은 특별합니다. 이름이 재미있는데, 53번 포트가 DNS에서 사용하는 표준 포트 번호이기 때문에 붙여진 이름입니다. Route 53은 단순히 DNS 서비스만 제공하는 것이 아닙니다. 도메인 등록, 헬스 체크, 트래픽 라우팅 정책 등 다양한 기능을 제공합니다. 특히 AWS의 다른 서비스들과 완벽하게 통합된다는 점이 큰 장점입니다. Route 53 없이 개발하던 시절 옛날에는 DNS 설정이 복잡했습니다. 별도의 DNS 호스팅 업체를 찾아야 했고, 설정 변경이 반영되는 데 몇 시간씩 걸리기도 했습니다. 문제가 생겨도 어디서 발생한 건지 찾기 어려웠습니다. 더 큰 문제는 확장성이었습니다. 트래픽이 급증하면 DNS 서버가 버티지 못해 서비스 전체가 마비되는 일도 있었습니다. 백업 DNS를 따로 구성하는 것도 만만치 않은 작업이었습니다. Route 53의 등장 Route 53은 이런 문제들을 깔끔하게 해결했습니다. 먼저 **높은 가용성**을 제공합니다. AWS의 글로벌 인프라를 활용하여 전 세계 어디서든 빠른 응답 속도를 보장합니다. 설정 변경도 거의 즉시 반영됩니다. 콘솔에서 클릭 몇 번이면 레코드를 추가하거나 수정할 수 있습니다. API를 통한 자동화도 쉽습니다. 위의 코드처럼 AWS SDK를 사용하면 프로그래밍 방식으로 DNS를 관리할 수 있습니다. 코드 분석 위의 예제 코드를 살펴보겠습니다. 먼저 AWS SDK를 불러온 후, Route 53 클라이언트를 생성합니다. 이때 리전과 인증 정보를 설정해야 합니다. listHostedZones 메서드는 현재 계정에 생성된 모든 호스팅 영역을 조회합니다. 호스팅 영역은 하나의 도메인에 대한 DNS 레코드들을 담는 컨테이너라고 생각하면 됩니다. 예를 들어 example.com 도메인을 관리한다면, 이 도메인을 위한 호스팅 영역이 하나 생성됩니다. 실무에서의 활용 실제 현업에서는 어떻게 사용할까요? 예를 들어 쇼핑몰 서비스를 운영한다고 가정해봅시다. 메인 사이트는 www.shopping.com, API 서버는 api.shopping.com, 관리자 페이지는 admin.shopping.com으로 분리하여 운영할 수 있습니다. Route 53을 사용하면 이 모든 서브도메인을 하나의 호스팅 영역에서 관리할 수 있습니다. 각 서브도메인마다 다른 서버로 연결할 수도 있고, 로드 밸런서를 연결할 수도 있습니다. 비용 절감 효과 많은 사람들이 놀라는 부분이 바로 비용입니다. Route 53은 사용한 만큼만 비용을 지불하는 종량제입니다. 호스팅 영역 하나당 월 0.5달러, DNS 쿼리 100만 건당 0.4달러 정도로 매우 저렴합니다. 게다가 AWS 내부 서비스 간 통신에는 DNS 쿼리 비용이 발생하지 않습니다. EC2 인스턴스가 같은 VPC 내의 다른 서비스를 도메인으로 호출해도 무료입니다. 주의할 점 초보 개발자들이 흔히 하는 실수가 있습니다. Route 53에서 도메인을 등록하거나 레코드를 설정했다고 해서 바로 작동하는 것은 아닙니다. DNS 변경사항이 전 세계로 전파되는 데 시간이 걸립니다. 이를 **TTL(Time To Live)**이라고 합니다. 급하게 설정을 바꿨는데 반영이 안 된다고 당황하지 마세요. 보통 몇 분에서 최대 48시간 정도 걸릴 수 있습니다. 물론 실제로는 대부분 몇 분 내에 반영됩니다. 다시 김개발 씨의 이야기로 박시니어 씨의 설명을 들은 김개발 씨는 이해했다는 표정을 지었습니다. "그러니까 Route 53은 도메인과 서버를 연결해주는 다리 역할을 하는 거네요!" 정확합니다. Route 53을 제대로 이해하면 안정적이고 확장 가능한 서비스 인프라를 구축할 수 있습니다. 다음 섹션에서는 실제로 도메인을 등록하는 방법을 알아보겠습니다. **실전 팁** 💡 실전 팁 - Route 53은 99.99%의 SLA를 보장하므로 프로덕션 환경에서도 안심하고 사용할 수 있습니다. - AWS Certificate Manager와 함께 사용하면 무료 SSL 인증서를 쉽게 발급받을 수 있습니다. - CloudWatch와 연동하여 DNS 쿼리를 모니터링하고 이상 징후를 빠르게 감지할 수 있습니다. --- ## 2. 도메인 등록 첫 도메인 구매하기 김개발 씨는 Route 53의 개념을 이해했습니다. 이제 실제로 도메인을 등록해야 합니다. 박시니어 씨가 물었습니다. "어떤 도메인 이름으로 하실 건가요? 도메인은 한 번 정하면 바꾸기 어려우니 신중하게 선택해야 해요." 도메인 등록하기 **도메인 등록**은 원하는 도메인 이름을 구매하여 소유권을 얻는 과정입니다. Route 53에서는 도메인 검색부터 결제까지 모든 과정을 한 곳에서 처리할 수 있습니다. 등록된 도메인은 보통 1년 단위로 갱신되며, 자동 갱신을 설정할 수도 있습니다. 다음 코드를 살펴봅시다. ```javascript // Route 53에서 도메인 가용성 확인 const checkDomainParams = { DomainName: 'myawesomeservice.com' }; route53domains.checkDomainAvailability(checkDomainParams, (err, data) => { if (err) { console.log('에러 발생:', err); } else { console.log('도메인 사용 가능 여부:', data.Availability); // AVAILABLE: 구매 가능 // UNAVAILABLE: 이미 사용 중 // RESERVED: 예약됨 } }); ``` 도메인 이름의 중요성 김개발 씨는 고민에 빠졌습니다. 도메인 이름을 어떻게 정해야 할까요? 박시니어 씨가 조언을 시작했습니다. "도메인은 서비스의 얼굴입니다. 짧고 기억하기 쉬우면서도 서비스의 성격을 잘 드러내야 해요." 좋은 도메인 이름은 비즈니스의 성공에 큰 영향을 미칩니다. google.com, facebook.com처럼 간단하고 발음하기 쉬운 이름이 좋습니다. 철자가 복잡하거나 숫자와 하이픈이 많이 들어간 도메인은 피하는 것이 좋습니다. 도메인 확장자 선택 도메인은 **확장자**도 중요합니다. .com이 가장 보편적이지만, 요즘은 .io, .dev, .app 등 다양한 확장자가 있습니다. 개발자 커뮤니티에서는 .io가 인기가 많고, 앱 서비스라면 .app도 좋은 선택입니다. 국내 서비스라면 .kr 도메인도 고려해볼 만합니다. 다만 .kr 도메인은 등록 절차가 조금 더 복잡할 수 있습니다. Route 53에서는 수백 가지 확장자를 지원하므로 원하는 것을 선택할 수 있습니다. Route 53에서 도메인 검색 AWS 콘솔에 로그인한 후 Route 53 서비스로 이동합니다. 왼쪽 메뉴에서 **도메인 등록**을 선택하면 도메인 검색 화면이 나타납니다. 원하는 도메인 이름을 입력하고 검색 버튼을 클릭합니다. 위의 코드처럼 API를 사용할 수도 있지만, 처음에는 콘솔을 이용하는 것이 더 편리합니다. 검색 결과에서 사용 가능한 도메인과 가격을 한눈에 볼 수 있습니다. 도메인 가격 이해하기 도메인 가격은 확장자마다 다릅니다. .com 도메인은 보통 연간 12달러 정도이고, .io는 39달러 정도입니다. 인기 있는 확장자일수록 가격이 높은 편입니다. 첫해 등록 가격과 갱신 가격이 다른 경우도 있으니 주의해야 합니다. 어떤 도메인은 첫해에는 저렴하지만 갱신할 때는 가격이 크게 오르기도 합니다. Route 53 콘솔에서 갱신 가격도 함께 확인하세요. 등록 과정 사용 가능한 도메인을 찾았다면 장바구니에 담습니다. 다음으로 **연락처 정보**를 입력해야 합니다. 이름, 이메일, 주소 등을 정확히 입력하세요. 이 정보는 WHOIS 데이터베이스에 등록됩니다. 개인정보 보호가 걱정된다면 **프라이버시 보호** 옵션을 활성화하세요. Route 53은 대부분의 도메인에 대해 무료로 프라이버시 보호를 제공합니다. 이 옵션을 켜면 WHOIS 조회 시 실제 연락처 대신 대리 정보가 표시됩니다. 자동 갱신 설정 도메인은 기본적으로 **자동 갱신**이 활성화되어 있습니다. 이는 매우 중요한 설정입니다. 도메인이 만료되면 서비스가 중단될 수 있기 때문입니다. 실제로 많은 기업들이 도메인 갱신을 깜빡해서 큰 손해를 본 사례가 있습니다. 자동 갱신을 켜두면 만료 전에 자동으로 결제되어 이런 위험을 막을 수 있습니다. 만료 45일 전, 30일 전, 7일 전에 이메일 알림도 받게 됩니다. 결제 및 확인 모든 정보를 입력했다면 결제를 진행합니다. Route 53은 등록된 AWS 계정의 결제 수단을 사용합니다. 신용카드가 등록되어 있는지 확인하세요. 결제가 완료되면 도메인 등록이 시작됩니다. 대부분의 도메인은 몇 분 내에 등록이 완료되지만, 일부 국가별 도메인(.kr, .jp 등)은 추가 인증 절차로 인해 시간이 더 걸릴 수 있습니다. 등록 완료 후 도메인 등록이 완료되면 이메일로 확인 메시지를 받게 됩니다. ICANN 규정에 따라 **이메일 인증**을 요구하는 경우도 있습니다. 받은 메일의 링크를 클릭하여 이메일 주소를 인증해야 도메인이 정상적으로 작동합니다. Route 53 콘솔의 도메인 섹션에서 등록된 도메인을 확인할 수 있습니다. 상태가 'Available'이면 모든 준비가 완료된 것입니다. 김개발 씨의 선택 김개발 씨는 신중하게 고민한 끝에 'devjourney.dev'라는 도메인을 선택했습니다. 개발자들의 여정을 함께한다는 의미를 담았고, .dev 확장자로 개발 관련 서비스임을 명확히 했습니다. "좋은 선택이에요." 박시니어 씨가 고개를 끄덕였습니다. "이제 이 도메인을 실제 서버와 연결해야겠죠. 그러려면 호스팅 영역을 만들어야 합니다." **실전 팁** 💡 실전 팁 - 도메인 이름을 정할 때는 상표권 침해 여부를 먼저 확인하세요. - 비슷한 철자의 도메인도 함께 구매하면 사용자 유입을 늘릴 수 있습니다. - 도메인 만료 알림 이메일을 받을 수 있도록 정확한 이메일 주소를 등록하세요. --- ## 3. 호스팅 영역 생성 DNS 레코드의 집 김개발 씨가 물었습니다. "도메인은 등록했는데, 이걸 어떻게 서버와 연결하나요?" 박시니어 씨가 화면을 가리키며 말했습니다. "호스팅 영역을 만들어야 해요. 호스팅 영역은 DNS 레코드들을 보관하는 컨테이너 같은 거예요." 호스팅 영역의 역할 **호스팅 영역**은 특정 도메인에 대한 모든 DNS 레코드를 담는 공간입니다. 마치 파일을 정리하는 폴더처럼, 하나의 도메인에 관련된 모든 DNS 설정을 한곳에 모아둡니다. Route 53에서 도메인을 등록하면 호스팅 영역이 자동으로 생성되지만, 외부에서 구매한 도메인을 사용할 때는 직접 만들어야 합니다. 다음 코드를 살펴봅시다. ```javascript // 호스팅 영역 생성 const createHostedZoneParams = { Name: 'devjourney.dev', CallerReference: Date.now().toString(), // 고유 식별자 HostedZoneConfig: { Comment: '개발자 여정 서비스를 위한 호스팅 영역', PrivateZone: false // 퍼블릭 호스팅 영역 } }; route53.createHostedZone(createHostedZoneParams, (err, data) => { if (err) console.log('호스팅 영역 생성 실패:', err); else { console.log('호스팅 영역 ID:', data.HostedZone.Id); console.log('네임서버:', data.DelegationSet.NameServers); } }); ``` 호스팅 영역이란 김개발 씨는 처음 듣는 용어에 혼란스러웠습니다. 박시니어 씨가 쉽게 설명했습니다. "예를 들어볼게요. 도서관을 상상해보세요. 도서관 전체가 Route 53이라면, 호스팅 영역은 특정 주제의 책들을 모아둔 서가입니다." 하나의 호스팅 영역에는 example.com이라는 도메인에 대한 모든 정보가 들어갑니다. www.example.com은 어디로 연결되는지, api.example.com은 어디로 연결되는지, 이메일은 어느 서버로 보내야 하는지 등의 정보가 모두 여기에 담깁니다. 퍼블릭 vs 프라이빗 호스팅 영역에는 두 가지 유형이 있습니다. **퍼블릭 호스팅 영역**은 인터넷 전체에 공개되는 DNS 레코드를 담습니다. 일반적인 웹사이트는 모두 퍼블릭 호스팅 영역을 사용합니다. 반면 **프라이빗 호스팅 영역**은 AWS VPC 내부에서만 사용됩니다. 외부에서는 접근할 수 없고, VPC 안의 리소스들끼리만 도메인으로 통신할 때 사용합니다. 예를 들어 내부 데이터베이스를 db.internal.mycompany.com 같은 프라이빗 도메인으로 접근하게 할 수 있습니다. 자동 생성되는 레코드 호스팅 영역을 만들면 두 가지 레코드가 자동으로 생성됩니다. 먼저 **NS(Name Server) 레코드**입니다. 이것은 이 도메인의 DNS 정보를 어느 네임서버에서 관리하는지 알려줍니다. 다음은 **SOA(Start of Authority) 레코드**입니다. 이것은 호스팅 영역의 기본 정보를 담고 있습니다. DNS 갱신 주기, 재시도 간격 등의 설정이 들어있습니다. 이 두 레코드는 삭제하면 안 됩니다. 콘솔에서 생성하기 AWS 콘솔에서 Route 53으로 이동한 후 **호스팅 영역** 메뉴를 클릭합니다. 오른쪽 상단의 '호스팅 영역 생성' 버튼을 누릅니다. 도메인 이름을 입력합니다. Route 53에서 등록한 도메인이라면 이미 호스팅 영역이 있을 것입니다. 외부에서 구매한 도메인을 사용한다면 새로 만들어야 합니다. 유형은 '퍼블릭 호스팅 영역'을 선택합니다. 코드로 생성하기 위의 코드는 API를 통해 호스팅 영역을 만드는 예제입니다. CallerReference는 중복 생성을 방지하기 위한 고유 값입니다. 현재 시간을 밀리초로 변환한 값을 사용하면 충돌을 피할 수 있습니다. PrivateZone을 false로 설정하면 퍼블릭 호스팅 영역이 생성됩니다. 만약 VPC 내부용 프라이빗 호스팅 영역을 만들려면 true로 설정하고 VPC ID를 함께 지정해야 합니다. 네임서버 정보 확인 호스팅 영역이 생성되면 **네임서버 목록**을 받게 됩니다. 보통 4개의 네임서버가 할당됩니다. 예를 들어 이런 형태입니다. ns-123.awsdns-12.com ns-456.awsdns-45.net ns-789.awsdns-78.org ns-012.awsdns-01.co.uk 이 네임서버 정보는 매우 중요합니다. 도메인 등록 업체에서 네임서버를 이 주소들로 변경해야 Route 53의 DNS 설정이 적용되기 때문입니다. 호스팅 영역 비용 호스팅 영역은 **월 0.5달러**의 비용이 발생합니다. 많은 레코드를 만들어도 호스팅 영역 자체의 비용은 동일합니다. 추가로 DNS 쿼리 비용이 발생하는데, 이것은 사용량에 따라 달라집니다. 만약 사용하지 않는 호스팅 영역이 있다면 삭제하는 것이 좋습니다. 단, 호스팅 영역을 삭제하면 그 안의 모든 레코드도 함께 사라지므로 주의해야 합니다. 여러 도메인 관리 하나의 AWS 계정에서 여러 호스팅 영역을 만들 수 있습니다. example.com, example.org, example.net처럼 여러 도메인을 운영한다면 각각에 대해 별도의 호스팅 영역을 만들면 됩니다. 서브도메인도 별도의 호스팅 영역으로 분리할 수 있습니다. 예를 들어 blog.example.com을 다른 팀에서 관리하게 하려면, 이것만을 위한 호스팅 영역을 따로 만들 수 있습니다. 주의할 점 초보자들이 자주 하는 실수가 있습니다. 호스팅 영역을 만들었는데 도메인이 작동하지 않는 경우입니다. 이것은 보통 **네임서버 설정을 하지 않았기 때문**입니다. 호스팅 영역은 단지 DNS 레코드를 담는 컨테이너일 뿐입니다. 실제로 이 DNS 정보가 사용되려면 도메인의 네임서버를 Route 53의 네임서버로 변경해야 합니다. 다음 섹션에서 이 부분을 자세히 다루겠습니다. 김개발 씨의 호스팅 영역 김개발 씨는 devjourney.dev 도메인을 위한 호스팅 영역을 성공적으로 만들었습니다. 화면에는 NS 레코드와 SOA 레코드가 보였습니다. "이제 진짜 DNS 설정을 할 차례네요." 박시니어 씨가 미소 지었습니다. 호스팅 영역은 DNS 관리의 시작점입니다. 이제 여기에 실제 레코드들을 추가하여 도메인을 서버와 연결할 수 있습니다. **실전 팁** 💡 실전 팁 - 호스팅 영역 이름은 정확히 입력해야 하며, 마침표는 자동으로 추가되므로 입력하지 않아도 됩니다. - 테스트용 호스팅 영역을 만들었다면 사용 후 바로 삭제하여 불필요한 비용을 방지하세요. - 프라이빗 호스팅 영역을 사용하면 VPC 내부 통신에서 공인 IP 없이도 도메인을 사용할 수 있습니다. --- ## 4. A, CNAME 레코드 도메인과 서버 연결하기 김개발 씨가 EC2 인스턴스의 IP 주소를 메모장에 적었습니다. "이 IP를 도메인과 연결하려면 어떻게 해야 하나요?" 박시니어 씨가 답했습니다. "A 레코드를 만들면 됩니다. DNS의 가장 기본적인 레코드예요." A와 CNAME 레코드 **A 레코드**는 도메인 이름을 IPv4 주소로 연결합니다. **CNAME 레코드**는 도메인을 다른 도메인으로 연결하는 별칭입니다. A 레코드는 실제 서버의 IP를 가리키고, CNAME은 이미 존재하는 도메인을 재사용할 때 사용합니다. 두 레코드는 DNS의 핵심이며, 대부분의 웹사이트 설정에 필수적입니다. 다음 코드를 살펴봅시다. ```javascript // A 레코드 생성 - 도메인을 IP 주소로 연결 const createARecordParams = { HostedZoneId: '/hostedzone/Z1234567890ABC', ChangeBatch: { Changes: [{ Action: 'CREATE', ResourceRecordSet: { Name: 'www.devjourney.dev', Type: 'A', TTL: 300, // 5분 ResourceRecords: [{ Value: '203.0.113.10' }] } }] } }; // CNAME 레코드 생성 - 도메인을 다른 도메인으로 연결 const createCNAMEParams = { HostedZoneId: '/hostedzone/Z1234567890ABC', ChangeBatch: { Changes: [{ Action: 'CREATE', ResourceRecordSet: { Name: 'blog.devjourney.dev', Type: 'CNAME', TTL: 300, ResourceRecords: [{ Value: 'www.devjourney.dev' }] } }] } }; route53.changeResourceRecordSets(createARecordParams, (err, data) => { if (err) console.log('A 레코드 생성 실패:', err); else console.log('A 레코드 생성 성공:', data.ChangeInfo.Id); }); ``` DNS 레코드의 양대 산맥 김개발 씨는 호스팅 영역에 레코드를 추가하려고 했습니다. 그런데 레코드 타입이 너무 많았습니다. A, AAAA, CNAME, MX, TXT... 박시니어 씨가 설명했습니다. "처음에는 A 레코드와 CNAME만 알면 됩니다. 나머지는 필요할 때 배우면 돼요." DNS 레코드는 마치 주소록과 같습니다. 각 레코드는 "이 이름을 찾으면 여기로 가세요"라고 알려주는 표지판입니다. 그중에서도 A 레코드와 CNAME 레코드가 가장 자주 사용됩니다. A 레코드의 원리 **A 레코드**는 Address의 약자입니다. 도메인 이름을 실제 서버의 IP 주소로 변환해줍니다. 예를 들어 www.example.com이라는 도메인에 A 레코드를 만들어 203.0.113.10이라는 IP를 지정하면, 사용자가 www.example.com을 입력했을 때 해당 IP의 서버로 연결됩니다. 비유하자면, A 레코드는 친구의 이름을 보고 전화번호를 찾는 것과 같습니다. "김철수"를 검색하면 "010-1234-5678"이 나오는 것처럼, "www.example.com"을 검색하면 "203.0.113.10"이 나옵니다. A 레코드 만들기 Route 53 콘솔에서 호스팅 영역을 열고 '레코드 생성' 버튼을 클릭합니다. 레코드 이름에 www를 입력하고, 레코드 타입은 A를 선택합니다. 값 필드에는 EC2 인스턴스나 서버의 **퍼블릭 IP 주소**를 입력합니다. TTL은 Time To Live의 약자로, DNS 정보를 캐시에 얼마나 오래 보관할지 결정합니다. 300초(5분)가 적당합니다. 자주 변경되는 서버라면 짧게, 안정적인 서버라면 길게 설정할 수 있습니다. 루트 도메인 설정 www 없이 example.com만으로 접속하게 하려면 어떻게 할까요? 레코드 이름을 비워두면 됩니다. 빈 이름은 루트 도메인을 의미합니다. 많은 사이트들이 www 버전과 루트 도메인 버전 두 개를 모두 설정합니다. 실무에서는 보통 www.example.com과 example.com 모두에 A 레코드를 만듭니다. 사용자가 어떤 방식으로 입력하든 접속할 수 있게 하기 위해서입니다. CNAME 레코드란 **CNAME 레코드**는 Canonical Name의 약자입니다. 한 도메인을 다른 도메인의 별칭으로 만듭니다. 예를 들어 blog.example.com을 www.example.com의 CNAME으로 만들면, blog.example.com에 접속하면 자동으로 www.example.com의 IP로 연결됩니다. CNAME은 실제 IP 주소를 가리키지 않고, 다른 도메인 이름을 가리킵니다. 마치 "김철수의 번호를 알고 싶으면 김영희한테 물어봐"라고 하는 것과 같습니다. CNAME의 실용성 왜 CNAME을 사용할까요? 예를 들어 여러 서브도메인이 모두 같은 서버를 가리킨다고 가정해봅시다. A 레코드로 각각 설정하면 IP가 바뀔 때마다 모든 레코드를 수정해야 합니다. 하지만 CNAME을 사용하면 하나의 A 레코드만 수정하면 됩니다. www.example.com에만 A 레코드를 만들고, 나머지는 모두 www.example.com을 가리키는 CNAME으로 만들면 관리가 훨씬 쉬워집니다. CNAME 제약사항 CNAME에는 중요한 제약이 있습니다. **루트 도메인에는 CNAME을 사용할 수 없습니다.** 예를 들어 example.com에는 CNAME 레코드를 만들 수 없고, 반드시 A 레코드를 사용해야 합니다. 이것은 DNS 표준 규약입니다. 루트 도메인에는 NS 레코드와 SOA 레코드가 있는데, CNAME은 다른 레코드와 함께 있을 수 없기 때문입니다. 서브도메인에만 CNAME을 사용할 수 있습니다. 코드로 레코드 만들기 위의 코드는 A 레코드와 CNAME 레코드를 API로 생성하는 예제입니다. changeResourceRecordSets 메서드는 레코드를 생성, 수정, 삭제할 때 모두 사용됩니다. Action을 CREATE, UPSERT, DELETE 중 선택하면 됩니다. UPSERT는 UPDATE + INSERT의 합성어로, 레코드가 없으면 생성하고 있으면 수정합니다. 실무에서는 UPSERT를 자주 사용합니다. 레코드 존재 여부를 확인할 필요 없이 바로 적용할 수 있기 때문입니다. 실전 시나리오 쇼핑몰을 운영한다고 가정해봅시다. 메인 사이트는 www.shop.com, 모바일은 m.shop.com, API는 api.shop.com입니다. 모두 같은 로드 밸런서를 사용합니다. 이 경우 www.shop.com에만 A 레코드를 만들고, m.shop.com과 api.shop.com은 www.shop.com을 가리키는 CNAME으로 만들 수 있습니다. 로드 밸런서 IP가 바뀌어도 A 레코드 하나만 수정하면 됩니다. 주의할 점 초보자들이 자주 하는 실수가 있습니다. EC2 인스턴스를 재시작하면 퍼블릭 IP가 바뀔 수 있다는 점입니다. IP가 바뀌면 A 레코드도 수정해야 합니다. 이를 방지하려면 **Elastic IP**를 사용하세요. Elastic IP는 고정 IP 주소로, EC2 인스턴스를 재시작해도 변하지 않습니다. 또는 다음 섹션에서 배울 Alias 레코드를 사용하는 것도 좋은 방법입니다. 김개발 씨의 성공 김개발 씨는 www.devjourney.dev에 A 레코드를 만들었습니다. 몇 분 후 브라우저에서 도메인을 입력하자 서버의 웹 페이지가 나타났습니다. "와, 정말 되네요!" 김개발 씨가 감탄했습니다. "축하합니다." 박시니어 씨가 말했습니다. "이제 AWS 리소스를 더 쉽게 연결하는 방법을 알려드릴게요. Alias 레코드라는 게 있습니다." **실전 팁** 💡 실전 팁 - 개발 환경에서는 TTL을 짧게(60초) 설정하여 변경사항이 빠르게 반영되도록 하세요. - 프로덕션 환경에서는 TTL을 길게(3600초 이상) 설정하여 DNS 쿼리 비용을 절감할 수 있습니다. - CNAME 체인(CNAME이 또 다른 CNAME을 가리키는 것)은 성능 저하를 일으키므로 피하세요. --- ## 5. Alias 레코드 AWS 리소스 연결의 비밀 무기 박시니어 씨가 화면을 가리켰습니다. "김개발 씨, 로드 밸런서나 CloudFront를 사용하시나요? 그렇다면 A 레코드 대신 Alias 레코드를 사용하는 게 훨씬 좋습니다." 김개발 씨는 고개를 갸우뚱했습니다. "Alias요? 별칭이라는 뜻 아닌가요?" Alias 레코드의 특별함 **Alias 레코드**는 Route 53의 특별한 기능으로, AWS 리소스를 직접 가리킬 수 있는 레코드입니다. A 레코드처럼 동작하지만 IP 주소 대신 AWS 리소스를 지정합니다. CloudFront, ELB, S3, API Gateway 등을 연결할 때 사용하며, DNS 쿼리 비용이 무료이고 자동으로 IP 변경을 추적한다는 큰 장점이 있습니다. 다음 코드를 살펴봅시다. ```javascript // CloudFront 배포를 가리키는 Alias 레코드 생성 const createAliasRecordParams = { HostedZoneId: '/hostedzone/Z1234567890ABC', ChangeBatch: { Changes: [{ Action: 'CREATE', ResourceRecordSet: { Name: 'www.devjourney.dev', Type: 'A', AliasTarget: { HostedZoneId: 'Z2FDTNDATAQYW2', // CloudFront의 호스팅 영역 ID DNSName: 'd1234abcd.cloudfront.net', EvaluateTargetHealth: false } } }] } }; // Application Load Balancer를 가리키는 Alias 레코드 const createALBAliasParams = { HostedZoneId: '/hostedzone/Z1234567890ABC', ChangeBatch: { Changes: [{ Action: 'CREATE', ResourceRecordSet: { Name: 'api.devjourney.dev', Type: 'A', AliasTarget: { HostedZoneId: 'Z35SXDOTRQ7X7K', // 리전별로 다름 DNSName: 'my-alb-1234567890.ap-northeast-2.elb.amazonaws.com', EvaluateTargetHealth: true // ALB 헬스 체크 활성화 } } }] } }; route53.changeResourceRecordSets(createAliasRecordParams, (err, data) => { if (err) console.log('Alias 레코드 생성 실패:', err); else console.log('Alias 레코드 생성 성공'); }); ``` Route 53의 숨은 보석 김개발 씨는 궁금했습니다. "A 레코드로도 연결할 수 있는데 왜 Alias를 따로 사용하나요?" 박시니어 씨가 웃으며 답했습니다. "좋은 질문이에요. Alias는 AWS 환경에서만 쓸 수 있는 특별한 기능입니다." Alias 레코드는 표준 DNS 사양에는 없는 Route 53만의 확장 기능입니다. 하지만 외부에서 보면 일반 A 레코드처럼 동작합니다. 이것이 Alias의 마법입니다. 왜 Alias가 필요한가 AWS 리소스는 IP 주소가 자주 바뀝니다. CloudFront는 전 세계에 수백 개의 엣지 서버를 가지고 있고, 로드 밸런서도 트래픽에 따라 자동으로 확장됩니다. 이런 리소스들을 A 레코드로 관리하는 것은 사실상 불가능합니다. 예전에는 개발자들이 스크립트를 만들어 주기적으로 IP를 확인하고 DNS 레코드를 업데이트했습니다. 번거롭고 오류가 발생하기 쉬운 방식이었습니다. Alias 레코드는 이 모든 과정을 자동화합니다. Alias vs CNAME "그럼 CNAME이랑 뭐가 다른가요?" 김개발 씨가 물었습니다. 중요한 차이가 있습니다. CNAME은 루트 도메인에 사용할 수 없지만, **Alias는 루트 도메인에도 사용할 수 있습니다.** 예를 들어 example.com(www 없이)을 CloudFront에 연결하고 싶다면 CNAME으로는 불가능합니다. 반드시 Alias를 사용해야 합니다. 이것은 실무에서 매우 중요한 차이입니다. 무료 DNS 쿼리 Alias 레코드의 또 다른 장점은 **비용**입니다. 일반 A 레코드나 CNAME 레코드는 DNS 쿼리마다 비용이 발생합니다. 하지만 Alias 레코드로 AWS 리소스를 가리키면 DNS 쿼리 비용이 무료입니다. 트래픽이 많은 사이트라면 이 차이가 큽니다. 하루에 수백만 건의 DNS 쿼리가 발생하는 서비스에서는 Alias 레코드를 사용하는 것만으로도 상당한 비용을 절감할 수 있습니다. CloudFront 연결하기 CloudFront는 AWS의 CDN 서비스입니다. 정적 파일을 전 세계에 빠르게 제공할 때 사용합니다. CloudFront를 도메인에 연결하려면 Alias 레코드가 필수입니다. 위의 코드에서 보듯이, CloudFront의 호스팅 영역 ID는 항상 'Z2FDTNDATAQYW2'입니다. 전 세계 모든 CloudFront 배포가 이 호스팅 영역 ID를 사용합니다. DNSName에는 CloudFront 배포의 도메인 이름을 입력합니다. 로드 밸런서 연결하기 Application Load Balancer나 Network Load Balancer를 사용한다면 Alias 레코드로 연결하세요. 로드 밸런서의 IP는 자동으로 변경될 수 있으므로 A 레코드로는 안정적으로 운영할 수 없습니다. 로드 밸런서의 호스팅 영역 ID는 **리전마다 다릅니다.** 서울 리전(ap-northeast-2)의 ALB는 'Z35SXDOTRQ7X7K'를 사용합니다. AWS 문서에서 각 리전의 호스팅 영역 ID를 확인할 수 있습니다. 헬스 체크 기능 Alias 레코드에는 **EvaluateTargetHealth**라는 옵션이 있습니다. 이것을 true로 설정하면 대상 리소스의 헬스 체크 결과를 DNS 응답에 반영합니다. 예를 들어 로드 밸런서가 비정상 상태라면, Route 53은 해당 엔드포인트로 트래픽을 보내지 않습니다. 장애 조치를 자동화할 수 있는 강력한 기능입니다. CloudFront는 자체 헬스 체크가 없으므로 보통 false로 설정합니다. S3 정적 웹사이트 S3 버킷을 정적 웹사이트로 호스팅할 때도 Alias 레코드를 사용합니다. 버킷 이름과 도메인 이름이 정확히 일치해야 합니다. 예를 들어 www.example.com 도메인을 사용한다면 버킷 이름도 www.example.com이어야 합니다. S3의 호스팅 영역 ID는 리전마다 다릅니다. 서울 리전은 'Z3W03O7B5YMIYP'를 사용합니다. DNSName에는 S3 웹사이트 엔드포인트를 입력합니다. 예: www.example.com.s3-website.ap-northeast-2.amazonaws.com 콘솔에서 설정하기 Route 53 콘솔에서 Alias 레코드를 만드는 것은 매우 쉽습니다. 레코드 생성 화면에서 **Alias** 스위치를 켭니다. 그러면 트래픽 라우팅 대상을 선택하는 드롭다운이 나타납니다. CloudFront 배포, ELB, S3 버킷 등이 자동으로 목록에 표시됩니다. 원하는 리소스를 선택하기만 하면 됩니다. 호스팅 영역 ID나 DNS 이름을 수동으로 입력할 필요가 없습니다. 제약사항 Alias 레코드는 AWS 리소스에만 사용할 수 있습니다. 외부 서비스나 타사 CDN을 연결할 때는 일반 CNAME을 사용해야 합니다. 또한 Alias로 연결할 수 있는 리소스 타입이 정해져 있습니다. CloudFront, ELB, S3, API Gateway, Elastic Beanstalk, VPC 엔드포인트 등은 가능하지만, EC2 인스턴스는 직접 연결할 수 없습니다. EC2는 A 레코드를 사용해야 합니다. 실전 활용 실무에서는 여러 레코드를 조합하여 사용합니다. 예를 들어 www.example.com은 CloudFront를 가리키는 Alias, api.example.com은 ALB를 가리키는 Alias, admin.example.com은 EC2 IP를 가리키는 A 레코드로 설정할 수 있습니다. 이렇게 하면 각 서비스의 특성에 맞는 최적의 DNS 구성을 만들 수 있습니다. 비용도 절감하고 관리도 쉬워집니다. 김개발 씨의 깨달음 "아, 이제 이해했어요!" 김개발 씨가 말했습니다. "AWS 리소스를 연결할 때는 Alias를 쓰면 자동으로 관리되고 비용도 안 나가는 거네요." 박시니어 씨가 고개를 끄덕였습니다. "정확합니다. 이제 마지막으로 네임서버 설정만 하면 모든 준비가 끝납니다." **실전 팁** 💡 실전 팁 - Alias 레코드는 Zone Apex(루트 도메인)에 사용할 수 있는 유일한 방법입니다. - CloudFront 배포는 여러 도메인에서 Alias로 가리킬 수 있지만, 배포 설정에서 해당 도메인들을 Alternate Domain Names에 추가해야 합니다. - Alias 레코드로 다른 호스팅 영역의 레코드를 가리킬 수도 있어, 복잡한 DNS 구조를 만들 수 있습니다. --- ## 6. 네임서버 설정 마지막 퍼즐 조각 김개발 씨는 모든 레코드를 완벽하게 설정했습니다. 그런데 브라우저에서 도메인을 입력해도 여전히 연결되지 않았습니다. "왜 안 되는 거죠?" 박시니어 씨가 웃으며 말했습니다. "가장 중요한 단계를 빠뜨렸네요. 네임서버 설정이에요." 네임서버의 역할 **네임서버**는 도메인의 DNS 정보가 어디에 저장되어 있는지 알려주는 서버입니다. 도메인 등록 업체에서 네임서버를 Route 53의 네임서버로 변경해야 Route 53에서 설정한 DNS 레코드들이 실제로 작동합니다. 네임서버 설정은 DNS 체인의 시작점이며, 이것 없이는 아무리 완벽한 레코드를 만들어도 소용이 없습니다. 다음 코드를 살펴봅시다. ```javascript // Route 53 호스팅 영역의 네임서버 조회 const getNameServersParams = { Id: '/hostedzone/Z1234567890ABC' }; route53.getHostedZone(getNameServersParams, (err, data) => { if (err) { console.log('호스팅 영역 조회 실패:', err); } else { console.log('네임서버 목록:'); data.DelegationSet.NameServers.forEach((ns, index) => { console.log(`${index + 1}. ${ns}`); }); console.log('\n이 네임서버들을 도메인 등록 업체에 설정하세요.'); } }); // 출력 예시: // 네임서버 목록: // 1. ns-123.awsdns-12.com // 2. ns-456.awsdns-45.net // 3. ns-789.awsdns-78.org // 4. ns-012.awsdns-01.co.uk ``` DNS의 시작점 김개발 씨는 혼란스러웠습니다. "Route 53에서 다 설정했는데 왜 안 되는 거죠?" 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "DNS는 계층 구조로 되어 있어요. 네임서버 설정이 그 시작점입니다." 사용자가 브라우저에 도메인을 입력하면 컴퓨터는 먼저 루트 DNS 서버에 물어봅니다. "이 도메인은 어디서 관리하나요?" 루트 서버는 도메인 등록 업체에 설정된 네임서버 정보를 알려줍니다. 그제야 컴퓨터는 해당 네임서버에 접속하여 실제 IP 주소를 받아옵니다. 네임서버가 중요한 이유 네임서버 설정이 잘못되면 DNS 전체가 작동하지 않습니다. 마치 우편물의 주소가 잘못된 것과 같습니다. 아무리 집 안에 우편함이 잘 준비되어 있어도, 주소가 틀리면 우편물이 도착하지 않습니다. Route 53에서 완벽한 레코드를 만들어도 네임서버가 다른 곳을 가리키고 있다면 아무 소용이 없습니다. 인터넷은 도메인 등록 업체에 설정된 네임서버만 신뢰하기 때문입니다. Route 53 네임서버 확인 호스팅 영역을 만들면 Route 53이 자동으로 4개의 네임서버를 할당합니다. 콘솔에서 호스팅 영역을 열면 NS 레코드에서 확인할 수 있습니다. 위의 코드처럼 API로도 조회할 수 있습니다. 네임서버는 보통 이런 형태입니다. ns-123.awsdns-12.com, ns-456.awsdns-45.net, ns-789.awsdns-78.org, ns-012.awsdns-01.co.uk. 4개의 서버가 서로 다른 최상위 도메인(.com, .net, .org, .uk)을 사용하는 것을 볼 수 있습니다. 이는 **이중화**를 위한 것입니다. 도메인 등록 업체에서 설정하기 이제 도메인을 등록한 업체의 관리 페이지로 이동합니다. GoDaddy, Namecheap, 가비아 등 어디서 구매했든 네임서버 설정 메뉴가 있습니다. 보통 'DNS 설정', '네임서버 관리', 'Name Servers' 같은 이름으로 되어 있습니다. 기존 네임서버를 삭제하고 Route 53에서 받은 4개의 네임서버를 입력합니다. 순서는 상관없지만, 4개를 모두 정확히 입력해야 합니다. 하나라도 빠뜨리면 안정성이 떨어집니다. Route 53에서 도메인을 구매한 경우 Route 53에서 직접 도메인을 구매했다면 이 과정이 자동으로 완료됩니다. 도메인 등록과 동시에 호스팅 영역이 만들어지고, 네임서버도 자동으로 설정됩니다. 추가 작업 없이 바로 DNS 레코드를 사용할 수 있습니다. 이것이 Route 53에서 도메인을 구매하는 큰 장점입니다. 모든 것이 한곳에서 관리되어 실수할 여지가 없습니다. 전파 시간 기다리기 네임서버를 변경하면 **전파 시간**이 필요합니다. 전 세계의 DNS 서버들이 새로운 네임서버 정보를 업데이트하는 데 시간이 걸립니다. 보통 몇 분에서 최대 48시간까지 소요될 수 있습니다. 대부분의 경우 1-2시간 내에 완료됩니다. 급하게 확인하고 싶다면 dig나 nslookup 명령어로 직접 Route 53 네임서버에 쿼리를 보내볼 수 있습니다. 이렇게 하면 전파 완료 여부와 관계없이 즉시 결과를 확인할 수 있습니다. 네임서버 변경 확인 네임서버가 제대로 변경되었는지 확인하려면 터미널에서 이 명령어를 실행합니다. dig NS example.com 또는 nslookup -type=NS example.com 결과에서 Route 53의 네임서버가 나타나면 성공입니다. 아직 이전 네임서버가 보인다면 조금 더 기다려야 합니다. 흔한 실수들 초보자들이 자주 하는 실수가 있습니다. 첫째, 네임서버를 일부만 입력하는 것입니다. 4개를 모두 입력해야 합니다. 둘째, 앞뒤 공백이나 마침표를 잘못 입력하는 것입니다. 정확히 복사하여 붙여넣으세요. 셋째, 네임서버를 변경하고 몇 분 내에 작동하지 않는다고 실패했다고 판단하는 것입니다. 전파 시간을 고려하여 최소 1시간은 기다려보세요. DNS 캐시 때문에 본인 컴퓨터에서만 안 될 수도 있으니, 다른 네트워크에서도 테스트해보는 것이 좋습니다. 서브도메인 위임 고급 기술로 **서브도메인 위임**이 있습니다. 예를 들어 example.com은 Route 53에서 관리하지만, blog.example.com은 다른 팀이 다른 DNS 서비스에서 관리하게 할 수 있습니다. 이때 example.com 호스팅 영역에 blog.example.com을 위한 NS 레코드를 만들고, 다른 DNS 서비스의 네임서버를 지정합니다. 이렇게 하면 blog.example.com에 대한 쿼리는 지정된 네임서버로 위임됩니다. 보안 고려사항 네임서버는 DNS의 핵심이므로 보안이 중요합니다. 도메인 등록 업체 계정에는 **2단계 인증**을 반드시 설정하세요. 계정이 해킹되면 공격자가 네임서버를 변경하여 트래픽을 가로챌 수 있습니다. 또한 **도메인 잠금(Domain Lock)** 기능을 활성화하세요. 이것은 네임서버 변경 등 중요한 설정을 보호합니다. 잠금을 해제하지 않으면 변경할 수 없어, 무단 수정을 막을 수 있습니다. DNSSEC 고려 더 높은 보안을 원한다면 **DNSSEC**을 고려할 수 있습니다. DNSSEC은 DNS 응답의 진위를 암호학적으로 검증합니다. Route 53은 DNSSEC을 지원하며, 호스팅 영역에서 활성화할 수 있습니다. 다만 DNSSEC은 설정이 복잡하고 도메인 등록 업체에서도 지원해야 합니다. 일반적인 서비스에서는 필수는 아니지만, 금융 서비스나 보안이 중요한 사이트에서는 고려할 만합니다. 김개발 씨의 완성 김개발 씨는 도메인 등록 업체 사이트에서 네임서버를 변경했습니다. 1시간 후 다시 확인했을 때, devjourney.dev 도메인이 완벽하게 작동했습니다. "드디어 됐어요!" 김개발 씨가 환호했습니다. 박시니어 씨가 미소 지었습니다. "축하합니다. 이제 Route 53의 기본은 마스터했어요. DNS는 보이지 않지만 인터넷의 기초입니다. 잘 이해하고 계시네요." 김개발 씨는 뿌듯했습니다. 도메인 등록부터 네임서버 설정까지, Route 53의 전체 과정을 이해했습니다. 이제 어떤 서비스든 자신 있게 배포할 수 있을 것 같았습니다. **실전 팁** 💡 실전 팁 - 네임서버 변경 전에 현재 설정을 스크린샷으로 저장해두면 문제 발생 시 되돌릴 수 있습니다. - 여러 도메인을 운영한다면 모두 같은 DNS 서비스로 통일하면 관리가 편리합니다. - 중요한 서비스는 네임서버 변경 후 최소 24시간 동안 모니터링하여 문제가 없는지 확인하세요. --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, Route53, DNS, DomainManagement, NetworkConfiguration

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

Route 53 DNS 관리 완벽 가이드

목차

1. Route 53 소개

2. 도메인 등록

3. 호스팅 영역 생성

4. A, CNAME 레코드

5. Alias 레코드

6. 네임서버 설정

댓글 (0)

함께 보면 좋은 카드 뉴스

서비스 메시 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

분산 추적 완벽 가이드

보안 아키텍처 구성 완벽 가이드