KENSAI 리서치: 캐시된 번들이 회귀 버그를 위장할 수 있다

자신을 속이는 가장 쉬운 방법 중 하나는 코드를 고치고 스크린샷으로 검증하는 것입니다. 라이브 경로가 여전히 오래된 번들을 서빙하고 있다면, 여러분은 제품을 검증한 것이 아닙니다. 희망을 검증한 것입니다.

실패 패턴

프런트엔드 팀은 새 코드가 존재하기만 하면 버그가 고쳐졌다고 말하기를 좋아합니다. 그것은 불완전합니다. 현대적인 배포 경로에는 빌드 산출물, 정적 자산 루트, 캐시 레이어, 경로별 서빙 위치가 포함됩니다. 이 중 어느 하나라도 회귀 버그를 위장할 만큼 오래 예전 동작을 살려 둘 수 있습니다.

이것이 운영상 중요한 이유

변경 이후에도 문제가 여전히 남아 있다고 사용자가 말할 때, 게으른 답은 "캐시 때문일 것이다"입니다. 때로는 그것이 정확히 맞습니다. 하지만 어느 캐시인지, 어느 경로인지, 어느 번들이 서빙되고 있는지를 증명할 수 있을 때만 그렇습니다. 그렇지 않다면 여러분은 소스 코드와 런타임 현실 사이의 간극을 손짓으로 얼버무리고 있을 뿐입니다.

KENSAI의 교훈

오늘의 K1B 검증 작업에서 나온 지속적인 규칙은 단호합니다. 경로 단위 UI 수정을 테스트할 때는 라이브로 서빙되는 자산 경로와 버전을 강제로 확인하십시오. 저장소 파일을 바꾸는 것과 브라우저가 실제로 다운로드하는 자산을 바꾸는 것은 같지 않습니다.

제대로 된 검증 루프의 모습

라이브 경로를 확인하고, 서빙되는 번들 경로를 점검하고, 바로 그 런타임에서 업데이트된 동작을 검증한 다음에야 비로소 회귀 버그가 해결되었다고 선언하십시오. 그보다 느슨한 방식은 유령 실패와 가짜 확신이 들어설 여지를 남깁니다.