투자자들은 당신의 '바이브 코딩'엔 관심 없습니다. 데모 때 앱이 안 터지는 게 중요하죠.
Your investors don't care that it's vibe-coded. They care it doesn't fall over at the demo.
핵심 요약
AI로 만든 MVP를 투자자에게 시연할 때 흔히 발생하는 인프라 결함과 이를 해결하는 법을 다룹니다.
- 인프라 결함 — 서버리스 콜드 스타트나 DB 연결 문제 등 데모 시 앱이 멈추는 원인을 해결해야 함.
- 개발자 도구 — 투자자가 F12를 눌렀을 때 보이는 에러나 API 키 노출 등 기본적인 보안과 품질을 점검해야 함.
- 예외 처리 — OpenAI 에러나 Stripe 웹훅 지연 등 '해피 패스' 외의 상황에 대한 대비가 필요함.
- 모바일 대응 — 노트북 환경에서만 테스트하지 말고 실제 모바일 환경에서의 레이아웃을 반드시 확인해야 함.
저는 생업으로 AI로 코딩된 MVP를 프로덕션 수준으로 재구축하는 일을 합니다. Lovable, Bolt, Cursor, Replit 등을 거쳐 지금까지 30개 정도를 다뤘는데, 항상 똑같은 상황이 반복되더군요. 창업자가 빠르게 제품을 출시하고, 마침내 지갑을 든 누군가와 실제 데모를 하게 되는데, 앱이 규모와는 아무 상관 없는 창피한 방식으로 고장 납니다. 좌절스러운 점은 거의 항상 똑같은 6~7가지 근본적인 문제 때문이라는 겁니다. 무엇을 확인해야 할지만 알면 고치기 쉬운 것들이지만, 모르면 조용히 치명적인 결과를 초래하죠.
전체 체크리스트는 아니지만 몇 가지를 여기서 다뤄보겠습니다. 이미 돈이 새고 있는 고객들을 통해 어렵게 배운 것들이라, 지금 시점에서는 레딧 게시물보다 저에게 더 가치가 있는 정보들이거든요.
첫 번째는 서버리스 환경의 콜드 스타트입니다. 몇 분 동안 활동이 없으면 함수가 잠자기 모드로 들어가서, 투자자가 링크를 클릭하면 아무 일도 일어나지 않는 빈 화면을 4초 동안 쳐다보게 됩니다. 그러면 미팅은 이미 시작부터 꼬인 거죠. 투자자들은 아무 말 안 하겠지만 방 안의 분위기는 눈에 띄게 가라앉습니다. 제가 열어본 거의 모든 AI 빌드 앱은 이 상황에 대한 처리가 전혀 안 되어 있습니다. 스켈레톤 상태도 없고, 경로 어디에도 로더가 보이지 않죠. 데모 시간 동안 5분마다 주요 경로를 핑(ping)하는 간단한 크론 작업 하나면 10분 만에 설정할 수 있고, 첫 사용자에게 제품이 느껴지는 방식을 완전히 바꿀 수 있습니다.
다음은 무료 Supabase 티어에서의 동시 접속자 문제입니다. 이건 제가 함께 일하는 거의 모든 사람을 낚는 교묘한 문제입니다. 무료 티어는 데이터베이스 연결을 60개 정도 제공하는데, AI 도구들은 연결을 풀링(pooling)하는 대신 요청마다 새 클라이언트를 여는 걸 좋아합니다. 그래서 개발 환경에서 혼자 테스트할 때는 앱이 완벽하게 작동하죠. 그러다 라이브 데모에서 3명이 동시에 접속하고 백그라운드 워커가 병렬로 실행되는 순간, 앱이 깔끔하게 죽는 대신 멈춰버립니다. 그러면 데이터베이스가 새 연결을 받아들일 수 없는 상태일 뿐인데도 제품이 고장 난 것처럼 보이죠. 대부분의 스택에서 설정 하나만 바꾸면 해결되는 문제인데, 고객 프로젝트에서 처음 겪었을 때 해결책을 찾는 데 정말 오래 걸렸습니다.
또 다른 하나는 개발자 도구(devtools)를 열었을 때 실제로 보이는 것들입니다. 이 글을 더 읽기 전에 꼭 확인해보시길 권합니다. F12를 누르고 콘솔에서 빨간 에러와 경고 메시지를 확인하세요. 그다음 네트워크 탭에서 요청 URL 안에 API 키가 그대로 노출되어 있는지 보세요. 기술적인 투자자가 앱을 열었을 때 정확히 보는 게 바로 그거니까요. 창업자가 피칭하는 도중에 파트너가 개발자 도구를 켜는 걸 본 적이 있는데, 6피트 거리에서 직접 보기 전까지는 실제 미팅에서 그런 일이 일어날 거라곤 믿지 않았습니다.
거의 아무도 대비하지 않는 더 큰 문제는 AI 도구가 '해피 패스(happy path)'만을 위해 빌드된다는 점입니다. 모든 게 처음부터 잘 작동하고 아무도 인터페이스에서 예상치 못한 행동을 하지 않는 경우죠. OpenAI가 429 에러를 뱉거나, Stripe 웹훅이 30초 지연되거나, 사용자가 제출 버튼을 더블 클릭할 때 어떻게 되는지 거의 처리되지 않거나, 처리되어도 있으나 마나 한 수준입니다. 한 번은 창업자가 라이브 데모 중에 체크아웃 버튼에 멱등성(idempotency) 처리를 안 해서 같은 사람을 위해 Stripe 고객을 두 번 생성하는 걸 본 적이 있습니다. 투자자는 예의 바르게 웃어넘겼지만, 실제 결제는 조용히 이루어지지 않았죠.
그리고 모바일 환경이 고장 나 있는데 본인만 모르는 경우도 있습니다. 개발하는 내내 노트북으로만 데모를 했기 때문이죠. 투자자들은 미팅 사이나 우버 뒷좌석에서 휴대폰으로 링크를 열어볼 텐데, AI가 생성한 레이아웃은 프롬프트에 특별히 요청하지 않는 한 모바일에서 제대로 작동하지 않습니다. 그러니 외부 미팅 전에 반드시 실제 모바일 데이터 환경에서 휴대폰으로 앱을 열어보세요. 매번 최소한 하나는 잘못된 점을 발견하게 될 겁니다.
마지막으로 여기서는 자세히 다루지 않겠지만, 웹훅 서명 검증(webhook signature verification) 문제입니다. 제 고객 중 한 명은 AI가 서명 검증을 추가하지 않아서 웹훅 악용으로 5자리 수 금액을 잃었습니다. 엔드포인트가 인터넷 어디에서든 오는 JSON 본문을 무조건 신뢰하는 열린 POST 상태로 방치되었기 때문이죠. Stripe나 Clerk 웹훅이 서명을 검증하고 있는지 스스로 물어본 적이 없다면, 다음 스프린트가 아니라 오늘 당장 확인해봐야 할 문제입니다.


