AI로 만든 앱이 내 컴퓨터에서만 작동하는 이유
몇 시간 만에 프로토타입은 누구든 만들 수 있다. 하지만 사용자가 실제로 믿고 쓸 수 있는, 안전하고 확장 가능한 제품을 출시하는 건 완전히 다른 이야기다.
지난달, 나는 비개발자 친구가 Lovable을 이용해 48시간 만에 첫 풀스택 앱을 출시하는 것을 옆에서 지켜봤다.
앱은 그녀의 노트북에서 완벽하게 돌아갔다. DB 쿼리는 빠릿빠릿했고, 폼도 잘 작동했으며, UI는 꽤 세련됐다. 그녀는 진심으로 행복해했다. 당연한 반응이었다. 전통적인 방식으로 배웠다면 6개월이 걸렸을 일을 해낸 것이니까.
그런데 2주 후, 첫 번째 유료 고객이 문의를 해왔다. 자신의 결제 대시보드에 다른 고객의 거래 내역이 보인다는 것이었다.
그녀는 작동하는 앱을 만들었다. 하지만 안전한 앱은 만들지 못했다.
이건 드문 비극이 아니다. 바이브 코딩 시대의 가장 전형적인 실패 패턴이 되어가고 있다.
바이브 코딩의 현실: 혁명과 함정 사이
Cursor, Lovable, Bolt.new, v0 같은 AI 개발 도구들은 소프트웨어 개발을 눈부시게 민주화했다. Y Combinator의 2025년 겨울 배치에서는 스타트업의 25%가 코드베이스의 95% 이상을 AI로 생성했다고 보고했다. Lovable은 매일 25,000개 이상의 프로젝트를 생성하며, 6개월 만에 연매출 500억 원을 달성했다. 이 변화는 현실이고, 되돌릴 수 없다.
하지만 여기서 과대광고가 말해주지 않는 것이 있다. "작동하는 프로토타입"과 "프로덕션 레디 제품" 사이에는 거대하고 눈에 보이지 않는 간극이 있다. 그리고 대부분의 비개발자들은 그 함정을 향해 곧장 걸어 들어가고 있다.
39 %의 자신감 격차. 이게 바로 문제의 핵심이다. 바이브 코딩은 작동을 멈추기 전까지는 마법처럼 느껴진다. 그리고 멈추는 순간, 대부분의 비개발자들은 왜 멈춘지 이해할 정신적 모델이 없다.
보이지 않는 복잡성의 벽
언제나 비슷한 시점에 이 벽에 부딪힌다.
복잡성의 벽이 나타나는 시점
코드가 500줄에서 5,000줄로 늘어날 때
로컬호스트에서 실제 프로덕션 DB로 이전할 때
두 명의 사용자가 같은 작업을 동시에 시도할 때
민감한 데이터를 저장하거나 처리해야 할 때
N+1 쿼리 루프로 API 비용이 급등할 때
파일 하나의 버그가 관련 없어 보이는 기능들을 망가뜨릴 때
이 시점에서 AI의 컨텍스트 윈도우는 한계를 드러내기 시작한다. 세 번의 프롬프트 전에 내렸던 아키텍처 결정을 잊어버린다. 기존 함수를 재활용하는 대신 새 함수를 환각으로 만들어낸다. 버그를 고치려다 브레이킹 체인지를 들여온다.
그래서 "바이브 디버깅"이 시작된다. 에러 메시지를 다시 AI에 붙여넣고 다음 시도가 나아지길 바라는 것이다.
시니어 개발자들이 AI 생성 코드를 검토하고 수정하는 데 업무 시간의 약 30%를 쓴다는 보고가 있다. AI가 작성한 코드가 인간이 작성한 코드보다 주요 결함을 1.7배 더 많이, 보안 취약점을 2.74배 더 많이 포함하기 때문이다.
아무도 말하지 않는 보안 위기
인프라 팀을 밤새 잠 못 들게 하는 수치가 있다. AI 생성 코드의 40~48%가 심각한 보안 취약점을 포함한다는 것이다. 5%도 아니고, 10%도 아니다. 거의 절반이다.
2025년 3월, Lovable로 만들어진 앱의 보안 감사에서 170개 프로젝트가 Supabase 백엔드의 Row-Level Security 정책 누락으로 민감한 고객 데이터를 유출하고 있었다는 것이 밝혀졌다. 앱들은 기능적으로 완벽했다. DB는 연결되어 있었고, 폼도 작동했으며, 인증도 구현되어 있었다. 단지 데이터가 보호되지 않았을 뿐이다.
비개발자 빌더는 Row-Level Security 정책에 대해 AI에게 물어볼 생각조차 하지 않는다. 그 개념 자체를 모르기 때문이다. 프로덕션 DB에 로그인 시스템이 있으면 앱이 안전하다고 당연히 생각한다. 합리적인 가정이다. 하지만 치명적으로 틀렸다.
가이드 없는 AI 개발의 기본 취약점
API 키가 프론트엔드 코드에 하드코딩 (서버 측 환경 변수 대신)
클라이언트 측 전용 인증 (결심한 사용자는 우회 가능)
DB 제약 조건 누락
검증되지 않은 사용자 입력
누구든 엔드포인트를 공격할 수 있는 와일드카드 CORS 정책
이것들은 예외 사항이 아니다. 가이드 없는 AI 개발의 기본 출력값이다. 그리고 비용이 크다. 유출된 API 키 하나로 수백만 원의 원치 않는 청구서를 받을 수 있다. Row-Level Security 정책 하나의 누락이 규제 과태료나 고객 신뢰 붕괴로 사업을 날려버릴 수 있다.
아키텍처 드리프트: AI가 자기 코드를 유지하지 못하는 이유
코드 3,000~5,000줄 즈음에서 AI 생성 애플리케이션에는 예측 가능한 일이 일어난다. 썩기 시작한다.
AI는 이전에 내렸던 결정을 잊는다. 재사용 대신 로직을 복제한다. 중복된 DB 호출을 들여온다. 처음 백 번의 프롬프트에서 확립했던 아키텍처 패턴을 위반한다. 그리고 수정을 거듭할수록 코드베이스는 더욱 복잡해진다.
이 현상을 아키텍처 드리프트라고 부른다. 컨텍스트 윈도우 한계의 직접적인 부산물이다. LLM은 전체 코드베이스를 메모리에 담을 수 없다. 주변 코드와 프롬프트에서 제공한 히스토리만 볼 수 있다. 일정 규모를 넘으면 계기판 없이 비행하는 것과 같다.
Reddit에서 바이럴이 된 "30개 파일 파이썬 재앙" 스레드. 바이브 코더가 자신의 AI 생성 앱에 기능을 추가하려 했더니, AI 제안이 완전히 관련 없어 보이는 다른 파일 다섯 개를 망가뜨렸다.
여기서 기초 지식이 선택이 아닌 필수가 된다. 시니어 개발자들은 모듈형 아키텍처, 버전 컨트롤 규율, 규칙 파일(.cursorrules), 코드 리뷰로 이 문제를 해결한다. 이것들은 코딩 스킬이 아니다. 구문과 독립적으로 존재하는 사고 스킬이다.
툴 스택의 현실: 모든 플랫폼은 다르다
바이브 코딩의 가장 위험한 미신 중 하나는 모든 툴이 교환 가능하다는 것이다. 아니다.
내가 가장 많이 보는 실수는 초기 사용의 용이성을 기준으로 툴을 선택한 후, 빠져나올 수 없는 벽에 부딪히는 것이다. 성공하는 빌더들 사이에서 나타나는 하이브리드 패턴이 있다. 빠른 프론트엔드 반복에는 Bolt, Lovable, v0를 쓰고, 백엔드 로직과 복잡한 조율에는 Cursor(.cursorrules 가드레일과 함께)를 활용한다.
실제로 작동하는 것: '참을성 있는 시니어 개발자' 프레임워크
다행히 프로덕션 급 AI 앱 출시에 성공하는 비개발자들은 코딩을 배우지 않는다. 소프트웨어 엔지니어처럼 생각하는 법을 배운다.
가장 효과적인 패턴은 내가 '참을성 있는 시니어 개발자 프레임워크'라고 부르는 것이다. AI를 복사-붙여넣기 기계가 아닌, 인터뷰하고 있는 시니어 개발자처럼 대하는 것이다.
프롬프트 비교
하지 말 것: "결제 페이지 만들어줘."
할 것: "결제 페이지가 필요해. 사용자 흐름은 이렇고 [설명], DB와 연결은 이렇게 돼 [설명]. 만들고, 서버에 닿기 전에 결제 데이터를 어떻게 검증하는지 줄 단위로 설명해줘."
이 한 가지 행동 변화가 여러 가지를 동시에 해낸다. 명확하게 생각하도록 강제하고, 자신의 사각지대를 드러내며, AI에게 코드 설명을 요청할 때 환각과 보안 이슈를 즉시 잡아낼 수 있다.
모듈형 프롬프팅과 규칙 파일도 똑같이 중요하다. 앱 전체를 한 번에 만들어달라고 요청하는 대신, 이렇게 구조화한다.
# 단계별 모듈 프롬프팅 예시
"DB 스키마 만들어줘. 각 테이블 설명해줘."
"UI 만들어줘. 컴포넌트 구조 설명해줘."
"API 라우트 추가해줘. 요청/응답 흐름 설명해줘."
"인증 추가해줘. 보안 모델 설명해줘."
그리고 .cursorrules 파일을 만들어 이렇게 지시한다.
.cursorrules 핵심 가드레일
- 모든 DB 쿼리는 Row-Level Security 정책 포함
- API 키는 절대 프론트엔드 코드에 노출 금지
- 폼 입력값은 서버 측에서 검증
- 사용자 접근 가능 데이터는 인증된 사용자 범위로 제한
이것이 AI가 불안전한 패턴으로 드리프트되는 것을 막는다. AI 어시스턴트에게 상시 명령을 내리는 것과 같다.
결론: 만들 수 있다. 문제는 만들어야 하느냐다
AI 보조 개발은 진정으로 혁명적이다. 비개발자들이 이제 몇 달이나 몇 년이 아닌 며칠 만에 작동하는 소프트웨어를 만들 수 있다. 이건 과대광고가 아니다. 변혁이다.
하지만 "작동하는"과 "프로덕션 레디" 사이의 간극은 광고가 인정하는 것보다 훨씬 크다. 그리고 그 간극은 실제 사람들에게 실제 돈을 잃게 하고 있다.
자신을 위한 개인 도구를 만드는 것이라면 — 생산성 앱, 내부 대시보드, 워크플로 자동화 스크립트 — 바이브 코딩은 그 자체로 충분히 잘 작동한다.
하지만 사용자 데이터, 결제 처리, 수익이 관련된 무언가를 만드는 것이라면, 마법의 프롬프트 이상이 필요하다. 프레임워크, 가드레일, 그리고 자신이 무엇을 만들고 있는지에 대한 실질적인 이해가 필요하다.
Y Combinator, 수백 명의 부트스트랩 창업자들, 그리고 수만 명의 솔로 빌더들이 이미 AI 생성 코드를 대규모로 출시하고 있다. 성공하는 이들은 최고의 프롬프트를 가진 사람들이 아니다. 자신이 요청하고 있는 것이 무엇인지 이해하는 사람들이다.
송재희
Seattle Partners LLC 전무이사이자 Vibe Coding Boot Camp 설립자. 저서 《AI 개발 가이드: 코딩 없이 솔루션을 만들고 싶은 모든 분들을 위한》이 출판되어 있습니다. AI 보조 개발, 데이터 아키텍처, 소프트웨어가 만들어지는 방식의 미래에 대해 씁니다.