2026년 AI 플랫폼으로 만드는 사람에게 최소 기능 제품(MVP)은 나쁜 조언입니다. 정확히 말하면 틀린 조언이라기보다는, 더 이상 존재하지 않는 세상에서 나온 조언이 운율이 좋고 슬라이드에 잘 들어간다는 이유로 계속 반복되고 있는 것입니다.
Eric Ries는 2011년, 병목 현상이 엔지니어 시간이었던 팀들을 위해 MVP 개념을 썼습니다. 어떤 기능이 개발에 3주가 걸리는데 누군가 그것을 원할지 확신할 수 없다면, 범위를 최소화하는 것이 유일하게 합리적인 선택이었습니다 — 진짜로 희소한 자원을 배분하고 있었던 것이니까요. 그 제약 조건 때문에 그 문구에서 "최소"가 핵심적인 의미를 가졌습니다. 그것은 제품 취향에 관한 철학이 아니었습니다. 구축이 비싸고, 먼저 덜 만들어야만 알아보는 것이 저렴해지는 비용 구조 아래에서의 트리아지였습니다.
비용 구조가 뒤집혔다
스프린트 보드 대신 채팅-계획-실행 파이프라인을 통해 빌드할 때, 한계 기능은 더 이상 3주의 비용이 들지 않습니다. 프롬프트 하나와 검증 과정 정도의 비용이 듭니다. 예전에 비쌌던 것 — 코드를 작성하는 것 — 은 이제 거의 공짜에 가깝습니다. 여전히 진짜로 비싼 것은 무엇을 만들지 파악하는 것과, 출시된 후 노이즈 많은 사용자 행동에서 신호를 읽어내는 것입니다. MVP 이론은 첫 번째 제약 조건에 최적화되어 있었습니다. 이제 AI 플랫폼으로 빌드하는 사람들 중 그 제약에 병목이 걸리는 경우는 거의 없습니다.
그래서 창업자가 로그인 화면 하나와 기능 하나만 출시하고 "빠르게 배우기 위해" MVP라고 부를 때, 보통은 아무것도 배분하고 있는 것이 아닙니다. 다른 경제 환경에 맞았던 조언을 패턴 매칭하고 있는 것이고, 그 과정에서 실제 신호를 만들어내기에는 너무 얇은 무언가를 출시하고 있는 것입니다. 다섯 명이 기능 하나짜리 앱을 써보고, 세 명이 즉시 이탈하면, 벗겨낸 앱은 벗겨낸 느낌이 든다는 것 외에는 거의 아무것도 배운 게 없습니다. 그것은 린(lean)한 것이 아닙니다. 그냥 작은 것입니다.
| 2011년의 제약 조건 | 2026년의 제약 조건 (AI 빌더) | |
|---|---|---|
| 희소 자원 | 코드를 작성하고 테스트할 엔지니어 시간 | 올바른 범위를 정의하고 결과를 읽는 시간 |
| 한계 기능 비용 | 며칠에서 몇 주 | 한 번의 빌드 주기, 대략 몇 분에서 몇 시간 |
| 과도하게 만들 위험 | 높음 — 잘못되면 매몰 비용 발생 | 낮음 — 제거하거나 재구축하는 비용이 추가하는 비용과 거의 같음 |
| 너무 적게 만들 위험 | 낮음 — 다음 스프린트에서 다시 출시하면 됨 | 높음 — 얇은 앱은 얇고 모호한 신호만 생성함 |
| "최소한"으로 보호되던 것 | 팀의 시간 | 더 이상 그렇지 않습니다 — 이제는 데이터 품질이라는 대가를 치릅니다 |
마지막 줄을 다시 읽어보세요. 미니멀리즘의 모든 정당화는 지금 당신에게는 희소하지 않은 자원을 보호하기 위한 것이었습니다. 당신은 예전 규칙의 대가를 치르고 있습니다 — 더 얇아진 테스트 범위, 더 약해진 리텐션 신호, 아이디어가 나빠서가 아니라 앱이 미완성처럼 느껴져서 이탈하는 사용자들 — 그런데 그것이 예전에 사주던 이점은 얻지 못하고 있습니다.
"더 넓게 만든다"는 것이 실제로 의미하는 것
상상할 수 있는 모든 것을 만들라는 뜻이 아닙니다. 사용자를 찾아 나서기 전에 그 제품의 전체적이고 당연한 형태 — 온보딩, 핵심 루프, 해당 카테고리의 모두가 갖고 있는 인접 기능 하나, 프로토타입이 아니라 소프트웨어처럼 느껴지게 하는 설정 페이지 — 를 만들라는 뜻입니다. 습관 트래커를 만든다면 스트릭만이 아니라 스트릭, 알림, 히스토리 뷰가 있어야 합니다. 니치 마켓플레이스를 만든다면 리스팅에 문의 양식만 붙인 게 아니라 리스팅, 메시징, 신뢰 신호(리뷰, 인증 등)가 있어야 합니다.
테스트 기준은 "얼마나 작게 만들 수 있는가"가 아닙니다. "낯선 사람이 완성된 제품으로 착각할 만한 최소 버전은 무엇인가"입니다. 이는 다른 기준이며, 보통 기능 하나가 아니라 서너 개 정도입니다. 각 기능이 채용 결정이 아니라 플랜 단계와 검증 절차에 불과한 플랫폼에서는, 첫 주에 그 기준을 달성하는 것이 2011년에는 전혀 불가능했던 방식으로 현실적입니다.
저도 초기에 이걸로 데인 경험이 있습니다. 친구의 스튜디오를 위해 작은 도구를 만든 적이 있는데 — 화면 하나, 기능 하나, 빠르게 완성, 아주 MVP다웠죠. 아무도 쓰지 않았고, 저는 그것이 시장의 목소리라고 생각했습니다. 아니었습니다. 워크플로우의 다른 모든 것이 탭 세 개를 가진 상황에서 그 도구는 미완성처럼 보였고, 그래서 아무도 그것을 습관으로 삼을 만큼 신뢰하지 않았던 것입니다. 아이디어 자체는 괜찮았습니다. 실패한 것은 형태였고, 저는 얇은 것이 미덕이라고 생각했기 때문에 일부러 얇게 출시했던 것입니다.
비판자들이 옳은 지점
이에 반박할 사람들의 논지는 타당하며, 엔지니어링 비용에 관한 것이 아니라 주의력에 관한 것입니다. 이제 기능 다섯 개를 만드는 것이 개발자-주 단위의 비용을 요구하지는 않지만, 여전히 의사결정-주 단위의 비용을 요구하고, 사용자의 이해 부담도 늘어납니다. 더 넓은 첫 버전은 검증할 범위가 넓어지고, 버그가 숨을 곳이 많아지고, 작성할 온보딩이 늘어나며, 핵심 루프가 와닿기 전에 신규 사용자가 배워야 할 것도 늘어난다는 뜻입니다. 넓게 만들었는데 핵심 루프가 틀렸다면, 이제 신호가 하나가 아니라 다섯 개 기능에 걸쳐 뒤섞이게 되고, 어떤 것이 리텐션을 죽였는지 풀어내는 데 단일하고 깔끔한 테스트보다 더 오래 걸립니다. 범위에 대한 규율은 여전히 중요합니다 — 다만 이제는 다른 대상을 겨냥할 뿐입니다. 예전의 MVP는 빌드 시간을 규율했습니다. 지금 이 경제에 맞는 버전은 의사결정 시간을 규율합니다: 제품을 진짜처럼 느끼게 만드는 소수의 기능을 고르고, 그 이상은 가차없이 잘라내고, 추가가 저렴하다는 이유만으로 계속 추가하고 싶은 유혹을 뿌리치세요. 만들기 저렴한 것과 유지보수하거나 설명하거나 무언가 고장 났을 때 추론하기 쉬운 것은 다릅니다.
그러니 본능이 시키는 것보다 더 넓게 만드세요. "최소한"이라는 단어를 옳게 만들었던 그 제약이 사라졌기 때문입니다. 하지만 MVP를 좋은 아이디어로 만들었던 그 규율은 유지하세요 — 다만 이제는 첫 버전이 아니라 출시 후의 스코프 크리프를 겨냥하게 하세요.
