<!doctype html>
2026년 6월 3일 | 바이브코딩 Tips
코딩 에이전트가 파일을 고치기 시작할 때 내가 제일 먼저 보는 것은 답변의 자신감이 아니라, 방금 읽은 파일 목록이다. 말은 그럴듯한데 실제로는 에러 로그 한 줄만 보고 전체 구조를 짐작한 뒤 수정에 들어가는 경우가 꽤 있다. 이때 결과가 바로 깨지면 차라리 낫다. 더 피곤한 쪽은 작은 테스트 하나만 통과하고, 며칠 뒤 다른 경로에서 어긋나는 수정이다.
그래서 요즘은 에이전트에게 바로 “고쳐줘”라고 던지기보다, 먼저 수정 전에 읽은 근거를 밖으로 꺼내게 하는 편이 훨씬 안정적이라고 느낀다. 거창한 리서치 보고서가 필요하다는 뜻은 아니다. 이번 작업과 관련해 본 파일, 로그, 설정, 문서가 무엇인지 짧게 적고, 그중 어떤 항목 때문에 어느 파일을 고치려는지 연결해 달라는 정도면 충분하다. 이 작은 한 단계가 없으면 사람도 에이전트도 너무 빨리 결론으로 뛰어간다.
읽기 목록은 장식이 아니라 작업 계약
내가 쓰는 가장 단순한 형식은 세 줄이다. 첫째, “읽은 것”에는 파일명만 쓰지 않고 왜 봤는지까지 적는다. 둘째, “이 근거로 고칠 곳”에는 수정 후보를 한두 군데로 좁힌다. 셋째, “아직 안 본 것”에는 건드리지 않은 모듈이나 테스트를 남긴다. 이 세 줄이 있으면 에이전트가 갑자기 옆 디렉터리까지 손대는 일을 꽤 줄일 수 있다.
이 방식의 장점은 사람이 중간에 끼어들기 쉽다는 데 있다. 에이전트가 “A 로그를 보고 B 파일을 고치겠다”고 쓰면, 나는 B가 아니라 C를 먼저 봐야 한다고 바로 말할 수 있다. 반대로 읽은 목록이 없으면 수정이 끝난 뒤에야 “왜 거길 고쳤지?”를 묻게 된다. 그때는 이미 diff가 생겼고, 되돌림도 검증도 더 비싸다.
read:edit 비율을 숫자보다 흐름으로 보기
read:edit 비율을 엄밀한 KPI처럼 관리하려고 하면 금방 피곤해진다. 작업마다 적정 비율이 다르고, 작은 CSS 수정과 인증 버그 추적을 같은 숫자로 비교할 수는 없다. 그래도 흐름은 꽤 잘 보인다. 읽기는 거의 없는데 edit만 계속 늘어나는 순간, 에이전트가 문제를 이해했다기보다 앞선 답변의 모양을 유지하려고 움직이는 경우가 많았다.
특히 긴 세션에서는 이 신호가 더 중요하다. 처음에는 로그를 잘 읽고 시작했더라도, 중간에 요구사항이 추가되고 컨텍스트가 압축되고 실패가 몇 번 반복되면 어느 순간 수정 근거가 흐려진다. 그때 “계속 진행” 대신 “지금까지 읽은 근거와 아직 안 본 영역을 다시 접어줘”라고 요구하면 세션이 다시 작아진다. 나는 이걸 일종의 숨 고르기 지점으로 쓴다.
바로 쓰는 미니 프롬프트
실제로는 길게 말하지 않는다. “수정 전에 읽은 파일 목록을 먼저 줘. 각 항목마다 왜 봤는지 한 줄로 적고, 그 근거로 고칠 파일을 최대 두 개만 제안해. 아직 확인하지 않은 영역도 따로 적어.” 이 정도면 된다. 여기서 핵심은 에이전트의 답을 예쁘게 만드는 것이 아니라, 수정 권한을 읽기 근거에 묶는 것이다.
프론트엔드 작업이라면 여기에 preview나 스크린샷 확인을 붙인다. 백엔드 작업이라면 실패 로그와 재현 명령을 붙인다. 데이터 파이프라인이라면 샘플 입력과 출력 차이를 붙인다. 분야마다 붙는 증거는 다르지만, 순서는 비슷하다. 먼저 읽은 것을 밖으로 꺼내고, 그다음 좁게 고치고, 마지막에 무엇을 확인했고 무엇을 못 봤는지 남긴다.
읽은 목록을 요구할 때 조심할 점
읽은 파일 목록을 남기게 한다고 해서, 에이전트에게 모든 파일을 훑으라고 시키면 또 다른 문제가 생긴다. 컨텍스트가 불어나고, 핵심 파일보다 주변 설명을 더 많이 들고 오면서 정작 수정 판단이 흐려진다. 그래서 나는 “많이 읽기”보다 “먼저 읽을 곳을 제한하고, 더 필요하면 확장 요청하기”에 가깝게 쓴다. 처음 계약은 보통 중심 파일 2개, 관련 테스트 1개, 실패 로그 1개 정도면 충분하다.
또 하나는 읽은 목록을 면피용 문서로 만들지 않는 것이다. 에이전트가 파일명만 줄줄이 나열하면 사람 입장에서는 좋아 보이지만, 실제 판단에는 별 도움이 안 된다. 내가 원하는 것은 “무엇을 봤다”가 아니라 “그걸 보고 어떤 가정을 세웠다”이다. 예를 들어 설정 파일을 봤다면 어떤 옵션 때문에 실행 경로를 의심하는지, 테스트 파일을 봤다면 어떤 케이스가 빠져 있다고 보는지까지 붙어야 한다.
이렇게 쓰면 수정 전 단계가 조금 느려 보인다. 그런데 실제로는 전체 시간이 줄어드는 날이 많았다. 근거 없는 첫 diff를 만들고, 그 diff를 되돌리고, 다시 로그를 읽고, 다른 파일까지 만지는 흐름보다 처음 3분 동안 읽은 흔적을 정리하는 쪽이 덜 비싸다. 특히 다른 사람이 이어받을 수 있는 작업이면 이 차이가 더 크게 난다.
내가 자주 쓰는 판정 기준
답변을 받았을 때 나는 세 가지를 본다. 읽은 목록에 실패를 재현하는 단서가 있는지, 수정 후보가 읽은 근거와 직접 연결되는지, 미확인 영역이 따로 남아 있는지다. 세 가지가 모두 보이면 바로 작은 수정을 허용한다. 하나라도 빠지면 아직 edit으로 넘어가지 않고 읽기 범위를 다시 좁힌다.
이 기준은 에이전트에게만 쓰는 게 아니다. 내가 직접 급하게 고칠 때도 비슷하게 흔들린다. 에러 메시지 하나를 보고 예전 기억으로 파일을 열고, 익숙한 위치를 고치고, 테스트가 한 번 통과하면 끝났다고 착각한다. 읽은 목록을 쓰게 하는 습관은 에이전트를 통제하는 동시에, 내 판단이 너무 빨라지는 것도 잡아 준다.
작업을 맡길 때는 이 목록을 완벽한 문서로 만들 필요가 없다. 오히려 너무 정돈된 보고서보다, 지금 판단에 필요한 짧은 근거가 더 낫다. “이 로그 때문에 이 함수가 의심된다”, “이 테스트는 봤지만 모바일 경로는 아직 안 봤다” 정도의 투박한 문장이면 충분하다. 그 정도만 남아도 다음 지시는 훨씬 구체적이 된다. 에이전트가 다시 길을 잃었을 때도 이 문장들이 작은 지도 역할을 한다. 어디서 판단이 갈라졌는지 보이면, 프롬프트를 다시 길게 쓰지 않고도 읽기 범위만 조정해 재시작할 수 있다.
끝났다는 말보다 확인 영수증
에이전트가 “완료했습니다”라고 말하는 순간에도 나는 같은 기준을 한 번 더 쓴다. 어떤 파일을 읽고 고쳤는지, 어떤 검증을 실제로 돌렸는지, 남은 위험이 무엇인지가 보이면 그 답변은 꽤 믿을 만하다. 반대로 수정 결과만 있고 읽은 근거와 미확인 영역이 없으면, 아무리 말투가 확신 있어도 다음 세션에서 다시 열어 봐야 한다.
결국 이 팁은 에이전트를 더 똑똑하게 만드는 비법이라기보다, 내가 덜 속도록 작업 표면을 바꾸는 방법에 가깝다. 수정 전 읽은 파일 목록을 남기게 하면 에이전트의 추론이 완벽해지지는 않는다. 대신 잘못 읽은 부분, 안 읽은 부분, 너무 빨리 고치려는 부분이 눈에 보인다. 바이브코딩에서 이 정도만 보여도 실패를 꽤 일찍 끊을 수 있다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 상태 차이부터 넘기기 (0) | 2026.06.05 |
|---|---|
| 반복 작업은 실행 조건까지 묶기 (0) | 2026.06.04 |
| 모델을 바꿔 이어 갈 때 남길 것 (0) | 2026.06.02 |
| 같은 지시를 세 번 밀지 않기 (0) | 2026.05.29 |
| 출력 형태부터 정하고 도구를 맡기기 (0) | 2026.05.27 |