얼마 전 작은 쇼핑몰 이전 작업을 봤는데, 서버는 멀쩡한데 도메인 설정 하나 때문에 반나절을 날렸습니다. 운영자는 호스팅을 바꾸면 자동으로 접속될 줄 알았고, 제작사는 네임서버만 바꾸면 끝난다고 생각했죠. 그런데 실제 장애는 그 사이에서 납니다. 도메인은 눈에 안 보이지만, 사용자가 사이트에 들어오는 첫 관문입니다.
14년 정도 웹서버와 호스팅 인프라를 만지다 보니 도메인 문제는 늘 비슷한 모양으로 터졌습니다. 만료일을 놓치거나, DNS 레코드를 잘못 넣거나, 이전 전에 TTL을 줄이지 않거나, SSL 인증서 발급 조건을 확인하지 않는 식입니다. 트래픽이 많아서 죽는 사이트보다 이런 기본 설정 때문에 안 열리는 사이트가 훨씬 많습니다.
도메인은 주소가 아니라 연결 규칙입니다
도메인을 산다는 건 서버를 사는 게 아닙니다. 사람들이 외우기 쉬운 이름을 등록하고, 그 이름이 어느 서버를 바라볼지 규칙을 적어두는 일에 가깝습니다. 실제 웹사이트 파일은 웹호스팅, VPS, 클라우드 서버 어딘가에 있고 도메인은 그 위치를 찾아가게 해줍니다.
기본 구조는 단순합니다. 도메인 등록기관에서 이름을 등록하고, 네임서버가 DNS 정보를 들고 있으며, 그 안에 A 레코드나 CNAME 같은 값이 들어갑니다. 사용자가 브라우저에 주소를 입력하면 DNS 조회가 먼저 일어나고, 그 결과로 나온 서버 IP로 접속합니다. 이 과정이 몇 초 안에 지나가니 평소에는 신경을 안 쓰지만, 이전이나 장애 때는 제일 먼저 확인해야 합니다.
- A 레코드: 도메인을 특정 IPv4 주소로 연결합니다.
- AAAA 레코드: IPv6 주소로 연결할 때 씁니다.
- CNAME: 다른 이름을 별칭처럼 바라보게 합니다.
- MX: 메일 서버를 지정합니다.
- TXT: 소유권 확인, 메일 인증, 보안 정책에 자주 씁니다.
초보자가 많이 헷갈리는 부분은 네임서버 변경과 DNS 레코드 변경입니다. 네임서버 변경은 DNS 장부를 들고 있는 곳 자체를 바꾸는 일이고, 레코드 변경은 기존 장부 안의 항목을 고치는 일입니다. 사이트만 다른 서버로 옮기는 상황이라면 네임서버까지 바꿀 필요가 없는 경우도 많습니다.
처음 도메인을 고를 때 보는 기준
도메인은 짧고 읽기 쉬운 게 좋습니다. 그런데 무조건 짧은 이름만 찾다 보면 이상한 철자, 하이픈, 숫자를 억지로 넣게 됩니다. 운영해보면 그런 이름은 전화로 불러주기도 어렵고, 고객이 잘못 입력하는 일도 많습니다. 브랜드 이름이 분명하다면 브랜드를 우선하고, 업종 키워드는 너무 욕심내지 않는 편이 낫습니다.
확장자는 운영 목적에 맞게 고르면 됩니다. 국내 사업자라면 국내 사용자에게 익숙한 확장자가 편하고, 기술 서비스나 글로벌 서비스를 생각한다면 국제적으로 익숙한 확장자가 무난합니다. 특이한 확장자는 당장 보기엔 재미있지만 메일 신뢰도, 사용자 인식, 일부 보안 장비의 필터링에서 손해를 볼 수 있습니다.
가격도 첫해 등록비만 보면 안 됩니다. 일부 도메인은 첫해는 싸고 갱신비가 확 올라갑니다. 실제 비용은 최소 3년 기준으로 봐야 합니다. 도메인 하나가 연 1만 원대인지, 3만 원대인지, 10만 원 이상인지에 따라 여러 개를 운영할 때 차이가 꽤 납니다. 보호 기능, 기관 이전 수수료, 개인정보 보호 제공 여부도 같이 확인해야 합니다.
사기 쉬운 이름보다 오래 쓸 이름이 낫습니다
도메인은 나중에 바꾸기 번거롭습니다. 검색 노출, 메일 주소, 명함, 광고 소재, 고객 안내 문구가 전부 엮입니다. 서버는 옮기면 되지만 도메인 변경은 외부에 퍼진 이름을 다시 회수하는 작업이라 비용이 더 큽니다. 그래서 처음부터 2~3년은 버틸 이름인지 보는 게 좋습니다.
호스팅에 도메인 연결하는 방법
웹호스팅을 쓴다면 보통 관리 화면에서 도메인 추가 메뉴가 있습니다. 거기에 보유 도메인을 등록하고, 도메인의 DNS에서 A 레코드를 호스팅 서버 IP로 지정합니다. 업체에 따라 CNAME을 요구하는 경우도 있습니다. 이때 중요한 건 기존 메일 레코드를 건드리지 않는 겁니다. 사이트만 옮기려다가 MX 레코드를 지워서 회사 메일이 멈추는 사고가 꽤 자주 납니다.
VPS나 클라우드 서버라면 조금 더 직접 봐야 합니다. 서버에 웹서버가 떠 있어야 하고, 가상 호스트 설정에서 해당 도메인을 받아야 합니다. Nginx라면 server_name, Apache라면 ServerName과 ServerAlias가 맞아야 합니다. DNS가 서버 IP를 잘 가리켜도 웹서버 설정이 빠져 있으면 기본 페이지가 뜨거나 404가 나옵니다.
- 도메인 등록기관에서 만료일과 잠금 상태를 확인합니다.
- 현재 네임서버가 어디인지 확인합니다.
- 웹서버 또는 호스팅 패널에 도메인을 먼저 추가합니다.
- A 레코드나 CNAME을 새 서버 기준으로 변경합니다.
- SSL 인증서를 발급하고 강제 이동 설정을 적용합니다.
- 메일을 쓰고 있다면 MX, SPF, DKIM, DMARC 값을 보존합니다.
DNS 변경 후 바로 안 열린다고 설정을 계속 만지는 분들이 있습니다. 이러면 원인 추적이 더 어려워집니다. TTL이 3600초라면 길게는 한 시간 정도 예전 값이 남아 있을 수 있습니다. 이전 작업 전날 TTL을 300초 정도로 줄여두면 전환 시간이 훨씬 예측 가능해집니다. 단, 작업이 끝난 뒤에는 너무 짧은 TTL을 계속 유지할 필요는 없습니다.
이전할 때 사고를 줄이는 순서
도메인 이전과 서버 이전은 분리해서 생각해야 합니다. 도메인 기관 이전은 등록업체를 바꾸는 일이고, 서버 이전은 실제 사이트 파일과 데이터베이스 위치를 바꾸는 일입니다. 둘을 같은 날 동시에 하면 문제가 생겼을 때 어디가 원인인지 찾기 어렵습니다.
제가 현장에서 쓰는 순서는 단순합니다. 먼저 새 서버에 사이트를 올리고 임시 주소나 hosts 파일로 접속 테스트를 합니다. 관리자 로그인, 주문, 게시글 작성, 파일 업로드, 메일 발송까지 확인합니다. 그다음 기존 서버의 데이터를 최종 백업하고, 짧은 점검 시간에 데이터베이스를 한 번 더 옮깁니다. 마지막에 DNS를 새 서버로 바꿉니다.
작은 블로그나 회사 소개 사이트는 1GB 메모리 VPS나 저가 웹호스팅으로도 충분한 경우가 많습니다. 하루 방문자 1천 명 이하, 동시 접속 10명 안팎, 이미지 최적화가 된 사이트라면 비싼 클라우드 구성이 먼저 필요하지 않습니다. 반대로 쇼핑몰처럼 주문과 결제가 걸린 서비스는 사양보다 백업, 복구 시간, 장애 알림이 더 중요합니다. 싼 서버를 쓰더라도 매일 백업과 복구 테스트가 있으면 꽤 안정적으로 운영됩니다.
장애가 났을 때 확인하는 순서
사이트가 안 열린다는 연락을 받으면 서버부터 재부팅하는 경우가 있습니다. 급한 마음은 이해하지만 순서를 지키는 게 빠릅니다. 먼저 도메인 만료 여부를 확인합니다. 만료된 도메인은 서버가 아무리 멀쩡해도 접속이 안 됩니다. 그다음 DNS가 어떤 IP를 반환하는지 보고, 그 IP의 서버가 살아 있는지 확인합니다.
서버가 살아 있다면 웹서버 프로세스, 방화벽, SSL 인증서, 리다이렉트 설정을 봅니다. 인증서가 만료되면 브라우저가 접속을 막고, 리다이렉트가 꼬이면 무한 이동이 생깁니다. 특히 도메인 앞부분을 붙인 주소와 붙이지 않은 주소를 서로 강제로 보내는 설정을 동시에 넣으면 이런 일이 생깁니다.
- 도메인 만료일이 지나지 않았는지 확인합니다.
- 네임서버가 의도한 곳으로 설정되어 있는지 봅니다.
- DNS 레코드가 현재 서버 IP와 맞는지 확인합니다.
- 웹서버가 해당 도메인을 받도록 설정되어 있는지 봅니다.
- SSL 인증서의 대상 이름과 만료일을 확인합니다.
- 최근 변경한 리다이렉트, 보안 플러그인, CDN 설정을 되짚습니다.
도메인 관리는 화려한 기술은 아닙니다. 그런데 운영에서는 이런 기본값이 제일 오래 발목을 잡습니다. 좋은 서버를 쓰는 것도 중요하지만, 도메인 만료 알림을 두 군데 이상 걸어두고 DNS 변경 이력을 남기고 백업 복구 순서를 문서로 갖고 있는 쪽이 실제 장애에는 더 강합니다. 저는 서버 사양을 올리기 전에 이 부분부터 보는 편입니다. 비용도 덜 들고, 효과는 훨씬 확실합니다.
