롤백 기준표: 고치기 전에 되돌릴 조건부터 쓰기

2026년 5월 13일 | 바이브코딩 Tips

---

코딩 에이전트에게 수정 권한을 열 때 내가 제일 먼저 보는 건 되돌릴 조건이다. 기능 설명은 누구나 길게 쓸 수 있다. 그런데 어디까지 고치다가 멈출지, 어떤 신호가 나오면 방금 방향을 버릴지, 되돌린 뒤 무엇을 다시 확인할지는 생각보다 자주 비어 있다. 이 칸이 비어 있으면 에이전트는 실패를 만회하려고 더 넓게 수정하고, 사람은 나중에 diff를 보고서야 일이 커졌다는 걸 알아차린다.

그래서 나는 요즘 작업을 맡길 때 작은 롤백 기준표를 먼저 붙인다. 거창한 재해 복구 문서가 아니다. 현재 정상으로 보는 기준선, 허용할 수정 범위, 되돌릴 신호, 되돌린 뒤 재검증 순서를 네 줄로 적는 정도다. 이걸 해두면 에이전트가 실패했을 때 “조금만 더 고쳐 보겠다”로 흘러가지 않고, 미리 정한 지점에서 멈춘다. 바이브코딩에서 중요한 건 빠른 수정과 함께, 빠르게 망가진 방향을 접는 능력이라고 느낀다.

1. 롤백은 시작 조건에 가깝다

예전에는 롤백을 작업이 크게 꼬였을 때 쓰는 마지막 수단처럼 생각했다. 하지만 코딩 에이전트와 일할 때는 반대로 보는 편이 낫다. 롤백 기준은 작업 시작 전에 정해 두는 안전한 종료 조건이다. 사람이 직접 코드를 고칠 때는 손으로 바꾼 줄이 기억에 남지만, 에이전트는 한 번에 여러 파일을 읽고 수정한다. 그 과정에서 작은 실패를 만회하려다 수정면이 넓어지는 일이 꽤 자주 생긴다.

특히 프론트엔드 화면, 설정 파일, 데이터 스키마처럼 한 곳을 바꾸면 옆 단계가 같이 흔들리는 작업에서 이 문제가 잘 보인다. 처음 목표는 버튼 문구 하나였는데, 에이전트가 스타일 구조와 validation 흐름까지 같이 손대는 식이다. 나중에 보면 이유는 그럴듯하다. “일관성을 맞추기 위해”, “테스트를 통과시키기 위해”, “타입 오류를 줄이기 위해” 같은 말이 붙는다. 문제는 그 이유가 이번 작업의 허용 범위 안에 있었는지다.

Figure 1: 수정 지시 전에 기준선, 수정 범위, 되돌림 신호, 재검증 순서를 먼저 적는 롤백 기준표

위 도식에서 내가 제일 중요하게 보는 칸은 세 번째다. 되돌림 신호가 없으면 에이전트는 실패를 실패로 인정하지 않고 다음 수정을 시도한다. 테스트가 한 번 더 깨져도, 파일이 하나 더 늘어나도, 화면이 조금 이상해져도 계속 “수정 중”이라는 상태로 남는다. 반대로 되돌림 신호를 먼저 적어 두면 실패가 발생했을 때 사람과 에이전트가 같은 기준으로 멈출 수 있다.

2. 내가 쓰는 네 칸

롤백 기준표는 길게 쓸수록 안 쓰게 된다. 나는 보통 작업 시작 프롬프트 아래에 네 줄짜리 표를 붙인다. 핵심은 복잡한 절차를 만들기보다, 실패가 커지기 전에 확인할 작은 cutline을 정하는 것이다.

칸	적는 내용	효과
기준선	마지막으로 정상이라고 보는 테스트, 화면, 파일 상태	되돌릴 위치를 증거로 고정
수정 범위	건드릴 파일과 건드리지 않을 파일, 허용할 diff 폭	좋은 의도에서 시작한 범위 확대를 줄임
되돌림 신호	실패 반복 횟수, 무관 파일 수정, 화면 악화, 응답 추측	더 고치기 전에 멈출 이유를 제공
재검증	되돌린 뒤 다시 돌릴 테스트와 남길 로그	실패한 세션도 다음 작업의 자료로 남김

이 네 칸을 쓰면 “어디까지 해도 되는지”와 “어디서 그만둘지”가 같이 생긴다. 에이전트에게 허용 범위만 주고 중단 조건을 주지 않으면, 실패한 방향도 계속 수리 대상으로 남는다. 반대로 중단 조건만 있고 기준선이 없으면, 되돌리자는 말이 추상적이 된다. 기준선과 되돌림 신호를 같이 붙여야 실제 작업에서 쓸 수 있다.

3. 프롬프트에 붙이는 짧은 양식

내가 실제로 쓰는 양식은 아래 정도다. 코드나 명령어라기보다 작업 계약에 가깝다. 중요한 건 에이전트가 실패를 숨기지 않고, 정해 둔 신호가 나오면 수정 확대를 멈추게 만드는 것이다.

목표: 결제 내역 화면에서 중복 요청 표시를 줄인다.

기준선:
- 현재 목록 조회 테스트는 통과한 상태로 본다.
- 사용자가 직접 새로고침하는 흐름은 보존한다.

수정 범위:
- 화면 컴포넌트와 요청 dedupe 유틸까지만 수정한다.
- 라우터, 인증, 결제 API 스키마는 건드리지 않는다.

되돌림 신호:
- 같은 테스트가 2회 연속 다른 이유로 실패하면 멈춘다.
- 수정 파일이 4개를 넘으면 확장 이유를 먼저 보고한다.
- preview에서 기존 목록 정렬이 바뀌면 직전 diff로 되돌린다.

재검증:
- 목록 조회 테스트, 중복 요청 재현 케이스, 화면 preview 순서로 확인한다.
- 되돌렸다면 실패 로그와 버린 가설만 남긴다.

이 양식을 붙이면 에이전트의 답변도 달라진다. “수정했습니다”보다 “이 조건 때문에 멈췄습니다”라는 보고가 나오기 쉬워진다. 나는 그 보고가 꽤 중요하다고 본다. 실패한 작업을 실패한 채로 정리할 수 있어야, 다음 루프가 같은 길을 다시 걷지 않는다.

여기서 포인트는 되돌림 신호를 너무 거창하게 잡지 않는 것이다. “서비스가 망가지면 롤백” 같은 기준은 실제 코딩 세션에서는 늦다. 파일 수, 테스트 반복 실패, preview 악화, 금지 영역 접근처럼 작업 중간에 바로 보이는 신호가 좋다. 그래야 에이전트가 아직 설명을 그럴듯하게 만들고 있을 때 사람 쪽에서 끊을 수 있다.

4. hook과 handoff 사이에 놓기

롤백 기준표는 hook이나 guardrail과도 잘 맞는다. hook은 삭제, 배포, 보호 경로 수정 같은 위험 행동을 자동으로 막을 수 있다. 하지만 모든 상황을 hook으로 만들 수는 없다. 어떤 작업은 사람이 그때그때 판단해야 하고, 어떤 위험은 도구 실행 전에는 보이지 않는다. 롤백 기준표는 그 사이에서 사람이 정한 중단 기준을 에이전트에게 계속 보이게 하는 역할을 한다.

handoff와도 연결된다. 작업이 끝난 뒤 “남은 위험 있음”이라고 쓰는 것보다, 처음에 적어 둔 되돌림 신호 중 어떤 것이 실제로 울렸는지를 적는 편이 훨씬 낫다. 그러면 다음 사람이 봤을 때 실패가 재현 가능한 사건으로 남는다. 나는 이 차이가 팀 작업에서도 꽤 크다고 느낀다. 실패한 세션이 다음 실행의 입력이 되기 때문이다.

5. 너무 빨리 되돌리는 게 아깝게 느껴질 때

롤백 기준표를 쓰다 보면 가끔 아깝다. 한두 줄만 더 고치면 될 것 같은데, 미리 정한 신호 때문에 멈춰야 하는 순간이 온다. 그런데 이 아까움이 바이브코딩에서는 꽤 위험하다. 에이전트가 이미 잘못된 가설을 잡은 상태라면 방향 자체가 틀어진 경우가 많았다. 그때 더 밀어붙이면 결과는 종종 “작동은 하는데 왜 이렇게 바뀌었는지 모르는 코드”가 된다.

그래서 나는 작은 롤백을 손실로 보지 않으려고 한다. 기준선으로 돌아온다는 건 판단면을 다시 좁히는 일이다. 버린 diff, 실패 로그, 울린 신호가 남아 있으면 다음 시도는 오히려 더 작게 시작할 수 있다. 바이브코딩을 오래 굴릴수록 완주보다 중요한 순간이 생긴다. 그 순간은 대개 여기서 멈추고 되돌리기 쪽에 있다.