아이디어 검증 72시간 — 내가 쓰는 프레임워크

좋아 보이는 아이디어에 6개월을 태운 적이 있다.

그래서 이제는 72시간을 넘기지 않는다.

내가 묻은 6개 사이드 프로젝트 중 가장 아픈 건 시간을 가장 많이 쏟은 것들이었다. 240시간을 쓴 SaaS는 가입 13명에 유료 0명이었다. 돌아보면 그 240시간 중 235시간은 검증이 아니라 자기 위안이었다. "이만큼 만들었으니 누군가는 쓰겠지"라는, 검증을 흉내 낸 빌드였다.

이 글은 그 1년 위에서 내가 정착시킨 아이디어 검증 72시간 프레임워크다. 거창한 방법론이 아니라, 손이 코드로 가기 전에 나를 멈추는 3일짜리 브레이크에 가깝다.

왜 하필 72시간인가

72시간은 짧아서가 아니라 끝이 있어서 정한 숫자다.

내 실패의 공통점은 검증에 끝이 없었다는 거다. "조금만 더 만들어보고 판단하자"가 반복되면, 판단은 영원히 미뤄지고 매몰비용만 쌓인다. 그래서 검증에 데드라인을 박았다. 평일 저녁 3일, 길어야 주말까지. 그 안에 Go/No-Go가 안 나오면 그 자체가 No-Go의 신호다 — 3일 안에 신호 하나 못 잡는 아이디어는, 6개월을 줘도 신호가 흐릿하다.

린 스타트업의 Build-Measure-Learn 루프를 1인 빌더의 시간 예산에 맞춰 압축한 거라고 보면 된다. 다른 점은 하나다. 나에겐 Build를 시작할 자격을 얻는 단계가 먼저 있다.

1일차 — 문제가 진짜인가

첫날은 코드 금지, 솔루션 금지다. 오직 문제만 본다.

내가 6개를 묻은 진짜 이유는 솔루션이 나빠서가 아니라 문제가 없었기 때문이다. 그래서 1일차엔 한 문장만 적는다 — "누가, 어떤 상황에서, 지금 무엇으로 이 문제를 때우고 있는가." 마지막 절이 핵심이다. 지금 이미 무언가로 때우고 있다면 문제는 진짜다. 아무것도 안 하고 있다면, 그건 문제가 아니라 내가 만든 가정이다.

그날 저녁에 실제 사람 3명에게 묻는다. DM이든 전화든. "이거 어떻게 생각해?"가 아니라 *"마지막으로 이 상황 겪은 게 언제예요?"*라고. 미래형 질문은 다들 친절하게 거짓말을 하지만, 과거형 질문엔 진짜 행동이 묻어 나온다.

2일차 — 수요 신호 찾기

문제가 진짜로 확인되면, 2일차엔 나 말고 다른 사람도 이걸 찾고 있는가를 본다.

이때 내가 보는 신호는 말이 아니라 흔적이다. 누가 "있으면 좋겠다"고 말하는 건 신호가 아니다. 이미 돈·시간·검색을 쓰고 있는 흔적만 신호로 친다.

• 검색량 — 관련 키워드를 실제로 찾는 사람이 있나 (네이버·구글 검색 자동완성, 카페·커뮤니티 질문)
• 기존 대체재 — 사람들이 불편을 감수하면서까지 쓰는 임시 도구가 있나 (엑셀·메모장·수작업)
• 돈의 흔적 — 비슷한 유료 제품이 이미 팔리고 있나 (경쟁자가 있다는 건 시장이 있다는 뜻이다)

경쟁자가 없으면 안심하던 시절이 있었다. 지금은 정반대다. 경쟁자가 0이면 시장이 0일 가능성을 먼저 의심한다. 6개 중 4개가 "아무도 안 만든 영역"이었고, 그 이유는 단순했다 — 돈이 안 됐기 때문이다.

3일차 — 가장 작은 실험

3일차는 드디어 손을 쓰는 날이다. 단, 제품을 만들지 않는다.

내가 만드는 건 제품이 아니라 신호 수집기다. 보통은 이 셋 중 하나다 — 랜딩 페이지 + 폼, 손으로 그린 화면 3장, 또는 수동으로 직접 대신 해주는 컨시어지 버전. 핵심은 코드 없이 진짜 반응 하나를 받아내는 것이다.

그리고 통과 기준을 미리 적어둔다. 이게 가장 중요하다. 실험 결과를 보고 기준을 정하면, 나는 반드시 통과시킨다. 그래서 실험을 시작하기 전에 종이에 적는다.

신호	No-Go	Go
랜딩 폼 전환	100조회 중 2명 미만	100조회 중 5명+
인터뷰에서 "당장 쓰겠다"	5명 중 1명 이하	5명 중 3명+
선결제·대기명단 등록	0명	1명+ (가장 강한 신호)
기존 대체재 존재	전무 (시장 없음 의심)	불편 감수하며 사용 중

세 신호 중 둘 이상이 Go여야 Go다. 하나만 켜지면 판단 보류, 전부 No-Go면 그날 폐기다.

적용 사례 2건 — 통과 1, 탈락 1

말보다 실제 두 번이 이 프레임워크를 더 잘 설명한다.

탈락 — "개발자용 북마크 정리 SaaS." 1일차에 막혔다. 내가 불편했을 뿐, 3명에게 "마지막으로 북마크 때문에 곤란했던 게 언제예요?"라고 물었더니 셋 다 기억을 못 했다. 지금 무언가로 때우고 있지도 않았다 — 그냥 안 불편했다. 코드 한 줄 짜지 않고 1일차에 접었다. 예전의 나라면 240시간을 또 묻었을 자리다.

통과 — 지금의 앱 아이디어. 1일차에 3명이 전부 "어제도 그랬다"고 답했다. 2일차에 사람들이 엑셀과 메모장으로 수작업하는 흔적을 확인했고, 비슷한 유료 앱도 있었다. 3일차 랜딩 폼에서 100조회 중 7명이 등록했고, 그중 1명이 대기명단에 이메일까지 남겼다. 세 신호 모두 Go. 그제야 처음으로 코드를 켤 자격을 얻었다.

차이는 분명하다. 탈락한 건 내 결핍이었고, 통과한 건 남의 결핍이었다. 72시간은 그 둘을 가르는 가장 싼 필터다.

Go/No-Go — 내가 나에게 거는 규칙

프레임워크가 작동하려면 규칙을 나보다 위에 둬야 한다. 그래서 새 아이디어가 떠오를 때마다 노트 첫 줄에 적는다.

• 1일차 문제 인터뷰 3명 중 과거형으로 진짜 겪은 사람이 1명 이하면 → 즉시 폐기
• 2일차 돈·시간·검색의 흔적 중 하나도 못 찾으면 → 폐기
• 3일차 통과 기준은 실험 시작 전에 적는다 (사후 기준 변경 금지)
• 세 신호 중 둘 이상 Go가 아니면 코드 한 줄도 짜지 않는다

가장 지키기 어려운 건 마지막이다. 손이 근질거리는 걸 막는 게 검증의 8할이다. 하지만 6개의 시체가 가르쳐준 게 정확히 이거다 — 빌드는 검증이 아니다. 빌드하고 싶은 마음을 이기는 것이 검증이다.

다음 계획

이 72시간 프레임워크는 어떤 아이디어를 죽일지는 잘 가르쳐주지만, 통과한 여러 개 중 무엇을 먼저 할지는 아직 못 정해준다. 통과한 아이디어가 둘 이상 쌓이면 그때부터는 선택의 문제다.

그래서 다음 글에선 통과한 아이디어들 사이의 우선순위를 어떻게 매기는지 — 시장 크기·내 적합도·인프라 재사용도를 한 점수표로 묶어 — 따로 적을 생각이다.

검증은 시작할 자격을 가르고, 선택은 순서를 가른다. 6개월을 태운 그 시절에 나에게 없던 건, 정확히 이 두 단계였다.