표·플로우차트 병행 + 버전 이력 관리
기획 문서를 구성할 때 저는 독자를 먼저 정의합니다. 개발자가 읽을 문서와 PD·기획 리뷰용 문서는 필요한 세부 수준이 다르기 때문에, 같은 내용도 대상에 따라 표현 밀도를 다르게 가져갑니다. 구조는 목적(왜 만드는지)→스코프→상세 스펙→예외 케이스 순서로 배치하고, 정의를 앞에 두지 않으면 이후 내용이 흔들린다는 걸 실습에서 배웠습니다.
표와 플로우차트를 텍스트와 병행하면 구현 담당자가 의도를 빠르게 파악합니다. 문서를 쓰고 나면 자가 검수 체크리스트(빠진 엣지 케이스·용어 통일)를 돌리는 습관이 리뷰 라운드를 줄이는 데 효과적이었습니다. 버전 이력을 남겨두면 의사결정 맥락이 남아 나중에 이유를 묻는 상황이 줄었습니다.