3.3 KiB

Raw Blame History

회의 리뷰 요약 — Q1~Q7 확정 및 기획 문서 세트 검토용

이 회의의 목표: decision-log.md의 잠정 결정(Q1~Q7)을 실제로 확정하거나 뒤집는다. 그 외 문서(PRD, 기술설계 등)는 이 결정들 위에 이미 작성돼 있으므로, Q#이 뒤집히면 해당 문서도 같이 갱신해야 한다 — 회의 마지막에 담당자와 갱신 범위를 정한다.

지금까지 준비된 것 (한눈에)

문서	내용	상태
`decision-log.md`	Q1~Q7 잠정 결정 + 근거	이 회의에서 확정 대상
`vision.md`	문제/타깃/가치제안/성공지표	결정 반영 완료
`PRD.md`	v1 기능 명세, 유저 플로우, 엣지 케이스	결정 반영 완료
`tech-design.md`	아키텍처, 자율성 엔진, 투명성 구현	결정 반영 완료
`risk-log.md`	리스크 + 완화 상태	결정 반영 완료
`roadmap.md`	Phase 0~4 게이트 기반 로드맵	결정 반영 완료
`poc-plan.md` / `poc-materials.md`	PoC #1·#3 방법론 + 바로 쓸 모집문구·스크립트	계획 완료, 실행 전
`user-interview-guide.md`	Q3 위임 의향 인터뷰 (와카뷰 사용자 관점)	계획 완료, 실행 전
클릭 프로토타입	읽씹종결·본인확인·거부권·에스컬레이션·자율성설정 4장면	완료, 앵커 `prototype.md`

아직 안 된 것 (사람이 직접 해야 함): 실제 참가자 모집, 대화 샘플 수집, 역할극/인터뷰 진행, 그 결과의 Go/No-Go 판정. 문서·계획·자극재는 다 준비돼 있어 착수만 하면 된다.

Q1~Q7 확정 체크리스트 (회의 중 하나씩)

각 항목을 "확정" 또는 "재검토"로 표시하고, 재검토라면 이유와 다음 액션을 적는다.

Q1 AI 와카뷰 컨셉 확정? → 확정: 예 (decision-log.md)
Q2 타깃 대중 우선? → 확정: 예 (B2B는 이후)
Q3 자율성 L0~L2만 출시? → 확정: 예 (기본 레벨·화이트리스트는 PoC/실사용 후)
Q4 사칭 우려 대응(뱃지·거부권) 충분? → 확정: 1차 설계로 베타, PoC#3로 검증
Q5 MVP 시나리오 = 읽씹종결 + 단톡따라잡기? → 확정: 예
Q6 서비스 이름 "와카뷰"(가칭)? → 확정: 가칭 유지
Q7 자체 앱 클로즈드 베타 먼저, OS 레이어는 이후? → 확정: 예

회의에서 정할 것 (Q1~Q7 확정 외)

PoC #1·#3 착수 일정 — poc-materials.md 모집 문구를 누가, 언제 발송할지
Q3 인터뷰(user-interview-guide.md) 담당자 — PoC#3과 같은 날 진행할지 여부
Go/No-Go 기준 재확인 — poc-plan.md의 수치 기준(예: "말투 같다" 4/5 이상)에 이견 없는지
다음 리뷰 시점 — PoC 결과가 나오는 대로 재소집할지, 정기 주기로 할지

회의 후 팔로업

Q#이 확정되면 decision-log.md의 "상태" 열을 제안 → 확정으로 갱신
Q#이 뒤집히면 decision-log.md + 영향받는 하위 문서(§ 위 표 참고)를 같은 커밋에서 함께 수정 (AGENTS.md: "Q1~Q7이 뒤집히면 decision-log.md와 파생 문서를 동시에 갱신" 원칙)
PoC 실행 담당자·일정이 정해지면 PLANNING.md §8 체크리스트에 담당자/일정 메모 추가

3.3 KiB Raw Blame History