최근에 다른 팀 디자이너에게 기능 요구서를 적을 일이 있었다. 합을 맞춰본 적이 없으니 내가 쓰는 표현을 이해하지 못할 것 같아 평소 같으면 생략했을 부분까지 기재하는 등 조금 더 명확하게 적으려고 했다. 그리고 문서를 전달하면서 질문이 있으면 편히 물어봐달라는 코멘트도 남겼다. 전달하는 순간까지도 더 명확하게 쓸 수 있는 부분이 보였기 때문에 이해하실 수 있을까? 하는 걱정이 있었다. 그러나 우려한 것과 다르게 별다른 질문 없이도 내 의도와 일치한 디자인을 해주셨다. 디자인하는데 필요 없는 내용도 들어갔겠구나 하면서 문서를 잘못 작성했다고 생각했다.
문서화는 얼마나 디테일하냐에 따라 호불호가 많이 갈리고, 심지어 작성된 문서로 일을 얼마나 잘하는지 역량 판단 기준으로 활용되기도 한다. 그리고 문서를 디테일하게 쓰는 것에는 장점이 많다. 첫째로는 읽는 시간을 낭비하지 않을 수 있다. 문서를 읽는 사람에게 가장 좋은 문서는 읽으면서 무엇을 해야 하는지 바로 떠오르는 글인데, 중간에 이런저런 논의내용이 쭉 나오다가 마지막에 할 일이 기재되어 있으면 정리도 어렵고 불필요한 내용을 읽은 것 같기도 하다. 둘째로는 세부 내용을 기억하지 않아도 된다. 고려사항이 많아지다 보면 세세한 내용은 기억이 잘 나지 않고, 경우에 따라선 애매하게 정리되기도 하는데 문서화가 되어 있으면 애매한 부분 없이 무엇을 해야 하는지 확인할 수 있다. 또, 같이 논의한 사람이 나중에 다른 소리를 했을 때, 적절한 근거 자료로 활용되기도 한다. 마지막으로 중간에 다른 사람이 합류했을 때, 진행 상황에 대한 소통이 편하다.
하지만 위에서 말한 장점들은 문서화의 장점이지 문서를 쓰는 이유가 되지는 않는다. 기능 요구서를 쓰는 이유는 '무엇을 해주세요'라는 내용 전달이다. 수단일 뿐인 문서에 집착해 너무 많은 시간을 쓰는 건 올바르지 않다. 문서는 대충 쓰고, 만나서 5분 이야기하는 것이 전체적으로 나은 경우가 대부분이다. 또한 많이 사용되는 노션이나 컨플루언서 같은 문서 관리 솔루션에는 댓글 기능을 높은 수준으로 지원하기 때문에 이해하지 못한 세부 스펙에 대한 내용은 댓글을 통해 이야기할 수도 있다. 문서에 집착하지 않으면 메신저에서 한두 줄 이야기한 것이 제품으로 나오면서 팀의 속도를 더 높이는 결과를 만들기도 한다. 그리고 이것이 일의 본질에 더 가까운 행위라고 생각한다. 말은 이렇게 하지만 나도 대부분의 경우 몇 자라도 끄적여놓는 편인데, 결과를 적어두기에 알맞은 페이지가 테크스펙 문서이기 때문이다. 내가 거부하는 문서화는 이미 작성된 문서를 사후에 수정하는 것이다. 테크 스펙은 추가하는 것이지 지우고 다시 쓰는 것이 아니다. 그리고 계속 추가하는 것이기 때문에 처음에는 가볍게 작성할 수 있어야 한다. 본질에 집중하는 팀일수록 문서화는 수단에 가까워진다.
구독은 저에게 큰 힘이 됩니다.