AI 코딩 시대 MVP: 기능을 더 만들수록 망할 수 있는 이유: Standard Capital (youtube.com) ↗

• 두 사람의 핵심 메시지는 간단함. AI 덕분에 기능 만들기는 쉬워졌지만, 그래서 오히려 MVP가 더 어려워졌다는 것
• Dalton은 직접 만든 제품(Standard DB)에서 2주 만에 기능이 너무 많아져서 출시 직전 80%를 지웠다고 말함
• 기능을 많이 넣는 게 고객가치로 바로 이어지지 않았고, 오히려 복잡해서 고객이 이해를 못 했다는 사례
• 사용자 대화도 양보다 질을 강조. 무작정 1000명 스팸보다, 적은 수의 깊은 대화가 제품 방향을 더 정확히 잡아준다는 주장
• Standard Capital의 Dalton Caldwell과 Michael Seibel이 AI 코딩 시대 MVP 전략을 12분 대담으로 정리한 영상

왜 AI 시대 MVP는 더 작게 시작해야 할까?

• 예전 MVP 조언은 “기능을 최소로 만들어 빨리 검증하라”였음. 이유는 개발이 비싸고 느렸기 때문
• 지금은 반대 압력이 생김. 코드 생성 도구로 기능을 너무 빨리 붙일 수 있어, 팀이 스스로 과한 제품을 만들기 쉬워짐
• Dalton 사례가 이를 보여줌. 공동창업자와 2주 만에 큰 기능 묶음을 만들었지만, 출시 직전에 대부분을 덜어내야 했음
• 핵심은 개발 속도가 아니라 편집 능력. “만들 수 있는가”보다 “지워도 되는가”가 MVP 성패를 가른다는 포인트
• 특히 남의 문제를 푸는 제품일수록 위험함. 고객이 원하는 걸 전부 넣어주고 싶어져서 범위가 끝없이 커지기 때문

사용자 인터뷰는 왜 더 적고 깊게 해야 하나?

• AI 시대에는 스팸도 같이 쉬워짐. 리드 명단을 사서 대량 메시지를 보내면 숫자는 쉽게 커 보임
• 두 사람은 이걸 노이즈라고 봄. 숫자가 커도 고객 문제를 정확히 이해하지 못하면 제품은 빗나감
• 대신 고품질 대화를 권함. 소수 고객과 깊게 대화해 “진짜로 아픈 문제”를 잡아야 나중에 입소문이 생김
• Dalton은 실제로 12번의 줌콜을 진행했다고 공유. 그 과정에서 “기능이 너무 많아 이해가 안 된다”는 반응을 직접 확인
• 기능 80%를 걷어낸 뒤에는 통화 중 바로 가입이 나왔다는 점이 중요함. 적은 기능이 오히려 사용 시작을 쉽게 만든 사례

방식	겉으로 보이는 성과	실제 제품 학습 효과
대량 스팸 인터뷰	숫자 큼, 반응 빨라 보임	낮음, 왜 쓰는지/안 쓰는지 파악 어려움
소수 정밀 인터뷰	숫자 작아 보임	높음, 핵심 문제와 구매 이유를 잡기 쉬움

”GarageBand 음악” 비유가 창업자에게 주는 경고는?

• Michael의 비유는 이렇다. 음악 제작 도구가 쉬워졌다고 해서 히트곡 수요가 무한대로 늘지는 않았음
• 누구나 노래를 만들 수 있어도, 사람들이 듣는 시간은 하루 24시간 안에서 크게 늘지 않음
• 이걸 MVP에 대입하면 “만들 수 있음”과 “시장 수요가 있음”은 전혀 다른 문제라는 뜻
• AI 코딩 도구는 진입 장벽을 낮춰주지만, 고객이 정말 원하는 제품만 살아남는 구조는 그대로임
• 따라서 창업자는 제작 능력 과시보다 수요 검증에 더 엄격해야 한다는 결론

AI 코딩 시대 MVP 체크리스트는 무엇인가?

• 첫째, 초기 기능은 의도적으로 줄이기. “있으면 좋을 것”보다 “지금 당장 문제를 해결하는 것”만 남기기
• 둘째, 고객이 말한 기능 목록을 바로 개발하지 않기. 먼저 그 기능 뒤에 있는 근본 문제를 다시 확인하기
• 셋째, 인터뷰 숫자 목표 대신 학습 목표를 세우기. 예를 들어 “고객이 10초 안에 제품 가치를 설명할 수 있는지”를 확인
• 넷째, 성장 지표 착시 경계하기. 스팸으로 만든 반짝 사용량과 실제 재사용은 분리해서 보기
• 다섯째, 공개 글쓰기에서도 같은 원칙 적용. 자동 생성 글을 많이 뿌리는 것보다, 실제 경험에서 나온 구체 글이 신뢰를 더 만듦

AI로 기능을 빨리 만드는 게 왜 오히려 위험한가?

만드는 속도가 빨라질수록 제품 범위를 통제하기가 더 어려워짐. 고객 문제를 충분히 이해하기 전에 기능을 붙이면, 제품이 커지는데도 가치는 흐려질 수 있음. 결국 출시가 늦어지거나, 출시해도 고객이 핵심을 못 알아보는 상황이 생김.

고객이 요청한 기능을 바로 구현하면 안 되나?

항상 나쁜 건 아니지만, 그대로 전부 구현하면 방향을 잃기 쉬움. 고객도 자기 문제의 해법을 완전히 모를 때가 많아, 요청 기능은 단서로 쓰고 본질 문제를 다시 파는 과정이 필요함. 두 사람은 이 단계 없이 빌드하면 “기능 늪”에 빠진다고 경고함.

1인기업은 MVP를 몇 명에게 먼저 보여주는 게 좋을까?

영상 맥락에선 “작고 깊은 검증”이 정답에 가까움. Dalton도 대규모 설문 대신 12회의 직접 대화로 방향을 바꿨고, 그 후 반응이 좋아졌음. 숫자보다 대화 밀도와 학습 품질을 우선으로 두는 방식이 현실적임.

1인기업 관점

1인기업은 기능 수보다 디테일 완성도에 더 집착하는 게 맞는 듯함. 잭 도시가 말한 것처럼 less features but make them perfect가 지금 더 유효한 원칙 같음. 기능이 많아질수록 제품이 좋아지는 게 아니라, 오히려 사용자가 뭐부터 써야 하는지 이해를 못 하게 되는 경우가 더 많은 듯함.

---

관련: AI가 스타트업을 다 죽일까: Standard Capital, AI 네이티브 회사 만드는 법: Y Combinator도 같이 보면 흐름이 이어집니다.