<!doctype html>
2026년 5월 21일 | 바이브코딩 Tips
코딩 에이전트와 작업할 때 가장 위험한 순간은 실패가 아니라, 일이 조금 풀리기 시작한 뒤에 새 요구가 끼어드는 순간이다. 테스트 하나가 드디어 지나가고, 화면도 얼추 맞아 보이고, 그때 갑자기 “이 김에 필터도 넣을까”, “문구도 바꾸자”, “상태 저장까지 같이 하면 좋겠다” 같은 생각이 따라붙는다. 사람이 직접 코딩할 때도 흔한데, 바이브코딩에서는 이 순간이 더 미끄럽다. 에이전트는 새 지시를 받으면 대체로 성실하게 반영하려고 하고, 그 결과 현재 diff의 목적이 조용히 바뀐다.
나는 이럴 때 새 요구 보류 목록을 하나 따로 둔다. 새 요구를 바로 버리지도 않고, 현재 수정에 바로 섞지도 않는다. 대신 “지금 diff 밖에 세워 둔다”는 규칙을 먼저 만든다. 보류 목록에 들어간 항목은 나중에 할 일이 될 수도 있고, 그대로 버릴 수도 있다. 중요한 건 그 판단을 지금 수정 중인 파일 안에서 하지 않는다는 점이다.
새 요구를 바로 반영하면 생기는 일
예를 들어 모바일 AI 빌더에서 설정 화면을 다듬고 있다고 치자. 시작 계약은 “토글 레이아웃 깨짐만 고치고, 저장 로직은 건드리지 않는다”였다. 그런데 중간 미리보기에서 문구가 어색해 보이고, 빈 상태 화면도 같이 바꾸고 싶어진다. 여기서 아무 생각 없이 “문구도 좀 자연스럽게 바꿔줘”라고 던지면 에이전트는 레이아웃 파일만 보던 흐름에서 번역 파일, 상태 컴포넌트, 저장 후 토스트까지 읽기 시작한다. 처음에는 친절해 보이지만, 20분 뒤 diff를 보면 내가 무엇을 승인했고 무엇을 그냥 흘려보냈는지 흐릿해진다.
이 문제는 에이전트가 나빠서 생기는 게 아니다. 대화형 작업은 기본적으로 최근 문맥을 따라간다. 내가 던진 한 줄이 새 목표처럼 보이면, 에이전트는 그 한 줄을 현재 목표와 합쳐 버린다. 그래서 필요한 건 더 긴 프롬프트가 아니라 현재 diff에 들어갈 수 있는 것과 다음 diff로 미룰 것을 분리하는 장치다.
보류 목록에 적는 네 칸
내가 쓰는 보류 목록은 보통 네 칸이면 충분하다. 첫째, 새 요구의 원문이다. 사람이 한 말이든 내가 떠올린 아이디어든 최대한 가공하지 않고 적는다. 둘째, 지금 반영하지 않는 이유다. “현재 테스트 범위 밖”, “허용 파일 밖”, “디자인 판단 필요”, “저장 로직과 충돌 가능”처럼 짧게 쓴다. 셋째, 다시 볼 증거다. 화면 캡처, 실패 로그, 파일 위치, 사용자 문장 중 하나가 들어가면 된다. 넷째, 다음 판단이다. 폐기할지, 별도 티켓으로 뺄지, 다음 세션에서 계약을 다시 쓸지 표시한다.
| 칸 | 적는 내용 | 예시 |
|---|---|---|
| 요구 원문 | 떠오른 요청 그대로 | 빈 상태 문구도 더 부드럽게 |
| 보류 이유 | 현재 계약 밖인 이유 | 레이아웃 수정 범위를 넘음 |
| 증거 | 나중에 다시 볼 단서 | SettingsEmptyState.tsx 42행 |
| 다음 판단 | 폐기·티켓·다음 세션 | 현재 diff 머지 후 별도 수정 |
여기서 의외로 중요한 칸은 “보류 이유”다. 그냥 보류 목록에 넣기만 하면 보류 목록이 곧 새 TODO가 된다. 그러면 다음 세션에서 또 “다 해야 할 것”처럼 보인다. 반대로 보류 이유를 적어 두면, 그 항목이 왜 지금 작업에 들어오면 안 되는지 남는다. 나중에 다시 봤을 때도 “이건 귀찮아서 미룬 게 아니라, 현재 diff의 검증 범위를 깨서 뺐구나”라고 판단할 수 있다.
에이전트에게 맡길 때의 문장
나는 작업을 시작할 때부터 보류 목록 규칙을 짧게 붙이는 편이다. 길게 쓸 필요는 없다. 오히려 너무 복잡하면 에이전트가 보류 목록 자체를 또 하나의 산출물처럼 부풀린다. 내가 자주 쓰는 형태는 이 정도다.
현재 작업은 설정 화면의 토글 레이아웃 수정만 한다.
새 요구나 개선 아이디어가 나오면 코드에 반영하지 말고 보류 목록에만 적어라.
보류 목록에는 요구 원문, 지금 제외하는 이유, 다시 볼 증거, 다음 판단을 남겨라.
현재 diff는 기존 테스트와 미리보기 검증을 통과한 뒤 멈춘다.이 문장의 핵심은 “새 요구를 무시하라”가 아니다. 새 요구를 코드가 아니라 메모로 먼저 받으라는 뜻이다. 그래서 에이전트가 좋은 개선점을 발견해도 바로 파일을 열지 않는다. 대신 “이건 보류 목록에 넣겠습니다. 현재 diff에는 반영하지 않습니다”라고 말하게 만든다. 이 한 문장이 있으면, 작업 중간의 욕심이 바로 변경으로 번지는 속도가 확실히 줄어든다.
변경 반경 캡과 다른 점
처음에는 이게 변경 반경 캡과 거의 같은 말 아닌가 싶었다. 실제로 둘은 같이 쓰면 좋다. 변경 반경 캡은 중심 파일과 허용 파일을 정해 “어디까지 수정할 수 있는가”를 묶는다. 새 요구 보류 목록은 그보다 한 단계 앞에서 “방금 생긴 요구를 현재 수정 목표로 승격할 것인가”를 묻는다. 즉 파일 반경의 문제가 아니라 목표 반경의 문제다.
권한 계단과도 결이 다르다. 권한 계단은 읽기 전용, 패치 제안, 좁은 수정, 검증처럼 에이전트에게 열어 줄 권한의 높이를 조절한다. 새 요구 보류 목록은 그 계단을 오르는 중간에 새 문장이 들어왔을 때, 계단 자체를 다시 설계할지 아니면 옆에 세워 둘지를 결정한다. 둘을 같이 쓰면 “지금은 좁은 수정 권한이므로, 새 요구는 보류 목록에만 남긴다”처럼 꽤 단단한 계약이 된다.
언제 바로 반영해도 되는가
물론 모든 새 요구를 보류 목록으로 보내면 작업이 답답해진다. 나는 세 가지 경우에는 바로 계약을 다시 쓴다. 첫째, 보안이나 데이터 손실처럼 현재 diff를 멈추는 게 맞는 문제다. 둘째, 새 요구가 사실상 현재 버그의 원인이라서 분리하면 검증이 거짓이 되는 경우다. 셋째, 한 줄 수정처럼 보이더라도 사용자 경험의 의미가 완전히 달라지는 경우다. 이때는 몰래 섞지 말고 “현재 계약을 중단하고 새 계약으로 바꾼다”고 선언하는 편이 낫다.
작업이 커질수록 좋은 에이전트 운영은 더 많은 일을 시키는 쪽이 아니라, 일을 덜 섞이게 하는 쪽에 가까워진다. 새 요구 보류 목록은 특별한 도구가 없어도 쓸 수 있는 작은 장치다. 하지만 한 번 익숙해지면 diff 리뷰가 훨씬 편해진다. 보류 목록에 남은 항목은 다음 실행 후보가 되고, 현재 diff는 처음 약속한 검증만 통과하면 닫을 수 있다. 나는 이 정도의 분리만 해도 바이브코딩 세션이 꽤 덜 흐려진다고 느낀다.
마지막으로 보류 목록을 비우는 시간도 정해 두는 편이 좋다. 나는 보통 현재 diff가 머지되거나 배포 확인이 끝난 뒤 5분만 다시 본다. 그때도 바로 손이 안 가는 항목은 과감히 지운다. 살아남은 항목만 다음 작업 계약의 후보가 된다. 이렇게 해야 보류 목록이 또 다른 미완성 더미가 되지 않는다. 특히 에이전트가 남긴 보류 항목에는 날짜와 판단자를 같이 적어 두면, 다음 사람이 이어받을 때도 같은 논쟁을 반복하지 않는다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 재현 명령: 넘겨받을 작업의 첫 줄 (0) | 2026.05.26 |
|---|---|
| 만료 조건: 오래 열린 세션 닫기 (0) | 2026.05.22 |
| 권한 계단: 읽기 전용에서 수정까지 한 칸씩 (0) | 2026.05.20 |
| 검증 레인: 만든 세션과 확인 세션 분리 (0) | 2026.05.19 |
| 실패 묶음: 재시도 전에 남길 네 칸 (0) | 2026.05.18 |