카테고리 없음
[특강]목적별 문서 작성법 초급편
j-node
2026. 7. 13. 20:22
1. 문서 작성의 대원칙 (목적 & 구조)
- 분량보다 명확성: 문서의 양이 많은 것보다 '하고자 하는 바(목적)'가 명확한 것이 좋은 문서이다.
- 문서 작성 3원칙:
- 독자 먼저: 내가 쓰고 싶은 게 아니라 읽는 사람이 알아야 할 것 작성. (이 문서를 누가, 어떤 상황에서, 무엇을 하려고 읽는가?)
- 결론 먼저: 배경부터 늘어놓지 말고 핵심 결론과 요청을 먼저 제시. (3초 안에 무슨 문서이고 나에게 뭘 원하는지 보이는가?)
- 근거와 함께: 주장에는 데이터, 사용자 목소리, 사례 등이 함께 있어야 함. (이 주장에 '왜?'라고 물으면 답이 문서 안에 있는가?)
2. 회의록 작성 및 협업 가이드
- 목적: 회의 후에 '무엇이 결정되었고 누가 무엇을 언제까지 하는가'를 기록하는 것.
- 핵심 관점: 단순 받아쓰기(~님이 ~얘기했음)가 아니라 결정과 액션 아이템 중심으로 작성해야 함. 발언을 다 적지 말고 '결정·이유·할 일' 위주로 정리함.
- 구성 요소:
- 회의 전: 아젠다, 회의 목적 한 줄(예: 'A 기능 오픈 일정 확정'), 참석자와 각자 역할(결정권자 표시), 논의 안건 목록, 사전 읽을 자료 링크
- 회의 후: 일시/참석자/작성자, 결정 사항(확정된 결론과 그 이유 - 가장 중요), 액션 아이템(할 일·담당자·기한), 논의 요약(주요 쟁점과 대안 핵심만)
상황별 항목들:
- 실무자 간 회의: 상세한 내용보다는 핵심 위주로 요약.
- 정기 협업 회의: 이번 주에 발생한 '평소와 다른 특이 사항/이슈' 중심.
- 리소스/타임라인 조정 등 예민한 회의: 버짓의 증감 범위, 줄일 수 있는 지점, 타임라인 조정이 필요한 명확한 근거 포함.
- 의견이 좁혀지지 않을 때 (교착 상태 해결):
- 보통 안건의 장단점 정리가 명확히 안 되었거나, 정해야 할 것이 불분명할 때 발생한다. (사실 이런 경우 드물다고..)
- 준비가 안 되었다면 다음 회의로 미루거나, 정리가 되었음에도 결정이 안 된다면 상위 결정권자에게 -결정을 위임한다.
3. 릴리즈 노트 / 공지 작성법
- 목적: 기능 출시나 정책 변경 사실을 대상 독자에게 정확하고 오해 없이 전달하는 문서.
- 핵심 관점: '무엇이 · 언제부터 · 누구에게 바뀌는가'를 명확히 전달해야 함. 독자가 개발자라면 상세 스펙을, 사용자라면 혜택과 사용법을 중심으로 작성.
- 구성 요소:
- 제목 (요약): 무엇이 바뀌는지 한 줄로 표현 (ex. [7/20] 간편결제 오픈)
- 대상 / 적용 시점: 누구에게, 언제부터 적용되는지 (적용일, 대상 범위)
- 변경 내용: 새 기능, 변경점, 개선 사항 (사용자 관점 → 혜택 상세 순)
- 영향 / 주의사항: 기존과 무엇이 달라지는지 명시
- 해야 할 일: 독자가 취해야 할 조치
- 문의 / 링크: 더 알아보기 및 문의처
4. 문서화 팁
- 시각적 편의성: 텍스트로 길게 늘어놓기보다 표나 데이터베이스를 적극적으로 활용하여 읽는 사람이 보기 편하게 구조화한다.
오늘의 인사이트, 느낀 점
- 좋은 PM의 문서는 독자가 궁금해하는 것을 결론부터 근거와 함께 제시하며, 분량이 아닌 '읽고 나서 무엇을 할 수 있는가'로 평가받는다.
- 과제 중에도 문서 작성 시 내가 좋아하는 파트를 먼저 작성하고, 분량도 많이 할애했던 것 같다. 내용 구성만큼이나 형식적 구성도 먼저 계획해야겠다.
- 전에는 회의록을 AI로 요약하고 간단히 검토만 하면 된다고 생각했는데, 절대 아니었다..
- 회의록으로 각자의 책임과 액션 아이템을 도출하고, 회의에 없었던 사람들도 내용을 이해할 수 있어야 한다. 좋은 문서 작성을 부단히 연습해야겠다.
- 문서화 최종 체크리스트:
- 1) 누가, 어떤 상황에서, 무엇을 위해 읽나? 독자가 알고 싶은 것을 알 수 있는 문서인가?
- 2) 결론을 먼저 제시했는가?
- 3) 근거: 데이터/사용자 목소리/사례 중 무엇을 포함했나?
- 4) 문서 핵심 관점: 독자를 고려해 문서에 포함되어야 하는 구성 요소가 무엇이며, 포함되었는가?