도메인을 처음 붙일 때 가장 많이 나오는 말이 있습니다.

도메인은 샀는데 왜 사이트가 안 보이지?

대부분은 서버가 고장 난 게 아니라, 도메인 등록, 네임서버, DNS 레코드, 캐시 시간이 서로 다른 개념이라는 점에서 막힙니다.

이 글은 2026년 5월 4일 기준 ICANN과 Cloudflare 공식 문서를 바탕으로, 초급자가 처음 도메인을 붙일 때 알아야 할 것만 추렸습니다.

1. 도메인, 서버, 호스팅은 같은 말이 아닙니다

가장 먼저 이 세 개를 분리해서 봐야 합니다.

  • 도메인: 사람이 읽는 주소
  • 서버: 실제 파일이나 앱이 돌아가는 컴퓨터
  • DNS: 그 도메인이 어느 서버를 가리키는지 알려주는 시스템

ICANN 설명대로 인터넷은 결국 이름과 숫자 주소(IP)를 함께 씁니다.
도메인은 사람이 외우기 쉬운 이름이고, DNS는 그 이름을 IP 주소로 연결해주는 계층입니다.

즉, 도메인을 샀다는 것만으로는 사이트가 열리지 않습니다.
도메인이 어느 DNS를 쓰는지, DNS가 어느 서버를 가리키는지까지 맞아야 합니다.

2. 등록자, 등록기관, 레지스트리를 섞어 보면 헷갈립니다

ICANN 자료에서는 역할을 이렇게 나눕니다.

  • Registrant: 도메인을 등록한 사람이나 회사
  • Registrar: 도메인 등록 서비스를 파는 회사
  • Registry: 해당 TLD 데이터를 운영하는 쪽

초급자에게 중요한 건 어디서 무엇을 바꾸는가입니다.

보통:

  • 등록자 정보, 갱신, 이전, 네임서버 변경은 Registrar에서 합니다.
  • 실제 DNS 레코드 관리는 사용하는 DNS 서비스에서 합니다.

예를 들어 도메인을 A사에서 샀고 DNS는 Cloudflare에서 관리한다면:

  1. A사에서 네임서버를 Cloudflare로 바꿉니다.
  2. Cloudflare에서 A, CNAME, MX, TXT 같은 레코드를 관리합니다.

이 둘을 한 화면에서 모두 하는 경우도 있지만, 개념상으로는 다른 작업입니다.

3. 네임서버를 바꾸는 순간 “어느 DNS가 정답인지”가 바뀝니다

네임서버는 이 도메인의 권한 있는 DNS가 누구인가를 정하는 설정입니다.

실무에서는 이 순서로 생각하면 됩니다.

  1. 도메인을 산 등록기관 화면으로 간다.
  2. 네임서버를 현재 쓰려는 DNS 제공자 값으로 바꾼다.
  3. 그 DNS 제공자에서 실제 레코드를 넣는다.

중요한 점은, 네임서버를 바꾸기 전에는 새 DNS 화면에 레코드를 예쁘게 넣어도 외부에서 아직 안 볼 수 있다는 점입니다.
반대로 네임서버만 바꾸고 레코드를 비워두면 사이트가 열리지 않을 수 있습니다.

즉, 네임서버 변경과 레코드 입력은 세트로 봐야 합니다.

4. 처음에는 모든 레코드를 다 알 필요 없고, 자주 쓰는 것만 알면 됩니다

Cloudflare 공식 문서 기준으로 DNS 레코드는 각 타입마다 역할이 다릅니다.
초급자가 먼저 익힐 것은 아래 정도면 충분합니다.

  • A: 도메인이나 서브도메인을 IPv4 주소로 연결
  • AAAA: IPv6 주소로 연결
  • CNAME: 다른 호스트 이름을 가리킴
  • MX: 메일 수신 서버 지정
  • TXT: 인증 문자열, SPF/도메인 검증 같은 텍스트 정보

예를 들면:

  • jestools.com을 서버 IP로 붙이면 A
  • www.example.com을 example.com으로 돌리면 CNAME
  • Google Search Console, 메일 서비스 인증을 하면 TXT

처음부터 복잡한 레코드를 다 건드리기보다, 웹 열기, 메일, 도메인 인증 세 종류만 먼저 이해하는 편이 낫습니다.

5. TTL은 “왜 바로 안 바뀌지?”를 설명하는 값입니다

Cloudflare 설명에 따르면 TTL은 DNS 레코드가 리졸버에 얼마나 오래 캐시되는지를 정합니다.
즉, TTL이 길수록 조회는 빨라질 수 있지만, 변경 사항이 사용자에게 도달하는 시간도 길어질 수 있습니다.

초급자가 자주 오해하는 부분은 이겁니다.

  • 레코드를 저장했다고 바로 전 세계가 동시에 바뀌는 것은 아니다
  • TTL이 짧아도 로컬 캐시 때문에 실제 체감은 더 늦을 수 있다

Cloudflare는 프록시된 레코드의 기본 TTL을 300초로 설명하지만, 실제 체감 변경은 5분보다 더 걸릴 수 있다고 안내합니다.

그러니 DNS 작업을 할 때는:

  1. 저장 직후 바로 패닉하지 않기
  2. 변경 전 TTL을 너무 길게 두지 않았는지 보기
  3. 브라우저/로컬 DNS 캐시 영향도 의심하기

이 세 가지를 같이 봐야 합니다.

6. Cloudflare를 쓴다면 Proxied와 DNS only 차이를 알아야 합니다

Cloudflare 문서 기준으로 프록시된 레코드는 dig로 조회했을 때 Cloudflare IP가 보이고, HTTP 트래픽은 Cloudflare를 거쳐 갑니다.
반대로 DNS-only 레코드는 원본 서버 IP가 그대로 드러날 수 있습니다.

특히 초급자가 놓치기 쉬운 함정이 있습니다.

  • 메인 웹 도메인은 proxied
  • 다른 서브도메인은 DNS-only
  • 그런데 둘 다 같은 원본 IP를 가리킴

이 경우 DNS-only 레코드가 원본 IP를 공개할 수 있습니다.
Cloudflare도 HTTP 트래픽을 처리하는 레코드는 프록시를 권장하고, 같은 원본 IP를 공유하는 DNS-only 레코드는 주의하라고 안내합니다.

즉, Cloudflare를 쓰는 목적이 원본 IP를 숨기고 보호 기능을 붙이는 것이라면, 레코드 단위로 다시 확인해야 합니다.

7. DNSSEC은 좋은데, 제공자 이동 전후 순서를 틀리면 장애가 납니다

DNSSEC은 DNS 응답이 위조되지 않았는지 확인하는 추가 인증 계층입니다.
Cloudflare도 DNSSEC이 DNS 요청이 스푸핑된 도메인으로 가지 않도록 돕는다고 설명합니다.

다만 기존 도메인을 Cloudflare 권한 네임서버로 옮길 때는 순서가 중요합니다.
Cloudflare 문서 기준으로, 기존 제공자에서 DNSSEC이 켜진 상태로 네임서버만 먼저 바꾸면 연결 오류가 날 수 있습니다.

실무적으로는 보통 이렇게 갑니다.

  1. 기존 DNS 제공자 쪽 DNSSEC 상태 확인
  2. 필요하면 기존 DNSSEC 비활성화
  3. 네임서버를 Cloudflare로 변경
  4. 레코드 확인
  5. 안정화 뒤 Cloudflare에서 DNSSEC 활성화 후 DS 기록 반영

즉, DNSSEC은 나중에 켜도 되는 옵션이 아니라 제공자 이동 순서를 맞춰야 하는 항목입니다.

오늘 바로 확인할 것

  1. 내 도메인을 산 회사와 DNS를 관리하는 회사를 구분할 수 있는가
  2. 네임서버를 어디서 바꾸는지 알고 있는가
  3. 웹, 메일, 인증에 쓰는 레코드가 무엇인지 알고 있는가
  4. TTL 때문에 변경 반영이 지연될 수 있다는 점을 이해했는가
  5. Cloudflare를 쓴다면 proxied/DNS-only를 구분했는가
  6. DNS 제공자를 옮길 계획이라면 DNSSEC 순서를 알고 있는가

한 줄 결론

도메인 연결에서 가장 큰 실수는 기술이 어려워서가 아니라, 누가 무엇을 관리하는지를 섞어 보기 때문에 생깁니다.
등록기관, 네임서버, 레코드, TTL, DNSSEC만 분리해서 봐도 대부분의 초반 사고를 줄일 수 있습니다.

이어 읽기

출처