DNS 레코드 설정 실전 — 도메인을 서버,클라우드에 연결하기 (A,CNAME,apex,TTL)

2026년 6월 1일 월요일

7 분 소요

도메인을 샀고 서버도 준비했는데, 주소를 입력해도 사이트가 뜨지 않습니다. 이렇게 막히는 지점은 거의 DNS 설정입니다. 이 글에서는 도메인을 실제 서버나 클라우드에 연결하는 과정을 A,CNAME,apex,TTL을 중심으로 단계별로 다룹니다. 도메인,네임서버,레코드가 무엇인지부터 짚고 싶다면 도메인이란 무엇이고, 왜 필요한가를 먼저 읽어 보시길 권합니다.

먼저 정할 것: 네임서버를 어디에 둘 것인가 #

도메인을 연결하는 첫 결정은 “이 도메인의 DNS를 누가 운영할 것인가"입니다. 선택지는 크게 둘입니다.

등록업체 기본 네임서버 사용: 도메인을 산 곳(예: 가비아, GoDaddy, Cloudflare Registrar)이 제공하는 DNS에 레코드를 직접 적습니다. 간단한 사이트라면 충분합니다.
외부 DNS로 위임: 등록업체에서 네임서버만 외부 서비스(Cloudflare, AWS Route 53 등)로 바꾸고, 레코드는 그쪽에서 관리합니다. 캐싱, 프록시, 헬스 체크 같은 기능이 필요할 때 선택합니다.

위임은 등록업체 화면에서 네임서버 항목을 외부 서비스가 알려 준 값으로 바꾸면 됩니다.

# 예: Cloudflare로 위임하면 등록업체에 이런 네임서버를 지정
ns1.cloudflare.com
ns2.cloudflare.com

네임서버를 바꾼 직후에는 아직 옛 네임서버를 보는 곳이 남아 있어, 변경이 완전히 자리 잡기까지 시간이 걸립니다. 그래서 네임서버 위임은 사이트를 본격적으로 옮기기 며칠 전에 미리 끝내 두는 편이 안전합니다.

핵심 레코드와 실제 값 #

연결에 자주 쓰는 레코드는 다섯 가지면 충분합니다.

레코드	역할	값의 예
A	이름 → IPv4 주소	`203.0.113.10`
AAAA	이름 → IPv6 주소	`2001:db8::1`
CNAME	이름 → 다른 이름	`schoolofweb.net`
MX	메일 수신 서버 지정	`10 mail.example.com`
TXT	인증,소유 확인 메모	`v=spf1 include:...`

가장 단순한 형태는 이렇습니다. 사이트를 고정 IP를 가진 서버 한 대에 올린다면, apex 도메인과 www를 각각 이렇게 둡니다.

# 이름            타입     값
@                A        203.0.113.10
www              CNAME    schoolofweb.net

여기서 @는 www 같은 접두어가 없는 apex 도메인, 곧 schoolofweb.net 자체를 가리킵니다.

apex 도메인의 함정 #

실무에서 가장 많이 막히는 지점이 apex 도메인입니다. 규칙상 apex(@)에는 CNAME을 둘 수 없습니다. CNAME은 그 이름의 다른 모든 레코드와 공존할 수 없는데, apex에는 MX나 TXT처럼 반드시 함께 있어야 하는 레코드가 있기 때문입니다.

문제는 요즘 호스팅이나 CDN이 고정 IP가 아니라 이름(예: myapp.vercel.app)을 연결 대상으로 준다는 점입니다. apex에 CNAME을 못 쓰니 그 이름을 그대로 붙일 수가 없습니다. 해법은 DNS 서비스가 제공하는 다음 기능 중 하나입니다.

ALIAS 또는 ANAME 레코드: apex에서도 이름을 가리킬 수 있게 해 주는 특수 레코드입니다. (Route 53의 Alias, 일부 DNS의 ANAME)
CNAME flattening: apex에 CNAME처럼 적되, DNS 서비스가 응답 시점에 실제 IP로 바꿔서 돌려줍니다. (Cloudflare가 대표적)

둘 다 없다면, 연결 대상의 고정 IP를 받아 apex에 A 레코드로 직접 박는 수밖에 없습니다. 이 경우 대상 IP가 바뀌면 직접 따라 고쳐야 합니다.

환경별 설정 #

리눅스 서버에 직접 올리는 경우 #

고정 공인 IP를 가진 리눅스 서버에 Nginx로 사이트를 띄운다면, 연결은 A 레코드 한 줄로 끝납니다.

@                A        203.0.113.10
www              CNAME    schoolofweb.net

서버 쪽 Nginx는 두 이름을 모두 받도록 설정합니다.

server {
    listen 80;
    server_name schoolofweb.net www.schoolofweb.net;
    # ...
}

설정 후에는 이름이 의도한 IP로 풀리는지 dig로 확인합니다.

dig +short schoolofweb.net A
# 203.0.113.10

dig +short www.schoolofweb.net
# schoolofweb.net.
# 203.0.113.10

클라우드 관리형으로 올리는 경우 #

로드 밸런서나 CDN 뒤에 두는 경우에는 대상이 고정 IP가 아니라 이름인 경우가 많습니다.

AWS (Route 53 + ALB/CloudFront): www는 CNAME 또는 Alias로 로드 밸런서 이름을 가리키고, apex는 Alias 레코드로 같은 대상을 가리킵니다. Alias는 AWS 내부 리소스를 가리킬 때 요금 없이 동작합니다.
Cloudflare: apex와 www 모두 CNAME처럼 대상 이름을 적으면, CNAME flattening 덕분에 apex에서도 그대로 동작합니다. 주황색 구름(프록시)을 켜면 Cloudflare를 거쳐 들어옵니다.

# Cloudflare 예 (프록시 켬)
@                CNAME    myapp.example-host.com   (flattening 적용)
www              CNAME    myapp.example-host.com

TTL과 전파: 옮기기 전에 TTL부터 낮춘다 #

레코드에는 TTL(Time To Live)이 있습니다. 다른 곳에서 이 레코드를 얼마 동안 캐시해도 되는지를 초 단위로 정한 값입니다. TTL이 3600이면 한 시간 동안은 바뀐 값을 못 볼 수 있습니다.

그래서 서버 이전처럼 IP가 바뀌는 작업은 순서가 중요합니다.

이전하기 하루 전, 해당 레코드의 TTL을 300(5분) 이하로 낮춰 둡니다.
낮춘 TTL이 퍼질 때까지(원래 TTL만큼) 기다립니다.
실제 이전 시점에 레코드 값을 새 IP로 바꿉니다. 이제 5분 안에 대부분 반영됩니다.
안정되면 TTL을 다시 3600 정도로 올려 둡니다.

이렇게 바뀐 레코드가 전 세계 캐시에 퍼지는 것을 전파(propagation)라고 부르며, TTL을 미리 낮춰 두면 전파로 인한 공백을 크게 줄일 수 있습니다.

확인 도구: dig 읽는 법 #

설정이 의도대로 풀리는지는 추측하지 말고 dig로 확인합니다. dig(Domain Information Groper)는 DNS에 직접 질의해 응답을 그대로 보여 주는 도구로, 리눅스와 macOS에는 보통 기본 포함돼 있습니다.

기본 조회와 출력 읽기 #

옵션 없이 조회하면 응답 전체가 나옵니다.

$ dig schoolofweb.net A

; <<>> DiG 9.18.18 <<>> schoolofweb.net A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;schoolofweb.net.		IN	A

;; ANSWER SECTION:
schoolofweb.net.	300	IN	A	203.0.113.10

;; Query time: 31 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jul 28 10:12:04 KST 2026
;; MSG SIZE  rcvd: 71

읽을 곳은 두 군데입니다.

status: NOERROR면 정상 응답입니다. NXDOMAIN은 도메인 자체가 없다는 뜻이고, NOERROR인데 ANSWER: 0이면 도메인은 있지만 그 타입의 레코드가 없다는 뜻입니다.
ANSWER SECTION: 실제 답입니다. 한 줄은 이름 / TTL / 클래스(IN) / 타입 / 값 순서이고, 위에서 300이 TTL(초), 203.0.113.10이 연결된 IP입니다.

값만 간단히 보기: +short #

값만 빠르게 보려면 +short를 붙입니다.

$ dig +short schoolofweb.net A
203.0.113.10

www처럼 CNAME이 걸린 이름은 사슬이 그대로 보입니다. 맨 위가 CNAME 대상, 그 아래가 최종 IP입니다.

$ dig +short www.schoolofweb.net
schoolofweb.net.
203.0.113.10

레코드 타입별 조회 #

타입을 바꿔 가며 같은 방식으로 확인합니다.

$ dig +short schoolofweb.net MX
10 mail.schoolofweb.net.

$ dig +short schoolofweb.net TXT
"v=spf1 include:_spf.example.com ~all"

$ dig +short schoolofweb.net NS
ns1.cloudflare.com.
ns2.cloudflare.com.

특정 서버에 직접 묻기: @ #

@로 질의할 서버를 지정합니다. 권한 네임서버에 직접 물으면 전파와 무관하게 원본 값을 볼 수 있고, 공개 리졸버(예: 1.1.1.1)에 물으면 일반 사용자가 받는 캐시된 값을 볼 수 있습니다.

# 권한 네임서버에 직접 (전파 전이라도 원본 확인)
$ dig @ns1.cloudflare.com schoolofweb.net A +short
203.0.113.10

# 공개 리졸버를 통해 (사용자가 실제로 받는 값)
$ dig @1.1.1.1 schoolofweb.net A +short
203.0.113.10

두 값이 다르면 아직 전파가 끝나지 않았다는 신호입니다.

TTL로 전파 상태 읽기 #

캐시된 응답에서는 TTL이 0을 향해 줄어듭니다. +noall +answer로 답만 추려서 잠시 뒤 다시 조회하면 숫자가 작아진 것이 보입니다.

$ dig +noall +answer schoolofweb.net A
schoolofweb.net.	287	IN	A	203.0.113.10

287은 원래 TTL 300에서 13초가 지났다는 뜻입니다. 0이 되면 리졸버가 권한 서버에 다시 물어 새 값을 받아오므로, 이전 전에 TTL을 낮춰 두면 새 값이 그만큼 빨리 반영됩니다.

루트부터 단계 추적: +trace #

응답이 이상할 때는 +trace로 루트부터 권한 서버까지 누가 무엇을 답하는지 단계별로 따라갈 수 있습니다.

$ dig +trace schoolofweb.net

.			518400	IN	NS	a.root-servers.net.
...
net.			172800	IN	NS	a.gtld-servers.net.
...
schoolofweb.net.	86400	IN	NS	ns1.cloudflare.com.
schoolofweb.net.	300	IN	A	203.0.113.10

위에서 아래로 루트 → net → 도메인의 권한 네임서버 순으로 위임이 이어집니다. 중간에서 끊기거나 엉뚱한 서버가 나오면, 그 단계의 위임이 잘못됐다는 뜻입니다.

dig가 없을 때 #

dig가 없는 환경(일부 Windows 등)에서는 nslookup으로 기본 조회를 할 수 있습니다.

$ nslookup schoolofweb.net
$ nslookup -type=MX schoolofweb.net

흔한 실수 체크리스트 #

apex에 CNAME을 넣으려다 막힘: ALIAS/ANAME 또는 CNAME flattening을 쓰거나, 고정 IP에 A 레코드로 둡니다.
www만 되고 apex가 안 됨: apex(@) 레코드를 빠뜨린 경우입니다. 두 이름을 모두 설정했는지 확인합니다.
옛 A 레코드가 남아 있음: 새 레코드를 추가만 하고 옛 값을 지우지 않으면, 일부 방문자가 옛 서버로 갑니다.
TTL이 높아 변경이 안 보임: 바로 안 바뀐다고 값을 거듭 고치지 말고, TTL과 전파 시간을 먼저 확인합니다.
메일이 끊김: 네임서버를 위임하면서 MX,TXT(SPF/DKIM)를 새 DNS로 옮기지 않은 경우입니다. 메일 전달 구조는 이메일은 어떻게 상대에게 도착할까를 참고하세요.

마무리 #

도메인 연결은 결국 “어느 네임서버가 답을 하고, 거기에 어떤 레코드를 적는가"로 정리됩니다. 핵심은 apex 도메인의 CNAME 제약을 알고 ALIAS,flattening,A 레코드 중 맞는 해법을 고르는 것, 그리고 이전 전에 TTL을 미리 낮춰 전파 공백을 줄이는 것입니다.

도메인이 연결됐다면 다음 차례는 HTTPS 인증서입니다. 실제로 인증서를 발급받고 자동으로 갱신하는 방법은 HTTPS 인증서 실전에서 이어집니다.