AI 에이전트가 완료라고 했을 때 확인할 5가지

완료 보고를 말이 아니라 증거로 들여다보는 장면을 담은 이미지입니다.

"완료했습니다.
화면 버그 고쳤고 테스트도 통과했습니다."

답이 너무 깔끔해서, 그 말을 믿고 그냥 넘어갈 뻔했습니다.

그런데 습관처럼 diff를 열었어요.

정작 그 화면 파일은 그대로였습니다.
엉뚱한 코드를 고쳐놓고 완료라고 한 거였죠.

한두 번이 아니었어요.
화면을 맡기면 특히 그랬습니다.

그날 이후로 완료 보고를 받으면 말투를 안 봅니다.
증거를 봐요.
보는 순서가 있는데, 다섯이긴 해도 무게가 다 달라요.

제일 먼저, 말보다 diff

"수정했습니다"는 아직 빈말이에요.

어떤 파일이 바뀌었는지부터 봐야 진짜죠.
고쳐야 할 화면의 위젯 파일이 바뀌었나.
엉뚱한 파일만 바뀌어 있으면, 설명이 아무리 매끄러워도 그 순간 보고는 무효입니다.

오히려 설명을 잘할수록 이 단계가 더 중요해요.
그 말이 맞는지는 결국 diff를 봐야 아니까요.
그래서 저는 아예 AI가 잘못 고를 후보를 줄여 둡니다.
파일을 단일 책임으로 잘게 나누고, 안 쓰는 파일은 매주 지워요.
고를 수 있는 게 적으면 엉뚱한 데를 고칠 일도 줄거든요.

그 다음 세 개는 한 호흡에 봐요

diff가 맞으면, 거의 같이 묶어서 빠르게 훑는 게 셋이에요.

먼저 검증이 그 버그를 정확히 겨냥했나.
"테스트 통과"는 그대로 안 믿어요.
결제 반올림 버그면 전체 통과보다 10,005원 같은 경계값 하나를 직접 넣은 테스트가 진짜죠.
그래서 매번 같은 걸 물어요.
이 테스트, 방금 고친 버그를 되살리면 실패하나?
"아니"가 나오면 그 테스트는 예쁘기만 한 거예요.

그리고 돌린 명령이 작업과 맞나.
한번은 느린 화면을 빠르게 만드는 작업을 맡겼는데, 단위 테스트가 전부 초록불이라 통과 보고가 깔끔했어요.
그런데 자세히 보니 "정말 빨라졌나"는 한 번도 안 재본 거였어요.
정작 그 작업의 목표였는데요.
게다가 로컬 DB가 막혀서 아예 안 돌아간 테스트 몇 개가 '통과' 줄에 슬쩍 끼어 있었고요.
초록불 개수만 보면 다 된 것 같지만, 진짜 봐야 할 걸 안 본 채로 초록불이 켜질 수 있다는 걸 그때 알았어요.
그 뒤로는 무엇을 봤고 무엇을 안 봤는지가 같이 적혀 있는지를 봐요.
그게 적혀 있으면 믿을지 말지 제가 판단할 수 있으니까요.

마지막으로 사용자가 밟는 길을 직접 한 번.
코드는 통과해도 화면은 깨질 수 있으니까요.
버튼 누르면 요청이 나가는지, 응답이 화면에 도는지, 실패하면 메시지가 뜨는지.
화면이면 빈 목록일 때랑 글자가 길 때를 한 번씩 켜 보고요.
개발자는 결국 사용자가 밟는 길을 책임지잖아요.

제일 무겁게 보는 건, 남은 리스크

순서로는 마지막인데 사실 제일 중요해요.
못 본 부분이요.

에이전트가 "완벽히 해결했습니다"라고 하면 저는 오히려 불안해요.
복잡한 작업에서 완벽이라는 말은 너무 싸게 나오거든요.
차라리 이런 보고가 셉니다.

• 모바일 Safari는 확인하지 못했습니다
• 결제 sandbox는 권한이 없어 못 돌렸습니다
• 캐시가 있는 환경은 반영까지 시간이 걸릴 수 있습니다

약한 보고처럼 보여도 사실 강한 보고예요.
다음에 사람이 어디를 봐야 할지 알려주니까요.

그래서 깔끔한 보고일수록

다섯 개가 매번 다 필요한 건 아니에요.
변수명 하나 바꾼 거면 diff만 봐도 되고요.

그래도 화면을 맡겼을 땐, 보고가 아무리 깔끔해도 일단 diff부터 열고 그 화면을 진짜로 한 번 켭니다.
그 "완료했습니다"에 한 번 속아 본 뒤로 생긴 버릇이에요.

솔직히 아직도 가끔은 그냥 믿고 싶어요.
근데 그렇게 믿은 날이 꼭 나중에 터지더라고요.

이 글은 'AI 코딩 에이전트를 믿는 법' 시리즈의 한 편이에요.
위임·검증·하네스·비용 6편을 한 번에 보려면 여기로요.

https://datacook.tistory.com/156

AI 코딩 에이전트를 믿는 법 — 위임·검증·하네스·비용 6편 정리