<!doctype html>
2026년 6월 24일 | 바이브코딩 Tips
코딩 에이전트가 “완료했습니다”라고 말했는데, 막상 내가 다시 열어야 할 파일이 어디인지 바로 안 보일 때가 있다. diff는 바뀌었고 테스트도 통과했다는데, 생성된 리포트가 어느 경로에 있는지, 스크린샷은 어떤 파일인지, 중간에 만든 표는 남길 것인지 버릴 것인지가 흐려진다. 이럴 때 나는 대화 기록을 위아래로 다시 훑는다. 빠른 작업처럼 보였던 세션이 마지막 5분에 갑자기 느려진다.
그래서 요즘은 완료 보고를 받을 때 바뀐 코드, 결과 파일, 검증 기록을 한 덩어리로 묶어 달라고 한다. 파일 목록을 길게 달라는 뜻은 아니다. 사람이 다음에 바로 열어야 하는 산출물만 보이게 하자는 쪽에 가깝다. 바이브코딩에서는 코드 수정 자체보다, 그 수정이 만든 흔적을 잃지 않는 일이 의외로 중요했다.
완료 문장만으로는 다시 열 수 없다
작업이 작을 때는 “고쳤다”는 말로도 충분해 보인다. 버튼 문구 하나, 파서 조건 하나, 테스트 fixture 하나 정도면 내가 기억할 수 있을 것 같다. 그런데 세션이 두세 턴만 길어져도 상황은 바뀐다. 에이전트가 임시 JSON을 만들고, 실패 화면을 캡처하고, 비교 표를 저장하고, 마지막에는 그중 일부만 실제 결과로 남긴다. 이때 완료 보고가 자연어 요약으로만 끝나면, 나는 어떤 파일을 믿어야 하는지 다시 물어보게 된다.
내가 원하는 것은 친절한 장문 요약보다 작다. “최종 결과는 이 파일”, “검증 로그는 이 명령의 출력”, “임시 파일은 버려도 됨” 같은 짧은 표시다. 이 표시가 있으면 다음 세션이 시작될 때 대화 전체를 복원하지 않아도 된다. 결과 파일이 바로 보이면, 나는 에이전트의 말이 아니라 남아 있는 산출물을 기준으로 판단할 수 있다.
코드 파일과 결과 파일을 나눠 받는다
에이전트에게 “변경 파일을 알려줘”라고만 하면 보통 소스 코드 파일이 먼저 나온다. 물론 그 정보도 필요하다. 하지만 내가 실제로 확인하는 것은 코드 파일만이 아니다. 생성된 CSV, 실패 케이스 표, 화면 캡처, 성능 비교 PNG, 짧은 마크다운 리포트가 더 중요할 때도 많다. 코드는 원인이고, 결과 파일은 내가 눈으로 확인할 수 있는 증거다.
내가 마지막 답변에 붙이는 요청
변경 파일: 실제로 수정한 코드와 설정
결과 파일: 사람이 열어 확인해야 하는 표, 이미지, 리포트
검증 기록: 돌린 명령과 통과/미확인 범위이 세 줄을 요구하면 보고의 결이 달라진다. “수정 완료”라는 말이 “무엇을 열어 보면 되는가”로 바뀐다. 특히 결과 파일 칸은 생각보다 많은 것을 걸러 준다. 정말 남길 산출물이 없으면 없다고 적으면 된다. 반대로 산출물이 있는데 경로를 적지 못한다면, 그 작업은 아직 사람에게 넘길 준비가 덜 된 상태일 수 있다.
임시 산출물도 상태를 붙인다
작업 중간에 만든 파일은 애매하다. 어떤 것은 최종 결과고, 어떤 것은 디버깅용이고, 어떤 것은 다시 만들 수 있는 캐시다. 이 구분 없이 폴더에 남겨 두면 다음번에 같은 파일이 근거처럼 보인다. 예전에 나는 오래된 비교표를 최신 결과로 착각해서 한 번 더 확인한 적이 있다. 파일은 남아 있었지만 상태가 없었다.
그래서 결과 파일 칸에는 경로만 쓰지 않고 상태를 같이 붙이는 편이 낫다. “최종 리포트”, “검증용 스크린샷”, “재생성 가능”, “삭제 후보”처럼 짧게 붙이면 된다. 이 네 단어만 있어도 다음 사람이 파일을 여는 방식이 달라진다. 파일의 존재와 파일의 역할은 다르다. 역할을 적지 않으면, 임시 산출물이 다음 판단을 오염시키기 쉽다.
검증 기록은 산출물의 유효기간이다
결과 파일이 있어도 언제, 어떤 조건에서 만들어졌는지 모르면 금방 낡는다. 테스트 데이터가 바뀌었거나, 옵션이 달랐거나, seed가 다르면 같은 파일명도 다른 의미가 된다. 그래서 나는 결과 파일 옆에 검증 기록을 붙인다. 거창한 로그 전체가 아니라, 어떤 명령을 돌렸고 무엇을 아직 못 봤는지 정도면 충분하다.
예를 들어 “summary.csv 생성”이라고만 쓰면 다음에 다시 읽을 때 애매하다. “summary.csv, sample 20건, timeout 케이스는 미확인”처럼 적으면 훨씬 낫다. 파일이 가진 증거 범위가 보이기 때문이다. 이 한 줄이 있으면 나는 결과 파일을 과신하지 않고, 필요한 부분만 다시 돌릴 수 있다. 완료 보고의 목적은 확신을 크게 만드는 것이 아니라, 다음 확인을 작게 만드는 데 있다.
내가 보는 작은 체크표
| 칸 | 좋은 상태 | 불안한 상태 |
|---|---|---|
| 변경 파일 | 수정한 코드와 설정이 범위별로 묶여 있다. | 파일명만 길게 나열되고 사용자 영향이 없다. |
| 결과 파일 | 최종/임시/삭제 후보 상태가 함께 붙어 있다. | 어떤 산출물을 열어야 하는지 다시 물어봐야 한다. |
| 검증 기록 | 명령, 입력 범위, 미확인 조건이 한 줄로 보인다. | “테스트 통과”만 있고 어떤 조건인지 알 수 없다. |
이 표를 매번 형식적으로 채우지는 않는다. 다만 에이전트가 파일을 만들었거나, 실험 결과를 저장했거나, 화면 캡처를 남겼다면 최소한 한 번은 확인한다. 완료 보고는 말로 닫히지만, 작업은 보통 파일로 남는다. 그 파일이 어디에 있고, 어떤 상태이고, 어떤 검증 아래에서 생겼는지 보이면 다음 요청이 훨씬 작아진다. 나는 이 작은 영수증이 있어야 마음 놓고 다음 세션으로 넘어간다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 삭제 패치 앞의 보존 샘플 (0) | 2026.06.26 |
|---|---|
| 패치 제안 옆의 검증 표 (0) | 2026.06.25 |
| 실패 로그 옆의 재현 명령 (0) | 2026.06.23 |
| 컨텍스트 압축 직전의 기준선 세 줄 (0) | 2026.06.22 |
| 미확인 영역이 보이는 완료 보고 (0) | 2026.06.19 |