<!doctype html>
2026년 7월 1일 | 바이브코딩 Tips
에이전트가 “수정 완료”라고 말했는데 diff가 비어 있으면, 나는 성공보다 먼저 작업트리를 의심한다. 실제로는 세 가지가 섞여 있을 때가 많다. 애초에 바꿀 것이 없었던 경우, 에이전트가 다른 경로를 보고 있었던 경우, 그리고 수정은 했지만 검증 전에 다시 되돌아간 경우다. 셋 다 화면에서는 비슷하게 보이는데, 다음 행동은 완전히 다르다.
완료 문장과 작업트리는 따로 본다
코딩 에이전트를 쓰다 보면 “반영했습니다”라는 문장은 꽤 빨리 나온다. 문제는 그 문장이 실제 변경 파일을 보장하지 않는다는 데 있다. 에이전트가 설명을 잘했다고 해서 같은 작업트리에서 edit이 일어났다는 뜻은 아니다. 특히 여러 터미널, 임시 복사본, 생성 파일, ignore된 디렉터리가 끼면 완료 문장은 더 쉽게 뜨고 diff는 비어 있을 수 있다.
그래서 나는 완료 보고를 받을 때 먼저 diff가 있는지와 diff가 비어 있다면 왜 비어 있는지를 분리한다. “변경 없음”이라는 사실 자체는 나쁘지 않다. 나쁜 쪽은 변경 없음의 이유가 없는 상태다. 이미 원하는 상태였는지, 조건이 맞지 않아 스킵됐는지, 아니면 엉뚱한 작업공간에서 손을 댔는지를 모르면 다음 프롬프트가 바로 추측으로 넘어간다.
빈 diff는 다섯 갈래로 나눈다
내가 자주 보는 갈래는 다섯 개다. 첫째, 이미 반영되어 있어서 새 diff가 없는 경우. 둘째, 에이전트가 읽기만 하고 수정 권한이나 조건에서 멈춘 경우. 셋째, 다른 branch나 다른 checkout에서 바꾼 경우. 넷째, 생성 파일이나 캐시처럼 추적되지 않는 곳만 바뀐 경우. 다섯째, 수정 후 formatter나 복구 로직이 원래 모양으로 되돌린 경우다.
이 다섯 갈래를 구분하지 않고 “한 번 더 해봐”라고 던지면 대체로 일이 커진다. 이미 반영된 상태에 또 패치를 얹거나, 다른 경로에서 만든 변경을 현재 경로에 맞는 것처럼 설명하거나, 실제 원인은 권한인데 코드만 계속 고친다. 빈 diff가 보이면 바로 재시도하기보다 비어 있는 이유를 먼저 한 문장으로 받는 것이 낫다.
한 번은 문서 생성 경로를 고치는 작업에서 이 신호를 늦게 봤다. 에이전트는 템플릿을 수정했다고 했지만 현재 checkout의 diff는 비어 있었다. 알고 보니 예전 임시 폴더에서 같은 이름의 파일을 보고 있었고, 실제 배포 경로에는 아무 변화가 없었다. 그 뒤로는 완료 문장보다 작업트리 위치와 변경 파일 수를 먼저 본다. 이 작은 확인 하나가 같은 설명을 두 번 듣는 시간을 실제로 꽤 줄여 준다.
에이전트에게 남기는 네 줄
요즘은 완료 직후에 긴 요약을 요구하지 않고 네 줄만 남긴다. 기대 변경, 실제 diff, 확인 신호, 다음 행동이다. 기대 변경에는 바뀌어야 했던 파일이나 사용자 동작을 적는다. 실제 diff에는 변경 파일 수와 비어 있는 이유를 적는다. 확인 신호에는 테스트, 화면, 로그 중 실제로 본 것을 넣는다. 다음 행동은 재시도, HOLD, 그대로 종료 중 하나로 고른다.
이 네 줄은 거창한 프로세스라기보다, 완료 보고의 모양을 조금 좁히는 장치다. “수정 완료”라고만 쓰면 사람은 다시 확인해야 할 표면을 처음부터 찾아야 한다. 반대로 “diff 0, 이유: 이미 동일 상태, 확인: 대상 함수와 테스트 로그, 다음 행동: 종료”처럼 쓰면 빈 diff도 판단 가능한 결과가 된다.
예를 들면 이렇게 쓴다. “기대 변경: 결과 저장 버튼을 누른 뒤 summary.json이 갱신되어야 함. 실제 diff: 추적 파일 0개, 생성 디렉터리에도 새 파일 없음. 확인 신호: 저장 로그는 성공으로 보였지만 현재 작업트리에는 산출물이 없음. 다음 행동: HOLD, 저장 경로를 먼저 다시 확인.” 이 정도면 에이전트가 다시 움직이더라도 무엇을 고쳐야 하는지보다 어디를 확인해야 하는지가 먼저 보인다.
반대로 빈 diff가 정상인 경우도 있다. 이미 같은 패치가 들어가 있었거나, 설정값이 목표 상태와 같거나, 테스트가 기존 코드로도 통과하는 경우다. 이때는 “수정할 게 없었다”는 결론 자체가 결과가 된다. 다만 그 결론에도 근거가 필요하다. 대상 파일의 현재 값, 관련 테스트 한 줄, 사용자가 기대한 동작과 현재 동작이 같다는 확인이 같이 붙어야 마음 편하게 닫을 수 있다.
내가 싫어하는 답은 “이미 반영된 것으로 보입니다” 같은 문장이다. 보인다는 말은 편하지만, 다음 세션에서 다시 열면 아무것도 남지 않는다. 그래서 빈 diff가 나왔을 때는 추측형 문장보다 확인형 문장을 요구한다. “현재 파일의 해당 값이 이미 true라서 변경 없음”처럼 쓸 수 있으면 종료하고, 그렇게 못 쓰면 아직 끝난 게 아니다.
이 습관은 작은 수정에서 더 잘 먹힌다. 큰 리팩터링은 어차피 diff가 크게 남지만, 설정 한 줄이나 템플릿 한 줄은 빈 diff와 성공 diff의 차이가 눈에 잘 안 들어온다. 작은 작업일수록 완료 문장보다 변경 파일 수, 경로, 확인 신호를 먼저 붙이는 편이 덜 흔들린다. 이 줄이 있어야 나중에 같은 자동 수정을 다시 열 때도 어디서 멈췄는지 바로 보인다.
재시도보다 HOLD가 싼 순간
빈 diff가 나왔는데 이유가 애매하면 나는 바로 HOLD로 둔다. HOLD는 실패 판정이 아니다. 에이전트가 한 번 더 움직이기 전에 작업공간과 기대 변경을 다시 맞추자는 표시다. 특히 파일 경로가 비슷한 프로젝트, 생성물이 많은 프런트엔드, 테스트 fixture가 여러 군데 있는 저장소에서는 HOLD 한 번이 재시도 세 번보다 싸다.
여기서 중요한 건 “검증을 더 많이 하자”가 아니라 검증 위치를 먼저 맞추자는 점이다. 작업트리가 맞고, 기대 변경도 맞고, diff가 비어 있는 이유까지 맞으면 그때는 정말 변경이 필요 없는 상태일 수 있다. 반대로 셋 중 하나라도 흐리면, 다음 수정은 새 기능 개발이 아니라 위치 찾기부터 다시 시작해야 한다.
내가 실제로 쓰는 짧은 문장
내가 에이전트에게 자주 붙이는 문장은 이렇다. “완료라고 말하기 전에 기대 변경과 실제 diff를 나눠서 써 줘. diff가 비어 있으면 그 이유를 다섯 갈래 중 하나로 분류하고, 확인한 명령이나 파일 한 줄을 붙여 줘.” 이 정도만 넣어도 에이전트의 답이 묘하게 달라진다. 자신감 있는 문장이 줄고, 대신 사람이 확인할 수 있는 표면이 생긴다.
바이브코딩에서 제일 피곤한 순간은 에이전트가 틀리는 때보다, 맞았는지 틀렸는지 모르는 상태가 길어질 때다. 빈 diff는 그 상태를 꽤 빨리 알려 주는 신호다. 나는 이제 빈 diff를 무조건 실패로 보지도 않고, 성공으로 넘기지도 않는다. 그냥 완료 문장과 작업트리를 분리해서 보고, 이유가 붙을 때만 다음 단계로 넘긴다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 중단된 작업의 기준선과 미확인 영역 (0) | 2026.07.04 |
|---|---|
| 테스트 파일까지 바뀐 diff의 경계선 (0) | 2026.07.02 |
| 오래된 검증 로그가 만든 엉뚱한 재시도 (0) | 2026.06.29 |
| 원본 줄이 빠진 패치 리뷰 (0) | 2026.06.28 |
| 종료 코드가 빠진 에이전트 재시도 (0) | 2026.06.27 |