<!doctype html>
2026년 6월 23일 | 바이브코딩 Tips
실패 로그만 길게 붙이면 코딩 에이전트는 대체로 마지막 줄부터 잡는다. 마지막 줄이 실제 원인일 때도 있지만, 실무에서는 그렇지 않은 경우가 더 많았다. 빌드 로그의 마지막은 실패를 출력한 위치이고, 원인은 그보다 훨씬 앞의 입력·환경·옵션에 숨어 있을 수 있다. 나는 예전에는 “이 로그 보고 고쳐줘”라고 많이 던졌는데, 그렇게 시작한 세션은 수정 범위가 빠르게 넓어졌다.
요즘은 로그를 붙일 때 다시 돌릴 명령, 기대하는 실패 문구, 건드려도 되는 범위를 같이 적는다. 이 세 가지가 붙으면 에이전트가 로그를 해석하는 방식이 달라진다. 실패를 설명하는 글을 쓰는 대신, 같은 실패를 다시 만들고 그 실패가 사라졌는지 확인하는 쪽으로 움직인다. 바이브코딩에서 이 차이는 꽤 크다. 속도를 내는 것보다 먼저 실패의 주소를 잃지 않는 일이 필요하다.
마지막 줄만 보면 방향이 좁아진다
긴 로그를 보면 사람도 마지막 에러 메시지에 끌린다. 에이전트는 더 그렇다. `TypeError`, `Timeout`, `Module not found` 같은 문구가 맨 아래에 있으면 곧바로 그 단어를 중심으로 수정을 제안한다. 그런데 실제로는 fixture가 비어 있었거나, 이전 테스트가 상태를 남겼거나, 실행 옵션이 다른 환경을 가리키는 경우가 있다. 마지막 줄은 증상이지 항상 원인은 아니다.
그래서 나는 로그를 붙일 때 “마지막 줄을 고치라”는 신호를 줄이려고 한다. 대신 같은 실패를 다시 만드는 절차를 앞에 둔다. 에이전트가 먼저 명령을 따라가면, 로그의 어느 부분이 재현 경로에서 생긴 것인지 확인하게 된다. 이때부터 대화의 중심이 에러 문자열에서 실패를 다시 만드는 조건으로 옮겨 간다.
재현 명령은 실패의 주소다
재현 명령은 거창한 테스트 스위트가 아니다. 내가 실제로 실패를 봤던 가장 작은 실행 단위면 충분하다. 특정 테스트 파일 하나, 특정 옵션 하나, 특정 입력 파일 하나면 된다. 중요한 것은 에이전트가 “어디서부터 봐야 할지”를 추측하지 않게 하는 것이다. 추측이 줄어들면 첫 수정도 작아진다.
내가 로그 위에 붙이는 형식
재현 명령: pnpm test -- auth/session-timeout.spec.ts
기대 실패: session refresh 뒤 redirect가 두 번 발생한다
수정 범위: auth middleware와 session store만 먼저 본다이렇게 적으면 에이전트는 “전체 인증 구조를 개선하자”로 바로 뛰지 못한다. 먼저 지정된 명령을 기준으로 실패를 다시 확인해야 한다. 실패가 재현되지 않으면 환경 차이를 묻고, 재현되면 지정된 범위 안에서 원인을 찾는다. 이 작은 제약이 없으면 로그 하나가 리팩터링 제안으로 번지는 일이 자주 생긴다.
기대 실패 문구를 같이 둔다
명령만 남기면 또 다른 문제가 생긴다. 같은 명령 안에서도 여러 실패가 날 수 있다. 의존성 설치가 안 됐을 수도 있고, 스냅샷이 달라졌을 수도 있고, 내가 보려던 실패와 무관한 lint가 먼저 터질 수도 있다. 이때 기대 실패 문구를 같이 두면 에이전트가 “지금 본 실패가 원래 문제인가”를 먼저 비교한다.
나는 여기서 완벽한 문구 일치를 요구하지 않는다. 대략 어떤 화면, 어떤 assertion, 어떤 응답 코드가 핵심인지 적는다. 예를 들어 “redirect가 두 번 발생한다”, “빈 배열에서 fallback 문구가 사라진다”, “한국어 파일명 업로드 때 경로가 깨진다”처럼 쓴다. 그러면 다른 실패가 먼저 뜰 때도 작업이 엉뚱한 방향으로 가지 않는다. 기대 실패는 로그의 목적지를 표시하는 작은 표지판이다.
수정 범위를 한 번 더 묶는다
실패를 재현해도 수정 범위가 넓으면 바이브코딩 세션은 금방 무거워진다. 인증 실패를 본다고 해서 로그인 화면, 라우터, 토큰 저장소, API 클라이언트, 테스트 fixture를 전부 열 필요는 없다. 처음에는 의심 범위를 작게 잡고, 그 범위에서 설명이 안 될 때만 넓히는 편이 낫다. 에이전트에게도 이 순서를 명시해야 한다.
내가 자주 쓰는 말은 “먼저 A와 B만 보고, 안 나오면 C로 넓힌다”이다. 이 문장은 단순하지만 효과가 있다. 에이전트가 첫 턴에서 전체 구조를 다시 설계하지 못하게 막고, 사람이 확인할 diff도 작게 남긴다. 실패 로그를 붙이는 순간에는 이미 마음이 급한데, 그럴수록 수정 반경을 좁히는 문장이 필요하다.
내가 확인하는 작은 표
| 붙일 것 | 좋은 상태 | 흔한 실패 |
|---|---|---|
| 재현 명령 | 한 번에 다시 실행할 수 있는 파일·옵션이 있다. | “로그 보고 판단”만 남고 시작점이 없다. |
| 기대 실패 | 원래 보려던 증상이 한 문장으로 적혀 있다. | 다른 실패가 나도 같은 문제로 착각한다. |
| 수정 범위 | 처음 열 파일과 넓힐 조건이 분리돼 있다. | 원인 찾기 전에 리팩터링이 시작된다. |
이 표를 매번 길게 채우지는 않는다. 하지만 실패 로그를 에이전트에게 넘길 때 세 칸 중 하나라도 비어 있으면 한 번 멈춘다. 로그는 이미 충분히 길다. 더 필요한 것은 설명이 아니라 주소다. 같은 실패를 다시 만들 수 있고, 원래 보려던 증상을 구분할 수 있고, 첫 수정 범위가 작게 묶여 있으면 다음 세션은 훨씬 덜 흔들린다. 나는 그 상태에서야 “이제 고쳐줘”라는 말을 조금 더 편하게 한다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 패치 제안 옆의 검증 표 (0) | 2026.06.25 |
|---|---|
| 완료 보고 옆의 결과 파일 (0) | 2026.06.24 |
| 컨텍스트 압축 직전의 기준선 세 줄 (0) | 2026.06.22 |
| 미확인 영역이 보이는 완료 보고 (0) | 2026.06.19 |
| 긴 실패 로그보다 처음 달라진 줄 (0) | 2026.06.17 |