Cloudflare로 도메인 구매하고 Vercel에 연동하기

본 hijero.me 웹사이트를 구현하고, vercel 배포 시 제공되는 기본 도메인(*.vercel.app) 대신 커스텀 도메인을 연결하는 것도 좋겠다 판단했습니다.

향후 유지보수 동기부여(매일 매일 돈 쓰고 있는 것과 같으니 애착을 갖고 관리해야해!)도 되고, 앞으로 틈틈이 구현해 나갈 토이프로젝트들에서도 서브 도메인을 붙임으로써 하나의 브랜딩 생태계를 구축할 수 있겠다 생각해서입니다.

도메인 구매는 인턴 때 해본 적이 있고, DNS 설정 등은 이전 직장에서도 해봤기에 어렵지 않았지만, 어느 서비스에서 살지 고민이 좀 됐습니다.

기존에 알고 있던 곳과 조사해봤을 때 도메인 제공 업체 후보로는 GoDaddy, 가비아, 그리고 Cloudflare 세 가지를 추려보았습니다.

도메인 호스팅 서비스 특징 비교

보편적으로 많이 사용되는 위 세 서비스를 다음과 같이 비교할 수 있습니다.

표 항목에 * 붙인 부분들에 대해 하나씩 살펴보겠습니다.

WHOIS 보호는 도메인 등록자의 개인정보 공개 여부와 관련이 있습니다. 도메인을 구매하면 등록자의 이름, 이메일, 주소, 전화번호가 WHOIS 공개 데이터베이스에 올라갑니다. 누구나 whois hijero.me를 조회하면 이 정보를 볼 수 있어서, 스팸이나 마케팅 연락의 표적이 될 수 있습니다. GoDaddy와 가비아는 이 정보를 숨겨주는 "WHOIS Privacy Protection" 서비스를 연간 ~$10에 별도 판매합니다. Cloudflare는 모든 도메인에 무료로 포함됩니다.

업셀링(upselling)이란 도메인 구매 과정에서 "같이 사면 어때요?"식으로 추가 상품을 권유하는 행위입니다. GoDaddy는 결제 플로우에서 웹호스팅, 비즈니스 이메일, SSL 인증서, 사이트 빌더 등을 적극적으로 끼워 넣어, 원하는 것만 사기 위해 여러 번 "No thanks"를 클릭해야 합니다. 가비아도 유사하지만 GoDaddy보다는 덜합니다. Cloudflare는 레지스트라(도메인 등록 대행 업체) 자체가 부가 서비스 판매 모델이 아니라 가입자 기반 확장이 목적이라 업셀링이 없습니다.

DNS 관리(네임서버)는 도메인의 DNS 설정을 어느 서버에서 관리할지의 문제를 의미합니다. GoDaddy와 가비아는 자체 DNS도 제공하고 Cloudflare·Route53 등 외부 네임서버로 자유롭게 전환할 수 있습니다. 반면 Cloudflare 레지스트라는 구매 즉시 Cloudflare 네임서버(ns1.cloudflare.com)로 고정되어 변경이 불가능합니다. 제약처럼 보이지만, Cloudflare DNS 자체가 전 세계 최상위권 응답 속도를 제공하기 때문에 실질적 불편함은 거의 없다고 합니다.

API 자동화는 DNS 레코드 추가·수정, 도메인 설정 변경을 코드로 자동화할 수 있는지 여부를 뜻합니다. GoDaddy는 API를 제공하지만 기능이 제한적이고, 가비아는 API 지원이 더 제한적입니다. Cloudflare는 완전한 REST API와 공식 Terraform 프로바이더를 제공해 Infrastructure as Code(IaC)가 가능합니다. 지금 당장은 필요 없더라도, 사이트가 성장해 자동화가 필요해질 때 Cloudflare 기반이 훨씬 유리합니다.

Vercel 직접 연동은 도메인을 Vercel 프로젝트에 연결하는 편의성을 말합니다. GoDaddy·가비아는 Vercel이 요구하는 A 레코드와 CNAME 레코드를 각 레지스트라의 DNS 화면에서 수동으로 입력해야 합니다. Cloudflare도 기본적으로 수동 DNS 추가 방식이지만, 레코드 충돌이 발생하면 Vercel이 이를 감지해 "Authorize DNS records from Vercel" 모달로 자동 해소를 제안합니다. 뒤에서 자세히 다루겠습니다.

네임서버 이전은 DNS 관리 서버를 다른 곳으로 옮길 수 있는지의 문제입니다. Cloudflare 레지스트라에서 구매하면 네임서버가 Cloudflare로 고정되어 다른 DNS 서비스로 이전할 수 없습니다. GoDaddy·가비아는 자유롭게 전환할 수 있습니다. 이 제약이 걸린다면 GoDaddy·가비아에서 도메인을 사고 DNS만 Cloudflare로 이전하는 방법도 있습니다.

한가지, SSL에 대해서도 덧붙이자면, Cloudflare는 Universal SSL을 무료로 제공합니다. 트래픽이 Cloudflare Proxy를 통과하면 사용자 ↔ Cloudflare 구간이 자동으로 HTTPS로 보호됩니다. 그런데 Vercel을 호스팅으로 사용하는 경우엔 이야기가 조금 다릅니다. Vercel이 Let's Encrypt 기반으로 도메인 SSL 인증서를 자동으로 발급해주기 때문에, Cloudflare SSL의 차별점은 상대적으로 줄어듭니다.

즉, SSL 제공 유무 자체는 결정에서 큰 영향을 미치지 않았습니다.

결론: Cloudflare를 선택

위 특징을 면밀하게 비교해봤을 때 Cloudflare에서 도메인 구매를 진행하기로 결정했습니다.

결정 배경을 정리하면 이렇습니다.

• .me 도메인 $16.56/년, 갱신 시에도 동일 금액 (GoDaddy는 갱신 시 크게 오름)
• WHOIS 개인정보 보호 무료 (GoDaddy·가비아는 별도 유료)
• CDN + DDoS 보호 기본 포함 — 트래픽이 늘어도 추가 비용 없음
• Vercel과의 DNS 충돌 자동 해소 지원
• 향후 Cloudflare Workers, R2 등 생태계를 확장할 가능성을 열어둠

네임서버를 Cloudflare로 고정해야 한다는 제약이 있지만, Vercel로 배포하는 상황에서는 이 조합이 가장 자연스럽고 합리적이라고 판단했습니다.

Cloudflare에서 도메인 구매하기

먼저 Cloudflare 사용은 처음이라, 개인 회원으로 회원 가입을 진행한 후 로그인하여 대시보드에 들어갑니다.

대시보드 -> 도메인 페이지 접근

Cloudflare에 처음 로그인하면 도메인 탭에 아무것도 없습니다.

"Add domain" 버튼 눌러서 도메인 구매를 시작합니다.

도메인 검색 및 선택

사고 싶은 도메인을 검색하면 구매 가능할 시 비용이 뜹니다. 저의 경우, hijero.me를 $16.56에 살 수 있다고 나오네요. 그 아래 대체 도메인으로 유사한 이름과 비용을 제안해주기도 합니다.

.com이나 .org가 더 저렴하긴 했지만, 저의 "Jerome" 이라는 이름을 도메인에 자연스럽게 융화시키면 좋겠다 싶어 .me를 선택했습니다.

등록 정보 입력 및 결제

1년 요금제를 확인하고 영문주소, 결제 수단 정보 등 입력합니다.

저의 경우 만료일은 2027년 5월 23일입니다. Cloudflare at-cost 정책 덕분에 갱신 때도 동일한 금액을 냅니다. 참고로 결제 시 미화 달러로 지불 되니 원화 환산 가격은 결제 시점 환율에 따라 다르겠네요..

구매 완료

끝났습니다. 역시 쉽네요.

하단 WHOIS 정보에서 Registrar가 Cloudflare로 등록된 것을 확인할 수 있습니다. 구매 완료와 동시에 네임서버도 Cloudflare로 자동 설정됩니다.

Vercel 프로젝트에 도메인 연동하기

도메인을 샀으니 이제 Vercel에 연결할 차례입니다.

구매 직후 DNS 상태

Cloudflare DNS 탭에서 확인하면 레코드가 아무것도 없습니다.

+ Add record 버튼을 눌러 Vercel이 요구하는 레코드를 여기에 추가해야 합니다.

Vercel에서 필요한 DNS 레코드 확인

Vercel 프로젝트 → Settings → Domains 탭에서 hijero.me를 추가합니다. 그러면 Vercel이 어떤 DNS 레코드가 필요한지 알려줍니다.

A 레코드와 CNAME(www) 레코드가 필요하다는 안내를 확인했습니다. 이 레코드들을 Cloudflare DNS에 직접 추가하면 되는데, 진행하면서 문제가 하나 발생했습니다.

DNS 충돌 발생 — Authorize 필요 모달

Cloudflare DNS에 레코드를 추가하는 과정에서 Vercel이 요구하는 레코드와 충돌이 발생했습니다. www CNAME 레코드를 Proxied 상태로 추가했는데, Vercel 측에서 이를 감지하고 다음 모달을 표시했습니다.

다음 화면은 Vercel이 Cloudflare DNS에 직접 레코드를 수정·추가할 수 있도록 일회성 권한을 요청하는 화면인데요, 여기서 눈여겨볼 부분이 두 가지 있습니다.

첫 번째는 추가될 레코드입니다. _vercel TXT 레코드와 www CNAME 레코드가 새로 등록됩니다.

두 번째는 제거될 레코드입니다. 제가 추가한 www CNAME(Proxied 상태)이 삭제 대상으로 표시됩니다. 이유는 Proxied 상태로 남아 있으면 Vercel이 SSL 인증서를 직접 발급할 수 없어서 충돌이 발생하기 때문입니다.

주의: "Authorize" 버튼은 단순한 동의가 아니라 기존 DNS 레코드를 삭제하는 다소 위험한 액션입니다. 실서비스가 운영 중인 도메인이라면 반드시 삭제 대상 레코드를 먼저 확인해야 합니다.

그리고 여기서 _vercel TXT 레코드가 낯설게 느껴질 수 있는데, 조사해보니 다음과 같았습니다.

_vercel TXT 레코드란?

Vercel이 "이 도메인이 내 계정 소유임"을 DNS를 통해 증명하는 소유권 검증 토큰입니다. Vercel 내부 API가 고유 토큰 값을 생성하고, 이를 _vercel.hijero.me TXT 레코드에 등록하면 Vercel이 DNS 조회로 토큰을 확인해 소유권을 인정하는 방식입니다.

레코드 이름 앞에 _가 붙은 이유는 RFC 2782/6763에서 정의한 서비스 전용 DNS 네임 컨벤션 때문입니다. _로 시작하는 이름은 일반 호스트명과 구분되어, 서비스별 메타데이터를 DNS에 안전하게 저장하기 위한 규칙입니다. 이메일 인증에 쓰이는 _dmarc, _domainkey나 Let's Encrypt의 _acme-challenge도 같은 패턴입니다.

AWS와 비교하면 차이가 더 명확해집니다. AWS Certificate Manager는 유사한 목적으로 CNAME 레코드(_abc123.example.com → _xyz.acm-validations.aws)를 사용합니다. Route53은 AWS가 DNS 자체를 관리하기 때문에 이런 별도 검증이 불필요합니다.

Vercel이 TXT 레코드 방식을 선택한 이유는 멀티테넌트 플랫폼의 특성 때문입니다. Vercel은 누구나 임의의 도메인을 자신의 프로젝트에 추가할 수 있는 구조입니다. 검증 없이 도메인을 추가할 수 있다면 타인의 도메인을 가로채는 하이재킹이 가능해집니다. _vercel TXT 토큰은 이를 막기 위한 장치입니다.

최종 DNS 설정 완료

다시 돌아가, Authorize를 승인해주면 Vercel이 자동으로 레코드를 정리해줍니다.

최종적으로 세 가지 레코드가 연동됩니다.

• A 레코드: hijero.me (Proxied, Auto TTL) — Cloudflare CDN을 통과하는 메인 도메인
• CNAME: www (DNS only, 10분 TTL) — Vercel SSL 인증서 발급을 위해 Proxy 해제
• TXT: _vercel (DNS only, 10분 TTL) — 도메인 소유권 검증 토큰

www CNAME과 _vercel TXT가 DNS only인 이유는, Cloudflare Proxy(주황 구름 아이콘)를 켜면 Vercel이 SSL 인증서를 직접 발급할 수 없기 때문입니다. A 레코드만 Proxied로 두어 메인 도메인은 Cloudflare CDN의 혜택을 여전히 갖고, 나머지는 Vercel이 직접 처리하도록 분리한 구조입니다.

추가 확인 사항: 환경변수 업데이트 필요 여부

도메인 연동을 마치고 Google Search Console에서 sitemap을 제출하러 들어갔는데, sitemap 내 URL이 여전히 xxxx.vercel.app 형태로 되어 있는 것을 발견했습니다. 원인을 찾아보니 Vercel 환경변수 NEXT_PUBLIC_SITE_URL이 초기 배포 때 설정했던 .vercel.app 주소 그대로였습니다. 따라서 이 환경변수값을 연결한 도메인으로 바꿔줘야 했습니다.

이 프로젝트에서는 lib/config/site.ts에서 NEXT_PUBLIC_SITE_URL 환경변수를 읽어 SITE_URL 상수를 만듭니다. 그리고 sitemap.ts와 robots.ts가 이 상수를 공통으로 참조하고 있어, 변수 하나가 잘못되어 있으면 sitemap.xml, robots.txt, canonical 태그, OG URL 등이 전부 틀린 주소를 가리키게 됩니다.

참고: 환경변수 변경 후에는 반드시 재배포가 필요합니다. Vercel 대시보드에서 환경변수를 저장한 것만으로는 기존 빌드에 반영되지 않으므로, 저장 후 Redeploy를 명시적으로 트리거해야 합니다.

처리 순서는 다음과 같습니다.

1. Vercel 프로젝트 → Settings → Environment Variables → NEXT_PUBLIC_SITE_URL 값을 커스텀 도메인(https://hijero.me)으로 수정
2. Redeploy 트리거 → 완료 후 https://hijero.me/sitemap.xml 직접 접근해 URL 확인
3. Google Search Console → Sitemaps → sitemap URL 제출

Google 이 sitemap을 통해 정상적으로 페이지들을 읽게 되면 제출된 사이트맵 에서 상태가 "성공" 으로 표시됩니다.

마치며

도메인 구매부터 실 연동 및 검증까지 전체 과정은 15-20분 정도 걸렸습니다. DNS 전파는 최대 48시간이라고 하지만, 실제로는 5분만에 완료된 것 같습니다.

당연히 문제가 없는 쉬운 작업이라 생각했는데 막상 진행하면서 짚고 넘어가면 좋을 만한 것들이 있었습니다.

먼저 Proxied vs DNS only 설정이 Vercel SSL 인증서 발급에 영향을 준다는 점입니다. 처음에 www CNAME을 Proxied로 추가했다가 충돌이 발생한 것도 이 때문이었습니다. Cloudflare Proxy를 켜면 트래픽이 Cloudflare 엣지에서 종료되어 Vercel이 직접 SSL을 발급하지 못합니다.

그리고 _vercel TXT 레코드의 의미도 새롭게 알게 되었습니다. 단순한 설정 값이 아니라, 멀티테넌트 플랫폼에서 도메인 하이재킹을 막기 위한 RFC 표준 기반의 소유권 검증 메커니즘이라는 점이 흥미로웠습니다. _dmarc나 _acme-challenge와 같은 패턴이라는 것도요.

마지막으로 환경변수 업데이트 역시 놓치기 쉬운 부분이었습니다. NEXT_PUBLIC_SITE_URL처럼 사이트 URL을 기반으로 하는 환경변수가 있다면, 도메인 연동 직후 값을 갱신하고 재배포해야 sitemap과 SEO 메타데이터가 올바른 URL을 가리킵니다.

이렇게 해서 도메인 구매, Vercel 연동, 환경변수 정비까지 한 사이클을 마무리 해보았습니다. Cloudflare를 이렇게 개인적으로 활용해 보는 것도 좋은 경험이었습니다.

긴 글 읽어주셔서 감사합니다.