바이브코딩 한계 — 고칠수록 다른 곳이 깨질 때 멈출 기준
로그인은 고쳤는데 결제가 깨지고, 결제를 되돌리니 로그인 오류가 다시 나타납니다. 이럴 때 프롬프트를 더 길게 쓰는 것이 답은 아닐 수 있습니다. 우선 같은 오류가 반복되는지, 관련 기능을 함께 확인할 테스트가 있는지부터 살펴봐야 합니다.
바이브코딩이 언제 막히는지는 프로젝트마다 다릅니다. 기능, 위험, 코드 상태가 다르기 때문입니다. 대신 작업 방식을 바꿔야 하는 신호는 구체적으로 확인할 수 있습니다.
혼자 계속해도 되는지는 실패 비용으로 판단합니다
화면 시안, 버릴 수 있는 프로토타입, 소수 팀원이 쓰는 내부 도구처럼 실패했을 때 영향이 제한된 작업은 시행착오를 감당하기 쉽습니다. 단순한 CRUD 앱도 요구가 명확하고 테스트할 수 있다면 AI 도구가 많은 부분을 도울 수 있습니다.
반드시 혼자 끝낼 수 있다는 뜻은 아닙니다. 중요한 기준은 문제가 생겨도 되돌릴 수 있는가입니다. 같은 CRUD라도 개인정보를 저장하거나 외부 고객이 쓰기 시작하면 이야기가 달라집니다.
기능보다 위험이 먼저 커지는 지점
다음 요소가 붙으면 코드가 화면에서 잘 돌아가는 것만으로는 충분하지 않습니다.
- 결제: 금액은 서버에서 다시 계산하고, 웹훅 서명을 검증하며, 같은 이벤트를 두 번 처리하지 않도록 해야 합니다.
- 개인정보: 인증뿐 아니라 사용자별 권한, 보관 기간, 삭제와 사고 대응까지 고려해야 합니다.
- 여러 사용자의 동시 작업: 같은 데이터를 동시에 바꿀 때 충돌과 상태 불일치가 생길 수 있습니다.
- 운영 의존성: 배포, 모니터링, 백업, 장애 복구는 기능 구현과 다른 종류의 일입니다.
관리형 서비스를 쓰면 직접 구현할 범위는 줄어듭니다. 하지만 Supabase의 책임 공유 안내처럼 데이터와 접근 권한, 애플리케이션 설정에 대한 책임까지 사라지는 것은 아닙니다.
후반부가 느린 것은 고정된 임계점 때문이 아닙니다
초반에는 화면과 핵심 동작이 빠르게 생깁니다. 뒤로 갈수록 기능 사이 연결, 예외 처리, 이전 데이터, 테스트, 보안, 배포 조건이 한꺼번에 드러납니다. 눈에 보이는 기능 수보다 서로 맞물리는 경계가 늘어나는 시기입니다.
AI가 한 번에 참고하는 대화와 파일의 양도 영향을 줍니다. Anthropic은 문맥에 들어가는 토큰이 많아질수록 모델이 그 안의 정보를 정확히 떠올리는 능력이 떨어질 수 있는 ‘context rot’을 설명합니다. 파일 수 자체에 고정된 실패선이 있는 것은 아닙니다. 관련 없는 파일과 긴 대화가 섞이거나 변경 범위가 불명확하면 앞선 결정을 놓칠 가능성이 커진다고 이해하면 됩니다.
그래서 "완성 직전에 갑자기 한계가 왔다"기보다, 구현해야 할 기능보다 검증해야 할 연결부가 더 빨리 늘기 시작했다고 보는 편이 정확합니다.
멈추고 도움을 받을 세 가지 신호
수정이 제자리로 돌아옵니다
A를 고치면 B가 깨지고, B를 고치면 A가 다시 깨지는 패턴이 반복됩니다. 이때는 새 수정을 지시하기 전에 재현 절차와 테스트를 먼저 고정해야 합니다. 같은 오류가 며칠째라는 시간 자체보다, 수정 결과가 회귀 테스트를 통과하지 못한다는 점이 신호입니다.
맞는 결과인지 확인할 방법이 없습니다
인증·권한·결제·데이터 복구처럼 화면만 보고 안전성을 판단할 수 없는 기능이 생겼는데, 테스트가 없거나, 로그가 있어도 이를 해석해 안전성을 판단할 수 없습니다. 구현보다 검증 공백이 큰 상태입니다. 이 구간은 범위를 정한 코드 리뷰나 보안 검토가 도움이 됩니다.
실패했을 때 다른 사람이 피해를 봅니다
실사용자의 돈이나 데이터를 다루기 시작했거나, 장애가 영업에 영향을 줍니다. 이때부터는 "일단 배포하고 고치기"의 비용이 달라집니다. 출시 전 검토, 백업, 롤백, 모니터링을 작업 범위에 넣어야 합니다.
전체 외주 말고 범위를 줄여 맡길 수도 있습니다
먼저 기능 추가를 잠시 멈추고 현재 동작하는 버전을 저장하세요. 재현 절차, 기대 결과, 실제 결과, 관련 로그를 한 문서에 모으면 AI에게 다시 맡기든 개발자에게 보여 주든 출발점이 같아집니다.
그다음 도움을 구할 범위를 작게 정합니다.
- 인증과 사용자별 권한만 검토
- 결제 요청과 웹훅 처리만 검토
- 배포 설정과 API 키·환경변수만 검토
- 반복해서 깨지는 기능의 테스트부터 작성
"앱을 완성해 주세요"보다 검토 대상과 완료 조건을 적은 요청이 견적과 결과를 비교하기 쉽습니다. 수정 후 같은 테스트를 다시 돌리는 것까지 의뢰 범위에 포함하세요.
다음 프롬프트 전에 남겨 둘 기록
전문가에게 바로 넘기지 않더라도 다음 네 가지는 작성해 두는 편이 좋습니다.
- 오류가 재현되는 클릭 순서와 계정 상태
- 마지막으로 정상 작동했던 커밋
- AI가 바꾼 파일과 바꾼 이유
- 수정 뒤 반드시 통과해야 하는 테스트
이 기록이 있으면 문제를 다시 설명하느라 시간을 쓰지 않고, 수정이 다른 기능을 되돌려 놓았는지도 확인할 수 있습니다. 바이브코딩의 한계는 도구를 포기하라는 선이 아니라, 구현보다 검증과 운영이 중요해졌다는 표시입니다.