배포 후 실제 주소에서 내용과 버전을 다시 확인하기

배포한 버전과 실제 주소의 응답을 대조하고 불일치 원인을 확인하는 개념도.

내가 겪은 상황

2026년 7월 Claude 작업에서 배포 명령은 성공했지만 직후 일부 공개 주소에는 이전 내용이 남아 있었다. 응답 헤더에서 캐시 HIT를 확인했고, 같은 주소를 다시 검증한 기록에서 이전 문구가 더는 나오지 않는 것을 확인했다. 10월의 다른 작업에서도 최신 성공 버전과 과거 실패 버전을 각각 설명했다.

내가 선택한 방법

배포한 소스 커밋과 서비스가 받은 버전, 실제 공개 주소의 응답 내용과 헤더를 나눠 확인한다. 일부 주소만 다르면 그 차이를 먼저 기록한다. 확인하지 않은 원인을 캐시라고 단정하고 빌드를 반복하지 않는다.

다음에도 쓸 기준

배포 접수와 실제 사용자 화면은 다른 증거다. 원하는 내용이 같은 실제 주소에서 나오는지 확인한 뒤 공개 반영을 보고한다. 관리 화면의 과거 실패를 최신 성공으로 덮어 설명하지 않고, 어느 버전의 상태인지 명시한다.

적용 한계

모든 배포 불일치가 캐시 때문인 것은 아니다. 도메인 연결, upstream, 산출물이나 소스가 다를 수도 있다. 과거 사례의 캐시 해결 시간으로 현재의 대기 시간을 약속하지 않는다. 게시하지 않은 빌드에는 공개 반영 완료라는 표현을 쓰지 않는다.

관련: 완료라고 말하기 전에 검증한 단계를 나누기 · Toris의 작업 기록에서 정리한 암묵지