VIBE Release Smoke Checker

AI 에이전트에게 리팩터링을 맡길 때 가장 위험한 것은 모델이 코드를 못 쓰는 상황이 아닙니다. 큰 diff를 한 번에 만들고, 그 diff가 왜 안전한지 증명하지 못하는 상황이 더 위험합니다. 코드가 그럴듯해 보여도 사용자 동작이 바뀌었는지, API 응답이 깨졌는지, 사이드 이펙트가 생겼는지 확인하지 않으면 리팩터링은 개선이 아니라 장애가 됩니다.

이 글의 결론은 간단합니다. AI 리팩터링은 작게 나누고, 테스트로 고정하고, 언제든 되돌릴 수 있게 끝내야 합니다. AI에게 "이 파일 정리해줘"라고 맡기는 대신, 어떤 동작은 보존해야 하는지, 어떤 파일은 건드리지 말아야 하는지, 어떤 검증을 통과해야 완료인지 먼저 적어야 합니다.

핵심 결론 먼저

AI가 프런트엔드 기능을 빠르게 붙일 때 자주 놓치는 영역이 브라우저 저장소입니다. 화면은 분명 새로 배포됐는데 어떤 사용자는 예전 권한 화면을 보고, 어떤 사용자는 결제 완료 후에도 온보딩 배너가 사라지지 않고, 어떤 사용자는 로그아웃 뒤 새로고침하면 다시 로그인된 것처럼 보입니다. 서버 코드와 API 응답만 보면 정상이라 더 혼란스럽습니다. 원인은 localStorage, sessionStorage, 쿠키, IndexedDB, Service Worker 캐시, 탭 사이 동기화, 기능 플래그 캐시 같은 브라우저 상태가 서로 다른 생명주기로 남아 있기 때문인 경우가 많습니다.

초보자는 브라우저 저장소를 “웹사이트가 내 브라우저에 잠깐 맡겨 두는 작은 상태 창고”로 이해하면 됩니다. 실무자는 여기서 한 단계 더 들어가야 합니다. 어떤 값은 탭을…