특강) 목적별 문서 작성법 — 왜 이 문서를 쓰는가? 누구에게 보일 문서인가?(+개인적인 TIP)

도에서 운영하는 센터(도에서 용역을 받아 처리하는 기관이었음)에서 일한 경험이 있다.

당시에 용역 문서를 처음부터 싹 다 내 스타일대로 작성하라는 지시를 받은 적이 있는데

그때 느껴지던 막막함이란...(진심인가 궁금했는데 진심이셨음)

용역 문서 하나 가지고 일주일 넘게 씨름했었다.....ㅋ....ㅋㅋㅋ....

(그땐 너무나 원망스러웠는데 지금 문서 꼼꼼히 잘 쓴다는 평을 받게 된 계기가 됐다...아이러니)

그래서 문서 작성을 어려워하는 게 이해된다.

목적, 추진 방향, 기대효과 등등... 이거 같은 거 아닌가? 싶은데 완전 다르다.

(그리고... 공문 보내면 기본 양식과 조금이라도 다르게 작성하거나

들여 쓰기 같은 사소한 것도 안 맞으면 수정해야 한다....

그럼 또 부장님, 센터장님 결재받고 공문 작성해서 다시 보낸다!!!!!!!!!!!!!!! 후..)

아무튼 이후로 제안서 등등 문서 관련해서 크리티컬한 문제없이 문서를 작성할 수 있게 됐다.

이번 특강 정리는 내 개인적인 TIP을 중간중간 풀어볼까 한다.

[게시글 목차]

 

1. 왜 문서 작성이 어려운가

2. 좋은 PM 문서의 기준

3. 문서 작성 3원칙

4. 회의록 작성법

5. 릴리즈 노트 / 공지 작성법

6. Q&A → 회의에서 의견이 좁혀지지 않을 때

 

+) 오늘의 인사이트 / KPT 회고

 

 

---

 

목적별 문서 작성법 : 초급편
-
개인적인 TIP을 최대한 풀어보겠다(비장)

 

 

1. 왜 문서 작성이 어려운가

• 문서가 어려운 이유는 대부분 처음부터 목적을 잡지 않고 쓰기 시작하기 때문이다.
  → TIP : 괜히 모든 문서가 목적을 먼저 쓰는 게 아니다(특히 기관 제출용(ex. 제안서, 추진계획서, 결과보고서 등등)).
  제일 먼저 목적을 잡고 작성하는 게 문서의 일관적인 내용 전달에 용이하다
  보통은 목적 다음에 추진 방향과 사업개요, 기대효과를 개조식으로 작성한 뒤, 이후 페이지에서 사업 내용을 상세하게 다룬다.

[대표적 패턴]
일단 아는 걸 다 쓴다
→ 나중에 다듬으려고 한다
→ 분량은 많아진다
→ 결론은 흐려진다
→ 읽는 사람은 뭘 해야 할지 모른다

• 분량이 많다고 좋은 문서가 아니다.
  읽고 나서 '그래서 뭘 하라는 거지?'라는 생각이 들면 실패한 문서에 가깝다.
• 좋은 문서는 읽는 사람이 다음 행동을 할 수 있어야 한다.
  → TIP : '짧으면 문서에 대한 근거가 부족하진 않을까...'+'내가 이만큼 열심히 조사&정리했다'
  의 이유로 문서가 길어지기 마련인데(일단 과거의 난 그랬음)
  내용이 짧아도 문서를 본 뒤 해야 할 일이 명확히 보이고 상대를 납득시킨다면 잘 작성한 문서이다.
• ex. 회의록이라면 회의 내용을 전부 받아쓰는 게 아니라, 결정된 것과 해야 할 일을 확인할 수 있어야 한다.
  → TIP : 받아쓰기로 길게 나열된 글은 애초에 각 담당자들이 확인을 잘 안 하는 경우가 많다.
  핵심만 전달해도 못 봤다는 사람들이 많은데... 바쁜데 줄글로 적힌 글을 누가 보겠는가? 나라도 안 본다.
  • 기획서라면 개발자나 디자이너가 이걸 보고 무엇을 만들어야 하는지 알아야 한다.
  • 보고 문서라면 팀장이나 의사결정자가 왜 이 판단이 필요한지 이해하고 결정할 수 있어야 한다.
  • 문서는 결국 독자를 움직이게 하는 도구다.
    → TIP : 분명 전달했는데 나중에 확인할 때 특별한 이유 없이 작업 시작을 안 했다면
    문서 작성이 잘 못 되진 않았는지/의미 전달이 미흡하진 않았는지 점검할 필요가 있다.

 

2. 좋은 PM 문서의 기준

[좋은 PM 문서의 기준]
독자가 궁금한 것을
'결론부터'
근거와 함께 쓰는 문서

• 내가 쓰고 싶은 내용 X / 읽는 사람이 알아야 하는 내용 O
• 같은 내용을 써도 독자에 따라 문서의 형태가 달라진다.
  • 개발자가 읽는 문서 : 구현 범위, 정책, 예외 케이스가 중요
  • 디자이너가 읽는 문서 : 사용자 흐름, 화면 목적, 정보 우선순위가 중요
  • 대표나 임원이 읽는 문서 : 이 일이 매출, 비용, 리스크, 성장에 어떤 영향을 주는지가 중요
    → TIP : 각자의 역할과 업무 범위에 따라 확인해야 할 사항들이 다르다.
    '그래서 뭘 말하고 싶은데?'를 두괄식으로 어필해야 한다.
    (현업에서는 업무 보고 또한 효율적으로 해야 한다. 안 그러면 '바쁜데 빨리합시다'를 듣게 된다.
    짜증과 인상 쓴 얼굴은 덤...ㅋㅋㅋㅋㅋㅋ(ex. 아이씨.. / 아 좀;; / 그래서요? / 목적만 빨리 말해요 등등))
• 심지어 Claude 같은 AI에게 요청하는 문서도 마찬가지다.
  AI가 어떤 결과물을 만들어야 하는지 이해할 수 있게 요구사항과 맥락을 정리해야 한다.
  → TIP : AI도 결국 사람이 만든 것이다.
  원하는 출력값이 있다면 명확히 내가 뭘 원하는지 프롬프트를 작성해야 한다.
  결과물이 이상하다면 '혹시 내가 프롬프트를 제대로 못 쓴 건 아닐까?'를 고민해 볼 필요가 있다.
  프롬프트와 업무 지시는 굉장히 유사한 면이 있다.
  누군가에게 업무를 지시할 때도 '무엇을, 어떻게, 왜'해야 하는지 인수인계서나 사업계획서를 공유하듯...
  
• 결국 좋은 문서는 고정된 양식이 아니라, 읽는 사람과 목적에 맞게 구조화된 문서다.

 

3. 문서 작성 3원칙

1) 독자 먼저

문서 작성 전 체크리스트
이 문서를 누가 읽는가?	그 사람은 어떤 상황에서 읽는가?	이 문서를 읽고 무엇을 해야 하는가?

• 독자가 지금 알아야 하는 내용을 골라 쓰는 게 중요하다.
  ex. 같은 회의 내용을 정리하더라도, 팀원에게 공유하는 회의록과 팀장에게 보고하는 회의록은 달라야 한다.
• 팀원에게는 실행할 일과 담당자가 중요하고, 팀장에게는 결정 사항, 리스크, 일정 영향이 중요할 수 있다.
  → TIP : 주로 팀원에게는 업무 분담 별 지시 사항을 논의된 내용 중심으로 가급적 상세하게,
  팀장에게는 업무 분담 내용과 각 분담 별 담당자 등등 보고 사항(위에 적힌 내용 등)을 담는 게 좋다.

2) 결론 먼저

• 문서는 배경 설명부터 길게 들어가면 읽는 사람이 쉽게 지친다.

앞단에 명시할 것
무슨 문서인지	결론이 무엇인지	읽는 사람에게 무엇을 원하는지

• 읽는 사람이 끝까지 읽어야만 결론을 알 수 있다면 이미 피로한 문서가 된다.
• 회의록도 시간 순서대로 누가 무슨 말을 했는지 쓰는 것보다, 먼저 결정 사항과 액션 아이템이 보여야 한다.
  →TIP : 회의를 통해 오고 간 의견 중 핵심만(결과와 밀접한 내용 중심) 작성하고,
  보는 이가 '그래서 나는 뭘 해야 하는가'를 확실히 알 수 있어야 한다.
  (안 그러면 내가 다시 확인하러 갈 때까지 멍 때리고 있는 경우도..
  이 경우, 왜 안 했냐 물어보면 '뭘 해야 할지 모르겠어요'라는 환장할 답변이 나온다)

3) 근거와 함께

• 문서 안에는 왜 그렇게 판단했는지에 대한 근거가 있어야 한다.

근거 예시
데이터	사용자 인터뷰	VOC	실제 사례	비교 자료	회의에서 나온 결정 이유	리스크

• ex. '이 기능을 먼저 개발해야 합니다'라고 쓰는 것만으로는 부족하다.
  왜 먼저 해야 하는지, 어떤 사용자 문제가 있는지, 지표상 어떤 영향이 있는지,
  하지 않으면 어떤 리스크가 있는지까지 보여줘야 한다.
• 문서에서 주장에 '왜?'라고 물었을 때 답이 없으면 보완이 필요하다.
  →TIP : 이 '왜?'라는 질문에 '엄.... 음... 아....' 이런 식으로 말을 끌거나 고민이 길어지면
  실시간으로 신뢰도가 떨어지는 걸 상대의 표정과 분위기로 느낄 수 있다.
  가급적이면 주장과 함께 주요 예상 답변을 시뮬레이션한 뒤 내세우길 추천한다...

 

4. 회의록 작성법

회의 후에 남길 내용
무엇이 결정되었는가	왜 그렇게 결정했는가	누가 무엇을 언제까지 해야 하는가

• 회의록을 쓰는 이유는 나중에 '그때 뭐라고 했죠?'를 줄이기 위해서다.
  →TIP : 조금 더 개인적인 경험을 보태자면, 기록을 해둬야 이후에 이와 관련한 말이 나왔을 때
  '00월 00일 회의에서 ~에 대한 내용이 나왔고 회의록으로 공유드렸습니다'로 방어 가능하다.
  (방어 못 했을 경우의 상황은... 마음껏 상상하시길...)

1) 회의 전 문서에 들어가면 좋은 것

회의 목적 한 줄	아젠다	참석자와 역할	결정권자	논의할 안건	사전 자료 링크
회의 전에 이 정도를 정리해두면 회의가 덜 떠돈다(최소 빨간 글자만이라도!!). ex. 회의 목적이 'A 기능 오픈 일정 확정'이라면, 회의 중에 논의가 다른 방향으로 새더라도 다시 목적에 맞게 끌고 올 수 있다.

 

2) 회의 후 문서에 들어가야 하는 것

일시

참석자

작성자

결정 사항

결정 이유

액션 아이템

담당자

기한

논의 요약

• 특히 액션 아이템에는 반드시 담당자와 기한이 붙어야 한다.

결제 API 스펙 확정 후 공유 / 김OO / 7월 14일
오픈 일정 유관부서 공지 / 서OO / 7월 11일

• 그냥 '추후 공유 예정'이라고 쓰면 일이 흐려진다.
  누가, 언제까지, 무엇을 할지가 있어야 실행으로 이어진다.
  →TIP : 인간은 마감일이 지정돼 있어야 움직이는 동물이다... 명심하자...
  (근데 가끔 돈 받고 일하라고 고용했는데 마감일을 안 지키는 기이한 형태의 인간도 있다...
  이 경우, 프리랜서는 바로 일감이 끊기는 원인이 된다. 한 번 끊긴 일감은 다시 돌아오지 않는다.)

 

5. 릴리즈 노트 / 공지 작성법

• 릴리즈 노트나 공지는 기능 출시, 정책 변경, 서비스 변경 사항을 대상 독자에게 전달하는 문서다.
  여기서 중요한 건 '무엇이, 언제부터, 누구에게 바뀌는가'를 오해 없이 전달하는 것이다.
  → 독자가 개발자라면 상세 스펙이 중요하고, 사용자가 읽는 공지라면 혜택과 사용 방법이 중요하다.
  →TIP : 상대가 누구인지에 따라, '이 사람은 뭐가 궁금할까?'를 생각해야 한다.
  핀트가 안 맞으면 다소 뜬금없이 느껴질 수 있기 때문이다.

들어가야 할 요소
제목	대상	적용 시점	변경 내용	영향/주의사항	해야 할 일	문의/링크

ex. 제목은 간결하게
→ [7/20] 간편결제 기능 오픈 안내

공지에서 애매하게 X, 명확히 명시할 것 → 적용 대상 + 시점
누구에게 적용되는지	언제부터 적용되는지	기존과 무엇이 달라지는지	사용자가 해야 할 일이 있는지
ex. 전주 거주자 대상	ex. 2026.07.13~2026.07.23	ex. 기존 : 카테고리 타이핑 → 현재 : 카테고리 버튼 클릭	ex. 기존과 어떻게 다른지 설문조사 진행하면 소정의 경품 증정
공지 문서는 읽는 사람이 내가 영향을 받는지, 뭘 해야 하는지만 빠르게 알 수 있으면 된다.

 

 

6. Q&A : 회의에서 의견이 좁혀지지 않을 때

질문 내용

회의에서 두 가지 이상 의견이 좁혀지지 않고, 마감 기한은 정해져 있는데

다음 스텝으로 넘어갈 기미가 없을 때 어떻게 해야 하는지.

이전에는 각 의견에 대한 개인의 이유와 근거를 듣고 다수결로 결정했는데,

더 좋은 방법이 있는지에 대하여...

→ 미리 답변을 정리하면 핵심은 '왜 결정이 안 되는지부터 봐야 한다'였다.

1) 무엇을 정해야 하는지 명확한가

• 의견이 좁혀지지 않는 이유는 애초에 회의에서 결정해야 할 것이 명확하지 않아서일 수 있다.
  ex. '방향성을 논의합시다'는 너무 넓다.
• 회의에서 정해야 하는 대상과 기준이 모호하면 의견은 계속 퍼진다.
  →TIP : 사람은 보통 자신이 피해 보는 상황(야근을 해야 한다든지, 힘들다든지 등등)은
  피하고 싶어 해서 그 특성을 이용하는 게 좋다...
  ex. '지금 이 내용 픽스 안 하고 진행하면 ~~한 리스크가 있습니다'와 같이 리스크를 강조하면
  그때는 비교적 집중을 잘하는 편이다(그에 따른 성과까지 어필하면 굿굿).

[ex. 의견 좁히기]
오늘은 A안과 B안 중 하나를 선택한다
선택 기준은 일정, 리소스, 사용자 영향, 리스크다
오늘 결정하지 못하면 내일 개발 일정이 밀린다

2) 참석자들이 준비되어 있는가

• 의견을 좁히려면 각 안에 대한 근거가 있어야 한다.
  그런데 참석자들이 자료나 판단 기준 없이 들어오면 회의에서 결론이 나기 어렵다.
  이 경우는 억지로 결정하기보다, 필요한 자료를 정리해서 다음 회의를 잡는 편이 낫다.
  단, 그냥 '다음에 다시 이야기하죠'가 아니라 다음 회의에서 무엇을 가져올지 정해야 한다.
  →TIP : 아무런 진전이나 대책안이 없는 상태로 같은 내용의 회의를 진행하면....
  (회의 진행자 이미지도 나락 가고 업무에 지장이 있을 정도로 민원이 폭주한다................................
  or 주변인 포기 상태(이 경우는 도리어 말이 없어짐/왜 이견이 없는지도 확인할 필요가 있다))

A안/B안 장단점 정리

일정 영향

개발 리소스

사용자 영향

비용

리스크

추천안

3) 장단점과 우선순위를 놓고 비교한다

• 자료가 준비되어 있는데도 의견이 갈린다면 각 안의 장단점을 펼쳐놓고 비교해야 한다.
  이때 중요한 건 개인 취향이 아니라 상위 우선순위다.
  ex.
  이번 목표가 일정 준수라면 → 빠르게 구현 가능한 안이 우선될 수 있다.
  목표가 사용자 경험 개선이라면 → 사용자의 혼란을 줄이는 안이 우선될 수 있다.
  목표가 리스크 최소화라면 → 안정적인 안이 우선될 수 있다.
  → 결국 '누가 더 설득력 있게 말했는가'가 아니라 '이번 목표에 더 맞는 안이 무엇인가'로 결정해야 한다.
  →TIP : 비단 PM 직무뿐 아니라 모든 일에서 마감 기한 내
  '우선적으로 처리해야 할 일이 무엇인가?'를 도출해 낼 줄 알아야 효율적인 업무 처리가 가능하다.

4) 그래도 안 정해지면 에스컬레이션 한다

• 마감 기한이 있는데 다음 스텝으로 못 넘어가는 건 결국 일정 관리의 문제이고, 일정 관리는 PM의 책임이다.
• PM은 오늘 무엇을 결정해야 하고, 내일 무엇으로 넘어가야 하는지 알고 있어야 한다.
  그리고 그 상태가 팀에도 공유되어 있어야 한다.
  결정이 안 되는 상황을 방치하면 일정 전체가 밀린다.
  → 이때는 관련 근거를 정리해서 상위 의사결정자에게 올리는 게 맞다.

현재 A안/B안에서 의견이 갈림	각 안의 장단점	일정 영향	리소스 영향	리스크	팀 내 추천안 또는 쟁점	결정 필요 시점
→TIP : 좋은 방법이긴 하나, 이게 반복적으로 일어나면 개인 역량 부족으로 평가되기도 한다. (잊지말자... 상위 의사결정자는 학교 선생님이 아니다... 내부적으로 충분히 조율을 시도했으나 최종의 최종까지도 결정이 안 나는 경우만 시도해보자)

 

 

---

 

오늘의 인사이트

 

'문서를 어떻게 작성해야 잘 작성하는가?'에 대한 답변은

특강에서 다뤘듯, 많이 접해보는 수밖에 없다.

(사실 현업에서 대차게 깨져보면 알고 싶지 않아도 알게 돼있다....ㅋㅋㅋ)

 

그리고 신입일수록 특히... 메모를 잘해야 한다.

처음부터 잘할 순 없으니, 신입이 실수.. 할 수 있다 당연히.

근데 같은 실수가 3번 이상이면 고의라고 생각하는 입장에서

메모라도 하고 있으면 '그래도 열심히 하는 친구네'라는 생각이 든다.

반면 메모도 안 하고 같은 실수를 3번 이상 할 경우,

나는 '...메모 안 해요?'라고 물어본다......

(메모 안 하고 또 같은 실수 하면 가만 안 둔다는 뜻)

 

간혹 핸드폰에 메모하는 분들 있는데

요즘은 어떤지 잘 모르겠지만 부정적으로 보는 시각이 있다.

('내 말은 안 듣고 카톡을 해...?ㅂㄷㅂㄷ'로 인식하는 경우도 있다는 말이다
내가 겪은 건 아니고 주변 동료들이 이야기한 걸 옮긴 것이다)

가급적이면 기업 노트 같은 거 주면 거기다 적고 나중에 사진 찍어서

AI에 넣고 텍스트화해달라고 하든지 하는 걸 추천한다.

아니면 노트북으로 메모를 하든지...

 

각설하고 요점은, 메모를 습관화하는 것이 문서화의 시작이며

그 내용을 누구에게 어떤 목적으로 전달하느냐에 따라 문서화 내용이 달라질 수 있다.

이 차이를 체감하려면 다른 사람의 문서는 어떻게 작성했는지 보고 많이 작성해 봐야 한다.

(특히 상사의 문서를 보고 나름대로 분석해 보면 좋다

현재 상황의 경우에는 튜터님과 매니저님의 문서를 유심히 보는 게 좋다)

 

 

---

 

오늘의 KPT 회고

 

Keep	• 문서를 쓸 때 독자, 목적, 다음 행동을 먼저 생각해야 한다는 점을 다시 확인했다. • 예전 용역 문서 작성 경험을 떠올리면서, 문서 구조를 잡는 감각이 어떻게 쌓였는지 연결해볼 수 있었다.(그땐 그랬지... 아련해진다) • 회의록은 받아쓰기가 아니라 결정 사항, 이유, 액션 아이템을 남기는 문서라는 관점을 계속 가져가야겠다.
Problem	• 회의에서 의견이 좁혀지지 않을 때, 결정 기준보다 각자의 의견 자체에 집중할 가능성이 있다.
Try	• 문서 작성 전 '누가 읽는지 / 왜 읽는지 / 읽고 나서 무엇을 해야 하는지'를 먼저 적어보기. • 회의록에는 결정 사항, 결정 이유, 담당자, 기한을 반드시 포함하기. • 의견이 좁혀지지 않을 때는 A안/B안의 장단점, 일정 영향, 리스크, 결정 필요 시점을 정리한 뒤 필요하면 에스컬레이션하기.