| name | product-manual |
| description | 제품의 기능·사양을 "찾아보는" 레퍼런스 문서(제품 설명서/사양서)로 체계화한다. 기능별 무엇을·어떻게·제약·권한과 버전·업데이트 이력을 정리한다. "제품 설명서 만들어줘 / 기능 사양서 / 스펙시트 / 기능 레퍼런스 정리 / 이 기능 뭐 하는지 문서로 / 제품 사양 정리해줘"라고 할 때. (사용 순서를 알려주는 과업 중심 사용 가이드가 아니라, 기능을 항목으로 찾아보는 사양 레퍼런스다.) |
작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].
제품 설명서 · 기능 사양서 (레퍼런스)
제품의 기능을 항목별로 찾아보는 문서다. 처음부터 끝까지 읽는 문서가 아니라, "이 기능 뭐였지?"를 검색하는 사전(辭典)에 가깝다.
- 이건 레퍼런스다(manual): 기능 하나하나의 무엇을·어떻게·제약·권한을 정확히 못 박는다.
- 과업 가이드(user-guide)와 다르다: "처음 시작하는 법 → 다음 단계" 같은 순서·과업 중심 안내는 별도다. 사용자가 "쓰는 법을 순서대로" 원하면 그건 과업 가이드이니 그렇게 짚어주고 범위를 나눈다. 왜: 둘을 섞으면 개발/CS는 사양을 못 찾고, 초보 고객은 순서를 못 따라간다.
공통 원칙 (항상 지켜라)
- 왜를 사람 말로: 제약·권한 옆에 이유를 붙인다. "무료 플랜은 월 20건 제한" 옆에 "왜냐면 원가가 여기서 나가서" 식으로. 형식만 채운 사양서는 죽은 문서다.
- 근거·출처: 한계값·요금·권한·지원 범위 같은 수치·주장은 실제 소스(코드·정책·config·기존 스펙)에서 인용한다. 없으면 **지어내지 말고 "확인 필요(어디를 보면 되는지)"**로 남겨라. 사양서의 추측값은 개발·CS·고객이 그대로 사실로 믿는다 — 특히 위험하다.
- 추론을 사실로 단정하지 마라(중요): 서로 다른 단위의 카운트로 "가장 많이 쓰인 기능" 같은 순위를 단정하거나, "온라인 결제엔 버튼이 있다" 같은 대비 추론을 ⚠ 없이 사실처럼 쓰지 않는다. 방어 가능한 해석이라도 근거가 직접 없으면 '추정' 또는 ⚠로 표시한다.
- 반자동: 여기서 만드는 건 초안이다. AI가 표를 채우고 → 사람(기획·개발·CS)이 검토·확정. 확정 전엔
draft 표시.
- 코칭(신입이면): 신입은 "정상 동작"만 적고 제약·권한·미지원·에러를 빠뜨린다. 사양서의 값어치는 바로 그 경계에 있음을 짚어주며 진행.
진행 순서
- 대상 독자·목적 확인 — 개발/CS/영업/외부 고객 중 누가 찾아보나? 독자가 다르면 상세도가 다르다(개발=파라미터·에러, CS=제약·권한, 고객=무엇을·요금).
- 기존 컨텍스트 점검(헛발질 방지) — 기존 컨텍스트 문서(
~/.pm-copilot/data/context.md, 위치는 PM_COPILOT_HOME로 재정의 가능), 기존 [write-spec]·[[plan-doc]](화면 정책·요구사항 등)·이전 사양 문서, 그리고 실제 동작(코드/화면)을 먼저 본다. 부족하면 [[research]]·[[market-radar]]로 보완(출처·날짜).
- 기능 인벤토리 뽑기 → 사용자 확인 — 문서화할 기능 목록을 먼저 나열해 합의한다. 많으면 [[prioritize]]로 핵심 기능부터.
- 기능별 템플릿 채우기 — 아래 카드 형식. 아는 것부터, 모르는 값은 "확인 필요".
- 버전·업데이트 이력 정리 — 사양서는 "지금 버전이 뭔지"가 생명. 이력 표를 반드시 붙인다.
- 시각화(필요 시) — 화면·플로우가 얽히면 [[mockup]]·[[simple-design]]으로 눈에 보이게.
- 저장·검토로 연결 — 저장 제안 후 [[ask-sunbae]]로 다각도 검토, 다듬기가 필요하면 [[doc-polish]].
문서 상단 (한 번만)
- 제품/버전: 예) 제품명 vX.Y · 최종수정 YYYY-MM-DD · 상태
draft
- 한 줄 정의: 이 제품이 무엇인가. 예) "○○ 사용자를 위한 △△ 서비스 — 핵심 가치 한 줄." (구체 수치·요금·조건은 정책/config에서 인용, 없으면 확인 필요)
- 이 문서의 범위: 무엇을 다루고(다루는 기능군), 무엇은 안 다루나(비범위).
기능별 템플릿 (레퍼런스 카드 — 기능마다 반복)
기능명
- 무엇을 (정의): 이 기능이 하는 일 한 줄. 왜 존재하나(어떤 문제를 푸나) 한 줄.
- 어떻게 (동작): 입력 → 처리 → 출력. 사용자가 무엇을 하면 무슨 결과가 나오는지.
파라미터 · 옵션
| 항목 | 설명 | 기본값 | 허용 범위/형식 | 비고 |
|---|
| 예: 소재 개수 | 1회 생성 수 | 4 | 1~10 | 초과 시 확인 필요 |
제약 · 한계 (신입이 제일 잘 빠뜨리는 곳)
- 지원 범위 / 미지원(안 되는 것) / 상한·하한 / 성능·용량 한계. 각 값에 근거 또는 "확인 필요".
- 예) "동영상 소재 미지원(현재 이미지만) — 왜: 이번 버전 로드맵 밖(확인 필요)."
권한 · 요금
| 누가/어떤 플랜 | 사용 가능 | 제한 | 왜 |
|---|
| 무료 | O | 월 20건 | 원가 |
| 유료(스탠다드) | O | 무제한 | |
상태 · 에러 (해당 시)
| 코드/상황 | 의미 | 사용자에게 보이는 처리 |
|---|
| E-401 | 권한 없음 | 로그인/업그레이드 유도 |
- 관련 기능 · 의존성: 이 기능이 기대는/영향 주는 다른 기능.
버전 · 업데이트 이력 (필수)
| 버전 | 날짜 | 변경 내용 | 영향받는 기능/사용자 | 결정 근거 |
|---|
| vX.Y | YYYY-MM-DD | 예) 소재 개수 상한 상향 | 생성 기능·유료 | [[decision-log]] 참조 |
- 큰 사양 변경은 여기 한 줄 + 결정 배경은 [[decision-log]]에 남기고 링크. 왜: 사양서는 "무엇이 바뀌었나", 결정로그는 "왜 바꿨나"를 맡는다.
마무리 체크리스트 (넘기기 전)
저장 · 공유
- 완성 초안은
~/.pm-copilot/data/docs/에 날짜-유형 이름으로 저장 제안(자동 저장 아님). 예) 2026-07-26-product-manual-<제품>.md
- 노션/Confluence 게시는 커넥터로 초안 페이지 생성 제안 → 사람 승인 후. 자동 게시 금지.
관련: [[write-spec]](PRD·상위 요구) · [[plan-doc]](화면 정책·요구사항 등 기타 문서) · [[mockup]] [simple-design] · [[decision-log]](사양 변경의 '왜') · [ask-sunbae] · [doc-polish] · 흐름 전체는 [[method]]
