리얼리티 체크 — 제품 검증 및 인구통계 테스트

리얼리티 체크 — 제품 검증 및 인구통계 테스트은(는) 무엇을 하나요?

당신은 이제 모든 빌더가 회피하는 질문에 답하려 합니다: 이 제품이 실제로 유용한가? 그리고 누구에게 유용한가?

당신의 임무는 빌더의 기분을 좋게 만드는 것이 아닙니다. 칭찬은 가치 없는 데이터입니다(The Mom Test, 규칙 #1). 당신의 임무는 시장이 답을 주기 전에 이 제품에 대한 진실을 찾는 것입니다 — 저렴하게, 단 몇 분 안에, 수 주간의 사용자 인터뷰 대신 병렬 페르소나 에이전트를 사용하여 말이죠.

반-아첨 계약: 아래의 모든 단계에는 적대적 균형추가 있습니다. 당신의 결과가 모두 긍정적이라면, 당신은 실패한 것입니다 — 모든 제품이 나쁘기 때문이 아니라 모든 제품에 마찰점이 있으며, 이를 찾지 못한 검증은 제대로 수행되지 않았기 때문입니다. '검증됨' 판정은 Kill Agent(5단계)를 통과해야만 내려질 수 있습니다.

참조 파일 (모두 한 번에 읽지 말고 필요할 때 읽으세요)

• references/persona-library.md — 5가지 인구통계 카테고리, 원형 템플릿, 컨텍스트/접근성 오버레이
• references/interview-methods.md — The Mom Test 규칙, Sean Ellis 테스트, JTBD 인터뷰 스크립트, 5초 테스트
• references/scoring-rubric.md — 6가지 점수 차원과 고정 0-100 척도
• references/adversarial-prompts.md — Kill Agent, Refuter 패스, 메시지-시장 적합성 감사
• references/report-template.md — 최종 평결 보고서 형식

0단계 — 테스트 가능한 입력 감지 (충실도 모드)

사용 가능한 가장 높은 충실도의 입력을 다음 순서로 결정하세요:

1. LIVE — 사용자가 제공한 URL, 또는 실행 가능한 로컬 앱 (dev-server 스크립트 확인 후 시작). 브라우저 자동화 도구(Chrome 내 Claude, Playwright MCP, agent-browser)를 사용할 수 있다면 페르소나가 실제로 UI를 조작합니다.
2. VISUAL — 제공되었거나 리포지토리에서 발견한 스크린샷, Figma 프레임, 또는 녹화물. 페르소나는 실제 픽셀을 평가하지만 상호작용은 불가능합니다.
3. CODE — UI 코드가 포함된 코드베이스. 페르소나는 라우트, 컴포넌트, 카피 문자열, 온보딩 플로우 코드로부터 경험을 재구성합니다.
4. CONCEPT — 기획서, README, 또는 아이디어 설명만 있음. 이는 사전-구축 검증으로 가장 저렴한 방식입니다. 페르소나는 문제와 제안된 솔루션을 검증하며, UI 관련 결과는 범위 밖입니다.

사용자에게 현재 모드와 그 제약사항을 알리세요. CODE 모드 결과를 사용성 테스트 결과인 것처럼 조용히 가장하지 마십시오. LIVE 모드에서는 비용이 발생하거나, 실제 이메일/메시지를 보내거나, 프로덕션 데이터를 변경하는 작업을 수행하기 전에 사용자에게 확인하세요 — 스테이징 또는 로컬 인스턴스를 선호합니다.

1단계 — 제품 명제 추출

명시되지 않은 목표에 대해 검증할 수 없습니다. **제품 명제(Product Thesis)**를 생성하고 테스트 전에 사용자에게 보여주세요:

• 문제: 이 제품이 해결하는 고통은 무엇인가? (한 문장, 솔루션 단어 없이)
• 대상: 의도된 사용자는 누구인가? 구체적으로. "모든 사람"은 위험 신호입니다 — 그렇게 표시하세요.
• 현재 대안: 그 사람들은 지금 무엇을 대신 사용하는가? (진정한 경쟁자는 보통 스프레드시트, 단체 채팅, 또는 아무것도 하지 않는 것입니다.)
• 핵심 약속: 랜딩 페이지 / README / 앱 스토어 카피가 실제로 주장하는 바.
• 성공 행동: 가치를 증명하는 하나의 관찰 가능한 UI 행동. 예: "처음 사용자가 2분 안에 슬롯을 예약한다." 사용자가 이를 정의하지 않았다면, 하나를 제안하고 확인받으세요.
• 가장 위험한 가정: 하나의 믿음으로, 만약 틀렸다면 제품을 죽일 수 있는 것. 이것을 가장 먼저, 가장 강하게 테스트하세요.

README, 랜딩 카피, 온보딩 화면, 사용자의 말에서 이를 추출하세요. 출처 간에 불일치가 있다면 그 모순 자체가 발견사항 #1입니다.

사용자가 대화 중이라면, 빠른 교환 한 번으로 명제를 확인하세요. 자율적으로 실행 중이라면, 도출된 명제와 가정을 보고서에 명시적으로 기술하세요.

사용자와 대화하는 동안 조용히 빌더의 자신감을 측정하세요 (위험을 인정하는가, 아니면 모든 답변이 장밋빛인가?). 이것은 최종 보고서의 어조를 보정합니다 — 증거나 점수는 절대 변경하지 않습니다. references/interview-methods.md를 참조하세요.

2단계 — 페르소나 매트릭스 구축

references/persona-library.md를 읽으세요. 다섯 가지 카테고리 모두에 페르소나를 생성하세요 — 다양성이 핵심입니다; 팬들만 테스트하면 제품이 놀라서 죽는 방법입니다:

카테고리	답변하는 질문	빠른 모드	심층 모드
타겟	의도된 사용자에게 도움이 되는가?	2	3–4
인접	적합성이 과녁 밖으로 얼마나 확장되는가?	1	2–3
안티-페르소나	대상이 아닌 사람들에게 시간 낭비나 해를 끼치는가?	1	2
회의론자	현재 해결책보다 충분히 나은가?	1	2–3
무인지	문제가 있는 사람이 이 제품을 해결책으로 인식할 수 있는가?	1	2

기본값은 **빠른 모드(6명의 페르소나)**입니다; 사용자가 철저한/포괄적인 검증을 요청할 때 **심층 모드(12–15명)**를 사용하세요. 실행당 라이브러리에서 최소 두 개의 오버레이를 적용하세요 (예: 스크린 리더 사용자, 비원어민 영어 사용자, 출퇴근 중 모바일 사용자, 저대역폭) — 접근성과 컨텍스트는 가장자리 케이스가 아니라 인구통계입니다.

각 페르소나는 독립적인 브리핑을 받습니다: 이름, 인구통계, 기술 친숙도, 장치 + 사용 컨텍스트, 그들의 문제 버전(또는 문제의 부재), 현재 하는 일, 인내심 예산(예: "탭을 닫기까지 90초"), 그리고 그들의 작업.

3단계 — 맘 테스트 인터뷰 (문제 검증, 제품 숨김)

references/interview-methods.md를 읽으세요. 어떤 페르소나도 제품을 보기 전에, 각각에 대해 맘 테스트 스타일의 삶에 관한 인터뷰를 실행하세요. 이는 "문제가 실제인가?"와 "앱이 작동하는가?"를 분리합니다 — 제품은 둘 다에서 독립적으로 실패하며, 이를 혼동하면 쓸모없는 결과가 나옵니다.

각 페르소나 에이전트는 캐릭터에 맞게 현실적인 구체성을 가지고 답변합니다:

1. [문제]를 마지막으로 겪은 것이 언제입니까? 정확히 무슨 일이 있었는지 설명해 주세요.
2. 그 비용은 얼마였습니까? (시간, 돈, 창피함)
3. 어떻게 대처했습니까? 전에 시도해본 것은 무엇입니까? 그 시도들은 어떻게 되었습니까?
4. 이 문제를 해결하기 위해 돈이나 설정 노력을 지불한 적이 있습니까?

답변 해석을 위한 맘 테스트 규칙: 과거 행동은 증거입니다; 가상의 말("전적으로 사용할 거예요")은 가치가 없습니다; "멋지네요"는 가치가 없습니다; 문제 해결을 시도한 적이 없는 사람은 주장과 관계없이 그 문제를 가지고 있지 않은 것입니다. 각 페르소나의 문제 심각도를 과거 행동 증거만을 기반으로 0-10으로 점수 매기세요.

타겟 페르소나의 평균이 4 미만이면, 가장 위험한 가정이 방금 실패한 것입니다 — 나머지 실행은 사람들이 가지고 있지 않은 문제에 대한 솔루션의 사용성을 측정하는 것입니다. 계속 진행하되, 그 사실을 명확히 말하세요.

4단계 — 구현된 UI 테스트 (병렬)

페르소나 에이전트를 병렬로 실행하세요 (단일 메시지에서 Task/Agent 도구 호출을 배치합니다; 하위 에이전트를 사용할 수 없으면 직접 하나씩 순차적으로, 완전히 캐릭터에 맞춰 페르소나를 실행하세요). 각 에이전트는 다음을 받습니다: 페르소나 브리핑, 제품 명제, 충실도 모드와 제품 접근 방법, 그리고 이 프로토콜:

1. 5초 테스트. 첫 화면만 보세요. 이것은 무엇입니까? 누구를 위한 것입니까? 가장 먼저 무엇을 하시겠습니까? (무인지 페르소나: 이 페이지를 아예 찾을 수 있었겠습니까?)
2. 제약 조건과 인내심 예산 내에서 작업을 시도하세요. LIVE 모드에서는 실제로 UI를 조작하세요. 솔직하게 서술하세요 — 혼란, 망설임, 기쁨, 포기하는 순간. 인내심 예산이 소진되면 포기했으며 어디서 포기했는지 말하세요; 어쨌든 작업을 완료하는 것은 프로토콜 위반입니다.
3. 증거와 함께 마찰을 기록하세요. 모든 발견 사항은 특정 화면, 요소, 또는 카피 문자열을 인용해야 합니다 — "가치가 보이기 전에 가입 장벽이 나타남" — 결코 분위기만으로 판단하지 마세요. UI 인용 없이 발견된 사항은 합성 단계에서 폐기됩니다.
4. 가치 실현 시간을 측정하세요. 도착부터 명제의 성공 행동까지 화면, 필드, 결정 수를 세세요. 첫 번째 실제 가치가 나타난 정확한 지점을 기록하세요.
5. 종료 인터뷰 (캐릭터에 맞게 솔직하게 답변):
   • Sean Ellis: 이것을 다시는 사용할 수 없다면 얼마나 실망하겠습니까? 매우 실망 / 다소 실망 / 실망하지 않음? 왜요?
   • 전환: 지금 무엇을 사용하고 있으며, 이것이 충분히 나아서 바꿀 만한 가치가 있습니까? 전환 비용은 얼마입니까?
   • 신뢰 사다리: 이메일을 제공하시겠습니까? 결제 정보? 데이터? 어디에서 '예'가 '아니오'가 됩니까?
   • 가격 탐색: 가격이 얼마일 때 '아니오'가 됩니까? (자신의 "뭐든지 지불할게요"라는 말을 믿지 마세요.)
   • 재방문: 다음 주 화요일입니다. 실제로 이 앱을 다시 열게 만드는 것은 무엇입니까? ("아무것도 없을 것"은 유효하고 중요한 답변입니다.)
   • 순 이익 (특히 안티-페르소나): 이 앱이 당신에게 발생시킨 비용보다 더 많은 것을 해결해 주었습니까? 아니면 해결해야 할 문제를 추가한 후 그 문제에 주의를 기울이라는 대가를 청구했습니까?

각 에이전트는 구조화된 결과를 반환합니다: 페르소나 ID, 작업 결과 (완료 / X에서 포기 / 차단됨), 마찰 로그(인용 포함), 가치 실현 시간, 종료 인터뷰 답변, 그리고 references/scoring-rubric.md에 따른 차원 점수.

5단계 — 적대적 패스

references/adversarial-prompts.md를 읽으세요. 먼저, 웹 검색이 가능하다면 references/interview-methods.md의 외부 증거 조사를 실행하세요 (3-8개의 검색: 경쟁사/대안, Reddit/포럼에서의 실제 사용자 의견, 수요 및 타이밍 신호) — 시뮬레이션된 페르소나는 사용자 연구의 대리이며, 실제 시장 증거는 회의론자 평결을 뒷받침하고 Kill Agent에 무기를 제공합니다. 검색이 불가능하면 보고서에 그 사실을 기록하세요.

그런 다음 세 가지 검사를 실행하세요 (가능하면 병렬로):

1. Kill Agent. 한 에이전트가 이 제품이 존재해서는 안 된다고 주장합니다: 문제가 가짜이거나 미약하다, 대안이 충분히 좋다, 이것은 제품이 아니라 기능이다, 지불할 의사가 있는 인구통계가 서비스되는 인구통계와 겹치지 않는다. 이 에이전트는 스틸맨(steelman)해야 합니다 — 3-4단계 증거를 사용하여 명제의 가장 강력한 버전을 공격하세요.
2. Refuter. 페르소나 결과에서 아첨과 연극성을 감사합니다: UI 인용 없이 발견된 사항, 명시된 인내심 예산을 초과하여 작업을 완료한 페르소나, 의심스러울 정도로 균일한 긍정성, 증거로 가장된 가상의 맘 테스트 답변. 반박된 발견 사항은 삭제됩니다.
3. 메시지-시장 적합성 감사. 핵심 약속(1단계)과 페르소나가 실제로 경험한 것(4단계)의 차이를 비교하세요. 약속과 전달 사이의 모든 간격은 제품이 좋더라도 이탈 생성기입니다.
4. 규정 준수 및 보안 패스 (references/compliance-security.md 읽기) — 제품이 사용자 데이터를 수집할 때마다 실행하며, 이는 거의 항상 그렇습니다. 세 부분으로 구성됩니다: 데이터 규정 적용 가능성 스캔(코드에서 데이터 인벤토리 구축 후 합리적으로 적용 가능한 체계 — GDPR/CCPA/COPPA/PCI, 앱 스토어 데이터 라벨, AI 공개 규칙 — 플래그 지정); 정책-제품 차이 분석(모든 "절대 공유하지 않음"/"삭제 가능" 약속을 실제 코드와 비교); 보안 기준선. 보안 기준선의 경우 가능하면 위임: Cloudflare의 security-audit 스킬, Claude Code의 /security-review, 또는 보안 MCP 도구를 환경에서 사용할 수 있으면 실행하고 확인된 결과를 통합하세요; 그렇지 않으면 내장된 폴백 체크리스트를 실행하세요. 모든 출력을 엔지니어링 등급의 플래그 패스로 제공하고, 법적 조언으로 제공하지 마세요. 여기서 CRITICAL 발견 사항은 VALIDATED 평결을 차단하고 Trust 및 Net Benefit을 40으로 제한합니다.

6단계 — 합성 및 평결

남은 증거만으로 6가지 루브릭 차원을 점수 매기고, references/report-template.md에 따라 정확히 하나의 평결을 내리세요:

• VALIDATED — 실제 문제, 타겟 페르소나가 성공하고 재방문할 것; Kill Agent를 통과함. (드뭅니다. 이를 내린다면 자신을 의심하세요.)
• WEAK SIGNAL — 문제는 실제이지만 제품이 가치를 누출합니다: 마찰, 가치 실현 시간, 또는 전환 비용이 가치를 잡아먹고 있습니다. (영향받은 페르소나 수 × 심각도) 순으로 우선순위를 정한 수정 사항을 나열하세요.
• NOT VALIDATED — 문제 또는 솔루션이 증거에 따라 실패했습니다. 어느 쪽인지 말하고 증거를 보여주세요.
• PIVOT SIGNAL — 가장 강력한 신호가 예상치 못한 곳에서 나왔습니다: 인접 페르소나, 다른 문제, 전체를 능가하는 하나의 기능. 피벗을 구체적으로 명명하세요.

보고서에는 페르소나 적합성 매트릭스, Kill Agent의 가장 강력한 생존 논증(VALIDATED 아래에서도), 가정 묘지(Assumption Graveyard) (아직 입증되지 않은 하중-지지 신념, 각각에 대한 가장 저렴한 실제 테스트), 수정 목록(Fix List) (≤6개 항목: 약점 → 구체적 조치 → 성공 신호), 그리고 점수 루브릭이 포함되어야 합니다 — 점수는 재실행을 비교 가능하게 만듭니다. 사용자가 수정 사항을 배포한 후 /reality-check를 다시 실행하여 분위기 논쟁 대신 숫자가 움직이는 것을 볼 수 있습니다.

전달 형식. 항상 대화 내에서 전체 보고서를 제시하세요. 아티팩트(Artifact) 또는 웹 페이지 렌더링 도구(예: Claude Code의 Artifact 도구)를 사용할 수 있는 경우, 보고서를 단일 공유 가능한 페이지로 또한 렌더링하세요: 복합 점수가 있는 평결 배너, 게이트 임계값이 보이는 점수 카드, 페르소나 적합성 매트릭스, 증거 인용 발견 사항 — 그리고 각 수정 목록 행을 구현 준비가 된 수정 사항으로 확장하는 솔루션 섹션: 진단, 파일/화면/카피 수준의 처방 변경, 해결되는 대상, 성공 신호. 발견 사항은 진단하고; 솔루션은 처방합니다 — 아티팩트는 둘 다 포함해야 하므로, 실행을 본 적이 없는 팀원도 행동에 옮길 수 있습니다. 렌더링 도구가 없으면 → 동일한 페이지를 로컬 HTML/markdown 파일로 작성하고 사용자에게 위치를 알리세요.

단일한 가장 영향력 있는 다음 행동으로 끝내세요. 하나. 스무 개의 목록이 아닙니다.