product-manual

name	product-manual
description	제품의 기능·사양을 "찾아보는" 레퍼런스 문서(제품 설명서/사양서)로 체계화한다. 기능별 무엇을·어떻게·제약·권한과 버전·업데이트 이력을 정리한다. "제품 설명서 만들어줘 / 기능 사양서 / 스펙시트 / 기능 레퍼런스 정리 / 이 기능 뭐 하는지 문서로 / 제품 사양 정리해줘"라고 할 때. (사용 순서를 알려주는 과업 중심 사용 가이드가 아니라, 기능을 항목으로 찾아보는 사양 레퍼런스다.)

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

제품 설명서 · 기능 사양서 (레퍼런스)

제품의 기능을 항목별로 찾아보는 문서다. 처음부터 끝까지 읽는 문서가 아니라, "이 기능 뭐였지?"를 검색하는 사전(辭典)에 가깝다.

• 이건 레퍼런스다(manual): 기능 하나하나의 무엇을·어떻게·제약·권한을 정확히 못 박는다.
• 과업 가이드(user-guide)와 다르다: "처음 시작하는 법 → 다음 단계" 같은 순서·과업 중심 안내는 별도다. 사용자가 "쓰는 법을 순서대로" 원하면 그건 과업 가이드이니 그렇게 짚어주고 범위를 나눈다. 왜: 둘을 섞으면 개발/CS는 사양을 못 찾고, 초보 고객은 순서를 못 따라간다.

공통 원칙 (항상 지켜라)

1. 왜를 사람 말로: 제약·권한 옆에 이유를 붙인다. "무료 플랜은 월 20건 제한" 옆에 "왜냐면 원가가 여기서 나가서" 식으로. 형식만 채운 사양서는 죽은 문서다.
2. 근거·출처: 한계값·요금·권한·지원 범위 같은 수치·주장은 실제 소스(코드·정책·config·기존 스펙)에서 인용한다. 없으면 **지어내지 말고 "확인 필요(어디를 보면 되는지)"**로 남겨라. 사양서의 추측값은 개발·CS·고객이 그대로 사실로 믿는다 — 특히 위험하다.
   • 추론을 사실로 단정하지 마라(중요): 서로 다른 단위의 카운트로 "가장 많이 쓰인 기능" 같은 순위를 단정하거나, "온라인 결제엔 버튼이 있다" 같은 대비 추론을 ⚠ 없이 사실처럼 쓰지 않는다. 방어 가능한 해석이라도 근거가 직접 없으면 '추정' 또는 ⚠로 표시한다.
3. 반자동: 여기서 만드는 건 초안이다. AI가 표를 채우고 → 사람(기획·개발·CS)이 검토·확정. 확정 전엔 draft 표시.
4. 코칭(신입이면): 신입은 "정상 동작"만 적고 제약·권한·미지원·에러를 빠뜨린다. 사양서의 값어치는 바로 그 경계에 있음을 짚어주며 진행.

진행 순서

1. 대상 독자·목적 확인 — 개발/CS/영업/외부 고객 중 누가 찾아보나? 독자가 다르면 상세도가 다르다(개발=파라미터·에러, CS=제약·권한, 고객=무엇을·요금).
2. 기존 컨텍스트 점검(헛발질 방지) — 기존 컨텍스트 문서(~/.pm-copilot/data/context.md, 위치는 PM_COPILOT_HOME로 재정의 가능), 기존 [write-spec]·[[plan-doc]](화면 정책·요구사항 등)·이전 사양 문서, 그리고 실제 동작(코드/화면)을 먼저 본다. 부족하면 [[research]]·[[market-radar]]로 보완(출처·날짜).
3. 기능 인벤토리 뽑기 → 사용자 확인 — 문서화할 기능 목록을 먼저 나열해 합의한다. 많으면 [[prioritize]]로 핵심 기능부터.
4. 기능별 템플릿 채우기 — 아래 카드 형식. 아는 것부터, 모르는 값은 "확인 필요".
5. 버전·업데이트 이력 정리 — 사양서는 "지금 버전이 뭔지"가 생명. 이력 표를 반드시 붙인다.
6. 시각화(필요 시) — 화면·플로우가 얽히면 [[mockup]]·[[simple-design]]으로 눈에 보이게.
7. 저장·검토로 연결 — 저장 제안 후 [[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]]에 남기고 링크. 왜: 사양서는 "무엇이 바뀌었나", 결정로그는 "왜 바꿨나"를 맡는다.

마무리 체크리스트 (넘기기 전)

• 기능마다 무엇을·어떻게·제약·권한이 다 있나 (경계값·미지원 포함)
• 모든 수치·요금·권한에 **출처 or "확인 필요"**가 붙었나 (추측 확정 금지)
• 추론·해석을 사실처럼 단정하지 않고 '추정'/⚠로 표시했나 (순위 단정·대비 추론 주의)
• 각 제약/권한 옆에 **'왜'**가 있나
• 버전·이력 표가 있고 현재 버전이 명확한가
• "확인 필요" 항목을 모아 담당자에게 넘겼나
• 과업 가이드와 섞이지 않았나 (순서 안내가 필요하면 별도로 분리)

저장 · 공유

• 완성 초안은 ~/.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]]