jacobhan.me

기술 · 창업 · 보고서

AI 네이티브 스타트업 플레이북:
창업의 네 단계는 어떻게 다시 쓰이는가

코드를 한 줄도 써본 적 없는 사람이 제품을 출시하고, 10명짜리 유니콘이 전략이 되는 시대. 한 기술 기업이 내놓은 창업 안내서를 따라가며, 무엇이 진짜 달라졌고 무엇이 그대로인지 짚는다.

한승문 2026년 6월 20일 읽는 데 약 16분

창업의 풍경이 바뀌고 있다. 한때 기술 창업자는 코드를 쓰는 사람, 비기획 창업자는 영업과 운영을 맡는 사람으로 갈렸다. 두 부류 사이에는 '만들 줄 아는 사람'과 '만들 만한 아이디어를 가진 사람'을 가르는 벽이 있었다. 이 벽이 빠르게 허물어지고 있다는 것이 최근 창업 담론의 핵심이다.

한 인공지능(Artificial Intelligence, AI) 기업이 펴낸 창업 안내서는 이 변화를 네 단계의 창업 여정 — 아이디어(Idea), 최소기능제품(Minimum Viable Product, MVP), 출시(Launch), 확장(Scale) — 으로 재구성한다. 이 글은 그 안내서를 따라가되, 거기 담긴 주장을 그대로 옮기는 대신 핵심 논지를 추려 검증하고, 외부 자료로 사실을 확인하며, 무엇이 정말 새로운 통찰이고 무엇이 오래된 교훈의 재포장인지 구분하려 한다.

창업자는 무엇을 하는 사람인가

안내서가 던지는 가장 근본적인 주장은 창업자의 정의 자체가 달라진다는 것이다. 과거의 창업자는 대부분의 시간을 '실행'에 썼다. 코드를 쓰고, 사람을 관리하고, 매일의 운영 업무를 처리했다. AI를 핵심 기반(infrastructure)으로 삼는 창업에서는 이 역할이 한 단계 위로 올라간다. 창업자는 직접 일을 처리하는 개별 기여자라기보다, 파일을 읽고 명령을 실행하고 코드를 돌리고 웹을 탐색하는 여러 AI 에이전트를 지휘하는 사람에 가까워진다.

이 변화가 가져오는 가장 의미 있는 결과는, 엔지니어링 배경이 없지만 특정 분야에 깊은 전문성을 가진 사람이 창업의 무대에 오를 수 있게 된다는 점이다. 창업자 풀이 공학도 중심의 좁은 통로 밖으로 넓어지면, 기존 기술 창업 생태계가 한 번도 우선순위에 두지 않았던 — 어쩌면 알아채지도 못했던 — 현실의 문제들을 풀려는 시도가 늘어난다.

▶ 비유로 이해하기 · 연주자에서 지휘자로

예전의 창업자는 직접 악기를 연주하는 사람이었다. 코드라는 바이올린을 켜고, 영업이라는 트럼펫을 불었다. 잘하려면 그 악기를 오래 연습해야 했고, 못 다루는 악기의 자리는 비어 있었다.

AI 네이티브 창업에서 창업자는 지휘자가 된다. 직접 악기를 다루지 않는다. 대신 어떤 곡을 연주할지 정하고, 각 파트에게 언제 들어오고 어떤 강약으로 연주할지 지시한다. 연주의 품질을 결정하는 것은 더 이상 손가락의 숙련도가 아니라, 곡에 대한 해석과 전체를 듣는 귀다. 다만 한 가지가 남는다 — 악보가 엉터리면, 아무리 뛰어난 오케스트라도 엉터리 음악만 정확하게 연주한다.

안내서는 이 지휘 역량을 세 갈래로 나눈다. 첫째는 모든 분야의 상담 가능한 전문가처럼 쓰는 대화형 조사 능력 — 시장 규모 추정, 경쟁 분석, 재무 모델링, 투자 메모 초안 작성. 둘째는 언제나 대기 중이고 막히는 법이 없는 엔지니어로서의 에이전트 코딩 — 말로 설명하면 AI가 생산 수준의 코드를 생성·시험·디버그·재구성한다. 셋째는 주문형 운영팀처럼 작동하는 워크플로 자동화 — 일정 관리, 고객관계관리(Customer Relationship Management, CRM) 갱신, 주간 보고서 취합, 문서 동기화 같은 반복 업무의 자동 처리다.

전통적 성장 곡선 — 매 단계가 더 큰 팀·새 자금을 요구 검증 투자 유치 채용 빌드 성장 팀 규모 ↑ · 새 자금 라운드 ↑ · 다시 반복 AI 네이티브 성장 곡선 — 소수 팀이 같은 여정을 압축 아이디어 이걸 만들 가치가 있나 MVP 먼저 뭘 만드나 출시 사업이 클 자격 있나 확장 베팅에서 사업으로 분기를 몇 주로 — 같은 일, 압축된 타임라인

매 단계마다 더 큰 팀과 새 자금 라운드를 요구하던 선형 성장 곡선이, 소수 팀이 같은 여정을 압축해 통과하는 구조로 바뀐다는 것이 안내서의 출발점이다.

이 책 전체를 관통하는 하나의 역설

네 단계의 설명을 따라 읽다 보면 한 가지 사실이 반복적으로 드러난다. 각 단계의 '위험' 항목이 사실상 같은 문장의 변주라는 점이다 — 만들기가 거의 공짜가 되면, 만들지 않는 규율이 가장 희소한 자원이 된다.

아이디어 단계에서는 '검증 대신 빌드를 택하는 함정'으로, MVP 단계에서는 '마찰 없는 기능 욕심(scope creep)'과 '복리로 불어나는 기술 부채'로, 출시 단계에서는 '준비되지 않은 확장'으로, 확장 단계에서는 '준비 안 된 시장으로의 진출'로 나타난다. 표현은 다르지만 본질은 같다. 과거에는 엔지니어링 시간과 예산이라는 비용 자체가 과속을 막는 제동장치였다. 그 제동장치가 사라진 지금, 속도는 보장되지만 판단은 스스로 챙겨야 한다.

지능은 시스템이 아니라 당신 안에 있다. 에이전트 코딩 도구는 형편없는 전제 위에서도 훌륭한 아이디어를 다룰 때와 똑같은 열정으로 코드를 짜낸다.

이 통찰은 도구 제조사가 누구든 상관없이 들고 갈 수 있는, 이 안내서에서 가장 값진 부분이다. AI는 당신이 시키는 방향으로 정확하게 일한다. 그래서 자기 아이디어를 검증해 달라고 하면 뒷받침할 근거를 찾아오고, 시장 규모를 키워 달라고 하면 투자받기 좋아 보이는 숫자를 찾아온다. 어려운 질문을 던지지 않는 창업자는, 나쁜 아이디어를 위한 정교하고 그럴듯한 논거를 그 어느 때보다 빠르게 쌓아 올리면서도 자신이 충실히 실사(due diligence)를 하고 있다고 믿게 된다.

▶ 비유로 이해하기 · 거울이 아니라 스파링 파트너

확증 편향에 빠진 창업자에게 AI는 거울이 된다. 보고 싶은 모습만 비춰주는 거울. 시장이 충분히 크다고 말해주고, 경쟁자가 위협이 아니라고 안심시켜 준다.

해독제는 같은 도구를 반대로 겨누는 것이다. AI에게 "내 아이디어를 반박해 달라", "이 경쟁자가 성공하고 내가 실패할 가장 강력한 이유를 만들어 달라"고 시키면, 똑같은 성실함으로 약점을 파고든다. 거울을 스파링 파트너로 바꾸는 순간, 같은 도구가 자기기만의 증폭기에서 검증의 도구로 뒤집힌다.

◆ 사실 확인

안내서는 "에이전트 코딩 이전에도 스타트업의 42%가 아무도 원하지 않는 것을 만들어 실패했다"고 적는다. 이 수치는 실재한다. 미국 시장조사기업 CB인사이츠(CB Insights)가 실패한 스타트업 100여 건의 사후 분석(post-mortem)을 검토한 결과, 가장 많이 꼽힌 실패 원인이 '시장의 필요 없음(no market need)'으로 약 42%였다. 자금 고갈(약 29%), 부적합한 팀(약 23%)이 그 뒤를 이었다.

다만 이 통계의 원본은 2014년 분석이라는 점은 짚어둘 만하다. CB인사이츠는 2024년에 4배 많은 데이터(실패한 벤처투자 기업 약 431건)로 갱신하며 '제품-시장 적합성 부족'을 약 43%로, '자금 고갈'을 70%로 재집계했다 — 다만 자금 고갈은 원인이라기보다 시장 부적합의 증상에 가깝다고 봤다. 안내서의 논지는 여기서 한 발 더 나간다. 그럴듯한 시제품을 며칠 만에 띄울 수 있게 된 지금, 이 실패율은 오히려 더 오를 가능성이 크다는 것이다.

출처: CB Insights 'The Top Reasons Startups Fail'(2014, 2024 갱신) — 다수 2차 자료 교차 확인

진짜 병목은 더 이상 무엇을 만들 수 있느냐가 아니라 무엇을 만들기로 선택하느냐다.

산출 시간 → 빌드 속도 AI로 거의 수직 상승 판단·이해 사람의 속도로 천천히 위험 구간 이해보다 앞서 달리는 실행

제동장치였던 비용이 사라지면 빌드 속도는 치솟지만, 그것이 좋은 것인지 판단하는 능력은 여전히 사람의 속도로 자란다. 두 곡선 사이의 벌어진 틈이 AI 시대 창업의 핵심 위험 구간이다.

네 단계, 다시 읽기

단계 1 — 아이디어

만들기 전에, 검증하라

모든 창업자는 같은 자리에서 출발한다. 머릿속에서 떠나지 않는 어떤 문제. 안내서는 이 단계의 핵심을 분명히 한다. 코드를 짜는 것이 아니라, 증거가 정당화하기 전까지는 만들지 않는 규율이다. 이 단계의 목표는 '연구 기반 검증' — 실제 문제가 존재하고 내 해법이 그 문제를 효과적으로 푼다는 단단한 증거를, 자원을 쏟기 전에 모으는 일이다.

여기서 핵심은 구체성이다. "사람들이 비용 정산을 힘들어한다"는 관찰일 뿐이다. "중견기업 재무 담당자가 회계 소프트웨어와 연동되지 않는 도구 탓에 매주 4시간 넘게 제출 내역을 대조한다"는 검증 가능한 가설이다. 안내서는 AI를 가설의 칼날을 세우는 데 — 누가, 얼마나 자주, 얼마나 심각하게 이 문제를 겪고 지금은 어떻게 대처하는지 — 쓰라고 권한다. 그다음 같은 AI에게 자기 가설을 반박하고 부정하는 증거를 찾게 한다. 고객 인터뷰에 들어갈 때는 이미 가장 강력한 반론으로 자기 가정을 두들겨 본 상태여야, 인터뷰가 확증을 찾는 사냥이 아니라 진짜 열린 탐색이 된다.

이 단계의 출구 조건은 '문제-해법 적합성(problem-solution fit)'이다. 세 질문에 모두 '그렇다'고 답할 수 있을 때다. 문제가 실재하고 구체적인가. 내 해법이 (처음 가정한 문제가 아니라) 검증으로 드러난 진짜 문제를 다루는가. 빌드를 정당화할 만큼의 신호가 있는가. 확실성은 결코 오지 않으며, 그것을 기다리는 것 자체가 또 하나의 실패 방식이다.

단계 2 — MVP(최소기능제품)

제품에 관한 증거를 모으는 단계

많은 창업자가 MVP 단계를 '건설 공사'로 여기지만, 안내서는 이것이 여전히 증거 수집 활동이라고 강조한다. 다만 이제 증거를 모으는 대상이 '문제 공간'에서 '해법'으로 바뀐다. 식별 가능한 특정 집단이 이 제품을 쓸 만큼, 다시 찾을 만큼, 돈을 낼 만큼, 남에게 알릴 만큼 가치 있다고 느끼는가.

이 단계에는 동시에 추구해야 할 두 번째 목표가 있다. 지금 어떻게 만드느냐가 나중에 무엇이 가능한지를 결정한다는 것. 그래서 빠르게 움직이되, 사용자가 본격적으로 몰려드는 순간 발목을 잡을 종류의 기술 부채를 쌓지 않아야 한다.

▶ 비유로 이해하기 · 복리로 불어나는 빚

보통의 기술 부채는 단리(單利)에 가깝다. 천천히 쌓이고, 시간을 두고 혹은 전용 스프린트 한 번으로 갚을 수 있다. 일정한 이자를 내는 빚이다.

AI가 만든 기술 부채는 복리(複利)다. 설계 원칙과 아키텍처 제약이 AI가 읽을 수 있는 곳에 적혀 있지 않으면, 매 작업 세션마다 기초 결정이 처음부터 다시 도출되고 조금씩 어긋난다. 어느 조각도 그 자체로는 나쁘지 않은데, 애초에 서로 맞물리도록 설계되지 않았기에 일관된 밑그림이 없는 코드베이스가 된다. 이 빚은 늦게, 그리고 한꺼번에 청구서를 들이민다.

해독제는 빌드를 시작하기 전에 적어 두는 것이다. 안내서는 아키텍처 원칙과 의사결정을 담은 맥락 문서(예: CLAUDE.md 같은 프로젝트 지침 파일)를 첫 산출물로 만들라고 권한다. 이것이 AI에게는 프로젝트의 지속적 '기억'으로 작동해, 매 세션이 백지에서 시작하지 않게 한다. 기능 욕심에 대해서도 마찬가지다 — 제품이 무엇을 하고 무엇을 의도적으로 하지 않는지, 그리고 무엇을 추가하려면 실제 사용자로부터 어떤 증거가 필요한지를 미리 문서로 못 박는다. 그러면 판단의 질문이 "이걸 만들까?"에서 "사용자 다수가 이것 없이는 제품에서 가치를 못 얻는다고 말했는가?"로 바뀐다.

◆ 사실 확인

안내서가 제품-시장 적합성(Product-Market Fit, PMF)의 가늠자로 드는 '션 엘리스 테스트(Sean Ellis test)'는 실재하는 방법론이다. 활성 사용자에게 "이 제품을 더는 쓸 수 없게 된다면 어떤 기분이겠는가"를 묻고, '매우 실망스럽다'고 답한 비율이 40% 이상이면 PMF 신호로 본다. 드롭박스 초기 성장을 이끌고 '그로스 해킹(growth hacking)'이라는 말을 만든 션 엘리스가 약 100개 스타트업을 비교해 도출한 기준선이다.

출처: Sean Ellis PMF Survey 방법론 — 다수 2차 자료 교차 확인

안내서는 또한 경계해야 할 함정으로 '거짓 PMF'를 든다. 출시 직후의 에너지는 창업자의 지인, 투자자의 다른 포트폴리오 기업, 혹은 커뮤니티 헤드라인이 만든 일시적 힘에서 나온다. 어느 것도 6주, 12주 뒤를 신뢰성 있게 예측하지 못한다. 그래서 측정 지표를 출시 전에 — 어떤 패턴이 진짜 PMF이고 어떤 것이 듣기 좋은 소음인지 — 미리 정의해 두라고 권한다. 그리고 한 가지를 더 짚는다. AI가 생성한 코드는 '작동하는 코드'이지 '안전한 코드'가 아니다. 기능은 되거나 안 되거나로 즉시 드러나지만, 보안 취약점은 악용되기 전까지 보이지 않는다.

단계 3 — 출시

제품이 존재할 자격에서, 사업이 성장할 자격으로

MVP가 "이 제품이 존재할 자격이 있는가"를 증명하는 단계였다면, 출시 단계는 "이 사업이 성장할 자격이 있는가"를 증명한다. 창업자는 초기 견인력을 반복 가능하고 지속 가능한 성장 엔진으로 바꿔야 한다. 출구 조건은 세 가지다. 성장이 반복 가능하고 채널 기반이며 단위경제(고객획득비용, 생애가치, 회수기간)를 설명할 수 있을 것. 제품이 실제 운영 부하를 견딜 것. 운영이 창업자라는 병목 없이 돌아갈 것.

여기서 가장 흥미로운 전환이 일어난다. 아이디어·MVP 단계에서 창업자가 모든 실에 직접 손을 대는 것은 자산이었다. 출시 단계에서 같은 본능은 제약이 된다. 그런데 이 전환에는 명확한 순간이 없어서, 조직이 멈춰 서는 동안에도 창업자가 빌더 모드에 머무는 것이 가장 큰 위험이다. 한 시간이면 될 결정이 일주일씩 걸리고, 답을 아는 사람이 창업자뿐이라 지원 요청이 쌓이고, 창업자가 직접 기억해야만 처리되는 운영 업무가 생긴다면 — 그 신호다.

MVP 때 속도를 위해 받아들였던 기술 부채도 이때 이자를 붙여 청구된다. 해법은 구조적 약점을 찾는 체계적 아키텍처 감사, 최악의 것들을 겨냥한 리팩터링, 그리고 다음 기능 작업이 같은 문제를 다시 끌어들이지 않도록 시험 범위를 의미 있게 넓히는 일이다. 보안과 규정 준수도 더는 미룰 수 없다. 베타 사용자 몇 명에 민감 데이터가 없을 때 이론적 위험이던 취약점이, 실사용자가 의존하는 순간 실재하는 노출 위험이 된다.

단계 4 — 확장

빌더에서 대외 경영자로

확장 단계에서 창업자의 역할은 다시 한 번 옮겨간다. 빌더에서 대외적으로 회사를 대표하는 경영자로. 수천 명에서 수백만 명으로, 하나의 시장에서 여러 시장으로 간다. 이전까지 성장은 사용자와 가까이서 데이터와 직관으로 더듬어 갈 수 있었지만, 이제는 성숙한 조직 운영이 떠받치는 체계적 성장이 목표다. 동시에 공개 시장 투자자, 분석가, 규제 당국, 기업 구매팀, 인수자가 더 큰 압박과 회의(懷疑)를 들이댄다.

안내서가 확장 단계에서 강조하는 것은 '해자(moat)' — 복제하기 어려운 방어선이다. 세 가지 축으로 제시된다.

도메인 전문성 누적되는 맥락 현장 지식이 켜켜이 제품 안에 쌓인다 데이터 플라이휠 복리로 도는 가치 사용 피드백 개선 유용성↑ 베껴 살 수 없는 행동 지문 워크플로 락인 떠나기 어렵게 연동·자동화가 얽혀 전환이 곧 대공사가 된다 세 축이 함께 쌓인 깊이 = 자금력 있는 후발주자도 단기간에 따라잡기 어려운 방어선

확장 단계의 방어선은 한 번에 만들어지지 않는다. 제품에 녹아든 도메인 전문성, 사용이 피드백을 낳고 다시 개선으로 도는 데이터 플라이휠, 사용자의 일상 업무에 얽혀 떠나기 어렵게 만드는 워크플로 락인 — 시간을 들여 한 방향으로 쌓을수록 복제가 어려워진다.

첫째는 도메인 전문성을 AI 맥락으로 전환하는 것이다. 산업 은어, 규제의 함정, 예외 사례, 뻔한 답이 통하지 않는 이유 — 창업자 머릿속의 지식을 구조화된 맥락으로 옮겨 두면, 제품이 그것을 끌어다 쓸 수 있다. 안내서가 든 예가 직관적이다. 범용 의료비 청구 도구는 특수한 약가 프로그램 청구 건에서 무너지지만, 그 분야 전문가가 만든 도구는 그것을 위한 전용 로직을 갖는다. 시간이 지날수록 이 깊이는 일반 AI가 따라올 수 없는 독점적 지식 기반이 된다.

둘째는 누적된 사용자 데이터다. 사용자가 어떤 출력을 받아들이고 어떤 것을 거부하는지가 행동 신호로 쌓이고, 이것이 로드맵을 인도한다. 각 개선이 제품을 더 유용하게 만들고, 그것이 더 많은 사용을 부르고, 더 많은 피드백을 낳아, 다시 개선으로 돌아온다. 이 데이터는 시점에 묶여 있고 맥락에 특화되어 있어, 모방자가 재현할 수 없다. 수천 명이 당신 제품 안에서 다듬어 온 작업 방식의 '행동 지문'은 돈으로 살 수 없다.

셋째는 워크플로 락인이다. 데이터 네트워크 효과가 제품을 복제하기 어렵게 만든다면, 워크플로 락인은 제품을 떠나기 어렵게 만든다. 사용자가 제품 위에 자동화를 쌓고, 사람을 교육하고, 데이터 소스와 다른 도구에 연결할수록, 전환은 단순한 제품 결정에서 전사적 운영 프로젝트로 격상된다. 그래서 응용프로그래밍인터페이스(Application Programming Interface, API)와 웹훅, 소프트웨어개발도구(Software Development Kit, SDK)를 열어 사용자가 제품을 쓰는 것을 넘어 그 위에 무언가를 짓게 하는 것이 가장 깊은 형태의 락인이라고 안내서는 말한다.

이것은 플레이북이자, 동시에 세일즈 퍼널이다

여기까지가 안내서의 골자다. 프레임워크 자체는 견고하다. 네 단계 구분, 각 단계의 출구 조건, '속도보다 판단이 희소해진다'는 관통하는 통찰 — 어느 것도 특정 회사의 도구에 의존하지 않는, 이식 가능한 사고틀이다. 그러나 한 가지는 분명히 해 둘 필요가 있다. 이 문서는 창업 안내서인 동시에, 한 AI 기업 제품군의 세일즈 퍼널이기도 하다.

안내서는 각 단계마다 세 제품 — 빠른 대화용 채팅, 지식 작업용 협업 도구, 코딩용 에이전트 — 을 어디에 쓸지 정교하게 배치한다. 아이디어 단계의 검증부터 확장 단계의 시장 진출(Go-To-Market, GTM) 엔진까지, 모든 권장 활동이 자사 제품 호출로 자연스럽게 연결된다. 이는 비난할 일이 아니라, 읽는 사람이 알고 읽어야 할 맥락이다. 같은 작업의 상당수는 다른 회사의 도구로도, 혹은 도구 조합으로도 수행할 수 있다.

그래서 이 안내서에서 도구 종속적이지 않은 핵심만 추리면 다음과 같다. 첫째, 만들기가 거의 공짜가 된 세계에서 창업자의 일은 '실행'에서 '지휘'로 옮겨가며, 진짜 병목은 무엇을 만들 수 있느냐가 아니라 무엇을 만들기로 선택하느냐다. 둘째, AI는 당신이 시키는 방향으로 정확하게 일하므로, 검증과 반박에 의식적으로 같은 도구를 쓰지 않으면 확증 편향의 증폭기가 된다. 셋째, 속도가 보장되는 만큼 판단·문서화·보안 같은, 비용이라는 제동장치가 사라지면서 함께 약해진 규율을 의도적으로 복원해야 한다.

▶ 한발 떨어져 보기 · 누가 이 변화의 수혜자인가

안내서의 가장 급진적인 함의는 기술 창업자에게 있지 않다. 오히려 코드를 한 줄도 못 쓰지만 특정 현장을 깊이 아는 사람 — 변호사, 간호사, 조달 담당자, 비영리 활동가 — 에게 있다. 창업의 진입 장벽이 '만들 수 있느냐'에서 '풀 만한 진짜 문제를 아느냐'로 옮겨가면, 기존 기술 창업 통로가 한 번도 다루지 않았던 문제들이 무대에 오른다.

다만 같은 논리가 양날이다. 진입이 쉬워질수록 검증 없이 그럴듯한 제품을 띄우는 사람도 늘어난다. 도구가 평준화한 것은 '만드는 능력'이지 '판단하는 능력'이 아니기 때문이다.

같은 일, 새로운 규칙

AI 시대에도 창업자의 본질적 임무는 바뀌지 않았다. 진짜 문제를 찾고, 그것을 푸는 무언가를 만들고, 중요한 회사로 키우는 것. 달라진 것은 거기까지 가는 길이다. 몇 달 걸리던 검증 주기가 오후 한나절로 줄고, 적합한 기술 스택을 가진 공동창업자가 있어야 했던 시제품이 명확한 문제 정의와 몇 번의 집중된 작업 세션으로 가능해졌다.

하지만 압축된 것은 시간이지 판단이 아니다. 이 안내서가 네 단계에 걸쳐 반복해서 말하는 것도 결국 한 문장으로 모인다 — 만들기가 쉬워진 만큼, 무엇을 만들지 고르는 일의 무게가 커졌다. 도구는 손가락의 숙련도를 대신해 줄 수 있어도, 무엇이 진짜 문제이고 무엇이 자기기만인지를 가르는 귀까지 대신해 주지는 않는다. 지휘봉은 여전히 사람의 손에 있다.