같은 지시를 세 번 밀지 않기

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

---

코딩 에이전트가 같은 실패를 두 번 반복하면, 그다음 입력은 더 긴 지시보다 더 작은 재시도 단위에 가까워야 한다. 나는 예전에는 "아니 그게 아니라"로 시작해서 요구사항을 더 길게 붙이는 쪽으로 갔는데, 그렇게 하면 에이전트도 나도 무엇이 달라졌는지 금방 잃어버렸다.

특히 바이브코딩 흐름에서는 속도가 장점인 만큼 같은 프롬프트를 계속 밀어 넣기 쉽다. 버튼이 안 붙으면 다시 붙여 달라고 하고, 테스트가 깨지면 다시 고쳐 달라고 하고, 화면이 어색하면 조금 더 예쁘게 해 달라고 한다. 그런데 이 반복이 세 번째쯤 되면 작업은 앞으로 간다기보다 옆으로 번진다. diff는 커지고, 실패 원인은 흐려지고, 나중에는 "어느 입력부터 이상해졌지"를 되짚는 데 시간을 쓴다.

같은 지시를 더 세게 반복하기보다, 실패 관찰과 한 변수 변경을 분리해 둔다.

반복 지시가 신호를 지우는 순간

한 번 실패한 에이전트에게 같은 요구를 다시 주는 것 자체는 흔한 일이다. 첫 실패는 보통 맥락 누락, 파일 위치 착각, 테스트 조건 오해 같은 평범한 이유에서 온다. 문제는 두 번째 입력에서도 무엇을 새로 알려줬는지가 남지 않을 때다. "다시 해봐"만 반복하면 에이전트는 더 넓게 추측하고, 사람은 더 늦게 확인한다.

내 기준으로는 실패가 두 번 겹치는 순간부터 작업 모드가 바뀐다. 구현 요청을 잠깐 멈추고 디버깅 요청으로 바꾸며, 그 디버깅 요청도 네 갈래 중 하나만 고른다. 문맥을 더 줄 것인지, 수정 범위를 줄일 것인지, 권한을 낮출 것인지, 검증 기준을 바꿀 것인지다. 네 가지를 한꺼번에 바꾸면 결과가 좋아져도 무엇이 먹혔는지 모른다.

재시도는 한 변수만 바꾸기

가장 효과가 좋았던 방식은 단순했다. 다음 입력에서 바꿀 변수를 하나만 고르는 것이다. 예를 들어 파일을 더 읽게 할 거면 수정 금지를 붙인다. 수정 범위를 좁힐 거면 기존 컨텍스트는 그대로 둔다. 검증 명령을 바꿀 거면 코드 변경은 멈춘다. 이렇게 해야 다음 결과가 실패해도 실패의 위치가 더 선명해진다.

나는 이걸 작은 재시도 칸처럼 쓴다. 첫 칸에는 방금 본 실패 증거를 적는다. 둘째 칸에는 이번에 바꿀 변수 하나를 적는다. 셋째 칸에는 같은 기준으로 다시 볼 확인 방법을 적는다. 마지막 칸에는 여기서 또 실패하면 멈출지, 사람 판단으로 넘길지, 아예 다른 접근을 열지 적는다.

실패 증거: 저장 버튼 클릭 뒤 toast가 안 뜸
이번에 바꿀 변수: 수정 금지, 관련 컴포넌트 읽기만 허용
다시 볼 기준: 버튼 handler와 API 호출 경로가 같은지 확인
멈춤 조건: 원인 파일을 특정하지 못하면 구현 재시도 중단

이 정도 템플릿이면 거창하게 문서화할 필요가 없다. 오히려 길게 쓰면 안 쓴다. 핵심은 에이전트에게 친절한 설명을 늘어놓는 쪽보다, 내가 다음 관찰을 읽을 수 있게 변화량을 작게 묶는 것에 있다.

세 번째 요청 전에 바꾸는 질문

세 번째 요청을 던지기 전에는 프롬프트 문장 자체보다 질문의 종류를 먼저 바꾼다. "다시 고쳐줘"에서 바로 출발하지 않고, "방금 실패를 어디서 확인했지"를 먼저 묻는다. 화면, 테스트, 로그, diff 중 하나로 증거가 좁혀지지 않으면 에이전트는 대개 더 넓은 수정을 시도한다. 그 상태에서 다시 맡기면 운 좋게 통과해도 나중에 설명이 남지 않는다.

두 번째 질문은 에이전트가 실제로 읽은 파일과 고친 파일이 맞닿아 있는지다. 실패가 반복될 때는 의외로 해결 로직보다 탐색 경로가 틀린 경우가 많다. 프론트 버튼 문제를 이야기했는데 서버 라우터만 보고 있거나, 테스트 실패를 말했는데 fixture를 읽지 않은 채 구현 파일만 만지는 식이다. 이때는 새 구현을 시키기보다 "수정 금지, 관련 파일 후보만 세 개로 줄여줘"처럼 읽기 작업으로 되돌리는 편이 더 빠르다.

세 번째 질문은 다음 입력이 관찰인지 수정인지 구분되어 있는지다. 관찰 요청과 수정 요청이 한 문장 안에 섞이면 결과도 섞인다. 그래서 나는 재시도 프롬프트 맨 앞에 "이번 턴은 읽기만", "이번 턴은 한 파일만 수정", "이번 턴은 테스트 명령만 재확인"처럼 턴의 성격을 붙인다. 사소해 보이지만 이 한 줄이 diff를 줄이고, 실패했을 때 되돌릴 기준도 만들어 준다.

모바일 빌더나 웹 AI 빌더처럼 미리보기와 코드 생성이 붙어 있는 도구에서는 이 구분이 더 중요하다. 화면에서 바로 보이는 변화가 있으니 계속 누르고 싶지만, 같은 실패를 세 번 밀면 상태가 뒤엉킨다. 작은 handoff bundle을 남겨 두면 다음 세션에서 "어디까지 봤고, 무엇을 바꿨고, 무엇은 아직 확인하지 않았는지"를 바로 이어받을 수 있다.

세 번째 입력 전에 멈춤 조건 붙이기

바이브코딩에서 제일 위험한 구간은 실패 직후보다 애매하게 좋아진 직후다. 화면은 조금 나아졌고, 테스트는 하나 줄었고, 에이전트 답변도 그럴듯해 보인다. 그래서 한 번만 더 시키고 싶어진다. 그런데 이때 멈춤 조건이 없으면 작은 개선을 핑계로 원래 작업 반경을 넘어간다.

그래서 나는 두 번째 실패 뒤에는 세 번째 입력을 바로 던지지 않는다. 먼저 성공으로 인정할 최소 증거를 적는다. 예를 들면 "이 파일 하나만 바뀌고 기존 테스트가 그대로 통과"처럼 좁게 쓴다. 반대로 "아마 해결됨"이나 "전체적으로 개선" 같은 말은 분위기에 가깝기 때문에 종료 기준으로 쓰지 않는다.

멈춤 조건은 에이전트를 덜 믿겠다는 선언과 거리가 있다. 잘 맡기려면 어디까지 맡길지 분명해야 한다. 같은 세션 안에서 읽기, 수정, 검증, 인수인계가 모두 섞이면 빠르게 보이지만 복구 비용이 커진다. 작게 끊어야 다음 사람, 혹은 다음 세션의 내가 이어받을 수 있다.

내가 실제로 쓰는 기준

요즘 코딩 에이전트는 첫 초안을 정말 빨리 만든다. 그래서 처음부터 느리게 굴릴 필요는 없다. 다만 실패가 반복되기 시작하면 속도보다 관찰 가능성이 먼저다. 같은 지시를 두 번 밀었는데 결과가 흔들리면, 세 번째부터는 요구를 늘리는 대신 기록을 줄이고 변수를 하나만 바꾼다.

실무에서는 이 작은 차이가 생각보다 크다. 실패가 나도 다음 입력이 깨끗하고, 성공해도 왜 성공했는지 남는다. 무엇보다 "에이전트가 이상하게 굴었다"는 뭉뚱그린 느낌에서 빨리 빠져나올 수 있다. 실패를 성격 문제가 아니라 루프 문제로 보면, 손댈 곳도 훨씬 작아진다.

이 방식은 팀 작업에서도 꽤 편하다. 누군가 이어받을 때 장황한 대화 로그를 전부 읽지 않아도 되고, 빠진 검증도 작게라도 바로 보이게 된다. 실패 증거, 바꾼 변수, 확인 기준, 멈춤 조건만 보면 다음 입력을 어디서 시작해야 하는지 보인다.

내 기준은 간단하다. 같은 지시를 세 번 밀기 전에 멈춘다. 세 번째 입력이 필요하다면, 그 입력은 더 강한 요구가 아니라 더 좁은 관찰이어야 한다. 바이브코딩은 빨리 맡기는 일만큼이나, 언제 같은 말을 그만하고 루프를 다시 자를지 정하는 일에 품질이 걸린다.