긴 실패 로그보다 처음 달라진 줄

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

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

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

---

긴 실패 로그는 에이전트에게 생각보다 나쁜 지도처럼 작동한다. 마지막 stack trace만 크게 보이기 때문에, 정작 문제가 처음 틀어진 줄은 뒤로 밀린다. 나도 코딩 에이전트에게 “이 테스트가 실패한다”라고 통째로 던졌다가, 마지막 assertion 문구만 세 번 고치는 답을 받은 적이 있다. assertion은 결과였고, 원인은 훨씬 앞의 데이터 정규화 단계에서 행 수가 128개에서 0개로 줄어든 데 있었다.

긴 실패 로그를 전부 넘기기보다, 기준 로그와 현재 로그가 처음 갈라지는 줄을 먼저 표시해 주는 편이 수정 범위를 훨씬 줄인다.

요즘 내가 더 자주 쓰는 방식은 로그를 짧게 줄이는 것이 아니라, 처음 달라진 줄을 표시해서 넘기는 것이다. 이건 멋진 프롬프트 기법이라기보다 디버깅 입력을 다듬는 습관에 가깝다. 에이전트가 읽어야 할 범위는 남기되, 어떤 줄을 원인 후보로 봐야 하는지 손가락으로 짚어 주는 셈이다.

마지막 에러는 원인이 아닐 때가 많다

테스트 로그의 마지막 줄은 눈에 잘 띈다. `expected 128, got 0` 같은 문구는 분명하고, 실패한 파일명도 같이 나온다. 문제는 그 줄이 대부분 원인이 아니라 결과라는 데 있다. 에이전트에게 마지막 줄만 주면, 반환값을 맞추거나 assertion을 느슨하게 만드는 쪽으로 생각이 기울기 쉽다. 사람이 보면 “행이 왜 0개가 됐지?”라고 앞을 거슬러 올라가지만, 에이전트는 주어진 입력 안에서 가장 선명한 문장을 해결 대상으로 착각할 수 있다.

특히 리팩터링 뒤 실패한 테스트에서는 이 차이가 더 커진다. import 경로, fixture 이름, 필터 조건, 날짜 파싱, 빈 문자열 처리처럼 앞단의 작은 변화가 뒤쪽 assertion에서 터진다. 그래서 나는 긴 로그를 복사하기 전에 기준 실행과 현재 실행을 나란히 보고, 둘이 처음 달라지는 지점을 찾는다. 그 줄 하나가 있으면 대화의 방향이 “테스트를 고쳐 줘”에서 “왜 여기서 상태가 갈라졌는지 좁혀 줘”로 바뀐다.

내가 먼저 자르는 네 가지 입력

에이전트에게 넘길 때는 보통 네 가지를 붙인다. 첫째, 같은 명령을 기준 버전과 현재 버전에서 어떻게 실행했는지 적는다. 둘째, 기준 로그에서 정상으로 보이는 줄을 한 줄 남긴다. 셋째, 현재 로그에서 처음 달라진 줄을 붙인다. 넷째, 아직 고치지 말아야 할 영역을 짧게 적는다. 이 네 가지가 있으면 에이전트가 코드를 넓게 뒤지는 대신, 상태가 처음 갈라진 변환 단계를 먼저 확인하게 된다.

예를 들어 “테스트가 실패한다” 대신 “같은 fixture에서 build index 단계가 128 rows에서 0 rows로 바뀌었다. assertion 문구는 건드리지 말고, normalize keys 이후 필터 조건부터 확인해 달라”라고 말한다. 이렇게 쓰면 수정 요청이 더 길어진 것처럼 보이지만, 실제로는 탐색 범위가 줄어든다. 실패 로그 300줄보다 이 네 줄이 더 쓸모 있을 때가 많다.

비교 줄은 너무 똑똑하게 해석하지 않는다

처음 달라진 줄을 찾았다고 해서 그 줄을 바로 원인으로 확정하지는 않는다. 나는 그 줄을 원인이라기보다 탐색을 시작할 좌표로 본다. `0 rows`가 찍힌 줄은 필터가 문제일 수도 있고, 입력 fixture가 빈 값으로 바뀐 결과일 수도 있다. 그래서 요청에는 “이 줄이 원인이라고 단정하지 말고, 직전 단계의 입력과 출력 모양을 먼저 확인해 달라”는 문장을 붙인다.

이 작은 단서가 없으면 에이전트는 숫자가 달라진 줄을 바로 고치려 든다. 그러면 빈 배열을 허용하거나, 실패 조건을 바꾸거나, 임시 기본값을 넣는 식의 얕은 수정이 생긴다. 반대로 비교 줄을 좌표로만 주면, 수정 전에 어떤 상태를 더 읽어야 하는지 묻는 답이 나온다. 바이브코딩에서 내가 원하는 건 빠른 패치가 아니라, 패치가 놓일 위치를 먼저 좁히는 대화다.

말투는 분석 요청에 가깝게 둔다

여기서 중요한 건 바로 “고쳐라”로 시작하지 않는 것이다. 나는 먼저 “원인 후보를 두 개 이하로 좁혀 달라”거나 “수정 전에 어떤 파일을 읽을지 먼저 말해 달라”라고 시킨다. 수정 권한을 바로 열면 에이전트가 가장 가까운 failing test 파일로 뛰어들 수 있다. 반대로 분석 요청으로 시작하면 [[concepts/vibe-coding-read-edit-ratio]]에서 말한 read와 edit의 순서를 지키기가 쉬워진다.

이 방식은 [[concepts/agent-repro-command-handoff]]와도 잘 맞는다. 재현 명령은 “다시 열 첫 줄”이고, 처음 달라진 줄은 “어디부터 볼지”를 정해 준다. 둘을 같이 넘기면 다음 세션이나 다른 모델로 이어 갈 때도 설명이 덜 흔들린다. 긴 요약을 남기는 것보다, 재현 명령 하나와 갈라진 로그 한 줄이 더 빨리 작업을 되살릴 때가 있다.

비교가 안 되면 멈추는 편이 낫다

물론 항상 기준 로그가 남아 있는 건 아니다. 이럴 때 억지로 “아마 여기일 것”이라고 찍어서 넘기면 오히려 나쁜 힌트가 된다. 기준이 없으면 에이전트에게 바로 수정을 맡기기보다, 먼저 기준을 재현할 수 있는 작은 입력을 만들게 하는 편이 낫다. 샘플 fixture 하나, 이전 커밋의 실행 결과, 저장된 CI artifact 중 하나만 있어도 비교면이 생긴다.

비교면을 만들 수 없을 때는 그 사실 자체를 요청에 넣는다. “기준 로그가 없다. 먼저 현재 로그에서 상태가 바뀌는 후보 지점을 표시하고, 수정은 보류해 달라” 정도면 충분하다. 이 문장이 있으면 에이전트도 바로 patch를 만들지 않고 관찰 목록을 내놓을 가능성이 커진다. 바이브코딩에서 속도를 내는 것과, 확인되지 않은 원인 위에 수정을 쌓는 것은 다른 문제다.

나는 이 표시를 남긴 뒤에는 에이전트 답변도 짧게 검사한다. 답이 처음 달라진 줄보다 훨씬 뒤의 assertion만 고치고 있으면 중단시키고, 다시 앞 단계 관찰을 요구한다. 이 한 번의 중단이 나중에 생길 되돌림 비용을 꽤 줄여 준다.

작은 표시가 수정 반경을 줄인다

처음 달라진 줄을 표시하는 습관의 장점은 거창하지 않다. 다만 에이전트가 마지막 에러만 보고 달려드는 시간을 줄인다. 사람 입장에서도 “내가 무엇을 확인했고 무엇을 아직 모르는지”가 분리된다. 기준 줄, 현재 줄, 보류할 영역이 같이 있으면 수정 후 검증도 간단해진다. 같은 명령을 다시 돌려서 그 줄이 기준 쪽으로 돌아왔는지 보면 된다.

나는 이걸 실패 로그의 북마크처럼 생각한다. 긴 로그 전체를 버리는 게 아니라, 첫 갈림길에 작은 표시를 붙이는 것이다. 그 표시 하나가 있으면 에이전트와의 대화가 조금 덜 문학적이고, 조금 더 작업장에 가까워진다. 빠르게 고치는 척하는 답보다, 어디서부터 달라졌는지 먼저 보는 답이 결국 더 오래 남는다.

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

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