운영 기간이 끝난 사이트를 닫아 달라는 요청은 메뉴에서 링크 하나를 지우는 일보다 컸다. 같은 내용을 보여 주는 다른 주소도 있었고, 이미 주소를 아는 사람은 첫 화면을 거치지 않고 이미지나 문서를 요청할 수 있었다. 나는 당시 대화와 남아 있는 종료 응답 코드를 다시 읽으며 어디에서 제공을 멈추는지 정리했다. 이번 글을 쓰려고 고객 사이트를 새로 닫거나 다시 연 것은 아니다.
방문자가 아는 주소는 대표 주소 하나가 아니다
당시 요청은 한 배포 주소를 가리키면서 연결된 곳도 함께 보이지 않게 하라는 내용이었다. 나는 이 문장을 화면 한 장의 수정이 아니라 노출 범위를 정해야 하는 요청으로 읽었다. 사용자 도메인, 원본 배포 주소, 따로 알려 준 직접 문서 주소가 어디로 가는지 먼저 구분해야 한다. 사람이 비슷하게 부르는 이름만으로 같은 서비스인지 판단하지 않는다.
기존 도메인 연결 글은 DNS와 프로젝트 등록, 실제 도착 화면의 연결을 다뤘다. 종료에서는 반대로 그 연결표를 따라 어떤 입구가 남아 있는지 묻는다. 한 입구에서 종료 안내가 보였다는 사실로 다른 입구의 응답을 채울 수 없다. 이번에는 고객 주소를 공개하지 않고 실제 소스에 남은 두 종류의 응답 경계만 설명한다.
라우터의 종료 표시와 원본 주소의 응답을 나눴다
사용자 호스트를 고르는 라우터에는 특정 항목에 closed가 명시되어 있었다. 그 항목의 요청이 종료 분기에 도달하면 원본 사이트를 읽기 전에 410 응답을 만든다. 이 분기는 SEO용 파일을 만들어 주거나 원본에 fetch를 보내는 흐름보다 앞에 있다. 종료된 곳의 요청을 평소의 정상 페이지 처리로 계속 넘기지 않으려는 경계다.
다른 로컬 종료 폴더에는 별도의 _worker.js가 남아 있다. 이 함수도 종료 응답을 만들며 원래 자산을 읽지 않는다. 사용자 호스트의 라우터와 직접 배포 주소의 처리 코드를 따로 보는 이유가 여기에 있다. 한쪽 코드만으로 현재 모든 별칭과 플랫폼 경로가 연결됐다고 증명하지는 않는다. 이번에는 원격 등록이나 현재 배포 상태를 조회하지 않았다.
이미지와 CSS의 직접 요청도 질문에 넣었다
종료 안내 화면만 올리고 원래 파일을 그대로 제공하면 저장된 이미지 주소나 깊은 문서 주소는 여전히 별개로 읽힐 수 있다. 남아 있는 종료용 함수는 요청 경로를 골라 정상 파일을 반환하는 코드가 아니라 같은 종료 응답을 만드는 형태다. 나는 이 소스의 의도와 실제 배포 범위를 구분하면서 첫 화면 밖의 요청을 검수 질문에 넣었다.
코드에는 410 상태와 no-store, noindex·nofollow·noarchive 헤더가 함께 있다. 서버가 이번 요청에 어떤 응답을 줄지와 검색·보관에 어떤 지시를 남기는지는 다른 역할이다. 헤더를 붙였다는 사실만으로 이미 내려받은 사본, 과거 캐시나 검색 결과가 모두 없어졌다고 쓸 수 없다. 종료 응답과 과거 노출의 정리를 하나의 완료로 섞지 않는다.
한 곳을 닫으면서 다른 곳을 함께 닫지 않도록
공용 라우터는 종료된 항목 외에도 여러 정상 대상을 가진다. 그래서 전체 공용 주소를 막거나 기본 목적지를 바꾼 결과로 한 곳의 종료를 대신하지 않는다. 선택 소스에는 호스트별 설정과 경로별 정상 라우팅이 함께 있다. 종료할 범위의 이름과 그대로 제공할 범위의 이름을 따로 남겨야 영향을 설명할 수 있다.
기존 시험 파일에는 종료 호스트의 첫 화면이 410인지 보는 항목과 다른 라우팅을 확인하는 항목이 있었다. 나는 그 코드를 읽었지만 이번에 원래 시험이나 고객 프로그램을 실행하지 않았다. 첫 화면 한 항목을 봤다는 사실로 모든 메서드와 자산까지 통과했다고 확대하지 않는다. 과거 시험의 일부 예상 목적지가 현재 설정과 다른 점도 있어 현재 성공 근거로 가져오지 않았다.
검수표에는 주소와 요청 종류를 함께 남긴다
다른 현장에 같은 생각을 적용한다면 알려진 각 입구마다 첫 화면, 직접 문서, 이미지, CSS와 스크립트, 검색 안내 파일을 적을 수 있다. 읽기 요청과 HEAD 같은 별도 메서드, 질의가 붙은 주소도 요구 범위에 맞춰 나눈다. 이 목록은 이번 고객 서버에서 새로 실행한 결과표가 아니라 다음 실제 검수에 사용할 질문의 틀이다.
기대값을 적을 때도 종료 응답의 상태, 원래 본문이나 자산 바이트가 나오지 않는지, 정상 이웃 대상이 보존되는지를 따로 본다. 목록에 없는 별칭을 자동으로 발견해 모두 확인했다고 하지 않는다. 현재 연결표를 확보할 책임과 각 요청을 실제로 확인할 책임을 분리해야 작은 검사 수를 전체 종료 성공으로 바꾸지 않을 수 있다.
종료와 보관은 같은 삭제 명령이 아니다
당시 완료 답변에는 프로젝트와 이전 배포 이력을 남겼다는 기록이 있었다. 이번에는 그 원격 이력을 다시 열어 확인하지 않았고, 고객 파일과 운영 상태도 바꾸지 않았다. 공개 제공을 멈추는 결정과 나중에 검토할 제작 자료를 보존하는 결정은 서로 다른 범위다. 복구할 자료가 있다는 말도 다시 공개해도 된다는 허가가 되지는 않는다.
이 구분은 제작기를 남길 때도 같다. 실제 고객 원고·주소·연락처를 다시 드러내는 대신 어떤 요청 경계를 만들었는지 설명한다. 코드를 보관했다는 사실, 종료 코드가 남아 있다는 사실, 현재 서비스가 모든 주소에서 종료됐다는 사실을 각각의 근거로 읽는다. 이번 글은 앞의 기록과 소스를 재검토한 결과다.
기존 공개 상태 모듈을 어디까지 재사용했는가
이미 공개한 본문 상태 검사 모듈에는 목록과 관련 글에서 내린 항목을 빼고 직접 본문 요청에서도 공개 상태를 확인하는 코드가 있다. 이번에는 현재 CMS version 3의 코드를 꺼내 합성 저장소로 9개 검사를 실행했다. 내린 본문 차단, 다음 조회의 상태 변경, 비공개 필드 제외와 반환 배열의 분리를 확인했다. 그 연결 원리를 설명하는 데 기존 구현을 재사용했다.
이 모듈은 호스트 라우터나 정적 파일 차단기가 아니며 410 응답을 만들어 주지도 않는다. 코드가 확인한 범위를 사이트 전체 종료의 시험으로 바꾸지 않는다. 나는 새 패키지를 하나 더 만들기보다 기존 공개 상태 검사의 사용 범위를 정확히 연결했다. 독자가 적용할 때도 메뉴에서 보이지 않는가와 요청에 실제로 제공되는가를 나눠 물으면 종료 범위를 더 분명히 정할 수 있다.