하루 만에 MVP를 만든다? — 진짜 일은 둘째 날부터입니다

결론부터

"AI로 MVP를 하루 만에 만들었다"는 말을 요즘 자주 듣습니다. 가능합니다. 저도 만들 수 있고, 어쩌면 더 빨리 만듭니다. 다만 분명히 해야 합니다 — 그건 데모를 만든 것이지 제품을 만든 게 아닙니다.

18년간 수십 개를 출시하며 배운 걸 한 문장으로 줄이면, **빌드는 전체 일의 10%**입니다. 나머지 90%는 출시 둘째 날부터 시작됩니다.

일주일 뒤, 다들 제자리였다

언젠가 직접 AI 코딩 워크숍을 진행한 적이 있습니다. 코드를 한 줄도 못 쓰던 분들이 세 시간 만에 각자 무언가를 '만들어' 냈습니다. 화면이 돌고 버튼이 눌렸습니다. 그 자리에선 분명 감동적이었습니다.

일주일 뒤, 궁금해서 물었습니다. "그래서 얼마나 진행되셨어요?"

대부분 제자리였습니다.

이상한 일이 아닙니다. 게을러서가 아니라, **하루 만에 만든 게 '제품의 시작'이 아니라 '데모의 끝'**이었기 때문입니다. 가장 쉬운 10%를 끝낸 자리에서, 진짜 일이 거기서 시작되는 줄 모른 채 멈춘 겁니다.

둘째 날부터 시작되는 것들

데모는 '잘 되는 경우'만 보여주면 됩니다. 제품은 '안 되는 경우'를 전부 감당해야 합니다.

• 실데이터는 늘 지저분합니다. 진짜 사용자는 이름에 이모지를 넣고, 빈 칸으로 제출하고, 같은 걸 두 번 누릅니다.
• 결제는 성공보다 실패가 더 많은 일입니다. 붙이는 건 반나절, 환불·부분취소·중복결제 처리가 진짜 분량입니다.
• 보안·동시성·확장은 사용자가 한 명일 땐 안 보이다가 열 명만 몰려도 터집니다.
• 유지보수 — 정책이 바뀌고, 취약점이 뜨고, 엣지케이스가 쌓입니다. 출시로 끝나는 게 아니라 출시로 시작됩니다.

이 90%는 화면에 안 보입니다. 그래서 '하루 만에'라는 말에 다들 속습니다.

AI가 10배 빨라도 못 줄이는 것

오해는 마세요. 저는 AI를 적극적으로 씁니다. 손으로 짜던 걸 체감 10배 가까이 빠르게 만듭니다(저희는 WBS로 작업 시간을 실측합니다). 그런데 빨라지는 건 '코드를 치는' 시간뿐입니다. 줄지 않는 게 셋 있습니다.

1. 무엇을 만들지 정하는 시간(스펙) — AI는 '어떻게'는 잘하지만 '무엇을·왜'는 대신 정해주지 못합니다.
2. 맞게 만들었는지 보는 시간(리뷰) — 코드가 왜 그렇게 도는지 모르면, 빠르게 틀린 걸 쌓는 겁니다.
3. 그 가설이 맞는지 확인하는 시간(검증) — 이게 MVP의 존재 이유입니다.

빌드가 10배 빨라져도 이 셋이 그대로면, 전체는 10배가 아니라 기껏 1.5배 빨라집니다. '하루'가 비현실적인 이유가 여기 있습니다.

MVP는 '만드는 것'이 아니라 '검증하는 것'이다

MVP의 M은 Minimum(최소)이지만, 핵심은 V — **Viable, '검증 가능한'**입니다. 목적은 코드가 아니라 가설 검증, "사람들이 이걸 진짜 원하는가?"에 답하는 가장 빠른 방법입니다.

그래서 빨리 만드는 것이 목적이 아닙니다. 빨리 배우는 것이 목적입니다. 검증 없는 빠른 빌드는, 빠르게 틀리는 것일 뿐입니다.

마무리

하루 만에 무언가를 만드는 건 멋진 일이고, 진입장벽이 낮아진 건 분명한 축복입니다. 다만 그 '하루'를 끝이 아니라 시작으로 보셔야 합니다.

저희가 하는 일은 사실 '만드는 것'보다 그 둘째 날 이후를 설계하는 것에 더 가깝습니다. 무엇을 검증할지 정하고, 안 되는 경우를 감당하고, 출시 후를 버티게 만드는 것.

만들고 싶은 게 있는데 '어디까지가 진짜 일인지' 가늠이 안 되신다면, 무료 MVP 진단으로 범위부터 같이 그려보셔도 좋습니다.