해시만 다른 URL로 goto하면 페이지는 다시 뜨지 않는다 — 이전 화면을 새 부트 결과로 오인한다

해시만 다른 URL로 goto하면 페이지는 다시 뜨지 않는다 — 이전 화면을 새 부트 결과로 오인한다

웹앱 배포 검증 자동화가 “라우팅이 깨졌다”는 보고를 올렸다. 스크린샷을 보니 정말 엉뚱한 화면이었다. 그런데 실제 서비스는 멀쩡했다. 오보의 원인은 검증 스크립트 쪽에 있었다. page.goto('https://…/#/screen-a')로 한 화면을 확인한 뒤 page.goto('https://…/#/screen-b')로 넘어갔는데, 두 URL이 해시(#) 부분만 다르면 브라우저는 문서를 다시 로드하지 않는다. 해시 변경은 같은 문서 안의 이동이라서다. 앱이 해시 변경 이벤트를 구독하지 않는 구조면 화면은 그대로 남고, 스크립트는 이전 화면을 “screen-b의 부트 결과”로 찍어 온다.

즉 검증기가 잰 것은 대상 앱이 아니라 자기 자신의 탐침 방식이었다.

왜 위험한가

• URL 표시줄과 page.url()은 새 주소를 보여준다. URL은 이동했는데 문서는 그대로인 상태라, 로그만 봐서는 완전히 정상으로 보인다.
• “깨졌다” 오보는 멀쩡한 배포를 롤백하게 만들 수 있다. 계기 오류가 실제 조치를 유발하는 최악의 경로다.

룰

1. 탐침 사이에 about:blank로 리셋한다. goto('about:blank') → goto(대상) 순서면 해시만 다른 URL도 항상 풀 리로드된다. (같은 효과로 page.reload()를 쓸 수도 있다.)
2. 판정 근거는 URL·타이틀이 아니라 렌더된 픽셀/DOM이다. 화면 고유의 마커 요소나 스크린샷을 기준으로 삼는다.
3. 화면 A와 B가 동시에 가진 요소로 판정하지 않는다. 그 화면에만 있는 것을 마커로 골라야 이전 화면 잔상과 구분된다.

체크리스트

1. 검증 스크립트가 같은 origin의 해시/쿼리만 다른 URL을 연속 goto 하는가?
2. 각 탐침 앞에 리셋(about:blank 또는 reload)이 있는가?
3. “화면이 떴다”의 판정 근거가 URL인가, 그 화면 고유의 렌더 결과인가?
4. 오보 가능성 점검: 검증기가 “깨졌다”고 할 때, 손으로 열어 본 대조가 한 번이라도 있었는가?

한 문장으로. 브라우저 자동화에서 URL은 의도의 기록이지 결과의 증거가 아니다 — 문서가 다시 떴는지는 리셋과 픽셀로만 증명된다.