바이브 코딩의 처음 80%는 빠르게 느껴지지만, 나머지 20%는 정말 지치네요.
The first 80% of vibe coding feels fast. The last 20% has been exhausting.
핵심 요약
AI를 활용한 바이브 코딩으로 빠르게 프로토타입을 만들 수 있지만, 실제 서비스 배포를 위한 유지보수와 아키텍처 설계 단계에서 큰 어려움을 겪고 있습니다.
- 바이브 코딩의 한계 — 프로토타입 이후 유지보수와 아키텍처 설계가 매우 어려움
- 복잡한 요구사항 — 결제, 보안, 데이터 무결성 등 실제 서비스 운영을 위한 기능 구현의 고충
- AI의 단점 — 전체 아키텍처를 고려하지 않고 당장의 문제만 해결하려는 경향
- 경험 공유 요청 — 프로토타입을 넘어 실제 운영 가능한 수준으로 코드를 관리하는 방법
바이브 코딩을 정말 즐기고 있어. 덕분에 아이디어를 예전보다 훨씬 빠르게 작동하는 소프트웨어로 바꿀 수 있었거든.
하지만 가장 큰 고통은 앱이 이미 완성된 것처럼 보인 후에 시작됐어.
인증은 작동했지만, 그다음엔 인가(authorization)에 대해 고민해야 했고 모든 사용자가 자신의 데이터에만 접근할 수 있는지 확인해야 했지. 결제 기능도 작동했지만, 결제 시스템에는 웹훅, 재시도, 중복 이벤트 방지, 구독 상태, 환불, 그리고 접근 제어까지 필요했어.
그다음엔 데이터베이스 마이그레이션, 에러 처리, 속도 제한, 보안 정책, 테스트, 모니터링, 배포 환경 차이, 그리고 AI가 생성한 변경 사항이 다른 곳을 조용히 망가뜨리지 않았는지 확인하는 작업들이 뒤따랐지.
가장 힘든 부분은 유지보수야. 코드베이스가 커질수록 AI는 전체 아키텍처를 이해하지 못한 채 당장의 문제만 해결하곤 해. 작은 기능 하나가 중복 로직이나 일관성 없는 패턴을 만들거나, 나중에 이해하기 어려운 파일들을 양산하기도 하지.
어느 순간부터는 "기능을 설명하고 배포한다"는 느낌이 사라져. 대신 맥락, 경계, 관례, 그리고 사용자는 절대 보지 못하지만 의존하고 있는 모든 지루한 시스템들을 관리하기 시작하게 되지.
여전히 바이브 코딩은 엄청나게 유용하다고 생각해. 단지 데모에서 작동하는 앱과 실제 사용자에게 제공해도 괜찮겠다고 느끼는 앱 사이의 간극이 얼마나 큰지 과소평가했을 뿐이야.
바이브 코딩으로 만든 앱을 프로토타입 단계를 넘어 배포해 본 사람들에게 묻고 싶어. 코드베이스를 이해하기 쉽게 유지하고, 새로운 기능을 추가할 때마다 코드가 더 취약해지지 않게 하려면 어떻게 해야 해?


