<!doctype html>
2026년 6월 22일 | 바이브코딩 Tips
긴 코딩 에이전트 세션은 대화가 길어질수록 이상하게 조용해진다. 처음에는 내가 무엇을 바꾸고 싶은지, 어느 파일은 건드리면 안 되는지, 어떤 테스트를 믿고 있는지 꽤 선명하다. 그런데 중간에 로그가 쌓이고, 작은 수정이 몇 번 지나가고, 모델이 요약을 한 번 끼워 넣는 순간부터 기준이 흐려진다. 나는 이때 예전처럼 “전체 상황을 잘 요약해줘”라고 시키곤 했는데, 막상 다음 세션에서 다시 열어 보면 그 요약은 친절하지만 행동을 제한하지 못했다.
요즘 내가 더 자주 남기는 것은 긴 요약이 아니라 목표, 현재 상태, 첫 검증 세 줄이다. 이 세 줄은 멋진 문서가 아니다. 오히려 다음 에이전트가 첫 턴에서 바로 코드를 고치지 못하게 막는 작은 브레이크에 가깝다. 컨텍스트 압축이나 모델 전환은 어쩔 수 없이 정보가 줄어드는 일인데, 그 직후의 첫 행동까지 넓게 열어 두면 줄어든 정보 위에서 수정이 시작된다. 여기서 사고가 난다.
요약보다 기준선이 먼저다
세션이 길어졌을 때 “정리해줘”라고 말하면 에이전트는 대체로 많은 것을 예쁘게 묶어 준다. 바뀐 파일, 시도한 방법, 실패한 로그, 남은 TODO가 한 문서 안에 들어간다. 문제는 그 문서가 무엇을 믿어도 되는지와 무엇을 아직 믿으면 안 되는지를 같은 톤으로 섞는다는 점이다. 다음 세션 입장에서는 둘 다 그럴듯한 맥락으로 보인다.
내가 원하는 기준선은 더 작다. “마지막으로 믿을 수 있는 상태가 어디였나”, “그 뒤에 무엇이 달라졌나”, “다음에 제일 먼저 확인할 것은 무엇인가”만 남긴다. 파일 다섯 개를 읽었다는 사실보다, 그중 어느 파일이 실제 수정 근거였는지가 중요하다. 테스트 세 개를 돌렸다는 사실보다, 어느 테스트가 통과했고 어느 경로는 아직 빈칸인지가 중요하다.
세 줄만 남겨도 충분한 경우
내가 쓰는 형식은 거의 고정돼 있다. 첫 줄은 목표다. “설정 저장 후 새로고침해도 선택값이 유지되는 상태”처럼 사용자가 체감하는 성공 기준으로 쓴다. 둘째 줄은 현재 상태다. 여기에는 바뀐 파일과 통과한 검증을 같이 쓰되, 못 본 부분도 같은 줄에 붙인다. 셋째 줄은 첫 검증이다. 다음 세션이 수정 전에 먼저 실행하거나 열어 볼 대상을 하나만 고른다.
내가 남기는 작은 형식
목표: 설정 저장 후 새로고침에도 선택값이 유지되어야 한다.
현재 상태: 저장 API와 local state 연결은 고쳤고, 모바일 화면은 아직 못 봤다.
첫 검증: 수정 전에 같은 계정으로 저장 → 새로고침 → 모바일 폭 확인 순서만 먼저 재현한다.
이 정도면 전체 대화를 대신하지는 못한다. 대신 다음 행동을 충분히 좁힌다. 압축 뒤의 에이전트가 바로 리팩터링을 제안하더라도, 나는 “첫 검증부터”라고 되돌릴 수 있다. 이 작은 되돌림 지점이 없으면 새 세션은 예전 맥락을 복원하려다 새로운 변경을 섞기 쉽다.
압축 뒤 첫 행동을 수정으로 열지 않기
컨텍스트 압축이 무서운 이유는 정보가 사라져서만은 아니다. 정보가 줄어든 상태에서 에이전트가 자신 있게 행동한다는 점이 더 불편하다. 특히 코딩 작업에서는 첫 턴이 중요하다. 첫 턴에서 파일을 열어 기준선을 확인하면 세션이 안정된다. 반대로 첫 턴에서 바로 수정하면, 이전 세션의 미확인 영역이 새 diff 안으로 숨어 들어간다.
그래서 나는 압축 직전 세 줄의 마지막을 항상 동사 하나로 끝낸다. “확인한다”, “재현한다”, “비교한다” 같은 말이다. “고친다”로 두지 않는다. 이 차이가 생각보다 크다. 다음 에이전트가 할 일을 구현이 아니라 확인으로 시작하게 만들면, 이전 세션의 결론이 여전히 유효한지 먼저 걸러진다.
못 본 것은 다음 검증으로 넘긴다
예전에는 못 본 항목을 보고서 아래쪽에 따로 붙였다. “추가 확인 필요”라는 식이었다. 그런데 그런 줄은 다음 세션에서 잘 밀린다. 더 급해 보이는 수정 후보와 로그가 위에 있으면, 미확인 항목은 예의상 남긴 꼬리표처럼 취급된다. 그래서 요즘은 못 본 항목을 아예 첫 검증 줄 안에 넣는다.
예를 들어 “데스크톱에서는 확인, 모바일은 미확인”이라고만 남기지 않는다. “첫 검증: 모바일 폭에서 저장 후 새로고침을 먼저 본다”라고 쓴다. 미확인 영역을 다음 행동으로 바꾸는 것이다. 이렇게 적어 두면 완료 보고의 빈칸이 다음 세션의 출발점이 된다. 나중에 봐도 왜 그 검증을 먼저 했는지 설명이 남는다.
내가 실제로 보는 체크포인트
| 줄 | 좋은 상태 | 불안한 상태 |
|---|---|---|
| 목표 | 사용자 동작이나 실패 증상으로 적혀 있다. | “코드 정리”, “품질 개선”처럼 넓다. |
| 현재 상태 | 수정, 검증, 미확인이 분리돼 있다. | 통과한 것과 추정한 것이 한 문장에 섞인다. |
| 첫 검증 | 다음 세션의 첫 행동이 확인으로 제한된다. | 바로 구현하거나 리팩터링하게 만든다. |
이 표를 매번 완벽하게 채우지는 않는다. 다만 압축이나 모델 전환이 보이면 최소한 한 번은 본다. 세 줄이 흐리면 세션을 더 이어 가기보다 멈추는 편이 낫다. 대화가 길어질수록 중요한 것은 기억력이 아니라 기준선이다. 기준선을 작게 남겨 두면, 다음 세션은 똑똑하게 이어받기보다 먼저 같은 땅을 밟고 있는지 확인하게 된다. 나는 그 느린 첫걸음이 긴 바이브코딩 작업에서는 훨씬 싸게 먹힌다고 느낀다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 완료 보고 옆의 결과 파일 (0) | 2026.06.24 |
|---|---|
| 실패 로그 옆의 재현 명령 (0) | 2026.06.23 |
| 미확인 영역이 보이는 완료 보고 (0) | 2026.06.19 |
| 긴 실패 로그보다 처음 달라진 줄 (0) | 2026.06.17 |
| 건드리지 않을 파일 먼저 적기 (0) | 2026.06.15 |