AI에게 수정 작업을 맡기고 “완료했습니다”라는 보고를 받았는데, 로컬 화면을 열어보면 이전 UI가 그대로인 일이 있었다.
처음에는 수정이 잘못됐다고 생각했다. 하지만 저장소의 코드는 실제로 바뀌어 있었다.
문제는 코드 수정 완료와 지금 브라우저가 보고 있는 실행 결과가 같은 상태가 아니었다는 점이었다.
파일이 바뀌었다고 실행 중인 앱이 반드시 바뀌는 것은 아니다
개발 서버가 다른 디렉터리를 보고 있거나, 이전 프로세스가 계속 실행 중이거나, 빌드가 다시 만들어지지 않았으면 브라우저에는 예전 결과가 남을 수 있다.
특히 여러 프로젝트와 runner를 동시에 운영하면 “5173인지 5176인지”, “어느 폴더에서 dev server를 띄웠는지” 같은 사소한 차이가 중요해진다.
agent는 파일 수정까지만 확인하고 성공으로 판단할 수 있다. 하지만 사용자가 확인하는 것은 브라우저에 렌더링된 결과다.
QA 시작 전에 확인해야 하는 주소가 생겼다
이후에는 QA 요청에 로컬 주소까지 포함하기 시작했다.
예를 들면 단순히 “임신 캘린더 화면 확인해줘”라고 하지 않고 다음처럼 조건을 붙인다.
- 확인할 정확한 로컬 URL
- 현재 서버가 바라봐야 하는 브랜치 또는 작업 디렉터리
- 최신 코드가 반영된 서버인지
- 테스트 계정과 시작 화면
- 확인할 기능 범위
QA가 잘못된 빌드를 보고 있으면 아무리 테스트를 많이 해도 결과가 의미가 없다.
코드 검증과 화면 검증을 분리했다
“수정 완료”라는 말을 두 단계로 나누는 것이 도움이 됐다.
첫 번째는 코드 수준 완료다.
- 예상 파일이 수정됨
- 테스트 통과
- 빌드 통과
두 번째는 실행 결과 완료다.
- 지정한 로컬 주소에서 최신 UI 확인
- 주요 인터랙션 확인
- 브라우저 콘솔 오류 확인
- 기존 기능 회귀 여부 확인
두 단계가 모두 끝나야 운영 반영 후보로 본다.
캐시 문제와 잘못된 빌드 문제도 구분해야 한다
브라우저에 예전 화면이 보인다고 무조건 캐시를 지우는 것도 위험하다.
PWA라면 Service Worker 캐시 문제일 수 있지만, 일반 개발 서버에서는 아예 다른 프로세스나 오래된 빌드를 보고 있을 수도 있다.
그래서 먼저 서버가 올바른 코드를 제공하는지 확인하고, 그다음 브라우저 캐시나 Service Worker를 본다.
운영 배포 전 QA의 첫 질문은 “무엇을 보고 있는가”
기능 테스트는 보통 “버튼이 동작하는가”부터 시작한다. 하지만 여러 자동화와 개발 서버가 얽힌 환경에서는 그보다 앞선 질문이 필요했다.
지금 내가 보고 있는 화면이 정말 방금 수정한 코드인가?
이 확인 하나가 빠지면 정상 코드를 다시 고치거나, 이미 해결된 문제를 반복해서 디버깅할 수 있다.
자동화가 많아질수록 코드뿐 아니라 실행 중인 환경의 정체성도 함께 관리해야 했다.