DNS를 건드리지 않고 커스텀 도메인과 HTTPS 설정하기

커스텀 도메인은 이유 없이 사람들을 겁먹게 한다. 정작 중요한 레코드는 몇 개뿐이고, 추가하는 합리적인 순서가 있으며, 누구나 처음 한 번은 걸려 넘어지는 apex 함정이 하나 있을 뿐이다. 한 번 익혀두면 다시는 신경 쓸 일이 없다.

전체 그림

모든 현대적인 호스트 — Cloudflare Pages, Vercel, Netlify — 는 동일하게 동작한다: 대시보드에서 도메인을 추가하고(“pending”으로 표시됨), DNS 레코드를 호스트의 대상(target)으로 가리키게 하면, 호스트가 TLS 인증서를 자동으로 발급해준다. nginx도, certbot도, 인증서 파일을 여기저기 복사하는 일도 없다.

호스트의 대상은 그저 당신이 가리키는 호스트네임일 뿐이다:

잘 통하는 순서

1. 먼저 도메인을 추가하라 — 호스트 대시보드에서 먼저 추가해 호스트가 그것을 기다리도록 한다.
2. www는 쉽다 — 위의 호스트 대상으로 향하는 CNAME을 www에 추가하라.
3. apex가 함정이다. 맨 도메인(example.com)에는 순수 CNAME을 넣을 수 없다 — DNS 명세에 어긋난다. 대신 DNS 제공자의 CNAME flattening(Cloudflare는 이를 자동으로 처리한다) 이나 ALIAS / ANAME 레코드를 사용하라.
4. 정규(canonical) 주소를 정하라 — www → apex 또는 apex → www로 리다이렉트하고, 둘 다 살려두지 마라. 집은 하나, URL도 하나.
5. 검증을 기다린 다음, 자축하기 전에 HTTPS로 정상 접속되는지 확인하라. 인증서는 보통 몇 분 안에 발급된다.

사람들이 잊는 두 가지

• apex 대 www — 둘 다 설정한 다음, 하나를 다른 하나로 리다이렉트하라. 이걸 건너뛰면 example.com은 되는데 www.example.com은 인증서 오류를 내는(혹은 그 반대인) 이유가 된다.
• 이메일도 같은 도메인을 공유한다 — example.com의 앱과 같은 도메인의 이메일은 문제없이 공존한다; 그 김에 MX 레코드만 삭제하지 마라.

결론

이건 DevOps 프로젝트가 아니라 10분짜리 작업이다: 도메인 추가, www용 CNAME 하나, apex용 flattening/ALIAS, 정규 주소 선택, HTTPS 확인. 이제 인증서는 호스트가 알아서 할 문제다 — 그게 바로 마땅히 그래야 할 모습이다. 앱은 있는데 아직 도메인이 없는가? 그렇다면 전체 배포 과정을 보라.