vercel 가비아 도메인 연결을 하려는데 A 레코드, CNAME, 네임서버가 한꺼번에 나오면 막막해요. 저도 먼저 배포 상태와 기존 DNS부터 나눠 보니 어디를 고쳐야 할지 훨씬 선명해졌습니다.
Vercel 가비아 도메인 연결 전 무엇을 확인해야 할까요?

Vercel에 도메인을 붙이기 전에는 사이트 자체가 먼저 정상이어야 해요. Next.js 앱이든 React 사이트든 Vercel 프로젝트의 프로덕션 환경 배포가 끝났고, 배포 주소로 열리는지 확인해야 DNS 문제와 앱 문제를 나눠 볼 수 있습니다. 기본 `vercel.app` 주소에서 페이지가 열리지 않으면 가비아 DNS를 만져도 결과가 헷갈려요.
가비아 쪽에서는 도메인 구매가 끝났는지, 내가 관리 권한을 가진 도메인인지, 만료가 가까운지부터 봤습니다. 외부 등록기관에서 산 도메인은 Vercel이 자동으로 모든 설정을 바꿔주지 않기 때문에 소유 상태와 관리 화면 접근이 중요해요.
- Vercel 프로젝트의 프로덕션 배포 성공 여부
- `프로젝트명.vercel.app` 접속 여부
- 연결할 정확한 도메인 문자열
- 가비아 DNS 관리 권한
- 도메인 만료일과 자동 갱신 상태
- 기존 웹사이트와 이메일 사용 여부
DNS 설정 전에 현재 DNS 레코드를 화면 캡처나 별도 문서로 남겨두면 되돌릴 때 훨씬 편합니다.
커스텀 도메인의 루트와 www는 어떻게 정할까요?
루트 도메인은 `example.com`처럼 앞에 아무것도 붙지 않은 주소이고, apex 도메인이라고도 부릅니다. www 주소는 `www.example.com`이고, 기술적으로는 www라는 서브도메인입니다. 처음에는 둘이 같은 주소처럼 느껴졌지만, DNS에서는 서로 다른 항목으로 다뤄요.
커스텀 도메인을 운영할 때 두 주소를 따로 관리하기보다 하나를 대표 운영 도메인으로 정하고 다른 주소는 도메인 리디렉션으로 보내는 편이 깔끔했습니다. 그래야 검색엔진이 루트 도메인과 www 주소를 별도 페이지로 보지 않고, canonical URL도 한 방향으로 맞출 수 있어요. Vercel에서는 두 주소를 커스텀 도메인으로 넣은 뒤 기본 도메인 변경을 통해 기준 주소를 정리할 수 있습니다.
- 대표 운영 주소를 루트 또는 www 중에서 선택
- 두 주소를 모두 Vercel 프로젝트에 추가
- 보조 주소에서 대표 주소로 영구 리디렉션 설정
- canonical URL과 사이트맵 주소를 대표 주소로 통일
| 주소 유형 | 입력 예시 | 권장 역할 | 일반적인 DNS 방식 |
|---|---|---|---|
| 루트 도메인 | example.com | 대표 주소 또는 리디렉션 대상 | A 레코드 |
| www 주소 | www.example.com | 대표 주소 또는 보조 주소 | CNAME 레코드 |
| 별도 서브도메인 | blog.example.com | 블로그나 별도 서비스 | CNAME 레코드 |
Vercel 프로젝트 Domains 메뉴에는 어떻게 등록할까요?

vercel 가비아 도메인 연결의 첫 작업은 가비아가 아니라 Vercel 프로젝트 화면에서 시작했습니다. Domains 메뉴에 외부 도메인을 먼저 넣어야 Vercel이 현재 상태를 검사하고, 가비아에 입력할 커스텀 도메인 DNS 값을 보여주기 때문이에요.
- 대시보드에서 연결 대상 Vercel 프로젝트 선택
- Settings의 Domains 메뉴 이동
- Add Domain 버튼 선택
- 가비아에서 보유한 루트 도메인 입력
- 필요하면 www 주소도 별도로 추가
- 표시된 DNS 레코드 유형, 호스트, 대상 값 기록
도메인 등록 직후 Domains 메뉴에 `Invalid Configuration`이 보여도 바로 실패로 보지 않았습니다. 아직 가비아 DNS를 수정하지 않았다면 자연스러운 상태예요. 다만 같은 도메인이 다른 Vercel 프로젝트에 이미 붙어 있거나 도메인 소유권 확인이 필요한 경우가 있습니다. 그때는 Vercel 안내에 따라 기존 프로젝트 연결을 해제하거나 TXT 레코드를 추가해야 설정 검증이 이어집니다. 프론트엔드 배포가 여러 개라면 어느 Vercel 프로젝트에 붙일지도 꼭 다시 확인하세요.
가비아 네임서버와 Vercel DNS 중 무엇을 고를까요?
가비아에서 산 도메인이라고 해서 네임서버를 꼭 바꿔야 하는 것은 아니었습니다. 기본 선택은 가비아 네임서버 사용 상태를 유지하고, 가비아 DNS 관리에서 Vercel용 A와 CNAME만 넣는 방식이에요. 이렇게 하면 변경 범위가 작고 기존 DNS 설정을 그대로 보면서 필요한 부분만 고칠 수 있습니다.
반대로 Vercel DNS 사용을 원하면 Vercel이 안내한 네임서버로 위임해야 합니다. 이 방식은 커스텀 도메인을 Vercel에서 통합 관리하기 편하지만, 기존 이메일이나 다른 서비스용 DNS 레코드까지 새 DNS 영역에 옮겨야 해요. 네임서버 변경은 도메인 이전과 다릅니다. WHOIS 정보와 만료일 관리는 여전히 도메인 등록기관인 가비아에서 확인합니다.
| 비교 항목 | 가비아 네임서버 유지 | Vercel DNS 사용 |
|---|---|---|
| 설정 위치 | 가비아 DNS 관리 | Vercel DNS 화면 |
| 변경 범위 | A, CNAME 등 필요한 레코드만 수정 | DNS 관리 권한을 Vercel로 위임 |
| 기존 이메일 영향 | 메일 레코드를 그대로 두면 영향이 적음 | MX, TXT 값을 빠짐없이 옮겨야 함 |
| 관리 편의성 | 가비아 화면에 익숙하면 편함 | Vercel 중심으로 한곳에서 관리 가능 |
| 전환 시 주의점 | 중복 레코드만 정리 | 기존 레코드 누락 여부 점검 필요 |
| 적합한 상황 | 이메일이나 기존 서비스가 있을 때 | 새 도메인을 Vercel 중심으로 쓸 때 |
네임서버를 바꿔도 도메인 등록기관, WHOIS 정보, 만료일은 가비아에서 관리됩니다. 그래서 저는 처음 연결이라면 가비아 네임서버 사용으로 시작하는 편이 덜 부담스럽다고 봤어요.
가비아 DNS 관리에는 A와 CNAME을 어떻게 넣을까요?

가비아 DNS 설정 화면에서는 연결 대상별로 레코드 호스트 값과 대상 값을 나눠 입력합니다. 루트 도메인은 보통 `@` 기호의 A 레코드로 연결하고, www 주소는 `www`의 CNAME 레코드로 연결합니다. 예시 값은 `76.76.21.21`과 `cname.vercel-dns.com`이지만, 실제 작업에서는 Vercel Domains 화면의 현재 안내를 우선해야 해요.
- 가비아 로그인 후 My가비아 이동
- 도메인 관리 화면에서 대상 도메인 선택
- DNS 관리 또는 DNS 설정 화면 열기
- 루트용 A 레코드 행 추가
- www용 CNAME 레코드 행 추가
- 변경 내용을 저장
- Vercel Domains 화면으로 돌아가 상태 확인
| 연결 대상 | 레코드 유형 | 호스트 | 대상 값 예시 | TTL |
|---|---|---|---|---|
| 루트 도메인 | A | @ | 76.76.21.21 | 기본값 |
| www 주소 | CNAME | www | cname.vercel-dns.com | 기본값 |
| 일반 서브도메인 | CNAME | 원하는 이름 | Vercel 화면의 CNAME 대상 | 기본값 |
커스텀 도메인 DNS 레코드를 넣을 때 `@` 기호 자리에 도메인 전체 문자열을 그대로 쓰면 다른 값으로 처리될 수 있습니다. 일부 화면은 루트 호스트를 빈칸으로 표현하기도 해요. A 레코드, CNAME 레코드 대상 끝의 마침표 허용 여부와 정확한 값은 가비아 입력 규칙과 Vercel 현행 안내를 함께 확인하는 편이 좋습니다. TTL 값은 특별한 이유가 없다면 기본값으로 시작해도 충분했습니다.
소유권 확인과 기존 DNS 레코드 충돌은 어떻게 막을까요?
Vercel에서 도메인 소유권 확인을 요청하면 그때만 TXT 레코드를 추가하면 됩니다. 인증 문자열은 안내된 호스트와 값을 그대로 옮겨야 해요. 따옴표, 공백, 호스트 이름을 임의로 바꾸면 설정 검증이 늦어질 수 있습니다.
다만 기존 값을 지우기 전에는 이 DNS 설정이 현재 웹사이트, 이메일, 외부 서비스와 연결되어 있는지 먼저 봐야 합니다. 커스텀 도메인 연결 때문에 중복 레코드 삭제가 필요할 때도 있지만, 쓰임을 모르는 항목을 바로 지우면 다른 기능이 멈출 수 있어요.
- `@`에 남아 있는 이전 서버용 A 레코드
- `www`에 함께 존재하는 A와 CNAME
- 동일 호스트에 중복된 CNAME
- 활성화된 URL 포워딩
- 가비아 기본 파킹 페이지
- 이전 호스팅 서비스의 인증용 레코드
| 발견된 항목 | 예상 영향 | 처리 기준 |
|---|---|---|
| 이전 A 레코드 | 루트가 예전 서버로 응답 | 기존 A 레코드 충돌 여부 확인 후 정리 |
| 중복 CNAME | www 응답이 불안정할 수 있음 | CNAME 충돌이면 하나만 남김 |
| URL 포워딩 | Vercel 연결 전 다른 주소로 이동 | URL 포워딩 해제 필요 여부 확인 |
| 파킹 레코드 | 기본 안내 페이지가 계속 보임 | 파킹 페이지 제거 여부 검토 |
| Vercel TXT 인증값 | 도메인 소유권 확인에 필요 | Vercel이 확인할 때까지 유지 |
이메일용 MX SPF DKIM 레코드는 왜 건드리면 안 될까요?
웹 연결에 쓰는 A와 CNAME, 이메일 연결에 쓰는 MX 레코드와 SPF 레코드, DKIM 레코드, DMARC 레코드는 역할이 다릅니다. 그래서 가비아 네임서버를 유지하고 웹용 DNS 레코드만 바꾼다면 이메일 관련 값은 그대로 둘 수 있어요. DNSSEC 상태까지 손보는 경우에는 더 조심해서 봐야 합니다.
- 메일 수신 서버와 우선순위를 담은 MX 레코드
- 발신 서버 범위를 정의하는 SPF용 TXT 레코드
- 발신 메일 서명을 검증하는 DKIM 레코드
- 인증 실패 처리 정책을 지정하는 DMARC 레코드
- 메일 서비스 업체가 제공한 추가 확인 레코드
웹용 A와 CNAME만 수정할 때 이메일 레코드를 함께 삭제할 이유는 없습니다. 네임서버 변경이나 DNSSEC 상태 변경 전에는 이용 중인 메일 업체의 원본 설정값과 가비아의 현재 DNS 목록을 나란히 대조해 두는 편이 안전합니다.
DNS 전파와 HTTPS 인증서 상태는 어떻게 확인할까요?

DNS 전파는 저장하자마자 모든 지역에 동시에 반영되는 작업이 아니었습니다. 전파 대기 시간은 TTL, 통신사 DNS 캐시, 이전 설정에 따라 달라져요. 그래서 기다리기만 하기보다 DNS 조회 결과와 Vercel 상태 확인을 같이 보는 것이 좋았습니다.
DNS가 Vercel을 올바르게 가리키면 HTTPS 인증서는 보통 SSL 자동 발급 흐름으로 처리됩니다. 그래도 커스텀 도메인의 설정 완료 여부는 Vercel Domains 화면에서 다시 봐야 합니다. 인증서 갱신도 자동 처리되는 구조지만, 잘못된 DNS 응답이 오래 남으면 발급이 지연될 수 있어요.
- `nslookup example.com`: 루트 도메인의 A 응답 확인
- `dig example.com A` 및 `dig www.example.com CNAME`: 레코드 유형별 응답 확인
- DNS Checker: 여러 지역의 DNS 전파 상태 비교
- 가비아에서 레코드 저장 여부 확인
- 외부 DNS 조회로 반환값 확인
- Vercel Domains의 상태 새로 확인
- `https://` 루트와 www 주소 각각 접속
- HTTPS 인증서와 리디렉션 결과 확인
브라우저 캐시와 통신사 DNS 캐시 때문에 예전 화면이 보일 때도 있습니다. 시크릿 창, 다른 네트워크, 로컬 DNS 캐시 초기화를 보조 확인 수단으로 써보세요. 짧은 시간에 DNS 설정을 계속 바꾸면 어느 변경이 반영된 것인지 판단하기 더 어려워질 수 있습니다.
Invalid Configuration과 접속 오류는 어디서부터 볼까요?
Invalid Configuration 오류는 Vercel이 기대한 DNS 응답과 실제 응답이 다를 때 자주 보입니다. 연결 실패가 생기면 먼저 DNS 설정 문제인지, Vercel 프로젝트 문제인지, 앱 내부 문제인지 나눠서 보는 것이 빠릅니다.
| 증상 | 가능성이 높은 원인 | 우선 확인 항목 | 조치 |
|---|---|---|---|
| Invalid Configuration 오류 | A 레코드 또는 CNAME 레코드 값 불일치 | Vercel Domains 안내값 | 가비아 DNS 설정과 전파 상태 확인 |
| ERR_NAME_NOT_RESOLVED | DNS 응답 없음 | 도메인 만료, 네임서버, 저장 여부 | 가비아 관리 화면부터 재확인 |
| 루트 주소 접속 오류 | 루트용 A 레코드 누락 | `@` 호스트 응답 | A 레코드 추가 또는 수정 |
| www 접속 오류 | www용 CNAME 레코드 누락 | www가 Vercel에 등록됐는지 확인 | CNAME 추가와 도메인 등록 확인 |
| 도메인 인증 실패 | TXT 값 입력 오류 | 호스트, 값, 공백 | Vercel 안내와 한 글자씩 대조 |
| SSL 오류 또는 Mixed Content | 인증서 미발급 또는 내부 HTTP 자원 | HTTPS 인증서 상태, 페이지 자원 주소 | DNS 안정화 후 HTTP 자원 수정 |
| 404 오류 | 라우팅 또는 프로젝트 연결 문제 | Vercel 프로젝트, 프레임워크 라우팅 | 연결 대상과 경로 설정 확인 |
| 502 오류 | 서버 응답 또는 백엔드 문제 | 환경 변수, 백엔드 API 상태 | 로그 확인 후 필요한 배포 재실행 |
| 리디렉션 루프 | 중복 이동 규칙 | Vercel 리디렉션, 앱 설정, 외부 포워딩 | 이동 규칙을 한곳으로 정리 |
DNS 조회 결과가 틀렸다면 가비아 레코드와 전파 상태부터 봐야 합니다. DNS가 정확하다면 Vercel 프로젝트 연결과 최신 프로덕션 배포를 확인하세요. 404 오류나 502 오류에서는 배포 재실행만 반복하기보다 프레임워크 라우팅, 환경 변수, 백엔드 API 상태를 먼저 나눠 보는 편이 좋았습니다.
운영 도메인 전환 후 무엇을 더 점검할까요?
커스텀 도메인이 열린 뒤에는 루트 도메인, www, 기존 `vercel.app` 주소의 이동 경로를 정리해야 합니다. 대표 운영 도메인을 하나로 정하고 도메인 리디렉션이 일관되게 동작하는지 확인했어요. `vercel.app` 주소는 Vercel 프로젝트 기본 주소로 남을 수 있으니, canonical URL과 검색 기준 주소는 새 운영 도메인으로 맞추는 편이 좋습니다.
프리뷰 배포, 브랜치별 주소, API 도메인, 멀티 도메인은 운영 도메인과 역할이 다릅니다. 프로덕션 환경에 붙은 주소와 테스트용 주소를 섞어 쓰면 검색엔진 색인이나 API 호출 경로가 어긋날 수 있어요. 백엔드 API나 별도 서브도메인은 각각 서비스가 요구하는 A 레코드 또는 CNAME 레코드를 따라야 합니다.
- 루트와 www의 HTTPS 접속
- 대표 운영 도메인으로의 리디렉션
- canonical URL 일치
- Google Search Console 속성 등록
- 사이트맵 제출과 robots.txt 확인
- 주요 페이지의 검색엔진 색인 가능 여부
- 보안 헤더와 HSTS 적용 상태
- 도메인 만료일 및 자동 갱신 확인
| 확인 대상 | 정상 기준 | 확인 위치 |
|---|---|---|
| 루트와 www 주소 | 둘 다 HTTPS로 접속됨 | 브라우저와 Vercel Domains |
| HTTPS | HTTPS 인증서가 활성 상태 | Vercel 도메인 상태 |
| 리디렉션 | 대표 주소로 한 번만 이동 | 브라우저 주소창 |
| Search Console | 새 운영 도메인 속성 확인 | Google Search Console |
| 사이트맵과 robots.txt | 대표 주소 기준으로 접근 가능 | `/sitemap.xml`, `/robots.txt` |
| API와 서브도메인 | 각 서비스의 DNS 기준과 일치 | Vercel 프로젝트 또는 백엔드 서비스 |
와일드카드 도메인을 쓸 때는 별도 DNS와 인증서 조건이 적용될 수 있습니다. 이 경우에는 Vercel 프로젝트의 현행 Domains 안내를 기준으로 연결 체크리스트를 다시 보는 편이 안전합니다.
vercel 가비아 도메인 연결을 마치며 확인할 것
처음에는 DNS 용어가 한꺼번에 보여서 어디부터 손대야 할지 헷갈렸습니다. 직접 해보니 순서는 단순했어요. 먼저 Vercel 기본 주소가 열리는지 보고, Vercel Domains 화면에서 요구값을 확인한 뒤, 가비아 DNS에는 필요한 A와 CNAME만 정확히 넣으면 됩니다.
마지막으로 기존 이메일 레코드, 루트와 www 리디렉션, HTTPS, Search Console까지 확인하면 운영 단계에서 생길 수 있는 불편을 많이 줄일 수 있습니다. 설정값이 바뀔 수 있는 부분은 화면 안내를 기준으로 다시 확인하세요. 이 기록이 첫 도메인 연결에서 불안한 지점을 하나씩 지우는 데 도움이 되면 좋겠습니다.