Do things that don't scale · 창업자 1,000명을 직접 돕습니다

Business Driven Development AI Agent

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

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

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

14일 무료 · 카드 등록 없음

기존 서비스 기획·개발 설계 빈틈 심층 점검받기 →

AI 도구에서도Claude CodeCodexCursorVisual Studio CodeGoogle Antigravity

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

실제 사용자 후기 원문에서

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

순정 AI 에이전트만 쓸 때와 다른 점

Session memory, context 유지, 잘 몰라도 돼요. 코치가 알아서 해요.

데모 직접 열어 보기 →

작동 방식

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

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

  1. 아이디어를 말해요

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

  2. 1순위를 보고 정해요

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

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

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

기능

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

고르라고 하지 않고, 1순위를 먼저 제안해요

Claude Code·Codex만 쓸 때
  1. 무엇을 어떻게 설계할지 내가 정하고 지시해야 해요
  2. 설계를 잘 모르면 지시하기 어려워 결국 AI에 맡기게 돼요
  3. 맡긴 설계는 수동적이라, 기획 경험이 적을수록 얕아져요
퍼플프린트와 할 때
  1. 코치가 먼저 묻고, 후보와 1순위, 뺀 이유까지 보여 주며 이끌어요
  2. 기획 역량이 부족해도 차근차근 깊이 있는 설계가 돼요
PurplePrint 코치Phase 1 유저 페르소나 정의

사진이나 메모를 그만두는 가장 가까운 이유는 적어둔 걸 다시 확인하는 일을 잊는 것이군요. 기록 자체보다 기록을 다시 떠올리게 하는 게 어려운 모습이에요.

이 사람이 가진 강점도 살펴볼게요.

후보 셋
  1. 낭비를 줄이려고 사진이나 메모를 시도해봤어요. 문제를 바꾸려는 마음이 이미 있다는 점이 강점이라, 저는 이 후보를 우선으로 봐요.1순위
  2. 일주일에 몇 번은 직접 요리해요. 재료를 실제로 쓸 기회가 있으니, 알맞은 때 메뉴를 제안하면 도움이 될 수 있어요.
  3. 다른 강점이 있어요. 예를 들어 냉장고 정리를 잘하거나, 장보기 전에 계획하는 습관이 있을 수 있어요.

2번은 요리하는 빈도를 확인했지만, 실제로 잘하는 점인지는 더 알아야 해요. 3번은 아직 그런 습관을 들은 적이 없어요.뺀 이유 이 사람의 강점은 어느 쪽에 가장 가까워요?

고르기만 하면 돼요

이 사람이 가진 강점은 어떤 점에 가장 가까울까요?

  • 낭비를 줄이려고 사진이나 메모를 시도해봤어요추천문제를 바꾸려는 마음과 이미 시도해본 경험이 있어요.
  • 일주일에 몇 번은 직접 요리해요재료를 실제로 쓸 기회가 있어요.
  • 다른 강점이 있어요냉장고 정리나 장보기 계획처럼 떠오르는 습관을 말해주셔도 돼요.

낭비를 줄이려고 사진이나 메모를 시도해봤어요

아이디어들을 마구 발산하세요. 퍼플프린트가 알아서 체계적인 설계문서들로 만들어줍니다.

맥락문서.mdPhase 0~1막연한 아이디어가 '누구의 어떤 문제'로 바뀌는 첫 장이에요.
  • 아이디어 한 문장과 왜 지금이어야 하는지
  • 비슷한 서비스와 확인한 사실(출처까지)
  • 가장 먼저 도울 한 사람과 그 사람이 쓰는 말
  • 검증 계획과 아직 모르는 것
맥락문서.mdPhase 0~1

맥락문서

Phase 0 · 아이디어와 배경

0.1 아이디어 한 문장

전세계약을 앞둔 사람이 집의 위험을 일반인도 이해할 수 있게 확인하는 서비스를 만들고 싶어요. 시작 범위는 전세와 보증금이 있는 월세계약이에요.

0.2 왜 지금인가

친구가 전세사기로 보증금 1억 2천만 원을 돌려받지 못하는 일을 겪었어요. 친구는 가계약금을 보내기 전에 주소와 보증금은 알았지만 위험 확인 서비스가 있다는 사실을 몰랐어요. 송금 뒤에는 인터넷 정보를 찾아봤지만 확인 항목이 많고 설명도 달라 중요도를 고르지 못했어요. 본계약 때는 등기부등본을 약 10분 봤지만 근저당의 뜻을 몰랐고 중개사의 설명에 기대었어요.

이 사례를 계기로 가계약금을 보내기 전 위험 신호와 믿을 만한 확인 방법을 알 수 있게 돕고 싶어요. 집의 안전이나 보증금 반환을 보장하는 서비스가 아니라, 이해와 확인을 돕는 서비스로 생각해요.

0.3 참고 서비스와 확인된 맥락

  • HUG 안심전세는 시세·위험성 진단, 적정보증금, 임대인 정보 조회, 계약 단계별 확인 등을 공개 안내해요.
  • KB부동산 전세안전진단은 주소와 보증금으로 시세·권리 정보를 살피는 기능을 공개 안내해요.
  • 경기도의 경기 안심 부동산은 지도에서 매물을 찾고 AI 권리분석을 받을 수 있으며, 원하는 매물이 없으면 주소와 계약 조건을 제출해 인근 중개사에게 분석을 요청할 수 있어요.
  • 따라서 위험 정보를 모으거나 주소로 진단하는 것만으로는 새로움이나 경쟁 우위를 주장하기 어려워요. 실제 이용자가 기존 서비스를 발견하고 이해하는 데 어려움이 있는지는 검증이 필요해요.
  • 출처: HUG 안심전세 · KB 전세안전진단 · 경기 안심 부동산

Phase 1 · 먼저 도울 사람

1.1 현재 1차 페르소나

처음 전세계약을 하는 20대 후반~30대 초반 직장인이에요. 회사 근처로 이사하려고 매물 앱을 살피고 중개사무소를 방문해 집을 봐요. 집의 위치·상태와 가격에는 관심을 두지만, 부동산 권리관계에는 익숙하지 않을 수 있어요.

실제 친구 사례에서는 주변보다 약 2천만 원 싼 빌라를 봤고, 다른 두 팀도 집을 봤다는 말을 듣자 놓칠까 불안해져 한 시간도 안 돼 가계약금을 보냈어요. 당시 집 주소와 보증금은 알았지만 등기부등본은 없었어요. 송금 후 블로그를 검색했지만 확인 항목이 많고 설명이 달라 중요한 것을 고르지 못했고, 공식 앱이 있다는 것도 일이 생긴 뒤 알았어요.

이 사례는 한 사람에게서 들은 경험이에요. 모든 초보 세입자가 같은 행동을 한다고 일반화하지 않아요. 공개 사례 조사에서도 첫 계약과 현장 가계약 압박 신호는 일부 확인했지만 빈도나 대표성은 검증하지 못했어요. 자세한 내용은 docs/research/persona-20261010-first-rental.md에 기록했어요.

1.2 먼저 얻었으면 하는 변화

가계약금을 보내기 전에 집에서 먼저 살펴볼 점과 이유, 믿을 만한 확인 방법을 이해한 뒤 스스로 판단해요. 6개월 뒤에는 새 집을 알아볼 때 위험 신호와 확인할 점을 스스로 살필 수 있으면 좋겠어요.

서비스는 집이 안전하다거나 보증금을 지켜준다고 단정하지 않아요. 현재 확인할 수 없는 정보와 근거의 한계도 밝혀요.

1.3 말과 태도

당사자가 쓸 수 있는 말의 초안은 “이 집, 괜찮은 건가요?”, “등기부등본에서 뭘 봐야 해요?”, “가계약금 보내기 전에 더 확인할 게 있나요?”예요. 공개 질문에서 확인한 실제 표현으로는 “그자리에서 가계약금 넣으라고 하네요, 그렇지 않으면 계약할 수 없다고요”가 있어요. 실제 인용과 코치가 만든 초안은 구분해 사용해요.

전문용어를 설명 없이 나열하거나 안전을 확정하는 말, 모른다고 탓하는 말은 피하고 쉬운 말로 설명해요.

Phase 2 · 문제 정의 확정

2.1 현재 행동과 가장 급한 순간

친구분은 약 2주간 매물을 찾고 중개사무소 두 곳을 방문했어요. 주변보다 약 2천만 원 싼 빌라를 본 뒤, 다른 두 팀도 집을 봤다는 말을 듣고 한 시간도 안 돼 가계약금을 보냈어요. 당시 가진 건 주소와 보증금뿐이었어요. 송금 뒤 블로그를 검색했지만 확인 항목이 많고 설명이 달라 우선순위를 고르지 못했어요. 일주일 뒤 본계약 당일 등기부등본을 약 10분 보았지만 근저당의 뜻을 몰라 중개사의 설명에 기대었어요. 전체 여정은 대략 3주로 볼 수 있지만 탐색과 방문의 시점이 겹쳤는지는 미확인입니다.

우선 풀 문제는 처음 전세계약을 하는 직장인이 집을 놓칠까 급해진 순간, 가계약금을 보내기 전에 위험 신호와 믿을 만한 확인 방법을 몰라 충분히 판단하지 못하는 것이에요.

2.2 사용자가 선택한 접점과 가치 가설

매물 링크를 먼저 붙여넣고, 읽을 수 없으면 주소를 입력해요. 중개사무소 앞에서도 휴대전화로 바로 시작해, 먼저 확인할 점과 이유·믿을 만한 다음 확인 방법을 짧게 안내받고 싶어 해요.

HUG·KB는 주소 기반 진단을, 경기 안심 부동산은 지도 매물 탐색과 주소·조건 기반 권리분석을 안내해요. 따라서 링크 입력이나 쉬운 설명만으로 차별점이라고 할 수 없어요. 매물을 보는 순간에 실제로 더 쉽게 시작하고, 다음 확인을 빨리 이해하는지는 검증할 가설이에요.

2.3 검증 계획과 한계

사용자는 이번 주 회사 동료 중 최근 전세 계약을 한 사람 몇 명과 인터뷰하기로 했어요. 설계를 멈추지는 않고 현재 가설로 진행하며, 실제 경험이 다르면 이후 수정하기로 했어요.

공개 후기와 질문을 일부 확인했지만 표본이 작고 대표성이 없어요. 직접 인터뷰·정량 수요·지불 의사·매물 링크 호환성·실제 진단 결과의 정확도와 사용성은 아직 검증되지 않았어요. 상세 행동 지도·경쟁 분석·출처는 설계문서.md §2와 docs/research/persona-20261010-first-rental.md에 있어요.

필요하면 직접 찾아보고 근거를 남겨요

경쟁 서비스, 쓸 사람(페르소나), 마케팅·시장 진입, 만들 기능에 필요한 자료까지 코치가 웹에서 찾아 읽어요. GitHub·Reddit 같은 곳도 살펴보고, 출처는 문서에 남겨요.

페르소나 조사가정한 쓸 사람을 공개 자료로 다시 확인하고, 가까이 있는 다른 사람도 찾아봐요.
  • 경쟁 서비스
  • 페르소나
  • 마케팅
  • 시장 진입
  • 기능 자료 · GitHub · Reddit
페르소나 조사

페르소나 검증 리포트

가정한 1차 페르소나

처음 전세계약을 하는 20대 후반~30대 초반 직장인. 집을 놓칠까 서두르는 상황에서 가계약금을 보내기 전에 위험 확인을 시작할 수 있는 방법과 다음 확인 행동을 필요로 해요.

분석 일시

2026-10-10

요약

  • 부분 확증: 첫 전세계약을 앞둔 사회초년생과 현장에서 가계약을 재촉받는 세입자의 공개 사례를 확인했어요. 다만 표본이 적어 나이대 전체나 문제의 빈도를 입증하지는 않아요.
  • 조정 검토: 매물 앱의 링크 붙여넣기가 실제로 더 편한지는 확인되지 않았고, 주소 기반 진단과 권리분석 서비스가 이미 있어요.
  • 핵심 미확인: 초보 세입자가 가계약 전 바로 쓸 서비스를 찾는지, 짧은 우선순위 안내가 기존 진단보다 더 도움이 되는지, 돈을 낼 의사가 있는지 직접 검증해야 해요.

검증 범위

  • 관찰 방식: 공개된 개인 전세계약 후기 1건, 부동산 질의응답 2건, HUG 앱스토어 후기 표본, 공식 서비스 안내를 검색해 원문 일부를 읽었어요.
  • 직접 확인 범위: 2023년 사회초년생 계약 후기, 2023년 가계약금 질문과 답변, 2026년 가계약금 관련 질문과 답변, HUG 앱스토어 페이지의 평점·평가 수·노출 후기 및 버전 내역이에요.
  • 미확인 범위: 실제 1:1 인터뷰, 커뮤니티 내 게시글 전체와 빈도, 사용성 테스트, 수요 규모, 전환율·지불 의사, 링크 붙여넣기 사용성, 진단 서비스의 정확도와 최신 결과 흐름이에요.
  • 표본 한계: 공개 게시물은 검색에 잡힌 소수 사례예요. 대표 표본이 아니며, 답변은 법률 자문이 아니에요.

1. 페르소나 실존 검증

신호 · 직접 확인

  • 어디에 나타났는가: 부동산 질의응답 게시판과 개인 블로그에서 첫 계약, 가계약금, 대출·보증보험, 등기부 확인에 관한 공개 글을 찾았어요.
  • 실제 표현: 2026년 질문자는 “그자리에서 가계약금 넣으라고 하네요, 그렇지 않으면 계약할 수 없다고요”라고 썼어요. 이는 매물을 놓칠까 급해지는 상황과 닿아 있지만, 한 사례예요.
  • 행동 신호: 2023년 사회초년생의 전세계약 후기에는 한 달가량 준비하고 매물을 검색하며, 매물 등기부등본을 가지고 은행에서 대출 가능 금액을 확인한 뒤 가계약을 진행한 과정이 적혀 있어요. 글쓴이는 등기부상 융자·근저당이 없는 조건을 우선했고, 임대인의 세금 납부 확인과 계약 특약을 찾아봤다고 해요. 또 계약 과정에 필요한 서류와 용어를 스스로 공부해야 했다고 회고해요.
  • 반대 신호: 위 후기의 작성자는 시간을 들여 여러 정보를 찾고, 등기부등본을 은행에 가져가 확인하고, 중개사에게 추가 자료를 요청했어요. 따라서 모든 초보 세입자가 정보를 못 찾거나 중개사에게만 의존한다고 볼 수 없어요.
  • HUG 앱스토어 신호: 페이지는 평점 3.6, 평가 448개를 표시해요. 직접 읽은 불편 후기는 주로 2023년으로 느린 구동, 가입·서명 문제, 서류 제출 문제를 말했고, 긍정 후기 또한 확인했어요. 2025~2026년의 구체적 불편 리뷰라고 일반화하지 않으며, 해당 리뷰는 계약 전 위험 진단 기능 자체의 평가도 아니에요.

판정: 가정한 사람이 존재하고 전세계약을 준비하는 과정에서 불확실성과 시간 부담을 겪는 신호는 부분 확증이에요. 가계약 직전의 압박과 이해 부족이 얼마나 흔한지는 공개 표본으로 검증되지 않았어요.

2. 인접 페르소나

세그먼트같은 문제를 겪는 방식규모감해결책 적합도
처음 보증금 있는 월세계약을 하는 청년 직장인보증금과 권리 확인에 익숙하지 않을 수 있어요.이 조사에서는 규모를 확인하지 못했어요.전세 확인 과정과 겹치는 부분이 있을 수 있지만, 임대차 조건별 확인 차이를 먼저 확인해야 해요.
지역을 옮기며 급히 집을 구하는 직장인입주 기한이나 매물 경쟁 때문에 확인보다 선점에 마음이 쏠릴 수 있어요.2026년 공개 질문 한 건에서 현장 가계약 압박을 봤지만, 세그먼트 규모는 알 수 없어요.짧은 모바일 확인 안내와 맞을 가능성이 있으나 직접 인터뷰가 필요해요.
첫 집을 전세로 구하는 신혼부부큰 보증금을 처음 다루며 등기·선순위 권리 등을 어려워할 수 있어요.이 조사에서는 자료를 확인하지 못했어요.지금 대상과 유사할 수 있지만 부부 공동 의사결정 등 상황이 달라 검증 전 우선순위를 올리지 않아요.

우선순위 판단: 처음 전세계약을 하는 직장인이 친구분의 사례와 직접 맞닿으므로 1차 대상은 유지해요. 보증금 있는 월세 이용자는 인접 확장 후보지만 근거가 부족해요.

3. 니즈와 언어

진짜 불편 · 직접 확인한 신호

  • 한 공개 글에서는 계약 전에 여러 서류·대출 조건을 알아보고 중개사에게 설명을 요청하는 부담이 나타나요.
  • 2026년 질의응답에는 “다른 사람이 먼저 볼까 봐 지금 가계약금을 넣어야 하는가”라는 불안이 드러나요. 일부 답변은 서류 확인과 반환 조건 기록을 권했지만, 답변끼리 강조점이 다르고 법률 판단으로 사용할 수 없어요.
  • 친구분의 사례에는 검색 정보가 너무 많아 중요한 항목을 고르지 못했다는 경험이 있어요. 이는 유저가 전달한 단일 사례로, 외부 표본으로 반복 확인되지는 않았어요.

현재 대안

  • 검색·블로그로 전세 위험과 체크리스트를 찾기.
  • 매물 등기부등본을 받아 은행이나 전문가에게 문의하기.
  • 중개사에게 권리·대출·보증보험 가능성을 묻기.
  • HUG, KB 전세안전진단, 경기 안심 부동산 등의 공식·민간 확인 경로 이용하기. 친구분은 공식 앱의 존재를 일이 생긴 뒤 알았어요.

언어 사전 재료

  • 써볼 표현: “그자리에서 가계약금 넣으라고 하네요”, “그렇지 않으면 계약할 수 없다고요”, “등기부등본을 가지고 은행에 문의했어요”, “가계약금 넣고 나면 마음이 놓이지 않아요”처럼 출처가 있는 실제 표현. 마지막 표현은 이번에 확인한 문장 그대로가 아니라 해당 질문의 맥락을 요약한 것이므로 실제 인용으로 쓰지 않아요.
  • 피할 표현: “안전한 집 확정”, “사기를 막아드려요”, “이 집은 위험/안전”처럼 검증되지 않은 확정 판정이나 보증을 암시하는 말. 초보자를 탓하는 표현도 피하는 게 좋아요.

4. 지불·전환 신호

  • 지불 신호: 이 표본에서 전세 확인 안내에 대한 명확한 지불 의사나 유료 이용 증거를 확인하지 못했어요. 블로그 검색과 서류 확인에 쓴 시간은 있으나, 지불 의사와 같다고 볼 수 없어요. HUG 등 기존 선택지의 일부 확인 비용은 공개되어 있어도, 그것만으로 이 서비스에 대한 WTP를 입증하지 않아요.
  • 전환 트리거: 매물을 놓칠 수 있다는 말을 듣거나 현장에서 바로 가계약금을 요구받는 상황이 공개 질문과 친구분 사례에서 확인돼요. 빈도는 알 수 없어요.
  • 이탈 지점: 블로그마다 확인 사항이 달라 우선순위를 정하지 못했다는 친구분의 설명이 있어요. 공개 후기 하나에서는 수많은 계약 서류와 정보 탐색이 부담스러웠지만, 기존 진단 서비스 이용 도중 이탈했는지 확인한 사례는 없어요.

5. 우리 서비스 관점 시사점

분류항목이유
✅ 유지처음 전세계약을 하는 직장인실제 전세계약 후기와 가계약 압박 질문이 일부 확인됐고, 친구분 경험과도 직접 맞닿아요. 일반화는 금지해요.
🔄 검증가계약 직전의 즉시 모바일 진입현장 압박 사례는 있으나 링크 붙여넣기가 더 편하거나 더 자주 쓰일지는 확인되지 않았어요.
🔄 검증한두 가지 우선 확인과 다음 행동 안내친구분의 정보 과부하와 맞지만, 다른 사용자에게도 가장 중요한 문제인지 확인이 필요해요.
🔄 검증경쟁 우위HUG·KB는 주소 진단을, 경기 안심 부동산은 지도·주소 기반 권리분석을 안내해요. 링크 입력만으로 우위를 주장할 수 없어요.
❌ 현재 주장하지 않음정확한 위험 판정, 보증금 보호, 사기 예방 보장공개 자료와 제한 표본으로 보장할 근거가 없어요.
🔄 검증보증금 있는 월세까지 확장인접 대상일 가능성은 있지만 세부 확인 니즈와 규모를 확인하지 못했어요.

출처

서비스 설계의 핵심 정리를 한눈에 봐요

문서가 쌓여도 전체가 보이게, 밸류 체인·유저 여정·화면·핵심 로직·데이터 관계를 문서에서 바로 지도로 그려요. 오른쪽에서 칩을 눌러 직접 바꿔 보세요.

다섯 가지 지도

핀을 찍어 바로 고치고 이야기해요

서비스 설계의 핵심 정리에서 고칠 자리를 누르고 한 줄 남기면 돼요. 여러 곳에 달아 한 번에 코치에게 보내면, 코치가 그 자리를 짚어 문서를 고치거나 왜 그렇게 정했는지 같이 이야기해요.

고칠 자리에 한 줄

매 세션마다 자동으로 재귀점검, 누락/빈틈이 0건이 될 때까지

설계 문서와 개발 설계, 코드가 정합하는지 알아서 점검해줘요. 한 번 고치고 끝내지 않고, 새 빈틈이 두 번 연속 나오지 않을 때까지 다시 봐요. 코드까지 보는 건 AI 도구에 연결해 만들 때예요. 오른쪽은 데모 프로젝트가 실제로 남긴 점검 기록이에요.

phase6-점검로그.mdPhase 6

Phase 6 · 종합 점검 기록

검증 대상은 처음 전세계약을 하는 직장인이 가계약금 송금 전 휴대전화로 매물을 확인하는 흐름이에요. 실제 사용자 행동, 실제 자료 제공 가능성, 법률·기기 검증을 완료한 것으로 보지 않아요.

Cycle 1~11의 상세 기록은 이 문서의 이전 버전에 보존돼요. 아래에는 Cycle 12부터 이어지는 기록을 정리해요.

이전 점검 요약 · Cycle 1~11

  • Cycle 1~4에서 상태 표현 충돌을 고치고 UX·수익·개발 전제를 점검했어요.
  • Cycle 5~9에서 결과의 집 전체 상태 오해, 공유 미리보기·주소 초기화, 외부 링크 보안, 두 30초 시간의 구분, 시안과 실제 기능의 차이를 보완했어요.
  • Cycle 10에서 화면 진입이나 일반 미확인을 성공으로 세지 않도록 첫 행동 결과의 기준을 엄격히 했어요.
  • Cycle 11에서 건물 자료를 세대 사실로 확장하지 않도록 자료 범위 표시·주소 대응 규칙을 추가하고, 동·호수는 필요성과 개인정보·보안 검토 전 필수로 받지 않게 했어요.
  • 실제 자료원·권한·최신성·주소 정확도·법률·개인정보·접근성·현장 성능·비용은 계속 미검증이에요.

사이클 12 · 전체 점검 결과 · 2026-10-10

점검 범위와 방법

최신 여섯 정본, project-lens.md, 선택·비교 HTML 시안, 페르소나 조사와 여정 시뮬레이션을 대조했어요. R1~R6과 표준 27축을 모두 살폈어요. 이번에는 출처와 기준일을 표시해도 그 자료가 계약 판단 시점에 여전히 유효한지 알 수 없는 위험을 중점적으로 봤어요. 시안을 실제 브라우저·기기에서 실행하거나 외부 자료원·전문가·이용자 검증을 하지는 않았어요.

R1~R6

  • R1 · 페르소나: 급한 초보 세입자가 출처와 날짜가 적힌 자료를 현재 유효한 사실로 받아들이면 보증금 송금 판단에 직접 영향을 줄 수 있어요. 최신성 기준을 모르면 결과를 확인 완료로 세지 않도록 해야 해요.
  • R2 · UX·신뢰: 날짜 표기만으로는 갱신 지연, 기준일의 의미, 정정·소급 반영, 정보 자체의 빠른 변화를 알 수 없어요. UX에는 출처별 갱신 주기·기준일 의미·정정 방식과 이용자 판단 시점을 확인해 최신성 기준을 정하고, 기준이 없거나 벗어나면 최신 사실로 안내하지 않는 규칙이 반영돼 있어요. 이 기준이 검증되지 않은 동안에는 사실 확인 상태로 올리지 않아요.
  • R3 · 수익: 필수 확인 무료와 유료 후보의 경계는 변하지 않아요. 가격·지불 의사·변동비는 여전히 미검증이에요.
  • R4 · 개발 현실성: 실제 자료 제공자의 갱신 주기·지연·정정 방식과 필드별 변화 특성은 확인되지 않았어요. 공급자와 자료 기준을 검증하기 전 집별 정보 제공은 출시 차단 사항이에요.
  • R5 · 문서 정합: UX설계.md의 최신성 기준과 와이어프레임.md의 출처·기준 시점·미확인 처리 원칙은 같은 뜻이에요. 설계문서.md와 디자인 시스템은 출처·자료 시점을 요구하지만 UX보다 느슨한 최소 조건으로 적혀 있어 모순은 아니에요. 실제 서비스에서는 UX의 더 엄격한 조건을 따라야 해요.
  • R6 · 디자인: 근거 가까이에 출처와 시점을 두는 차분한 방향은 유지돼요. 날짜·문구의 작은 HTML 배치 조정은 영향이 낮아 사용자의 요청대로 고치지 않고 기록만 남겨요. 실제 가독성은 기기 검증 전이에요.

표준 27축 점검

축근거와 판단
1 일반링크·주소·조건·결과 흐름은 정해졌지만 실제 조회는 구현되지 않았어요.
2 엣지기준일 누락·자료 지연·정정은 미확인 처리 규칙으로 다뤄요. 실제 자료별 판별은 미구현이에요.
3 아웃라이어복수 필지·다가구·공동명의의 자료 적용은 미정이에요.
4 시간출처별 최신성 기준을 요구하지만 공급자 기준과 실제 지연은 검증되지 않았어요.
5 규모조회량·비용·공급자 한도는 미정이에요.
6 실패최신성 기준 불명확·초과 시 최신 사실로 표시하지 않아요. 실제 실패 처리는 구현 전이에요.
7 신뢰날짜만으로 최신성을 보장하지 않는다는 규칙이 있어요. 실제 정확도는 미검증이에요.
8 유저 유형초보 세입자 흐름은 반영됐지만 월세·접근성 사용자는 시험 전이에요.
9 인지출처·기준 시점·확인 불가를 가까이 표시해요. 이용자 이해는 미측정이에요.
10 도메인집 전체 안전·계약 판단을 대신하지 않아요. 실제 권리 정보는 전문가 검토 전이에요.
11 가치 전달근거와 실행 가능한 다음 행동이 없으면 성공으로 세지 않아요. 실제 효용은 미검증이에요.
12 진화자료원별 기준 변경·버전 관리 절차는 미정이에요.
13 품질 퇴화최신성 이탈·정정 감시와 운영 책임은 미정이에요.
14 법적데이터 이용권·표현의 법률 검토는 끝나지 않았어요.
15 모델 행동자료가 오래됐거나 기준이 불명확하면 사실로 단정하지 않는 설계예요. 자동 통제는 미정이에요.
16 비즈니스무료 기본과 유료 후보는 일치해요. 원가·구매 의사는 미검증이에요.
17 문서 생태계UX와 와이어프레임은 최신성 처리 의미를 공유해요.
18 운영자료 갱신·정정·장애 책임자와 절차는 미정이에요.
19 의존성자료 공급자의 기준일·갱신·정정 정보에 의존해요. 공급자는 미정이에요.
20 관측최신성 기준 이탈을 계측할 이벤트·운영 기준은 미정이에요.
21 전환오래된 결과의 재조회·외부 사이트 왕복은 실기기 시험 전이에요.
22 심리오래된 자료의 잘못된 안심을 막는 방향이에요. 이용자 반응은 미검증이에요.
23 학습자료 기준 시점을 통해 한계를 알리는 방향이에요. 학습 효과는 측정 전이에요.
24 핸드오프 수신공유에도 출처·기준 시점·미확인 의미를 유지해야 해요. 공유 구현은 미검증이에요.
25 메타시스템기존 안전 보증 금지·자료 범위 규칙과 함께 적용돼요.
26 미시 시간조회 시각과 원자료 기준 시점을 구분해요. 실제 갱신 경합은 미정이에요.
27 도구 생태계공식 사이트·매물 앱·공유 조합은 실기기에서 시험하지 않았어요.

사이클 12 발견과 처리

  1. 주요 · 날짜가 있는 오래된 자료가 현재 유효한 사실처럼 읽힐 수 있어요. UX와 와이어프레임의 최신성 규칙을 보강해 출처별 갱신 주기, 기준일 의미, 지연·정정 방식과 판단 시점을 확인한 뒤 기준을 정하도록 했어요. 공통 만료 기간은 임의로 만들지 않아요. 기준을 정당화할 수 없거나 자료가 벗어나면 최신 사실로 취급하지 않고 미확인 또는 추가 확인으로 낮추며, 현재 확인이 필요한 경우 검증된 공식 방법만 안내해요. 날짜나 조회 시각 표시는 최신성 보증이 아니에요.
  2. 미검증 · 공급자 조건: 출처별 기준은 실제 자료 공급자·전문가가 확인하기 전까지 미정이에요. 그 전에는 집별 자료 기능을 출시 가능한 것으로 보지 않아요.
  3. 로그만 기록 · 시안 세부: 출처·날짜 글씨 크기와 예시 화면의 미세한 배치·문구는 사용자의 요청에 따라 수정하지 않았어요. 실제 가독성·자료 유효성 시험도 하지 않았어요.

수정·반영 확인: UX설계.md, 와이어프레임.md. 해당 최신성 규칙은 이번 점검에서 확인했어요. 실제 데이터 공급자 기준을 검증한 것은 아니에요.

사이클 13 · 수정본 전체 재점검 결과 · 2026-10-10

점검 범위와 방법

Cycle 12 최신성 규칙이 반영된 여섯 정본, project-lens.md, 시안, 페르소나·시나리오 자료를 다시 대조했어요. R1~R6과 27축을 전부 확인했어요. 이번에는 계약 직전의 시간 압박에서 최신성 안내가 어떤 행동으로 이어지는지, 오류·범위 불일치·공유에서도 같은 경계가 유지되는지 살폈어요. 실제 출처·법률·기기·사용자 검증은 하지 않았어요.

R1~R6

  • R1 · 페르소나: 가계약 직전 현재성에 대한 잘못된 안심은 계약 판단에 큰 영향을 줘요. 자료 기준이 없으면 미확인으로 낮추고 검증된 공식 방법을 안내하는 규칙이 있어요.
  • R2 · UX·신뢰: 자료 기준 시점, 최신성 기준, 주소 적용 범위와 다음 행동을 함께 두며, 단순 결과 화면 진입은 성공이 아니에요. 오래된 자료를 현재 사실로 올리는 예외는 발견하지 못했어요.
  • R3 · 수익: 무료 필수 확인·미검증 단건 유료 후보·법률 검토 게이트가 정본 간 일치해요. 새 과금 위험은 발견하지 않았어요.
  • R4 · 개발 현실성: 출처별 최신성 메타데이터·주소 범위·권한을 확보하지 못하면 집별 결과를 내지 않는 게이트가 있어요. 구현 가능성이 입증된 것은 아니에요.
  • R5 · 문서 정합: UX·와이어프레임의 최신성·범위·미확인 규칙에 충돌이 없어요. 설계문서·플랜의 제품 범위·가격·무료 제공도 일치해요.
  • R6 · 디자인: 항목별 상태와 출처·시점 가까운 배치가 디자인 의도에 맞아요. HTML의 작은 크기·간격 세부는 로그에만 남겼고 실제 가독성은 검증 전이에요.

27축 점검 · 각 항목의 근거

1 일반: 정상 흐름은 정의됐고 실제 조회는 없어요. 2 엣지: 링크·주소·기준일·자료 범위 실패를 미확인으로 처리해요. 3 아웃라이어: 복합 권리 사례는 별도 판단하지 않아요. 4 시간: 소스별 최신성 기준은 있으나 공급자 검증 전이에요. 5 규모: 처리량·비용은 미정이에요. 6 실패: 지연·누락·마감 뒤 결과 고정이 정의돼 있어요. 7 신뢰: 안전 보증과 날짜만의 최신성 주장은 금지돼요. 8 유저 유형: 초보 세입자 중심이며 월세·접근성 시험은 없어요. 9 인지: 자료 범위·시점·다음 행동을 가까이 보여줘요. 10 도메인: 계약 판단을 대신하지 않아요. 11 가치 전달: 구체적 행동이 없으면 30초 통과가 아니에요. 12 진화: 기준 변경 절차는 미정이에요. 13 품질 퇴화: 자료 품질 감시는 운영 설계 전이에요. 14 법적: 권리·개인정보 검토는 미완료예요. 15 모델 행동: 확인 안 된 사실을 만들지 않는 원칙이 있어요. 16 비즈니스: 원가·지불 의사는 미검증이에요. 17 문서 생태계: 최신성 기준을 UX와 와이어프레임에서 맞췄어요. 18 운영: 민원·정정 책임은 미정이에요. 19 의존성: 외부 출처·공식 경로에 의존해요. 20 관측: 시간·최신성 계측은 미정이에요. 21 전환: 외부 확인 후 복귀는 시험 전이에요. 22 심리: 확인 불가를 위험 판정으로 바꾸지 않아요. 23 학습: 공식 확인을 돕지만 학습 효과는 미검증이에요. 24 핸드오프: 공유에도 자료 한계를 유지해야 해요. 25 메타시스템: 앞선 주소·안전 경계와 맞아요. 26 미시 시간: 조회 시각과 원자료 기준 시점을 구분해요. 27 도구 생태계: 앱·브라우저·공유 연동은 미시험이에요.

사이클 13 결론

새로운 이용자 판단상 결함은 0건이에요. 출처 권한·실제 갱신 특성·정확도·현장 발견·접근성·비용은 여전히 미검증 전제이지만, 이를 검증된 사실로 주장하지 않고 출시 차단 또는 미확인으로 다루고 있어 설계 결함으로 새로 분류하지 않았어요. 규칙에 따라 더 넓고 깊은 강제 추가 점검을 1회 진행해요.

작은 HTML 배치·문구 세부는 바꾸지 않고 로그에만 남겼어요.

사이클 14 · 강제 추가 전체 점검 결과 · 2026-10-10

점검 범위와 방법

연속 0건 조건을 확인하기 위한 강제 추가 점검이에요. 여섯 정본과 최신성 수정, project-lens.md, 선택·비교 시안, 페르소나 조사·시나리오 리포트를 다시 대조했어요. 이번에는 자료가 기준을 통과한 뒤 계약 판단까지 시간이 더 흐르는 경우, 범위가 다른 자료의 공유·외부 확인, 오래된 자료가 새 매물에 재사용되는 경우를 넓게 재생했어요. 실제 원자료나 제품 구현·사용자 행동을 검증한 것은 아니에요.

R1~R6

  • R1 · 페르소나: 이용자가 결과를 계약·송금 시점까지 유효하다고 오해할 위험을 살폈어요. 출처 기준 시점 표시, 최신성 기준, 현재 확인이 필요할 때 공식 경로 안내가 정의돼 있고 지속 유효성을 보장하지 않아요. 새 결함은 찾지 못했어요.
  • R2 · UX·신뢰: 오래된·범위 불일치·미확인 자료가 확정 사실이나 집 전체 판정으로 바뀌지 않아요. 마감 뒤 자료를 섞지 않는 규칙도 유지돼요. 새 결함은 찾지 못했어요.
  • R3 · 수익: 필수 확인은 무료이며 결제·업로드는 검토 전 비활성이라는 점이 정합해요. 새 결함은 찾지 못했어요.
  • R4 · 개발 현실성: 공급자 메타데이터·주소 범위·권한·최신성 기준이 없으면 집별 사실을 내지 않는 게이트가 있어요. 출시 가능성을 검증한 것은 아니에요. 새 설계 결함은 찾지 못했어요.
  • R5 · 문서 정합: UX·와이어프레임의 출처·기준 시점·범위·미확인 규칙이 일치하고, 변경이 가격·사용자 범위와 충돌하지 않아요. 새 충돌은 0건이에요.
  • R6 · 디자인: 집 전체 신호등 없이 항목별 상태·근거를 보여주는 방향이 차분함·명확함과 맞아요. HTML 세부는 요청대로 기록만 했어요. 새 주요 디자인 결함은 발견하지 않았어요.

27축 추가 스캔 · 근거

1 일반: 세 화면 흐름은 유지돼요. 2 엣지: 주소·범위·기준일 불명확 시 사실을 만들지 않아요. 3 아웃라이어: 복합 권리 판단은 하지 않아요. 4 시간: 계약 시점까지 유효하다고 보장하지 않고 기준을 적용해요. 5 규모: 실제 부하·비용은 미측정이에요. 6 실패: 마감 뒤 결과를 고정해요. 7 신뢰: 자료 확인은 집 안전 보증이 아니에요. 8 유저 유형: 초보자 중심이며 다양한 사용성은 미시험이에요. 9 인지: 기준일·조회 시각·범위를 구분해요. 10 도메인: 법률 판단은 전문가 검토 전이에요. 11 가치 전달: 검증 가능한 다음 행동이 있어야 통과예요. 12 진화: 새 출처 기준 승인·변경 관리가 미정이에요. 13 품질 퇴화: 실제 모니터링 운영은 미정이에요. 14 법적: 자료권·개인정보 검토가 남아요. 15 모델 행동: 예시·미확인을 실자료 사실로 바꾸지 않아요. 16 비즈니스: 가격·마진은 미검증이에요. 17 문서 생태계: 공유에서도 한계를 유지하도록 설계돼요. 18 운영: 오류 정정 책임은 미정이에요. 19 의존성: 자료 공급자·공식 사이트에 의존해요. 20 관측: 실측 이벤트는 미정이에요. 21 전환: 외부 사이트 왕복·세션 복귀는 미시험이에요. 22 심리: 공포·안심을 과장하는 종합 판정이 없어요. 23 학습: 자율 확인을 돕지만 효과는 미검증이에요. 24 핸드오프: 결과 공유에 출처·행동을 포함해요. 25 메타시스템: 앞 단계 제품 경계와 맞아요. 26 미시 시간: 늦은 자료가 확정 결과를 변경하지 않아요. 27 도구 생태계: 실제 앱·브라우저·기기 공유는 미시험이에요.

사이클 14 결론

발견 문제 0건이에요. 미검증 출시 전제는 남아 있지만 문서에서 검증된 사실처럼 주장하지 않고 차단 조건으로 구분하고 있어요. HTML 시안의 작은 문구·간격·장식 세부와 실기기 검사는 사용자 요청대로 로그에만 남기고 수정하지 않았어요.

Phase 6 결과

Cycle 13과 강제 추가 Cycle 14에서 연속 0건이에요. 실제 자료원·권한·최신성·정확도·주소 범위·법률·개인정보·기기 검증은 완료된 것이 아니며, 집별 정보 기능의 출시 승인을 뜻하지 않아요. 사용자는 연속 0건이면 Phase 7로 이동하라고 요청했어요. 다음 단계는 Phase 7 · 시장에 알릴 사람·메시지·채널 설계예요.

서비스 설계 후, 개발 설계의 순서를 3중 근거와 함께 먼저 제안해줘요.

후보를 먼저 늘어놓고, 1순위와 그 근거, 나머지를 뒤로 미룬 이유까지 함께 말해 줘요. 무엇부터 만들어야 할지 몰라도 고르기만 하면 돼요.

PurplePrint 코치Phase 8 개발 설계

제가 추천하는 방향은 실제 집 정보를 조회하지 않는 검증용 웹부터 만드는 것이에요. 비교하면 다음 세 가지예요.

후보 셋
  1. 검증용 웹부터 만들기. 검색에 읽히는 안내 페이지와 예시 자료로 화면 흐름을 시험해요. 지금 자료 권한과 최신성 기준이 미정이라 이쪽을 권해요.1순위
  2. 이용자의 실제 주소와 보증금을 서버에 받아 저장하기. 저장·개인정보·보안 결정을 먼저 해야 해서 지금은 권하지 않아요.뺀 이유
  3. 외부 자료원에 바로 연결해 실제 집을 확인하기. 자료 권한·주소 범위·최신성 기준이 검증되지 않아 지금은 열 수 없어요.뺀 이유

1번으로 가면 Next.js와 TypeScript로 검색에 읽히는 웹 화면을 만들고, Vercel 같은 호스팅에 올리는 구성이 적절해요.기술 구성 첫 단계에는 데이터베이스·로그인·결제·외부 자료 연결을 두지 않고, 설명용 예시만 사용해요. 제품 안에서 AI가 집을 분석하게 하지 않아요. AI 개발 도구는 구현 보조로만 써요.

공개 데모(전세 안심 체크)에서 코치가 실제로 한 답이에요

과업정의서로 진행 현황과 백로그까지 알아서 챙겨요

설계를 마치면 무엇을 어떤 순서로 만들고 언제 끝났다고 볼지 과업정의서로 정리해요. 만들기 시작하면 코치가 진행률과 진행 현황을 계속 갱신하고, 새로 생긴 할 일은 백로그에 모았다가 과업으로 올려요.

과업정의서.mdPhase 9

과업정의서

상태: 실행 관리 문서 초안. 저장소·담당자·실행 환경을 확인하지 못해 모든 과업은 예정이에요. 이 문서의 완료율은 0%예요. 완료는 정의된 완료 조건을 증거로 확인한 경우에만 표시해요.

진행률 대시보드

진행률은 과업별 진척도 가중평균이에요. 완료 100%, 진행 중은 증거가 확인된 실제 비율, 예정은 0%, 보류는 전체 산정에서 제외해요. 현재 완료·진행 중 과업은 없어요.

영역진행률요약
전체0%저장소와 구현 담당자를 확인하지 못해 착수 전이에요.
P1 · 정적 검증용 웹0%합성 데이터만 쓰는 모바일 웹. 실제 주소·자료 조회는 범위 밖이에요.
P2 · 실제 자료 연결 준비0%승인 전 차단 상태예요. 공급자 권한·주소 범위·최신성·개인정보·법률·보안 검토를 통과해야만 별도 착수해요.

범위 앵커

Phase 1 · 정적 검증용 웹

  • 목표: 실제 집 정보를 받지 않는 시안으로 처음 전세계약을 하는 사람이 화면 흐름과 다음 행동을 이해하는지 살펴봐요.
  • Wedge · 승리 논리: 실제 위험 점수를 만들지 않고도 가계약 직전의 이용자가 어디서 시작하고 무엇을 이해해야 하는지 시험할 수 있어요. 기존 서비스 대비 우위가 확인됐다는 뜻은 아니에요.
  • North Star: 실제 서비스의 핵심 지표는 유효한 실제 매물 확인 완료예요. Phase 1에는 실제 자료가 없으므로 이 수치는 측정하지 않아요. 임시 사용성 지표는 참여자가 합성 시나리오에서 시안의 한계를 이해하고, 안내된 다음 공식 확인 행동을 자기 말로 설명할 수 있는지예요. 이 신호는 실서비스 WTU 증거로 세지 않아요.
  • 범위 안: 정적 안내, 모바일 시안 흐름, 설명용 합성 결과, 시맨틱 HTML과 기본 검색 메타 정보, 키보드·화면 크기 확인.
  • 범위 밖: 실제 매물 링크 처리, 실제 주소·동호수·보증금 입력이나 저장, 외부 자료/API, 데이터베이스, 로그인, 결제, 문서 업로드, 분석 이벤트, 제품용 AI·LLM, 집의 안전·위험 판정, 공개 실서비스.

Phase 2 · 실제 자료 연결 준비, 승인 전 보류

  • 목표: 실제 자료를 연결할 수 있는지 권한·기술·품질·법률·개인정보·보안·운영 증거로 판단해요.
  • Wedge · 승리 논리: 확인 가능한 자료와 모르는 점, 다음 공식 행동을 구분하는 서비스 경계를 지켜요. 외부 서비스보다 우월하다는 주장은 하지 않아요.
  • North Star: 관문 통과 뒤 제한 시험에서 유효한 실제 매물 확인 완료를 측정하는 것을 후보로 둬요. 아직 실제 시험 승인이나 계측은 없어요.
  • 범위 안: 공급자 조사, 서면 이용 권한 확인, 건물·세대 주소 적용 범위, 최신성·정정 방식 확인, 보안·개인정보 검토와 승인 기록 준비.
  • 범위 밖: 모든 필수 관문과 담당자의 명시적 승인 전 실제 주소 조회·집별 결과·상업적 자료 재배포·공개 출시.

과업 표

모든 미완료 상태는 예정이에요. 담당자를 임의로 지정하지 않았어요. G-1은 Phase 2의 실제 자료 기능을 켜기 전 필수 출시 관문이에요.

ID과업모듈담당상태DoD의존참조
P1-W1-1저장소·브랜치·기존 자산·배포 조건 확인개발 환경미지정⬜ 예정실제 저장소와 기존 파일을 확인하고, 새 코드가 1단계 범위만 포함하는 기준선을 기록해요. 이 호스트에서 확인·생성하지 않았어요.없음핸드오프.md §7
P1-W1-2정적 모바일 시안 뼈대 구성화면미지정⬜ 예정시작·예시 입력·합성 결과 화면을 모바일에서 볼 수 있고, 실제 조회가 아닌 점을 화면 가까이에 표시해요.P1-W1-1UX설계.md §4, 와이어프레임.md §5, 디자인시스템.md §5
P1-W1-3합성 안내·결과 상태 구현콘텐츠·화면미지정⬜ 예정합성 데이터 외 입력·자료 요청 없이 항목별 상태·범위·예시 출처·다음 공식 행동의 표현 흐름을 살펴볼 수 있어요. 결과가 실제 집의 위험이나 사실처럼 표시되지 않아요.P1-W1-2설계문서.md §3, 와이어프레임.md §5.2.3
P1-W1-4정적 검색 기본과 접근성 확인웹 기반미지정⬜ 예정승인된 정적 페이지에 제목·설명·OG·시맨틱 구조를 넣고, 사이트맵·robots·canonical 여부를 공개 범위에 맞춰 확인해요. 키보드 조작, 글자 확대, 작은 화면에서 핵심 흐름을 점검하고 결과를 기록해요.P1-W1-2마케팅전략.md §7.2, 디자인시스템.md §5.1.5, 핸드오프.md §7
P1-W1-51단계 차단·비포함 시험보안·품질미지정⬜ 예정빌드와 네트워크 검사에서 실제 주소·매물 링크·외부 자료 요청·저장·분석·로그인·결제·제품 LLM·비밀 키가 없음을 증거로 남겨요. 하나라도 있으면 배포를 막아요.P1-W1-2, P1-W1-3설계문서.md §8.2.1, §8.7.1, 핸드오프.md §6
P1-W2-1합성 시나리오 사용성 확인조사·검증미지정⬜ 예정참여자에게 시안 한계와 합성 데이터임을 알리고, 안내를 이해하고 다음 공식 확인 행동을 설명하는지 관찰해요. 실제 매물 확인·시장 수요·진단 정확도·결제 의사 증거로 보고하지 않아요.P1-W1-2, P1-W1-3, P1-W1-5마케팅전략.md §7.0, §7.7, 설계문서.md §3.2
P1-W2-2Phase 1 범위 검토와 결과 기록제품·품질미지정⬜ 예정시안이 범위를 지켰는지, 발견한 사용성 문제와 다음 수정이 무엇인지 근거와 함께 정리해요. 이 문서만으로 공개 운영이나 Phase 2 연결을 승인하지 않아요.P1-W1-4, P1-W1-5, P1-W2-1핸드오프.md §7, 과업정의서.md Phase 1 DoD
P2-W1-1자료원별 필드·갱신·주소 범위 조사데이터·조사미지정⬜ 예정, 승인 전 조사만공식 명세와 실제 공급자 확인을 통해 자료 항목, 기준 시각 의미, 갱신·지연·정정·소급 반영, 건물·세대 범위의 불확실성을 기록해요. 조사만으로 API 사용 권한을 주장하지 않아요.P1-W2-2설계문서.md §8.3, §8.4
P2-W1-2공급자 이용 권한·비용·SLA 서면 확인자료 권한·운영미지정⬜ 예정, 승인 전 차단자동 조회, 상업적 표시, 저장·캐시·재배포 권한과 호출 한도·비용·SLA·장애·정정 통보 조건을 공급자 증거로 기록해요. 권한이 없거나 불명확한 자료는 연결하지 않아요.P2-W1-1설계문서.md §8.3, §8.4
P2-W1-3주소·세대 범위와 최신성 시험주소·데이터 품질미지정⬜ 예정, 승인 전 차단대표·예외 주소 사례에서 조회 주소와 자료의 건물/세대 범위를 확인하고 출처별 최신성 기준을 승인된 근거로 작성해요. 오매칭·미확인 기준·기준 초과는 집별 사실로 통과하지 않아요.P2-W1-1, P2-W1-2설계문서.md §8.4, §8.5, UX설계.md §4.0.2
P2-W1-4개인정보·법률·보안·삭제 설계 검토개인정보·법률·보안미지정⬜ 예정, 전문가 검토 필요수집 최소화, 처리 고지·근거, 보관·삭제·위탁, 서버 링크 보안·SSRF·키·로그·접근권한을 적격 검토자가 확인하고 증거를 남겨요. 담당자·보관 기한 미정 상태로 저장 기능을 열지 않아요.P2-W1-1설계문서.md §8.5.1, §8.6
P2-W1-5결과 근거·정정 전파·세션·응답 시험개발·품질미지정⬜ 예정, 승인 전 차단결과마다 자료 버전·범위·최신성 정책·표시 규칙을 추적해요. 원자료 정정 시 영향을 받은 결과가 재평가·무효화돼요. 주소 변경 뒤 늦은 응답이 버려지고 삭제 요청이 연결 자료·파생 결과에 전파되는 시험 증거를 기록해요.P2-W1-3, P2-W1-4설계문서.md §8.5.1, §8.5.2, §8.6.2, §8.7.1
P2-W1-6공급자 변화·승인 게이트·운영 책임 확인운영·출시 관리미지정⬜ 예정, 승인 전 차단공급자 규격·권한 재확인 주기, 차단·복구 기준, 담당자, 증거, 실패 시 범위 제한을 기록해요. ReleaseGateRecord 필수 게이트가 모두 통과되고 책임자의 제한 시험 승인이 기록되기 전 연결은 꺼져 있어요.P2-W1-2, P2-W1-3, P2-W1-4, P2-W1-5설계문서.md §8.5, §8.7, §8.8
G-1실제 자료 연결 제한 시험 출시 관문승인 게이트미지정⬜ 예정, 차단P2-W1-1~P2-W1-6 필수 증거와 개인정보·법률·보안 검토가 모두 통과하고, 주소·최신성·정정·삭제·늦은 응답 시험에서 알려진 범위/최신성 불일치를 사실로 노출하는 결함이 0건이며, 책임자의 명시적 승인 기록이 있어야 해요. 미완료·실패·담당자 미지정이면 실제 집별 조회를 열지 않아요.P2-W1-1~P2-W1-6설계문서.md §8.7.1, §8.8

백로그

  • 검색 수요·CAC·전환을 실제 데이터로 조사해요. 지금은 숫자와 전환율을 확인하지 못했어요.
  • 9,900원 용어 설명 가설은 법률·개인정보·비용·결제 의향 검증 전 보류해요.
  • 시안 사용성 시험 뒤 실제 집별 확인을 제한 시험할지 다시 결정해요. 이 파일은 자동 승인이 아니에요.
  • 최종 호스팅·도메인·저장소·담당자·자료 공급자·보관 기간·실행 비용은 결정 전이에요.
  • 반복 사용·공유 유도·계약 후 알림 기능은 사용 빈도와 필요가 검증되기 전 과업으로 승격하지 않아요.

프로젝트 작업의 우선순위를 3중 근거와 함께 먼저 제안해줘요.

무엇부터 할지 묻기 전에 코치가 먼저 1순위와 그 근거, 미룰 일과 그 이유를 말해 줘요. 만드는 동안에도 세션을 열면 진행 현황과 다음 할 일부터 짚어요.

PurplePrint 코치Phase 9 핸드오프 초안

저는 1단계 검증용 웹만 개발 대상으로 넘기고, 실제 집 정보 연결은 승인 관문을 통과한 뒤 별도 결정하는 안을 권해요.1순위 이미 선택한 구현 범위와 맞고, 자료 권한·최신성·주소 범위가 검증되지 않은 상태에서 실제 집별 정보를 제공하는 일을 막을 수 있어요.근거 실제 자료 연결을 지금 개발 범위에 넣는 안은 필요한 권한과 검증이 아직 없어서 권하지 않아요.뺀 이유

공개 데모(전세 안심 체크)에서 코치가 실제로 한 답이에요

어려운 세션 기억, 컨텍스트 관리도 퍼플프린트 내장 하네스가 다 알아서 해줘요.

CLAUDE.md·AGENTS.md 같은 작업 규칙 파일을 직접 쓰고 고칠 필요가 없어요. 코치가 세션마다 한 장 요약과 과업정의서를 먼저 읽고 이어가고, 대화가 길어지면 정리해서 새 세션으로 넘겨요.

직접 안 해도 되는 것
  • 세션 기억 관리
  • 컨텍스트 창 관리
  • CLAUDE.md · AGENTS.md 작성
  • 작업 규칙 갱신
project-lens.md
  • 현재 프로젝트: 전세 안심 체크
  • 1차 사용자: 처음 전세계약을 하는 20대 후반~30대 초반 직장인. 부동산 지식이 적고 가계약금을 서두르는 상황에서 무엇을 확인할지 몰라 중개사의 설명에 기대기 쉬움.
  • 핵심 문제: 마음에 든 집을 놓칠까 급해진 순간, 보증금 송금 전에 위험 신호와 믿을 만한 확인 방법을 몰라 충분히 판단하지 못함.
  • 핵심 가치 가설: 매물 링크를 붙여넣고 실패 시 주소 입력. 계약 형태와 보증금을 확인한 뒤, 출처와 원자료 기준 시점, 출처별 최신성 기준, 자료가 적용되는 건물/세대 범위가 검증되는 집별 정보 중 먼저 확인할 점과 공식 확인 방법을 모바일에서 안내함. 날짜나 조회 시각만으로 최신성을 보증하지 않으며, 기준이 없거나 검증되지 않았거나 자료가 기준을 벗어나면 현재 사실로 안내하지 않음. 자료 범위가 주소와 맞지 않으면 더 좁은 범위의 사실을 추정하지 않음.
  • UX 기준: 모바일 우선, 시작 A + 결과 A. 첫 화면에서 링크 입력, 결과에서 먼저 할 행동 하나. 전체 현장 체감 목표는 링크 확인 시작부터 주소 확인·조건 입력을 거쳐 출처가 있는 확인 내용과 구체적인 다음 행동이 보이는 첫 행동 결과까지 30초 이내이며 검증 전 약속하지 않음. 단순 화면 진입, 로딩 종료, 일반 미확인 문구 또는 시안 예시는 통과로 세지 않음. 자료 조회 마감은 주소·조건을 확인한 뒤 마지막 “확인 시작하기”를 누른 때부터 최대 30초로 별도 적용함. 입력 중에는 조회 시계가 시작되지 않음. 확인 상태는 항목별 텍스트 중심이며 결과 상단에 집 전체 상태처럼 읽힐 종합 신호등을 두지 않음. 결과에는 자료가 건물 기준인지 세대 기준인지 출처가 뒷받침하는 범위로 표시함. 건물 자료를 세대별 사실처럼 말하지 않으며 주소/자료 범위가 대응하지 않으면 집별 사실을 내지 않고 미확인 처리함. 조회 마감 뒤 미도착 자료는 “이번 확인에서 확인하지 못했어요”로 확정하고 늦은 자료를 기존 결과에 섞지 않음. 주소 공유는 실제 공유될 항목·상태·자료 범위·다음 행동·출처·기준 시점을 미리보기에서 확인하고 기본 숨김, 직접 입력 후 최종 확인함.
  • 디자인 의도: 차분함·신뢰감·명확함. 겁주지 않고 확인된 내용과 다음 행동을 보여줌. 텍스트 이름만 사용하고 체크·방패 같은 안전 인증 표식은 배제. 결과 화면은 먼저 할 행동과 해당 항목의 상태·근거를 함께 보여주고 집 전체를 요약 판정하지 않음.
  • 법률·개인정보 게이트: 등기부 업로드·유료 용어 설명은 검토 전 비활성. 특정 집의 권리 위험·계약 여부는 대신 판단하지 않음. 자료 범위·출처·원자료 기준 시점·출처별 최신성 기준이 불명확하면 집별 사실을 추측하지 않음. 최신성 기준은 공급자별 갱신·지연·정정 방식과 계약 판단 시점을 확인한 뒤 출처·항목별로 정하며, 임의의 공통 만료 기간은 만들지 않음. 세대 주소는 검증된 자료가 꼭 필요로 하는 경우에만 개인정보·보안 검토 후 수집하며 기본 필수값이 아님. 실제 공유는 주소·동·호수·식별 링크의 이미지·제목·미리보기·대체 텍스트 노출 검증 전 제공하지 않음.
  • 링크·보안 게이트: 사용자가 준 링크는 신뢰할 수 없는 입력으로 취급. 허용된 호스트와 안전한 이동 경로를 확인할 때만 다루고 사설망·로컬 주소·허용되지 않은 이동·권한 우회는 금지. 기술·보안·법률 검토와 구현 확인 전 실제 링크 조회는 제공하지 않으며 실패 시 주소 입력으로 안내.
  • 경쟁 맥락: HUG 안심전세, KB부동산, 경기 안심 부동산 등 주소 기반 확인·진단이 있어 링크 입력이나 쉬운 설명만으로 차별성을 주장하지 않음. 현장 순간의 빠른 행동 안내가 유효한지는 검증 가설.
  • 경쟁 UX 참고: HUG 안심전세 첫 화면. 디자인 비교로 HUG·토스·서울주거포털의 휴대폰 첫 화면을 관찰. 외부 문구·이미지·로고는 복사하지 않음.
  • Phase 5 산출물: 디자인시스템.md, 와이어프레임.md 확정. 비교·선택 HTML은 docs/prototype/ 아래, 여정 시뮬레이션 리포트는 docs/scenario/ 아래.
  • Phase 6: Cycle 114 완료. Cycle 511에서 결과 전체 상태 오해, 공유 전 확인 부족, 링크 보안 경계, 현장 시간 범위, 30초 통과 기준, 건물/세대 자료 범위 불일치를 보정함. Cycle 12에서 출처·날짜 표시만으로 최신성을 보장할 수 없음을 확인하고, 공급자별 갱신·지연·정정 방식과 계약 판단 시점을 검증해 기준을 정하기 전에는 현재 사실로 안내하지 않도록 UX·와이어프레임을 보완함. Cycle 13과 강제 추가 Cycle 14에서 이용자 판단에 큰 영향을 주는 새 설계 결함과 문서 충돌이 0건임을 확인함. 연속 0건 조건을 충족함.
  • Phase 7: 마케팅전략.md 확정. 실제 이용자 없는 출시 전 단계로 설정. 첫 검증 가설은 실제 매물 확인을 시작해 출처·최신성·주소 범위가 검증된 정보와 다음 행동까지 보는지 여부. 검색 질문형 콘텐츠, 허가받은 커뮤니티, 검토 통과 후 기관 접점을 채널 후보로 둠. 첫 30일 100 적격 방문 중 20 유효 확인 완료는 업계 기준이 아닌 계획 가설. 2026-10-10 경쟁 마케팅·GTM 리서치는 docs/research/marketing-20261010-jeonse.md, docs/research/gtm-20261010-jeonse.md에 저장. 검색량·CAC·채널 반응률·실제 이용 전환은 미확인.
  • Phase 8: 설계문서.md §8에 2026-10-10 DAR 결과 10건(높음 1, 중간 9)을 반영. 이용 여정·대안과 제품 책임 범위를 연결하고, 세션 상태·주소별 늦은 응답·자료 근거 묶음·정정 전파·삭제 전파·공급자 변화·시험 증거·승인 기록·단계별 배포 경계를 보강함. 전체 리포트 docs/review/PurplePrint-HyperReview-dar-0ae65140-0add-422f-a6f0-4af7656cc03a.md. DAR은 설계 문서 리뷰이며 실제 코드·공급자·법률·개인정보·보안·운영 검증이나 출시 승인이 아님.
  • Phase 9: 핸드오프.md와 과업정의서.md 확정. 핸드오프.md는 SSOT·1단계 정적 합성 웹 범위·2단계 승인 게이트·보안 경계·개발 체크리스트를 담음. 과업정의서.md는 실행 관리 SSOT이며 현재 전체 0%, 모든 과업 예정. 체크리스트에 미완료 항목이 있어 전체 개발 착수 게이트는 미통과. 1단계 정적 시안 범위만 개발자/AI에게 전달 가능, 실제 집별 자료 기능은 미승인. 다음 행동은 핸드오프와 과업정의서로 P1-W1-1 저장소·실행 환경 및 기존 자산 확인부터 시작하는 것. 이 웹 호스트에는 셸/git/IDE가 없어 저장소·원격·배포 확인·생성, dev-lens 작성, 코드베이스 스캔 문서층 생성은 하지 못함.
  • 남은 검증: 유입 경로, 매물 링크 호환·허용 범위, 주소 정밀도와 자료 범위 일치, 자료 공급권·정확도·최신성 기준·공식 경로, 세대 주소 수집의 필요성·적법성, 복수 필지·공동명의·다가구 사례, 월세 조건, 두 30초 목표의 실측, 공식 경로 복귀, 공유 개인정보·접근성, 법률·보안·운영 책임, 비용·지불 의사, 실제 API 공급자·호스팅·DB 여부·처리 계약.

구독 중인 AI 도구에서도 MCP로 쉽게 연동

설치 프롬프트를 AI 도구에 붙여 넣기만 하면 연결과 로그인은 AI가 알아서 해요. 다시 열고 "퍼플프린트 시작해줘"라고 말하면 바로 시작돼요. Claude Code·Codex·Cursor에서 같은 설계를 이어가요.

Claude Code~/dev
PurplePrint MCP를 Claude Code에 추가해줘.붙여 넣기만[붙여 넣은 설치 문구 · 9줄 더]
Bash(claude mcp add --transport http --scope user purpleprint https://app.purpleprint-ai.com/mcp)
Added HTTP MCP server purpleprint with URL: https://app.purpleprint-ai.com/mcp to user config
/mcp에서 purpleprint 로그인을 열었어요. 브라우저에서 로그인을 마쳐 주세요.
purpleprint · connected연결·로그인
이제 Claude Code를 다시 시작해 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 "퍼플프린트 시작해줘"라고 말해 주세요.
claude 다시 실행
퍼플프린트 시작해줘
purpleprint - pp_start (MCP)
환영해요!바로 시작
PurplePrint는 아이디어를 개발할 수 있는 구조화된 서비스 설계로 빈틈 없이 바꿔주는 AI 코치예요.
서비스 기획도, 개발 설계도 해본 적 없어도 괜찮아요. PP가 알아서 설계 문서를 정리하고 한 단계씩 꼼꼼히 이끌어가니까, 마음 편하게 같이 만들어봐요!
이 프로젝트를 뭐라고 부를까요? 이름을 정하면 전용 폴더를 만들어 산출물을 거기 정리해드려요.
재구성 화면 · 실제 설치 문구와 첫 답 문장 그대로

코어 엔진

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를 얼마나 잘 이끄는지, 다음 단계로 가려면 무엇을 연습하면 되는지 알려줘요.

실제 성장 리포트 보기 →

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

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

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

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

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

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

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

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

시작하기 전에 확인할 것

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

내 아이디어는 내 것이에요

AI 학습에 쓰지 않아요웹 코치와 Hyper-Review의 AI 처리는 모델 학습에 쓰지 않아요. 외부 AI 모델은 입력·출력을 보관하지 않는 무보관(Zero Data Retention) 경로로만 불러요.쓰는 AI 도구로 하면 내 컴퓨터에 남아요Claude Code·Cursor 같은 AI 도구에 연결해 쓰면, 코칭 대화와 설계 문서는 내 작업 폴더에만 있고 PurplePrint 서버로 오지 않아요.만든 설계는 내 것이에요코치와 만든 맥락문서·설계문서 같은 산출물의 권리는 이용자에게 있어요.지우면 바로 지워져요웹 코치에서 프로젝트를 지우면 대화와 설계 문서를 바로 지우고 공유 링크도 멈춰요.

개인정보 처리방침 전문 보기 →

Kits

서비스 설계, 개발 설계, 웹페이지, 앱 제작, 마케팅 콘텐츠 제작 시 쓰는 템플릿들.

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

클라이언트 운영 워크스페이스요청·피드백·과업·문서가 흩어진 서비스 사업을 하나의 양면 운영 공간으로 재설계합니다.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://app.purpleprint-ai.com/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 없이 진행 중'임을 유저에게 먼저 알린다. 그리고 연결 안내(https://www.purpleprint-ai.com/docs#connect)를 보여 주고, 유저가 원하면 연결까지 대신한다(연결 뒤 앱을 다시 열어야 도구가 보인다). 무관한 작업이면 무시한다." 마지막 단계(꼭 해야 해요): 설치·로그인이 끝나면 나에게 이렇게 알려줘. "이제 Claude Code를 다시 시작해 주세요. 터미널이면 지금 세션을 끝내고 claude를 새로 실행하고, VS Code·Cursor 확장이면 창 다시 로드, 데스크톱 앱이면 트레이까지 완전히 종료했다가 다시 열어 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 "퍼플프린트 시작해줘"라고 말해 주세요." 새 연결은 앱을 다시 열어야 잡히니까, 이 세션에서 바로 확인이 안 돼도 정상이야. 설치를 다시 하지 마.
Cursor · VS Code 설치 자연어 명령 · 올리면 원문 보기PurplePrint MCP를 이 에디터에 추가해줘. 서버 이름은 purpleprint, URL은 https://app.purpleprint-ai.com/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 없이 진행 중'임을 유저에게 먼저 알린다. 그리고 연결 안내(https://www.purpleprint-ai.com/docs#connect)를 보여 주고, 유저가 원하면 연결까지 대신한다(연결 뒤 앱을 다시 열어야 도구가 보인다). 무관한 작업이면 무시한다." 마지막 단계(꼭 해야 해요): 설치·로그인이 끝나면 나에게 이렇게 알려줘. "이제 에디터(Cursor·VS Code)를 완전히 종료했다가 다시 열어 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 새 채팅에서 "퍼플프린트 시작해줘"라고 말해 주세요." 새 연결은 앱을 다시 열어야 잡히니까, 이 세션에서 바로 확인이 안 돼도 정상이야. 설치를 다시 하지 마.
Codex 설치 자연어 명령 · 올리면 원문 보기PurplePrint MCP를 Codex에 추가해줘. 서버 이름은 purpleprint, URL은 https://app.purpleprint-ai.com/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 없이 진행 중'임을 유저에게 먼저 알린다. 그리고 연결 안내(https://www.purpleprint-ai.com/docs#connect)를 보여 주고, 유저가 원하면 연결까지 대신한다(연결 뒤 앱을 다시 열어야 도구가 보인다). 무관한 작업이면 무시한다." 마지막 단계(꼭 해야 해요): 설치·로그인이 끝나면 나에게 이렇게 알려줘. "이제 Codex를 다시 시작해 주세요. CLI면 지금 세션을 끝내고 새로 실행하고, VS Code 확장이면 창 다시 로드, ChatGPT 데스크톱 앱이면 트레이까지 완전히 종료했다가 다시 열어 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 새 스레드에서 "PurplePrint 시작해줘"라고 말해 주세요." 새 연결은 앱을 다시 열어야 잡히니까, 이 세션에서 바로 확인이 안 돼도 정상이야. 설치를 다시 하지 마.
Antigravity 설치 자연어 명령 · 올리면 원문 보기PurplePrint MCP를 Antigravity 전역 MCP로 추가해줘. 서버 이름은 purpleprint, URL은 https://app.purpleprint-ai.com/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 없이 진행 중'임을 유저에게 먼저 알린다. 그리고 연결 안내(https://www.purpleprint-ai.com/docs#connect)를 보여 주고, 유저가 원하면 연결까지 대신한다(연결 뒤 앱을 다시 열어야 도구가 보인다). 무관한 작업이면 무시한다." 마지막 단계(꼭 해야 해요): 설치·로그인이 끝나면 나에게 이렇게 알려줘. "이제 Antigravity를 완전히 종료했다가 다시 열어 주세요. 창만 닫으면 안 되고 완전히 종료했다가 다시 열어야 새 연결이 잡혀요. 다시 열면 "PurplePrint 시작해줘"라고 말해 주세요." 새 연결은 앱을 다시 열어야 잡히니까, 이 세션에서 바로 확인이 안 돼도 정상이야. 설치를 다시 하지 마.

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

가격

무료 체험

$0 14일

카드 등록 없음 · 끝나도 자동 결제 없음

  • 설계 코치: 웹에서는 문제 정의(0~2단계)까지 · 쓰는 AI 도구에 연결하면 전 단계
  • Hyper-Review 1회: 서비스 설계(39축) 또는 개발 설계(DAR) · 실패한 점검은 안 세요
  • 프로젝트 동시 2개
  • Kits · 빌더 성장 측정
14일 무료로 시작

베타 구독

$13 / 월

베타 가격 · 정가 $20

  • 설계 코치 전 단계: 웹과 쓰는 AI 도구 모두
  • Hyper-Review 월 10회: 서비스 설계(39축) · 개발 설계(DAR)
  • 프로젝트 동시 4개
  • Kits · 빌더 성장 측정
베타 구독

웹 코치는 두 플랜 모두 사용량 한도가 있고, 남은 양은 코치 화면에 보여요.

AI 처리는 무보관 경로로만 하고, 모델 학습에 쓰지 않아요. 처리방침 · 설치 상세 보기

FAQ

PURPLEPRINT, 무엇이 다른가요?

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

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

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

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

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

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

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

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

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

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

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

AI 도구(MCP)로 쓰면 코칭으로 만든 문서는 내 작업 폴더에 남고, 대화 내용은 PurplePrint 서버로 오지 않습니다. 웹 코치로 쓰면 이어 쓸 수 있도록 대화와 문서를 내 계정 저장소에 보관하고, 프로젝트를 지우면 바로 지웁니다. Hyper-Review를 실행하면 제출하거나 선택한 자료를 서버에서 분석하고 결과 리포트를 저장합니다. 진행 단계와 사용량은 내용 없이 따로 기록합니다.

내 아이디어가 AI 학습에 쓰이나요?

아니요. 웹 코치와 Hyper-Review의 AI 처리는 모델 학습에 쓰이지 않습니다. 외부 AI 모델은 입력과 출력을 보관하지 않는 무보관(Zero Data Retention) 경로로만 부릅니다. AI 도구(MCP)로 쓸 때 코칭 대화는 쓰는 AI 안에서 이뤄지고 PurplePrint 서버로 오지 않습니다. 만든 설계 산출물의 권리는 이용자에게 있습니다.

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

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

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

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

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

PurplePrint가 나에게 맞는지, 쓰는 AI에게 물어보세요

ChatGPT에 물어보기Claude에 물어보기Perplexity에 물어보기