서비스를 옮긴 뒤 예전 주소는 왜 열릴까: 410·이동·noindex를 나눈 기록

2026년 10월 22일, 운영하던 네 정보 서비스를 gamepunch.org의 /public/ 하위에서 punchblog.com의 별도 경로로 옮겼습니다. 첫 적용은 이전 주소에서 새 주소로 이동시키는 방식이었고, 이후 운영자의 의도에 맞춰 이전 공개 주소가 서비스 화면을 열지 않도록 410 응답으로 바꿨습니다. 이 글은 그 두 동작을 구분한 작업 기록과 반영 후 직접 수행한 여덟 번의 공개 GET 확인입니다. 여기서 종료한 대상은 이전 서비스 화면입니다. 같은 경로 아래의 데이터까지 한꺼번에 종료하면 이미 설치된 앱을 깨뜨릴 수 있었습니다. 최초 화면 확인 자료는 그대로 두고, 아래에 데이터 복구 기록과 별도의 후속 확인을 추가했습니다.

접속 유지와 검색 제외를 다른 질문으로 나눴습니다

기존 서비스를 계속 쓸 수 있어야 한다는 조건과, 이전 도메인에서는 그 서비스가 열리지 않아야 한다는 조건을 함께 정리했습니다. 새 주소가 200을 반환한다는 사실만 확인하면 이전 주소가 여전히 200인지, 새 주소로 이동하는지, 종료됐는지 알 수 없습니다. 또한 새 주소에 noindex를 넣어도 브라우저 접속은 계속 가능합니다. 접속 여부와 검색 노출 의도는 응답의 다른 부분에서 확인해야 했습니다.

반영 후 직접 확인한 여덟 응답

아래 표는 설정 반영을 끝낸 뒤 공개 HTTPS 주소에 GET 요청을 보낸 결과입니다. curl에 -L을 주지 않아 이동 응답을 자동으로 따라가지 않았고 TLS 검증을 켰습니다. 상태 코드는 2026년 10월 22일에 관찰한 응답이며, 변경 전 화면을 보존한 자료나 장시간 가용성 시험은 아닙니다. 기존 주소 네 곳은 410과 Location 없음, 새 주소 네 곳은 200과 noindex를 확인했습니다.

왜 이동 응답만으로 끝내지 않았나요

새 주소를 알려 주면서 이전 링크의 이용자를 계속 연결하려면 리디렉션이 한 가지 방법입니다. 하지만 이번 요청은 이전 도메인의 서비스 주소를 열어도 서비스로 연결되지 않는 상태였습니다. 그래서 이 네 공개 경로의 기대 상태를 410으로 바꿨습니다. 모든 도메인 이전에서 같은 결정을 권하는 뜻은 아닙니다. 이전 링크의 이용자를 새 서비스로 안내해야 한다면 목표 자체가 다르므로 종료 코드 대신 적절한 이동 응답을 검토해야 합니다.

검사 도구도 그 목표를 따라 바꿔야 했습니다. 200 또는 이동 뒤의 최종 화면만 성공으로 판정하면, 의도한 410을 장애로 오인할 수 있습니다. 이번 검사는 기존 경로의 410과 새 경로의 200을 각각 정상 기대값으로 두었습니다. 읽기 전용 스크립트는 응답 본문을 공개하지 않고 길이와 해시만 남기며, 쿠키나 계정 정보를 기록하지 않습니다.

공개 경로를 막았는데 새 서비스도 같이 막히는 경우

두 도메인이 같은 서버의 기존 라우팅을 이용하면 새 도메인의 내부 요청도 이전 경로를 거칠 수 있습니다. 공개 경로를 구분 없이 막으면 새 주소까지 410으로 끝나는 자기 차단이 생길 수 있습니다. 이번 작업은 외부 공개 요청의 종료 규칙과 내부 루프백 라우팅을 구분했습니다. 공개 확인에서 새 주소가 실제 콘텐츠를 반환하는지 검사한 이유입니다. 웹서버가 켜져 있다는 상태 확인만으로는 이 구분을 검증하지 못합니다.

본문 안의 링크·스크립트·데이터 경로도 대상입니다. 첫 HTML만 새 주소에서 열려도 검색이나 상세 화면이 이전 도메인을 다시 요청하면 이전 경로의 종료 규칙에 걸립니다. 이 사례에서는 공개 전 테스트 경로에서 네 서비스의 화면과 연결 경로를 먼저 점검하고, 공개 후 다시 확인했습니다. 이 글의 다운로드 자료는 여덟 대표 요청의 후속 확인만 담으며, 모든 브라우저 동작이나 로그인 상태를 재현하는 검사는 아닙니다.

noindex는 브라우저 접근 차단이 아닙니다

새 서비스는 공개 접속을 유지하면서 X-Robots-Tag의 noindex로 검색 제외 의도를 전달했습니다. 이 헤더는 비밀번호나 접근 제어 기능이 아니므로 주소를 아는 사람이 서비스를 여는 것을 막지 않습니다. Google이 이 설정을 읽으려면 해당 주소를 수집할 수 있어야 합니다. 따라서 검색 제외를 읽히게 하려는 주소를 robots.txt로 동시에 막는 방식은 쓰지 않았습니다.

410을 적용했다고 서치콘솔의 이전 주소 수가 그 자리에서 사라지지는 않습니다. HTTP 응답을 고치는 작업과 검색엔진이 다시 방문해 결과를 반영하는 일은 서로 다른 시점에 일어납니다. 이번 스크립트는 공개 서버가 보내는 응답만 확인합니다. Google의 실제 재수집, 검색 결과 삭제나 광고 심사 결과를 검증하는 도구가 아닙니다.

내 사이트에서는 어떤 요청을 먼저 확인할까요

1. 목표 응답을 적습니다

   이전 주소를 이동시킬지 종료할지, 새 주소의 접속과 검색 노출은 어떻게 할지 나눕니다.

2. 이동을 따라가지 않고 요청합니다

   curl의 HTTP 상태·Location·검색 제외 헤더를 별도 항목으로 읽습니다.

3. 첫 화면 뒤의 경로를 확인합니다

   상세 글, 정적 파일, 데이터 요청과 없는 주소도 기대 상태와 대조합니다.

4. 현재 응답과 검색 기록을 구분합니다

   사이트맵에서 종료 주소를 빼고, 재수집 전의 보고서 숫자로 배포 실패를 단정하지 않습니다.

curl -q -sS --connect-timeout 4 --max-time 20 \
  -D response-headers.txt -o response-body.html \
  -w '%{http_code}\n' https://example.com/old-service

설치된 앱은 새 화면 주소를 자동으로 알지 못했습니다

화면 주소 여덟 곳이 의도대로 응답해도 설치 앱의 데이터 연결은 별개였습니다. 이전 데이터 주소 네 곳까지 410 HTML이 되었고 새 도메인의 대응 데이터 주소는 200 JSON이었습니다. 기존 앱은 옛 주소를 계속 호출하므로 새 서비스가 열려 있어도 목록을 받을 수 없었습니다. 다음 표는 10월 22일 보관한 공개 확인 기록입니다. 정확한 요청 시각은 기록되지 않았으며 오늘의 장애를 다시 재현한 자료가 아닙니다.

복구는 이전 화면 전체를 되살리는 방식이 아니라 설치 앱이 이미 쓰는 데이터 경로에만 기존 처리기로 연결하는 방식이었습니다. 원래의 캐시·요청 제한을 유지하고 API 응답에 noindex를 남겼습니다. 특히 축구 공개 요청에 외부 공급자 재조회 경로를 넣지 않았습니다. 주소 이전으로 생긴 연결 문제와 캐시 미수집·자료 지연은 다른 원인이므로 구분했습니다.

현재 데이터 여덟 곳과 종료 화면 네 곳을 따로 검사했습니다

후속 공개 GET에서는 기존·새 데이터 주소 여덟 곳이 모두 200 JSON, 이전 화면 네 곳은 모두 410이었습니다. 데이터별로 sections 배열, global 객체, response 배열, regions 배열이 있는지 검사했습니다. JSON 본문이 바이트 단위로 같다는 조건은 쓰지 않았습니다. 시각·캐시 갱신 등에 따라 두 요청의 값이 달라질 수 있고, 외곽 형식 일치만으로 모든 값의 정확성이나 앱의 모든 화면을 보장하지는 않기 때문입니다.

독자가 같은 이전을 준비한다면 화면 URL 목록과 설치된 클라이언트의 실제 데이터 URL 목록을 따로 적고, 기존 버전의 주소도 검사해야 합니다. 새 앱을 배포하기 전까지 필요한 호환 경로의 범위를 기록하고 화면의 410 응답도 함께 확인합니다. 이 후속 검사는 공개 읽기 전용 요청이며 휴대폰 설치·로그인·푸시 알림 검사는 아닙니다. noindex는 접속 차단이나 애드센스 심사 제외를 보장하는 장치가 아닙니다.

python3 check-service-retirement.py --output new-observations.json

python3 check-native-api-compatibility.py --output check-native-api-compatibility-result.json