도메인과 네임서버는 어떻게 연결되는가?

00 / PLAIN EXPLANATION

도메인은 주소, 네임서버는 안내데스크, DNS 레코드는 실제 목적지를 적어둔 안내표라고 생각하면 쉽습니다.

웹사이트 연결이 어려운 이유는 도메인, 네임서버, DNS, 호스팅을 모두 한 덩어리로 생각하기 때문입니다. 실제로는 각각 하는 일이 다릅니다.

DOMAIN사용자가 입력하는 주소

예: sostlabs.com. 주소의 등록과 갱신은 도메인 등록기관에서 관리합니다.

NAMESERVERDNS 정보를 어디서 관리하는지 알려줌

이 도메인의 설정을 어느 DNS 서비스에 물어봐야 하는지 지정합니다.

DNS RECORD실제 연결 규칙

웹은 어느 서버로, 메일은 어느 서버로 갈지 A·CNAME·MX·TXT 등으로 기록합니다.

HOSTING실제 사이트가 존재하는 곳

GitHub Pages, Firebase Hosting, 웹호스팅, 아임웹 같은 서비스가 여기에 해당합니다.

01주소 입력

02네임서버 확인

03DNS 레코드 조회

04실제 서버 접속

01 / DOMAIN

도메인을 구입한 곳은 “주소의 소유와 갱신”을 관리하는 곳이지, 사이트가 저장된 곳은 아닙니다.

가비아, 후이즈, Cloudflare Registrar 같은 서비스에서 도메인을 구매하면 해당 등록기관이 도메인의 등록 상태와 갱신, 소유자 정보를 관리합니다. 하지만 그 도메인으로 어떤 웹사이트를 보여줄지는 별도의 DNS 설정으로 정합니다.

예를 들어가비아에서 example.com을 구매하고, 실제 사이트는 GitHub Pages에 올려도 전혀 이상하지 않습니다.

가비아는 주소를 관리하고, GitHub는 사이트 파일을 제공하며, DNS가 둘을 연결합니다.

EXAMPLE / 서로 다른 서비스가 역할을 나누는 경우

도메인 구매: 가비아
DNS 관리: 가비아 DNS 또는 Cloudflare
웹사이트: GitHub Pages
회사 메일: Google Workspace

02 / NAMESERVER

네임서버를 바꾼다는 것은 DNS 설정 한 줄이 아니라 “DNS 관리 장소 전체”를 바꾸는 일에 가깝습니다.

브라우저나 메일 서버가 example.com의 정보를 찾으려면 먼저 이 도메인의 DNS 정보를 누가 관리하는지 확인합니다. 그 역할을 지정하는 것이 네임서버입니다.

예를 들어 현재 가비아 네임서버를 쓰다가 Cloudflare 네임서버로 변경하면, 이후에는 Cloudflare에 입력된 DNS 레코드가 기준이 됩니다. 가비아 화면에 예전 A·MX·TXT 값이 남아 있어도 새 네임서버가 Cloudflare라면 그 값들은 더 이상 실제 응답에 사용되지 않습니다.

그래서 네임서버 변경이 위험할 수 있습니다.

새 DNS 서비스에 웹·메일·인증용 레코드를 미리 복사하지 않고 네임서버부터 바꾸면 사이트뿐 아니라 회사 메일까지 함께 끊길 수 있습니다.

03 / DNS RECORDS

DNS 레코드는 “무엇을 어디로 보낼지”를 정하는 실제 연결 규칙입니다.

A도메인 → IPv4 주소

루트 도메인을 특정 서버 IP에 연결할 때 자주 사용합니다.

AAAA도메인 → IPv6 주소

IPv6 환경에서 서버 주소를 연결하는 레코드입니다.

CNAME이름 → 다른 이름

www.example.com을 호스팅 서비스가 제공한 주소로 연결할 때 많이 사용합니다.

MX메일 수신 서버 지정

example.com으로 들어오는 이메일을 어느 메일 서비스가 받을지 정합니다.

TXT문자열 기반 검증·정책

SPF, 도메인 소유권 확인, 각종 서비스 인증 등에 사용됩니다.

TTLDNS 응답 캐시 시간 기준

레코드 변경이 전파되는 체감 시간에 영향을 줄 수 있습니다.

GitHub Pages 연결을 단순화해서 보면

EXAMPLE / example.com

루트 도메인: A 레코드로 서비스가 요구하는 IP 연결
www: CNAME으로 사용자명.github.io 같은 호스트 연결
메일: 기존 MX와 TXT는 그대로 유지

이처럼 사이트를 옮긴다고 모든 DNS를 바꾸는 것이 아닙니다. 웹 연결에 필요한 레코드만 변경하고 메일·인증 레코드는 유지할 수 있습니다.

04 / PROPAGATION

DNS 변경은 저장 버튼을 누르는 순간 모든 사용자에게 동시에 적용되지 않습니다.

DNS 응답은 통신사, 회사 네트워크, 공용 리졸버 등 여러 곳에서 일정 시간 캐시될 수 있습니다. 그래서 변경 직후 어떤 사람에게는 새 사이트가 보이고, 다른 사람에게는 이전 사이트가 보이는 상황이 생길 수 있습니다.

BEFORE현재 레코드 백업

A, CNAME, MX, TXT 전체를 캡처하거나 기록합니다.

PREPARE새 서버 먼저 준비

도메인을 바꾸기 전 임시 주소에서 새 사이트가 정상인지 확인합니다.

SWITCH필요한 레코드만 변경

웹 이전이라면 보통 웹 연결용 A/CNAME부터 바꿉니다.

VERIFY여러 환경에서 확인

PC·모바일·외부 네트워크에서 새 서버 연결 여부를 확인합니다.

05 / MIGRATION

사이트 이전에서 가장 안전한 방식은 “네임서버부터 바꾸는 것”이 아니라 현재 구조를 먼저 그리는 것입니다.

기존 사이트가 아임웹이고 새 사이트는 GitHub Pages라고 해서 반드시 네임서버를 바꿔야 하는 것은 아닙니다. 현재 DNS를 그대로 유지하면서 웹용 레코드만 수정할 수도 있습니다. 반대로 DNS 관리까지 다른 서비스로 옮기고 싶다면 기존 레코드를 모두 복제한 뒤 네임서버를 변경해야 합니다.

변경 전에 답할 수 있어야 하는 질문

도메인은 어느 계정에서 구매했는가?
현재 네임서버는 어디를 가리키는가?
실제 DNS 레코드는 어느 화면에서 관리하는가?
웹사이트는 어느 서비스에 올라가 있는가?
회사 메일은 어떤 서비스를 사용하는가?
서브도메인, 인증, 소유권 확인 TXT가 있는가?
새 호스팅은 어떤 A 또는 CNAME 값을 요구하는가?

실무에서 자주 생기는 실수“웹사이트만 바꾸려고 했는데 메일이 끊겼다.”

대부분 웹과 메일이 같은 도메인을 공유한다는 점을 놓치거나, 네임서버를 바꾸면서 기존 MX/TXT 레코드를 복사하지 않았을 때 발생합니다.

SOST의 기준

도메인 소유권, 네임서버, DNS 레코드, 웹호스팅, 메일을 각각 다른 레이어로 보고 필요한 레이어만 변경합니다.

도메인과 네임서버는어떻게 연결되는가?