도메인주소 고르고 서버에 연결하는 방법

얼마 전 서버 이전을 도와달라는 연락을 받았는데, 서버는 멀쩡했고 도메인주소가 예전 서버를 가리키고 있었습니다. 이런 일은 흔합니다. 도메인 등록, DNS 설정, 웹서버 운영을 한 업체에서 처리하면 평소에는 편하지만, 장애가 나면 어디부터 확인해야 할지 헷갈리기 쉽습니다. 도메인주소를 고를 때부터 각 역할을 구분해 두면 이전도 복구도 수월해집니다.

이름보다 먼저 갱신 비용과 관리 권한을 본다

도메인주소는 짧고 읽기 쉬운 쪽이 좋습니다. 전화로 불러줘도 철자를 여러 번 설명하지 않아야 하고, 숫자나 비슷하게 보이는 문자는 가급적 피합니다. 상호를 쓴다면 나중에 이름이 바뀌어도 계속 쓸 수 있을지도 생각해 볼 만합니다. 이미 쓰는 상표와 지나치게 비슷한 이름은 운영상 분쟁거리가 될 수 있습니다.

등록 화면의 첫해 가격만 보고 고르면 곤란합니다. 첫해 할인과 다음 해 갱신 가격이 다를 수 있고, 이전 비용이나 개인정보 보호 기능의 조건도 등록 업체마다 다릅니다. 방문자가 하루 100명이든 10만 명이든 도메인 등록비가 트래픽에 비례해 오르는 구조는 아닙니다. 작은 사이트라면 비싼 확장자를 고르는 것보다 익숙하고 갱신 부담이 적은 이름을 유지하는 편이 실용적입니다.

더 중요한 것은 등록자와 계정의 소유권입니다. 제작 업체가 자기 계정으로 도메인을 등록하면 업체를 바꿀 때 이전 절차가 꼬일 수 있습니다. 등록자 정보와 연락 가능한 이메일을 직접 관리하고, 계정에는 2단계 인증을 켜 둡니다. 자동 갱신을 설정했더라도 결제 카드 만료와 알림 이메일 수신 여부는 따로 확인해야 합니다. ICANN도 만료 전 갱신 알림을 안내하지만, 알림 하나에 운영을 맡겨 두지는 않습니다.

도메인과 서버가 연결되는 경로를 구분한다

도메인 등록 업체는 이름을 등록하고 갱신하는 곳입니다. 네임서버는 그 이름의 DNS 정보를 어디서 찾을지 알려줍니다. DNS의 A 레코드는 서버의 IPv4 주소를, AAAA 레코드는 IPv6 주소를 가리킵니다. 웹사이트가 열리지 않는다고 해서 곧바로 서버 사양을 올릴 일이 아닌 이유입니다. 등록 상태와 네임서버, DNS 레코드, 서버 응답을 차례로 확인해야 원인을 좁힐 수 있습니다.

메일을 함께 쓴다면 MX와 TXT 레코드도 빠뜨리면 안 됩니다. 웹 접속은 정상인데 메일만 끊기는 경우는 이전하면서 웹용 레코드만 옮겼을 때 자주 생깁니다. TXT에는 메일 인증에 필요한 값이 들어갈 수 있습니다. 기존 DNS 화면의 레코드를 종류, 이름, 값, TTL까지 기록해 두면 새 DNS로 옮길 때 대조하기 쉽습니다. 화면 사진만 남기기보다 표로 적어 두는 편이 누락을 찾기 편했습니다.

호스팅 업체가 제공하는 무료 하위 주소로 시작해도 되는 사이트가 있습니다. 시험용 페이지나 짧게 운영할 프로젝트라면 충분합니다. 다만 독립 도메인주소를 쓰면 호스팅을 바꿀 때 방문자에게 알린 주소를 유지하기 쉽습니다. 비용을 줄이려면 서버 요금제부터 키우기보다 실제로 독립 주소가 필요한지, 메일을 직접 운영할지부터 결정하는 편이 맞습니다.

서버 이전은 DNS를 바꾸기 전에 준비한다

이전할 때는 새 서버에 파일과 데이터베이스를 복원하고, 기존 주소로 접속했을 때와 같은 화면이 나오는지 먼저 확인합니다. 로그인, 게시글 작성, 이미지 표시처럼 데이터가 오가는 기능까지 점검해야 합니다. 새 서버에 SSL 인증서를 준비하는 절차도 확인합니다. 인증서 발급 방식에 따라 도메인 확인이 필요하므로 DNS를 바꾸는 시각에 처음 신청하면 접속 오류가 길어질 수 있습니다.

DNS 레코드에는 TTL이라는 캐시 유지 시간이 있습니다. 예를 들어 기존 A 레코드의 TTL이 3600초라면 일부 DNS 서버는 변경 전 값을 최대 그 시간 동안 사용할 수 있습니다. 이전 하루 전쯤 TTL을 300초로 낮추면 전환 시간을 줄이는 데 도움이 되지만, 이미 캐시된 기존 값의 시간이 즉시 짧아지는 것은 아닙니다. DNS 서비스가 허용하는 최소값과 기존 TTL을 보고 변경 시각을 잡습니다.

전환 직전에는 쓰기 작업을 잠시 멈추거나 양쪽 서버의 데이터 차이를 처리할 방법을 정해야 합니다. DNS가 바뀌는 동안 이용자마다 서로 다른 서버에 접속할 수 있기 때문입니다. 게시판이나 주문 데이터가 있는 사이트에서 이 단계를 건너뛰면 글이나 결제가 한쪽 서버에만 남습니다. 변경 후에는 새 서버의 접속 기록을 확인하고, 예전 서버도 곧바로 지우지 않습니다. 저는 기존 TTL과 실제 접속 기록을 보고 며칠 여유를 둡니다.

등록 업체 자체를 옮기는 작업은 서버 이전과 별개입니다. 등록 업체 이전에는 이전 승인 코드가 필요할 수 있고, 등록 시점이나 등록자 정보 변경 시점에 따라 이전 제한이 걸릴 수 있습니다. 서버 이전 당일에 등록 업체까지 함께 바꾸면 확인할 변수가 늘어납니다. 특별한 이유가 없다면 서버와 DNS 전환을 먼저 안정화한 뒤 등록 업체 이전 일정을 잡는 편이 관리하기 쉽습니다.

접속이 안 될 때는 순서대로 확인한다

장애 신고가 오면 먼저 도메인 만료 여부와 네임서버 설정을 확인합니다. 다음은 DNS가 현재 어느 서버 주소를 돌려주는지, 그 서버가 요청에 응답하는지 확인합니다. 특정 사람에게만 예전 화면이 보인다면 DNS 캐시나 브라우저 캐시를 의심할 수 있습니다. 모두에게 같은 오류가 보인다면 서버와 웹서버 설정을 우선 봅니다. 인증서 경고가 뜨면 서버가 살아 있어도 인증서의 대상 이름과 만료 상태를 따로 확인해야 합니다.

웹만 안 열리면 A·AAAA 레코드와 웹서버 응답을 확인한다.
메일만 안 오면 MX 레코드와 메일 서비스 상태를 확인한다.
일부 이용자만 예전 서버로 가면 기존 TTL과 접속 기록을 확인한다.
인증서 경고가 나면 대상 이름, 유효 기간, 새 서버의 인증서 설정을 확인한다.

도메인주소 운영에 큰 서버는 필요하지 않습니다. 등록 계정의 권한, 갱신 상태, DNS 기록, 복원 가능한 백업이 더 자주 문제를 가릅니다. 작은 사이트일수록 이 네 가지를 적어 두는 데 드는 시간이 비싼 요금제로 올리는 비용보다 값어치가 있었습니다.