루프의 시작과 끝을 기록합니다
브라우저의 이동 횟수 초과 화면만 저장하면 어떤 규칙이 충돌했는지 알기 어렵습니다. 같은 경로를 슬래시 있음·없음으로 나눠 요청하고 최초 코드, Location과 다음 응답을 차례로 적습니다. 쿼리가 있는 요청도 한 개 포함하되 실제 고객 정보는 사용하지 않습니다. 결과가 같은 주소로 되돌아오면 반복이 시작되는 두 응답을 표시합니다.
정규화 책임을 한 곳씩 확인합니다
애플리케이션의 경로 설정, 호스팅의 Pretty URL 또는 디렉터리 처리, CDN 규칙과 직접 작성한 리다이렉트를 순서대로 봅니다. 개발 서버에서 정상이라는 사실은 호스팅의 추가 동작이 없다는 근거가 아닙니다. 운영 URL의 응답을 기준으로 어떤 계층이 슬래시를 추가하고 어느 계층이 제거하는지 구분합니다.
정상 경로와 없는 경로를 함께 검사합니다
- 홈, 실제 상세 문서, 정적 파일을 각각 표본으로 고릅니다.
- 끝 슬래시를 붙인 상태와 뺀 상태의 기대 목적지를 적습니다.
- 임의의 존재하지 않는 경로를 넣어 최종 오류 응답이 나오는지 확인합니다.
- 규칙 수정 뒤 기존 상품 이동 규칙이 먼저 적용돼야 하는 경로도 다시 검사합니다.
설계 예시로 /guide/가 이미 최종 주소인데 포괄 규칙이 다시 /guide/를 Location으로 반환하면 같은 요청이 반복될 수 있습니다. 반대로 한 계층이 /guide로 보내고 다른 계층이 /guide/로 돌리면 두 주소 사이를 오갑니다. 어느 한 쪽 규칙을 더 추가하는 대신 정규화 책임과 예외를 정리합니다.
완료 판정
정상 문서는 합의한 대표 주소의 200 응답으로 끝나고 자기 자신으로 이동하지 않아야 합니다. 정적 파일은 파일에 맞는 응답을, 존재하지 않는 문서는 의도한 오류 상태를 제공해야 합니다. 검사 결과에 총 이동 횟수와 최종 주소를 남깁니다. 홈만 통과한 것을 전체 경로 정책의 검증으로 보고하지 않습니다.
재발을 막는 변경 방식
새 규칙을 추가할 때 기존 규칙의 순서와 자동 정규화를 함께 검토합니다. 배포 전에 대표 표본을 작은 회귀 목록으로 저장하면 새 상품 경로나 프레임워크 설정 변경의 영향을 확인할 수 있습니다. 운영에서 루프가 발생하면 마지막 정상 규칙으로 복구할 수 있도록 변경 배포 식별자도 기록합니다.
자주 묻는 질문
- 모든 URL에 슬래시를 붙이는 규칙 하나로 처리하면 되나요?
- 이미 슬래시가 있는 요청과 존재하지 않는 경로가 어떻게 매칭되는지 먼저 테스트합니다. 프레임워크·호스팅이 제공하는 동작을 확인하지 않고 광범위한 규칙을 추가하면 자기 주소로 다시 이동하는 문제가 생길 수 있습니다.
- 존재하지 않는 경로도 슬래시 정규화가 필요하나요?
- 대표 주소 정리와 없는 문서의 오류 응답을 구분합니다. 존재하지 않는 주소가 반복 이동만 하거나 정상 홈으로 처리되지 않는지 별도의 실패 테스트를 둡니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.