로그인을 고쳤더니 결제가 고장났고, 결제를 복원하니 로그인 버그가 다시 나타났습니다. 더 긴 프롬프트로도 이 사이클을 해결할 수 없습니다. 또 다른 수정을 요청하기 전에, 실패가 반복되고 있는지, 관련된 동작이 테스트로 커버되는지 확인하세요.
바이브 코딩이 멈추는 고정된 시점은 없습니다. 답은 제품, 위험성, 코드 상태에 따라 달라집니다. 다른 작업 방식이 필요한 신호는 훨씬 쉽게 알아볼 수 있습니다.
실패 비용을, 기능 수보다 판단하세요
모의 화면, 일회용 프로토타입, 소규모 팀이 사용하는 내부 도구는 실험과 오류를 흡수할 수 있습니다. AI 도구도 요구 사항이 명확하고 동작이 테스트 가능한 CRUD 앱에서는 상당히 도움이 됩니다.
앱이 단독으로 개발되는 보장은 아닙니다. 의미는 오류가 되돌릴 수 있다는 것입니다. 같은 CRUD 앱이 개인 데이터를 저장하거나 고객에게 서비스를 제공하게 되면, 상황이 달라집니다.
위험은 가시적인 제품보다 더 커질 수 있습니다
제품에 포함된 다음 요소가 있으면, 작업 화면만으로는 충분하지 않습니다:
- 결제: 서버는 금액을 계산하고 웹후크 서명을 검증하며, 중복 이벤트 처리를 방지해야 합니다.
- 개인 데이터: 인증은 시작일 뿐입니다. 사용자별 권한, 보유, 삭제, 사고 대응도 중요합니다.
- 동시 사용자: 같은 데이터를 변경하는 두 사람이 충돌과 일관되지 않은 상태를 만들 수 있습니다.
- 운영 의존성: 배포, 모니터링, 백업, 복구는 기능 구현과는 다른 분야입니다.
관리 서비스는 작성해야 할 코드를 줄여줍니다. 하지만 데이터, 액세스 제어, 애플리케이션 구성에 대한 모든 책임을 대신해 주지는 않습니다. Supabase는 이점을 공유된 책임 모델에서 명확히 설명합니다.
마무리 단계는 고정된 비율이 아닙니다
초기 작업은 매우 가시적입니다. 화면이 나타나고 성공적인 경로가 시작됩니다. 후반 작업에서는 기능 간 연결, 오류 경로, 유산 데이터, 테스트, 보안 규칙, 배포 제약이 드러납니다. 가시적인 기능 수는 거의 변하지 않지만, 검증해야 할 경계는 빠르게 증가합니다.
AI 모델의 컨텍스트에 포함된 대화와 코드의 양도 중요합니다. Anthropic은 모델이 정보를 정확하게 검색할 능력이 컨텍스트에 들어오는 토큰이 많아질수록 저하되는 현상을 '컨텍스트 부패'라고 부릅니다. 특정 파일 수의 임계점은 없습니다. 관련 없는 파일과 긴 대화가 컨텍스트를 채우거나, 수정 범위가 제한적이지 않으며 이전 결정이 쉽게 놓치기 쉬울 때 실질적인 위험이 증가합니다.
완료에 가까운 시점에서 갑자기 벽을 만날 때는 종종 검증해야 할 연결이 구현해야 할 기능보다 더 빠르게 증가하고 있는 것일 수 있습니다.
세 가지 신호로 중단하고 도움을 요청해야 합니다
수정이 계속해서 돌아옵니다
A를 수정하면 B가 고장나고, B를 복구하면 A가 다시 고장납니다. 다시 수정을 요청하기 전에 실패가 반복되고 있는지, 그리고 관련된 동작이 테스트로 커버되는지 확인하세요. 중요한 신호는 버그가 며칠 동안 존재했는지가 아니라, 각 수정 시도가 동일한 회귀 검사를 실패하는지입니다.
결과가 올바른지 알 수 없습니다
인증, 권한, 결제, 데이터 복구는 UI만으로는 판단할 수 없습니다. 테스트가 없거나 로그가 있지만 이를 사용해 안전성을 평가할 수 없는 경우, 검증 격차가 구현 격차보다 더 큽니다. 제한된 범위의 코드 검토나 보안 검토가 도움이 됩니다.
실패가 다른 사람에게 피해를 줄 수 있습니다
제품이 실제 고객의 돈이나 데이터를 다루고 있거나, 장애가 수익에 영향을 줄 수 있습니다. '지금 배포하고 나중에 고치자'는 방식은 이제 다른 비용을 지불하게 됩니다. 사전 검토, 백업, 롤백, 모니터링은 이제 범위에 포함되어야 합니다.
더 많은 크레딧을 사용하기 전에 Try to Fix 루프를 끝내세요
Try to Fix과 Attempt Fix는 특정 오류를 노출하고 수정할 때 유용합니다. 하지만 각 시도가 관련 없는 코드를 변경하고 새로운 실패를 만들 때는 비용이 커집니다.
이 중단 규칙을 사용하세요:
- 동일한 증상에 대해 두 번의 자동 수정이 실패하면 에이전트를 중단하세요.
- 정확한 오류, 재현 단계, 변경된 파일 목록을 저장하세요.
- 주요 상호작용을 통과한 마지막 체크포인트를 복원하세요.
- 코드를 수정하지 않고 원인을 묻기 위해 채팅 또는 계획 모드를 사용하세요.
- 한 가지 제한된 수정을 승인하고, 다른 작업을 하기 전에 동일한 검사를 다시 실행하세요.
롤백은 버그가 해결되었음을 증명하지 않습니다. 이는 알려진 기준선을 복원하는 것입니다. 다음 시도가 성공하려면 원래의 재현이 실패하지 않고, 이전에 작동하던 동작이 여전히 통과해야 합니다.
도구가 좁은 수정을 설명하지 못하면 코드를 내보내거나 동기화하고, 범위 제한된 검토를 요청하세요. 같은 에이전트에게 전체 기능을 다시 작성하도록 더 많은 크레딧을 사용하지 마세요.
전체 앱 대신 좁은 검토를 외주할 수 있습니다
기능 작업을 일시 중단하고 현재 작동하는 버전을 보존하세요. 재현 단계, 예상 결과, 실제 결과, 관련 로그를 하나의 문서에 넣어 두세요. 이는 AI 도구와 개발자에게 동일한 시작점을 제공합니다.
그러면 요청을 작게 하세요:
- 인증과 사용자별 권한만 검토
- 결제 요청과 웹후크 처리만 검토
- 배포 설정, API 키, 환경 변수만 검토
- 반복적으로 회귀하는 기능에 대한 테스트를 작성
‘내 앱을 완성해줘’는 가격을 정하고 검증하기 어려운 요청입니다. 대상 범위와 완료 기준이 분명한 요청은 제안과 결과를 비교하기 쉬워집니다. 작업 범위에 수정 후 같은 테스트를 다시 실행하는 절차도 포함하세요.
다음 프롬프트 전에 네 가지 사항을 기록하세요
프로젝트를 아직 이관하지 않더라도 기록하세요:
- 버그를 재현하는 정확한 클릭 경로와 계정 상태
- 작동하는 마지막 커밋
- AI가 변경한 파일과 그 이유
- 다음 수정 후 통과해야 할 테스트
이 기록은 팀이 같은 문제를 반복해서 다시 찾는 일을 막고, 수정 때문에 다른 기능이 조용히 다시 망가졌는지도 보여줍니다. 바이브 코딩의 한계는 도구를 포기하라고 하는 선이 아니라, 검증과 운영이 더 중요해지는 지점입니다.