종료 체크: 끝났다는 말 앞에서 볼 세 가지

2026년 5월 2일 | 바이브코딩 Tips

---

에이전트가 “끝났습니다”라고 말하는 순간이 나는 제일 미묘하다. 실제로는 코드가 어느 정도 바뀌었고, 테스트도 하나쯤 돌았고, 답변도 그럴듯하다. 그런데 몇 번 삽질을 해보니 사고는 작업 중간보다 이 마지막 문장에서 더 자주 났다. 완료라는 말이 검증의 끝처럼 들리지만, 실제로는 사람이 확인해야 할 증거가 막 도착한 시점인 경우가 많았다.

그래서 요즘 코딩 에이전트를 쓸 때는 시작 프롬프트보다 마지막 답변의 모양을 더 신경 쓴다. 거창한 절차는 아니다. 에이전트가 마지막에 “완료”라고 말하기 전에, 변경·검증·위험을 세 줄로 접어 오게 만드는 정도다. 이 작은 종료 체크를 넣으면 작업이 느려질 것 같지만, 내 체감으로는 오히려 반대였다. 한 번 잘못 받아들인 변경을 되돌리는 시간이 훨씬 더 길었다.

도구 계약은 시작점이고, 종료 체크는 완료 답변 직전의 작은 검문소에 가깝다.

완료 답변은 결과가 아니라 handoff 자료

바이브코딩을 처음 편하게 쓰기 시작했을 때 나는 마지막 답변을 거의 영수증처럼 봤다. “수정했습니다”, “테스트 통과했습니다”, “이제 괜찮습니다” 같은 문장이 있으면 대충 안심했다. 그런데 나중에 diff를 다시 열어 보면 이상한 경우가 있었다. 테스트는 돌았지만 내가 걱정하던 경로가 아니었고, 화면은 바뀌었지만 빈 상태나 에러 상태는 보지 않았고, 타입 오류는 사라졌지만 데이터 흐름이 옆으로 샜다.

이때 문제는 에이전트가 거짓말을 했다기보다, 완료의 기준을 서로 다르게 들고 있었다는 점에 가까웠다. 에이전트는 “요청한 파일을 수정했고 즉시 보이는 오류를 없앴다”를 완료로 봤고, 나는 “원래 깨진 사용자 흐름이 다시 안전해졌다”를 완료로 보고 있었다. 둘 사이에는 꽤 큰 간격이 있다. 그래서 마지막 답변은 최종 판정이 아니라, 사람이 최종 판정을 내리기 위한 handoff 자료라고 보는 편이 맞았다.

나는 이 관점을 바꾼 뒤로 마지막 문장을 짧게 만들지 않는다. 대신 구조를 고정한다. 에이전트에게 “무엇을 바꿨는지”, “무엇으로 확인했는지”, “무엇은 아직 확인하지 못했는지”를 분리해서 쓰게 한다. 이 세 칸이 나뉘어 있으면 거짓 안정감이 줄어든다. 특히 “테스트 통과”라는 한 줄이 실제로 어떤 테스트인지 드러나기 때문에, 내가 추가로 볼 화면이나 케이스가 훨씬 빨리 보인다.

세 가지 칸: 변경, 검증, 위험

내가 가장 자주 쓰는 종료 체크는 세 칸짜리다. 첫째는 변경이다. 파일명만 나열하는 게 아니라, 사용자가 느낄 동작이 어떻게 달라졌는지 한 문장으로 쓰게 한다. “상태 계산 로직 수정”보다 “빈 검색 결과에서 이전 카드가 남지 않도록 상태 초기화 위치를 옮김”이 낫다. 이렇게 써야 나중에 diff를 열지 않고도 작업의 의도가 살아난다.

둘째는 검증이다. 여기서 중요한 건 “테스트함”이라는 말이 아니라 검증의 범위다. 단위 테스트를 돌렸는지, 빌드만 했는지, 화면 preview를 봤는지, 아니면 타입 체크만 통과했는지 구분한다. 바이브코딩에서는 이 차이가 꽤 크다. 에이전트가 UI를 고쳤다고 말해도 브라우저에서 빈 목록, 긴 문자열, 모바일 폭을 안 봤다면 그건 아직 UI 검증이 아니다. API를 고쳤다고 해도 실패 응답과 timeout을 안 봤다면 운영 검증도 아니다.

셋째는 위험이다. 이 칸은 조금 어색해도 일부러 남긴다. 아직 확인하지 못한 가정, 건드리지 않기로 한 파일, 다음 사람이 먼저 열어야 할 로그, 되돌릴 때 기준이 되는 커밋이나 설정을 적는다. 에이전트에게 이 칸을 요구하면 마지막 답변의 톤이 달라진다. “다 됐습니다”에서 “여기까지는 확인했고, 이 부분은 아직 사람 확인이 필요합니다”로 내려온다. 나는 이 낮아진 톤이 더 믿을 만하다고 느낀다.

칸	에이전트에게 요구할 문장	사람이 보는 포인트
변경	사용자 동작 기준으로 무엇이 달라졌는지 쓰기	diff가 원래 문제를 향했는지 확인
검증	실제로 돌린 테스트와 확인한 화면만 적기	검증 공백을 다음 행동으로 바꾸기
위험	미확인 가정과 되돌릴 기준을 남기기	배포·병합·추가 질문 중 무엇을 택할지 결정

프롬프트보다 종료 조건을 더 구체적으로

종료 체크를 잘 쓰려면 처음부터 완벽한 프롬프트를 쓰려는 욕심을 조금 내려놓는 편이 낫다. 시작 프롬프트가 아무리 좋아도 작업 중간에 파일 구조가 다르게 나오고, 테스트가 느리게 실패하고, 요구사항이 생각보다 애매한 경우가 생긴다. 그때 마지막에 “알아서 마무리해줘”라고 두면 에이전트는 자기가 본 세계 안에서만 닫아 버린다.

내가 쓰는 표현은 대략 이런 식이다.

마지막 답변은 세 칸으로만 정리해줘.
1) 변경: 사용자 동작 기준으로 달라진 점
2) 검증: 실제로 실행한 명령/화면 확인과 결과
3) 위험: 아직 확인하지 못한 가정, 건드리지 않은 범위, 다음 확인 순서

이 문장은 프롬프트라기보다 작업 계약의 종료 조건에 가깝다. 중요한 건 “좋은 요약을 해줘”가 아니라 “내가 판단할 수 있는 증거의 모양으로 접어줘”라는 요구다. 특히 모바일 AI 빌더나 웹 기반 vibe coding 도구에서는 이 차이가 더 커진다. 프리뷰 화면이 예쁘게 뜨는 것과 기존 저장소에 안전하게 들어갈 수 있는 것은 별개의 문제다. 그래서 preview URL, 생성된 화면, 수동 확인 플로우를 종료 체크 안에 같이 넣어야 한다.

hook으로 자동화할 부분과 사람이 남길 부분

이 종료 체크는 나중에 hook이나 routine으로 일부 자동화할 수 있다. 예를 들어 마지막에 변경 파일 목록, 마지막 테스트 명령, 실패 로그 일부, 보호 경로 변경 여부를 자동으로 붙이는 식이다. 이런 정보는 사람이 매번 기억하기 어렵고, 에이전트도 긴 세션에서는 놓치기 쉽다. 자동으로 모아도 되는 정보는 바깥 레이어에 맡기는 편이 낫다.

다만 전부 자동화하면 또 다른 문제가 생긴다. “이 변경이 원래 의도와 맞는가”, “이 위험을 받아들이고 배포할 것인가”, “사용자에게 다시 물어야 하는가” 같은 판단은 아직 사람이 들고 있어야 한다. 그래서 나는 종료 체크를 자동 로그와 사람 판단의 접점으로 본다. hook은 증거를 모으고, 에이전트는 그 증거를 세 칸으로 접고, 사람은 그걸 보고 닫을지 되돌릴지 결정한다.

이 구조가 마음에 드는 이유는 단순하다. 에이전트에게 더 많은 말을 시키는 게 아니라, 마지막 말의 책임 범위를 좁힌다. 완료 답변이 “다 됐다”라는 선언으로 끝나면 내가 바로 믿거나 바로 의심하는 수밖에 없다. 반대로 변경·검증·위험으로 나뉘면, 나는 어느 칸이 비었는지만 보면 된다. 빈 칸은 다시 시키면 되고, 위험 칸이 크면 배포를 미루면 된다.

내가 실제로 보는 작은 신호들

종료 체크가 잘 된 세션은 마지막 답변에서 변명이 줄어든다. “아마”, “대체로”, “문제없을 것입니다” 같은 표현보다 구체적인 파일, 테스트 이름, 확인하지 못한 케이스가 나온다. 반대로 종료 체크가 실패한 세션은 좋은 말이 많고 증거가 적다. 특히 “필요하면 추가로 테스트할 수 있습니다”라는 문장만 있고 실제 실행 결과가 없으면, 나는 아직 끝난 것으로 보지 않는다.

또 하나 보는 신호는 위험 칸의 정직함이다. 에이전트가 남은 위험을 하나도 쓰지 못하면, 정말 위험이 없는 게 아니라 작업 표면을 충분히 읽지 못했을 가능성이 있다. 작은 변경이라도 대개는 확인하지 못한 폭, 느린 테스트, 배포 환경 차이, 사용자 입력의 경계값 같은 빈틈이 남는다. 그 빈틈을 말로 꺼내는 순간 작업은 더 느려 보이지만, 실제로는 다음 판단이 빨라진다.

그래서 나는 vibe coding에서 “잘 끝낸 작업”을 에이전트가 자신 있게 닫은 작업으로 보지 않는다. 사람이 이어받을 수 있을 만큼 증거가 정리된 작업으로 본다. 시작할 때 도구 계약서로 권한을 좁히고, 중간에 세션 스냅샷으로 기준을 접어 두고, 마지막에 종료 체크로 증거를 나누면 긴 세션도 덜 흐려진다. 거창한 방법론은 아니지만, 몇 번의 복구 시간을 줄여 준 뒤로는 거의 습관처럼 붙이고 있다.