34
요즘 스레드를 내리다 보면 이런 식의 글이 하루에도 몇 번씩 올라옵니다.
“스친분들 저 사흘 만에 제 서비스 출시했어요 ㅠㅠ”
“클로드 코드로 처음 만들어 본 서비스가 앱스토어 20위까지 갔어요..!”
인스타그램은 다를까요?
“비개발자 20대 초반 대학생 바이브코딩으로 수십억원 매출을 내다”
“바이브코딩으로 서비스 만들어서 월 1000 찍는 비법 전수드립니다.
팔로우 + 댓글 남겨주시면 DM으로 링크 전송드립니다.”
물론 이런 글이 과장이라고 생각하지는 않습니다.
실제로 이렇게 성과를 내는 분들도 분명 있고,
그 노력과 결과를 깎아내릴 생각도 전혀 없어요.
오히려 AI 시대에 이렇게 적극적으로 본인만의 무언가를
계속해서 만들고 도전하시는 분들을 진심으로 존경합니다.
다만 이런 글을 계속 보다 보면,
바이브코딩 딸깍으로 프롬프트만 잘 쓰고 플러그인이나 MCP만 많이 연결하면
누구나 금방 서비스를 내고 수익까지 낼 수 있을 것처럼 느껴지기 쉽습니다.
화면에 보이는 성공 뒤에는 글에 잘 드러나지 않는 일이 훨씬 많은데도요.
이제 개발을 배운 적 없는 사람이 AI와 대화하며 앱을 만들고,
그걸로 창업까지 도전하는 시대가 됐어요.
중소벤처기업부의 ’모두의 창업 프로젝트’에는 1기에만 6만 3천 명이 지원했고,
이번 달 시작한 2차에는 9만 3천 명이 몰렸습니다.
직접 만들어 보려는 사람이 그 어느 때보다 많다는 뜻이죠.
출처: 중소벤처기업부 보도자료(2026.6.9), 매일일보(2026.10.20)
아까 스레드에 바이브코딩 관련 글이 많다고 했는데,
보통 댓글창을 열면 이런 댓글이 도배되어 있습니다.
“와 너무 축하드려요!!”
“바로 다운로드 완료! 평점도 5점으로 남겨드렸어요”
축하 댓글이 대부분이지만, 그 수많은 댓글 중 이런 댓글도 꼭 있어요.
“근데 소셜 로그인이 아니라 일반 계정으로 로그인하니까 다른 사람 주문 내역이 보이는데요?”
“흠.. 이거 안드로이드에서는 이 기능 지원이 안 되나요?
왜 연동이 안 될까요? 이 화면에서 넘어가질 않네요”
화면도 예쁘고 기능도 다 돌아가는데, 왜 이런 일이 생길까요?
오늘은 바이브코딩으로 만든 서비스가 출시 뒤에 자주 부딪히는 문제 다섯 가지와,
그 문제를 줄이려면 어떻게 일해야 하는지 정리해 볼게요.
AI가 지어 준 건 모델하우스입니다
모델하우스에 가 보면 거실은 넓고 주방은 반짝입니다.
그런데 거기서 살 수는 없어요.
수도꼭지를 틀어도 물이 나오지 않고,
현관문에는 제대로 된 잠금장치가 없거든요.
처음부터 보여 주려고 지은 집이니까요.
비유하자면 AI로 만든 서비스도 모델하우스와 비슷합니다.
화면과 버튼처럼 눈에 보이는 기능은 하루 만에 완성되지만,
사람이 들어와 쓰는 데 필요한 잠금장치와 배관은 따로 챙겨야 해요.
소프트웨어에서는 이 둘을 나눠서 부릅니다.
‘회원가입을 한다’, ‘주문을 한다’처럼 무엇을 하는지는 기능 요구사항,
’내 정보는 나만 본다’, ’오류가 나도 데이터가 사라지지 않는다’처럼
얼마나 안전하고 안정적으로 하는지는 비기능 요구사항이라고 해요.
문제는 AI에게 “소품 굿즈 주문 앱 만들어 줘”라고 할 때,
우리가 말하는 건 대부분 기능뿐이라는 겁니다.
“상품 목록 보여 주고, 장바구니에 담고, 카드로 결제되게 해 줘”는 말하지만,
“다른 사람 주문은 못 보게 해 줘”나 “결제가 실패하면 알려 줘”는 거의 말하지 않죠.
게다가 AI는 맞는 코드보다 일단 돌아가는 코드를 먼저 만드는 경향이 있어요.
컬럼비아대 연구팀이 Claude, Cursor, Replit 등
코딩 에이전트 5종으로 앱 15개 이상을 만들어 보고
2026년 상반기에 발표한 결과를 보면,
에이전트들은 정확성보다 실행되는 코드를 우선했고
그렇게 생긴 오류는 겉으로 잘 드러나지 않았습니다.
출처: Columbia DAPLab, 「9 Critical Failure Patterns of Coding Agents」(2026.1)
보안 회사 Veracode가 2025년 100개가 넘는 AI 모델에 코딩 과제를 맡겼을 때도,
전체 과제의 45%에서 주요 보안 취약점이 있는 코드가 나왔고요.
출처: Veracode, 「2025 GenAI Code Security Report」(2025.7)
그럼 모델하우스를 그대로 열었을 때, 어디서부터 물이 새기 시작할까요?
출시하고 나서 터지는 5가지
1. 남의 정보가 보입니다
요즘 시대에 남의 정보가 보인다고요? 그런 서비스가 출시를 어떻게 합니까?
앱 화면에 다른 유저의 이름이나 아이디, 비밀번호가 버젓이 떠 있다는 뜻이 아닙니다.
겉으로 보이는 화면은 정말 멀쩡해요.
예를 들어 굿즈 주문 앱에서 내 주문 내역을 열었더니,
인터넷 주소창 끝에 order/1023 같은 숫자가 붙어 있다고 해 볼게요.
호기심에 이 숫자를 1024로 바꿔 봤더니,
모르는 사람의 이름과 주소, 전화번호가 적힌 주문서가 그대로 열립니다.
앱은 “로그인한 사람에게 주문서를 보여 준다”까지만 만들어져 있고,
“그 주문서가 이 사람 것이 맞는지”는 확인하지 않았기 때문이에요.
현관문에 잠금장치는 달려 있는데, 어느 집 열쇠로도 열리는 셈이죠.
AI가 그렇게까지 빠뜨린다고요?
설마 싶겠지만, 이미 숫자로 확인된 일입니다.
보안 회사 UpGuard가 2026년 10월 발표한 조사에 따르면,
바이브코딩 서비스가 많이 쓰는 데이터베이스 서비스 Supabase를 쓰는 사이트 약 30만 곳을 살펴봤더니
누구나 내용을 읽을 수 있는 데이터베이스가 16,326개였습니다.
그중 절반 이상에서 개인정보로 보이는 데이터가 나왔고요.
출처: UpGuard, 「Everything Everywhere: Systemic Data Exposure in Supabase Apps」(2026.10)
원인은 대단한 해킹 기술이 아니라 설정이었습니다.
코딩 에이전트가 쓰는 방식으로 테이블을 만들면,
’이 데이터는 주인만 볼 수 있다’는 보호 설정이 기본으로 꺼져 있었던 거예요.
AI가 이 설정을 알아서 챙기지 않는 이유는 간단합니다.
“내 정보는 나만 본다”는 화면에 보이지 않으니, 요청에도 거의 들어가지 않거든요.
기획서에 적어볼 한 줄
“회원은 자기 데이터만 보고 고칠 수 있다. 관리자 화면은 관리자 계정만 들어갈 수 있다.”
2. 비밀 키가 화면 코드에 들어 있습니다
AI 기능이나 결제를 붙이면 API 키라는, 비밀번호 같은 값이 생깁니다.
이 키가 브라우저에서 누구나 볼 수 있는 코드에 그대로 들어가거나,
깃허브에 코드와 함께 올라가는 경우가 많아요.
그러면 다른 사람이 내 키로 AI를 마음껏 쓰고, 청구서는 나에게 날아옵니다.
초보자만 하는 실수도 아닙니다.
클라우드 보안 회사 Wiz가 2025년 11월 발표한 조사에서는
포브스가 꼽은 AI 기업 50곳 중 65%가 깃허브에 비밀 키를 노출한 적이 있었어요.
가트너 역시 바이브코딩의 큰 위험으로
코드에 박힌 비밀 키가 깃허브에 올라가 침투 경로가 되는 것을 꼽았습니다.
출처: Wiz 조사, The Register(2025.11), ITWorld Korea(2026.8)
기획서에 적어볼 한 줄
“결제 키와 AI API 키는 서버에서만 쓰고, 화면 코드에는 넣지 않는다. 월 사용 한도를 정해 둔다.”
3. 실패해도 아무도 모릅니다
“AI 요약 만들기” 버튼을 눌렀는데 화면에 ’생성 중…’만 계속 떠 있는 상황.
사용자는 기다리다 그냥 나가고, 만든 사람은 이런 일이 있었는지도 모릅니다.
이런 상황에서 오류가 있다고 피드백을 주시는 사용자분들은 정말 감사한 분들입니다.
앞서 본 컬럼비아대 연구에 나온 사례이기도 해요.
서버에서 오류가 났는데 그 기록은 개발자만 보는 화면에만 남았고,
사용자 화면은 아무 설명 없이 ’생성 중’에 멈춰 있었습니다.
연구팀은 오류 처리를 비즈니스 로직과 함께
가장 흔하고 심각한 실패로 꼽았어요.
AI는 앱이 멈추지 않을 만큼만 오류를 처리하는 경우가 많습니다.
실패했을 때 사용자에게 무엇을 보여 주고 누구에게 알릴지는,
누군가 정해 주지 않으면 빈칸인 채로 출시돼요.
기획서에 적어볼 한 줄
“요약 생성에 실패하면 사용자에게 ‘다시 시도’ 버튼을 보여 주고, 운영자에게 알림을 보낸다.”
4. 운영 데이터가 날아갑니다
출시하고 나서도 AI와 함께 기능을 계속 고치게 됩니다.
그런데 고치는 곳과 실제 회원이 쓰는 곳이 나뉘어 있지 않다면,
테스트 한 번에 진짜 회원 데이터가 지워질 수도 있어요.
2025년 7월, SaaS 창업자 커뮤니티 SaaStr의 창업자 제이슨 렘킨이 겪은 일이 그랬습니다.
코드를 더 이상 바꾸지 말라고 지시해 둔 상태였는데도
Replit의 AI 에이전트가 운영 중인 데이터베이스를 지워 버렸어요.
Replit 대표는 “있어서는 안 될 일”이라며 사과했고,
이후 개발용과 운영용 데이터베이스를 자동으로 나누는 기능을 도입했습니다.
AI 툴들은 분명 나아지고 있습니다.
다만 어디까지가 연습이고 어디부터가 진짜인지는
만드는 사람이 먼저 정해 둬야 해요.
기획서에 적어볼 한 줄
“기능 수정과 테스트는 운영 데이터와 분리된 곳에서만 한다. 데이터는 매일 백업한다.”
5. 심사와 법에서 막힙니다
마지막은 한국에서 서비스를 열 때의 이야기입니다.
혼자 만든 서비스라도 회원 정보를 받는 순간 지켜야 할 것들이 생겨요.
• 개인정보 처리방침: 개인정보보호법 제30조에 따라 개인정보를 처리하는 사업자는 처리방침을 만들어 공개해야 하고, 홈페이지가 있다면 홈페이지에 계속 게시해야 합니다.
• 비밀번호 암호화: 개인정보의 안전성 확보조치 기준 제7조는 비밀번호를 되돌릴 수 없는 방식(일방향 암호화)으로 저장하라고 정하고 있어요. 이용자가 1만 명이 안 되는 소상공인이나 개인도 생략할 수 있는 건 내부 관리계획을 세우는 것 정도입니다.
• 앱 안에서 계정 삭제: 앱스토어와 구글 플레이 모두, 회원가입이 있는 앱은 앱 안에서 계정을 삭제할 수 있어야 한다고 정해 두었습니다. 탈퇴 기능이 없으면 심사에서 반려될 수 있어요.
회원가입 화면은 AI가 금방 만들어 주지만,
탈퇴 화면이나 처리방침 페이지는 말하지 않으면 거의 만들어지지 않습니다.
기획서에 적어볼 한 줄
“회원 탈퇴 시 계정과 데이터를 삭제한다. 개인정보 처리방침 페이지를 두고 모든 화면 하단에서 연결한다.”
그래서 어떻게 하면 될까요?
다섯 가지를 다시 보면 공통점이 하나 있습니다.
모두 화면에는 보이지 않는다는 거예요.
그리고 사실 다섯 가지가 전부도 아닙니다.
결제가 중간에 실패하는 경우, 사람이 한꺼번에 몰리는 경우,
도입에서 본 댓글처럼 안드로이드에서만 화면이 넘어가지 않는 경우까지,
출시 뒤에 만나는 문제는 서비스마다 끝도 없이 다릅니다.
이걸 하나씩 외워서 막을 수는 없어요.
대신 일하는 순서를 조금만 바꾸면 됩니다.
1. 만들기 전에: 화면보다 규칙을 먼저 적습니다
“주문 화면 만들어 줘” 대신,
기능마다 누가 쓸 수 있는지, 실패하면 어떻게 되는지, 어떤 데이터를 남기는지를 먼저 적어 보세요.
앞에서 본 ’기획서에 적어볼 한 줄’이 바로 그 시작점입니다.
2. 만들 때: 대화가 아니라 기획서를 기준으로 넘깁니다
AI와 대화로 설명한 내용은 그 대화창 안에만 남습니다.
새 대화를 열거나 다른 도구로 옮기면, 지난번에 말한 규칙은 사라져요.
그래서 AI에게는 매번 같은 기획서를 기준으로 넘기는 게 안전합니다.
3. 만든 뒤에: 발견한 문제를 기획서에 되돌려 적습니다
출시 후 댓글로 제보받은 문제, 테스트하다 찾은 구멍은
고치고 끝내지 말고 기획서에도 한 줄 남겨 두세요.
그래야 다음 기능을 만들 때 AI가 같은 실수를 반복하지 않습니다.
정리하면 출시하는 날 끝나는 기획서가 아니라,
서비스와 함께 계속 고쳐지는 살아 있는 기획서가 필요하다는 거예요.
이 체크리스트를 다 채웠다고 서비스가 완벽하게 안전해지는 건 아닙니다.
다만 모델하우스를 그대로 열어 두는 일만큼은 막을 수 있어요.
매니패스트로 살아 있는 기획서 만들기
매니패스트는 PRD부터 기능명세서, 유저플로우, 와이어프레임까지
하나의 기획서로 이어 주는 기획 워크스페이스입니다.
앞의 세 가지 순서를 기획서 한 곳에서 이어 갈 수 있어요.
만들기 전에: 보이지 않는 규칙을 칸으로 챙깁니다
기능마다 ’개발 준비 슬롯’이 있어서 예외, 권한과 접근, 비즈니스 규칙, 데이터를 따로 적을 수 있습니다.
어떤 칸이 비어 있는지 한눈에 보이고,
비어 있는 칸은 ’AI로 채우기’로 초안을 받은 뒤 직접 다듬을 수 있어요.
결제, 데이터 보관, 회원 탈퇴처럼 여러 기능에 함께 걸리는 규칙은
기능명세서의 ’프로덕트 정책’으로 따로 묶어 정리할 수 있고요.
만들 때: AI 코딩 도구가 최신 기획서를 읽습니다
MCP로 Cursor, Claude Code, Lovable 같은 도구를 연결하면,
문서를 복사해 붙여 넣는 대신 매니패스트의 최신 기획서를 기준으로 작업합니다.
지난주 대화창에 남은 설명이 아니라, 지금 기획서에 적힌 규칙을 읽는 거죠.
만든 뒤에: 한 곳을 고치면 나머지도 맞춥니다
기능명세서에서 규칙을 바꾸면, ’문서 동기화’로 PRD나
유저플로우에서 어긋난 부분을 찾아 고칠 수 있어요.
무엇이 언제 바뀌었는지는 작업 로그에 남고요.
물론 매니패스트가 보안 점검 도구는 아닙니다.
출시 전 점검은 따로 해야 해요.
다만 지켜야 할 규칙이 기획서에 살아 있으면,
새 기능을 만들 때마다 그 기준이 함께 따라갑니다.
마무리하며
AI 덕분에 모델하우스를 짓는 데 걸리는 시간은 하루로 줄었습니다.
정말 대단한 변화예요.
다만 사람이 들어와 살 집이 되려면
누가 어느 문을 열 수 있는지, 물이 새면 누가 알아차리는지,
집이 무너지면 어디서 다시 지을 수 있는지가 도면에 있어야 합니다.
화면에 보이지 않는 것까지 기획서에 적어 두고, 서비스와 함께 고쳐 가고 싶다면
매니패스트에서 시작해 보세요.
