사용자 도구

사이트 도구


사이드바

메뉴:

블로그:

기타:


연락처:


안내:

blog:reduce-document-length

문서 길이 줄이기

팀원님의 문서를 검토하다가 예상한 길이에 비해 문서 길이가 엄청나게 길어 지레 겁부터 먹었습니다. 일단 긴 문서를 읽고싶지 않았을 뿐 아니라 요청한 주제는 이렇게까지 긴 문서를 필요로 하지 않을 거라고 예상했거든요. 일단 문서를 끝까지 읽으면서 요구사항을 만족하는지 확인해본 다음 어쩌다가 이 주제의 문서가 이렇게까지 길어졌는지를 생각해보기 시작했습니다.

문서는 일단 짧아야 합니다. 이전 시대에 비해 활자를 엄청나게 읽어대는 현대인들이지만 그들이 읽는 활자 덩어리는 점점 더 짧아지고 있다고 합니다. 이전 시대에는 읽을 수 있는 활자라고는 두툼하게 편집된 책이 전부였지만 한동안 블로그의 시대를 지나 지금은 그보다 더 짧은 마이크로블로깅(aka 트위터) 시대이고 또 활자를 벗어난 인스타그램의 시대이기도 하니까요. 문서는 짧아야 합니다. 그나마 활자를 읽는데 거부감이 적은 사람들이 매일같이 읽는 활자덩어리는 점점 더 짧아지고 있습니다. 이제 활자 길이거 길어져야 한다면 처음부터 길게 작성한 글 대신 짧은 글 여러 개를 짧은 호흡으로 이어붙인 글을 읽습니다. 이런 블로그에 긴 글을 적어도 그 누구도 읽지 않는 시대입니다. 문서는 짧아야 합니다. 문서는 읽는이에게 행동을 하도록 유도합니다. 기획서는 읽는 사람이 내용을 이해하고 개발하도록 만듭니다. 그런데 이 문서가 길다면 읽는 사람은 그 내용이 뭐든지간에 일단 겁부터 먹습니다. 실제로 이번 마일스톤에 구현할 항목은 첫 번째 챕터의 팝업 윈도우 하나뿐이지만 총 56페이지에 달하는 거대한 문서를 받는 순간 공포에 사로잡혀 서로 의도하지 않은 방어적인 자세로 변할 수도 있습니다.

문서는 짧게 써야 합니다. 짧게 쓰는데는 두어 가지 요령이 있는데 하나는 조금 더 어려운 방법, 다른 하나는 조금 더 쉬운 방법입니다. 여기서 어려운 방법을 잘 설명할 생각은 없으니 짧게 이야기하고 지나가면 문서를 MECE하게 작성하는 겁니다. 위키피디아 한국어판의 설명에 따르면 '상호배제와 전체포괄'이라고 하는데 내용에 중복된 부분이 없어야 하고 동시에 빠진 부분도 없어야 한다는 겁니다. 긴 문서를 읽다 보면 생략할 수 있는 중복이 자주 등장합니다. 앞에 한번 나온 개괄 설명이 뒤에 나오는 작은 항목을 설명하는데 다시 복사된 채 인용되기도 하고 서로 비슷비슷해 차이점만 나열하면 될 인터페이스 디자인이 여러 번 나타나기도 합니다. 또 같은 항목에 작은 옵션이 달라지는 형태로 정리할 수 있을 개념이 서로 아예 다른 개념으로 큰 챕터를 차지하고 나타나기도 합니다. 이런 중복을 줄이는데 MECE의 '상호배제'부분이 중요한 역할을 합니다. 다음 부분인 '전체포괄'은 난이도가 조금 더 높은데 전체를 포괄하기 위해 게임의 최상위 목표로부터 연관되어 내려오는 요구사항의 전체 트리를 파악하고 내가 담당한 트리와 하위 요소를 파악해 이들을 포괄할 시스템을 고안해내야 하기 때문입니다. 사실은 주니어분들께 이걸 잘 요구하지는 않습니다. 실제로 한번에 해내기 어렵고 현대의 게임 개발은 중간에 요구사항이 광범위하게 변경되는 일이 잦기 때문이기도 합니다. 몇 번 겪으면 일반적인 인간은 멘탈이 깨질 수 있거든요. 하지만 '상호배제'부분은 어렵지 않게 실천해 문서 길이를 줄일 수 있는 확실한 방법입니다.

좀더 쉬운 방법들이 있습니다. 눈속임일 수 있지만 많은 페이지 수로 독자에게 겁을 주는 것 보다는 낫습니다. 지난번에 이야기한 문단간격의 연장입니다. 일단 서양의 서술식 문서에 더 적당한 문단간격 설정을 동양의 개조식 문서에 더 적합한 모양으로 바꿉니다. MS워드 기본 서식에 '본문'과 '본문 (간격없음)'의 차이를 인식하고 사용해야 합니다.

전통적으로 문서에 꼭 집어넣던 항목이 정말 문서에 필요한지를 고민해야 합니다. 가령 표지와 목차와 히스토리가 정말 필요한지 고민해보세요. 표지는 이 문서가 길다는 인상을 첫 페이지부터 줍니다. 표지는 정말 필요한 정보를 전달하고 있나요? 아니면 다른 모든 기획서에 표지가 있으니까 나도 따라하고 있나요? 팀 외부로 공유할 예의를 갖춘 문서가 아니라면 표지는 필요없습니다. 부서 이름, 날짜도 필요없습니다. 사실은 쓴사람 이름도 필요없습니다. 이 모든 항목은 과거에 문서를 팀 외부로 인쇄해서 공유할 때 필요했습니다. 표지에는 부서, 책임자, 작성일, 결재선이 표시되어 있어야 했고 일단 결재선을 통과한 문서는 그대로 진행해야 했습니다. 또 문서는 문서 자체만 공유되므로 히스토리도 중요했습니다. 누가 언제 무엇을 고쳤는지 히스토리가 없으면 파악할 방법이 아예 없었으니까요. 하지만 현대 개발팀에서 문서는 웹 기반의 위키에 올라가 있거나 MS워드로 작성한다 하더라도 높은 확률로 형상관리시스템에 올라가 있을 겁니다. 누가 언제 무엇을 고쳤는지는 형상관리시스템의 로그에 더 잘 기록되어 있을 테고 문서 공유 역시 이 시스템을 통하므로 더이상 표지와 히스토리에 시간을 낭비할 필요가 없습니다. 문서를 커밋할 때 메시지를 잘 작성하는 습관만 남기세요.

목차도 필요없습니다. 목차는 문서가 길고 챕터 구조가 복잡할 때 사용합니다. 누군가는 목차를 잘 작성하면 목차만 보고도 문서의 내용을 파악할 수 있으므로 문서를 잘 구성하고 목차에 잘 드러나도록 해야 한다고도 말합니다만 제 생각은 다릅니다. 목차는 이 문서가 길다는 신호이고 목차 스스로도 문서를 더 길게 만듭니다. 문서를 짧게 만드는 노력을 기울이기 시작하면 굳이 목차가 필요 없는 수준으로 페이지가 줄어들고 굳이 목차를 빌어 요약을 제시할 필요도 없어집니다. 만약 필요하다면 목차 대신 실제 요약문을 문서 앞부분에 제공할 수도 있습니다. 굳이 목차 형식을 빌리지 않고서도요.

마지막으로 팀에 공유되는 문서 템플릿에 위에 이야기한 없앨 수 있는 모든 것이 들어있을 수 있습니다. 또 내가 가진 결정권이 없거나 거의 없는 것처럼 느껴진다면 문서를 개선해볼 생각 자체가 안 들 수도 있습니다. 하지만 팀의 문서 템플릿은 헌법이 아닙니다. 헌법조차도 시대의 흐름에 따라 수정되는 마당에 팀 표준 문서 템플릿이 이를 사용하는 사람들에게 자연스럽게 문서를 길게 쓰도록 유도하고 있다면 이는 따라야 할 대상이 아니라 바로잡아야 할 대상입니다.

문서는 짧은 편이 더 낫습니다. 읽는 사람이 겁먹지 않게 해 목표를 더 잘 달성할 수 있습니다. 문서를 짧게 쓰는데는 상호배제와 전체포괄의 원칙을 사용해야 하는데 상호배제가 당장 실천하기 더 쉽습니다. 문서의 형식에 따라 스타일 옵션에 신경쓰고 표지, 목차같은 불필요한 항목을 삭제하면 쉽게 문서 길이를 줄일 수 있습니다. 형상관리도구를 사용한다면 히스토리는 문서 안에 있을 필요가 없으모 형상관리도구를 사용하는 표준 규칙을 잘 따르기만 하면 됩니다. 비교적 간단한 방법으로 문서 길이를 줄일 수 있습니다.

blog/reduce-document-length.txt · 마지막으로 수정됨: 2019-12-15 11:46 저자 neoocean