2025년 11월 15일·7분
멋진 아이디어가 아닌 고통스러운 문제를 중심으로 스타트업을 세우기
반짝이는 아이디어가 아니라 사람들이 실제로 겪는 고통스러운 문제에서 시작해 스타트업을 세우는 방법을 배우세요. 실수요를 찾고 빠르게 검증해 명확한 가치로 성공하세요.
반짝이는 아이디어가 아니라 사람들이 실제로 겪는 고통스러운 문제에서 시작해 스타트업을 세우는 방법을 배우세요. 실수요를 찾고 빠르게 검증해 명확한 가치로 성공하세요.
고통스러운 문제는 사람들이 일상이나 업무에서 이미 느끼고 있는 것으로, 시간, 돈, 매출, 수면, 평판, 또는 규정 준수 위험 같은 실질적 비용을 꾸준히 발생시킵니다. 그들은 이걸 ‘고쳐볼까 말까’가 아니라 이미 줄이려고 애쓰고 있습니다—설령 현재 해법이 엉성하더라도(스프레드시트, 수작업 우회, 단기직 고용, 또는 그냥 참는 방식).
멋진 아이디어는 그 반대입니다: 새롭고 기발하고 흥미로울 수 있지만 강력하고 빈번하며 비용이 큰 문제와 연결되어 있지 않습니다. 사람들은 “멋지네”라고 말할 수 있지만, 행동을 바꾸거나 예산을 배정하지는 않습니다.
고통은 긴급성을 만듭니다. 문제가 충분히 비싸거나 위험하다면 사람들은 빠르게 관심을 기울입니다: 이메일에 답하고, 미팅에 나오고, 대안을 시험합니다. 고통은 또한 예산을 만듭니다: 회사는 매출을 위협하거나 급여 시간을 낭비하거나 노출을 증가시키는 문제에 자금을 대고, 개인은 시간을 절약하거나 스트레스를 줄이거나 더 나쁜 일을 막기 위해 돈을 씁니다.
멋진 아이디어는 보통 “나중에 해도 될 것”들과 경쟁합니다. 무언가를 무시해도 즉각적인 결과가 없다면 우선순위 목록에서 밀립니다.
이 가이드는 반복 가능한 경로를 따릅니다:
여기서 당신의 역할은 몇 달을 한 번에 걸쳐 큰 구축에 베팅하는 것이 아닙니다. 당신은 작은 테스트들—짧은 대화, 가벼운 프로토타입, 사전 판매, 좁은 범위의 MVP—을 돌려서 고통이 실제로 존재하고 지불 의사가 있는지 증명할 것입니다. 고통이 없다면 초기에 알게 되어 피벗하거나 좁히거나 후회 없이 그만둘 수 있습니다.
“멋진 아이디어”는 사랑받기 쉽지만 팔기 어렵습니다. 칭찬과 업보트, “꼭 만들어라”라는 에너지는 얻을 수 있지만, 그러한 감탄은 실제 지불 의사로 이어지지 않습니다.
문제가 날카로운 스타트업 페인포인트와 연결되어 있지 않으면 다음과 같은 증상이 반복됩니다:
약한 고통은 무한한 미루기를 만듭니다. 제품이 “성가신” 일을 돕는다면 구매자는 영원히 미룹니다: “다음 분기에 다시 보죠.” 이는 GTM(Go-to-market) 기본에 치명적입니다. 긴급성이 대화를 결정으로 바꾸니까요.
이 때문에 고객 발견은 사람들이 무엇을 좋아하는지보다는 그들이 이미 무엇을 고쳐보려 했는지에 더 집중해야 합니다—특히 시간, 돈, 평판이 걸려 있는 곳을 찾아야 합니다. Jobs-to-be-done 관점에서 보면: 어떤 일이 실패하고 있고, 실패의 비용은 무엇인가?
새로운 기능은 일시적으로 약한 수요를 가릴 수 있습니다. 초기 사용자는 그것을 가지고 놀고, 공유하고, 디자인을 칭찬할 수 있지만 워크플로에 통합하거나 비용을 지불하지는 않습니다. 새로움은 관심을 높일 뿐, 약속을 만들지는 않습니다.
검증의 목표는 찬사가 아니라 측정 가능한 완화입니다: 사이클 단축, 오류 감소, 수작업 감소, 리스크 감소, 빠른 매출. 완화를 이름 붙이고 측정할 수 없다면 문제 기반 MVP는 채택받기 어렵습니다.
멋진 아이디어는 흥분을 느끼게 하지만, 고통스러운 문제는 중력을 가집니다. 실수를 피하려면 솔루션에 사랑에 빠지기 전에 빠른 “고통 점수”를 사용하세요.
각 항목에 1–5점 부여 후 곱합니다.
예: 주간(4), 업무 중단(5), 월 $2k 비용(4)인 문제는 80점입니다. 드문 사소한 불편은 경쟁하기 어렵습니다.
세 가지 역할을 적으세요:
고통은 크지만 명확한 구매자가 없으면 “모두가 동의하지만 아무도 지불하지 않는다”는 결과가 됩니다. 최상의 기회는 고통과 예산이 정렬되어 있거나, 사용자 고통을 비즈니스 사례로 번역할 수 있는 강력한 내부 챔피언이 있는 경우입니다.
다음과 같은 시계가 붙어 있을 때 고통은 긴급해집니다:
고객이 “다음 분기에 처리하겠다”고 말하면 당신의 고통 점수는 과장되었을 가능성이 큽니다.
우회책은 누군가 이미 지불하고 있다는 증거입니다. 주목할 만한 징후:
사람들이 문제를 피하기 위해 투자하는 노력이 많을수록 구제를 위해 지불할 가능성이 높습니다.
고통스러운 문제는 ‘실제’ 누군가, ‘실제’ 상황, 그리고 실제 제약(시간, 예산, 도구, 승인)이 있을 때 비즈니스로 전환됩니다. “소기업”이나 “크리에이터”처럼 넓게 정의하면 고통이 희석되어 학습 속도가 느려집니다.
특정 고객과 상황을 선택하면:
넓게 시작하면 모든 대화가 달라 보이고 결국 아무에게도 잘 맞지 않는 유연한 제품을 만들기 쉽습니다.
다음 장소에서 긴급하고 상세한 불평이 반복되는 곳을 찾아라:
집중된 고통은 반복되는 시나리오, 강한 감정(“이거 우리를 망하게 한다”), 그리고 사람들이 문제를 해결하기 위해 시간이나 돈을 이미 쓰고 있다는 징후입니다.
“이번 주에 그들을 만날 수 있는 장소”를 채울 수 없다면 대상이 아직 너무 모호합니다.
고객 발견은 사람들이 당신의 아이디어를 “좋아하느냐”를 묻는 것이 아닙니다. 그들이 이미 고통스러운 상황을 어떻게 처리하는지, 그리고 그로 인해 어떤 비용이 드는지를 밝혀내는 과정입니다.
“사용하겠나요?” 같은 의견 질문은 공손한 부정확한 답을 낳습니다. 행동 질문이 현실을 드러냅니다.
시도해볼 문장:
모호한 답을 뚫기 위해 구체적이고 최근의 사례를 물어라:
기억 못하면 고통은 드물거나 중요하지 않을 수 있습니다.
고통은 측정 가능합니다. 이야기를 들으며(그리고 물어보며) 비용을 파악하세요:
해결책을 설명하거나 검증을 구하려 하지 마세요. 여러 이야기를 모으고 반복되는 촉발, 우회책, 결과를 찾아라.
유용한 마무리 질문: “만약 마법을 부려서 이 프로세스에서 한 가지를 바꿀 수 있다면, 무엇을 왜 바꾸고 싶나요?”
몇 건의 고객 대화를 하면 인용구와 일화로 가득한 노트가 생깁니다. 목표는 그 난잡함을 명확하고 우선순위가 매겨진 문제 목록으로 바꾸는 것입니다—재밌는 이야기로 제품을 만들지 않기 위해서입니다.
기능 요청이 아니라 문제를 추출하세요. 마찰, 지연, 리스크, 당혹감, 추가 작업, 손실된 돈을 묘사한 순간을 강조하고 유사한 순간을 한 문제 레이블 아래 묶으세요.
간단한 표를 만들어 다음 칸을 둡니다: 문제, 누가 말했는가, 빈도, 심각도, 현재 우회책, 우회 비용. 빠른 점수(예: 빈도 1–5, 심각도 1–5)를 매겨 곱하면 무엇이 일관되게 고통스러운지 빠르게 보입니다.
고객이 반복하는 정확한 문구를 주목하세요: “정말 싫다…”, “항상 그럴 때…”, “계속 기다리고 있다…” 같은 표현은 문제의 상단에 있음을 시사합니다.
또한 반복되는 결과에 주목하세요—이것들은 불만보다 종종 더 강력합니다:
다음 문장으로 명확성을 강제하세요:
[특정 고객]가 [특정 상황]에서, [문제]가 [촉발]될 때 발생하며 [고통스러운 결과]를 초래한다. 그 원인은 [근본 원인]이다.
실제 인용으로 각 괄호를 채울 수 없다면 아직 끝난 것이 아닙니다.
다음 항목은 무시하세요:
남는 것이 해결할 가치가 가장 큰 후보입니다.
검증은 “사람들이 이것을 좋아하나요?”가 아니라 “누군가 이걸 고치기 위해 시간, 평판, 또는 돈을 걸겠는가?”입니다. 코드 쓰기 전에 고통이 행동을 촉발할 만큼 강한지에 대한 구체적 증거를 찾으세요.
가장 좋은 신호는 약속을 수반합니다:
단 하나의 구체적 제안을 담은 간단한 랜딩 페이지를 만들고(대상, 고통 상황, 약속된 결과, 명확한 행동 유도: 통화 예약, 파일럿 참여, 보증금) 정확한 맥락에 들어맞는 사람들에게 타깃 아웃리치를 하세요.
목표는 트래픽이 아니라 자격을 갖춘 구매자와의 대화입니다. 열두 건의 고품질 아웃리치가 천 건의 랜덤 클릭보다 낫습니다.
“얼마를 지불하겠냐?” 대신 현재 대안을 기준으로 가격을 앵커링하세요:
사전 정의된 ‘통과’ 기준을 정하세요: 예약된 자격 있는 통화 수, 파일럿 약속 수, 보증금 금액, 아웃리치 대비 다음 단계 전환율 등. 기준을 정하지 못하면 테스트가 아니라 희망입니다.
MVP는 당신의 꿈의 제품의 축소판이 아닙니다. 고객의 고통을 실제로 눈에 띄게 줄 수 있는 가장 작은 방법입니다.
결과를 평이한 언어로 적으세요:
측정 가능하고 즉각적이게 하세요.
예시:
이 결과가 MVP의 목표가 됩니다. 그 외는 선택 사항입니다.
어떤 기능이든 시간이 단축되거나 노력이 줄거나 리스크가 줄이지 못하면 MVP가 아닙니다. 초기 고객은 고통이 빠르게 줄어들면 거친 부분을 용서하지만, 완화를 지연시키는 ‘있으면 좋은’ 기능은 용서하지 않습니다.
유용한 규칙: 실제 고객에게 그 결과를 최소 한 번 끝까지 제공할 수 있는 첫 버전을 출시하세요.
더 빠르게 배우기 위해 소프트웨어를 사람으로 대체하세요:
수작업은 실패가 아니라 나중에 자동화해야 할 부분을 발견하는 방법입니다.
속도가 중요할 때는 며칠 단위로 프로토타입을 만들 수 있는 도구를 사용하세요. 예를 들어 Koder.ai 같은 vibe-coding 플랫폼은 워크플로를 채팅으로 설명하면 작동하는 웹앱(프론트엔드 React, 백엔드 Go + PostgreSQL 등)을 생성할 수 있어 파일럿에서 빠르게 개선할 수 있습니다. 테스트가 통하면 소스 코드를 내보내 계속 빌드하면 되고, 안되면 매몰비용을 최소화했습니다.
플래닝 모드, 스냅샷, 롤백 같은 기능은 통제된 MVP 실험을 도울 수 있습니다.
초기 고객과 공유할 목록을 적으세요:
목표는 완화, 수요 증명, 다음에 무엇을 만들어야 할지에 대한 명확성이지 완벽함이 아닙니다.
포지셔닝은 “제품이 무엇을 하는가”가 아닙니다. 특정 상황의 특정 사람에게 하는 명확한 약속입니다: 당신은 이 고통스러운 문제를 가지고 있고, 우리는 이 결과를 얻도록 돕습니다. 포지셔닝이 기능 목록처럼 들리면 고객이 번역해야 하므로 실패입니다.
단순한 구조로 구체적으로 유지하세요:
“X에게, Y로 고생하는 사람들을 위해, 우리는 Z 결과를 제공합니다.”
예시:
결과는 그들이 원하는 것이어야지 당신이 만든 것이 아닙니다.
고객은 ‘더 나은 것’을 사는 것이 아니라 리스크 감소, 시간 절약, 더 많은 돈, 실수 감소를 삽니다. 고통을 지적 가능한 결과로 번역하세요:
측정할 수 없다면 프록시(“핸드오프 감소”, “단일 소스”, “당일 처리”)를 선택하고 실제 사용 후 정교화하세요.
발견 콜에서 나온 직접 인용구가 최고의 카피인 경우가 많습니다. 고객이 사용한 정확한 표현을 모아 두세요(“항상 추적하느라 정신없다”, “월말까지는 깜깜하다…”).
그 표현을 반영하세요:
이의 제기는 보통 현재 대안과의 비교입니다. 진짜 대안을 나열하고 직접 답하세요:
강한 포지셔닝은 구매를 ‘위험 감수’가 아니라 ‘구제’처럼 느끼게 합니다.
초기 GTM은 성장 해킹이 아닙니다. 진실을 찾는 임무입니다. 목표는 고통이 실제로 빈번하고 충분히 비싸서 사람들이 행동을 바꾸고 비용을 지불할 것인지 확인(또는 반박)하는 것입니다.
구매자와 빠르게 직접 접촉할 수 있는 채널을 선택하세요:
한꺼번에 다섯 채널로 확산하지 마세요. 일관되게 대화를 예약할 수 있을 때까지 하나면 충분합니다.
모든 피치는 가격표가 있는 인터뷰로 취급하세요. 테스트해야 할 것들:
사람들이 다음 단계(트라이얼, 파일럿, 유료 테스트)를 거부하면 중요한 것을 배운 것입니다.
단순하고 측정 가능하게 유지하세요:
어디서 새나가는지 보세요. 콜이 파일럿으로는 전환되지만 파일럿이 유료로 전환되지 않으면, MVP가 충분히 빨리 완화를 제공하지 못하거나 잘못된 구매자에게 팔고 있다는 신호입니다.
모든 “아니오”에는 이유가 있어야 합니다. 이유를 그대로 캡처하고 태그하세요(타이밍, 가격, 신뢰, 기능 부족, 잘못된 페르소나, 불분명한 가치). 그리고 그것을 다음에 반영하세요:
초기 판매의 목적은 논쟁에서 이기는 것이 아니라 학습을 몇 주로 압축하는 것입니다.
멋진 아이디어는 가입자를 얻을 수 있지만, 고통스러운 문제는 사람들이 행동을 바꾸고 남아 있으며 지불하게 만듭니다. 여기서 지표의 목표는 간단합니다: 사용자가 단순히 클릭하는 것이 아니라 실제 결과를 얻고 있음을 증명하세요.
초기에는 제품이 빠르게 완화를 제공한다는 신호에 집중하세요:
활성화는 높지만 반복 사용이 낮다면 ‘있으면 좋음’ 작업을 해결하고 있을 가능성이 큽니다.
유지율은 문제가 지속적임을 보여주는 가장 명확한 증거입니다.
코호트 유지율(주 1 → 주 4, 월 1 → 월 3)을 추적하고 다음과 같은 확장 신호와 쌍으로 관찰하세요:
고통이 실제라면 고객은 자연스럽게 사용 범위를 넓힙니다.
로그인은 하지만 작업을 끝내지 않는 사용자를 관찰하세요:
이는 가치가 불명확하거나 워크플로가 너무 어렵거나 결과가 매력적이지 않다는 뜻입니다.
이탈과 정체된 파일럿은 데이터입니다. 짧은 인터뷰로 배우세요:
이 답변으로 ICP를 다듬고 문제 진술을 좁히세요. 이탈 이유가 무작위이고 모호하면 특정 고통에 충분히 연결되어 있지 않을 가능성이 큽니다.
대부분의 초기 스타트업 ‘실패’는 제품이 나빠서가 아니라 고통이 충분히 강하지 않거나 잘못된 구매자를 위해 해결했기 때문입니다. 목표는 영원히 버티는 것이 아니라 빠르게 배우고 깔끔한 결정을 내리는 것입니다.
당신이 일관된 노력을 하고 있는데 고객의 반응(끌어당김)이 일관되지 않으면 피벗을 고려하세요. 흔한 적신호:
이 패턴이 여러 대화에서 보이면, 당신이 설정한 방식으로는 고통스러운 문제를 해결하고 있지 않을 가능성이 높습니다.
두 가지 다른 움직임이 있습니다:
둘 다 동시에 바꾸지 마세요. 그래야 어떤 변화가 결과를 개선했는지 알 수 있습니다.
결과가 약해도 증거는 보존하세요: 답장을 받게 한 메시지, 자격 있는 통화를 만든 채널, 긴급성이 폭발한 사용 사례 등. 그런 것들을 앵커로 삼아 변화를 테스트하세요.
시간 박스된 결정 규칙을 세워 끝없는 수정에 빠지지 마세요. 예: “다음 3주 동안 발견 콜 15회와 유료 파일럿 3건을 시도한다. 예산 소유자와 반복적 긴급 촉발을 확인할 수 없으면 그만둔다.”
포기하는 것은 실패가 아니라 진짜 고통에 시간을 쏟을 수 있도록 자신을 보호하는 것입니다.
고통스러운 문제는 누군가에게 시간, 돈, 매출, 평판, 수면, 또는 규정 준수 위험 같은 실질적인 비용을 꾸준히 발생시키며, 사람들이 이미 번거로운 우회책을 쓰더라도 이를 줄이려 하고 있다는 점에서 구별됩니다.
멋진 아이디어는 관심과 칭찬을 받을 수 있지만 행동 변화를 촉발하지 않기 때문에 ‘나중에 해도 된다’는 경쟁에 밀리기 쉽습니다.
고통은 긴급성과 예산을 만듭니다. 문제로 인해 매출이 위협받거나 급여 시간이 낭비되거나 리스크가 증가하면 사람들은:
신기한 요소는 관심을 끌 수 있지만, 결정으로 이어지는 것은 긴급성입니다.
간단한 점수법을 사용하세요: 빈도 × 심각도 × 비용(각 1–5), 곱해서 계산합니다.
이들 중 적어도 하나를 실제 사례로 수치화할 수 없다면, 그 문제는 ‘있으면 좋음’ 수준일 가능성이 큽니다.
세 가지 역할을 정의하세요:
사용자는 고통을 느끼지만 구매자가 없으면 ‘모두가 동의하지만 아무도 지불하지 않는다’는 상황이 됩니다. 고통과 예산이 정렬되어 있거나 내부 챔피언이 비즈니스 케이스를 만들어줄 수 있어야 합니다.
다음처럼 시간 압박을 주는 마감이 있으면 고통이 긴급해집니다:
일반적인 답변이 “다음 분기에 다시 보자”라면, 긴급성(및 지불 의사)이 약할 가능성이 높습니다.
우회책은 누군가 이미 비용을 지불하고 있다는 증거입니다—단지 당신의 제품으로 지불하지 않을 뿐입니다. 예시:
사람들이 우회책에 더 많은 노력과 조정을 들일수록, 그 문제에 대한 구제(솔루션)에 지불할 가능성은 높아집니다.
행동과 최근 사례에 대해 물어보세요. 의견을 묻는 질문은 공손한 답변을 만들 뿐입니다.
“사용하겠나요?”처럼 바람직성 질문은 신뢰할 만한 증거를 주지 않습니다.
코드 작성 전에 약속 기반의 검증을 찾으세요:
관심만 표명하는 것은 잡음입니다; 약속은 증거입니다.
“가장 작은 완화 결과(smallest relieving outcome)”를 정의하세요. 예: “이걸 사용한 후 고객은 더 이상 …할 필요가 없다” 또는 “이것은 X의 시간/비용/리스크를 …만큼 줄인다.”
그 결과를 달성할 수 있는 가장 작은 버전을 끝까지 한 번이라도 제공하세요. 콘시어지 온보딩, 함께 하는 구현, 수동 데이터 정리처럼 사람을 끼워 넣어도 괜찮습니다—속도(빠른 완화)가 기능 목록보다 우선입니다.
다음과 같은 신호가 반복된다면 피벗을 고려하세요:
피벗은 두 가지로 나뉩니다:
변화를 줄 때는 한 번에 하나만 바꿔야 어떤 변화가 효과를 냈는지 알 수 있습니다.