모두
모두콘텐츠
얼마 전 서버는 멀쩡한데 사이트와 메일이 함께 끊긴 곳을 봤습니다. 도메인 갱신 알림이 퇴사자 메일로 가고 있었고, 등록 기간이 끝난 뒤에야 문제를 알았습니다. 서버를 몇 대로 늘려도 도메인 관리가 비어 있으면 접속 경로 하나가 통째로 사라집니다.
도메인을 살 때 먼저 확인할 것
도메인 비용은 첫해 등록비보다 다음 해 갱신비가 중요합니다. 첫해 1만 원, 갱신은 3만 원인 상품이라면 3년 비용은 7만 원입니다. 첫해 2만 원, 갱신도 2만 원인 상품은 같은 기간 6만 원입니다. 할인 문구만 보고 고르면 두 번째 청구서에서 차이가 납니다. 이전 수수료와 개인정보 보호 기능의 별도 요금도 함께 확인해야 합니다.
도메인은 회사나 사업자가 직접 관리할 수 있는 계정에 등록하는 편이 안전합니다. 제작사 직원이나 외주 개발자 개인 계정에 넣으면 계약이 끝난 뒤 이전 절차가 복잡해질 수 있습니다. 등록자 정보와 갱신 알림을 받는 메일은 실제 담당자가 접근할 수 있어야 합니다. 그 메일 자체가 해당 도메인으로만 운영된다면 만료나 DNS 장애 때 알림을 못 받을 수도 있으니, 별도의 연락 수단도 남겨둡니다.
자동 갱신을 켰다고 끝난 건 아닙니다. 결제 카드가 만료되거나 결제가 실패할 수 있습니다. 저는 만료일을 운영 일정에도 넣고, 60일 전과 30일 전에 결제 수단과 알림 수신 상태를 확인합니다. 계정에는 다중 인증을 걸고 복구 코드의 보관 담당자를 정합니다. 도메인 이전을 막는 잠금 기능이 있다면 평소에는 켜두는 편이 낫습니다.
DNS 기록은 서버 설정과 함께 보관한다
도메인을 등록한 회사, DNS를 운영하는 곳, 웹서버를 운영하는 곳은 서로 다를 수 있습니다. 이 세 곳을 한 업체로 맞출 필요는 없습니다. 대신 어느 계정에서 네임서버를 바꾸고, 어느 화면에서 DNS 기록을 수정하는지 알아야 합니다. 장애가 난 뒤 로그인 계정을 찾기 시작하면 복구 시간이 길어집니다.
DNS 기록을 바꾸기 전에는 현재 값을 저장합니다. 웹 접속에 쓰는 A·AAAA·CNAME 기록뿐 아니라 메일 수신용 MX, 발신 인증에 쓰는 TXT 기록도 대상입니다. 웹서버를 옮기면서 메일 기록을 빠뜨리면 사이트는 열리는데 메일만 끊기는 일이 생깁니다. DNSSEC를 사용 중이라면 네임서버 변경 때 관련 설정도 함께 확인해야 합니다. 맞지 않는 설정이 남으면 일부 이용자에게 도메인이 조회되지 않을 수 있습니다.
기록 목록에는 값만 적지 말고 용도를 붙여둡니다. 예를 들어 ‘웹 접속’, ‘업무 메일 수신’, ‘메일 발신 인증’, ‘외부 서비스 소유 확인’처럼 써두면 오래된 TXT 기록을 지울 때 판단하기 쉽습니다. 담당자, 변경 날짜, 이전 값까지 남기면 잘못 바꾼 뒤 되돌리는 시간도 줄어듭니다. 방문자가 하루 100명이든 10만 명이든 이 작업은 필요합니다. 트래픽보다 설정 누락이 먼저 장애를 만드는 경우가 많습니다.
서버를 옮길 때는 접속 경로를 따로 시험한다
도메인을 새 서버로 연결하는 작업은 DNS 값 한 줄을 바꾸는 것으로 보이지만, 실제로는 사이트 파일, 데이터베이스, 인증서, 메일, 예약 작업이 함께 움직입니다. 먼저 새 서버에서 사이트와 관리 화면을 시험하고, 데이터베이스에 글이나 주문이 정상 저장되는지 확인합니다. 인증서도 새 서버에서 정상적으로 제공되는지 봅니다. 화면 첫 페이지만 열어보고 이전을 끝냈다고 판단하면 로그인이나 결제 단계에서 문제가 드러날 수 있습니다.
기존 DNS 기록의 TTL이 3600초라면 변경 직전에 300초로 낮춰도 기존 값을 받아간 캐시에는 최대 3600초 동안 이전 설정이 남을 수 있습니다. 그래서 저는 적어도 기존 TTL만큼 여유를 두고 낮춘 뒤 새 서버 주소로 바꿉니다. TTL은 캐시가 값을 보관하는 기준이지, 모든 방문자가 정확히 그 시간에 동시에 새 서버로 이동한다는 보장은 아닙니다. 기존 서버를 곧바로 끄지 않는 이유입니다.
이전 직전에는 파일과 데이터베이스를 백업하고, 실제 복원 가능한지도 확인합니다. 백업 파일이 있다는 사실과 복원이 된다는 사실은 다릅니다. 게시글이나 주문이 계속 들어오는 사이트라면 이전 중 데이터가 양쪽 서버에 나뉘지 않도록 쓰기 중지 시간이나 데이터 동기화 방법을 먼저 정해야 합니다. DNS만 되돌린다고 새 서버에 저장된 주문이 옛 서버로 옮겨지는 것은 아닙니다.
- 변경 전: DNS 전체 기록, 서버 설정, 데이터베이스 백업을 확보한다.
- 변경 중: 웹 접속, 로그인, 글쓰기나 주문, 메일 송수신을 각각 시험한다.
- 변경 후: 접속 기록과 오류 기록을 살피고, 이전 서버를 일정 기간 유지한다.
접속이 안 될 때 확인하는 순서
사이트가 안 열린다는 신고가 오면 서버부터 재시작하고 싶어집니다. 그런데 먼저 범위를 나눠야 합니다. 특정 사람에게만 안 열리는지, 웹만 안 되는지, 메일까지 함께 안 되는지 확인합니다. 웹과 메일이 모두 끊겼다면 도메인 만료, 네임서버, DNS 조회 상태를 먼저 봅니다. 웹만 안 된다면 웹용 DNS 기록, 인증서, 서버 응답과 최근 배포 내역을 차례로 확인합니다.
도메인 조회가 정상이고 새 서버 주소도 맞는데 옛 화면이 보인다면 캐시나 이전 서버 접속 가능성을 확인합니다. 인증서 경고가 뜬다면 도메인이 새 서버를 가리키는지와 새 서버의 인증서 설정을 함께 봐야 합니다. 여기서 임의로 DNS 값을 여러 번 바꾸면 이용자마다 서로 다른 설정을 보게 되어 원인 파악이 더 어려워집니다. 변경 시각과 변경값을 기록하고 한 단계씩 검증하는 편이 빠릅니다.
도메인 운영에 비싼 요금제가 필요한 경우는 드뭅니다. 먼저 필요한 것은 갱신 책임자, 접근 가능한 계정, DNS 기록 사본, 복원 가능한 백업입니다. 이 네 가지가 갖춰져 있으면 서버를 더 좋은 상품으로 옮길 때도 훨씬 덜 불안합니다.
