문서화 스킬을 기르기 위해

이번 포스팅에서는 개발자로서 갖춰야 하는 소프트 스킬 중 하나인 문서화 스킬의 대해 회고록을 통해 다뤄보고자 한다.

문서화 스킬은 개발자 간의 커뮤니케이션을 위한 도구 중 하나이며 말로 전달하는 것이 어려울 때 문서를 통해 전달하는 수단 중 하나이다.

또한 법적 근거를 남기기 위한 수단 중 하나이기도 하다.

대표적으로 요구사항 문서, RFP, WBS, 결함 문서, 업무일지 등 하나하나가 문서라고 표현할 수 있다.

따라서 나는 문서화 스킬을 기르기 위해 Github README.MD를 통해 다루고 외주 프로젝트 및 재능기부 프로젝트를 위해 요구사항 정리와 요구사항을 건네줄 문서화를 통해 진행을 하곤 하였다.

이때까지만 해도 문서화 스킬에 조금씩 자신감을 가지면서 할 수 있었다고 생각을 한 적이 있었다. 본인 스스로 아무리 문서화 스킬을 올렸다 해도 실제 현업에서 일하다 보면 어느 순간 한계점이 오기도 한다.

최근 나는 업무일지, 테스트 문서 등 잘 써보지 않은 것을 진행하다 보니 미숙함에 느껴 멘털이 나간 적이 있었다. 물론 이것도 앞으로 풀어 나가야 하는 과제 중 하나라고 생각한다. 특히 프리랜서에서 정규직으로 전환을 하고 싶다면 더더욱 헤쳐나갈 필요가 있다.

이것은 경력이 높은 개발자일수록 문서화 스킬은 더더욱 필요하기도 한다. 차후 본인이 팀장급이나 CTO가 된다고 하면 아직 접해보지 못한 WBS나 고객의 니즈를 충족시킬 RFP, 설계서, 기획안 문서 등 쓸 일은 많다고 판단한다

본인만 알아볼 수 있는 문서를 쓰는 것은 결코 문서의 의미가 전혀 없다. 문서가 길면 좋은 문서인가? 나 역시도 모든 것을 표현하려고 하는 성향이 강해 너무 상세하게 길게 쓰다가 실수가 많아지고 긴 글을 오래 보면 어느 순간 지루하게 느껴지기 때문에 퇴짜 맞은 적이 있다.

가장 좋은 건 짧고 간결하고 알아볼 수 있게 쓰는 것이 가장 중요한데 그 역시도 노하우를 터득하는 것도 내공이라고 생각한다.

사실 이 부분도 많이 해봐야 늘어나는 편이기도 하다. 결코 문서작업도 개발과 같다고 표현할 수 있다. 나 역시 개발 스킬뿐만 아닌 문서화 스킬의 대해 한계점을 알고 장기적인 계획을 위해 한계점을 돌파하기 위해 과제를 수행한다.

문서화 작업의 실패를 겪으면서 생긴 노하우는 너무 빠르게 하려는 마인드를 버리고, 시간을 너무 촉박하지 않게 잡고 진행하는 것이라 생각한다.

비록 느리지만 이것은 성장하기 위한 과제로 여길 것이다.