티스토리 뷰

솔직히 저는 보고서를 제대로 배운 적이 없습니다. 인수인계도 없었고, 매번 검색하고 남의 자료 찾아보면서 간신히 한 장씩 만들었습니다. 그러다 대기업 스탭 부서 출신의 10년 차 직장인이 정리한 보고서 원칙들을 접하고 나서야, 제가 그동안 가장 엉뚱한 걸 붙들고 있었다는 걸 알게 됐습니다. 예쁘게 꾸미는 것보다 훨씬 앞에 있어야 할 것들이 있었습니다.

 

보고서 잘 쓰는 법!
보고서 잘 쓰는 법

보고서는 디자인이 아니라 기획 구조가 먼저다

보고서를 잘 쓴다는 말을 들으면 많은 분들이 깔끔한 레이아웃이나 잘 정렬된 표를 떠올리는 경우가 많습니다. 저도 그랬습니다. 처음에는 폰트 크기, 색상 배치, 그래프 모양에 시간을 가장 많이 썼습니다. 그런데 제가 직접 여러 보고서를 만들어 보면서 느낀 건, 외형보다 훨씬 앞에 있어야 하는 것이 있다는 점이었습니다.

 

그것은 바로 페이지 간 흐름 설계, 즉 보고서의 내러티브 구조(narrative structure)입니다. 여기서 내러티브 구조란 보고서 전체가 어떤 논리 순서로 이야기를 전달하는지 큰 틀을 말합니다. 보고서를 잘 다루는 사람들을 보면 첫 페이지부터 채우지 않습니다. 1페이지엔 무엇이, 2페이지엔 무엇이 들어갈지 먼저 스케치하고, 그 안에서 어떤 인사이트 한 줄을 전달할 건지 정한 다음 근거를 채워 넣습니다.

 

이런 방식이 낯설게 느껴질 수 있습니다. 저도 처음엔 "뼈대를 먼저 짜는 게 왜 빠른 방법이지?"라고 의아했습니다. 그런데 막상 해보니 이유가 명확했습니다. 보고서는 한 장에 담아야 할 공간 제약이 크고, 텍스트와 그래프, 표를 효과적으로 배치하려면 구도부터 잡지 않으면 나중에 내용 다 쓰고 레이아웃을 처음부터 다시 잡는 일이 생깁니다. 실제로 저는 이 순서를 거꾸로 했다가 완성 직전에 전체를 엎은 적이 한 번 있습니다.

 

"보고서는 기획 싸움"이라는 말이 인상적이었는데, 저는 이 말에 반은 동의하고 반은 유보합니다. 기획 구조가 중요한 건 분명하지만, 기획이 완벽해도 내용 안에 담기는 인사이트(insight)가 없으면 의미가 없기 때문입니다. 인사이트란 데이터나 현황에서 우리가 무엇을 해야 하는지 방향을 짚어내는 핵심 판단을 말합니다. 단순 현황 보고조차도 "그래서 우리 조직이 지금 이렇게 해야 한다"는 필자의 목소리가 담기지 않으면 쓸모 없는 보고가 된다는 점, 제가 직접 경험해보고 나서야 실감했습니다.

 

또 한 가지, 보고서 작성에서 종종 간과되는 것이 아카이빙(archiving)입니다. 아카이빙이란 과거에 작성한 보고서 양식과 데이터를 체계적으로 쌓아두는 것을 말합니다. 실제로 보고서를 많이 다루는 조직일수록 레퍼런스가 축적되어 있고, 새로운 보고가 떨어졌을 때 완전히 새로 만드는 것이 아니라 기존 양식에서 내용만 갱신하는 방식으로 속도를 냅니다. 사실 실제로 써보니 이 축적된 양식이 없으면 보고서 한 장에 쓸데없이 긴 시간이 들어가는 경험을 반복하게 됩니다.

  • 보고서는 1페이지부터 채우지 말고, 전체 페이지 흐름(내러티브 구조)을 먼저 스케치한다
  • 각 페이지에서 전달할 인사이트 한 줄을 먼저 확정하고, 그에 맞는 근거를 채운다
  • 과거 보고서 양식을 아카이빙해두면 다음 보고서의 속도가 눈에 띄게 빨라진다
  • 현황 보고일지라도 자기 생각이 없으면 "쓸데없는 보고"가 된다

참고로, BBC Bitesize의 직장 내 커뮤니케이션 관련 자료에서도 보고서 작성 시 핵심 메시지를 먼저 정의한 뒤 구조를 설계하는 방식이 효과적이라는 내용을 다루고 있습니다. 자료 구조보다 전달 목적이 먼저라는 관점은 업무 문서 전반에 걸쳐 통용되는 원칙으로 보입니다.

 

대상이 바뀌면 내용도 바뀌고, 메모 없이는 설득도 없다

보고서를 쓰다 보면 "분명히 이 내용으로 보고했는데 왜 다시 쓰라는 거지?"라는 상황이 생깁니다. 저도 그 답답함을 경험한 적이 있습니다. 팀장용으로 작성한 자료를 조직장 보고에 그대로 들고 갔다가, "보고서 잘 못 들고온거 아니냐"라는 말을 들은 일이 있었습니다. 그때는 그냥 무시당하는 기분이었는데, 나중에 생각해보면 그분 말이 맞았습니다.

 

이것이 보고의 계층 구조(hierarchical reporting structure) 문제입니다. 계층 구조란 팀원 → 팀장 → 조직장으로 이어지는 보고 대상 간의 위계를 말하며, 각 계층은 같은 데이터를 봐도 다른 판단 기준과 관심사를 가집니다. 팀원 레벨에서 중요한 세부 수치가 조직장에게는 노이즈(noise)가 될 수 있고, 반대로 조직장이 원하는 방향성 판단은 팀원 보고서에서는 묻혀 버립니다. 제가 경험상 이건 좀 다르게 느꼈는데, 단순히 수준 차이만의 문제가 아니라 "이 보고에서 무엇을 결정하게 할 것인가"의 목적 자체가 달라지기 때문입니다.

 

그리고 보고서를 잘 쓰는 사람들에게서 발견한 또 다른 습관이 있습니다. 바로 보고 자리에서 메모를 철저히 한다는 것입니다. 보고가 한 번에 통과되는 경우는 많지 않습니다. 상사의 피드백이 나왔을 때 그 뉘앙스까지 기록해두지 않으면, 다음 번에 수정본을 들고 갔을 때 "이게 제가 말한 방향이 아닌데요"라는 말을 또 듣게 됩니다. 이게 반복되면 능력 문제가 아니라 태도 문제로 찍히게 됩니다.

 

메모를 강조하는 시각도 있고, "어차피 다시 하면 되지 않나"라고 생각하는 분들도 있는데, 저는 전자가 맞다고 봅니다. 보고서를 고치는 건 단순히 내용을 바꾸는 게 아니라, 상사가 어떤 맥락에서 무엇을 원하는지 파악하는 과정이기 때문입니다. 그걸 메모 없이 기억에만 의존하면 결국 엉뚱한 방향으로 수정하는 일이 생깁니다. 제가 실제로 그런 실수를 반복한 적이 있어서, 이 부분만큼은 확신을 갖고 말할 수 있습니다.

 

또 하나 중요한 것이 컨펌(confirm) 절차입니다. 보고서에 등장하는 모든 관련 조직에 사전 컨펌을 받는 것인데, 이를 이해관계자 사전 검토(stakeholder pre-review)라고 부르기도 합니다. 여기서 사전 검토란 보고 자리에서 처음 내용을 공개하는 것이 아니라, 관련 부서에 미리 공유해 데이터 오류나 맥락 차이를 잡아두는 과정을 말합니다. 처음엔 이게 상대에게 공격 포인트를 미리 알려주는 행위처럼 보였는데, 실은 우리 스스로 오류를 걸러내기 위한 방어 장치였습니다. 틀린 데이터로 보고에 올라가면 조직 전체의 신임이 흔들리기 때문입니다.

 

초등학생도 이해할 수 있게 간결히 쓴다는 원칙

보고서를 어렵게 쓰면 전문적으로 보일 것 같다고 생각하는 분들도 있는데, 저는 반대의 경험을 했습니다. 실무 용어와 복잡한 수식을 그대로 올렸더니 정작 핵심 논의까지 가기도 전에 용어 설명으로 시간을 다 써버렸습니다. 보고의 목적은 내 조직의 존재 이유를 설득력 있게 전달하는 것인데, 읽는 사람이 이해를 못 하면 그 설득 자체가 시작도 안 됩니다. 어려운 내용은 첨부 자료로 빼고, 본문에는 결론과 방향성만 명확하게 담는 방식이 실제로 훨씬 효과적이었습니다.

 

 

자주 묻는 질문

Q. 보고서 처음 쓸 때 어디서부터 시작해야 하나요?

A. 첫 페이지부터 채우는 것보다 전체 페이지 흐름을 먼저 잡는 것이 효과적입니다. 몇 장짜리 보고서인지, 각 장에서 무엇을 말할 건지 큰 틀을 스케치한 뒤, 각 페이지의 핵심 메시지 한 줄을 먼저 정하고 근거를 채우는 순서로 진행하면 중간에 방향이 흔들리는 일이 줄어듭니다.

 

Q. 팀장용 보고서랑 임원용 보고서가 달라야 하나요?

A. 내용이 같아도 대상이 바뀌면 다시 쓰는 것이 원칙이라는 의견이 있고, 저도 이 부분에 동의합니다. 팀장은 실행 가능성과 세부 수치를 보고, 임원은 방향성과 조직 간 영향을 봅니다. 같은 데이터를 올려도 어떤 판단을 이끌어낼 것인지의 목적 자체가 다르기 때문에, 구성과 강조점을 달리해야 합니다.

 

Q. 보고서에서 전문 용어를 쓰면 안 되나요?

A. 완전히 쓰면 안 되는 건 아니지만, 보고를 받는 사람이 실무자가 아닌 경우가 많기 때문에 본문 안에서 전문 용어를 그대로 노출하면 핵심 논의에 들어가기도 전에 막히는 경우가 많습니다. 어려운 내용은 첨부 자료로 빼고, 본문에는 결론 중심으로 쉽게 쓰는 것이 보고 자리에서 훨씬 유리합니다.

 

Q. 보고 자리에서 메모가 그렇게 중요한가요?

A. 보고는 한 번에 통과되는 경우가 많지 않기 때문에, 피드백을 얼마나 정확히 기록해두느냐가 다음 보고의 퀄리티를 결정합니다. 상사의 말 중에는 직접 표현보다 뉘앙스에 더 많은 의미가 담긴 경우가 많아서, 기억에만 의존하면 수정 방향이 어긋나게 됩니다. 보고하는 사람이 바빠서 메모가 어려우면 옆에 메모 담당을 따로 두는 것도 방법입니다.

 

결론

이 원칙들을 알고 나서 가장 먼저 든 생각은 "왜 이걸 아무도 미리 안 알려줬을까"였습니다. 그런데 사실 알아도 바로 잘 쓸 수 있는 건 아닙니다. 큰 틀을 먼저 잡고, 대상에 따라 내용을 달리 쓰고, 피드백을 메모로 남기는 습관이 몸에 배기까지는 반복이 필요합니다.

그래서 저는 당장 완벽한 보고서를 목표로 하기보다, 초안을 조금 일찍 완성해두고 여유를 두고 다시 읽어보는 방식으로 접근하는 것이 현실적이라고 생각합니다. "내 생각이 담겼는가, 읽는 사람이 이해할 수 있는가, 근거가 충분한가"를 하나씩 점검하다 보면 이 원칙들이 결국 내 것이 됩니다. 보고서는 기획 싸움이고, 기획은 연습으로 쌓이는 것입니다.

 

참고: https://www.bbc.co.uk/bitesize/articles/zffy92p