바이브 코딩으로 만든 앱의 첫날은 당신이 해본 최고의 데모일 것입니다. 프롬프트는 제대로 작동했고, 화면은 깔끔하며, 데이터베이스에는 데이터가 들어 있고, 화면 녹화 영상과 함께 트윗을 올렸을 겁니다. 우리는 그런 날을 많이 겪어봤습니다. 우리가 그것을 뺏으러 온 것이 아닙니다.
우리가 이야기하려는 것은 둘째 날입니다. 그 누구의 런칭 스레드에서도 이를 다루지 않기 때문입니다. 둘째 날은 실제 사용자가 로그인해서 당신이 테스트할 생각조차 못 했던 행동을 하고, 당신의 앱이 “생성된 것”과 “엔지니어링된 것” 사이의 간극에 직면하는 시점입니다.
둘째 날의 실제 모습
드물게 크래시로 시작됩니다. 보통은 이상한 일들로 시작하죠. 쓰레기 값이 입력되는 폼, 특정 사용자에게만 깨지는 페이지, 아무도 재현할 수 없는 방식으로 틀린 숫자 같은 것들입니다. 당신은 에러를 채팅창에 붙여넣고, AI는 자신 있게 수정합니다. 그리고 그 수정 사항이 다른 무언가를 망가뜨립니다.
프롬프트 두더지 잡기에 오신 것을 환영합니다. AI는 근본 원인이 아니라 증상을 수정하기 때문에, 패치가 겹겹이 쌓이면서 코드베이스는 빌더들이 말하는 ‘프랑켄슈타인 코드’가 됩니다. 서로 충돌하는 스타일, 중복 함수, 데이터베이스 쿼리가 인터페이스 코드 안에 들어 있는 엉킨 로직의 누더기가 되는 것이죠. 프로젝트가 AI의 컨텍스트 윈도우를 넘어서면, 모델은 자신의 이전 결정을 잊기 시작하고 그와 모순되는 코드를 제안합니다. 이제 당신은 앱을 유지 관리하는 것이 아니라, 앱과 협상하고 있는 것입니다.
더 잔인한 변종도 있습니다. 바로 조용한 배포 실패입니다. 호스팅 빌드가 사소한 에러로 실패했는데 라이브 URL은 계속 이전 버전을 보여주고, 변화가 없는 것을 본 당신은 AI에게 수정 사항이 “작동하지 않았다”고 말합니다. 그러면 AI는 이미 해결된 문제에 대해 완전히 다르고 더 복잡한 솔루션을 생성합니다. 몇 차례 반복하고 나면, v1으로도 충분했던 코드가 비대해진 v5가 되어 있을 것입니다.
보이지 않는 부분
디버깅의 쳇바퀴는 최소한 눈에라도 보입니다. 하지만 보안 문제는 보이지 않으며, 이것이 우리가 비즈니스 빌드에 대해 엄격하게 말하는 이유입니다.
이 분야의 연구 결과는 정말 불편합니다. LLM이 생성한 코드는 약 90%의 확률로 성공적으로 컴파일되지만, 약 45%는 우회 가능한 로그인 체크, 인젝션 결함 같은 OWASP Top 10 취약점을 포함하고 있습니다. AI 도구는 데모가 작동하는 것에 최적화되어 있으며, 이는 예측 가능한 지름길을 만듭니다. 페이지 편집만으로 누구나 우회할 수 있는 브라우저 기반의 액세스 제어, 빌드 중 에러가 나지 않도록 완전히 개방된 데이터베이스 권한, 그리고 빌더가 환경 변수가 무엇인지 몰라서 파일에 하드코딩된 API 키 같은 것들입니다. 그리고 이 파일들은 공개 GitHub 저장소로 푸시되어, 정해진 일정대로 자격 증명 스크래퍼들에게 발견됩니다.
이것이 특히 둘째 날의 문제인 이유는, 취약한 앱은 완벽하게 작동하기 때문입니다. “클라이언트 A가 기술적으로 클라이언트 B의 레코드를 읽을 수 있다”는 에러 메시지는 뜨지 않습니다. 운이 좋다면 사용자로부터 알게 되겠지만, 운이 나쁘면 훨씬 끔찍한 방식으로 알게 됩니다. 그리고 “그냥 테스트하세요!”라는 표준적인 조언은 현실과 충돌합니다. 비기술직 빌더들은 해피 패스만 테스트하지만, 실패는 엣지 케이스, 즉 동시성 버그나 데모에서는 필요 없었기에 AI가 생성하지 않은 비밀번호 재설정 흐름 같은 곳에 숨어 있기 때문입니다.
아무도 항목화하지 않는 유지보수 부채
이런 메커니즘이 몇 달 동안 쌓이면, 우리는 이를 기술 부채의 사채라고 생각하게 됩니다. 지금 당장 소프트웨어를 얻는 대신 나중에 복리 이자를 내는 꼴이죠. AI가 택한 모든 지름길은 미래의 수정 사항이 됩니다. 모든 수정은 더 많은 크레딧 소모와 약간의 코드 비대화로 이어집니다. 플랫폼 업데이트가 배포되어 건드리지 않은 부분이 망가지기도 합니다. 프롬프트 기반 앱 플랫폼의 장기 빌더들은 플랫폼 자체의 회귀 오류를 처리하기 위해 고객에게 월간 유지보수 비용을 청구한다고 보고합니다.
이것이 이 상황의 중심에 있는 씁쓸한 농담입니다. 바이브 코딩은 소프트웨어의 민주화를 약속했지만, 프로덕션 앱의 경우 대부분 기술 부채의 민주화를 가져왔습니다. 비기술직 빌더는 결국 AI를 사용해 피하려 했던 바로 그것, 즉 개발자의 판단이 필요한 코드베이스를 떠안게 됩니다. 다만 이제는 그것이 비즈니스의 핵심 지지대가 되었는데, 정작 읽을 수는 없는 상태라는 점이 다릅니다.
정직한 선택지
그렇다면 실제로 어떻게 해야 할까요? 많은 빌드와 몇 번의 상처를 겪은 끝에, 우리는 이것이 두 가지 정직한 경로가 있는 갈림길로 귀결된다고 생각합니다. 그리고 정직하지 않은 중간 지점이 유일한 오답입니다.
첫 번째 경로: 코드 유지 관리 배우기. 이것을 충분히 사랑해서 더 깊이 파고들고 싶다면, 바이브 코딩은 함정이 아니라 정당한 가속기가 됩니다. 에이전트가 작성한 내용을 읽으세요. RLS가 무엇인지 배우고 그것에 의존하는 앱을 배포하세요. 프롬프트 전용 도구에서 Cursor나 Replit로 넘어가세요. 그곳에서는 코드가 인터페이스가 되며 실제적인 판단력을 기를 수 있습니다. 이 경로는 진심으로 훌륭합니다. 다만 수개월의 시간이 걸리는 여정일 뿐입니다. 읽지도 않은 코드를 고객에게 배포하면서 이 경로에 있다고 착각하는 것이 바로 함정입니다.
두 번째 경로: 위험한 부분은 생성되지 않은 기반 위에 두기. 당신의 앱이 비즈니스 도구, 즉 클라이언트 포털, 트래커, 내부 CRM이라는 점을 인정하세요. 그리고 그 기능의 80%가 AI가 가장 못 만드는 배관 작업, 즉 인증, 권한, 비밀번호 재설정, 데이터 액세스라는 점에 주목하세요. 이런 카테고리는 Softr와 같은 노코드 플랫폼에서 구축하세요. 이곳의 배관은 시각적으로 설정하는 검증된 인프라이며, AI Co-Builder는 여전히 첫날의 속도를 제공합니다. 커스텀 스타일을 원할 때, 바이브 코딩 블록은 생성된 코드를 단일 컴포넌트로 제한하므로 AI가 지붕을 무너뜨리지 않고 집을 꾸밀 수 있습니다. 이 경로에서의 둘째 날은 고고학적 발굴이 아니라 단순한 수정이 됩니다. 이것이 Softr가 우리의 클라이언트 포털 순위에서 1위를 차지하는 이유입니다.
재미있는 것들은 계속 마음껏 바이브 코딩으로 만드세요. 프로토타입, 장난감, 주말 실험들은 바로 이런 도구들이 가장 빛나는 영역입니다. 다만 실제 사용자가 나타나기 전에, 당신이 갈림길의 어느 쪽에 서 있을지 결정하세요. 둘째 날은 정중하게 묻지 않습니다.