루트 도메인과 서브도메인
`emfls.com`처럼 앞에 아무것도 붙지 않은 주소를 루트 도메인 또는 apex 도메인이라고 부릅니다. `www.emfls.com`은 www라는 서브도메인입니다.
GitHub Pages에서 루트 도메인을 쓰려면 GitHub가 안내하는 A 레코드를 등록하고, www 주소는 보통 CNAME으로 GitHub Pages 기본 주소를 가리키게 합니다.
DNS 전파 시간 고려하기
DNS를 수정한 뒤 바로 결과가 바뀌지 않는 경우가 많습니다. 브라우저 캐시, 통신사 DNS 캐시, 기존 레코드의 TTL 때문에 몇 분에서 수 시간까지 차이가 날 수 있습니다.
설정을 바꾼 직후에는 여러 번 수정하기보다 현재 레코드가 정확한지 확인하고 기다리는 편이 좋습니다. 성급하게 값을 바꾸면 어떤 변경이 문제였는지 추적하기 어려워집니다.
GitHub 저장소의 CNAME 파일
GitHub Pages는 저장소 루트 또는 빌드 결과물에 `CNAME` 파일이 있어야 사용자 지정 도메인을 안정적으로 유지합니다. 파일에는 대표 도메인 한 줄만 넣는 것이 일반적입니다.
대표 주소를 `emfls.com`으로 정했다면 CNAME 파일에는 `emfls.com`을 넣습니다. www 주소는 DNS와 GitHub Pages 설정에서 보조적으로 처리합니다.
가비아에서 Cloudflare로 DNS 관리를 넘긴 사례
기존에는 가비아 DNS에 GitHub Pages용 A 레코드 4개와 `www -> emfls.github.io` CNAME이 있었습니다. Cloudflare를 사용하기로 한 뒤에는 가비아에서 개별 DNS 레코드를 수정하는 대신 네임서버를 Cloudflare가 안내한 값으로 변경했습니다.
이 차이를 이해하는 것이 중요합니다. 네임서버를 바꾸면 이후 DNS의 기준은 가비아 레코드 화면이 아니라 Cloudflare DNS 화면입니다. 가비아에서 CNAME을 계속 수정하면 실제 적용 위치를 착각할 수 있습니다.
준비할 스크린샷
가비아 네임서버 변경 화면과 Cloudflare DNS 레코드 화면을 각각 캡처하면 “레코드 수정”과 “네임서버 변경”의 차이를 설명하기 좋습니다.
실전 점검표
- 현재 도메인의 네임서버가 어디를 가리키는지 확인한다.
- Cloudflare를 쓰는 경우 가비아 DNS 레코드가 아니라 Cloudflare DNS를 기준으로 본다.
- 루트 도메인과 `www` 도메인이 같은 사이트로 연결되는지 확인한다.
- DNS 변경 후 바로 판단하지 말고 전파 시간을 둔다.
흔한 실수
- Cloudflare 네임서버로 바꾼 뒤에도 가비아 DNS 레코드를 수정하는 것.
- 루트 도메인 `@`에 일반 CNAME을 넣으려다 오류를 만드는 것.
- 예전 GitHub Pages 레코드와 새 Pages 레코드를 동시에 남겨두는 것.
자주 묻는 질문
가비아에서 A 레코드를 직접 바꾸면 안 되나요?
Cloudflare 네임서버를 쓰기로 했다면 가비아의 개별 DNS 레코드는 더 이상 기준이 아닙니다. Cloudflare DNS에서 관리해야 합니다.
DNS 전파는 얼마나 걸리나요?
몇 분 안에 반영되는 경우도 있지만 보통 1~2시간, 길면 24시간까지 걸릴 수 있습니다. 변경 직후에는 여러 번 수정하지 말고 상태를 확인하세요.
www 주소도 꼭 연결해야 하나요?
필수는 아니지만 사용자가 `www`를 붙여 접속할 수 있으므로 연결하거나 대표 도메인으로 리디렉션하는 것이 좋습니다.