모두
모두콘텐츠
얼마 전 서버 이전을 도와달라는 연락을 받았는데, 새 서버는 멀쩡했고 도메인 설정 때문에 사이트가 열리지 않았다. 웹 접속은 끊겼고 메일까지 한동안 도착하지 않았다. 14년 동안 비슷한 일을 여러 번 봤다. 도메인은 구입보다 그 뒤의 관리가 훨씬 중요하다.
도메인은 첫해 가격보다 갱신 조건을 본다
도메인을 고를 때 등록 첫해 가격만 비교하면 비용을 잘못 계산하기 쉽다. 첫해에 1만 원, 다음 해부터 3만 원인 상품과 매년 2만 원인 상품이라면 3년 총액은 각각 7만 원과 6만 원이다. 숫자는 예시지만 비교 방식은 같다. 갱신 가격, 이전 비용, 개인정보 보호 기능의 추가 요금까지 같은 기간으로 맞춰 봐야 한다.
짧고 기억하기 쉬운 이름이 좋지만, 철자를 말로 전달했을 때 자꾸 되물어야 한다면 운영에는 불리하다. 사업용이라면 개인 계정보다 조직이 계속 관리할 수 있는 계정으로 등록하는 편이 낫다. 담당자가 퇴사한 뒤 개인 메일로만 갱신 알림이 가는 사고가 생각보다 흔하다.
등록자 정보와 결제 수단도 확인한다. 자동 갱신을 켜 두더라도 카드 만료로 결제가 실패할 수 있다. 만료일 알림은 담당자 한 사람에게만 맡기지 말고 두 곳 이상에서 받도록 하고, 만료일 30일 전에는 실제 결제 수단이 유효한지 확인한다. 만료 후 복구 가능 기간과 비용은 도메인 종류와 등록 업체에 따라 달라진다. 만료일을 넘겨도 괜찮을 거라고 가정하면 안 된다.
DNS를 바꾸기 전에 현재 설정을 남긴다
도메인을 등록한 업체, DNS를 관리하는 업체, 서버를 운영하는 업체는 서로 다를 수 있다. 먼저 어느 계정에서 네임서버를 지정하고 어느 화면에서 DNS 레코드를 수정하는지 찾아야 한다. 이 두 화면을 혼동하면 레코드를 바꿨다고 생각해도 실제 접속에는 아무 변화가 없다.
변경 전에는 A와 AAAA, CNAME, MX, TXT 레코드의 이름과 값, TTL을 파일로 남긴다. 화면 캡처만으로는 긴 TXT 값을 다시 입력할 때 오타가 나기 쉽다. 특히 MX는 메일 수신 경로이고, SPF·DKIM·DMARC에 쓰이는 TXT 값은 메일 인증에 영향을 준다. 웹사이트만 이전한다고 메일 설정을 지워서는 안 된다.
TTL은 DNS 응답을 얼마나 오래 보관할지 나타내는 값이다. 예를 들어 현재 TTL이 3600초라면 변경 직전에 300초로 낮춰도 이미 받아 간 응답이 즉시 사라지지는 않는다. 이전 하루쯤 전에 TTL을 낮추고, 기존 값이 지나갈 시간을 확보하는 편이 안전하다. 그래도 모든 이용자가 정확히 5분 뒤 새 서버로 오는 것은 아니다. 통신사나 이용자 환경에 따라 오래된 응답이 남을 수 있다.
DNSSEC를 사용 중이라면 네임서버 교체 전에 DS 정보도 확인한다. 새 DNS의 서명과 등록 업체에 남은 DS 정보가 맞지 않으면 일부 환경에서는 도메인 조회 자체가 실패한다. 네임서버만 바꾸고 끝내기 쉬운 지점이라 작업표에 별도로 적어 둔다.
서버 이전은 도메인 변경보다 먼저 준비한다
새 서버를 띄운 뒤 바로 도메인을 돌리는 방식은 장애가 나면 원인을 찾기 어렵다. 먼저 사이트 파일과 데이터베이스를 옮기고, 새 서버에서 웹페이지·로그인·파일 업로드·관리자 화면을 확인한다. 인증서 발급과 갱신 방식도 이때 점검한다. 접속만 된다고 끝난 게 아니다. 문의 양식이나 결제 알림처럼 뒤에서 동작하는 기능까지 시험해야 한다.
백업은 이전 직전에 한 번 더 만든다. 파일과 데이터베이스를 따로 보관하고, 복원에 필요한 계정 정보와 설정값도 빠뜨리지 않는다. 백업 파일이 있다는 것과 복원할 수 있다는 것은 다르다. 가능하면 테스트 환경에서 실제로 복원해 보고, 어렵다면 최소한 압축 파일이 열리고 데이터베이스 내용을 읽을 수 있는지 확인한다.
새 서버 검증이 끝난 다음 DNS를 변경한다. 이때 기존 서버를 즉시 끄지 않는다. 이전 기간에는 일부 이용자가 기존 서버로 들어올 수 있다. 게시글, 주문, 문의처럼 데이터가 계속 쌓이는 사이트라면 두 서버에 쓰기가 갈라질 위험이 있다. 작업 시간을 공지하고 잠시 쓰기 기능을 멈추거나, 데이터 동기화 절차를 마련해야 한다. 단순한 회사 소개 사이트와 쇼핑몰의 이전 난도가 다른 이유다.
등록 업체 자체를 옮기는 작업은 서버 이전과 분리하는 편이 관리하기 쉽다. ICANN의 이전 정책에는 신규 등록이나 이전 직후 일정 기간의 이전 제한, 등록자 변경에 따른 잠금 규정이 있다. 적용 여부는 도메인 종류와 상태에 따라 확인해야 한다. 서버가 급하게 바뀌어야 할 때 등록 업체 이전까지 한꺼번에 진행할 이유는 거의 없다.
접속 장애가 나면 확인 순서를 고정한다
사이트가 열리지 않으면 서버부터 재시작하는 경우가 많다. 나는 먼저 도메인 만료 여부와 네임서버 설정을 보고, 그다음 DNS 응답이 새 서버 주소를 가리키는지 확인한다. 여기까지 정상이라면 서버의 웹 서비스, 방화벽, 인증서, 애플리케이션 로그 순서로 본다. 접속 불가라는 증상 하나만으로 원인을 단정하면 시간을 잃는다.
- 도메인 조회가 안 된다면 만료 상태, 네임서버, DNSSEC 설정을 확인한다.
- 다른 서버 화면이 뜬다면 A·AAAA 레코드와 기존 서버 잔존 여부를 확인한다.
- 웹은 되는데 메일이 끊겼다면 MX와 메일 인증용 TXT 값을 확인한다.
- 보안 경고가 뜬다면 인증서 대상 이름과 유효 기간, 새 서버의 인증서 설정을 확인한다.
장애 때 가장 도움이 되는 것은 화려한 관리 도구보다 변경 기록이다. 누가 언제 어떤 값을 바꿨는지 남아 있으면 이전 값으로 되돌릴지, 더 기다릴지 판단할 수 있다. 도메인 비용은 서버 비용에 비하면 작지만, 설정 한 줄이 웹과 메일을 함께 멈출 수 있다. 그래서 나는 새 도메인을 살 때도 가격표보다 관리 계정, 갱신일, DNS 백업부터 챙긴다.
