9월 말 Steve Blank는 자신이 만든 Lean LaunchPad 수업에서 더 이상 MVP라는 말을 쓰지 않겠다고 밝혔다. 이유는 제품을 만들기 어려워졌기 때문이 아니다. 정반대다. AI로 첫날부터 그럴듯하게 작동하는 제품을 만들 수 있게 되면서, 완성품이 팀이 고객을 이해했고 중요한 가설을 검증했다는 증거로 기능하지 않게 됐기 때문이다.[^1][^2]
그는 이런 결과물을 IUP(Initial Untested Product)라고 다시 불렀다. 제품이 존재한다는 사실과 그 제품이 무엇을 검증했다는 사실을 분리하려는 표현이다. 9월 30일 공개한 새 Lean LaunchPad 설계에서는 MVP 대신 작은 제품 조각으로 가설 하나를 시험하고, 제품 밖의 비즈니스 모델은 Minimal Tested Canvas로 검증하며, 후반부에는 실제 시간·데이터·업무환경을 내주는 design partner를 확보하도록 바꿨다.[^3]
이 변화는 창업 교육에만 해당하지 않는다. AI가 무너뜨린 것은 MVP 자체라기보다 “제품을 만들었다 = 무언가를 배웠다”는 오래된 신호의 결합이다. 코드를 생성하는 비용이 급격히 낮아지면 화면과 데모의 완성도는 더 이상 고객 학습, 기술적 깊이, 시장 수요, 배포 준비도를 동시에 보여주지 않는다. 앞으로 초기 제품은 결과물이 아니라 검증해야 할 가설 묶음에 가까워질 가능성이 높다.
예전 MVP에는 서로 다른 신호가 한꺼번에 들어 있었다
MVP는 원래 완벽한 제품을 뜻하지 않았다. 가장 작은 제품으로 고객 반응을 보고, 가설을 수정하고, 다음 버전을 만드는 학습 장치였다.
그런데 실제 창업 과정에서는 MVP가 몇 가지 신호를 동시에 담았다.
첫째, 팀이 최소한 제품을 구현할 수 있다는 기술적 신호였다. 둘째, 무엇을 만들지 선택하기 위해 어느 정도 고객을 만나고 문제를 좁혔다는 학습 신호였다. 셋째, 제한된 시간과 자원을 실제 구현에 투입했다는 commitment 신호였다. 넷째, 고객에게 보여줄 수 있는 형태까지 가져왔다는 실행 신호였다.
이 신호들이 하나의 artifact에 묶일 수 있었던 이유는 만드는 일이 비쌌기 때문이다. 기능 하나를 추가하는 데 며칠이나 몇 주가 걸리면 무엇을 만들지 선택하는 과정 자체에 비용이 있었다. 잘못 만든 제품은 팀의 시간과 자본을 태웠다.
AI가 바꾼 것은 이 비용 구조다.
Blank의 2026년 수업에서는 과거라면 학기 후반에야 기대했을 수준의 제품을 학생들이 초반부터 가져왔다. 하지만 teaching team은 가장 완성도가 높아 보이는 일부 팀이 오히려 고객에게서 덜 배우고 있다는 문제를 발견했다고 설명한다. 고객 인터뷰를 AI가 요약한 결과에 지나치게 의존하거나, 이미 잘 만들어진 초기 제품에 심리적으로 묶여 반대 증거가 나와도 방향을 바꾸기 어려워졌다는 것이다.[^1]
제품을 버리는 기술적 비용은 내려갔는데, 완성품이 주는 심리적 확신 때문에 피벗의 비용은 오히려 커질 수 있다는 역설이다.
이제 가장 싼 것은 ‘제품처럼 보이는 것’일 수 있다
AI 시대의 초기 제품에서 먼저 분리해야 할 것은 presentation quality와 evidence quality다.
화면이 매끄럽고 기능이 많다고 해서 문제의 중요성이 검증된 것은 아니다. 고객이 “좋다”고 말한다고 해서 돈을 낼 의사가 확인된 것도 아니다. AI가 다섯 명의 synthetic customer를 만들어 같은 답을 내놓는다고 해서 실제 구매 프로세스가 그렇게 움직인다는 보장도 없다.
Blank가 새 수업에서 첫 4주 동안 완성품 전체보다 snippet을 사용하도록 한 이유가 여기에 있다. 가격표 한 장, 화면 한 장, 특정 workflow 한 조각처럼 가설 하나를 공격할 수 있는 최소 단위만 보여준다. 목표는 제품의 완성도를 올리는 것이 아니라 틀릴 가능성이 있는 가정을 빨리 드러내는 것이다.[^3]
이 접근은 NSF I-Corps가 지금도 고객 발견을 별도 활동으로 강하게 요구하는 이유와도 맞닿아 있다. 현재 National Teams 프로그램은 7주 동안 잠재 고객과 파트너를 최소 100회 인터뷰하도록 요구하고 있고, 프로그램 설명도 핵심 활동을 연구실 밖에서 실제 상업적 기회를 검증하는 customer discovery로 둔다.[^4]
AI가 시장조사를 빠르게 해주는 것과 실제 고객이 예산·데이터·업무시간을 내주는 것은 다른 종류의 증거다.
AI가 제품을 빨리 만들어도 ‘출시 가능한 제품’까지 자동으로 빨라지는 것은 아니다
여기서 또 하나의 착시가 생긴다.
초기 프로토타입을 빠르게 만드는 것과 production에 안전하게 배포하는 속도는 같지 않다.
Meticulous의 Gabriel Spencer-Harper는 AI가 코드를 더 빨리 쓰기 시작하면서 검토와 검증이 새로운 병목이 될 수 있다고 설명한다. Meticulous가 제공하는 방식은 실제 사용자 흐름을 기록하고, pull request가 열리면 변경 전후의 workflow를 재생해 시각적·행동적 차이를 보여주는 것이다. 회사의 현재 제품 설명도 backend 응답을 기록·재생해 side effect를 줄이고, deterministic scheduling을 사용해 반복 가능한 검증을 목표로 한다고 밝힌다.[^5]
이 사례를 특정 도구의 우월성으로 읽을 필요는 없다. 더 중요한 것은 비용곡선이 서로 다르게 내려간다는 점이다.
프로토타입 생성 비용
↓ 빠르게 하락
고객 검증 비용
↓ 더 천천히 하락
production 검증 비용
↓ 자동화되지만 여전히 남음
AI가 첫 번째 곡선을 크게 낮추면 두 번째와 세 번째가 상대적으로 더 중요해진다.
실제로 AI 코딩의 생산성 효과 자체도 하나의 고정된 숫자로 정리하기 어렵다. METR는 2025년 경험 많은 오픈소스 개발자를 대상으로 한 실험에서 AI 사용 시 작업시간이 늘었다는 결과를 냈지만, 2026년 후속 실험에서는 참가자 선택편향과 병렬 agent 사용 때문에 현재 효과를 신뢰성 있게 추정하기 어렵다고 판단해 실험 설계를 바꾸고 있다고 밝혔다. 같은 연구진도 최신 도구가 2025년보다 개발자를 더 빠르게 만들 가능성이 높지만, 그 크기는 현재 데이터로 강하게 말하기 어렵다고 적었다.[^6]
즉 “AI가 코딩을 빠르게 한다”와 “회사가 기능을 더 빨리, 안전하게 출시한다” 사이에는 여전히 측정해야 할 구간이 있다.
AI 시대에는 discovery loop와 delivery loop를 분리해서 봐야 한다
이 변화는 MVP를 없애기보다 두 개의 루프로 쪼갠다.
첫 번째는 discovery loop다.
가설
→ 작은 제품 조각
→ 실제 고객 행동
→ 반대 증거
→ 가설 수정
여기서 중요한 것은 무엇을 만들었는지가 아니다. 무엇을 틀렸다고 판정할 수 있게 됐는지가 중요하다.
두 번째는 delivery loop다.
검증된 요구
→ 구현
→ 테스트
→ 배포
→ 실제 사용 결과
→ 회귀·실패 확인
여기서는 제품이 실제 환경에서 작동하는지가 중요하다.
과거에는 하나의 MVP가 두 루프의 중간 산출물처럼 보였다. 이제 AI가 구현 단계를 크게 압축하면서 두 루프를 의도적으로 분리할 필요가 커졌다.
고객이 원하는지 모르는 기능을 완벽하게 테스트하는 것도 낭비다. 반대로 고객이 강하게 원한다고 해서 검증되지 않은 코드를 바로 production에 넣을 수도 없다.
좋은 초기 제품 운영은 “이걸 만들 수 있는가?”보다 “무엇이 검증됐고, 다음에는 어떤 종류의 증거가 필요한가?”를 계속 구분하는 과정에 가까워진다.
design partner가 강한 신호인 이유는 칭찬보다 비용이 크기 때문이다
Blank가 새 수업에서 design partner를 중요한 validation signal로 둔 것도 같은 논리다.
온라인 미팅에서 “좋은 아이디어네요”라고 말하는 비용은 거의 없다. 데모를 보고 pilot에 관심을 보이는 것도 예전보다 쉬워졌다. AI로 며칠 만에 맞춤형 prototype을 만들 수 있기 때문이다.
반면 design partner는 더 비싼 행동을 요구한다.
직원 시간을 배정하고, 내부 데이터를 내주고, 실제 workflow에 연결하고, test environment를 제공하고, 때로는 업무 방식을 바꿔야 한다. Blank는 이런 scarce resource의 투입과 실제 사용 결과를 customer validation의 더 강한 증거로 보도록 수업을 바꿨다.[^3]
이 기준은 투자 판단에도 적용할 수 있다.
AI 스타트업이 “고객 30곳과 대화했다”고 말하는 것과, 세 고객이 실제 데이터와 engineering time을 제공해 제품을 업무에 연결했다는 것은 다르다. pilot 숫자가 많다는 것과 사용이 끝난 뒤 measurable outcome이 남았다는 것도 다르다.
AI가 데모를 싸게 만들수록 고객이 실제로 치른 비용이 더 중요한 신호가 될 수 있다.
그래서 초기 제품의 KPI도 달라져야 한다
AI 시대의 초기 제품을 평가할 때는 feature count나 demo polish보다 다음 네 종류의 증거를 분리해서 보는 편이 낫다.
| 검증 대상 | 약한 신호 | 더 강한 신호 |
|---|---|---|
| 문제 | “흥미롭다”는 반응 | 현재 행동·우회 방식·실패비용이 반복해서 확인됨 |
| 수요 | demo 신청 | 시간·데이터·예산·workflow를 실제로 투입 |
| 제품 | 기능 구현 | 실제 사용에서 outcome 개선 |
| delivery | 코드 생성 | 독립된 테스트·replay·monitoring에서 안전하게 검증 |
이 표에서 가장 중요한 변화는 첫 열과 둘째 열을 섞지 않는 것이다.
AI가 제품을 만들어줬다는 사실은 제품 증거일 수도 있지만 문제 증거는 아니다. 고객이 제품을 써봤다는 사실도 돈을 낼 이유를 증명하지 않을 수 있다. 테스트가 통과했다는 사실은 시장이 존재한다는 증거가 아니다.
반대로 고객이 아직 완성되지 않은 제품에 데이터와 시간을 내주고, 사용 결과가 개선되고, production 검증까지 반복된다면 화면의 완성도는 오히려 덜 중요할 수 있다.
투자자와 경영진이 물어야 할 질문도 바뀐다
AI 이전에는 “MVP가 있나?”가 꽤 많은 정보를 압축했다.
이제는 질문을 풀어서 물어야 한다.
무엇이 AI로 자동 생성됐는가. 어떤 가설을 실제 고객에게서 틀렸다고 확인했는가. 제품을 쓰기 위해 고객이 무엇을 포기하거나 투자했는가. 사용 뒤 어떤 outcome이 달라졌는가. production에 올릴 때 어떤 검증과 rollback이 존재하는가.
특히 초기 회사의 속도를 볼 때 build velocity와 learning velocity를 분리할 필요가 있다.
한 주에 기능 20개를 만드는 팀보다, 한 주에 중요한 가설 세 개를 버린 팀이 더 빨리 움직이고 있을 수 있다. 반대로 고객 인터뷰만 계속하면서 배포 가능한 제품을 만들지 못하는 팀도 좋은 것은 아니다.
AI가 좋은 팀과 나쁜 팀 모두를 빠르게 만들 수 있다면 경쟁우위는 “얼마나 빨리 만들었는가”보다 얼마나 빨리 잘못된 방향을 폐기하고, 검증된 방향을 production 품질로 전환했는가에 가까워진다.
이 변화가 과장일 수 있는 조건도 있다
MVP라는 용어가 실제 현장에서 완전히 사라질 가능성은 낮다. 많은 팀은 이미 MVP를 “가장 작은 학습 실험”이라는 원래 의미로 사용하고 있고, AI가 구현을 빠르게 한다고 해서 개념 자체가 무효가 되는 것은 아니다.
또 AI가 모든 제품의 제작비를 같은 정도로 낮추는 것도 아니다. 의료기기, 로봇, 반도체, 바이오처럼 물리적 실험과 규제, 제조가 큰 비중을 차지하는 영역에서는 작동 가능한 prototype 자체가 여전히 강한 기술 신호일 수 있다.
design partner 역시 완벽한 지표가 아니다. 한 고객에게 지나치게 맞추면 더 큰 시장을 놓칠 수 있고, 큰 고객의 내부 정치 때문에 실제 가치와 무관하게 pilot이 오래 이어질 수도 있다.
따라서 핵심은 MVP라는 단어를 버리는 데 있지 않다.
AI 때문에 제품을 만드는 비용과 제품을 믿을 근거를 만드는 비용이 분리됐다는 사실을 인정하는 것이 더 중요하다.
앞으로 초기 제품을 볼 때 가장 위험한 질문은 “이게 작동하나?” 하나로 끝나는 것이다.
더 필요한 질문은 세 가지다.
누구에게 어떤 문제를 검증했는가.
그 사람이 실제로 무엇을 투자했는가.
그리고 검증된 요구를 production에서 믿을 수 있게 실행할 수 있는가.
AI는 MVP를 죽이지 않았다.
완성된 제품이 자동으로 학습의 증거라는 믿음을 죽였다.
[^1]: Steve Blank, “The Year AI Came For Us: Teaching Entrepreneurship Will Never Be The Same,” September 23, 2026. https://steveblank.com/2026/09/23/the-year-ai-came-for-us-teaching-entrepreneurship-will-never-be-the-same/ [^2]: Steve Blank, “AI Killed the MVP – Long Live the IUP,” September 25, 2026. https://steveblank.com/2026/09/25/ai-killed-the-mvp-long-live-the-iup/ [^3]: Steve Blank, “Lean LaunchPad – The Next Generation,” September 30, 2026. https://steveblank.com/2026/09/30/lean-launchpad-the-next-generation/ [^4]: U.S. National Science Foundation, “National Teams Applicants — NSF I-Corps,” accessed October 3, 2026. https://www.nsf.gov/funding/initiatives/i-corps/national-teams-applicants [^5]: Meticulous, “How it Works,” accessed October 3, 2026. https://www.meticulous.ai/how-it-works [^6]: METR, “We are Changing our Developer Productivity Experiment Design,” February 24, 2026. https://metr.org/blog/2026-02-24-uplift-update/