<!doctype html>
2026년 5월 22일 | 바이브코딩 Tips
코딩 에이전트 세션은 오래 열어 둘수록 점점 똑똑해지는 게 아니라, 어느 순간부터 오래된 약속을 계속 붙잡는 쪽으로 기운다. 처음에는 실패 로그 하나, 수정 파일 두세 개, 확인할 테스트 하나로 시작했는데 중간에 요구사항이 붙고, 다른 파일을 읽고, 검증 조건이 바뀐다. 그런데 대화창에서는 그 변화가 꽤 자연스럽게 이어진다. 그래서 나도 모르게 “방금까지 하던 김에 이것도”라고 넘기기 쉽다.
문제는 에이전트가 그 흐름을 사람보다 더 매끈하게 이어 붙인다는 데 있다. 사람은 피곤하면 잠깐 멈추지만, 에이전트는 멈추지 않고 다음 diff를 만든다. 앞에서 정한 범위가 아직 유효한지, 실패 로그가 새로 바뀌었는지, 검증 기준이 다른 쪽으로 옮겨 갔는지까지 매번 따져 묻지는 않는다. 그래서 나는 요즘 긴 작업을 맡길 때 작업 계약에 만료 조건을 붙이는 방식을 꽤 자주 쓴다.
계약을 오래 들고 가면 생기는 일
여기서 말하는 계약은 거창한 문서가 아니다. “이 파일만 고친다”, “이 에러를 재현한 뒤 수정한다”, “테스트 A와 화면 B를 통과하면 끝낸다” 정도의 작은 약속이다. 짧은 작업에서는 이 정도만으로도 충분하다. 하지만 세션이 길어지면 계약이 낡는다. 처음 읽은 로그가 더 이상 최신 로그가 아니고, 처음 정한 파일 범위가 새 요구사항과 맞지 않으며, 처음 통과시키려던 테스트가 지금 문제의 핵심을 더 이상 대표하지 못할 수 있다.
그런데 대화형 작업에서는 이 낡음이 잘 보이지 않는다. 에이전트가 “이어서 진행하겠습니다”라고 말하면, 실제로는 새로운 작업인데도 이전 작업의 연장처럼 느껴진다. 특히 모바일 빌더나 웹 AI 빌더에서 초안을 빠르게 만들고, 데스크톱에서 코딩 에이전트로 정리하는 흐름에서는 이런 일이 더 자주 생긴다. 화면에서는 한 줄 버튼 수정처럼 보였는데, 실제 저장소에서는 라우팅, 상태 관리, 빌드 설정까지 연결되는 식이다.
이때 필요한 질문은 “더 해도 될까?”보다 “아직 같은 계약인가?”에 가깝다. 같은 계약이면 계속 가도 된다. 하지만 입력이 바뀌었거나, 수정 반경이 커졌거나, 검증 기준이 바뀌었다면 그건 연장이 아니라 재계약이다. 나는 이 경계선을 놓치면 에이전트가 나쁜 코드를 만든다기보다, 좋은 속도로 엉뚱한 문제를 해결하는 상태가 된다고 느낀다.
네 가지 만료 신호
첫 번째 신호는 시간이다. 한 세션이 너무 오래 열려 있으면, 앞쪽 맥락은 아직 보이더라도 판단의 무게가 흐려진다. 이때 “토큰이 남았으니 계속”이 아니라 “이 계약을 30분 더 들고 갈 이유가 있는가”를 본다. 작업이 단순하면 괜찮지만, 실패 원인을 여러 번 바꾸며 추적했다면 계약 만료에 가깝다. 나는 보통 같은 실패를 세 번 이상 다른 방식으로 설명하게 되면 여기서 한 번 끊는다.
두 번째 신호는 입력이다. 새 로그, 새 스크린샷, 새 요구사항, 새 파일 범위가 들어오면 기존 계약은 자동으로 연장되지 않는다. 특히 “아, 이것도 같이 봐줘”가 붙는 순간 조심해야 한다. 그 말이 작은 참고인지, 목표 자체를 바꾸는 입력인지 구분하지 않으면 에이전트는 참고 자료를 곧바로 수정 근거로 승격시킨다. 이럴 때는 새 입력을 바로 붙이지 말고, 필수 입력인지 보류 입력인지 먼저 나눠 둔다.
세 번째 신호는 검증 기준이다. 처음에는 단위 테스트 하나가 기준이었는데 중간에 실제 화면 확인, 배포 빌드, 성능 로그가 중요해질 수 있다. 검증 기준이 바뀌면 작업의 끝도 바뀐다. 이 상태에서 기존 계약 그대로 수정만 이어 가면 마지막에 “테스트는 통과했는데 원하는 상태는 아니다”라는 찜찜한 결과가 남는다. 검증 기준이 바뀌는 순간에는 수정 전에 검증 문장을 먼저 다시 쓰는 편이 안전하다.
네 번째 신호는 인수인계다. 에이전트가 계속 고칠 수는 있지만, 사람이 다시 봐야 하는 판단이 늘어난다면 세션을 닫아야 한다. 예를 들어 UI 문구 선택, 데이터 삭제 여부, 외부 API 요금이 걸린 실행, 기존 설계와 충돌하는 변경은 자동으로 밀어붙일 문제가 아니다. 이때는 “계속 진행” 대신 snapshot을 남기고, 새 요구사항은 parking lot에 빼고, 다음 세션에서 작은 계약으로 다시 여는 쪽이 낫다.
내가 쓰는 짧은 문장
실제로는 긴 템플릿보다 짧은 문장이 더 잘 먹힌다. 나는 세션 중간에 다음처럼 끊어 묻는다. “지금 작업 계약이 아직 유효한지 먼저 점검해줘. 목표, 허용 파일, 새로 들어온 입력, 남은 검증을 네 줄로 쓰고, 계약이 만료됐으면 수정하지 말고 handoff만 남겨.” 이 정도만 넣어도 에이전트가 무작정 다음 patch로 들어가는 흐름을 꽤 줄일 수 있다.
중요한 건 이 문장을 실패한 뒤에만 쓰지 않는 것이다. 오히려 작업이 잘 풀리는 중간에 한 번 넣는 편이 낫다. 잘 풀릴 때는 diff가 빠르게 커지고, 사람이 “아 이 정도면 거의 됐네”라고 생각하면서 확인을 미룬다. 그 순간에 계약 유효성을 묻는 짧은 체크를 넣으면, 에이전트가 지금까지 한 일을 멈춤 지점 기준으로 다시 정렬한다.
나는 특히 세 가지 상황에서 이 체크를 거의 고정으로 넣는다. 첫째, 새 파일을 세 개 이상 열어야 할 때. 둘째, 원래 요청에 없던 요구사항이 붙었을 때. 셋째, 검증이 한 번 실패한 뒤 원인 설명이 바뀌었을 때. 이 셋은 모두 “아직 같은 작업인가”가 흔들리는 지점이다. 여기서 계약을 다시 쓰지 않으면, 나중에는 어떤 변경이 원래 목표였고 어떤 변경이 중간에 붙은 것인지 추적하기가 힘들어진다.
닫는 것도 작업이다
바이브코딩을 하다 보면 새로 여는 능력만 늘기 쉽다. 새 모델을 붙이고, 새 도구를 켜고, 새 빌더로 초안을 만들고, 새 세션으로 이어 간다. 그런데 실제 품질 차이는 닫는 쪽에서 많이 난다. 어디까지가 이번 작업이고, 어디서부터는 다음 작업인지 가르지 않으면 에이전트는 계속 성실하게 움직이지만 저장소는 점점 설명하기 어려워진다.
그래서 만료 조건은 속도를 늦추는 장치라기보다, 다음 속도를 보존하는 장치에 가깝다. 오래 열린 세션을 억지로 끌고 가는 대신 작은 snapshot으로 접고, 새 입력은 보류 목록으로 빼고, 검증 기준을 다시 써서 다음 계약을 연다. 이렇게 하면 한 번의 긴 대화가 흐릿한 덩어리로 남지 않고, 여러 개의 짧은 작업 단위로 나뉜다. 나는 이 차이가 나중에 코드를 되돌리거나 동료에게 설명할 때 꽤 크게 돌아온다고 본다.
에이전트에게 일을 잘 맡기는 감각은 결국 “언제 더 시킬지”와 “언제 닫을지”를 같이 배우는 쪽에 있다. 만료 조건을 붙여 두면 닫는 결정이 기분이나 피로도에만 기대지 않는다. 시간, 입력, 검증, 인수인계 중 하나가 선을 넘었는지만 보면 된다. 단순하지만, 긴 세션에서 이 한 줄이 생각보다 많은 사고를 막아 준다.
'[개발 깨알 상식_Tips] > [바이브코딩 Tips]' 카테고리의 다른 글
| 출력 형태부터 정하고 도구를 맡기기 (0) | 2026.05.27 |
|---|---|
| 재현 명령: 넘겨받을 작업의 첫 줄 (0) | 2026.05.26 |
| 작업 중 끼어든 요구는 따로 빼기 (1) | 2026.05.21 |
| 권한 계단: 읽기 전용에서 수정까지 한 칸씩 (0) | 2026.05.20 |
| 검증 레인: 만든 세션과 확인 세션 분리 (0) | 2026.05.19 |