“어떤 아이디어로 창업할까?”보다 중요한 질문
아이디어부터 MVP까지
“어떤 아이디어로 창업을 해야 할까요?”
이 질문은 겉으로는 아이디어에 대한 질문처럼 보이는데,
실제로는 문제와 사람(그리고 그 사람이 돈을 내는 상황)에 대한 질문입니다.
저는 이 글을 통해 아이디어를 뽑는 요령을 말하는 대신,
‘문제 → 첫 고객 → MVP → 초기 GTM’까지 한 번에 연결해보려고 합니다.
아이디어가 아니라 문제로 시작해야 하는 이유
Y Combinator을 만든 Paul Graham은
“우리가 고를 수 있는 하나의 문장을 꼽으라면 ‘사람들이 원하는 것을 만들어라’”라고 했습니다.
이 말은 너무 흔하고 뻔한 문장으로 보이지만 창업의 KPI를 딱 하나로 정해버립니다.
원함(want).
더 정확히는 “원하고, 당장 필요하고, 돈까지 낼 정도로” 원함.
그리고 그는 더 노골적으로 말합니다. “스타트업은 빠르게 성장하도록 설계된 회사”라고요.
여기서 중요한 건 “스타트업 ≠ 멋진 새 회사”라는 사실입니다.
성장(특히 빠른 성장)을 전제로 설계되는 순간부터 게임이 바뀝니다.
아이디어는 “번뜩임”이 아니라, 거의 가설에 가깝습니다.
실제로 Kevin Hale의 스타트업 스쿨 강의에서
“스타트업 아이디어는 ‘왜 이 회사가 빠르게 성장할 수 있는지’에 대한 가설”이라고 말합니다.
가설이라면 당연히 해야 할 일이 정해지죠.
1) 가설을 세우고
2) 가장 싸게 검증하고
3) 틀리면 수정하고
4) 맞으면 밀어붙입니다.
이 프레임으로 보면 “어떤 아이디어로 창업할까?”는 사실
“어떤 문제를 잡고, 어떤 사람에게, 어떤 방식으로 검증할까?”로 번역됩니다.
문제는 어디에서 오는가
문제는 어디에나 있지만, 처음부터 좋은 문제를 고르는 출발점은 생각보다 좁습니다.
저는 특히 아래 세 방법을 강하게 추천합니다.
(이유는 간단합니다. 공감과 실행 속도를 남들이 못 따라옵니다.)
내 ‘현재’의 문제
가장 강력한 출발점은 내가 지금 겪는 불편입니다.
단, “불편하네”에서 끝나면 안 됩니다.
· 내가 실제로 불편함을 느끼고
· 이미 대안도 찾아봤는데
· 뾰족한 해결이 없고
· 해결된다면 돈을 내고라도 당장 쓰고 싶은 문제
이 조건이 맞으면 “아이디어”가 아니라 “이미 있는 수요”에 가까워집니다.
예로 TaskRabbit의 창업자 Leah Busque는
보스턴에서 외출 준비를 하다 개 사료가 떨어진 상황을 계기로
“동네 누군가가 대신 사다주면 얼마나 좋을까?”를 떠올렸고,
그 자리에서 도메인을 사고 서비스로 발전시켰습니다.
이후 IBM을 그만두고 초기 버전을 만들었다고 직접 말합니다.
또 다른 유명한 예로 Uber는 택시 잡기의 고통에서 출발했습니다.
여기서 중요한 건 “택시 앱”이 아니라,
“이 꼴을 다시는 겪기 싫다”는 반복되는 고통이 먼저였다는 점입니다.
내가 오래 일해온 도메인의 문제
두 번째는 내가 오래 일해온 산업/직무 영역입니다.
특히 회사에서는 관성 때문에 “불편하지만 그냥 그러려니”로 묻히는 문제가 많습니다.
그 문제는 종종 밖에서 보면 기회입니다.
Kevin Hale의 프레임을 빌리면,
좋은 문제는 대체로
인구가 크거나(popular),
커지거나(growing),
급하거나(urgent),
비싸거나(expensive),
필수거나(mandatory),
자주 발생(frequent)합니다.
도메인 경험은 이런 신호를 “문서”가 아니라 “체감”으로 압축해 갖고 있습니다.
그리고 더 큰 장점이 하나 더 있습니다. GTM이 쉬워집니다.
예를 들어 시니어 PM 출신이 PM 들의 문제를 풀면,
첫 고객은 보통 이미 알고 있는 PM 커뮤니티/네트워크에서 나옵니다.
(이는 굉장한 “지름길”입니다.)
내가 깊게 파본 취미/흥미 영역의 문제
세 번째는 취미입니다.
오래 파본 취미에는 보통 “덕후만 아는 비효율”이 숨어 있습니다.
이 영역의 장점은 공감이 매우 깊어져서 제품 디테일이 살아난다는 겁니다.
단점은 시장이 작을 수 있으니,
앞에서 말한 “문제의 성격(빈도/긴급/지불 의사)”을 더 엄격하게 체크해야 합니다.
비타민 말고 페인킬러로 문제를 재정의하기
여기서부터가 진짜 중요합니다.
“문제가 있다”와 “돈이 되는 문제다”는 다른 말입니다.
Michael Seibel은 “사용자의 머리카락에 불이 붙은(hair on fire) 문제를 찾아라”고 말합니다.
그리고 더 잔인한 장면을 하나 붙입니다.
호스(완벽한 제품)가 아니라 벽돌(엉성한 v1)이어도, 불이 붙었으면 뭐든 잡고 끈다.
그 정도로 절박한 문제를 찾아야 한다고요.
이 비유가 왜 유효하냐면, MVP의 본질이 “완성품”이 아니라
‘불을 끌 만큼만 되는 조악한 도구’일 때도 사람들이 쓴다는 뜻이기 때문입니다.
반대로, 아래 같은 문제 정의는 높은 확률로 “열심히 만들고 아무도 안 쓰는” 루트로 갑니다.
· “20대 남자들 옷 고르기 어려우니까, 옷 큐레이션 앱 만들자.”
· “냉장고 재료로 레시피 추천해주는 서비스 만들자.”
이런 아이템이 항상 실패한다는 말은 아닙니다.
다만 보통 이런 접근은 대개 “현상”에 머무르고,
돈이 걸린 ‘진짜 문제’로 내려가지 않은 경우가 많습니다.
이를 검증하기 위한 좋은 테스트 프레임워크를 소개합니다.
· 이 문제가 생길 때, 사용자는 이미 시간을/돈을 쓰며 해결하려고 하고 있는가?
· 대안이 있는데도 불만이 큰가? (대안의 어떤 점을 싫어하는가?)
· “언젠가 해야지”가 아니라 “지금 해결해야 한다”인가? (어찌보면 가장 중요)
“비타민(있으면 좋음)”과 “페인킬러(없으면 아픔)” 논쟁은 말장난처럼 보일 수 있지만,
초기 창업에서만큼은 현실적인 질문을 던져 줍니다.
사람은 ‘설득’당해서 지갑을 열기보다, ‘고통’ 때문에 지갑을 엽니다.
그리고 여기서 한 가지 함정이 더 있습니다.
페인킬러를 만들겠다고 결심한 이상, low intent 고객을 타깃하면 안 됩니다.
예를 들어 “다이어트 의지가 부족한 일반인”을 바꾸겠다는 제품은
아주 잘 만들지 않는 이상 대부분 벽에 부딪힙니다.
(의지가 부족한 사람은… 대체로 앱 설치 의지도 부족합니다.)
반대로 “이미 돈/시간을 태우고 있는 고통”은 MVP가 엉성해도 움직일 가능성이 큽니다.
한 명을 사랑하게 만들고 열 명으로 확대하기
문제를 골랐다면 다음 단계는 “제품 만들기”가 아닙니다.
그 문제를 ‘지금’ 겪고 있는 사람을 찾는 것입니다.
Paul Graham은 초기에는 “스케일되지 않는 일을 하라(Do things that don’t scale)”고 말하며,
특히 초기 사용자를 수동으로 직접 모집해야 한다고 못 박습니다.
그리고 창업자들이 그걸 피하는 이유도 적나라하게 말합니다.
부끄러움 + 게으름(그리고 거절이 싫음).
여기 스트라이프의 사례를 소개합니다.
Paul Graham은 이를 “Collison installation”이라고 부르며,
누군가 “써볼게요”라고 말하면 링크를 보내는 대신
“그럼 노트북 주세요” 하고 그 자리에서 설치/연동을 끝냈다고 소개합니다.
이게 왜 중요하냐면, 초기에 필요한 건 “월간 방문자 수”가 아니라
사랑(혹은 광의의 집착)이기 때문입니다.
여기서 말하는 사랑은
“이 제품을 너무 좋아하고 돈을 내고 기꺼이 쓰고 추천하고 싶고 이런 종류의 사랑”만이 아닙니다.
· 대안이 없어서 어쩔 수 없이라도 쓰는 사랑
· 내일 데드라인이라 지금 당장 써야 하는 사랑
· 팀이 욕먹기 싫어서 돈 내고 쓰는 사랑
이런 사랑을 하는 사람 1명을 찾으면, 창업자는 거의 본능적으로 알게 됩니다.
“아… 이거, 10명은 만들 수 있겠다.” 혹은 “이건 케이스가 너무 특수하다.”
그리고 10명쯤 만나면, 그 다음 질문이 자연스럽게 나옵니다.
“이 사랑을 복제할 수 있나?”
MVP는 제품이 아니라 실험 장치다
이제 MVP 얘기를 해보겠습니다.
Eric Ries (The Lean Startup저자)의 정식 정의부터 깔고 가겠습니다.
MVP는 “최소 노력으로 고객에 대해 최대한의 검증된 학습(validated learning)을
얻을 수 있는 제품 버전”입니다.
즉, MVP의 목적은 “그럴듯한 제품”이 아니라,
· 이 고객이 이 문제를 정말로 심각하게 느끼는지
· 내가 제안한 해결이 실제로 행동을 바꾸는지
· 결국… 돈을 내는지
를 확인하는 데 있습니다.
요즘은 AI 덕분에 MVP를 “만드는 것” 자체는 점점 쉬워지고 있습니다.
그런데 만드는 것은 쉬워졌지만 우리에게 중요한 질문은 '무엇을 만들지'가 아닙니다.
“뭘 만들지”가 아니라 “무슨 실험을 할지”입니다.
그래서 MVP에서 꼭 필요한 건 기능 목록보다도:
· 종료 조건(언제 이 가설이 틀렸다고 판단할지)
· 검증 지표(무엇이 ‘성공/실패’인지)
입니다.
(종료 조건과 검증 지표를 확인하기 위해 ‘드래프티’를 이용해보세요.)
여기서 가장 잔인하지만 유용한 지표는 결제입니다.
방문, 좋아요, 저장, 댓글… 다 좋습니다.
그런데 “좋다”와 “산다”는 다릅니다.
MVP가 수집해야 하는 ‘검증된 학습’의 핵심은 “고객이 실제로 구매하는가”라는 점입니다.
제품/시장 적합성(product-market fit)에 가까워질수록 “고객의 돈이 회사의 통장에 쌓이게 됩니다.”
스케일업을 가능하게 하는 해자를 미리 생각하기
초기에는 1명, 그 다음은 10명, 그 다음부터는 “복제”입니다.
스타트업이 “빠른 성장”을 전제로 깔고 가는 게임이기 때문에, 성장이 나오면 자본도 따라옵니다.
그런데 복제가 가능해지는 순간, 경쟁도 따라옵니다.
그래서 초기에 반드시 한 번은 이런 질문을 해야 합니다.
“이 서비스 키 포인트는 기능이야? 아니면 구조야?”
기능(feature)은 복제되기 쉽습니다.
반면, 구조(= 해자/방어력)는 만들기 어렵지만, 생기면 게임이 바뀝니다.
해자의 언어는 여러 프레임워크로 설명되지만, 큰 방향은 비슷합니다.
네트워크, 브랜딩 등 고유의 레거시 해자도 있지만 요즘 AI 시대에서 저는 3가지를 강조합니다.
· 물리적 해자(운영/현장/물류가 핵심이라 복제 비용이 큰 것)
· 고유 데이터(남이 쉽게 못 얻는 데이터, 특히 ‘계속 새로 생기는’ 데이터)
· 산업 노하우(인터넷에 없는 디테일, 시행착오 체계, 실행 프로세스)
정리하면, “내 제품”이 아니라 내가 만들 수 있는 ‘반복 가능한 승리 방식’이 있는지 보는 겁니다.
GTM은 창업자의 발에서 시작된다
여기까지 읽으면, 마지막으로 떠오르는 질문이 있습니다.
“그래서… 고객은 어디서 데려오죠?”
저는 이 질문을 들을 때마다, 다시 Paul Graham의 문장으로 돌아갑니다.
초기에는 사용자가 저절로 오지 않기 때문에, 창업자가 직접 나가서 데려와야 한다는 것.
그리고 그걸 창업자들이 피하는 이유로 “부끄러움”을 꼽는 것.
즉, 진짜 GTM의 시작은 광고 계정이 아니라 창업자의 발입니다.
· DM 보내는 발
· 전화 거는 발
· 커뮤니티에 글 쓰는 발
· 오프라인 모임에 얼굴 들이미는 발
· 고객사 앞에서 노트북 열고 바로 설치해주는 발(Stripe식)
여기서 “부끄러워하지 말라”는 말은, 허세를 부리라는 뜻이 아닙니다.
가설 기반으로, 내가 할 수 있는 가장 솔직하고 현실적인 방식으로 알리라는 뜻입니다.
예를 들어 Stripe는 초기엔 수동 설치/연동(말 그대로 사람 손으로) 같은
“안 scalable한” 방식으로 첫 고객을 만들었습니다.
그리고 규모가 커진 뒤에는 아예 컨퍼런스/세션 형태의 장을 만들어,
개발자/비즈니스 생태계와 접점을 늘리는 방식으로 확장해 왔습니다.
핵심은 한 가지입니다. 유통(distribution)을 남에게 맡기지 않았다는 것.
마지막으로, 오늘 당장 실행 가능한 “발로 뛰는 GTM”을 제안드려보면 아래와 같습니다.
첫째, “고객 인터뷰”를 설문으로 끝내지 말고, 최근 사례를 파고드는 방식으로 하세요
(“마지막으로 그 문제를 겪은 게 언제였나요?” 같은 질문).
(Mom test 참고)
둘째, MVP는 ‘대중’에게 던지지 말고, 머리카락에 불 붙은 사람에게 먼저 가져가세요.
(어디에 이런 고객들이 있을지 계속 고민해보기)
셋째, “베타 써보실래요?” 대신 “지금 15분만 잡고, 제가 세팅해드릴게요”를 하세요. (진짜로)
넷째, 콘텐츠(블로그)는 “좋은 글”보다 특정 페르소나가 자기 상황을 떠올리게 하는 글이 더 강합니다.
(페인·상황·대안·실패 비용을 구체화)
다섯째, 반응 지표가 헷갈리면, 다시 결제/구매로 돌아오세요.
MVP의 핵심 목적이 검증된 학습이며, 그 학습에는 “구매”가 포함됩니다.
마치며
창업 아이디어를 찾는다는 건, 결국 “멋진 생각”을 찾는 게 아니라
내가 남들보다 더 아프게 느끼고, 더 깊게 이해하고, 더 빨리 검증할 수 있는 문제를 찾는 일입니다.
그리고 그 문제를 잡는 순간, 아이디어는 더 이상 ‘상상’이 아니라 ‘가설’이 됩니다.
가설은 실험으로만 살아남습니다.
아이디어는 중요하지 않습니다.
다만 문제를 잘못 잡으면, 대부분의 창업자는 몇 개월을 틀린 방향으로 달리게 됩니다.
그리고 그 대가는 생각보다 큽니다.
그래서 시작은 항상 하나입니다.
“이 전략이 틀렸을 가능성은 없는가?”
그 질문을 스스로 끝까지 밀어붙이기 어렵다면,
한 번은 외부의 시선으로 점검해보는 것도 방법입니다.
실행하기 전에 드래프티로 한 번 지금 사업 전략을 검증해보세요.
참고한 문헌 링크
Startup School Week 1 Recap: Kevin Hale and Eric Migicovsky | Y Combinator
https://www.ycombinator.com/blog/startup-school-week-1-recap-kevin-hale-and-eric-migicovsky/
Be Good
https://paulgraham.com/good.html
Startup = Growth
https://paulgraham.com/growth.html
Uber’s Founding
https://www.uber.com/us/en/newsroom/ubers-founding/
What Is an MVP? Eric Ries Explains - Lean Startup Co.
https://leanstartup.co/resources/articles/what-is-an-mvp/
The Real Product Market Fit | Y Combinator
https://www.ycombinator.com/blog/the-real-product-market-fit/
Do Things that Don't Scale
https://paulgraham.com/ds.html
Taskrabbit Leah Busque Interview - Business Insider
https://www.businessinsider.com/taskrabbit-interview-2011-10
The Five Competitive Forces That Shape Strategy
What is a Minimum Viable Product (MVP)?
https://agilealliance.org/glossary/mvp/?utm_source=chatgpt.com
Unleash developer productivity with generative AI
The 4 Types Of Defensibility
https://www.nfx.com/post/the-four-types-of-defensibility
Claude Code overview - Claude Code Docs
https://code.claude.com/docs/en/overview
12 Things About Product-Market Fit | Andreessen Horowitz
https://a16z.com/12-things-about-product-market-fit/
J-Curve: Definition, Drivers & Mitigation Strategies
https://carta.com/learn/private-funds/management/fund-performance/j-curve/
How AI Companies Will Build Real Defensibility
https://www.nfx.com/post/ai-defensibility
Data Moats in the Age of AI: What Still Matters?
https://www.mawer.com/the-art-of-boring/blog/data-moats-in-the-age-of-ai-what-still-matters
AMA with Patrick and John Collison | Stripe Sessions
https://stripe.com/sessions/2025/ama-with-patrick-and-john-collison