바이브 코딩 앱의 첫째 날은 당신이 지금까지 선보인 데모 중 최고의 데모일 것입니다. 프롬프트는 작동했고, 화면은 깔끔하며, 데이터베이스에는 데이터가 들어 있고, 화면 녹화 영상과 함께 트윗을 올렸을 것입니다. 우리도 그런 날을 많이 겪어봤습니다. 우리는 그 기쁨을 뺏으려는 것이 아닙니다.
우리가 말하려는 것은 ‘둘째 날’에 관한 것입니다. 그 누구의 런칭 스레드에서도 이를 다루지 않기 때문입니다. 둘째 날은 실제 사용자가 로그인해 당신이 생각지도 못한 행동을 하고, 당신의 앱이 “생성된 것(generated)“과 “설계된 것(engineered)” 사이의 간극을 마주하는 날입니다.
둘째 날의 실제 모습
드물게 처음부터 완전히 뻗어버리며 시작하지는 않습니다. 보통 이상한 일들로 시작됩니다. 엉뚱한 값을 받아들이는 폼, 특정 사용자에게만 깨지는 페이지, 아무도 재현할 수 없는 방식으로 틀린 숫자 같은 것들이죠. 당신은 그 오류를 채팅창에 붙여넣습니다. AI는 자신만만하게 수정합니다. 그리고 그 수정이 다른 무언가를 망가뜨립니다.
프롬프트 두더지 잡기 게임에 오신 것을 환영합니다. AI는 근본 원인이 아니라 증상을 수정하기 때문에, 패치 위에 패치가 쌓이게 되고 코드베이스는 빌더들이 말하는 ‘프랑켄슈타인 코드’가 됩니다. 서로 충돌하는 스타일, 중복된 함수, 인터페이스 코드 안에 데이터베이스 쿼리가 들어있는 엉킨 로직의 누더기가 되는 것이죠. 프로젝트가 AI의 컨텍스트 윈도우를 넘어서면, 모델은 자신의 이전 결정들을 잊기 시작하고 그와 모순되는 코드를 제안합니다. 이제 당신은 앱을 유지보수하는 것이 아니라, 앱과 협상을 하고 있는 것입니다.
더 잔인한 변종도 있습니다. 바로 ‘조용한 배포 실패’입니다. 호스팅 빌드가 사소한 오류로 실패했는데, 라이브 URL에는 계속 이전 버전이 표시됩니다. 변경 사항이 없는 것을 본 당신은 AI에게 수정 사항이 “작동하지 않았다”고 말합니다. 그러면 AI는 이미 해결된 문제에 대해 완전히 다르고 더 복잡한 해결책을 생성합니다. 몇 라운드 후, 당신은 v1으로도 충분했던 코드의 비대해진 v5 버전을 갖게 됩니다.
보이지 않는 부분
디버깅 런닝머신은 적어도 눈에 보입니다. 하지만 보안 문제는 보이지 않으며, 이것이 바로 우리가 비즈니스 빌드에 대해 이토록 단호하게 말하는 이유입니다.
관련 연구 결과는 상당히 충격적입니다. LLM이 생성한 코드는 약 90%의 확률로 성공적으로 컴파일되지만, 그중 약 45%는 로그인 확인 우회, 인젝션 결함과 같은 OWASP Top 10 보안 취약점을 포함하고 있습니다. AI 도구는 ‘데모가 작동하는 것’에 최적화되어 있어 예측 가능한 지름길을 택하곤 합니다. 예를 들어, 누구나 페이지 수정만으로 우회할 수 있도록 브라우저 쪽에 액세스 제어를 구현하거나, 빌드 중 오류가 나지 않게 데이터베이스 권한을 완전히 개방하고, 환경 변수의 개념을 모르기에 API 키를 파일에 하드코딩하는 식입니다. 이렇게 작성된 파일들이 공개 GitHub 저장소에 푸시되면, 크리덴셜 스캐너들이 이를 즉각 찾아냅니다.
이것이 특히 ‘데이 투(Day Two, 출시 이후 운영 단계)‘의 문제가 되는 이유는 간단합니다. 취약점이 있는 앱도 겉으로는 완벽하게 작동하기 때문입니다. “클라이언트 A가 기술적으로 클라이언트 B의 레코드를 읽을 수 있다”는 식의 오류 메시지는 뜨지 않습니다. 운이 좋으면 사용자로부터 알게 되겠지만, 그렇지 않다면 훨씬 끔찍한 상황을 맞이하게 됩니다. 그리고 “그냥 테스트해 보세요!”라는 일반적인 조언은 현실의 벽에 부딪힙니다. 비기술자 빌더는 정상적인 시나리오(Happy Path)만 테스트하는 반면, 실제 문제는 동시성 버그나 데모에서는 필요 없었기에 AI가 생성하지 않은 비밀번호 재설정 흐름 같은 엣지 케이스(Edge Case)에 숨어 있기 때문입니다.
아무도 목록에 넣지 않는 유지보수 부채
이런 방식이 몇 달간 쌓이면 기술 부채의 ‘고금리 사채’ 같은 상황이 벌어집니다. 지금은 소프트웨어를 즉시 얻지만, 나중에는 복리로 이자를 갚아야 하는 것이죠. AI가 택한 모든 지름길은 미래의 수정 과제가 됩니다. 수정할 때마다 크레딧을 더 쓰고 코드 bloat(불필요한 코드 팽창)는 심해집니다. 플랫폼 업데이트가 배포되어 건드리지 않은 기능이 망가지기도 합니다. 프롬프트 기반 앱 플랫폼을 사용하는 장기 빌더들은 플랫폼 자체의 회귀 오류(Regression)를 처리하기 위해 고객에게 매달 유지보수 비용을 청구하고 있다고 말합니다.
여기에 이 상황의 씁쓸한 역설이 있습니다. 바이브 코딩(Vibe Coding)은 소프트웨어 개발의 민주화를 약속했지만, 실제 서비스 앱의 경우 ‘기술 부채의 민주화’를 가져왔을 뿐입니다. 비기술자 빌더는 결국 AI를 통해 피하고 싶었던 바로 그것, 즉 ‘개발자의 판단력이 필요한 코드베이스’를 떠안게 됩니다. 문제는 이제 그 코드가 사업의 핵심 지탱 구조가 되었는데, 정작 본인은 읽을 수 없다는 점입니다.
정직한 선택의 기로
그렇다면 실제로 어떻게 해야 할까요? 수많은 빌드 경험과 시행착오 끝에, 우리는 두 가지 정직한 경로 중 하나를 선택해야 한다고 생각합니다. 그 사이의 어설픈 타협안만이 유일한 오답입니다.
첫 번째 경로: 코드 유지보수 배우기. 이 분야에 깊게 빠져들 준비가 되었다면, 바이브 코딩은 함정이 아니라 강력한 가속기가 됩니다. AI 에이전트가 쓴 코드를 읽으세요. 앱을 배포하기 전에 RLS(Row Level Security)가 무엇인지 배우세요. 프롬프트 전용 도구에서 벗어나 코드가 곧 인터페이스가 되어 실제 판단력을 기를 수 있는 Cursor나 Replit로 넘어가세요. 이 길은 정말 훌륭합니다. 다만 수개월의 학습 시간이 필요한 ‘과정’일 뿐이며, 읽지도 않은 코드를 고객에게 배포하며 마치 이 길을 걷고 있는 척하는 것이 바로 함정입니다.
두 번째 경로: 위험한 부분은 생성형 AI가 아닌 탄탄한 기반 위에 구축하기. 내 앱이 비즈니스 도구(클라이언트 포털, 트래커, 내부 CRM 등)라는 점을 인정하세요. 그리고 앱의 80%를 차지하는 인증, 권한 설정, 비밀번호 재설정, 데이터 액세스와 같은 ‘배관 작업’이 AI가 가장 취약한 부분이라는 점을 인지해야 합니다. 이런 핵심 기능은 Softr와 같은 노코드 플랫폼에서 구축하세요. 이곳의 배관 시스템은 시각적으로 설정하는 검증된 인프라이며, AI Co-Builder를 통해 초기 구축 속도는 그대로 유지할 수 있습니다. 커스텀 디자인이 필요할 때만 바이브 코딩 블록을 사용하여 생성된 코드를 단일 컴포넌트로 제한하세요. 그러면 AI가 지붕을 무너뜨리지 않고 집을 예쁘게 꾸밀 수 있습니다. 이 경로에서의 ‘데이 투’는 고고학적 발굴이 아니라 단순한 수정 작업이 됩니다. 이것이 Softr가 우리의 클라이언트 포털 순위에서 1위를 차지한 이유입니다.
프로토타입, 장난감, 주말 실험 같은 즐거운 작업에는 마음껏 바이브 코딩을 활용하세요. 이런 도구들이 가장 빛을 발하는 영역입니다. 다만 실제 사용자가 나타나기 전에, 당신이 어떤 경로 위에 서 있을지 결정하십시오. ‘데이 투’의 문제는 친절하게 기다려주지 않습니다.