스타트업 검증 스택: 12개 프로젝트가 가르쳐준 증거의 중요성

CB Insights는 101개의 스타트업 사후 분석을 조사한 결과, 42%가 시장 수요가 없어서 실패했다는 사실을 발견했습니다. 저도 같은 실패 패턴을 소규모로 경험했습니다. SureInsure(보험 분석 도구)를 단 한 명의 사용자에게도 제품을 원하는지 묻지 않고 기능 완성 단계까지 개발했습니다. 아무도 원하지 않았습니다. 개발에 3주가 걸렸습니다. 그 3주를 절약할 수 있었던 검증은 하루 오후면 충분합니다.¹

TL;DR

스타트업 검증은 특정한 순서를 따릅니다: 매력도(사람들이 그 솔루션을 원하는가?), 실현 가능성(팀이 그 솔루션을 구축할 수 있는가?), 사업 타당성(그 솔루션이 비즈니스를 유지할 수 있는가?). 9개월 동안 12개 프로젝트를 출시한 후 — Ace Citizenship, Return (941), ResumeGeni, Banana List, Water, Reps, Design Gallery, Sorting Visualizer, Starfield Destroyer, SureInsure, amp97, 그리고 개인 사이트 — 모든 검증 안티패턴을 직접 경험했습니다. 검증 후 개발한 프로젝트는 더 빠르게 출시되었고 사용자를 확보했습니다. 개발 후 검증한 프로젝트는 값비싼 교훈을 남겼습니다.

---

검증 성적표

프로젝트	개발 전 검증 여부	결과
ResumeGeni	예 (랜딩 페이지 + 대기자 목록)	활성 사용자, 수익 발생
Ace Citizenship	예 (커뮤니티 리서치 + 인터뷰)	성장하는 사용자 기반
개인 사이트	부분적 (콘텐츠 검증, 디자인 미검증)	Lighthouse 100/100, 꾸준한 트래픽
Banana List	아니오 (개인적 필요에 의해 개발)	본인에게는 유용, 시장 견인력 없음
SureInsure	아니오 (기능 완성 후 검증 시도)	사용자 0명, 보류
Sorting Visualizer	아니오 (주말 프로젝트)	포트폴리오 작품, 제품 아님

패턴은 명확합니다: 코드를 작성하기 전에 검증 증거에 투자한 프로젝트는 사용자를 확보했습니다. 먼저 개발하고 나중에 검증한 프로젝트는 결과를 만들어내지 못했습니다.²

---

검증 순서

순서가 중요한 이유

엔지니어는 실현 가능성부터 확인합니다: “이것을 만들 수 있는가?” 제품 관리자는 사업 타당성부터 확인합니다: “이것으로 수익을 낼 수 있는가?” 둘 다 42%의 스타트업을 죽이는 질문을 건너뜁니다: “실제로 이것을 원하는 사람이 있는가?”³

올바른 순서는 검증 비용이 가장 저렴한 가정부터 테스트합니다:

1. 문제 검증 (문제가 실재하고 고통스러운가?)
2. 솔루션 검증 (제안된 솔루션이 문제를 해결하는가?)
3. 채널 검증 (목표 고객에게 도달할 수 있는가?)
4. 수익 검증 (고객이 비용을 지불하는가?)
5. 확장 검증 (규모에서 단위 경제학이 작동하는가?)

각 단계는 이전 단계보다 테스트 비용이 더 많이 듭니다. 단계를 건너뛰면 검증되지 않은 저비용 가정에 의존하는 고비용 가정을 테스트하는 데 자원을 낭비하게 됩니다.

---

단계를 건너뛴 프로젝트들

SureInsure: 기능 완성의 함정

SureInsure — LLM 기반 보험 약관 분석 도구 — 를 개발한 이유는 보험 문서가 이해하기 어려웠기 때문입니다. 검증 방식: 없음. 개인적인 불편함이 시장 수요로 일반화될 것이라고 가정했습니다.

3주간의 개발 끝에 보험 약관을 분석하고, 보장 공백을 강조하며, 제외 조항을 쉬운 말로 설명할 수 있는 도구가 완성되었습니다. 기술적으로는 잘 작동했습니다. 문제는 보험 가입자들이 능동적으로 분석 도구를 찾지 않는다는 것이었습니다. 고통은 실재하지만 잠재적입니다 — 보험금 청구가 거부되기 전까지는 자신의 보장이 부적절하다는 사실을 모릅니다. 아무리 뛰어난 제품 품질도 잠재적 고통에 대한 유통 문제를 해결할 수 없습니다.

검증이 밝혀냈을 사실: 보험 가입자 12명과의 대화만으로도 아무도 “보험 약관 분석기”를 검색하지 않는다는 사실을 알 수 있었을 것입니다. 문제는 약관 검토 시점이 아니라 보험금 청구 시점에 발생합니다. 채널(검색)이 문제 발생 시점(위기)과 일치하지 않습니다.⁴

Banana List: 자신의 가려운 곳 긁기

Banana List(SwiftUI + SwiftData 기반 장보기 목록 앱)를 개발한 이유는 특정 워크플로우를 원했기 때문입니다: 빠른 입력, iCloud 동기화, 그 외에는 아무것도 없는 앱. 검증은 본인의 사용이었습니다 — 자신을 위해 만드는 도구에는 유효하지만 시장 증거를 만들어내지는 못합니다.

Banana List는 잘 작동합니다. 매일 사용하고 있습니다. 이 앱은 한 명의 사용자를 완벽하게 만족시킵니다. 잘못된 것은 앱을 만든 것이 아니라 “내가 이 제품을 원한다”가 “시장이 이 제품을 원한다”로 일반화된다고 가정한 것입니다. 저의 사용은 실현 가능성과 개인적 매력도를 검증했지만, 시장 매력도나 유통에 대해서는 아무것도 검증하지 못했습니다.

---

먼저 검증한 프로젝트들

ResumeGeni: 코드보다 랜딩 페이지 먼저

ResumeGeni는 질문에서 시작했습니다: 구직자들이 ATS 시스템에 최적화된 AI 생성 이력서에 비용을 지불할 것인가? 애플리케이션 코드를 한 줄도 작성하기 전에 가치 제안을 설명하는 랜딩 페이지를 만들고 대기자 목록 양식을 추가했습니다.

증거: - Reddit과 LinkedIn의 타겟 게시물을 통해 2주 만에 이메일 가입 340건 - “언제 사용할 수 있나요?”라고 답장한 사용자 12명 - 조기 접근 비용을 지불하겠다고 제안한 사용자 3명

대기자 목록은 매력도(사람들이 ATS 최적화 이력서를 원한다)와 채널(Reddit/LinkedIn의 구직자 커뮤니티)을 검증했습니다. 증거가 제 기준을 통과한 후에야 FastAPI 백엔드, HTMX 프론트엔드, LLM 통합 개발에 투자했습니다.⁵

Ace Citizenship: 커뮤니티 리서치 먼저

Ace Citizenship(시민권 시험 준비 앱)은 코드가 아닌 커뮤니티 리서치에서 시작했습니다. 2주 동안 시민권 준비 포럼, 서브레딧, Facebook 그룹에서 다음을 관찰했습니다: - 사람들이 가장 자주 묻는 질문 - 기존 솔루션에 대해 불만을 표현하는 내용 - 존재했으면 하고 바라는 것

리서치를 통해 공백을 발견했습니다: 기존 준비 앱은 콘텐츠는 다루었지만 시험 전략은 다루지 않았습니다. 전략 공백이 제품 차별화 요소가 되었습니다. 리서치가 기존 제품이 다루지 않는 명확한 차별화 요소를 제시한 후에야 개발을 시작했습니다.⁶

---

30일 프레임워크 (경험으로 정제)

1주차: 문제 검증

방법: 잠재 고객 10-15명과 구조화된 인터뷰를 진행합니다. 솔루션을 설명하지 마세요. 문제 영역에만 집중합니다.

실제로 효과가 있는 질문: - “[문제]를 마지막으로 겪었을 때를 설명해 주세요. 무슨 일이 있었나요?” - “어떤 시도를 했나요? 무엇이 효과가 있었고 무엇이 실패했나요?” - “현재 [문제]를 처리하는 데 얼마나 많은 시간/비용을 쓰고 있나요?”

증거 산출물: 문제 빈도 및 심각도 매트릭스. 15명 중 7명 미만이 문제를 빈번하게(주 1회 이상) 그리고 고통스럽게(해결책에 돈/시간을 쓰고 있다고) 설명한다면, 문제의 시장 견인력이 충분하지 않습니다.⁷

2주차: 솔루션 검증

방법: 같은 인터뷰 대상자에게 솔루션 컨셉(와이어프레임, 랜딩 페이지 또는 구두 설명)을 제시합니다. 예의 바른 반응이 아닌 반응 강도를 측정합니다.

강한 신호: “언제 사용할 수 있나요?” “조기 접근 비용을 지불할 수 있나요?” “이 솔루션이 필요한 동료를 소개해 드리겠습니다.”

약한 신호: “흥미롭네요.” “좋아 보이네요.” “아마 사용해 볼 것 같아요.” SureInsure에 대해 친구들에게서 이 세 가지를 모두 들었습니다. 실제 사용으로 이어진 것은 없었습니다.

증거 산출물: 참여율. 15명 중 3명 미만이 구체적인 행동(가입, 예치금, 추천)을 취한다면, 솔루션이 문제와 충분히 강하게 일치하지 않는 것입니다.⁸

3주차: 채널 검증

방법: 소규모 고객 확보 실험 2건을 실행합니다. 채널당 $200-500을 투자하여 목표 고객에게 도달할 수 있는지 테스트합니다.

ResumeGeni의 경우 두 가지 채널을 테스트했습니다: - Reddit 구직자 커뮤니티: $0 지출로 340건 가입 (유기적 게시물) - LinkedIn 타겟 콘텐츠: $150 지출로 45건 가입 (가입당 $3.33)

Reddit이 승리했습니다. 채널 검증을 통해 지속적인 고객 확보 노력을 어디에 투자해야 하는지 알 수 있었습니다.⁹

4주차: 수익 및 단위 경제학 검증

방법: 제품을 사전 판매하거나 조기 접근에 대한 결제를 받습니다.

증거 산출물: 적격 리드에서 유료 고객으로의 전환율. B2B의 경우 2% 미만, B2C의 경우 0.5% 미만이라면, 프로덕션 개발에 투자하기 전에 가치 제안을 수정해야 합니다.¹⁰

---

직접 실천한 검증 안티패턴

설문조사의 함정

설문조사는 진술된 선호도를 측정합니다. 고객 인터뷰와 참여 행동은 드러난 선호도를 측정합니다. 80%가 “제품을 사용하겠다”고 응답한 설문조사는 실제 채택률 약 5%로 이어집니다. SureInsure를 통해 진술된 선호도와 드러난 선호도 사이의 격차를 배웠습니다: 모든 친구가 “유용해 보인다”고 말했습니다. 출시 후 제품을 사용한 친구는 아무도 없었습니다.¹¹

창업자-청중 문제

개인 네트워크 내에서만 검증하는 창업자는 편향된 데이터를 받습니다. 친구들은 시장 행동을 예측하지 못하는 호의적인 피드백을 제공합니다. 낯선 사람에 대한 콜드 아웃리치가 더 높은 품질의 검증 데이터를 생성하는 이유는 낯선 사람에게는 격려할 사회적 동기가 없기 때문입니다.

ResumeGeni의 검증이 성공한 이유는 가입이 친구가 아닌 Reddit의 낯선 사람들에게서 왔기 때문입니다. SureInsure의 “검증”이 실패한 이유는 저를 아는 사람들에게만 물었기 때문입니다.¹²

---

핵심 교훈

창업자를 위한 조언: - 실현 가능성보다 매력도를 먼저 검증하세요. 가장 흔한 실패 모드는 작동하지 않는 제품을 만드는 것이 아니라, 아무도 원하지 않는 제품을 만드는 것입니다 - 진술된 열정이 아닌 참여 행동(가입, 예치금, 추천)을 측정하세요. 예의 바른 관심은 구매 행동을 예측하지 못합니다 - 대기자 목록이 포함된 랜딩 페이지는 하루 오후면 됩니다. 기능 완성까지 개발하면 몇 주 또는 몇 달이 걸립니다

스타트업에 합류하는 엔지니어를 위한 조언: - 기술 아키텍처에 투자하기 전에 검증 증거를 확인하세요. 올바른 기술적 투자는 어떤 가설이 검증되었는지에 달려 있습니다 - 프로덕션 품질이 아닌 학습 속도를 위해 프로토타입을 만드세요. 첫 번째 버전의 목적은 대규모 고객 서비스가 아닌 증거 생성입니다

---

참고 문헌