<!doctype html>
2026년 6월 4일 | 바이브코딩 Tips
코드 리뷰 프롬프트를 세 번째로 다시 치는 순간, 나는 그 문장이 좋은지가 아니라 다시 실행되는 조건이 비어 있는지부터 보게 된다. 문장 자체는 꽤 괜찮아도 매번 사람이 같은 저장소, 같은 로그, 같은 금지 범위를 다시 설명해야 한다면 그건 아직 routine이 아니라 복사해 둔 부탁말에 가깝다. 바이브코딩을 오래 굴리다 보면 이 차이가 생각보다 크게 느껴진다.
반복 작업을 저장해 두자는 말은 흔하다. 하지만 실제로 흔들리는 지점은 프롬프트 저장이 아니라 언제 시작하고, 어디까지 만지고, 무엇을 보고 멈출지를 같이 저장하지 않는 데 있다. 예를 들어 “PR 리뷰해 줘”라는 문장을 routine으로 만들었다고 해도, 어떤 브랜치에서 돌릴지, 어떤 파일은 손대면 안 되는지, 실패하면 누구에게 넘길지, 결과로 어떤 증거를 남길지가 없으면 다음 실행도 다시 사람 설명에 기대게 된다.
프롬프트 저장과 routine 저장은 다르다
예전에는 자주 쓰는 요청문을 노트에 적어 두는 것만으로도 충분하다고 생각했다. “이 diff를 리뷰하고 위험한 변경을 짚어줘”, “테스트 실패 원인을 좁혀줘”, “릴리즈 노트를 초안으로 정리해 줘” 같은 문장들이다. 이것만으로도 첫 턴은 빨라진다. 그런데 두 번째, 세 번째 실행부터는 같은 문제가 반복됐다. 매번 대상 저장소가 바뀌고, 검증 명령이 바뀌고, 이번에는 수정까지 허용할지 읽기만 시킬지가 바뀌었다.
그래서 나는 routine을 만들 때 본문 프롬프트보다 먼저 네 칸을 본다. 트리거, 작업 표면, 멈춤 조건, 확인 영수증이다. 트리거는 언제 이 작업을 시작할지다. 작업 표면은 어느 저장소, 어느 브랜치, 어느 connector, 어느 파일군까지 열어 줄지다. 멈춤 조건은 실패 반복이나 권한 초과를 어디서 끊을지다. 확인 영수증은 실행 뒤 사람이 다시 열었을 때 무엇이 실제로 확인됐는지 보는 짧은 기록이다.
트리거가 없으면 그냥 좋은 문장
routine의 첫 칸은 “무슨 말을 할까”보다 “언제 자동으로 꺼낼까”에 가깝다. 매주 월요일 아침에 의존성 업데이트를 훑는 작업인지, PR이 열릴 때마다 위험 파일을 읽는 작업인지, 배포 실패 알림이 왔을 때 로그를 먼저 묶는 작업인지에 따라 같은 프롬프트도 완전히 달라진다. 사람이 직접 눌러 실행하는 routine이라도 시작 조건은 필요하다. 안 그러면 비슷한 상황마다 “이걸 지금 돌려도 되나?”부터 다시 판단하게 된다.
나는 트리거를 너무 넓게 잡지 않는 편이다. “모든 PR 리뷰”보다 “마이그레이션 파일이 포함된 PR 리뷰”가 낫고, “매일 코드 품질 점검”보다 “테스트 실패가 이틀 연속 같은 모듈에서 난 경우”가 낫다. 넓은 트리거는 자동화를 멋있게 보이게 하지만, 실제로는 노이즈를 빨리 만든다. 바이브코딩에서 중요한 건 많이 돌리는 게 아니라, 사람이 다시 설명하지 않아도 될 만큼 상황이 좁아졌을 때 돌리는 것이다.
작업 표면은 권한 목록보다 좁게
반복 실행으로 옮길 때 가장 위험한 부분은 연결 권한을 관성적으로 전부 넘기는 것이다. 채팅에서는 사람이 옆에서 보고 있으니 “그 파일은 건드리지 마”라고 중간에 끊을 수 있다. routine은 그렇지 않다. 저장소, 이슈, 문서, 알림, 배포 로그 같은 connector가 한꺼번에 붙으면 에이전트 입장에서는 더 많은 맥락을 얻지만, 사람 입장에서는 결과를 추적하기가 어려워진다.
그래서 routine의 작업 표면은 “가능한 것”이 아니라 “이번 반복에 꼭 필요한 것”으로 적는다. 예를 들어 PR 리뷰 routine이면 읽기 권한은 diff와 관련 테스트까지, 수정 권한은 기본적으로 닫아 둔다. 실패 로그 triage routine이면 최근 실행 로그와 설정 파일은 열어도, 바로 코드를 고치지는 못하게 한다. 수정이 필요하면 사람에게 다음 단계로 넘기게 하는 식이다. 반복 실행일수록 첫 권한은 더 작게 시작하는 편이 덜 피곤했다.
멈춤 조건을 미리 적어야 반복이 안전하다
좋은 routine은 성공 경로만 저장하지 않는다. 오히려 실패 경로를 어떻게 접을지 적어 둔 routine이 오래 간다. 같은 오류를 두 번 읽었는데 원인이 바뀌지 않으면 멈춘다. diff가 세 파일을 넘기면 요약만 남기고 수정하지 않는다. 테스트를 실행할 수 없으면 추정 패치를 만들지 않는다. 외부 서비스 권한이 필요하면 우회하지 말고 사람 확인으로 넘긴다. 이런 문장이 있어야 반복 실행이 자동 고집으로 바뀌지 않는다.
이 멈춤 조건은 에이전트를 못 믿어서 붙이는 장치라기보다, 나중에 내가 결과를 읽을 수 있게 만드는 장치에 가깝다. routine이 실패했을 때 “왜 여기서 멈췄지?”가 바로 보이면 다음 지시가 짧아진다. 반대로 멈춤 조건이 없으면 에이전트가 스스로 합리화하면서 더 넓은 범위를 뒤진다. 그때 생긴 긴 로그는 똑똑해 보이지만, 실제로는 다음 사람이 다시 압축해야 하는 빚이 된다.
확인 영수증은 짧을수록 좋다
routine의 마지막 출력은 예쁜 보고서가 아니어도 된다. 나는 보통 네 줄이면 충분하다고 본다. 무엇을 읽었는지, 무엇을 바꿨거나 바꾸지 않았는지, 어떤 검증을 실제로 돌렸는지, 남은 미확인 영역은 무엇인지다. 이 네 줄이 있으면 다음 실행이 같은 질문을 반복하지 않는다. 특히 실패한 routine도 이 영수증만 남아 있으면 실패 자산이 된다.
여기서 조심할 점은 확인 영수증을 산출물 자랑으로 만들지 않는 것이다. “완료했습니다”나 “문제 없습니다”보다 “A 테스트는 통과했고, 모바일 Safari 경로는 확인하지 못했다”가 훨씬 낫다. 바이브코딩에서 사람을 편하게 만드는 답은 자신감 있는 답이 아니라, 내가 다음에 어디를 봐야 하는지 줄여 주는 답이다. routine도 마찬가지다. 반복 실행의 가치는 매번 결과가 완벽한 데 있지 않고, 매번 같은 방식으로 확인 흔적을 남기는 데 있다.
내가 쓰는 작은 템플릿
실제로 routine을 만들 때는 길게 쓰지 않는다. 시작 조건에는 “어떤 이벤트에서 실행할지”를 한 줄로 적는다. 작업 표면에는 “읽기 허용, 수정 허용, 금지 경로”를 나눈다. 멈춤 조건에는 “반복 실패, 큰 변경, 권한 필요, 검증 불가”를 적는다. 마지막 출력에는 “읽은 것, 한 것, 확인한 것, 못 본 것” 네 칸을 요구한다. 이 정도만 있어도 프롬프트 복붙과 routine 사이의 경계가 꽤 분명해진다.
물론 모든 반복 작업을 routine으로 만들 필요는 없다. 한두 번 쓰고 말 요청은 그냥 채팅으로 던지는 편이 낫다. 내가 routine 후보로 보는 것은 세 번 이상 반복했고, 매번 같은 설명을 다시 붙였고, 실패했을 때 되돌림 비용이 있는 작업이다. 이 조건을 만족하면 프롬프트를 더 다듬기보다 실행 조건을 먼저 묶는다. 그쪽이 장기적으로 덜 흔들렸다.
결국 routine은 “좋은 요청문 저장소”가 아니라 작은 운영 계약이다. 시작 조건이 좁고, 연결 권한이 작고, 멈춤 신호가 분명하고, 확인 영수증이 남으면 에이전트가 조금 덜 똑똑한 날에도 작업이 크게 번지지 않는다. 반대로 이 네 가지가 빠진 반복 프롬프트는 처음 며칠은 편해 보여도, 나중에는 매번 사람이 수습해야 하는 또 하나의 열린 세션이 된다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 샘플 입력 세 개를 먼저 고정하기 (0) | 2026.06.11 |
|---|---|
| 상태 차이부터 넘기기 (0) | 2026.06.05 |
| 수정 전 읽은 파일 목록 (1) | 2026.06.03 |
| 모델을 바꿔 이어 갈 때 남길 것 (0) | 2026.06.02 |
| 같은 지시를 세 번 밀지 않기 (0) | 2026.05.29 |