모델을 바꿔 이어 갈 때 남길 것

시리즈: 바이브코딩 Tips #26

이전: 25편 | 목록 | 다음: 27편

2026년 6월 2일 | 바이브코딩 Tips

---

긴 코딩 작업은 한 모델만 붙잡고 끝까지 가기보다, 빠른 모델과 강한 모델 사이를 오가며 이어지는 경우가 많다. 초안은 가벼운 모델이 빨리 만들고, 까다로운 판단은 더 강한 모델에게 넘기고, 마지막 검증은 또 다른 세션에서 확인하는 식이다. 이 흐름 자체는 나쁘지 않다. 문제는 모델을 바꾸는 순간, 작업의 기준도 같이 흐려질 때다.

나는 예전에는 모델 전환을 거의 성능 선택처럼만 봤다. “이건 어려우니 더 강한 모델로 보내자” 정도의 감각이었다. 그런데 실제로는 성능보다 먼저 사라지는 것이 있다. 어디까지가 확정인지, 무엇을 건드리면 안 되는지, 어떤 검증을 이미 봤는지, 다음 세션이 어디서 멈춰야 하는지다. 이 네 가지가 빠지면 더 좋은 모델을 붙여도 결과가 더 안정적이 되지는 않았다.

모델 전환은 대화 요약이 아니라 기준선·권한·검증·미확인 영역을 넘기는 일에 가깝다.

모델 전환은 요약 문제가 아니었다

세션을 넘길 때 흔히 하는 실수는 대화 전체를 길게 요약하는 것이다. 물론 배경 설명도 필요하다. 하지만 긴 요약만 있으면 다음 모델은 그 요약을 새 출발점으로 믿는다. 앞 세션에서 잠깐 의심했던 가정, 아직 확인하지 않은 화면, 건드리지 않기로 한 파일은 문장 사이에 묻힌다. 그러면 새 모델은 친절하게 이어서 하려다가 오히려 기준을 넓힌다.

특히 빠른 모델에서 강한 모델로 넘길 때 이런 일이 잘 생겼다. 빠른 모델이 만든 초안은 쓸 만하지만 빈칸도 많다. 강한 모델은 그 빈칸을 알아서 채우려는 힘이 있다. 그래서 넘기는 쪽에서 무엇을 채워도 되는지보다 무엇을 아직 믿으면 안 되는지를 먼저 써 두지 않으면, 다음 세션은 그럴듯한 확신으로 미확인 영역을 덮어 버린다.

바뀌는 모델보다 고정할 기준선

내가 먼저 남기려고 하는 것은 기준선이다. 기준선은 “마지막으로 믿을 수 있는 상태”에 가깝다. 특정 commit일 수도 있고, 통과한 테스트 한 줄일 수도 있고, preview에서 확인한 화면 경로일 수도 있다. 중요한 건 새 모델이 작업을 시작하기 전에 “여기까지는 사실로 둔다”와 “여기부터는 다시 확인한다”를 구분할 수 있어야 한다는 점이다.

예를 들어 화면 수정 작업이라면 “데스크톱 폭에서는 버튼 위치 확인, 모바일 폭은 미확인”처럼 적는다. API 작업이라면 “mock 응답 기준 테스트는 통과, 실제 응답 스키마는 아직 미확인”이라고 쓴다. 이 정도 문장은 짧지만 효과가 크다. 다음 모델은 이미 통과한 부분을 다시 넓게 고치지 않고, 미확인 영역을 먼저 검증 대상으로 본다.

권한을 그대로 넘기지 않기

두 번째는 권한이다. 앞 모델에게 읽기 전용으로 맡겼던 작업을, 다음 모델에게 갑자기 수정까지 허용하면 작업 성격이 달라진다. 반대로 앞 모델이 넓게 수정하던 흐름을 다음 모델이 그대로 이어받으면, 원래 의도보다 큰 리팩터링으로 번지기 쉽다. 모델 전환은 단순히 더 똑똑한 작업자에게 넘기는 일이 아니라 권한 계약을 다시 쓰는 순간이다.

나는 그래서 전환 메모에 “이번 턴은 읽기만”, “수정은 이 파일 하나만”, “새 dependency 추가 금지”, “테스트 실패가 재현되지 않으면 수정 중단” 같은 줄을 붙인다. 이 줄이 있으면 강한 모델도 바로 고치기보다 먼저 경계를 확인한다. 좋은 모델일수록 더 많은 대안을 떠올리기 때문에, 허용 범위를 좁혀 두는 편이 오히려 결과를 깨끗하게 만든다.

검증 증거와 미확인 영역을 나눠 쓰기

세 번째는 검증이다. “테스트 통과”라고만 쓰면 너무 넓다. 어떤 테스트인지, 어떤 입력인지, 어떤 화면인지가 빠지면 다음 모델은 성공 기준을 다시 추측한다. 나는 가능한 한 통과한 증거와 아직 못 본 부분을 분리해서 쓴다. 그래야 새 모델이 이미 확인된 것을 반복하지 않고, 확인되지 않은 부분을 성공 조건으로 착각하지 않는다.

기준선: 설정 화면 desktop preview에서 저장 버튼 위치 확인
권한: 수정은 SettingsPanel.tsx 한 파일만, API 라우터 수정 금지
검증: 저장 클릭 후 toast 1회 표시까지 확인, 모바일 폭은 미확인
멈춤: 모바일에서 레이아웃이 깨지면 수정하지 말고 원인 후보만 보고

이 네 줄은 긴 handoff 문서보다 자주 살아남았다. 대화가 압축되어도 남고, 모델이 바뀌어도 남고, 내가 다음 날 다시 봐도 바로 읽힌다. 특히 “미확인” 줄은 생각보다 중요하다. 확인하지 않은 것을 확인한 것처럼 넘기지만 않아도, 다음 세션의 실패가 꽤 줄어든다.

강한 모델에게 바로 수정시키지 않기

모델을 바꾸는 가장 흔한 이유는 막혔기 때문이다. 그래서 새 모델을 열자마자 “이제 고쳐줘”라고 말하고 싶다. 하지만 막힌 상태에서 바로 수정 권한을 열면, 새 모델은 앞 세션의 실패를 재현하기 전에 해결책부터 만든다. 운 좋게 맞을 수도 있지만, 틀리면 실패 원인이 더 깊이 묻힌다.

내 기준으로는 전환 직후 첫 턴을 읽기 전용으로 두는 편이 낫다. “위 네 줄이 현재 상태와 맞는지 먼저 확인하고, 틀리면 수정하지 말고 정정하라” 정도면 충분하다. 이 한 턴이 아깝게 느껴질 때도 있지만, 실제로는 여기서 시간이 많이 줄었다. 잘못된 기준선을 들고 바로 코드를 바꾸는 것보다, 기준선 오류를 먼저 잡는 쪽이 훨씬 싸다.

작게 남겨야 계속 쓴다

모델 전환용 메모를 너무 거창하게 만들면 결국 안 쓴다. 나는 네 줄 이상으로 늘어나는 순간 대화 요약으로 돌아가기 쉽다는 걸 몇 번 겪었다. 그래서 기준선, 권한, 검증, 미확인 영역만 남긴다. 필요하면 그 아래에 참고 링크를 붙이지만, 첫 화면에서 네 줄이 먼저 보여야 한다.

바이브코딩에서 모델을 바꾸는 일은 점점 자연스러워지고 있다. 빠른 모델, 강한 모델, 브라우저형 빌더, 로컬 코딩 에이전트가 같은 작업을 나눠 맡는다. 이때 품질을 가르는 것은 어느 모델이 더 똑똑한지 하나로 끝나지 않는다. 모델이 바뀌어도 판단 기준이 바뀌지 않게 만드는 작은 handoff가 있어야 한다.

작업이 작을 때는 이 절차가 조금 번거로워 보인다. 그래도 모델을 한 번이라도 바꾸는 순간부터는 기록 비용보다 오해 비용이 더 커진다. 특히 화면, 테스트, 배포 설정이 같이 엮인 작업에서는 한 문장의 누락이 다음 세션의 수정 반경을 몇 배로 키운다. 그래서 나는 handoff를 문서화라기보다 속도 제한 장치에 가깝게 본다. 빠르게 넘기기 위한 메모가 아니라, 너무 빠르게 틀어지는 것을 막는 메모다. 이 메모가 있으면 다음 모델이 먼저 질문해야 할 지점도 보이고, 내가 다시 읽을 때도 어디서부터 의심해야 하는지 바로 잡힌다.

내가 믿는 규칙은 단순하다. 모델을 바꿀 때는 요약을 길게 쓰기 전에 기준선을 먼저 남긴다. 권한은 다시 열고, 검증은 통과한 것과 못 본 것을 나눈다. 새 모델의 첫 일은 수정이 아니라 그 네 줄이 맞는지 확인하는 것이다. 이 정도만 지켜도 “더 좋은 모델로 보냈는데 왜 더 엉켰지”라는 허무한 상황을 꽤 줄일 수 있었다.

시리즈: 바이브코딩 Tips #26

이전: 25편 | 목록 | 다음: 27편