좋은 기획서 글쓰기는?
[프롤로그] 잘 해서 쓰는 게 아니라, 잘 하려고 쓰는 글입니다.
기획서 작성에서 중요한 점은 무엇일까? 좋은 기획서 글쓰기에 대한 개인적인 관점과 기획자가 글을 쓸 때 필요한 핵심 요소들에 대해 소개한다. 글쓰기의 본질과 기획서 작성의 어려움에 대한 고민을 공유한다.
좋은 기획서 글쓰기란 무엇일까. 기획자로 일한 지 10년이 넘었지만 난 아직 실무 기획을 하는 현역이다. 하지만 연차를 더해갈수록 기획서를 쓰기 더 조심스러워진다. 동료나 후배들의 기획서를 검토할 일이 많은데 피드백(Feedback)을 주는 한편 내가 쓴 기획서도 다시 돌아보게(Lookback) 된다. 쓸 땐 안 보였던 아쉽고 부족한 부분이 자꾸 드러난다.
“좋은 기획서란 무엇인가?” 물어보면 열이면 열 자신만의 답을 내놓는다. 모두 정답인 경우가 많다. 기획서에 담아야 할 내용이 정의해야 하는 기능이나 스펙, 때론 조직의 업무 방식에 따라 다르기 때문이다. 모바일 화면 사용자 시나리오와 각 요소에 대한 노출 정책을 자세하게 기재해야 하기도 하고, 화면 정의보다는 데이터 플로우나 API 연동 구조를 정리해야 하는 경우도 있다.
기획서를 쓸 때 기획자에게 요구되는 가장 중요한 역량은 ‘글쓰기’다. 양식과 내용이 어떻든 기획서는 본디 정책을 담아야 하고, 다른 이들에게 보여주고 이해시켜야 하는 문서이기 때문이다. 여러 회사에서 다양한 툴로 기획서를 써왔지만 글쓰기라는 본질은 변하지 않았다. 좋은 기획서에 대한 단 하나의 답은 없지만, 좋은 기획서 글쓰기에 대해서는 많은 이들이 공감할 만한 방향성이 있을 것도 같다.
요즘 내가 생각하는 좋은 기획서 글쓰기를 한 줄 요약하면 이렇다.
“쉽고 간결한, 하지만 부실하지 않은”
라임을 맞춰본다면 “쉽게, 간결하게, 꼼꼼하게” 정도가 되겠다.
하나씩 풀어서 보자.
1. 이해하기 쉽게 쓰기
기획서는 쉬워야 한다. 여러 번 반복해서 곱씹어 읽어야만 하는 글은 시를 제외하고는 없다고 생각한다. 기획서도 마찬가지다. 여러 번 읽어야 이해되는 기획서는 잘못 쓰인 글일 가능성이 높다.
기획서가 쉬워야 하는 이유는 그 독자를 특정할 수 없기 때문이다. 기획자의 기획서는 프로젝트를 함께 하는 동료들의 업무 지침이 된다. 사업, 디자인, 백엔드, 프론트엔드, 앱, QA, 마케팅, CS 등 다양한 유관부서가 기획서를 참고한다. 조금 더 신랄하게 말하자면, 그들이 ‘참고할 만해야’ 한다.
당신이 함께 일하는 동료들은 모두 전문가다. 단 자신의 분야에서. 각자 업무가 다른 만큼 이해 수준도 다르다. 하지만 기획서는 함께 하는 동료 모두를 독자로 포용해야 한다. 내 글을 이해하고 좋아해 줄 사람만 따로 골라 독자로 삼을 수는 없다. 모두가 프로젝트에 참여하는 메이커이기 때문이다.
무조건 쉬운 용어만 사용하라는 것은 아니다. 일부러 전문용어 잘알인 척 할 필요 없다는 거다. 읽는 사람 누구든 이해할 수 있는 용어와 표현이면 충분하다. 엔지니어와 마케터를 위해 기획서를 따로 작성할 게 아니라면 말이다.
2. 간결하게 쓰기
기획서는 목적성이 강한 글이다. 프로젝트를 설명하고 설득하는 제안서다. 설명하는 기능에 대한 정책이 담겨 있는 정책서이고, 업무를 진행할 때 참고하는 가이드다. 그러므로 기획서는 간결해야 한다. 장황하지 않고, 명확하게 기획자의 의도를 표현해야 한다.
간단한 작업이어도 기획자는 기획서를 쓰기 위해 꽤 많은 준비와 고민을 거친다. 관련 지표를 찾아보고 사용자 VoC를 살피고 인터뷰를 하고 레퍼런스를 찾는다. 개인정보 취급상 문제는 없는지, 이 기능이 법적 리스크는 없는지 등을 검토 받는다.
이 과정에서 기획자는 생각이 정교해지기도, 바뀌기도 한다. 하지만 기획서에 표현되어야 하는 것은 '결과'다. 기획서를 보는 사람들이 궁금해 하는 건 무엇을(What), 왜(Why), 어떻게(How), 언제(When) 하는지다. 글에서 기획자의 고민은 보여야 하지만 기획자의 헤맴이 느껴지면 안 된다.
기획서를 간결하게 쓸 때 고려해야 할 점이 한 가지 더 있다. 글의 구조다. 기획서의 구조적 흐름은 독자가 글을 빠르게 이해할 수 있도록 돕는 중요한 요소다. 소설이나 드라마 같은 스토리에만 기승전결이 있는 것이 아니다. 기획서에도 기승전결이 필요하다.
(기) “문제가 뭐지? 현재 상황이 어떤데?” → 프로젝트 배경 설명
(승) “문제를 해결하면 무엇이 좋아지지?” → 목표 및 기대효과 (성과지표)
(전) “구체적으로 어떻게 고치려는 거지?” → 핵심 기능, 상세 정책 (요구사항)
(결) “그래서 언제까지 해야 하는 거지?” → 작업 및 배포 일정
기획서를 읽는 독자가 스토리라인을 따라오게 해야 한다. 단순히 “이거 해주세요!”보다 설득력이 높을 뿐더러, 단순히 요구사항만 들어주는 메이커가 아니라 함께 개선 의견을 내주는 적극적인 조력자가 생기게 될 것이다.
3. 꼼꼼하게 쓰기
이해하기 쉽고 간결하게 쓰려다 보면 자칫 기획서가 부실해질 수 있다. 그리고 부실한 기획서는 치명적이다. 치명적으로 매력 있다는 게 아니라 치명적인 결함이 있다는 말이다.
기획서의 제1 목적은 요구사항 전달과 정책 정의다. 짧게 쓰려다 내용을 빼먹으면 기능을 상실한 기획서가 된다. 잘 모르겠다고 대충 생략하고 써도 안 된다. 기획서 리뷰를 받은 엔지니어가 “이 기능은 이런 방식으로 구현하는 건 어떨까요?”라고 물어봐주면 고맙지만 “이 부분에 대한 내용이 없는데요”라고 말하면 식은 땀이 난다. 대게 내가 미리 생각해보지 못한 것이고, 생각하지 않았으니 답도 없는 경우가 대부분이니까.
범죄가 발생했을 때 나도 모르게 그 사실을 숨겨주었다면 공범으로 간주되지 않을 수 있다. 하지만 기획서를 쓸 때 나도 모르게 놓친 부분이 있다면 역량 부족이라고 평가 받아도 할 말이 없다. 정리가 필요한 것은 알았지만 답을 못 찾아서 못 썼다면? 그건 의도적인 은닉이다. 사전에 담당 메이커와 협의해 답을 찾거나, 의견을 구한다고 정확하게 적는 것이 낫다.
기획서 쓰기를 시작할 때 우선순위를 굳이 따지자면 “꼼꼼하게, 간결하게, 쉽게” 순이다. 쉽게 쓰는 것이 가장 낮은 우선순위인 이유는 함께 하는 메이커들이 이미 전문가들인 경우가 많아서다. 상황에 따라 기획서를 보는 대상이 더 폭넓고, 각자의 이해도 격차가 크다면 쉬움을 더 많이 고려해야 한다.
퇴고를 할 때에는 기획서를 읽는 독자를 생각하는 것이 좋다. 피보고자가 보기에 간결한가, 엔지니어, 디자이너가 보기에 꼼꼼한가, 다른 협업자들이 보기에도 이해하기 쉬운가. 개인적으로는 퇴고를 할 때 글체도 다듬는 편인데, 불필요한 형용사나 부사, 접속사를 남발하지 않았는지 본다. (의외로 이런 경우가 많다)
기획서는 나 혼자 보는 글이 아니다. 설득하고 납득시키고 가끔은 강요도 해야 하는 것이 기획서다. 그러기 위해서는 “쉽고 간결한, 하지만 부실하지 않은” 글을 써야 한다.
