얼마 전 오래된 쇼핑몰 이전을 도와줬는데, 서버보다 도메인 쪽에서 시간이 더 걸렸습니다. 웹서버는 백업 떠서 새 장비에 올리면 됐는데, 도메인 소유자 메일이 퇴사자 계정으로 되어 있고 만료 알림도 아무도 못 받고 있었습니다. 이런 일이 생각보다 많습니다. 사이트 운영에서 도메인은 작아 보이지만, 한 번 꼬이면 접속 장애와 메일 장애가 같이 납니다.
도메인을 살 때 많은 분들이 이름 예쁜지, 가격이 싼지만 봅니다. 물론 중요합니다. 그런데 운영자 입장에서는 그보다 먼저 봐야 할 게 있습니다. 소유권, 만료 관리, 네임서버, DNS 레코드 변경 속도, 이전 잠금 정책입니다. 트래픽이 많든 적든 도메인 설정 하나 잘못 건드리면 모든 접속이 멈춥니다.
도메인은 이름이 아니라 운영 권한입니다
도메인은 사이트 주소 역할을 하지만, 실무에서는 권한 관리 항목에 가깝습니다. 서버가 바뀌어도 도메인이 제대로 연결되어 있으면 사용자는 같은 이름으로 들어옵니다. 반대로 서버가 멀쩡해도 도메인 만료나 DNS 오류가 나면 사이트는 죽은 것처럼 보입니다.
처음 등록할 때는 반드시 실제 운영 주체 명의로 잡아야 합니다. 개인 블로그면 본인 계정이면 충분합니다. 회사 사이트라면 대표 개인 메일보다 회사가 관리하는 공용 계정이 낫습니다. 제작사나 외주 개발자 계정으로 등록해두면 나중에 이전할 때 권한 확인부터 막힙니다.
- 등록자 메일은 실제로 받을 수 있는 계정이어야 합니다.
- 도메인 등록 계정에는 2단계 인증을 켜는 편이 안전합니다.
- 자동 연장을 켜도 카드 만료와 결제 실패 알림을 따로 확인해야 합니다.
- 회사 도메인은 담당자 퇴사 시 인수인계 목록에 반드시 넣어야 합니다.
도메인 만료 사고는 고급 서버에서만 나는 일이 아닙니다. 오히려 작은 회사, 개인몰, 오래된 홈페이지에서 더 자주 봅니다. 월 서버비 몇 만 원 아끼는 것보다 도메인 만료 한 번이 훨씬 비쌉니다.
처음 고를 때는 짧고 헷갈리지 않는 이름이 낫습니다
도메인 이름은 짧을수록 좋지만, 무조건 짧은 게 답은 아닙니다. 전화로 불러줬을 때 한 번에 알아듣는지가 더 중요합니다. 숫자, 하이픈, 비슷한 발음이 섞이면 문의 응대에서 계속 문제가 생깁니다. 광고를 돌리거나 오프라인 명함에 넣을 계획이 있으면 이 차이가 큽니다.
개인 블로그나 작은 서비스라면 브랜드명과 주제가 같이 떠오르는 이름이 편합니다. 너무 넓은 단어를 잡으면 나중에 방향을 바꿀 때는 좋지만, 초반 검색 유입에는 애매할 수 있습니다. 반대로 너무 좁은 키워드로 만들면 사업 범위를 넓힐 때 이름이 발목을 잡습니다.
피하는 게 나은 패턴
- 영문 철자가 여러 방식으로 들리는 이름
- 숫자 0과 알파벳 O처럼 혼동되는 조합
- 의미 없는 하이픈이 들어간 이름
- 유명 브랜드와 너무 비슷한 이름
- 해마다 바뀌는 유행어가 들어간 이름
상표 문제도 가볍게 보면 안 됩니다. 내가 먼저 도메인을 샀다고 해서 그 이름을 마음대로 쓸 수 있는 건 아닙니다. 특히 쇼핑몰, 교육, 금융, 병원, 지역 서비스는 비슷한 상호가 이미 있는지 먼저 확인하는 게 좋습니다. 나중에 로고, 간판, 광고까지 만든 뒤 이름을 바꾸면 비용이 크게 늘어납니다.
가격 비교는 첫해보다 갱신 비용을 봐야 합니다
도메인 가격은 첫해만 싸게 보이는 경우가 많습니다. 등록 첫해는 이벤트가 붙고, 갱신부터 정상가가 적용됩니다. 운영 기간을 3년으로 잡으면 첫해 가격보다 갱신가가 더 중요합니다. 서버 요금제도 그렇지만 도메인도 월 단가처럼 환산해서 보는 편이 현실적입니다.
예를 들어 첫해가 3천 원이고 갱신이 3만 원인 도메인과, 첫해부터 매년 1만 5천 원인 도메인이 있다고 치면 3년 총액은 뒤쪽이 더 낮을 수 있습니다. 작은 금액처럼 보여도 도메인을 여러 개 운영하면 차이가 납니다. 브랜드 보호용으로 비슷한 이름을 여러 개 사는 회사는 특히 갱신비를 봐야 합니다.
개인 블로그나 테스트 서비스는 굳이 비싼 확장자를 고를 필요가 없습니다. 방문자가 직접 주소를 입력하는 비중이 낮고 검색 유입이 대부분이라면, 안정적인 관리업체와 적당한 가격이면 충분합니다. 다만 회사 대표 사이트, 결제 사이트, 이메일을 함께 쓰는 도메인은 너무 낯선 확장자보다 익숙한 쪽이 운영상 편합니다.
DNS 설정은 바꾸기 전에 현재 값을 백업해야 합니다
도메인 작업에서 가장 흔한 사고는 DNS 레코드를 덮어쓰는 겁니다. 홈페이지 이전만 하려다가 메일 수신이 끊기는 경우가 많습니다. 이유는 간단합니다. 웹 접속용 레코드와 메일용 레코드가 같은 DNS 화면에 같이 있기 때문입니다. 서버 업체 안내만 보고 전체 네임서버를 바꿨다가 기존 메일 설정이 날아가는 일이 자주 납니다.
변경 전에는 현재 DNS 값을 화면 캡처만 하지 말고 텍스트로 남기는 게 좋습니다. 이름, 종류, 값, 우선순위, TTL을 같이 적어둬야 복구가 됩니다. 특히 메일을 쓰고 있다면 MX, SPF, DKIM, DMARC 값은 따로 확인해야 합니다. 이 네 가지가 틀어지면 메일이 안 가거나 스팸함으로 빠집니다.
도메인 이전 전 확인 순서
- 현재 등록업체 계정에 로그인 가능한지 확인합니다.
- 등록자 메일을 받을 수 있는지 확인합니다.
- 도메인 잠금 상태와 인증 코드를 확인합니다.
- DNS 레코드 전체를 백업합니다.
- 메일 서비스 사용 여부를 먼저 확인합니다.
- 변경 작업은 방문자 적은 시간대에 진행합니다.
TTL은 DNS 변경이 퍼지는 시간과 관련이 있습니다. 평소에는 길게 둬도 되지만, 서버 이전을 앞두고 있다면 하루나 이틀 전에 짧게 낮춰두면 전환이 부드럽습니다. 단, 이미 이전 당일이 되어서 낮추면 큰 의미가 없습니다. DNS는 미리 준비한 만큼 사고가 줄어듭니다.
작은 사이트일수록 도메인 관리표 하나가 더 중요합니다
트래픽이 하루 수백 명인 사이트는 서버 사양보다 관리 누락이 더 큰 위험입니다. 1코어 VPS나 저가 웹호스팅으로도 충분한데, 도메인 만료일을 아무도 모르면 사이트는 그대로 멈춥니다. SSL 인증서 자동 갱신도 도메인 검증이 막히면 실패합니다. 그러면 브라우저에서 보안 경고가 뜨고, 사용자는 사이트가 망가졌다고 생각합니다.
운영 중인 도메인이 2개 이상이면 간단한 관리표를 두는 게 좋습니다. 도메인 이름 자체를 본문에 적을 필요는 없고, 내부 문서에는 등록업체, 만료일, 자동 연장 여부, 결제 카드, 네임서버 위치, 연결 서버, 메일 사용 여부 정도만 기록하면 됩니다. 장애 때 이 표가 있으면 확인 시간이 확 줄어듭니다.
제가 현장에서 보는 도메인 사고는 대부분 기술 난도가 높아서 생기지 않았습니다. 만료 알림을 못 봤고, 퇴사자 계정에 권한이 있었고, DNS 백업 없이 네임서버를 바꿨고, 메일 레코드를 모르고 지웠습니다. 그래서 도메인은 싸게 사는 것도 좋지만, 누가 어떻게 관리하는지까지 정해두는 게 더 중요합니다. 서버는 새로 만들 수 있지만, 운영 중인 이름의 신뢰는 한 번 끊기면 회복하는 데 시간이 꽤 걸립니다.
