[기획자의 자산] 위키 기반 문서화, 기획서는 파일이 아니라 지식이다

프로젝트가 끝나면 기획서는 어디로 갈까요? 대부분 이메일 함이나 메신저 대화록 깊은 곳에 묻혀 과거의 유물이 됩니다. 새로운 팀원이 합류하거나 유사한 기능을 고도화할 때, 예전 기획서를 찾느라 시간을 허비하는 것은 엄청난 리소스 낭비입니다. 기획서는 완료된 파일이 아니라, 팀과 함께 성장하는살아있는 지식이어야 합니다. 노션, 컨플루언스 같은 위키 기반 도구를 활용해 지식의 선순환을 만드는 문서화 기술을 소개합니다. 1. 왜 위키 방식이어야 하는가? 기존의 워드나 PPT 파일 형태의 문서화는 파편화라는 치명적인 단점이 있습니다. 검색의 한계: "그때 그 정책이 어디 있었지?"라며 수십 개의 파일을 열어봐야 합니다. 접근성 저하: 권한이 없거나 경로를 몰라 기획자에게 매번 물어봐야 하는 비효율이 발생합니다. 업데이트의 부재: 배포 후 수정된 세부 정책이 파일에는 반영되지 않아, 나중에는 기획서와 실제 서비스가 다른 상황이 벌어집니다. 2. 살아있는 위키 문서를 만드는 3가지 핵심 전략 ① 원소스 멀티유즈: 모든 정책의 Single Source of Truth 구축 위키 문서 하나가 서비스의 공식 기준점이 되어야 합니다. 기획 포인트: 기능 정의, 정책, 디자인 링크, QA 케이스를 하나의 위키 페이지에 연결하세요. 수정이 필요할 때 여러 파일을 고칠 필요 없이 위키 페이지 하나만 업데이트하면 모두가 최신 정보를 보게 됩니다. ② 계층형 구조와 태그 활용: 기획서도 도서관처럼 분류하라 문서가 많아질수록 찾기 쉬운 구조가 생명입니다. 기획 포인트: 프로젝트 단위가 아닌 도메인 단위(예: 결제, 전시, 마이페이지)로 상위 페이지를 구성하세요. 하위에 프로젝트 히스토리를 쌓으면, 나중에 특정 도메인을 공부하려는 팀원에게 완벽한 교과서가 됩니다. ③ 히스토리의 자산화: 의사결정의 맥락을 남겨라 결과물만큼 중요한 것이 왜 그렇게 결정했는가에 대한 기록입니다. 기획 포인트: 회의록이나 결정 사항을 위키 페이지 하단에 기록으로 남기세요. 당시 CS 이슈로 인해 이 정책은 이렇게 변경됨이라는 한 줄의 기록이, 1년 뒤 후임 기획자에게는 수십 시간의 시행착오를 줄여주는 보물이 됩니다. 3. 기획자의 최종 선택: 문서화는 일이 아니라 문화다 위키 기반 문서화의 완성은 기획자 혼자서 할 수 없습니다. 하지 말아야 할 것: 나만 편집할 수 있는 잠긴 문서로 만들지 마세요. 해야 할 것: 개발자, 디자이너도 댓글을 달고 함께 수정할 수 있는 협업의 장으로 만드세요. 팀 전체가 궁금하면 위키를 보자는 문화를 공유할 때, 기획서의 가치는 극대화됩니다. 포스팅 마무리 꿀팁 잘 만든 위키 문서는 기획자가 휴가를 가도 서비스가 돌아가게 만듭니다. 기록은 기억을 지배합니다. 남긴 작은 문서 한 줄이 우리 팀의 지식 부채를 줄이고, 더 나은 서비스를 만드는 밑거름이 된다는 사실을 잊지 마세요!