문서화의 6하원칙
이 글은 Dable - Zet team blog에 작성했던 블로그 포스트를 다듬어 재발행한 글이다. 어느 조직에서 일해도 집착적인 문서화는 업무를 원활하게 하는 조직의 코어 역량이다. 모두 문서화하고 광명 찾자!
일하기 좋은 팀은 어떻게 만들어질까? 각자가 생각하는 핵심이 있을 것이다. 나는 일하기 좋은 팀을 만들기 위해 가장 중요한 것은 다름 아닌 문서화라고 생각한다.
견고한 문서화는 팀의 커뮤니케이션 효율을 높인다. 결정한 사항에 대한 기록이 되어 있으면 커뮤니케이션에서 발생할 수밖에 없는 오해와 착오는 최소화할 수 있고, 스펙이 헷갈릴 때마다 찾아볼 수 있는 기획서가 꾸준히 업데이트되어 있으면 재확인에 드는 커뮤니케이션 비용이 획기적으로 줄어든다.
사실, 문서화의 이점을 모르거나 문서화를 안 하려는 팀은 없을 것이다. 잘 하고 싶어도 할 수 없거나 어떻게 할지 잘 모르는 일일 뿐이다. 오늘은 내가 Dable의 Zet team을 리드하며 어떻게 팀의 작업과 논의를 문서화하였는지 소개하고 실무에서 활용할 수 있는 팁을 공유해 본다.
Zet team의 문서화 방식
'왜'에 대한 부분은 모두가 충분히 아는 데다 서두에서 간략히 언급하였으니, 육하원칙 중 '왜'를 제외한 다섯 가지 항목으로 정리해 보았다.
어디서: 노션(Notion)&아사나(Asana)(or Jira or else)
최근 재택근무 시행으로 회식 기록은 드문드문 남기게 되었지만, 누구보다 먹는 것에 진심인 제트 팀의 회식 기록 페이지
줄글로 기록하는 모든 문서는 노션으로 일원화한다. 프리젠테이션 슬라이드나 피그마 파일 등 부득이하게 다른 형태를 취해야 하는 경우에도 노션에 해당 문서를 임베드해 노션 팀 페이지에서 필요한 문서를 모두 찾을 수 있다.
진행이 완료된 아사나 태스크 중 하나를 캡쳐해 봤다.
모든 태스크와 업무 핑퐁은 아사나에 기록하고 서브태스크와 코멘트 기능을 적극 활용해 업무 진행 상황을 트래킹한다. 내가 진행하거나 관여된 태스크가 아니라도 아사나의 태스크 카드만 보면 현재 그 태스크가 어떤 단계인지 확인할 수 있다. 지라 등 다른 협업 툴도 코멘터리 기능을 모두 제공하고 있으므로, 반드시 태스크에 관한 핑퐁은 활용하는 툴에 남겨두는 것으로 한다. 특히 다른사람에게 notify가 필요한 업데이트일수록 그렇다. 예를 들어, 요청한 기능의 디자인이 수정되었다던가 개발이 완료되었다던가, 혹은 개발 중에 스펙 변경의 필요성이 있으니 스펙 재검토를 요청한다던가 하는 등등.
Tip: 아사나의 서브태스크 기능을 잘 활용하면 어지럽게 얽혀 있는 일들의 위계를 한눈에 정리할 수 있어 매우매우 편리하다. 서브태스크의 서브태스크... 처럼 계속해서 서브태스크 depth를 추가할 수 있으므로 일단 큼직하고 모호한 일도 아사나에 적어둔 다음 서브태스크로 쪼개면 좋다.
무엇을: 모든 미팅, 태스크, 태스크의 수행 결과
우선, 커피챗을 제외한 팀의 모든 미팅은 진행할 때 기록자를 한 명 두고 노션에 미팅마다 새 노트를 축적한다. 기록의 길이는 상관 없다. 논의 시간과 기록의 길이가 언제나 비례하는 것도 아니다. 어떤 주제에 대해 어떤 논의를 했고, 어떤 결론이 도출되었는지만 확인할 수 있으면 된다.
앞으로 진행해야 하는 일은 아사나를 활용해 기록하고 있다. 크든 작든 모든 태스크는 반드시 아사나에 태스크를 생성해야 한다. 팀의 연간 및 분기별 마일스톤부터 업데이트된 스펙을 검토하고 확인하는 일까지 모두 적는다.
그리고 이 태스크의 수행 결과를 노션에 기록한다. 예를 들어, 기획자라면 그 결과물이 기획서가 될 것이고 개발자라면 해당 피처에 대한 기술 문서가 될 것이다. 결과에 대한 기록은 잦을 필요는 없지만 주기를 가지고 꾸준히 업데이트하는 것을 원칙으로, 내가 한 일에 대해 최대한 상세하게 적어 오버커뮤니케이션을 지향한다.
누가: 모두
문서화는 한 명만의 태스크가 아니다. 팀원 모두가 따를 수 있는 문서화 정책과 활용할 수 있는 템플릿을 제공한 상태에서, 기록이 필요한 상황을 마주한다면 누구나 문서화를 할 수 있어야 한다. 문서화에 익숙하지 않은 멤버가 있다 하더라도 각자의 영역은 각자 문서화를 진행하고, 팀 멤버가 이를 함게 살펴보며 가다듬을 수 있다. 도메인이 애매한 문서는 꾸준히 업데이트하는 담당자가 있기도 하다. 예를 들어, 팀 전체가 피처와 각각의 컴포넌트를 어떻게 부르는지를 정리하는 Terms and domains는 팀 리드가 한 주에 한 번씩 진척 상황을 반영해 업데이트한다.
Tip: 노션의 DB 기능을 활용해 기록 목적에 맞는 템플릿을 제공하고 기록을 일목요연하게 목록화할 수 있다. 개인적으로는 DB 기능만 제대로 활용해도 문서화에 필요한 수작업의 70% 이상이 해결된다고 본다.
어떻게(기록): 액션 아이템 위주로, 자세히 아카이빙(노션), 편하게 핑퐁(아사나)
미팅을 진행하고 미팅 노트를 남긴다 치자. 이때 어떤 내용을 남겨야 효과적인 기록일까? 사실 이 부분이야말로 문서화와 기록에 익숙해질수록 개인이 노하우를 쌓아 가는 영역이지만, 반대로 말하면 그만큼 애매모호한 영역이란 뜻이기도 하다. 몇 가지 기준을 세우면 큰 도움이 된다. 나는 아래와 같은 원칙을 세우고 이에 따른 미팅 노트 템플릿을 만들었다.
객관적인 정보를 남긴다: 누가 언제 어떤 주제에 대해 진행한 미팅인지 기록해 추후 관련 논의에 참여하게 됐을 때 누구에게 물어보면 될지 알 수 있음
속기록은 필요 없다: 오간 모든 논의의 내용을 기록하는 대신 팀원들이 알아야 할 결정사항과 논의사항만 남기면 됨
정보를 분류한다: 이 논의가 어떤 피처, 어떤 직군, 어떤 단계에 연관되어 있는지 라벨링해 찾기 쉽도록 함
아래는 Zet team의 미팅 노트 본문 템플릿이다. 여기에 태그를 붙이고, DB 테이블에는 최종 작성 일시와 최종 편집자가 보이도록 설정한다. 막상 옮겨놓고 보니 참 별 게 없는데, 원래 문서화라는 게 다 그렇습다. 하나하나 뜯어보면 생각보다 쉬운 일이다.
Info
진행 일시:
참여자:
기록자:
Discussion
주제:
결정사항
관련 링크(있는 경우에만 기재)
기타 사항(있는 경우에만 기재)
한편 미팅 노트가 아닌 업무 문서의 경우는 최대한 자세히 적어야 한다. 내가 어떤 의도로 어떤 일을 어떤 과정을 거쳐서 수행했는지, 스스로에겐 너무 당연해서 넘어가는 것들이 생각보다 많다. 자세히 적어야 한다는 것은 바로 그 부분을 포함한 기록을 말한다. 예를 들어, '당연한 일처럼' 특정 인풋 필드에 텍스트를 입력한 후 focus-blur를 하면 입력하거나 수정한 텍스트가 저장이 되어야 한다고 가정할 수 있지만 기획자가 이 부분을 적지 않는다면 개발자는 실제로 이 인풋 필드를 구현할 때 어떻게 수정이 이루어지는지 알지 못할 것이다.
아사나는 캐주얼한 커뮤니케이션 및 기록을 권장한다. 즉, 회의록이나 문서보다는 채팅에 가깝다. 주제별로 세분화된 슬랙처럼 쓰는 게 좋다. 그래야 즉각적인 반응과 소통이 가능해진다.
어떻게(정리): 일관된 기준을 가지고, 검색이 가능하도록, 투명하게
기록은 모두가 하는 게 맞지만 기록된 문서들의 체계화와 정리는 챕터와 팀 리드가 하면 좋다. 개인적으론 한 스코프에 한 명의 정리 담당이 있는 게 좋다고 생각한다. 예를 들어 Zet team의 개발 챕터의 기술 문서는 챕터 리드가 디렉토리화하고, 이 문서를 포함한 전체 디렉토리 정리는 팀 리드가 맡았다. 지나치게 복잡해지지 않도록 문서의 디렉토리를 꾸준히 업데이트하고 구조화한다. 프로덕트의 개발 주기에 따라 조금의 차이는 있겠지만, 최소 한 달에 한 번 정도는 문서의 체계화와 통폐합에 공을 들이는 것이 좋다.
동시에, 아무리 구조화를 하고 지속적으로 정리를 한다고 해도 체계란 것은 언제나 주관적일 수밖에 없기 때문에 한 사람에게 논리적인 구조가 다른 사람에게는 논리적이지 않을 수도 있다는 점을 염두에 두어야 한다. 이 부분을 보완하기 위해 모두가 동일하게 인지할 수 있는 라벨과 태그를 적극 활용해 문서를 분류한다. Zet team은 직군과 프로덕트, 문서의 종류(기획서, 기술문서와 같은)를 문서 공통 태그로 사용하고 있다.
마지막으로 각 문서의 최종 편집 일시와 편집자 등 문서에 대한 정보를 최대한 쉽게 확인할 수 있도록 전면에 드러내고 문서를 둘러싼 비공식적인 커뮤니케이션을 최대한 배제한다. 문서를 수정하거나, 수정을 했다거나, 삭제, 통합 등을 진행할 때 모두 이력이 있어야 하고 근거가 있어야 한다는 뜻이다. 결국 문서화도 각자의 리소스를 들이는 중요한 업무 중 하나이기 때문에 이를 존중하며 투명하게 문서를 관리해야 하는 것은 당연하다.
Tip: 팀 문서의 주제는 실무 기술문서부터 CoC와 팀 액티비티 기록까지 정말 광범위할 수밖에 없다. 디렉토리는 자연스럽게 복잡해지니 대분류가 다섯 가지를 넘어가도 놀라지 말자. 단, 편의성을 위해 열 개 이하의 대분류를 권장한다.
언제: 바로, 자주, 꾸준히
문서화는 미루면 망한다. 이것만큼은 단언할 수 있다. 미팅 기록은 미팅이 끝난지 30분만 지나도 부실해질 수밖에 없고, 방금 논의한 사항에 대한 기술 문서나 기획서의 업데이트를 슬쩍 미뤄두면 까먹고 말 것이다. 최선은 논의를 하는 중, 혹은 논의가 끝난 직후에 관련 문서를 작성하고 편집하는 것이나 줄회의나 긴급한 태스크 처리 등 즉석 문서화가 불가능한 상황이라면 차선책을 실천한다. 문서 업데이트를 별도의 태스크로 기록해 두고 매우 짧은 due date를 지정하는 것이다. 가급적이면 24시간 내에 정리하는 게 좋다.
또한 모든 문서는 끊임없이 업데이트하고 살펴봐야 한다. 한 번 기록하고 돌아서서 다시는 돌아보지 않는다면 문서의 가치는 급감한다. 문서화를 하는 목적을 다시 한 번 상기해 보자. 문서화는 최대 정보를 최소 시간에 공유할 수 있기 때문에 하는 거다. 그런데 기껏 공유받은 정보가 틀렸다거나, 낡았다거나, 더 이상 유효하지 않은 정보라면? 문서를 기반으로 작업하고 커뮤니케이션한다는 업무 원칙 자체가 위협을 받는 셈이다. 그래서 모든 팀 문서는 언제나 alive&active해야 한다. 업데이트가 필요한 문서는 원 문서 작성자이든, 아니든 눈에 띄는 대로 수정 및 보완할 수 있어야 하고, 이러한 수정과 보완을 모두가 당연하게 수용할 수 있어야 한다.
즉, 문서화에는 시간을 잘게 쓰는 게 제일 좋다. 업무 프로세스에 문서화를 포함시켜 생각하자. 다만, 잘게 자주 문서화를 진행해도 한 번씩 문서 정리 및 체계화, 회고 자체에 시간을 쏟아 파편화된 정보를 연결시켜야 하므로 문서화에만 집중하는 시간을 주기적으로 할당하는 것이 좋다. 나는 한 달에 한 번씩, 1~2일을 문서화 및 문서 정독 기간으로 두고 있다.
Tip: 나는 전체 업무 시간을 따졌을 때, 20% 가량을 크고 작은 문서화에 사용하면 적절한 비율이라고 생각하고 있다.
완벽한 답은 없다, 꾸준한 개선이 존재할 뿐
문서화는 시작과 끝이 없는 일이다. 끊임없는 유지보수가 필요하고, 처음엔 번거로울지도 모른다. 이런 것까지 써야 하나 싶기도 할 것이다. 하지만 문서화하는 습관이 조직에 제대로 자리잡기 시작하고 나면 업무 능률이 획기적으로 증가할 뿐만 아니라, 조직 구성원끼리의 신뢰도 두텁게 쌓인다. 혼란스러운 커뮤니케이션이 줄어들고 기억과 추론이 아닌 기록과 근거에 의거해 태스크를 진행할 수 있기 때문이다.
특히 린하게 일하는 조직일수록 문서화는 막강한 힘을 발휘한다. 문서화를 바탕으로 조직은 재빠른 의사결정과 방향성 변경에 의한 혼란을 최소화할 수 있고, 프로덕트의 스케일에 따라 급변하는 조직 구성원의 온보딩을 수월하게 진행할 수 있다. 각 조직과 개인에게 최적화된 문서화 프로세스를 세우고 이에 맞는 도구를 찾아 적극적으로 활용하자.
