개발자 없이 MVP를 만드는 방법, 그리고 아무도 먼저 알려 주지 않는 것

빌드는 더 이상 병목이 아니다. 그것을 계산에 넣어 자기 계획을 갱신한 사람은 거의 없다.

내가 받는 질문이 있고, 그 아래에 있는 질문이 있다.

받는 질문. 개발자를 고용하지 않고 내 제품을 만들 수 있는가? 그렇다. 2026년에 AI 도구를 쓰는 1인 창업자는 대략 일주일이면 작동하는 애플리케이션을 띄울 수 있다. 8주에서 16주인 전통적인 MVP 일정에 비해서 말이다 — Altar.io의 데이터는 평균을 4개월에 더 가깝게 두고, 3개월이 가장 흔하다고 본다.

그 아래의 질문. 그것이 통할까? 그리고 정직한 답은, 그것이 빌드와 아무 상관 없는 것들에 달려 있다는 것이다.

CB Insights는 실패한 벤처 투자 기업 431곳을 분석해, 43%가 제품-시장 적합성 부족으로 실패했음을 발견했다. 70%는 「자본이 소진되었다」고 했는데, 같은 분석은 그것을 원인이 아니라 증상으로 다룬다. 돈이 바닥나는 것은 진짜 문제로 가는 길에서 벌어지는 일이다.

그 실패 중 어느 것도 느린 개발 때문에 생기지 않았다. 즉 개발 병목을 제거하는 것만으로는 그 숫자가 움직이지 않는다.

정확히 무엇이 바뀌었나

「이제 소프트웨어가 쉽다」가 아니다. 더 좁고 더 유용한 무언가다.

애플리케이션을 생산하는 비용이 붕괴했다. 그 애플리케이션이 무엇이어야 하는지 결정하는 비용은 전혀 움직이지 않았다.

20년 동안 개발 병목이 그 두 번째 비용을 가리고 있었다. 빌드에 4개월과 8만 달러가 들 때, 그 4개월이 일종의 규율을 강제했다 — 엔지니어가 일하는 동안 고객과 이야기할 시간이 있었고, 그 지출이 확정하기 전에 생각하게 만들었다.

그 4개월을 없애면 이제 생각하는 일은 선택이 된다. 그것이 2026년의 실제 리스크이고, 새로운 리스크다. 이제 잘못된 것을 예전보다 훨씬 빠르게 만들 수 있고, 그것은 잘못된 상태로 인상적으로 완성된 것처럼 보일 것이다.

무엇에든 프롬프트를 넣기 전에 내려야 할 네 가지 결정

프로세스가 아니다. 네 가지 질문이고, 하루 오후면 전부 답할 수 있다.

1. 이것은 정확히 누구를 위한 것이고, 그 사람은 오늘 대신 무엇을 하고 있는가?

시장이 아니다. 한 사람, 그리고 그의 현재 우회책 — 스프레드시트, 단체 채팅방, 대행사, 일요일의 세 시간. 그 우회책을 지목할 수 없다면, 당신은 아직 그 문제가 실재하는지 모른다. 진짜로 아픈 문제에는 누구나 우회책을 갖고 있기 때문이다.

2. 그것이 반드시 해야 하는 한 가지는 무엇인가?

누군가의 하루를 나아지게 만드는 단 하나의 동작. 나머지 전부는 버전 2다. 이것이 예전보다 지금 더 중요하다. AI 도구는 당신이 서술한 아홉 개 기능을 기꺼이 다 만들어 줄 것이고, 아홉 개 기능은 아무도 설명할 수 없는 제품에 도달하는 방법이기 때문이다.

3. 당신 제품 안에 있는 것들은 무엇이고, 그것들은 어떻게 관계 맺는가?

창업자가 건너뛰는 것이 이것이고, 여섯 번째 달이 살아남을 만한지를 결정하는 것이 이것이다. 사용자, 주문, 프로젝트, 인보이스 — 당신의 명사가 무엇이든. 무엇이 무엇에 속하는지. 무엇이 유일해야 하는지. 하나가 삭제되면 무슨 일이 벌어지는지.

기술 어휘는 필요하지 않다. 「한 고객은 여러 프로젝트를 가질 수 있고, 한 프로젝트는 정확히 한 명의 소유자를 가지며, 두 고객은 같은 이메일 주소를 공유할 수 없다」 — 그것이 데이터 모델이다. 그것을 적는 데 15분이 걸리고, 그 15분이 이 모든 일에서 레버리지가 가장 높은 15분이다. 어휘가 낯설다면 기술 용어 사전이 당신이 이미 안다고 가정하지 않고 그 용어들을 다룬다.

4. 그것이 통하는지 어떻게 알 것인가?

출시 전에 그 숫자를 골라라. 출시 후에는 고무적으로 보이는 숫자를 찾아내게 되기 때문이다. 가입 수는 보통 잘못된 숫자다. 누군가 두 번째로 돌아왔는지가 보통 올바른 숫자다.

세 번째 질문이 물어뜯는 이유

그것을 건너뛰었을 때 벌어지는 일 때문이다.

당신이 명시적으로 내리지 않은 모든 결정은 그럼에도 내려진다. 그것은 생성 시점에 생성기에 의해, 당신의 비즈니스를 포함하지 않는 맥락에서 내려진다. 그 도구는 멈춰 서서 두 고객이 같은 이메일 주소를 공유할 수 있는지 묻지 않는다. 그럴듯한 것을 하나 고르고 계속 간다.

그리고 네 번째 달에 팀 기능이나 결제나 두 번째 사용자 유형을 추가해야 하고 — 첫 주에 조용히 선택된 그 답이 그 변경을 추가가 아니라 재구축으로 만든다는 것을 알게 된다. 모든 수정이 다른 것을 망가뜨린다. 프롬프트를 더하면 더 나빠진다.

빌더들은 이것을 70% 문제라고 부른다. 앱이 거의 완성 상태에 도달하고 진전이 멈춘다. 막고 있는 것은 결코 빠진 코드가 아니다. 그것은 수백 세대 전에 암묵적으로 내려져 더 이상 저렴하게 바꿀 수 없는 결정이다.

이것의 산업 수준 버전은 측정 가능하다. DORA의 2025년 연구는 더 높은 AI 도입이 소프트웨어 배포 처리량의 상승과 불안정성의 상승과 동시에 연관됨을 발견했다 — 더 빠르고 더 취약하게, 함께. GitClear의 6억 2,300만 건 코드 변경 분석은 2023년 기준선 대비 중복 코드가 81% 증가한 반면 리팩터링 활동은 2022년 변경의 21%에서 2026년 3.8%로 떨어졌음을 발견했다.

생성은 저렴하다. 일관성은 아니고, 그것을 우연히 만들어 내는 것은 없다. 이것을 다루기 위해 만들어진 실천이 명세 주도 개발이고, 이 논증의 아키텍처 버전은 여기에 있다.

실제로 무엇을 할지, 순서대로

1. 네 개의 답을 적어라. 한 페이지. 어떤 도구든 열기 전에 이것을 하라. 세 번째 질문에 답할 수 없다면 당신은 만들 준비가 된 것이 아니다 — 고객 두 명과 더 이야기할 준비가 된 것이다.
2. 오늘 오후가 아니라 여섯 번째 달에 무슨 일이 벌어질지로 도구를 골라라. 이 카테고리의 모든 선택지가 오늘 인상적인 무언가를 만들어 낼 것이다. 나중에도 그것을 확장할 수 있는지에서는 엄청나게 다르다. 정직하게 비교한 지형.
3. 그 한 가지를 만들어라. 누군가 첫 기능을 두 번 쓸 때까지 두 번째 기능에 저항하라. 기능 추가가 거의 무료일 때 이것은 들리는 것보다 훨씬 어렵다.
4. 50명이 아니라 진짜 5명 앞에 그것을 가져가라. 그 문제를 가진 5명이 예의를 지키는 50명보다 더 많이 말해 줄 것이다. 그들이 좋아했는지 묻지 말고 어디서 멈추는지 지켜보라.
5. 그 숫자에 대해 무엇을 할지 결정하라. 아무도 돌아오지 않았다면 답은 더 많은 기능이 아니다. 답은 다시 첫 번째 질문이다.

개발자가 정말로 여전히 필요한 곳

이것에 대해서는 환상을 파는 대신 솔직하게 말하겠다.

틀리는 것이 비싼 모든 것. 표준 결제를 넘어서는 지불, 건강 데이터, 규제를 받는 모든 것. 도구가 그것을 만들어 낼 수 없기 때문이 아니라, 그것들이 만들어 낸 것이 안전한지 당신이 평가할 수 없기 때문이고, 그 영역에서 「괜찮아 보였다」는 기준이 아니다.

부하가 걸린 상태의 마이그레이션. 실제 고객이 올라와 있는 상태에서 라이브 데이터의 형태를 바꾸는 일은 정말로 어렵고, 조용히 잘못된다.

그것이 통하기 시작하는 순간. 이것이 좋은 문제다. 사용량이 늘면 시스템을 이해하는 누군가가 그것을 맡아야 한다. 그 채용을 피해야 했던 실패가 아니라 성공의 이정표로 계획하라.

개발자가 아마 필요하지 않은 곳. 누가 이것을 원하는지 아는 지점까지 가는 것. 예전에는 그것에 개발자가 필요했다. 지금은 아니고, 그것은 활용할 가치가 있는 실재하는 변화다.

인상적인 데모라는 함정

작동하는 화면은 엄청나게 설득력이 있다. 당신 자신에게도 포함해서.

당신은 그것을 사람들에게 보여 줄 것이고 그들은 격려할 것이다. 잘 다듬어진 인터페이스를 보는 일은 자기 일하는 방식을 바꾸라는 요청을 받는 일과 다른 반응을 만들기 때문이다. 격려는 증거가 아니다. 그 데모는 당신이 그 방에 없는 상태로 누군가 그것을 두 번 쓸 때에만 가치가 있다.

나는 못생긴 제품과 40명의 재방문 사용자를 가진 창업자를, 아름다운 제품과 400건의 가입과 두 번째 방문이 없는 창업자보다 보고 싶다. 두 번째가 얻기는 훨씬 쉽고 회복하기는 훨씬 어렵다. 그것이 진전처럼 느껴지기 때문이다.

쉬워지지 않은 부분

이제 일주일이면 그것을 만들 수 있다. 그것은 실재하고 정말로 새로우며, 아니라고 말하는 사람은 최근에 시도해 보지 않은 것이다.

하지만 실패한 431곳 중 43%는 제품-시장 적합성 부족으로 죽었고, 빌드가 너무 오래 걸려서 죽은 곳은 하나도 없다. 병목이 옮겨 갔다. 그것은 언제나 어려운 부분이었고 4개월의 엔지니어링 뒤에 가려져 있던 그 부분으로 옮겨 갔다.

어떤 결정을, 어떤 순서로, 누구를 위해. 그것이 이제 일이다. 그것은 언제나 일이었다.

빌드가 그것을 덮을 만큼 시끄러웠을 뿐이다.

더 읽을 거리

구체적으로 아키텍처 결정에 대해서는 비기술 창업자를 위한 SaaS 앱 개발. 도구가 실제로 얼마를 쓰게 할지에 대해서는 토큰, 크레딧, 투입량.

자주 묻는 질문

2026년에 정말로 개발자 없이 앱을 만들 수 있는가? 그렇다. 비기술 창업자는 AI 앱 빌더로 대략 일주일이면 작동하는 애플리케이션을 띄울 수 있다. 8주에서 16주인 전통적인 MVP 일정에 비해서 말이다. 제약은 더 이상 그것을 만들 수 있는지가 아니다 — 시작하기 전에 올바른 것들을 결정했는지다.

MVP를 만드는 데 얼마나 걸리는가? 전통적으로 8주에서 16주이며, 데이터는 평균을 4개월에 더 가깝게, 3개월을 가장 흔한 일정으로 둔다. AI 도구로 1인 창업자는 대략 일주일이면 작동하는 제품에 도달할 수 있다. 다만 그 속도는 밑에 있는 결정들이 의도적으로 내려졌을 때만 도움이 된다.

만들기 전에 무엇을 결정해야 하는가? 네 가지. 누구를 위한 것이고 그 사람이 오늘 대신 무엇을 하는지, 제품이 반드시 지원해야 하는 단 하나의 동작, 당신 제품 안의 것들이 무엇이고 서로 어떻게 관계 맺는지, 그리고 그것이 통하는지 알려 줄 숫자. 세 번째가 대부분의 창업자가 건너뛰는 것이고 나중에 가장 비싼 문제를 일으키는 것이다.

AI로 만든 MVP는 왜 몇 달 뒤에 작동을 멈추는가? 아무도 명시적으로 내리지 않은 결정이 생성기에 의해 암묵적으로 내려졌고, 그 결정들이 그 이후의 모든 것을 제약하기 때문이다. 이것이 70% 문제다. 앱이 거의 완성에 도달하고 멈춘다. 막고 있는 것이 빠진 기능이 아니라 아키텍처 선택이기 때문이다.

MVP를 만들려면 데이터베이스를 이해해야 하는가? 기술 어휘는 필요하지 않지만, 당신 제품에 어떤 것들이 존재하고 그것들이 어떻게 관계 맺는지 말할 수는 있어야 한다. 「한 고객은 여러 프로젝트를 가질 수 있고, 한 프로젝트는 한 명의 소유자를 가지며, 두 고객은 같은 이메일 주소를 공유할 수 없다」 — 그것이 평범한 언어로 표현된 데이터 모델이고, 그것을 적는 일은 당신이 할 수 있는 가장 가치 있는 일 중 하나다.

개발자를 실제로 언제 고용해야 하는가? 틀리는 것이 비싼 모든 것 — 규제 데이터, 표준 결제를 넘어서는 지불 — 에서는 산출물이 안전한지 평가할 수 없기 때문이다. 부하가 걸린 상태에서 라이브 데이터를 마이그레이션할 때. 그리고 제품이 통하기 시작해 누군가 시스템을 제대로 맡아야 할 때. 마지막 것은 성공의 이정표로 대하라.

개발자 없이 MVP를 만드는 데 얼마가 드는가? 도구는 얼마나 반복하는지에 따라 무료 등급에서 월 수백 달러 사이이며, 전통적인 빌드보다 극적으로 적다. 창업자를 방심하게 만드는 비용은 출시 이후의 것들이다 — 사용량이 늘면서 붙는 호스팅비, 그리고 초기 아키텍처가 다음 기능을 견디지 못할 때의 재구축.