오래된 검증 로그가 만든 엉뚱한 재시도

시리즈: 바이브코딩 Tips #43

이전: 42편 | 목록 | 다음 없음

2026년 6월 29일 | 바이브코딩 Tips

---

에이전트가 가져온 성공 로그가 방금 실행한 결과인지 아닌지는 생각보다 자주 흐려진다. 대화 안에는 이전 실행의 통과 메시지, 중간에 고친 파일 목록, 다시 돌리겠다는 말이 같이 남는다. 사람은 대충 시간순으로 읽지만, 에이전트는 그중 가장 그럴듯한 줄을 근거로 삼을 때가 있다. 나는 이 장면을 몇 번 겪고 나서, 재시도 요청 앞에는 검증 로그의 신선도를 따로 확인하는 습관이 생겼다.

성공 로그를 그대로 믿기 전에 실행 시각, 입력 상태, 실패 위치, 판단 상태를 새로 맞춰 두면 엉뚱한 재시도를 줄일 수 있다.

로그에도 유통기한이 있다

코딩 에이전트와 일하다 보면 “테스트 통과했습니다”라는 문장 자체보다 그 문장이 언제 나온 것인지가 더 중요할 때가 있다. 같은 테스트 이름이라도 브랜치가 바뀌었고, 입력 파일이 바뀌었고, 환경변수가 바뀌었으면 이제 다른 증거다. 그런데 대화 맥락 안에서는 오래된 통과 로그가 방금 확인한 것처럼 보이기 쉽다. 특히 실패를 고친 직후에 다시 실패하면, 에이전트는 이전 PASS 줄과 새 traceback을 한 덩어리로 묶어 “거의 다 됐다”고 판단하기도 한다.

나는 여기서 작은 기준을 하나 둔다. 로그는 내용만으로는 근거가 아니고, 실행 시각과 입력 상태가 붙어야 근거다. 방금 돌린 명령인지, 같은 commit에서 나온 출력인지, 같은 샘플을 읽었는지까지 붙어 있지 않으면 일단 오래된 로그 후보로 본다. 이 기준이 있으면 에이전트의 자신감 있는 요약을 조금 덜 믿게 된다.

내가 먼저 보는 세 가지

재시도 전에 길게 회의를 하지는 않는다. 대신 세 가지를 작게 묻는다. 첫째, 이 로그가 몇 시 몇 분에 나온 결과인가. 둘째, 그때 입력과 지금 입력이 같은가. 셋째, 실패 위치가 마지막 에러 줄인지, 아니면 처음 달라진 줄인지. 이 세 가지가 비어 있으면 패치 방향을 정하기 전에 새 실행부터 해야 한다.

확인 칸	받고 싶은 답	멈출 신호
시간	방금 실행한 명령과 종료 시각	어느 실행인지 설명하지 못함
입력	branch, sample, config가 같은지	이전 샘플 기준 PASS를 재사용
위치	첫 divergence와 마지막 에러를 분리	마지막 traceback만 보고 가설 확정

이 표는 에이전트를 의심하기 위한 장치라기보다, 내가 오래된 근거를 새 근거처럼 읽지 않기 위한 장치에 가깝다. 사람도 같은 실수를 한다. 이미 한 번 통과한 줄이 눈에 남아 있으면, 새 실패가 그 통과 범위 밖에서 난 것인지 제대로 보지 않는다. 그래서 나는 “성공 로그가 있다”보다 “성공 로그가 아직 유효하다”를 따로 확인한다.

예를 들어 데이터 변환 스크립트를 고칠 때 이런 일이 자주 생긴다. 10분 전에는 sample_a.csv로 통과했고, 그 뒤에 컬럼 이름을 바꾸고 sample_b.csv를 넣었는데 대화에는 두 실행이 한 화면에 남는다. 에이전트가 “직전 테스트는 통과했으니 파서만 조금 조정하면 된다”고 말하면, 나는 먼저 어떤 직전인지 묻는다. sample_a의 통과는 sample_b의 실패를 설명하지 못한다. 같은 명령처럼 보여도 입력이 바뀌면 로그의 효력도 같이 바뀐다.

이 확인은 특히 여러 도구를 섞을 때 필요하다. 타입 체크는 최신인데 단위 테스트는 이전 commit일 수 있고, 로컬 재현은 최신인데 스크린샷은 예전 화면일 수 있다. 이 상태에서 에이전트가 하나의 결론으로 묶어 버리면, 사람은 어느 증거를 믿어야 하는지 다시 풀어야 한다. 그래서 나는 로그마다 작게라도 “현재 상태에서 나온 것”이라는 꼬리표를 붙이려고 한다.

새 실행 없이 결론을 내리지 않는 경우

특히 조심하는 상황이 몇 가지 있다. 설정 파일을 고친 뒤 같은 테스트를 다시 돌렸다고 말하지만 출력에 설정 파일 경로가 안 보이는 경우, 데이터 샘플을 바꿨는데 PASS 로그가 이전 샘플 이름을 가리키는 경우, 패키지를 새로 설치했는데 실패 로그가 설치 전 환경에서 난 경우다. 이런 때는 에이전트에게 바로 수정 방향을 묻지 않는다. 먼저 현재 상태에서 다시 실행한 짧은 증거를 요구한다.

여기서 새 실행은 전체 회귀 테스트를 뜻하지 않는다. 가끔은 파일 존재 확인, 샘플 세 줄 출력, 특정 함수 한 번 호출, 마지막 명령 재실행 정도면 충분하다. 중요한 것은 최신 상태와 붙은 작은 증거다. 오래된 큰 PASS보다 최신 작은 확인이 더 나을 때가 많다. 큰 로그는 멋있지만, 틀린 시점의 큰 로그는 판단을 더 흐린다.

에이전트에게 넘기는 짧은 문장

내가 자주 쓰는 요청은 길지 않다. 핵심은 재시도를 금지하는 것이 아니라, 재시도 전에 근거를 새로 고정하게 하는 것이다.

이전 PASS 로그를 근거로 결론 내리지 말고,
현재 branch와 현재 sample에서 같은 명령을 다시 실행해줘.
출력은 time / command / input / first_changed_line / decision 형식으로만 줘.
decision은 ACCEPT, REFRESH, HOLD 중 하나로 닫아줘.

이 문장을 넣으면 답변이 조금 덜 화려해진다. 대신 판단이 빨라진다. ACCEPT면 지금 로그를 근거로 진행하고, REFRESH면 새 실행이 필요하고, HOLD면 사람이 봐야 한다. “아마 됩니다”와 “거의 맞습니다” 사이에서 오래 머무르지 않아도 된다. 에이전트에게 필요한 것은 자신감 있는 요약이 아니라, 지금 이 결과를 믿어도 되는지에 대한 작은 상태값이다.

나는 여기서 REFRESH를 실패로 보지 않는다. 오히려 좋은 답에 가깝다. 현재 증거가 부족하다는 사실을 빨리 인정하면, 엉뚱한 패치를 하나 더 쌓지 않아도 된다. ACCEPT보다 REFRESH가 나오는 순간이 더 믿음직할 때도 있다. 재실행 비용은 작지만, 오래된 로그를 근거로 한 수정은 다음 판단까지 흐릴 수 있기 때문이다. 특히 긴 대화에서는 이 한 줄이 다음 사람에게 넘길 설명서 역할도 한다. 어느 로그를 버렸고 어느 로그를 다시 만든 것인지 남아 있으면, 다음 수정은 훨씬 짧게 시작된다.

빠른 재시도보다 작은 새 증거

바이브코딩에서 속도는 분명 장점이다. 그런데 빠른 재시도가 항상 빠른 해결로 이어지지는 않는다. 오래된 로그를 붙잡고 다시 고치면, 패치가 하나 더 생기고 실패도 하나 더 생긴다. 그러면 다음 에이전트는 더 긴 맥락을 받아야 하고, 사람은 어느 로그가 최신인지 다시 정리해야 한다. 나는 이 비용이 꽤 크다고 본다.

그래서 작은 작업일수록 최신 증거 한 줄을 아낄 이유가 없다. 방금 실행한 명령, 같은 입력, 처음 달라진 줄, 세 가지 판단 중 하나. 이 정도만 있어도 재시도는 훨씬 덜 흔들린다. 에이전트가 빠르게 움직일수록, 나는 오래된 확인 로그를 한 번 더 의심한다. 최신 로그를 만드는 데 30초가 걸려도, 잘못된 재시도 하나를 줄이면 그쪽이 훨씬 싸다. 나는 그 시간을 재시도 비용이 아니라 방향 확인 비용으로 본다.

시리즈: 바이브코딩 Tips #43

이전: 42편 | 목록 | 다음 없음