사이트 이전은 새 주소를 준비하고 DNS 한 건을 바꾸는 작업으로 끝나지 않습니다. 도메인을 바꾸거나 HTTP에서 HTTPS로 이동하거나 URL 경로를 재구성하면 사용자가 방문하는 페이지, 검색엔진이 수집하는 주소, 인증서가 제시되는 호스트, 메일과 애플리케이션이 호출하는 주소가 동시에 달라질 수 있습니다. 눈에 보이는 홈페이지가 열려도 결제, 로그인, 문의 양식, 모바일 앱과 거래처 연동이 끊겼다면 이전은 성공한 것이 아닙니다. 시작할 때부터 비즈니스에 중요한 경로를 별도로 표시하고 각 경로에 확인 담당자를 지정해야 합니다.
변경 범위와 성공 기준부터 고정하기
먼저 기존 도메인, 새 도메인, 모든 하위 도메인, 주요 URL, 메일 주소, API 콜백과 외부에 전달된 링크를 목록으로 만드세요. URL에는 프로토콜, 호스트, 포트, 경로, 쿼리와 조각 식별자를 구분해 기록합니다. 무엇을 이전하지 않는지도 적어야 합니다. 예를 들어 고객센터는 그대로 두고 상품 페이지만 이동한다면 전체 도메인 이전처럼 처리하면 안 됩니다. 성공 기준은 단순한 200 응답이 아니라 핵심 URL이 의도한 최종 페이지에 도달하고, 인증서 이름이 맞고, 메일과 중요 트랜잭션이 정상적으로 완료되는 상태로 정의합니다.
Google 검색 센터는 URL 변경이 있는 사이트 이전에서 새 사이트를 충분히 준비하고 이전 주소와 새 주소의 매핑을 만든 다음 서버 측 리디렉션을 설정하도록 안내합니다. 이 순서를 지키면 전환 순간에 추측으로 규칙을 추가하는 일을 줄일 수 있습니다. 매핑표에는 이전 URL, 새 URL, 리디렉션 코드, 콘텐츠가 실제로 같은지, 담당자, 테스트 결과와 예외 사유를 넣으세요. 새 페이지가 없다는 이유로 모든 주소를 홈페이지로 보내면 사용자의 기대와 검색 신호를 잃을 수 있으므로 가장 가까운 관련 페이지를 지정하거나 적절한 상태를 반환해야 합니다.
DNS 위임과 레코드의 일관성 확인
DNS 점검은 한 번의 조회로 끝내지 말고 위임과 권한 응답을 나누어 확인해야 합니다. 먼저 부모 영역에서 반환되는 NS가 계획한 서버와 일치하는지 확인하고, 각 권한 서버에 SOA, A, AAAA, CNAME, MX, TXT와 CAA를 질의하세요. 서버마다 값이나 시리얼이 다르면 일부 사용자는 새 주소로 가고 일부는 이전 주소로 갈 수 있습니다. 공용 재귀 확인 결과도 함께 저장하되, 캐시된 응답과 권한 서버의 현재 응답을 같은 의미로 취급하지 마세요. NXDOMAIN, SERVFAIL, 빈 응답과 시간 초과는 각각 다른 원인을 가질 수 있습니다.
TTL은 변경이 보이는 시점을 추정하는 데 도움이 되지만 모든 사용자가 동시에 새 값을 본다는 약속은 아닙니다. 릴리스 전에는 기존 TTL과 실제 변경 시간을 기록하고, 릴리스 후에는 여러 시점과 위치에서 결과를 비교하세요. 특히 MX, 인증 토큰, API 검증용 TXT와 CAA를 잊기 쉽습니다. 새 이름 서버가 웹 주소만 제공하고 메일이나 검증 레코드를 빠뜨리면 방문자는 페이지를 보더라도 메일 발송과 계정 확인이 실패할 수 있습니다. 각 레코드에 업무 목적과 담당자를 붙이면 불필요한 삭제도 줄어듭니다.
리디렉션은 한 번에 최종 주소로 보내기
이전 URL에서 새 URL까지 리디렉션이 두 번, 세 번 이어지는 체인은 느리고 진단하기 어렵습니다. 가능한 경우 이전 주소에서 최종 주소로 한 번에 이동하게 하고, HTTP와 HTTPS, www와 비 www 변형을 각각 테스트하세요. 상태 코드만 보지 말고 Location 헤더, 최종 호스트, 경로 보존, 쿼리 처리와 응답 본문을 함께 기록합니다. 로그인이나 결제처럼 자동으로 따라가면 안 되는 경로는 일반 페이지와 같은 규칙으로 검사하지 말고 안전한 테스트 계정과 별도의 승인 절차를 사용하세요.
리디렉션 규칙은 대소문자, 마지막 슬래시, 인코딩된 문자, 오래된 확장자와 캠페인 파라미터에서 예상 밖의 결과를 만들 수 있습니다. 대표 URL만 테스트하지 말고 검색 유입이 많았던 주소, 광고가 사용하는 주소, 외부 파트너가 호출하는 주소, 존재하지 않는 주소를 표본으로 뽑으세요. 잘못된 도메인으로 이동하거나 리디렉션 루프가 생기면 즉시 중단 조건으로 분류합니다. 검사 결과에는 체인 길이와 unknown 상태를 남겨서 확인하지 못한 주소가 성공으로 집계되지 않도록 해야 합니다.
HTTPS와 콘텐츠 신호를 함께 검증하기
새 도메인의 인증서가 발급되었다는 사실만으로 모든 호스트가 안전하게 연결되는 것은 아닙니다. 루트 도메인, www, 로그인, 정적 파일, API와 상태 확인 주소에 실제로 제시되는 인증서를 확인하고 이름, 유효 기간, SAN과 인증서 체인을 기록하세요. 인증서가 맞아도 페이지가 이전 주소의 이미지나 스크립트를 불러오면 브라우저의 혼합 콘텐츠 경고가 발생할 수 있습니다. canonical, 사이트맵, hreflang과 내부 링크가 새 주소를 가리키는지도 같은 릴리스 체크리스트에 넣어야 합니다.
다국어 사이트라면 언어별 페이지와 alternate 관계를 별도로 점검하세요. 한국어 페이지는 새 주소로 바뀌었지만 영어 페이지의 hreflang이 이전 주소를 계속 가리키는 경우처럼 일부 언어만 남는 오류가 흔합니다. 페이지가 정상적으로 열리는지뿐 아니라 canonical과 사이트맵의 주소가 서로 일관되는지도 확인해야 합니다. 검색 결과의 일시적인 변동은 재수집 과정에서 나타날 수 있지만, 지속적인 404 증가나 잘못된 canonical은 정상적인 변동으로 넘기면 안 됩니다.
메일과 애플리케이션 경로를 별도 승인하기
웹 이전과 메일 이전은 서로 다른 변경입니다. MX 우선순위, SPF, DKIM 선택자, DMARC 정책과 메일 검증용 TXT를 새 도메인에서 확인하고 외부 주소로 수신, 발신, 회신, 전달, 반송을 시험하세요. 기존 레코드를 바로 지우지 말고 어떤 애플리케이션이 사용했는지 확인해야 합니다. 비밀번호 재설정, 영수증, 문의 접수처럼 실패를 늦게 발견하는 메일을 별도의 테스트 항목으로 두면 고객지원에서 먼저 문제를 발견하는 상황을 피할 수 있습니다.
웹훅, 결제 콜백, 모바일 앱 설정, CRM과 파트너 연동은 브라우저 탐색으로 드러나지 않습니다. 각 호출 주소의 인증, 허용된 호스트, 재시도와 응답 코드를 실제 샘플로 확인하고, 오류를 안전하게 재현할 수 있는 테스트 요청도 준비하세요. 새 주소가 열리는 것과 업무 이벤트가 한 번만 처리되는 것은 다른 성공 조건입니다. 이전 주소를 당장 폐기하지 말아야 하는 경로가 있다면 유지 기간과 종료 승인자를 명확히 기록하세요.
릴리스 후 관찰과 롤백 기준
전환 직후에는 이전 주소와 새 주소의 요청량, 3xx와 4xx, 5xx, DNS 오류, TLS 오류, 반송과 중요한 전환 지표를 비교하세요. 한 시간의 정상 응답만으로 완료를 선언하지 말고 업무 시간과 야간, 모바일과 외부 네트워크처럼 서로 다른 조건을 포함해야 합니다. 결과에는 관찰 시각, 검사 위치, 입력 URL, 최종 응답, 증거와 담당자를 남기세요. 검사 자체가 실행되지 않았거나 모든 결과가 unknown이 된 경우에는 정상으로 표시하지 말고 검증 시스템의 이상으로 분류합니다.
롤백은 DNS만 되돌리는 작업이 아닙니다. 리디렉션 규칙, 인증서, 사이트맵, 메일 레코드, 애플리케이션 환경 설정과 외부에 배포한 링크를 어떤 순서로 복구할지 문서화하세요. 롤백 조건에는 결제 실패율, 핵심 URL의 404, 인증서 불일치, 메일 반송 증가처럼 관찰 가능한 신호를 사용합니다. 누가 중단을 승인하고 누가 고객과 파트너에게 알릴지도 정해 두어야 합니다. 이전 상태의 스냅샷과 새 상태의 스냅샷을 비교하면 원인 분석이 빨라집니다.
여러 도메인이나 수천 개의 URL을 다룬다면 동일한 입력과 출력 형식으로 검사하세요. DomScan의 리디렉션 검사, DNS 조회, DNS 기록, SSL 검사와 도메인 프로필을 역할별로 사용하면 한 화면의 점수에 의존하지 않고 증거를 분리할 수 있습니다. 배치 결과에는 성공, 실패, 부분 결과와 unknown을 모두 보존하고, 재시도나 캐시로 인해 확인 시점이 달라졌다면 그 사실도 기록하세요. 자동화는 누락을 찾고 검토 대상을 정리하는 도구이며, 매핑의 의미와 고객 영향에 대한 최종 판단을 대신하지 않습니다.
마지막 승인 때는 위임 DNS와 핵심 레코드가 계획과 맞는지, 주요 URL이 직접 최종 페이지에 도달하는지, HTTPS 이름과 체인이 올바른지, 메일과 API가 실제로 완료되는지 확인하세요. unknown 항목에는 소유자와 다음 확인 날짜가 있어야 합니다. 이전 URL, 오래된 계정과 불필요한 레코드를 언제 제거할지도 기록합니다. 이 기준을 충족해야 사이트 이전을 단순한 주소 변경이 아니라 재현 가능하고 되돌릴 수 있는 운영 변경으로 닫을 수 있습니다.