AI와 작업하다 보면 “수정했습니다”, “배포됐습니다”, “정상입니다”라는 문장이 쉽게 나온다. 문장만 보면 일이 끝난 것 같지만 실제로는 로컬 파일만 바뀌었거나 빌드 명령만 성공한 경우가 있었다. 나도 처음에는 답이 자연스러우면 확인 범위를 넓게 받아들였다.
지금은 결론보다 어떤 증거가 그 결론을 지지하는지 먼저 본다. 같은 성공이라는 말도 단계에 따라 의미가 다르다.
증거를 층으로 나눴다
웹 화면 수정이라면 대략 다음 순서로 강해진다.
1. 소스 코드에 변경이 존재한다
2. 정적 검사와 테스트가 통과한다
3. 빌드 산출물에 변경이 포함된다
4. 배포 대상이 그 산출물을 제공한다
5. 실제 브라우저 화면과 동작이 확인된다
2번 성공으로 5번을 주장하지 않는다. 어느 단계까지 확인했는지 그대로 말하면 다음 사람이 같은 검증을 반복하지 않아도 된다.
사실과 가설을 문장에서 분리했다
로그 한 줄을 보고 원인을 확정하지 않고 확인된 사실, 가장 가능성 높은 가설, 반대 증거를 나눴다.
확인: 요청 ID가 서버 로그에 도착함
가설: 응답 변환 단계에서 필드가 누락됨
미확인: 실제 사용자 화면이 새 응답을 받았는지
다음 증거: 배포 자산과 브라우저 네트워크 응답 비교
AI에게도 근거 없는 빈칸을 채우지 말고 미확인으로 남기게 했다.
실패한 검증도 버리지 않았다
테스트가 실패하면 성공할 때까지 명령만 반복하기보다 현재 코드 때문에 실패했는지, 기존 환경 문제인지, 도구 권한이 없는지 분류했다. 명령, 결과, 관련 변경을 기록하면 다음 반복이 같은 곳에서 시작하지 않았다.
화면 검증에서는 캐시, 데스크톱·모바일 크기, 직접 URL 접근을 나눠 봤다. 한 번 열린 홈 화면만으로 모든 글과 내비게이션이 정상이라고 결론 내리지 않았다.
증거에도 수명이 있었다. 어제의 배포 화면이나 오래된 로그는 현재 상태를 증명하지 못할 수 있어 변경 뒤에는 필요한 단계를 다시 확인했다. 반대로 동일한 커밋과 산출물임이 확인된 단계는 기록을 재사용해 불필요한 검증을 줄였다.
AI보다 내 판단을 더 명확하게 만들었다
증거를 먼저 모으는 방식은 AI를 불신해서 생긴 절차가 아니다. 사람끼리 작업할 때도 “내 PC에서는 됨”과 실제 배포 성공을 구분하는 데 필요했다. AI는 이 간격을 빠르게 건너뛰는 문장을 만들 수 있어 더 의식적으로 확인하게 됐다.
지금의 목표는 AI가 항상 정답을 말하게 만드는 게 아니다. 틀릴 수 있는 도구와 함께 일하면서도 코드와 사용자 경험에 대해 내가 책임질 수 있는 증거를 남기는 것이다. 답변보다 증거를 먼저 보는 습관이 지금까지 얻은 가장 큰 변화다.