Business Driven Development AI Agent

서비스 설계 초보도 전문가처럼.

기획도 코딩도 처음이라면, PurplePrint와 서비스를 만들어보세요. 사용하는 AI 에이전트 안에서 아이디어를 설계로 구체화하고, 구현·공개·고객을 찾는 실행까지 이어갑니다.

데모 둘러보기내 아이디어로 시작하기

14일 무료 · 카드 등록 없음

이미 만든 서비스가 있다면 → 점검하기

AI 도구에서도Claude CodeCodexCursorVisual Studio CodeGoogle Antigravity
PurplePrint 설계 코치 전체 화면: 왼쪽 프로젝트 목록, 가운데 코치 대화, 오른쪽 Phase 0~9 진행PurplePrint 설계 코치 전체 화면: 왼쪽 프로젝트 목록, 가운데 코치 대화, 오른쪽 Phase 0~9 진행

먼저 써 본 사람들이 알게 된 것

실제 사용자 후기 원문에서

Hyper-Research경쟁사가 이미 같은 걸 하고 있었는데, 몰랐어요.
AI 프롬프트 서비스, 개발자 출신 대표, 2인 팀
Hyper-Research우리 서비스가 왜 안 먹히는지, 드디어 알았어요.
헬스케어 앱, 비개발자 1인 창업자
Hyper-Scenario기능은 다 있었는데, 유저가 핵심까지 가는 길이 없었어요.
커머스 앱, 비개발자 기획자 출신 대표, 2인 팀
작동 방식

말하고, 정하고, 이어가세요

기획을 몰라도 돼요. 질문에 하나씩 답하다 보면 설계가 완성돼요.

  1. 아이디어를 말해요

    만들고 싶은 것을 평소 말로 설명하면 코치가 필요한 것부터 물어요.

  2. 1순위를 보고 정해요

    코치가 후보와 1순위, 뺀 이유까지 먼저 제안해요. 맞는지만 확인하면 돼요.

  3. 문서로 남기고 이어가요

    정한 내용이 설계 문서로 남고 구현과 출시로 이어져요.

기능

설계의 순서를 코치가 이끌어요

코치가 후보와 1순위를 제안하는 대화, 옆에 Phase 0~9 진행코치가 후보와 1순위를 제안하는 대화, 옆에 Phase 0~9 진행

코어 엔진

Hyper Series

Design Coach가 제품 설계도를 세우면, Hyper 엔진은 더 깊은 근거가 필요하거나 출시 판단을 강화해야 할 때 그 설계를 조사하고 반박하고 시뮬레이션합니다.

39 AXES · RECURSIVE REVIEW

그럴듯한 설계와 개발 가능한 설계가 갈리는 지점.

코딩 전에 인풋 성숙도를 진단하고 39개 설계 축을 재귀 점검합니다. 빠진 화면·정의 안 된 테이블·끊긴 흐름을 심각도순으로 꺼내 교정 경로까지 반환합니다.
샘플 리포트 보기Hyper-Review 시작

PurplePrint 실제 출력

시나리오 결과까지 봤으니, 이제 Hyper-Review로 전체 설계를 한 번 점검해 주세요.

Hyper-Review 점검을 요청했어요 외 1개
  • Hyper-Review 점검을 요청했어요
  • 점검 결과를 확인했어요

PurplePrint 코치

좋아요. 목록에서 빼는 의미를 지금 확정하기보다, 시나리오 리포트와 현재 설계 문서를 함께 Hyper-Review에 보내 전체 설계를 먼저 점검할게요. 점검 대상 문서가 서버로 전송돼요.

PurplePrint 코치

말씀하신 대로 ‘목록에서 빼기’의 의미는 아직 정하지 않고, 전체 설계 Hyper-Review를 시작했어요. 시나리오 리포트와 제품·UX·화면·디자인 문서가 점검 대상으로 서버에 전송됐어요.

점검은 백그라운드에서 진행 중이고 보통 20~40분 걸려요. 아직 결과가 나오지 않아 설계 문서는 수정하지 않았어요. jobId는 rev-4b6b0e2e-cb2d-4e5b-8a6a-d0e1d85e5699예요. 결과가 준비되면 이 번호로 확인해 이어갈게요.

빌더 레벨 2 / 9

지금 단계는 만든 문서로 표시되어 있어요.
설계를 이끌어가는 행동 측정은 아직 기록되지 않았어요.

Phase 6 가이드를 불러왔어요 외 7개
  • 코치를 켰어요
  • 문서 목록을 봤어요
  • Phase 6 가이드를 불러왔어요
  • 문서를 읽었어요
  • 문서를 읽었어요
  • 문서를 읽었어요
  • 문서를 읽었어요
  • 문서를 읽었어요

PurplePrint 코치

다시 오셨어요, 데모님! 냉장고 지도 이어가요. Phase 6까지 했어요. 다음은 “Phase 6 1차 표면 점검을 완료했어요. R1~R6와 시나리오 27개 축에서 문서 간 제거 의미 불일치, 저장 안내 불일치, 재방문 계기와 복구 규칙의 미검증을 확인했어요. 설계 문서는 아직 수정하지 않았고, ‘목록에서 빼기’가 무엇을 뜻하는지 먼저 확정해야 해요.”였어요. 이어서 갈게요.

PurplePrint 코치

먼저 정할 것은 ‘목록에서 빼기’가 먹었다는 기록인지, 더는 목록에서 관리하지 않는다는 뜻인지예요. 혼자 사는 사용자가 간단히 기록할 수 있어야 하고, 앱이 실제로 먹었는지 알 수 없다는 점도 함께 봐야 해요.

후보는 세 가지예요.

  • 재료를 실제로 다 썼을 때만 빼요. 버리거나 다른 곳으로 옮긴 재료는 뜻이 맞지 않을 수 있어요.
  • 이유를 묻지 않고 목록에서만 빼요. 이 방향을 추천해요. 먹었는지 앱이 단정하지 않고, 기록할 때 추가 입력도 생기지 않아요.
  • 뺄 때 먹음·버림 같은 이유를 남겨요. 낭비를 돌아보는 데 도움은 되지만, 현재 확인되지 않은 기록 부담을 더해요.

저는 두 번째가 지금의 첫 버전에 가장 잘 맞는다고 생각해요. 되돌리기는 실수로 뺀 항목을 5초 안에 복구하는 역할로 두면 돼요. 어떤 상황이 서비스의 뜻과 가장 가까워요?

빌더 레벨 2 / 9

지금 켜진 칸은 지금까지 만든 문서를 나타내요.
다음 칸부터는 설계를 끌고 가는 과정에서 열려요. 아직 행동 측정 기록은 없어요.

점검이 끝났다는 메일이 왔어요. 결과 같이 볼까요?

점검 결과를 확인했어요 외 1개
  • 지난 점검을 확인했어요
  • 점검 결과를 확인했어요

PurplePrint 코치

네, 같이 볼게요. 결과는 “설계가 틀렸다”는 판정이 아니라, 지금 확인된 내용과 아직 가정인 내용을 나눈 진단이에요.

전체 보고서는 docs/review/PurplePrint-HyperReview-rev-4b6b0e2e-cb2d-4e5b-8a6a-d0e1d85e5699.md에 저장했어요. 오른쪽 문서 작업 공간에서 볼 수 있어요.

먼저 볼 핵심

발견 19건 중 핵심 이슈는 18개예요. 가장 큰 뿌리는 제품 방향이 불분명한 게 아니라, 누구에게 특히 필요한지, 현재 방법보다 어느 순간에 나은지, 실제 재료 활용으로 이어지는지가 아직 확인되지 않았다는 점이에요.

이번 Phase 6에서 확인한 문제와도 겹치는 내용이 많아요.

  • 목록에서 빼기: 실제로 먹었다는 기록인지, 목록만 정리하는 행동인지 문서마다 달라요.
  • 저장 약속: 휴대폰 저장 안내와 실제 저장·복구 방식이 아직 맞춰지지 않았어요.
  • 가치 확인: 앱을 다시 연 것과 재료를 실제로 활용해 버리는 일을 줄인 것은 서로 다른 결과예요.
  • 목록 이해: 맨 위 재료가 먼저 먹어야 할 재료처럼 읽힐 수 있고, 같은 이름이나 긴 목록을 다루는 방법도 더 확인해야 해요.

보고서는 먼저 첫 버전이 약속하는 사용자 순간과 결과를 한 문장으로 좁히라고 권해요. 그다음 사용자와 현재 대안을 확인하고, 재방문·재료 활용·폐기 감소를 각각 나눠 살펴보는 순서예요. 다만 지금 진행 중인 Phase 6을 마치려면 목록에서 빼기의 의미부터 확정하고 관련 문서를 맞춘 뒤 전체 점검을 다시 해야 해요.

제 관점에서 보고서의 날짜 지적은 다른 항목보다 근거가 약해 보여요. 기준 문서가 8월에 갱신됐다는 사실만으로 10월 검증 자료의 날짜가 잘못됐다고 볼 수는 없으니, 실제 파일 작성 이력과 검증 범위를 확인하는 정도로 다루는 게 맞아요.

보고서 §11 · AI에게 넘길 메시지

첨부된 보고서를 읽고 먼저 제품이 약속하는 사용자 순간과 첫 버전 범위를 파악해 주세요. 그다음 대상 사용자 문제와 경쟁 대안을 확인해 공략 구간을 정리하고, 보고서의 권장 순서에 따라 사용자 흐름과 기술 기준을 보강해 주세요. 저장·복구·삭제, 목록에서 재료를 빼는 의미, 모바일 플랫폼은 자료에 없는 결정을 임의로 사실처럼 확정하지 말고 미정 사항으로 표시해 주세요. 기존 화면안과 디자인 자산을 보존하고, 원문 시안과 검증 근거의 최신 버전을 확인해 주세요. 각 변경은 작은 단위로 진행하고 기존 흐름이 유지되는지 매 단계 확인해 주세요.

이제 Phase 6의 바로 다음 행동으로 돌아갈게요. 후보는 세 가지예요. “다 쓴 재료만 빼기”는 버리거나 옮긴 재료의 뜻을 담지 못해요. “빼는 이유를 기록하기”는 지금 사용자에게 추가 입력을 요구해요. 저는 먹었는지 단정하지 않고 목록에서만 빼기를 추천해요. 단순하고, 실수하면 5초 안에 되돌릴 수 있기 때문이에요.

빌더 레벨 2 / 9

켜진 칸은 지금까지 만든 문서를 나타내요.
설계를 끌고 가는 행동을 측정한 기록은 아직 없어요.
다음 칸은 이후 작업 과정에서 열려요.

PurplePrint Hyper-Review · 요리할 때 냉장고 안쪽에 잊고 있던 재료를 다시 알아차리도록 돕는 모바일 목록 앱이에요.

방식: 전체 점검 · 점검일: 2026-10-06 발견 19건 → 핵심 이슈 18개

§0. 제품 정체성 + 최상위 가치

이 제품이 '무엇을 위한 것인지'와 '가장 중요한 가치'가 한눈에 서 있는지 봐요. 여기가 흐릿하면 아래 대부분이 흔들려요.

  • 한 문장 정의: 요리할 때 냉장고 안쪽에 잊고 있던 재료를 다시 알아차리도록 돕는 모바일 목록 앱이에요.
  • 최상위 가치: 요리할 때 먼저 확인할 재료를 알아차리게 도와 음식물을 버리는 일을 줄이는 것이에요.
  • 한 마디 테스트: "요리 전에 잊은 재료를 다시 보여주는 목록" → clear: 사용 순간과 대상, 기대하는 도움이 구체적으로 드러나요. 다만 재방문이나 음식물 폐기 감소 효과는 아직 검증되지 않은 가설이에요.
  • 명확도: 정체성 clear · 최상위가치 partial
  • 왜 중요한가: 제품이 돕는 순간과 첫 버전의 좁은 범위는 비교적 선명해요. 다만 그 경험이 실제 재방문과 음식물 폐기 감소로 이어지는지는 확인되지 않았고, 경쟁 대안 중 어느 구간에서 더 나은지도 아직 정리되지 않았어요.
  • 출처: 설계 패키지: "요리할 때 먼저 먹을 재료를 알아차리게 도와 음식 버리는 일을 줄이는 것"

§1. 인풋 성숙도 진단

설계가 어디까지 갖춰졌는지, 각 요소가 실제 근거로 뒷받침되는지 진단해요. 비어 있는 칸이 지금의 빈틈이에요.

종합 등급: partial

구성 요소존재요약
제품 정체성과 최상위 가치✅요리할 때 잊고 있던 재료를 다시 알아차리게 돕는다는 제품 정의와 가치 가설이 있어요. 효과는 아직 검증되지 않았어요.
맥락 정의✅혼자 살며 재료를 한꺼번에 사고 냉장고 안쪽 재료를 잊는 상황이 설명돼 있어요. 문제 빈도와 기록을 중단한 이유는 미확인이에요.
사용자 정의✅첫 사용자와 생활 맥락, 실제 사용자 표현이 구체적으로 제시돼 있어요. 다른 사람에게도 흔한 문제인지는 인터뷰로 확인되지 않았어요.
문제와 기능 경로❌-
수익 경로❌검증 기간 무료 제공과 알림 구독 후보는 정했지만, 가격·상품·마진과 지불 의향 검증 기준은 미정이에요.
UX 경로✅목록·입력·수정 화면과 빈 상태, 저장 실패, 되돌리기 흐름이 자세히 기술돼 있어요. 실제 기기 확인은 아직 필요해요.
디자인 보존성❌-
시장 검증 경로❌유입 채널, 메시지, 검증 목표를 담은 마케팅 계획은 입력에 포함되지 않았어요.
기술 설계❌저장 방식과 재설치·기기 변경 시 보존 및 복구 방식이 미정이에요. 개발 설계나 코드·실행 증거는 제공되지 않았어요.
핸드오프 준비도❌목록에서 빼기의 의미, 저장·복구 약속, 중복 저장 처리 등 구현에 필요한 결정이 남아 있어 바로 인계하기에는 부족해요.

강점:

  • 첫 버전의 범위를 좁히고, 기록 순서가 식품 안전 판단이 아니라는 점을 반복해서 밝혀 오해 위험을 줄였어요.
  • 저장 실패, 로딩 실패, 빈 상태, 되돌리기처럼 실제 흐름에서 생길 수 있는 상황을 구체적으로 다뤘어요.
  • 문서 검토와 실제 사용자 검증의 차이를 구분하고, 미확인 사항을 숨기지 않았어요.

빈틈:

  • 경쟁 서비스를 열거했지만 사용자 여정의 단계별 대안과 제품이 맡을 구간을 비교한 지도는 없어요.
  • 첫 사용자와 핵심 가치가 가설 단계여서 문제 빈도, 재방문, 활용 효과를 확인할 자료가 부족해요.
  • 저장·복구 방식과 목록에서 빼기의 의미가 정해지지 않아 구현 경계가 열려 있어요.
  • 유입 및 검증 계획과 정식 수익 조건이 아직 구체화되지 않았어요.

§2. 보존 체크리스트 · 건드리면 안 되는 것

이미 만들어 둔 것 중 바꾸면 안 되는 것들이에요. 아래 제안을 반영할 때 이 항목들이 깨지지 않게 매 단계 확인해요.

입력에는 화면 흐름, 시각 방향, HTML 시안이 기존 설계 자산으로 기술돼 있어 보존 확인이 필요해요. 다만 해당 파일과 실제 구현은 이번 자료에 포함되지 않아 문서에 적힌 범위만 기준으로 삼을 수 있어요.

항목지켜야 함비고
기존 UX 흐름✅목록 중심 시작 화면, 재료 입력·수정 흐름, 빈 상태와 실패 상태를 보존 대상으로 기록해요.
기존 UI 디테일✅-
디자인 토큰/시각 언어✅-
기존 로직/계약✅-
유저가 명시적으로 지키려는 항목✅-

§3. 인풋 분류 + 점검 범위

이 인풋이 어떤 종류의 설계인지 분류하고, 실제로 어디까지 점검했는지 밝혀요.

  • 인풋 분류: 서비스 설계 · 제품 맥락, 사용자, 기능, 수익 방향, UX와 시각 방향은 포함돼 있지만 아키텍처·데이터 모델·API 등 개발 설계는 제공되지 않았어요.
  • 실제 점검 범위: 39개 관점 중 39개를 시나리오로 점검했어요. 원문 대조·관점별 시나리오·추가 근거·설계 원칙 4단계를 17라운드 돌았어요.

§4. 팀 역량 진단

개별 이슈를 넘어, 이 팀에 지금 가장 필요한 역량이 무엇인지 진단해요. 강점을 먼저 짚고 보강 지점을 이어가요.

핵심 진단: 팀은 초기 제품 방향과 사용자 화면의 초안을 만드는 역량을 보여주고 있어요. 다음 보강 지점은 사용자 문제를 집단 근거와 경쟁 여정으로 확인하는 조사·시장 검증 역량, 행동을 가치 결과와 연결해 측정하는 역량, 그리고 저장·개인정보·운영 기준을 구현 가능한 결정으로 닫는 기술 기획 역량이에요. 이는 아이디어가 부족하다는 뜻이 아니라, 초기 설계에서 가설을 실제 사용자 증거와 실행 기준으로 전환하는 과정이 아직 충분히 문서화되지 않았다는 의미예요.

강점:

  • 제품의 첫 사용 순간과 핵심 가치가 한 문장으로 설명될 정도로 방향이 선명해요.
  • 첫 버전의 기능 범위를 목록 중심으로 제한하고 주요 사용 흐름을 정리했어요.
  • 검증되지 않은 사용자 문제와 가치 가설을 이미 구분하고 있어요.
  • 저장, 복구, 행동 의미 등 결정을 더 확인해야 할 지점을 자료에 드러냈어요.

보강할 역량:

  • 대상 사용자의 문제 빈도와 기록을 중단하는 이유를 확인하는 사용자 조사 역량을 보강할 수 있어요.
  • 전체 사용자 여정과 경쟁 대안을 비교해 제품이 이길 구간을 선택하는 시장 분석 역량이 필요해요.
  • 재방문, 재료 활용, 폐기 감소를 서로 구분해 판단하는 측정 설계 역량을 보강할 수 있어요.
  • 저장·복구·삭제·접근성·장애 대응을 사용자 약속과 구현 기준으로 연결하는 기술 기획 역량이 필요해요.
  • 검증 시안과 자료의 원문, 날짜, 플랫폼 전제를 후속 작업자가 확인할 수 있게 인계하는 문서 관리 역량을 보강할 수 있어요.

기본 방향과 초안은 이미 잡혀 있어요. 사용자와 경쟁 대안을 확인해 첫 버전의 공략 구간을 좁힌 뒤, 필요한 조사와 구현 기준을 순서대로 채우면 설계가 훨씬 단단해져요.

§5. 근본 원인 체인

겉으로 드러난 여러 문제의 하나의 뿌리를 인과로 이어봤어요. 앞쪽(뿌리)을 풀면 뒤쪽이 함께 풀려요.

현재 정의된 제품 정체성과 최상위 가치를 첫 버전의 약속으로 좁혀 확정 → 대상 사용자의 문제 빈도와 현재 대안을 확인 → 전체 여정에서 이길 구간과 제품 약속을 정함 → 실제 사용과 음식물 폐기 감소를 확인할 검증 경로를 마련 → 목록 사용성·저장 신뢰·운영 기준을 구현 가능한 수준으로 정리 → 확인된 가치에 맞춰 유료화 기준을 결정

제품 정체성과 최상위 가치는 비교적 선명하지만, 그 약속이 어떤 사용자 집단의 반복되는 문제를 해결하고 경쟁 대안보다 나은지 아직 확인되지 않았어요. 따라서 핵심 공략 구간과 가치 검증 경로를 먼저 정리한 뒤, 사용 흐름·저장 신뢰·운영 기준을 닫고 유료화 가능성을 판단하는 순서가 적절해요.

정체성 영향: 제품이 요리할 때 냉장고 안쪽의 재료를 다시 알아차리게 돕고 음식물 폐기를 줄인다는 방향은 명확해요. 발견의 중심은 정체성 부재가 아니라, 그 약속이 어느 사용자에게 특히 필요한지, 경쟁 대안보다 어느 구간에서 나은지, 실제 재료 활용과 폐기 감소로 이어지는지가 아직 검증되지 않았다는 점이에요.

먼저 살릴 강점:

  • 첫 버전이 재료 이름과 등록일을 보여주는 모바일 목록 앱이라는 범위가 비교적 구체적이에요.
  • 재방문, 재료 활용, 음식물 폐기 감소를 이미 가설로 구분하고 검증되지 않은 부분을 숨기지 않았어요.
  • 첫 실행, 목록 확인, 저장 실패 시 재시도 등 주요 사용자 흐름의 초안이 마련돼 있어요.
  • 저장 방식과 재료를 목록에서 빼는 의미처럼 미정인 결정을 자료에서 식별하고 있어요.

§6. 핵심 이슈 (18개 · 근본 원인 주제 7개)

핵심 이슈를 근본 원인이 같은 주제끼리 모았어요. 주제부터 보면 무엇을 한 번에 풀 수 있는지 보여요.

주제 1. 대상 사용자와 경쟁 구간의 근거가 아직 부족해요

제품 방향은 명확하지만, 대상 사용자의 문제와 현재 대안, 제품이 우위를 만들 구간이 함께 확인되지 않았어요. 이 기반은 첫 사용자 모집과 제품 약속을 좁히는 데 영향을 줘요.

  • 먼저 할 일: 대상 사용자의 문제 빈도와 전체 여정의 대안을 확인한 뒤 첫 버전이 맡을 구간을 정해요.
  • 이 주제의 이슈: C1 · C3 · C10

C1. [🔴 높음] 경쟁 우위와 사용자 여정의 기준이 아직 정리되지 않았어요 · 관련

  • 근본원인: 전체 사용자 여정과 경쟁 대안에 비추어 제품이 집중할 구간과 승리 논리가 정해지지 않았어요.
  • 요약: 기능 목록은 있으나 사용자가 현재 선택하는 대안과 제품이 맡을 여정의 구간이 연결돼 있지 않아요. 이 결정이 없으면 첫 버전의 차별 약속과 이후 검증 대상도 흐려져요.
  • 제안: 재료를 기억하고 확인하고 소비하는 여정을 단계별로 그린 뒤, 각 단계의 대안과 제품이 맡을 구간을 정리해요. 직접·인접 경쟁 대안의 우위와 대응 방향도 함께 결정해요.
  • 시나리오: 요리 전에 냉장고 재료를 확인하려는 사용자가 기존 메모나 다른 앱 대신 이 앱을 고를 이유를 아직 판단하기 어려워요.
  • 묶인 발견: 1건 (§8 참조)

C3. [🟡 중간] 첫 사용자의 문제가 다른 사람에게도 흔한지 아직 확인되지 않았어요

  • 근본원인: 첫 사용자 사례는 있으나 해당 문제가 대상 사용자 집단에 널리 나타나는지 확인할 근거가 부족해요.
  • 요약: 개인의 경험은 유용한 출발점이지만, 현재 자료만으로 집단 전체의 반복되는 문제라고 일반화하기 어려워요.
  • 제안: 혼자 살며 장을 보는 사용자를 대상으로 문제 빈도, 기록 중단 이유, 재료를 버리게 되는 상황을 확인하고 현재 가정을 조정해요.
  • 시나리오: 혼자 사는 직장인이 첫 재료를 기록하려 하지만, 실제로는 재료를 잊는 문제가 드물거나 기록을 계속하지 않는 다른 이유가 있을 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

C10. [🟡 중간] 제품 이름이 실제 목록보다 공간 지도 기능을 기대하게 할 수 있어요 · 관련

  • 근본원인: 제품을 설명하는 이름이 실제 첫 버전의 목록 기능보다 넓은 기대를 만들 수 있어요.
  • 요약: 이름에서 재료 위치를 찾는 기능을 기대할 수 있지만, 현재 설계된 기능은 재료 이름과 등록일을 보여주는 목록이에요.
  • 제안: 첫 사용자가 이름에서 기대하는 기능을 확인하고, 이름을 유지한다면 첫 화면 설명으로 위치 기능과 목록 기능의 차이를 분명히 해요.
  • 시나리오: 요리 중 재료의 위치를 찾으려고 앱을 연 사용자가 이름과 달리 위치 정보가 없는 목록만 보면 기대와 기능의 차이를 느낄 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

주제 2. 목록의 행동 의미와 누적 사용 경험을 더 분명히 해야 해요

재료를 목록에서 빼는 의미, 등록 순서의 해석, 중복 기록 구분, 목록 누적과 접근성은 서로 다른 설계 결정이지만 모두 핵심 목록을 믿고 쓰는 경험에 영향을 줘요.

  • 먼저 할 일: 목록의 상태 변화와 탐색 규칙을 정리하고 실제 사용 장면에서 이해와 조작이 가능한지 확인해요.
  • 이 주제의 이슈: C2 · C4 · C15 · C16 · C17

C2. [🟡 중간] 화면 접근성 기준이 정해지지 않아 일부 사용자는 핵심 목록을 쓰기 어려울 수 있어요

  • 근본원인: 화면과 키보드의 구성은 있으나 다양한 신체·기기 사용 조건에서 핵심 흐름이 가능한지 확인할 기준이 없어요.
  • 요약: 일부 사용자는 글자 확대나 보조기기, 터치 환경 때문에 첫 재료 입력과 목록 확인에서 어려움을 겪을 수 있어요.
  • 제안: 핵심 입력과 목록 흐름에 적용할 접근성 기준을 정하고, 실제 기기에서 확인할 항목을 설계에 추가해요.
  • 시나리오: 글자를 크게 설정한 사용자가 재료를 입력하고 목록을 다시 확인하려 할 때, 작은 터치 영역이나 보조기기 미지원으로 흐름이 막힐 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

C4. [🟡 중간] 등록 순서가 실제 사용 우선순위처럼 읽힐 수 있어요

  • 근본원인: 등록 순서와 먼저 소비해야 할 재료라는 판단이 화면에서 구분되지 않을 수 있어요.
  • 요약: 첫 항목의 안내가 등록 순서뿐 아니라 소비 우선순위나 신선도 판단을 암시할 가능성이 있어요.
  • 제안: 등록 순서가 소비 우선순위를 뜻하지 않는다는 점을 목록 가까이에서 설명하거나, 안내 문구가 만드는 기대를 화면 시안으로 확인해요.
  • 시나리오: 요리 직전에 목록을 보는 사용자가 맨 위 재료를 가장 먼저 쓰거나 더 빨리 상하는 재료라고 받아들일 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

C15. [🟡 중간] 재료를 목록에서 빼는 행동의 완료 의미가 문서마다 달라요

  • 근본원인: 재료를 목록에서 제거하는 행동의 제품 의미와 완료 상태가 확정되지 않았어요.
  • 요약: 현재 문서에는 실제 소비를 뜻하는 표현과 목록 정리를 뜻하는 표현이 함께 있어 사용자와 구현자가 서로 다른 의미로 이해할 수 있어요.
  • 제안: 사용자가 이 행동으로 무엇을 기록하거나 완료하는지 결정하고, 상태 변화와 화면 문구를 관련 설계 자료에 일관되게 반영해요.
  • 시나리오: 재료를 다른 곳으로 옮기거나 목록만 정리하려는 사용자가 항목을 뺄 때, 그 행동이 실제 소비 기록으로 남는지 알기 어려워요.
  • 묶인 발견: 1건 (§8 참조)

C16. [🟡 중간] 이름이 같은 재료 기록을 구분하기 어려울 수 있어요

  • 근본원인: 중복 기록을 허용하면서 목록에서 각각을 식별할 기준이 충분하지 않아요.
  • 요약: 같은 재료를 여러 번 기록했을 때 등록 시점이나 다른 구분 단서가 부족하면 원하는 항목을 찾기 어려워요.
  • 제안: 등록 시점 등 최소한의 구분 단서를 표시하고, 같은 재료를 연속 입력하는 장면에서 수정·제거가 쉬운지 확인해요.
  • 시나리오: 사용자가 같은 날 같은 재료를 두 번 적은 뒤 한 항목만 수정하려 할 때, 어느 기록을 선택해야 할지 구별하기 어려워요.
  • 묶인 발견: 1건 (§8 참조)

C17. [🟡 중간] 재료 기록이 많이 쌓인 뒤 찾고 정리하는 흐름이 비어 있어요

  • 근본원인: 첫 사용의 단순한 목록은 정의돼 있지만, 간헐적 사용으로 기록이 쌓인 뒤의 탐색과 정리 방식이 빠져 있어요.
  • 요약: 목록이 길어져도 등록 순서 표시만으로 원하는 재료를 찾고 정리할 수 있는지 확인되지 않았어요.
  • 제안: 기록이 누적된 사용자 장면을 추가하고, 검색·정리 등 필요한 목록 동작을 사용량에 맞춰 결정해요.
  • 시나리오: 앱을 한동안 열지 않아 재료 기록이 쌓인 사용자가 요리 전에 특정 재료를 찾으려 하지만, 목록을 효율적으로 탐색하기 어려울 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

주제 3. 핵심 가치가 실제 행동과 결과로 이어지는지 확인할 기준이 필요해요

재방문, 재료 활용, 음식물 폐기 감소는 서로 다른 단계예요. 현재는 각 단계를 구별해 확인할 관찰 기준과 사용자 접촉 경로가 충분히 정리되지 않았어요.

  • 먼저 할 일: 대상 사용자를 만날 경로를 정하고, 재방문부터 실제 활용과 폐기 감소까지 각각 확인할 기준을 마련해요.
  • 이 주제의 이슈: C5 · C9

C5. [🟡 중간] 핵심 가치 가설을 확인할 사용자 검증 기준이 보이지 않아요

  • 근본원인: 핵심 가치를 이루는 재방문 행동과 음식물 폐기 감소 결과를 구별해 판정하는 기준이 없어요.
  • 요약: 사용자가 앱을 다시 열었다는 사실만으로 재료를 활용했거나 폐기를 줄였다고 판단할 수 없어요. 가치의 각 단계를 나눠 확인할 기준이 필요해요.
  • 제안: 재방문, 재료 확인, 실제 활용, 폐기 감소를 서로 다른 신호로 정리하고 각 신호의 관찰 기간과 해석 기준을 설정해요.
  • 시나리오: 사용자가 며칠 동안 앱을 여러 번 열어도 재료를 요리에 쓰지 않고 버린다면, 방문 횟수만으로는 음식물 폐기를 줄였는지 알 수 없어요.
  • 묶인 발견: 2건 (§8 참조)

C9. [🟡 중간] 첫 사용자 검증으로 이어지는 유입 경로가 정리되지 않았어요

  • 근본원인: 대상 사용자와 문제 가설을 실제 관찰로 연결할 모집·접촉 계획이 아직 없어요.
  • 요약: 사용자 문제와 재방문 가설은 있지만, 누구를 어디서 만나 어떤 기간 동안 관찰할지 정해져 있지 않아요.
  • 제안: 첫 사용자 조건에 맞는 모집 경로를 정하고, 첫 사용부터 재방문까지 확인할 기간과 관찰 항목을 간단한 시험 계획으로 정리해요.
  • 시나리오: 혼자 살며 장을 한꺼번에 보는 직장인을 만나지 못하면, 앱을 쓰지 않는 이유가 유입 대상의 문제인지 제품 경험의 문제인지 구분하기 어려워요.
  • 묶인 발견: 1건 (§8 참조)

주제 4. 저장 약속과 데이터 보존·삭제 기준을 맞춰야 해요

저장 위치, 실패 후 복구, 기기 변경 시 보존, 삭제 범위가 아직 정해지지 않아 사용자 안내와 구현 기대가 어긋날 수 있어요.

  • 먼저 할 일: 데이터가 저장되고 복구되며 삭제되는 흐름을 정한 뒤 화면 안내와 구현 기준을 함께 맞춰요.
  • 이 주제의 이슈: C6 · C7 · C13

C6. [🟡 중간] 첫 실행의 저장 안내가 실제 저장 방식과 맞는지 확인되지 않았어요

  • 근본원인: 실제 저장 구조가 정해지기 전에 사용자에게 저장 위치를 약속하는 화면이 계획돼 있어요.
  • 요약: 첫 실행 안내와 저장 방식의 설명이 다를 수 있으며, 사용자가 기록의 위치와 기기 변경 시 보존 여부를 잘못 기대할 수 있어요.
  • 제안: 저장 구조와 기기 변경 시 기록 보존 정책을 먼저 정하고, 실제 동작에 맞게 첫 실행 안내와 관련 문서를 일치시켜요.
  • 시나리오: 처음 앱을 연 사용자가 휴대폰 저장 안내를 믿고 재료를 입력한 뒤 기기를 바꾸면, 안내와 다른 보존 동작 때문에 신뢰를 잃을 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

C7. [🟡 중간] 저장 실패 이후의 보존·복구 기준이 구현에 넘길 만큼 정해지지 않았어요

  • 근본원인: 저장 실패 후 기록이 남는 조건과 복구 동작, 반복 저장의 처리 기준이 미정이에요.
  • 요약: 사용자에게 재시도를 안내하는 흐름은 있지만, 기록이 언제까지 보존되고 실패 후 어떤 상태로 돌아오는지 구현 기준이 부족해요.
  • 제안: 저장 실패와 앱 종료, 재설치, 기기 변경별 데이터 상태를 결정하고 재시도 및 중복 방지 동작을 기술 계약에 기록해요.
  • 시나리오: 재료를 입력한 직후 앱이 종료된 사용자가 다음 실행에서 기록이 남아 있기를 기대하지만, 구현자는 현재 자료만으로 결과를 결정하기 어려워요.
  • 묶인 발견: 1건 (§8 참조)

C13. [🟡 중간] 재료 기록의 저장·삭제와 개인정보 안내 범위가 아직 확인되지 않았어요

  • 근본원인: 데이터 저장·보유·삭제 방식과 이에 대한 사용자 안내가 확인되지 않았어요.
  • 요약: 현재 자료만으로 위반을 단정할 수는 없지만, 사용자가 기록의 위치와 삭제 방법을 알아야 하는 순간에 명확한 안내를 제공하기 어려워요.
  • 제안: 재료 이름과 등록일의 데이터 흐름, 보유·삭제 기준을 확인하고 그에 맞는 사용자 안내 범위를 정리해요.
  • 시나리오: 기기를 바꾸거나 앱을 삭제하려는 사용자가 저장된 재료 기록이 어디에 남고 어떻게 지워지는지 확인하기 어려울 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

주제 5. 구현에 필요한 범위와 검증 근거의 전달이 더 구체적이어야 해요

플랫폼 범위가 열려 있고 선택한 시안과 검증 원문을 직접 확인하기 어려우며, 검증 자료의 날짜도 확인이 필요해요. 각각 별도 결정이지만 모두 후속 작업자가 전제를 확인하는 데 영향을 줘요.

  • 먼저 할 일: 플랫폼·배포 범위를 결정하고 시안·검증 자료의 최신 위치와 유효한 작성 이력을 인계 자료에 남겨요.
  • 이 주제의 이슈: C8 · C14 · C18

C8. [🟡 중간] 시나리오 검증 자료의 작성일이 기준 시점과 맞지 않아요

  • 근본원인: 제공된 기준 시점보다 뒤인 것으로 보이는 날짜가 검증 자료에 있어 자료의 작성 이력과 유효성이 불분명해요.
  • 요약: 날짜가 확인되지 않은 자료를 완료된 검증으로 간주하면 저장이나 기록 누적 문제를 이미 확인했다고 과대평가할 수 있어요.
  • 제안: 검증 자료의 날짜와 출처를 대조하고, 실제 확인 범위가 드러나도록 작성 이력과 문서 내용을 바로잡아요.
  • 시나리오: 팀이 날짜가 확인되지 않은 검증 자료를 완료된 시험으로 믿고 저장 방식이나 기록 누적 문제를 이미 확인했다고 판단할 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

C14. [🟡 중간] 구현 대상 모바일 플랫폼과 배포 범위가 정해지지 않았어요

  • 근본원인: 모바일 앱이라는 방향은 있으나 플랫폼과 배포 범위가 구현 전제에 연결되지 않았어요.
  • 요약: 플랫폼에 따라 입력 방식과 기기 확인 범위가 달라질 수 있어 개발자가 임의로 전제를 선택할 위험이 있어요.
  • 제안: 첫 출시에서 지원할 플랫폼과 배포 범위를 결정하거나, 미결정 상태와 결정 시점을 개발 인계 자료에 명확히 남겨요.
  • 시나리오: 개발자가 화면과 키보드 동작을 구현하려는 순간, iOS와 Android 중 무엇을 기준으로 삼을지 정해져 있지 않으면 구현과 기기 확인 범위가 달라져요.
  • 묶인 발견: 1건 (§8 참조)

C18. [🟢 낮음] 참조된 시안과 검증 자료를 패키지에서 직접 확인하기 어려워요

  • 근본원인: 화면 선택과 검증 결과의 요약은 있지만 이를 직접 확인할 자료가 전달 패키지에 포함되지 않았어요.
  • 요약: 후속 작업자가 선택의 세부 맥락과 검증 근거를 직접 확인하기 어려워, 설계 의도를 다른 작업 공간으로 옮길 때 근거가 약해질 수 있어요.
  • 제안: 선택된 시안과 검증 자료의 현재 버전을 인계 자료에 포함하거나 접근 가능한 경로와 버전을 명시해요.
  • 시나리오: 새 작업자가 선택된 화면안과 시험 결과를 확인하려 하지만 자료 원문이 전달되지 않아 결정의 세부 맥락을 대조하기 어려워요.
  • 묶인 발견: 1건 (§8 참조)

주제 6. 유료화 판단은 핵심 가치 확인 뒤 기준을 정해야 해요

유료 알림 검토는 반복 사용과 지불 의향이 확인된 뒤의 결정이에요. 현재는 어떤 결과가 다음 단계로 이어지는지 기준이 비어 있어요.

  • 먼저 할 일: 핵심 가치와 반복 사용을 확인한 뒤 유료 알림의 검토 기준과 결과별 선택을 정해요.
  • 이 주제의 이슈: C11

C11. [🟡 중간] 유료 알림을 검토할 때의 판정 기준이 비어 있어요

  • 근본원인: 반복 사용과 지불 의향이 확인된 뒤 유료 알림을 검토한다는 방향은 있으나, 검토를 시작할 판정 기준이 없어요.
  • 요약: 가격을 지금 정할 필요는 없지만, 어떤 검증 결과가 다음 수익 모델 결정을 뒷받침하는지는 미정이에요.
  • 제안: 핵심 사용자 가치와 반복 사용을 먼저 확인한 뒤, 유료 알림을 검토할 행동·지불 의향 기준과 결과별 다음 결정을 정해요.
  • 시나리오: 앱을 여러 번 연 1인 가구 사용자가 유료 알림을 시험할지 판단해야 하는 시점에, 팀원마다 성공 기준을 다르게 해석할 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

주제 7. 반복 오류를 서비스 복구로 잇는 운영 책임이 필요해요

사용자에게 재시도를 안내하는 흐름은 있으나, 반복되는 실패를 감지하고 해결하는 운영 경로는 확인되지 않았어요.

  • 먼저 할 일: 오류 감지부터 원인 확인, 복구, 사용자 안내까지 책임과 절차를 정해요.
  • 이 주제의 이슈: C12

C12. [🟡 중간] 사용자 오류 재시도 뒤의 운영 대응 흐름이 보이지 않아요

  • 근본원인: 사용자에게 재시도 방법은 있지만 반복되는 실패를 운영자가 감지하고 해결하는 경로가 확인되지 않았어요.
  • 요약: 서비스 장애가 반복돼도 운영 대응이 이어지지 않으면 사용자는 재시도만 반복하고 기록과 앱을 신뢰하기 어려워져요.
  • 제안: 목록 불러오기 실패를 감지할 신호, 원인 확인 책임, 복구 절차와 사용자 안내 기준을 정리해요.
  • 시나리오: 아침 시간에 여러 사용자의 목록 로딩이 실패해도 운영자가 이를 알아차리지 못하면 사용자에게 재시도만 남고 복구가 늦어질 수 있어요.
  • 묶인 발견: 1건 (§8 참조)

§7. 해소 경로

이슈를 '기반을 잡으면 함께 풀리는 것'과 '따로 처리할 것'으로 나눴어요. 기반부터 잡는 게 효율적이에요.

  • 기반 연결 (4건): 대상 사용자의 문제와 경쟁 구간을 좁히면 첫 사용자 모집과 제품 이름이 전달할 약속도 함께 구체화돼요. 이 항목들이 자동으로 해소되는 것은 아니지만, 기반 결정 뒤에는 확인해야 할 사용자와 비교 대상의 범위가 줄어들어요.
  • 별도 처리 (15건): 저장·복구·개인정보·목록 동작·접근성·운영·문서 전달에는 각기 다른 결정과 완료 기준이 있어요. 제품 기반을 정한 뒤에도 기술, 디자인, 운영, 문서 책임자가 별도로 닫아야 해요. 가치 측정과 유료화 판단도 독립적인 기준을 정해야 해요.

§8. 발견 전수 (19건)

점검에서 나온 발견 전체예요. §6 핵심 이슈의 근거가 되는 상세 목록이라, 필요할 때 펼쳐 보면 돼요.

[1] 경쟁 우위와 사용자 여정의 기준이 아직 정리되지 않았어요

🔴 높음 · 관점: Value Chain 경쟁 정합 · 핵심이슈 C1

  • 핵심: 경쟁 구간과 대체 행동의 연결 부재
  • 근거: 대안 서비스의 기능은 열거돼 있지만 사용자가 재료를 기억하고 확인하고 소비하는 전체 여정에서 각 대안이 어디를 해결하는지, 이 제품이 어느 구간을 맡는지는 제시되지 않았어요. 직접 경쟁 우위도 검증되지 않았다고 명시돼 있어요. 예를 들어 장을 본 뒤 냉장고 안쪽 재료를 잊은 사용자는 현재 쓰는 앱이나 메모와 비교해 이 앱을 선택할 이유를 아직 알기 어려워요. 이는 첫 버전을 더 만들기 전에 제품이 경쟁할 구간과 약속을 정리해야 하는 기반 공백이에요.
  • 제안: 사용자가 재료를 구매한 뒤 보관하고, 요리할 때 확인하고, 사용하거나 버리는 여정을 단계별로 그려요. 각 단계에서 경쟁 서비스·직접 기록·아무것도 하지 않기를 매핑하고, 제품이 맡을 구간과 그 구간에서 이길 근거를 따로 정리해요.
  • 소스: 가치사슬/경쟁
  • 시나리오: (혼자 사는 직장인 사용자) 장을 본 뒤 요리 전에 냉장고 안쪽 재료를 확인하려 해요.
    • 기대: 현재 쓰는 메모나 앱과 비교해 이 목록 앱을 선택할 이유를 빠르게 이해해요. / 실제: 대안이 해결하는 여정과 이 앱이 맡는 구간이 정리돼 있지 않아요.
    • 파단점: 사용자가 기존 대안 대신 이 앱을 선택할 차이를 알기 어려워요.
  • 되짚어볼 점: "재료를 기억하고 확인하는 과정에서 사용자가 현재 가장 자주 쓰는 대안은 무엇이며, 이 앱이 더 나은 구간은 어디인가요?"

[2] 첫 실행의 저장 안내가 실제 저장 방식과 맞는지 확인되지 않았어요

🟡 중간 · 관점: 교차 문서 모순 · 핵심이슈 C6

  • 핵심: 저장 약속보다 실제 저장 설계가 미확정
  • 근거: UX 설계에는 첫 실행 때 ‘휴대폰에만 저장’ 안내를 보여준다고 적혀 있지만, 와이어프레임과 디자인 시스템은 실제 저장 방식이 확인된 뒤에만 안내하라고 해요. 실제 저장 구조도 미정이에요. 예를 들어 처음 앱을 연 사용자가 저장 안내를 읽고 재료를 입력할 때, 실제 저장 위치와 기기 변경 시 보존 여부가 다르면 약속을 신뢰하기 어려워져요. 문서 간 안내 문구를 임의로 선택하기보다 저장 방식의 결정과 사용자 안내를 함께 맞출 필요가 있어요.
  • 제안: 저장 위치, 계정 없이 사용할 때의 보존 범위, 기기 변경·앱 삭제 시 동작을 먼저 정리해요. 결정된 동작에 맞춰 UX·와이어프레임·디자인 시스템의 첫 실행 안내를 같은 기준으로 갱신해요.
  • 소스: 저장·복구/사용자 안내
  • 시나리오: (처음 앱을 설치한 1인 가구 사용자) 첫 실행 안내를 읽고 냉장고 재료를 입력해요.
    • 기대: 저장 안내가 실제 저장 위치와 기기 변경 시 동작을 정확히 알려줘요. / 실제: 첫 실행 문구와 다른 설계 자료의 조건이 다르고 실제 저장 구조는 미정이에요.
    • 파단점: 사용자는 기록이 어디에 남는지와 기기 변경 후에도 보이는지 잘못 기대할 수 있어요.
  • 되짚어볼 점: "첫 실행에서 안내할 저장 위치와 기기를 바꿨을 때의 기록 보존 동작은 무엇으로 확정돼 있나요?"

[3] 재료를 목록에서 빼는 행동의 완료 의미가 문서마다 달라요

🟡 중간 · 관점: 교차 문서 모순 · 핵심이슈 C15

  • 핵심: 소비 완료와 목록 정리 의미 불일치
  • 근거: 설계문서 §3.1은 ‘다 쓴 재료’에서 ‘다 썼어요’를 눌러 목록에서 뺀다고 설명하지만, UX와 와이어프레임은 재료 상태를 사용자가 직접 판단한 뒤 ‘목록에서 빼기’를 누른다고 설명해요. 입력 자료도 이 의미가 아직 확정되지 않았다고 밝혀요. 예를 들어 재료를 다른 곳으로 옮기거나 기록만 정리하려는 사용자는 이 행동이 실제 소비를 뜻하는지 목록에서 숨기는 것인지 알기 어려워요. 현재 결정 미완료를 유지하면서 관련 문서의 표현과 기능 의미를 함께 정리해야 해요.
  • 제안: 행동이 의미하는 상태 변화를 먼저 결정해요. 실제로 사용한 기록인지, 목록에서만 제외하는지, 둘 다 필요한지 정한 뒤 설계문서·UX·와이어프레임의 동작 이름과 되돌리기 설명을 일치시켜요.
  • 소스: 기능 의미/사용 흐름
  • 시나리오: (재료를 옮기며 목록을 정리하는 사용자) 아직 먹지 않은 재료를 다른 보관 장소로 옮기고 목록에서 빼려 해요.
    • 기대: 목록에서 빼는 행동이 무엇을 기록하는지 사용자가 알고 선택해요. / 실제: 일부 자료는 다 쓴 것으로, 다른 자료는 사용자가 상태를 판단해 목록에서 빼는 것으로 설명해요.
    • 파단점: 사용자가 목록 정리를 실제 소비 기록으로 오해할 수 있어요.
  • 되짚어볼 점: "사용자가 재료를 목록에서 뺄 때 실제로 다 쓴 것으로 기록되나요, 아니면 화면에서만 정리되나요?"

[4] 저장 실패 이후의 보존·복구 기준이 구현에 넘길 만큼 정해지지 않았어요

🟡 중간 · 관점: 핸드오프 수신 · 핵심이슈 C7

  • 핵심: 실패 시 데이터 보존과 재시도 규칙 미완결
  • 근거: 입력 자료는 저장 중 앱 종료, 재설치·기기 변경·앱 데이터 삭제 뒤의 보존과 복구, 반복 저장의 중복 방지를 미정으로 남겨요. 저장 실패 시 입력을 보존하고 재시도한다는 UX 동작은 있지만, 기록이 언제까지 남고 실패 후 어떤 상태로 복구되는지는 별도 기준이 없어요. 예를 들어 재료를 적은 직후 앱이 종료된 사용자는 다음 실행에서 그 항목이 남아 있을 것으로 기대할 수 있지만, 구현자는 현재 자료만으로 기대 동작을 확정하기 어려워요.
  • 제안: 기록의 저장 완료 시점, 재시도 중복 처리, 앱 종료·재설치·기기 변경·데이터 삭제 시 동작을 간단한 상태별 기준으로 정리해요. 그 기준을 저장 실패 안내와 구현 인계 자료에 연결해요.
  • 소스: 구현/기술 계약
  • 시나리오: (재료를 막 기록한 모바일 사용자) 저장 중 앱이 닫힌 뒤 다시 앱을 열어요.
    • 기대: 입력한 기록의 보존 여부와 다시 저장할 때의 동작을 예측할 수 있어요. / 실제: 실패 후 재시도 안내는 있지만 보존·복구와 중복 방지 기준이 정해지지 않았어요.
    • 파단점: 사용자와 개발자가 실패 후 기록 상태를 서로 다르게 예상할 수 있어요.
  • 되짚어볼 점: "저장 직후 앱이 종료되거나 같은 입력을 다시 저장하면 기록은 어떻게 남고 중복은 어떻게 막나요?"

[5] 핵심 가치 가설을 확인할 사용자 검증 기준이 보이지 않아요

🟡 중간 · 관점: 품질 퇴화 · 핵심이슈 C5

  • 핵심: 재방문과 폐기 감소의 신호 혼동
  • 근거: 자료는 재방문과 재료 활용, 음식물 폐기 감소를 검증되지 않은 가설로 구분하고, 시나리오 검증도 실제 사용자 시험이 아니라고 밝혀요. 하지만 어떤 관찰 결과가 재방문이나 가치 전달의 신호인지, 어느 시점에 판단할지는 제시되지 않았어요. 예를 들어 사용자가 며칠 뒤 앱을 다시 열더라도 재료를 확인하거나 요리에 활용했는지 알 수 없다면, 핵심 가치가 작동했는지 판단하기 어려워요.
  • 제안: 실제 사용자 시험에서 확인할 행동을 좁혀요. 재방문, 먼저 표시된 재료 확인, 실제 사용 여부를 구분하고, 각 신호를 어떤 기간과 관찰 방법으로 해석할지 정리해요.
  • 소스: 가치 검증/측정
  • 시나리오: (앱을 며칠째 다시 사용하는 1인 가구 사용자) 앱을 여러 번 열어 재료 목록을 확인하지만 아직 요리에 쓰지는 않아요.
    • 기대: 팀이 재방문과 실제 활용을 서로 다른 가치 신호로 해석해요. / 실제: 각 신호의 관찰 기준과 판단 시점이 정해져 있지 않아요.
    • 파단점: 방문 횟수만으로 음식물 폐기가 줄었다고 오해할 수 있어요.
  • 되짚어볼 점: "사용자가 다시 방문한 것과 재료를 실제로 활용해 버리지 않은 것을 각각 어떤 기준으로 확인하나요?"

[6] 첫 사용자의 문제가 다른 사람에게도 흔한지 아직 확인되지 않았어요

🟡 중간 · 관점: 유저 유형 · 핵심이슈 C3

  • 핵심: 첫 사용자 문제의 집단 대표성 미확인
  • 근거: 문서는 혼자 사는 사람을 첫 사용자로 두고, 28세 직장인 사례를 만드는 사람의 실제 경험에서 가져왔다고 설명해요. 동시에 다른 사람에게 같은 문제가 흔한지는 인터뷰로 확인되지 않았고, 기록을 중단한 이유와 빈도도 미확인이라고 밝혀요. 따라서 현재 사용자상은 유용한 출발점이지만, 사용자 집단 전체의 문제로 일반화할 근거는 아직 부족해요. 예를 들어 냉장고 재료를 자주 잊는다고 가정한 사용자가 첫 기록을 시작하려 할 때, 실제로는 기록 자체보다 다른 이유로 앱을 지속하지 않을 수 있어요.
  • 제안: 첫 사용자 가정과 확인된 사실을 분리해 정리하고, 대상 사용자 몇 명에게 잊는 상황·기록을 그만두는 이유·발생 빈도를 확인해요. 확인 결과에 따라 첫 사용자 범위와 문제 설명을 좁히거나 조정해요.
  • 소스: 페르소나/사용자 문제
  • 시나리오: (혼자 사는 28세 직장인 사용자) 장을 보고 앱에 첫 재료를 적을지 결정해요.
    • 기대: 실제 문제 빈도와 기록을 지속할 이유가 사용자 근거로 뒷받침돼요. / 실제: 대표 사례는 있으나 다른 사람에게도 흔한지와 중단 이유는 확인되지 않았어요.
    • 파단점: 대표 사례 하나를 전체 사용자에게 해당하는 문제로 넓힐 수 있어요.
  • 되짚어볼 점: "첫 사용자로 둔 사람들 중 재료를 자주 잊는 경험은 얼마나 흔하고, 기록을 중단한 이유는 무엇인가요?"

[7] 유료 알림을 검토할 때의 판정 기준이 비어 있어요

🟡 중간 · 관점: 표면 단계화 전략 · 핵심이슈 C11

  • 핵심: 유료 알림 검토 시점의 판정선 부재
  • 근거: 설계는 반복 사용과 지불 의향이 확인된 뒤 알림 구독을 검토한다고 설명하지만, 무엇을 확인하면 다음 단계로 넘어갈지와 결과를 어떻게 해석할지는 정하지 않았어요. 앱을 여러 번 연 1인 가구 사용자가 알림을 유료로 시험해도 되는지 판단하는 시점에, 팀이 서로 다른 기준으로 성공을 해석할 수 있어요. 가격을 지금 정해야 한다는 뜻은 아니며, 검증을 마친 뒤의 결정 기준이 아직 문서에 없다는 점이 핵심이에요.
  • 제안: 가격을 확정하기 전에 반복 사용과 지불 의향을 각각 어떤 관찰이나 사용자 응답으로 확인할지, 확인 결과에 따라 구독 검토를 진행·보류하는 기준을 정리해요. 실제 사용자 자료가 생기기 전에는 기준을 가설로 표시하고, 수치나 효과를 확인된 사실처럼 다루지 않아요.
  • 소스: 수익/비즈니스
  • 시나리오: (앱을 여러 번 사용한 1인 가구 사용자) 팀이 알림을 유료 기능으로 시험할지 논의해요.
    • 기대: 사전에 합의한 사용자 행동과 지불 의향 기준으로 다음 단계가 결정돼요. / 실제: 반복 사용과 지불 의향을 확인한 뒤 검토한다는 방향만 있고 판정 기준은 없어요.
    • 파단점: 팀원마다 같은 결과를 성공 또는 실패로 다르게 해석할 수 있어요.
  • 되짚어볼 점: "반복 사용과 지불 의향 중 무엇을 어느 정도 확인하면 유료 알림 검토로 넘어가나요?"

[8] 등록 순서가 실제 사용 우선순위처럼 읽힐 수 있어요

🟡 중간 · 관점: 일반 · 핵심이슈 C4

  • 핵심: 등록 순서가 소비 우선순위로 오해될 가능성
  • 근거: 요리 직전에 목록을 확인한 사용자는 맨 위의 재료가 가장 먼저 써야 하거나 더 빨리 상하는 재료라고 받아들일 수 있어요. 설계는 등록일과 순서를 참고 정보로 설명하지만, 첫 항목에만 ‘먼저 확인해보세요’를 붙여 행동 우선순위를 함께 암시해요. 표시는 등록 순서에 따른다는 점을 목록 가까이에서 설명하거나 문구가 전달하는 의미를 시안에서 확인하면 제품의 생활 도움이라는 가치와 안전한 해석이 더 잘 맞아요.
  • 제안: 첫 항목 표시를 등록 순서 기준의 안내로 명확히 표현하고, 여러 재료 중 실제로 먼저 쓸 재료를 사용자가 판단하는 흐름과 혼동되지 않는지 화면 시안에서 확인해요.
  • 소스: UX 경로/목록 안내
  • 시나리오: (저녁 요리를 준비하는 혼자 사는 사용자) 앱을 열고 맨 위에 표시된 재료를 확인해요.
    • 기대: 등록 순서와 소비 우선순위의 차이를 혼동하지 않아요. / 실제: 첫 항목에 먼저 확인하라는 문구가 있어 우선순위를 암시할 수 있어요.
    • 파단점: 사용자가 등록일만으로 신선도나 소비 순서를 판단할 수 있어요.
  • 되짚어볼 점: "목록의 첫 재료가 먼저 써야 하는 재료라고 사용자가 이해하지 않도록 어떤 안내가 있나요?"

[9] 이름이 같은 재료 기록을 구분하기 어려울 수 있어요

🟡 중간 · 관점: 엣지 · 핵심이슈 C16

  • 핵심: 동일 재료 기록의 구별 단서 부족
  • 근거: 같은 이름의 기록을 별도 항목으로 허용하지만, 사용자가 목록에서 각 기록을 구분하는 기준은 명확하지 않아요. 같은 날 같은 재료를 두 번 적은 상황에서는 어느 항목을 수정하거나 목록에서 뺄지 구별하기 어려울 수 있어요. 기존 입력 단순성을 유지하면서 등록 시점 표시나 중복 확인 등 구분 방식을 정하면 핵심 목록을 관리하기 쉬워져요.
  • 제안: 같은 이름을 여러 번 등록하는 경우의 구분 기준을 정하고, 등록 시점 표시나 중복 입력 확인 중 첫 버전의 단순함과 맞는 방식을 화면에 반영해요.
  • 소스: UX 경로/목록 관리
  • 시나리오: (같은 재료를 두 번 입력한 모바일 사용자) 한 기록만 수정하거나 목록에서 빼려 해요.
    • 기대: 각 기록의 등록 시점 등 구별 단서를 보고 대상을 고를 수 있어요. / 실제: 중복 기록은 허용하지만 항목을 구별할 기준이 분명하지 않아요.
    • 파단점: 사용자가 의도하지 않은 기록을 수정하거나 제거할 수 있어요.
  • 되짚어볼 점: "같은 이름의 재료를 두 번 기록했을 때 사용자는 어느 항목을 수정하거나 뺄지 어떻게 알아보나요?"

[10] 재료 기록이 많이 쌓인 뒤 찾고 정리하는 흐름이 비어 있어요

🟡 중간 · 관점: 아웃라이어 · 핵심이슈 C17

  • 핵심: 누적 목록에서 찾기와 정리의 확장성 부족
  • 근거: 사용자가 앱을 간헐적으로 열거나 오랫동안 재료를 정리하지 않으면 기록이 많이 쌓일 수 있어요. 현재 목록은 등록 순서 표시를 중심으로 설명되며, 긴 목록에서 원하는 재료를 찾거나 여러 항목을 효율적으로 정리하는 방식은 제시되지 않았어요. 목록이 핵심 화면인 만큼 기록이 늘어난 뒤의 사용 장면을 확인하면 단순한 첫 버전 경험이 누적 사용으로 이어지는지 판단할 수 있어요.
  • 제안: 기록이 많이 쌓인 목록을 포함한 모바일 시안을 확인하고, 원하는 항목을 찾고 오래된 기록을 정리하는 데 필요한 최소한의 표시와 동작을 정해요.
  • 소스: UX 경로/목록 누적
  • 시나리오: (몇 주 동안 앱을 간헐적으로 사용한 1인 가구 사용자) 요리 직전에 오래된 기록이 섞인 목록에서 특정 재료를 찾아요.
    • 기대: 목록이 길어도 원하는 재료를 찾고 필요 없는 항목을 정리해요. / 실제: 등록 순서 표시는 있으나 긴 목록의 탐색·정리 방식은 제시되지 않았어요.
    • 파단점: 기록이 늘수록 핵심 재료를 찾는 데 드는 노력이 커질 수 있어요.
  • 되짚어볼 점: "기록이 많이 쌓인 사용자가 원하는 재료를 찾고 여러 항목을 정리하는 방법은 무엇인가요?"

[11] 화면 접근성 기준이 정해지지 않아 일부 사용자는 핵심 목록을 쓰기 어려울 수 있어요

🟡 중간 · 관점: 유저 유형 · 핵심이슈 C2

  • 핵심: 접근성 기준 부재로 첫 가치가 차단됨
  • 근거: 글자를 크게 설정해 쓰거나 터치가 불편한 사용자가 첫 재료를 적고 다시 확인하려는 순간을 생각해볼 수 있어요. 패키지는 화면 구성과 키보드 배치를 설명하지만, 글자 확대·보조기기 사용·최소 터치 영역 기준은 제시하지 않고 실제 기기 확인도 남겨두고 있어요. 이 기준이 없으면 제품의 첫 가치 경험이 일부 사용자에게 막힐 수 있으므로 접근성 확인 범위를 정리하는 편이 좋아요.
  • 제안: 글자 확대와 보조기기 사용 시 목록·입력·수정·되돌리기 흐름을 확인하고, 터치 영역과 읽기 순서의 기준을 화면별로 기록해요.
  • 소스: UX 경로/접근성
  • 시나리오: (글자 확대 기능을 사용하는 시력이 낮은 사용자) 화면 글자를 키운 상태로 첫 재료를 입력해요.
    • 기대: 입력과 목록 확인을 확대 화면과 보조기기에서도 진행할 수 있어요. / 실제: 화면 구성은 있으나 확대·보조기기·터치 영역 기준과 기기 확인이 남아 있어요.
    • 파단점: 핵심 입력이나 목록 조작을 완료하지 못할 수 있어요.
  • 되짚어볼 점: "글자 확대와 보조기기, 작은 터치 영역 때문에 첫 재료 입력이나 목록 확인이 막히지 않는지 무엇으로 확인하나요?"

[12] 재료 기록의 저장·삭제와 개인정보 안내 범위가 아직 확인되지 않았어요

🟡 중간 · 관점: 법적 · 핵심이슈 C13

  • 핵심: 저장 위치와 삭제 범위 안내 불투명
  • 근거: 사용자가 식재료 이름을 입력하고 앱이 이름과 등록한 날을 저장한다고 설명돼 있지만, 실제 저장 위치와 보유·삭제 방식은 정해지지 않았어요. 요리 전에 기록을 남기는 사용자가 기기 변경이나 앱 삭제를 고민하는 순간, 어떤 정보가 어디에 남고 어떻게 지워지는지 알기 어려울 수 있어요. 현재 자료만으로 법적 위반을 단정할 수는 없지만, 출시 전 데이터 흐름과 사용자 안내를 함께 확정할 필요가 있어요.
  • 제안: 저장 위치가 정해진 뒤 수집 항목, 보유 기간, 삭제 방법, 백업 여부를 확인하고 첫 실행 안내와 개인정보 문서에 같은 내용을 반영해요.
  • 소스: 운영/법무/신뢰
  • 시나리오: (휴대폰을 바꾸려는 재료 기록 사용자) 앱에 저장된 재료 이름과 등록일의 보유 여부를 확인해요.
    • 기대: 저장 위치와 보유·삭제 범위를 이해하고 기록을 관리해요. / 실제: 저장 위치와 보유·삭제 방식이 확정되거나 안내된 자료가 확인되지 않아요.
    • 파단점: 사용자는 기록이 기기나 앱 삭제 뒤에도 남는지 판단하기 어려워요.
  • 되짚어볼 점: "사용자가 기기를 바꾸거나 앱을 삭제하려 할 때 저장된 재료 기록을 어디서 어떻게 삭제할 수 있나요?"

[13] 참조된 시안과 검증 자료를 패키지에서 직접 확인하기 어려워요

🟢 낮음 · 관점: 문서 생태계 · 핵심이슈 C18

  • 핵심: 화면 선택과 시험 근거 원문이 누락됨
  • 근거: 다음 작업자가 선택된 화면안과 시나리오 검증 결과를 바탕으로 구현을 시작하는 상황을 생각해볼 수 있어요. 패키지는 HTML 시안에서 안 A를 골랐다는 기록과 별도 검증 리포트의 요약을 제공하지만, 해당 자료 자체는 포함하지 않아 화면 선택의 세부 맥락과 검증 근거를 직접 대조할 수 없어요. 이로 인해 후속 문서나 작업 공간으로 옮길 때 선택의 근거가 약해질 수 있으므로 현재 버전의 참조 자료를 함께 전달하는 편이 좋아요.
  • 제안: 선택된 화면안과 시나리오 검증 리포트를 패키지에 포함하거나, 접근 가능한 위치·버전·핵심 결론을 기록해 다음 작업자가 같은 근거를 확인할 수 있게 해요.
  • 소스: 핸드오프/참조 자료
  • 시나리오: (화면 구현을 넘겨받은 새 디자이너) 선택된 화면안과 검증 결과를 비교해 구현 방향을 파악해요.
    • 기대: 현재 선택된 시안과 검증 근거를 직접 열어 선택 이유를 확인해요. / 실제: 패키지에는 선택과 요약이 있으나 자료 원문은 포함되지 않았어요.
    • 파단점: 선택의 세부 맥락과 근거를 다음 작업자가 대조하기 어려워요.
  • 되짚어볼 점: "다음 작업자가 선택된 화면안과 시나리오 검증 자료의 원문을 직접 열어 확인할 수 있나요?"

[14] 사용자 오류 재시도 뒤의 운영 대응 흐름이 보이지 않아요

🟡 중간 · 관점: 운영 · 핵심이슈 C12

  • 핵심: 복구 절차 없는 반복 오류 안내
  • 근거: 목록을 불러오지 못하면 사용자에게 오류와 재시도를 보여주는 흐름은 마련돼 있어요. 하지만 여러 사용자가 같은 문제를 겪을 때 운영자가 장애를 알아차리고 원인을 확인하거나 대응하는 방법은 패키지에서 확인되지 않아요. 예를 들어 출시 뒤 아침 시간에 목록 로딩 실패가 반복되면, 사용자에게 재시도만 남고 문제가 해결될 때까지의 운영 대응은 불분명해요. 오류 안내와 실제 서비스 복구 사이가 끊기면 사용자가 기록을 믿고 다시 방문하기 어려워져요.
  • 제안: 실서비스 제공 범위에 맞춰 운영 담당자, 오류 접수·알림 경로, 장애 확인과 사용자 안내 기준을 정리해요. 기존 목록 중심 흐름과 오류 재시도 동작을 유지하면서 운영 절차를 보완해요.
  • 소스: 운영/오류 대응
  • 시나리오: (아침 시간에 앱 목록을 확인하려는 여러 사용자) 동시에 목록 불러오기에 실패해 재시도를 반복해요.
    • 기대: 운영자가 반복 오류를 알아차리고 원인을 확인해 복구해요. / 실제: 사용자 오류 안내와 재시도는 있지만 운영 감지와 대응 흐름은 확인되지 않아요.
    • 파단점: 사용자에게 재시도만 남고 서비스 복구가 지연될 수 있어요.
  • 되짚어볼 점: "여러 사용자에게 같은 목록 불러오기 오류가 반복되면 운영자는 어디서 이를 알아차리고 어떻게 해결하나요?"

[15] 앱 재방문과 음식물 폐기 감소를 구분해 확인할 기준이 없어요

🟢 낮음 · 관점: 선행·후행 지표 구분 · 핵심이슈 C5

  • 핵심: 재방문 지표가 음식물 절감 결과를 대신함
  • 근거: 문서는 나중에 앱을 열어 재료를 다시 알아차리는 순간을 가치 가설로 제시하면서도, 재방문과 활용 여부는 검증되지 않았다고 밝혀요. 예를 들어 사용자가 앱을 여러 번 열어도 재료를 쓰지 않고 결국 버린다면, 재방문만으로는 음식물 폐기를 줄였다고 판단할 수 없어요. 행동 신호와 최종 결과를 분리하지 않으면 사용이 늘었다는 사실이 핵심 가치가 달성됐다는 결론으로 잘못 이어질 수 있어요.
  • 제안: 먼저 재료를 다시 확인하거나 실제로 활용하는 행동 신호와, 버린 재료가 줄었는지 보는 결과 신호를 별도로 정의해요. 각 신호의 확인 방법과 성공으로 판단할 기준을 정하고, 행동 신호만 좋아졌을 때는 음식물 폐기 감소가 입증된 것으로 해석하지 않도록 해요.
  • 소스: 가치 검증/측정
  • 시나리오: (앱을 여러 차례 열었지만 재료를 버린 사용자) 사용자는 목록을 자주 확인했으나 해당 재료를 요리에 쓰지 못했어요.
    • 기대: 재방문 행동과 실제 재료 활용·폐기 감소를 분리해 해석해요. / 실제: 재방문과 최종 결과를 구분할 판정 기준이 제시되지 않았어요.
    • 파단점: 사용 횟수가 늘었다는 이유만으로 핵심 가치 달성을 선언할 수 있어요.
  • 되짚어볼 점: "앱 재방문이 늘었지만 재료 활용이나 폐기 감소가 늘지 않았을 때 성공을 어떻게 판정하나요?"

[16] 첫 사용자 검증으로 이어지는 유입 경로가 정리되지 않았어요

🟡 중간 · 관점: GTM-검증 정합 · 핵심이슈 C9

  • 핵심: 검증 대상에게 닿는 모집 경로 부재
  • 근거: 첫 사용자의 문제와 재방문 가설은 문서에 담겨 있지만, 그 사용자를 어디서 어떻게 만나 첫 사용과 재방문을 확인할지는 제시되지 않았어요. 예를 들어 혼자 살며 장을 한꺼번에 보는 직장인을 만날 경로와 관찰할 사용 기간이 없으면, 앱을 열지 않은 이유가 유입 대상의 차이인지 제품 경험의 문제인지 구분하기 어려워져요. 이는 제품의 첫 가치가 잘못됐다는 증거는 아니지만, 그 가치를 확인할 기회가 생기는지 판단하기 어렵게 해요.
  • 제안: 첫 사용자로 가정한 사람을 실제로 만날 수 있는 모집 경로를 정하고, 첫 재료 기록부터 며칠 뒤 재방문까지 확인할 소규모 검증 계획을 문서화해요. 유입 경로와 관찰 결과를 구분해 기록하면 제품 가치 가설을 더 정확히 살펴볼 수 있어요.
  • 소스: 시장 검증 경로
  • 시나리오: (혼자 살며 한꺼번에 장을 보는 직장인 사용자) 제품을 처음 써보고 며칠 뒤 다시 사용할 기회를 기다려요.
    • 기대: 팀이 대상 사용자를 모집하고 첫 사용과 재방문을 정한 기간 동안 관찰해요. / 실제: 접촉 경로와 사용 관찰 기간이 제시되지 않았어요.
    • 파단점: 유입되지 않은 문제와 제품을 경험한 뒤 돌아오지 않은 문제를 구별하기 어려워요.
  • 되짚어볼 점: "첫 사용자 조건에 맞는 사람을 어디서 모집하고, 첫 사용 뒤 얼마 동안 어떤 행동을 확인할 계획인가요?"

[17] 시나리오 검증 자료의 작성일이 기준 시점과 맞지 않아요

🟡 중간 · 관점: 시간적 유효성 · 핵심이슈 C8

  • 핵심: 검증 자료 날짜와 기준 시점이 불일치
  • 근거: 설계 패키지는 시나리오 검증 리포트를 2026-10-06 작성이라고 설명하지만, 제공된 엔진 기준 문서의 갱신일은 2026-08-23이에요. 따라서 현재 기준에서 해당 리포트가 이미 작성·검토된 자료인지, 날짜 오기인지 확인되지 않으며, 문서 기반 검증이 완료됐다는 근거로 그대로 사용하면 검증 수준을 실제보다 높게 판단할 수 있어요. 예를 들어 팀이 이 리포트를 완료된 점검으로 보고 저장 방식이나 기록 누적 문제를 이미 확인했다고 여길 수 있어요.
  • 제안: 원본 검증 리포트와 작성 이력을 확인해 날짜를 바로잡고, 실제 수행 여부와 검토 범위를 함께 기록해요. 확인 전에는 해당 자료를 완료된 검증 근거가 아니라 미확인 문서상 주장으로 다뤄요.
  • 소스: 검증 근거/문서 시점
  • 시나리오: (검증 자료를 기준으로 구현을 시작하는 개발자) 팀이 문서상 완료된 시나리오 검증을 믿고 저장 동작을 설계해요.
    • 기대: 검증 자료의 작성 시점과 실제 확인 범위를 먼저 확인해요. / 실제: 자료에 적힌 날짜가 제공된 기준 시점보다 뒤여서 작성 이력이 불분명해요.
    • 파단점: 실제로 확인되지 않은 내용을 완료된 검증으로 간주할 수 있어요.
  • 되짚어볼 점: "검증 자료의 작성일은 실제 작성 이력과 일치하나요, 아니면 날짜 오기인가요?"

[18] 제품 이름이 실제 목록보다 공간 지도 기능을 기대하게 할 수 있어요

🟡 중간 · 관점: 인지 · 핵심이슈 C10

  • 핵심: 제품 이름이 제공 기능보다 넓은 기대 생성
  • 근거: ‘냉장고 지도’라는 이름은 냉장고 안에서 재료의 위치를 찾는 기능을 떠올리게 할 수 있지만, 설계된 첫 버전은 재료 이름과 등록일을 보여주는 목록이에요. 예를 들어 요리 중 재료 위치를 찾으려는 사용자는 앱을 열어도 위치 정보가 없다는 점에서 기대와 실제 기능의 차이를 느낄 수 있어요. 이름이 의도적인 생활형 표현인지, 위치 안내를 기대하게 하는 약속인지 확인한 뒤 첫 화면의 짧은 설명이나 제품 표현을 맞추면 돼요.
  • 제안: 첫 사용자에게 제품명만 보여주고 어떤 기능을 기대하는지 확인해요. 위치 안내 기대가 반복되면 제품 설명을 목록 중심으로 구체화하거나 이름을 조정하고, 공간 위치 기능을 추가하는 선택은 별도 사용자 근거가 있을 때 검토해요.
  • 소스: 제품 정체성/UX 기대
  • 시나리오: (재료 위치를 찾으려는 요리 초보 사용자) 제품 이름을 보고 앱을 설치한 뒤 요리 중 재료를 찾으려 해요.
    • 기대: 이름과 첫 화면 설명이 실제 제공 기능의 범위를 정확히 알려줘요. / 실제: 이름은 공간 지도를 기대하게 할 수 있지만 첫 버전은 재료 목록이에요.
    • 파단점: 사용자가 위치 안내를 찾다가 기대와 기능의 차이를 느낄 수 있어요.
  • 되짚어볼 점: "처음 이름을 본 사용자는 실제 목록 기능과 달리 냉장고 안의 재료 위치를 찾을 수 있다고 기대하나요?"

[19] 구현 대상 모바일 플랫폼과 배포 범위가 정해지지 않았어요

🟡 중간 · 관점: 핸드오프 수신 · 핵심이슈 C14

  • 핵심: 모바일 구현 범위가 플랫폼별로 미정
  • 근거: 입력은 첫 버전을 모바일 앱으로 설명하지만 iOS·Android 등 대상 플랫폼이나 설치·배포 범위는 밝히지 않았어요. 개발자가 화면과 키보드 동작을 구현하는 순간, 선택한 플랫폼에 따라 입력 방식과 실제 기기 확인 범위가 달라질 수 있어요. 플랫폼이 의도적으로 아직 열려 있다면 그 상태와 결정 시점을 인계에 남겨 구현자가 임의로 전제를 보태지 않게 하면 돼요.
  • 제안: 개발 착수 전 첫 버전의 대상 플랫폼, 지원 기기 범위, 배포 방식과 실제 기기 확인 대상을 한 줄씩 확정하거나 미결정 항목으로 표시해요.
  • 소스: 구현/기술 범위
  • 시나리오: (모바일 입력 화면을 구현하는 개발자) 첫 재료 입력과 키보드 동작을 구현할 플랫폼을 선택해요.
    • 기대: 지원 플랫폼과 기기 확인 범위를 알고 구현과 시험을 진행해요. / 실제: 모바일 앱이라는 설명만 있고 대상 플랫폼과 배포 범위는 정해지지 않았어요.
    • 파단점: 개발자가 플랫폼과 시험 범위를 근거 없이 정할 수 있어요.
  • 되짚어볼 점: "첫 버전은 iOS와 Android 중 어디까지 지원하고, 실제 설치와 배포는 어떤 방식으로 할 계획인가요?"

§8.75. 의존성 지도 · 무엇부터 고치면 연쇄로 풀리나

이슈들은 서로 얽혀 있어요. 심각도 순서가 아니라 의존 순서로 봤을 때, 어떤 걸 먼저 고치면 나머지가 함께 풀리는지 정리했어요.

🚧 다른 것을 막는 것 · 먼저 풀어요

  • 첫 버전의 경쟁 구간 미확정 → 막는 것: 경쟁 우위와 사용자 여정의 기준이 아직 정리되지 않았어요 · 첫 사용자 검증으로 이어지는 유입 경로가 정리되지 않았어요 · 제품 이름이 실제 목록보다 공간 지도 기능을 기대하게 할 수 있어요
  • 대상 사용자와 문제 근거 부족 → 막는 것: 첫 사용자의 문제가 다른 사람에게도 흔한지 아직 확인되지 않았어요 · 첫 사용자 검증으로 이어지는 유입 경로가 정리되지 않았어요 · 핵심 가치 가설을 확인할 사용자 검증 기준이 보이지 않아요

🌱 근본 원인 · 여기서 여러 증상이 나와요

  • 대상 사용자와 경쟁 구간을 먼저 좁혀야 해요 → 파생: 경쟁 우위와 사용자 여정의 기준이 아직 정리되지 않았어요 · 첫 사용자의 문제가 다른 사람에게도 흔한지 아직 확인되지 않았어요 · 첫 사용자 검증으로 이어지는 유입 경로가 정리되지 않았어요
  • 핵심 가치의 실제 결과를 따로 확인해야 해요 → 파생: 핵심 가치 가설을 확인할 사용자 검증 기준이 보이지 않아요 · 유료 알림을 검토할 때의 판정 기준이 비어 있어요

🔗 함께 풀어야 성립하는 것

  • 첫 사용자의 문제가 다른 사람에게도 흔한지 아직 확인되지 않았어요 ↔ 경쟁 우위와 사용자 여정의 기준이 아직 정리되지 않았어요 (사용자 문제가 반복되는지와 현재 대안이 무엇인지 함께 확인해야 실제로 공략할 구간과 차별 약속을 정할 수 있어요.)

§9. 다음 행동 (무엇부터 할까)

무엇부터 손댈지 의존 순서대로 정리한 실행 계획이에요. 맨 위가 가장 근본 결정이에요. 위에서부터 순서대로 진행해요.

🔴 첫 버전의 제품 약속 확정

  • 현재 제품 정체성과 최상위 가치 중 첫 버전에서 어떤 사용자 순간과 결과까지 약속할지 전략적으로 확정해요.
    • 첫 행동: 제품 책임자와 함께 현재 한 문장 정의를 검토하고, 첫 버전에서 다룰 사용자 순간과 약속할 결과를 한 문장으로 결정해요.
    • 왜 지금: 제품의 기본 방향은 선명하지만 경쟁 구간과 실제 사용자 가치가 아직 확인되지 않았어요. 먼저 약속의 범위를 결정해야 이후 조사와 기능 우선순위가 같은 기준을 따를 수 있어요.

🟡 사용자와 경쟁 구간을 좁히기

  • 대상 사용자의 문제 빈도와 현재 대안, 제품이 맡을 여정을 함께 확인해요.
    • 첫 행동: 재료를 기억하고 확인하고 소비하는 여정을 단계별로 그린 뒤, 각 단계에서 사용자가 쓰는 앱·메모·직접 행동·포기를 적어요.
    • 왜 지금: 경쟁 대안과 사용자 문제를 함께 알아야 실제로 필요한 구간과 차별 약속을 정할 수 있어요.
  • 첫 사용자 모집 경로와 첫 화면의 제품 설명을 공략 구간에 맞춰 정리해요.
    • 첫 행동: 확정한 사용자 조건에 맞는 모집 경로를 정하고, 제품 이름과 첫 화면 설명이 실제 목록 기능을 정확히 기대하게 하는지 확인해요.
    • 왜 지금: 대상 사용자와 제품 약속이 정해져야 누구를 만나 어떤 기대를 검증할지 구체화돼요.

🟢 가치와 사용 경험을 실제로 확인하기

  • 재방문, 재료 활용, 음식물 폐기 감소를 구분해 관찰할 기준과 기간을 정해요.
    • 첫 행동: 각 단계에서 관찰할 행동 또는 결과, 확인 기간, 성공과 보류를 가르는 기준을 짧은 시험 계획으로 작성해요.
    • 왜 지금: 방문 횟수만으로 최상위 가치가 이뤄졌다고 판단하지 않도록 검증 기준을 먼저 맞출 필요가 있어요.
  • 재료를 목록에서 빼는 의미와 목록의 순서·중복·누적 사용 경험을 정리해요.
    • 첫 행동: 재료를 실제로 다 쓴 경우와 목록만 정리하는 경우를 구분하고, 중복 기록과 긴 목록을 포함한 사용 장면을 화면으로 확인해요.
    • 왜 지금: 사용자가 핵심 목록을 다르게 해석하거나 기록이 쌓인 뒤 찾기 어려우면 첫 가치 경험이 약해질 수 있어요.
  • 저장 안내, 기록 보존·삭제, 접근성 기준을 실제 사용자 흐름과 맞춰 확인해요.
    • 첫 행동: 첫 입력부터 저장 실패, 기기 변경, 기록 삭제까지의 사용자 기대와 실제 동작을 표로 맞춰요.
    • 왜 지금: 핵심 재료 기록을 맡기는 신뢰는 저장 약속과 실제 동작이 일치할 때 만들어져요.

🔵 구현·운영 범위와 수익 결정을 닫기

  • 모바일 플랫폼, 데이터 복구 방식, 반복 오류 대응을 구현 가능한 기준으로 확정해요.
    • 첫 행동: 지원 플랫폼과 배포 범위를 결정하고, 저장 실패·중복 저장·목록 불러오기 장애의 책임과 복구 흐름을 기술 인계 자료에 기록해요.
    • 왜 지금: 사용자와 제품 범위가 정해진 뒤에는 구현자가 임의 전제를 추가하지 않도록 기술·운영 결정을 구체화해야 해요.
  • 선택된 시안과 검증 자료의 최신 원문·작성 시점을 후속 작업자가 확인할 수 있게 정리해요.
    • 첫 행동: 현재 화면안과 검증 자료의 위치, 버전, 실제 작성일과 확인 범위를 한곳에 연결해요.
    • 왜 지금: 구현과 검토가 요약이나 오래된 근거에 의존하지 않도록 현재 기준 자료를 확인할 수 있어야 해요.
  • 핵심 가치와 반복 사용을 확인한 뒤 유료 알림의 검토 기준을 정해요.
    • 첫 행동: 사용자 시험 결과를 바탕으로 반복 사용과 지불 의향을 각각 판단할 기준과 결과별 다음 선택을 합의해요.
    • 왜 지금: 유료화는 현재의 기반 공백을 덮는 첫 결정이 아니라, 실제 가치와 반복 사용을 확인한 다음 판단할 사안이에요.

전문가와 함께 판단할 지점: 현재 자료에서는 특정 경쟁사가 명확히 우위라는 사실까지 확인되지 않아요. 경쟁 구간과 제품 약속을 좁힐 때 제품 책임자와 창업자가 함께 전략을 검토하면 좋아요. 자금·시간 여건은 제공되지 않아 기간이나 생존 제약을 임의로 정하지 않았어요. 실제 경쟁 결과가 제품 변경, 공략 구간 전환, 계속 진행 여부의 선택으로 이어지면 창업자 판단을 거쳐 결정해요.

§10. 개발 착수 준비 게이트

설계를 실제 개발로 넘기기 전에 갖춰졌는지 확인하는 관문이에요. ❌가 있으면 그걸 먼저 채워야 안전하게 착수할 수 있어요.

  • ❌ 핵심 문제·사용자 집단·최상위 가치가 근거와 함께 확정돼 있어요
  • ❌ 첫 버전이 맡을 사용자 여정과 경쟁 구간이 정해져 있어요
  • ❌ 핵심 기능과 재료를 목록에서 빼는 의미가 일관돼요
  • ❌ 첫 사용자 검증 경로와 가치 판정 기준이 마련돼 있어요
  • ❌ 수익 모델과 유료 알림 검토 기준이 정의돼 있어요
  • ❌ 저장 위치·복구·삭제와 기술 데이터 방향이 정해져 있어요
  • ❌ 고심각도 기반 공백이 해소돼 있어요
  • ❌ 기존 화면 자산의 보존 위험과 확인 방법이 정리돼 있어요
  • ❌ 구현 대상 플랫폼과 인계 자료의 최신 근거가 확인돼 있어요

아직 통과 못한 것:

  • 대상 사용자의 문제 근거와 제품이 경쟁할 구간이 아직 확인되지 않았어요.
  • 고심각도 경쟁 구간 공백이 남아 있어 첫 버전의 차별 약속을 확정하기 어려워요.
  • 핵심 기능의 완료 의미와 저장·복구·삭제 기준이 구현에 넘길 만큼 닫히지 않았어요.
  • 첫 사용자 검증 경로와 핵심 가치 판정 기준이 마련되지 않았어요.
  • 플랫폼 범위와 일부 시안·검증 자료의 최신성 및 접근 경로를 확인해야 해요.
  • 기존 화면 자산을 유지할 항목과 변경 시 확인할 보존 기준이 별도로 정리되지 않았어요.

§11. 핸드오프 메시지 · 그대로 복사해서 보내요

이 결과를 팀원·AI 에이전트·직접 수정 중 누구에게 넘기든, 따로 정리할 필요 없이 그대로 복사해 보낼 수 있는 메시지예요.

팀원에게

현재 제품의 방향과 첫 목록 경험은 구체적인 출발점이 있어요. 구현에 앞서 대상 사용자의 문제가 실제로 얼마나 자주 발생하는지, 현재 대안과 비교해 앱이 맡을 구간이 어디인지 먼저 정리해 주세요. 그다음 재료를 목록에서 빼는 의미, 저장·복구·삭제 안내, 접근성, 오류 대응을 담당자별로 결정하면 좋아요. 기존 화면안과 검증 자료의 최신 원문도 함께 확인하고, 화면이나 동작을 바꿀 때는 기존 자산이 유지되는지 단계별로 확인해 주세요.

AI 에이전트에게

첨부된 보고서를 읽고 먼저 제품이 약속하는 사용자 순간과 첫 버전 범위를 파악해 주세요. 그다음 대상 사용자 문제와 경쟁 대안을 확인해 공략 구간을 정리하고, 보고서의 권장 순서에 따라 사용자 흐름과 기술 기준을 보강해 주세요. 저장·복구·삭제, 목록에서 재료를 빼는 의미, 모바일 플랫폼은 자료에 없는 결정을 임의로 사실처럼 확정하지 말고 미정 사항으로 표시해 주세요. 기존 화면안과 디자인 자산을 보존하고, 원문 시안과 검증 근거의 최신 버전을 확인해 주세요. 각 변경은 작은 단위로 진행하고 기존 흐름이 유지되는지 매 단계 확인해 주세요.

직접 수정할 때

먼저 현재 제품 정체성과 최상위 가치 중 첫 버전에서 실제로 약속할 범위를 한 문장으로 결정해요. 이어서 대상 사용자와 현재 대안을 조사해 제품이 맡을 구간을 좁히고, 첫 사용자 모집 및 가치 확인 기준을 정해요. 그다음 목록 행동의 의미와 화면 사용성을 확인하고, 저장·복구·삭제·플랫폼·운영 기준을 문서화해요. 마지막으로 시안과 검증 자료의 최신 원문을 연결하고, 유료 알림은 반복 사용과 지불 의향을 확인한 뒤 판단해요. 기존 디자인과 동작은 바꾸기 전에 보존할 항목을 기록하고 단계별로 다시 확인해요.

이 리포트는 진단이에요. 실행 성공의 보장이 아니라, 어디를 보강하면 더 단단해지는지 짚은 거예요. 개선 후 다시 점검하면 실행 과정에서 생긴 새 빈틈을 잡을 수 있어요.

Zero to Builder

빌더로 자라는 과정을 보여줘요

AI를 얼마나 잘 이끄는지, 다음 단계로 가려면 무엇을 연습하면 되는지 알려줘요.

실제 성장 리포트 보기 →
PurplePrint 빌더 성장 대시보드 화면

초보 빌더를 위한 비즈니스 설계 프레임워크

제품의 방향이 바뀐 순간들.

“우리 팀이 뭐가 부족한지 알았어요.”

이미 제품을 만들고 100만원을 paid에 썼어요. 팀 3명이 달려들었고요. 그런데 회원가입 17명 중 핵심 기능을 경험한 유저는 0명. 뭐가 문제인지도, 어떻게 고쳐야 하는지도 모르는 상태였어요.

이대로 가면 팀의 시간과 돈을 계속 쏟아도 같은 결과. 이 아이템을 계속 해야 하나, 고민까지 들었죠.

Hyper-Review를 돌렸더니, 기획서에서 45건의 빈틈이 나왔어요. 리포트와 함께 founder 컨설팅을 한 결과, 가장 큰 문제는 서비스 설계 자체가 빈약한 상태로 제품을 만든 것이었어요. 페르소나도 부정확했고, 제대로 된 유저 value chain 분석 없이 이미 제품을 만들었으니, UX·UI도 엉망이었죠. 이 모든 걸 1시간 만에 진단했고, 당장 해야 할 액션까지 교정받았어요.

원래 이 정도 컨설팅을 받으려면 몇 주에 수 백만원 이상을 써야 하는데, 이렇게 빠르게 진단받고 해결 방안까지 받을 수 있을지 몰랐어요. 결과적으로 수 개월의 시간과 수 천만원의 비용을 아꼈고, 진짜 제품 설계를 토대로 제대로 된 제품을 만들어갈 수 있게 됐어요. 단 1시간 만에요! 너무 좋습니다.

Hyper-Review— B2C2B 서비스, SI 시니어 개발자 출신 대표, 3인 Startup team
둘러보기

시작하기 전에 확인할 것

시작 가이드 연결부터 첫 세션까지샘플 리포트 Hyper-Review 결과 예시빌더 레벨 my-growth로 보는 성장업데이트 최근에 바뀐 점
Kits

실제 프로젝트에서 쓴 템플릿과 운영 시스템

PurplePrint가 실제 프로젝트에서 사용한 방법론·템플릿·운영 시스템을 Kit으로 정리해, 무료 체험이나 구독 중인 분께 제공해요.

클라이언트 운영 워크스페이스요청·피드백·과업·문서가 흩어진 서비스 사업을 하나의 양면 운영 공간으로 재설계합니다.Dense Operations Console반복 레코드, 필터, 상태, 이벤트 이력과 상세 근거가 많은 운영 제품용 중립 스타터입니다.Editorial Web KitIA·컴포넌트·디자인 시스템·인터랙션·SEO 템플릿을 브랜드 설정으로 렌더하는 웹 빌드 킷입니다.Product UI System Extractor접근 권한이 있는 제품 UI를 실측해 복제가 아닌 재사용 가능한 구조와 테마 슬롯으로 변환합니다.SaaS 랜딩 템플릿제품 한 장 랜딩을 10블록으로 짜고, 원본·정돈판·제품 화면 우선판 세 판을 눈으로 보고 골라 씁니다.SEO Content Blueprint검색의도·고객 여정·콘텐츠 구조·기술 SEO/GEO·측정을 하나의 발행 방법론으로 묶습니다.Social Content Operations짧은 브랜드 브리프를 전략·캘린더·멀티모달 제작·검수·발행·성과 회수 흐름으로 확장합니다.Web Audit사이트 헬스·SEO·GEO·SERP·렌더 근거·전환 UX를 CLI 파이프라인으로 점검합니다.

Kits 전체 보기 →

간단하고 빠른 시작

AI 에이전트에 설치 프롬프트 하나만 붙여넣으세요.

AI 도구가 처음인가요? 시작 가이드 보기

Claude Code 설치 자연어 명령 · 올리면 원문 보기PurplePrint MCP를 Claude Code에 추가해줘. 서버 이름은 purpleprint, transport는 http, URL은 https://purpleprint-mcp.purpleprintai.workers.dev/mcp 이야. 전역(user scope)으로 등록하고, ~/.claude.json의 mcpServers.purpleprint에 alwaysLoad: true도 넣어줘 (최신 Claude Code IDE에서 /purpleprint:* 슬래시가 안 보이는 문제를 막는 설정이야). 직접 수정하면 UTF-8 no BOM으로 저장해줘. /mcp에서 purpleprint Authenticate까지 진행해줘. ⚠️ **슬래시(/purpleprint:*)가 안 보여도 그냥 쓸 수 있어. 연결만 됐으면 "퍼플프린트 시작해줘"라고 자연어로 말하면 pp_start tool로 바로 시작돼.** 슬래시 목록은 편의일 뿐이라, 안 뜬다고 설치를 다시 하거나 붙잡고 있지 말고 자연어로 진행해줘. 인증이 필요한데 화면이 안 뜨면 purpleprint를 껐다 켠 뒤(disable → enable) 다시 확인해줘. 이미 "connected"로 보이면 대개 인증은 끝난 상태야. 그리고 다음에도 자동으로 이어지게 ~/.claude/CLAUDE.md(전역)에 재개 규칙을 추가해줘: 이미 있으면 넘어가고, 기존 내용은 안 건드리고 append만 해줘: "PurplePrint로 설계하던 프로젝트를 이어가는 세션이면 먼저 pp_start로 재개한다. PurplePrint MCP가 연결돼 있지 않으면 그냥 진행하지 말고 '지금 PurplePrint 없이 진행 중'임을 유저에게 먼저 알린다. 무관한 작업이면 무시한다." 마지막 단계(꼭 해야 해요): 설치·로그인이 끝나면 나에게 이렇게 알려줘. "이제 Claude Code를 다시 시작해 주세요. 터미널이면 지금 세션을 끝내고 claude를 새로 실행하고, VS Code·Cursor 확장이면 창 다시 로드, 데스크톱 앱이면 트레이까지 완전히 종료했다가 다시 열어 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 "퍼플프린트 시작해줘"라고 말해 주세요." 새 연결은 앱을 다시 열어야 잡히니까, 이 세션에서 바로 확인이 안 돼도 정상이야. 설치를 다시 하지 마.
Cursor · VS Code 설치 자연어 명령 · 올리면 원문 보기PurplePrint MCP를 이 에디터에 추가해줘. 서버 이름은 purpleprint, URL은 https://purpleprint-mcp.purpleprintai.workers.dev/mcp 이야. 이 툴의 MCP 설정에 remote/http MCP로, 한 프로젝트가 아니라 전역(유저 설정: 예: ~/.cursor/mcp.json, VS Code 유저 settings)으로 등록해줘. OAuth/authorize 흐름이 필요하면 브라우저 로그인까지 진행하게 안내해줘. ⚠️ **명령 목록이 안 보여도 그냥 쓸 수 있어. 연결만 됐으면 "퍼플프린트 시작해줘"라고 자연어로 말하면 pp_start tool로 바로 시작돼.** 목록은 편의일 뿐이라 안 뜬다고 붙잡고 있지 말고 자연어로 진행해줘. 인증 화면이 필요한데 안 뜨면 purpleprint를 껐다 켠 뒤(disable → enable) 확인해줘. 이미 "connected"면 대개 인증은 끝난 상태야. 그리고 다음에도 자동으로 이어지게 Cursor면 ~/.cursor/rules/purpleprint.mdc(frontmatter alwaysApply: true), VS Code Copilot이면 유저 지침 파일(전역)에 재개 규칙을 추가해줘: 이미 있으면 넘어가고, 기존 내용은 안 건드리고 append만 해줘: "PurplePrint로 설계하던 프로젝트를 이어가는 세션이면 먼저 pp_start로 재개한다. PurplePrint MCP가 연결돼 있지 않으면 그냥 진행하지 말고 '지금 PurplePrint 없이 진행 중'임을 유저에게 먼저 알린다. 무관한 작업이면 무시한다." 마지막 단계(꼭 해야 해요): 설치·로그인이 끝나면 나에게 이렇게 알려줘. "이제 에디터(Cursor·VS Code)를 완전히 종료했다가 다시 열어 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 새 채팅에서 "퍼플프린트 시작해줘"라고 말해 주세요." 새 연결은 앱을 다시 열어야 잡히니까, 이 세션에서 바로 확인이 안 돼도 정상이야. 설치를 다시 하지 마.
Codex 설치 자연어 명령 · 올리면 원문 보기PurplePrint MCP를 Codex에 추가해줘. 서버 이름은 purpleprint, URL은 https://purpleprint-mcp.purpleprintai.workers.dev/mcp 이야. Codex CLI/IDE가 공유하는 ~/.codex/config.toml에 streamable HTTP MCP로 등록하고 OAuth 로그인까지 진행해줘. 로그인 창은 5분 안에 끝내야 한다고 먼저 알려줘(Codex가 5분만 기다려). 늦어서 "로그인은 끝났어요" 안내나 127.0.0.1 연결 오류가 뜨면 로그인을 한 번 더 시작해줘: 이미 로그인돼 있어서 금방 끝나. Windows PowerShell에서 codex.ps1 실행정책에 막히면 cmd /c codex mcp ... 형태로 실행해줘. 끝나면 codex mcp list로 등록을 확인해줘. / 메뉴에 /purpleprint:start가 안 떠도 정상이야: 자연어 "PurplePrint 시작해줘"로 pp_start tool을 써. 그리고 다음에도 자동으로 이어지게 ~/.codex/AGENTS.md(전역)에 재개 규칙을 추가해줘: 이미 있으면 넘어가고, 기존 내용은 안 건드리고 append만 해줘: "PurplePrint로 설계하던 프로젝트를 이어가는 세션이면 먼저 pp_start로 재개한다. PurplePrint MCP가 연결돼 있지 않으면 그냥 진행하지 말고 '지금 PurplePrint 없이 진행 중'임을 유저에게 먼저 알린다. 무관한 작업이면 무시한다." 마지막 단계(꼭 해야 해요): 설치·로그인이 끝나면 나에게 이렇게 알려줘. "이제 Codex를 다시 시작해 주세요. CLI면 지금 세션을 끝내고 새로 실행하고, VS Code 확장이면 창 다시 로드, ChatGPT 데스크톱 앱이면 트레이까지 완전히 종료했다가 다시 열어 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 새 스레드에서 "PurplePrint 시작해줘"라고 말해 주세요." 새 연결은 앱을 다시 열어야 잡히니까, 이 세션에서 바로 확인이 안 돼도 정상이야. 설치를 다시 하지 마.
Antigravity 설치 자연어 명령 · 올리면 원문 보기PurplePrint MCP를 Antigravity 전역 MCP로 추가해줘. 서버 이름은 purpleprint, URL은 https://purpleprint-mcp.purpleprintai.workers.dev/mcp 이야. ~/.gemini/config/mcp_config.json에 serverUrl 방식으로 등록하고, 필요하면 ~/.gemini/antigravity/mcp_config.json도 확인해줘. 등록 후 Settings > Customizations > Installed MCP Servers에서 Refresh하고 Authenticate까지 진행해줘. 그리고 다음에도 자동으로 이어지게 Antigravity가 세션 시작에 읽는 전역 지침 파일(예: ~/.gemini/GEMINI.md 또는 AGENTS.md)(전역)에 재개 규칙을 추가해줘: 이미 있으면 넘어가고, 기존 내용은 안 건드리고 append만 해줘: "PurplePrint로 설계하던 프로젝트를 이어가는 세션이면 먼저 pp_start로 재개한다. PurplePrint MCP가 연결돼 있지 않으면 그냥 진행하지 말고 '지금 PurplePrint 없이 진행 중'임을 유저에게 먼저 알린다. 무관한 작업이면 무시한다." 마지막 단계(꼭 해야 해요): 설치·로그인이 끝나면 나에게 이렇게 알려줘. "이제 Antigravity를 완전히 종료했다가 다시 열어 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 "PurplePrint 시작해줘"라고 말해 주세요." 새 연결은 앱을 다시 열어야 잡히니까, 이 세션에서 바로 확인이 안 돼도 정상이야. 설치를 다시 하지 마.

시작 방법: PurplePrint 연결 완료 후 /purpleprint:start를 입력하거나, “퍼플프린트 시작하자”라고 말하세요.

PURPLEPRINT BETA

$13 / 월

매월 10회 심층 설계 점검으로 빠진 부분을 찾고, 무엇부터 보완할지 확인하세요.

14일 무료, 카드 등록 없음. 설계 코치, Hyper-Review, 빌더 성장 측정을 포함합니다.

베타 구독설치 상세 보기
FAQ

PurplePrint, 무엇이 다른가요?

Claude Code나 Codex만 사용하는 것과 무엇이 다른가요?

Claude Code와 Codex는 작업을 실행하는 에이전트입니다. PurplePrint는 그 안에서 서비스 설계의 결정 순서, 근거 있는 제안, 승인 게이트, 산출물과 다음 행동을 이어줍니다.

어떤 선택이 좋은지 모르겠으면 어떡하나요?

PurplePrint가 상황에 맞는 1순위와 그 이유, 다른 후보를 뒤로 둔 이유를 먼저 제안합니다. 사용자는 자신의 경험과 맞는지 확인하면 됩니다. 아직 근거가 부족한 부분은 가정과 검증할 사항으로 남깁니다.

아이디어 한 줄만 있어도 시작할 수 있나요?

네. Design Coach가 제품이 왜 필요한지부터 사용자, 문제, 제품, 경험, GTM, 개발 설계와 핸드오프까지 순서대로 이끕니다.

이미 만든 제품도 진단하고 개선할 수 있나요?

네. Hyper-Review로 현재 설계의 빈틈을 찾은 뒤, 필요한 Design Coach Phase로 돌아가 보강할 수 있습니다.

설계 문서만 만들고 끝나나요?

정리한 설계를 바탕으로 사용하는 AI 에이전트와 구현·테스트·배포를 이어갈 수 있습니다. 고객을 찾는 전략과 실행도 함께 진행합니다. 사용자는 결과를 확인하고 필요한 외부 계정 연결이나 유료 서비스 이용을 승인합니다.

아이디어와 대화, 설계 문서는 어디에 저장되나요?

코칭으로 만든 문서는 기본적으로 내 작업 폴더에 남습니다. Hyper-Review를 실행하면 제출하거나 선택한 자료가 서버로 전송되어 분석되고, 결과 리포트가 저장됩니다. 진행 단계와 사용량은 별도로 기록합니다.

별도의 앱이나 서비스 설계 전문 지식이 필요한가요?

아니요. 지금 쓰는 에이전트 안에서 그대로 진행하면 됩니다. MCP, Skill, Hook, Memory, Compaction을 몰라도 과정을 따라갈 수 있습니다.

아이디어가 있다면, 오늘 설계를 시작해요

14일 무료, 카드 등록 없이 시작해요.

내 아이디어로 시작하기가격 보기 →