도메인은 이름보다 운영 기준이 먼저입니다
얼마 전 작은 쇼핑몰 이전 작업을 봤는데, 서버보다 도메인 쪽에서 시간이 더 걸렸습니다. 웹서버 사양은 하루 만에 맞췄는데, 도메인 소유자 계정이 퇴사자 메일로 묶여 있었고 네임서버 변경 권한도 확인이 안 됐습니다. 사이트 장애는 트래픽 때문에만 생기지 않습니다. 실제 운영에서는 이런 계정, 만료일, DNS 설정 같은 기본값에서 꽤 자주 터집니다.
도메인은 간단히 말하면 사람이 기억하는 서비스 이름입니다. 서버 입장에서는 결국 IP로 찾아오지만, 사용자는 숫자 주소를 외우지 않습니다. 그래서 도메인 자체보다 중요한 건 그 도메인을 누가 관리하고, 어디에서 DNS를 운영하며, 장애 때 얼마나 빨리 바꿀 수 있느냐입니다.
처음 사이트를 만들 때는 이름이 예쁜지만 보는 경우가 많습니다. 그런데 운영자는 조금 다르게 봐야 합니다. 짧은가, 오타가 적은가, 연장 비용이 과하지 않은가, 소유권 이전이 쉬운가, DNS 레코드 관리 화면이 안정적인가. 이 다섯 가지가 더 현실적입니다.
도메인 선택할 때 보는 기준
개인 블로그나 작은 회사 소개 사이트라면 도메인 가격은 보통 1년에 몇 만 원 선에서 끝납니다. 여기서 굳이 비싼 확장자를 고를 필요는 없습니다. 브랜드가 이미 잡힌 회사라면 예외지만, 검색 유입 중심 블로그라면 확장자보다 콘텐츠 구조와 속도, SSL, 색인 상태가 더 큰 영향을 줍니다.
저는 도메인을 고를 때 먼저 발음과 입력 난이도를 봅니다. 전화로 불러줬을 때 한 번에 알아들을 수 있는 이름이 좋습니다. 하이픈이 여러 개 들어가거나, 숫자와 영문자가 섞여서 설명이 필요한 이름은 운영하면서 계속 피곤합니다. 특히 광고나 명함, 고객센터 안내에 들어갈 도메인이라면 더 그렇습니다.
- 가능하면 짧고 읽기 쉬운 이름을 고릅니다.
- 상표권과 비슷한 이름은 피합니다.
- 첫해 가격보다 2년 차 연장 비용을 봅니다.
- 소유자 이메일을 개인 퇴사자 계정으로 두지 않습니다.
- DNS 관리 기능이 너무 제한적인 등록처는 피하는 편이 낫습니다.
싼 등록처가 무조건 나쁜 건 아닙니다. 사실 도메인 자체는 표준화된 상품에 가깝습니다. 다만 관리 화면이 느리거나, 인증 메일이 잘 안 오거나, 네임서버 변경 반영 상태를 확인하기 어려운 곳이면 장애 대응 시간이 길어집니다. 연 5천 원 아끼려다가 이전 작업에서 몇 시간씩 쓰면 별로 남는 장사가 아닙니다.
DNS 설정은 최소한 이것만 알면 됩니다
도메인을 샀다고 바로 사이트가 열리는 건 아닙니다. DNS에 어떤 요청을 어디로 보낼지 적어줘야 합니다. 가장 기본은 A 레코드입니다. 도메인을 서버 IP로 연결합니다. VPS나 클라우드 서버를 직접 쓰면 이 값을 자주 만집니다.
CNAME은 별칭에 가깝습니다. 예를 들어 특정 하위 이름을 다른 서비스의 이름으로 넘길 때 씁니다. 메일을 쓴다면 MX 레코드가 필요하고, 스팸 위조를 줄이려면 SPF, DKIM, DMARC 같은 TXT 레코드도 보게 됩니다. 처음에는 낯설지만 구조는 단순합니다. 이름, 종류, 값, TTL. 이 네 칸만 제대로 보면 됩니다.
TTL은 캐시 시간입니다. 보통 300초, 600초, 3600초 같은 값으로 둡니다. 서버 이전 전에는 TTL을 300초 정도로 낮춰두면 전환이 빨라집니다. 그런데 이전 당일에 낮추면 이미 기존 값이 캐시에 남아 있을 수 있습니다. 최소 하루 전에는 낮춰두는 게 안전합니다. 큰 사이트라면 48시간 전에 조정하는 편이 더 낫습니다.
자주 쓰는 레코드
- A: 도메인을 IPv4 주소로 연결합니다.
- AAAA: 도메인을 IPv6 주소로 연결합니다.
- CNAME: 다른 이름을 따라가게 만드는 별칭입니다.
- MX: 메일 서버를 지정합니다.
- TXT: 인증, 보안, 소유권 확인에 자주 씁니다.
실수도 패턴이 있습니다. 루트 도메인과 하위 이름을 헷갈리거나, 기존 메일 레코드를 지우고 웹 연결만 맞추는 경우가 많습니다. 그러면 사이트는 열리는데 메일이 죽습니다. 반대로 웹서버 IP는 바꿨는데 CDN 쪽 캐시나 네임서버가 예전 값을 들고 있어서 일부 사용자만 접속 장애를 겪기도 합니다.
도메인 이전과 서버 이전은 순서를 나눠야 합니다
도메인 이전과 서버 이전을 같은 날 몰아서 하면 위험합니다. 둘은 다른 작업입니다. 도메인 이전은 등록처를 바꾸는 일이고, 서버 이전은 실제 웹 파일과 데이터베이스가 있는 위치를 바꾸는 일입니다. DNS 변경은 이 둘을 이어주는 작업입니다. 세 작업을 한 번에 하면 문제가 생겼을 때 원인을 좁히기 어렵습니다.
작은 워드프레스 사이트 기준으로 보면 안전한 순서는 이렇습니다. 먼저 새 서버에 파일과 데이터베이스를 복사합니다. 임시 접근 경로로 화면과 관리자 로그인을 확인합니다. 그다음 SSL 인증서 발급 조건을 맞춥니다. DNS A 레코드를 새 서버 IP로 바꿉니다. 접속 로그를 보면서 트래픽이 새 서버로 넘어오는지 확인하고, 최소 2~3일은 기존 서버를 끄지 않는 게 좋습니다.
- 이전 전: 전체 파일, 데이터베이스, 설정 파일을 백업합니다.
- 이전 중: TTL을 낮추고 새 서버에서 기능 테스트를 합니다.
- 전환 시점: DNS 값을 바꾸고 접속 로그와 오류 로그를 같이 봅니다.
- 전환 후: 메일, SSL, 관리자 로그인, 결제 모듈을 다시 확인합니다.
트래픽이 많지 않은 사이트도 이 절차는 필요합니다. 하루 방문자 300명짜리 블로그라도 검색 유입이 있는 글이 죽으면 손실이 생깁니다. 쇼핑몰이면 더 민감합니다. 결제 실패는 단순 접속 장애보다 발견이 늦습니다. 화면은 열리는데 특정 단계에서만 오류가 나는 경우가 많기 때문입니다.
만료와 소유권 관리가 진짜 운영입니다
도메인 장애 중 가장 허무한 게 만료입니다. 서버도 살아 있고 파일도 멀쩡한데 도메인이 만료돼서 사이트가 안 열립니다. 운영팀이 있는 회사도 이걸 겪습니다. 이유는 단순합니다. 등록 알림 메일이 예전 담당자에게 가거나, 자동 결제 카드가 만료되거나, 등록처 계정 비밀번호를 아무도 모르는 상태가 됩니다.
저는 도메인을 운영할 때 최소 두 명이 접근 가능한 공용 관리 체계를 권합니다. 그렇다고 아무에게나 권한을 주라는 뜻은 아닙니다. 소유자 계정, 결제 담당, 기술 담당을 구분하고, 2단계 인증과 복구 이메일을 조직 계정으로 잡아두는 방식이 낫습니다. 개인 블로그라도 최소한 복구 이메일과 휴대폰 번호는 최신 상태로 둬야 합니다.
도메인 잠금 기능도 확인해야 합니다. 평소에는 잠가두는 게 좋습니다. 무단 이전을 막아주기 때문입니다. 다만 실제 이전을 해야 할 때는 잠금을 풀고 인증 코드를 받아야 합니다. 이 절차를 모르면 급한 상황에서 등록처 고객센터 답변만 기다리게 됩니다.
제가 운영 전에 꼭 확인하는 항목
- 만료일과 자동 연장 상태
- 등록자 이메일과 복구 수단
- 네임서버가 어디를 보고 있는지
- 웹, 메일, 인증 관련 DNS 레코드 백업
- SSL 자동 갱신 여부
- 도메인 잠금과 이전 인증 코드 발급 가능 여부
도메인은 비싼 걸 산다고 운영이 좋아지지 않습니다. 오히려 평범한 도메인을 정확히 관리하는 쪽이 훨씬 안정적입니다. 방문자가 적은 사이트라면 무료 DNS나 저가 등록처로도 충분한 구간이 많습니다. 대신 계정 권한, 만료일, 레코드 백업, 이전 절차는 꼭 문서로 남겨야 합니다. 서버는 다시 만들 수 있어도, 도메인 소유권이 꼬이면 복구 시간이 길어집니다. 운영자는 이름보다 통제권을 먼저 봐야 합니다.
