리브랜딩과 함께 개발본부 Confluence 공간을 정리하면서 대분류를 만들고 01_기획 처럼 번호 접두를 붙여 순서를 정했다. 몇 달 뒤에 보니 그 분류를 아무도 쓰지 않고 있었다.
Table of contents
Open Table of contents
배경 — 미리 만든 다섯 갈래
01_기획·02_설계·03_개발·04_운영·05_기타 로 나누고 앞에 번호를 붙였다. 겉으로는 깔끔했지만 새 문서를 만들 때마다 어디에 넣을지 고민하게 됐다.
Jenkins 배포 절차서가 설계인지 운영인지 애매하고 외부 거래소 API 규격이 설계인지 개발인지도 애매했다. 애매한 것은 전부 05_기타 로 갔다.
증상 — 기타가 절반이 됐다
세어 보니 05_기타 가 나머지 넷을 합친 것보다 컸다. 한쪽으로 몰렸다는 것은 분류가 실제와 안 맞는다는 신호였다.
05_기타 안을 열어 보니 그 안에 다시 갈래가 있었다. 회의록과 외부 연동 규격과 장애 기록과 LDAP 계정 권한이 각각 덩어리를 이루고 있었다.
판단 기준 — 실제 갈래로 다시 나눈 기준
두 가지 방법이 있었다. 다섯 갈래를 그대로 두고 05_기타 안에만 하위 폴더를 파는 것과, 기타 안에서 나온 갈래로 상위를 다시 잡는 것이다. 뒤쪽을 골랐다. 이유는 기타 안의 하위 폴더는 결국 상위 다섯과 같은 층위의 것이라 두 층으로 갈라질 이유가 없어서다. 대신 기존 링크가 전부 깨져 Confluence 이동 기록에 의존해야 하는 것을 감수했다. 회의록과 외부 연동과 장애 기록과 운영 절차와 설계 다섯이 되었고 기타는 세 건으로 줄었다.
미리 정하고 채우는 것이 아니라 무엇이 있는지 보고 정하는 순서였다. 처음에 만든 다섯은 일반적인 개발 단계였지 이 문서들의 실제 갈래가 아니었다.
번호 접두가 뜻하는 것
번호는 순서를 정하려고 붙였는데 이 폴더들에 순서가 필요한 일이 없었다. 번호가 있으면 새 갈래를 중간에 넣을 때 뒤를 전부 다시 매겨야 한다. 인수인계 때 받은 0.문서 부터 13. 인수인계 까지의 폴더가 바로 그 상태였다.
다만 전부 뺀 것은 아니고 V20210303__ 마이그레이션 파일처럼 순서가 곧 실행 순서인 자리에는 남겼다. 번호가 무엇을 뜻하는지 있으면 두고 보기 좋으려고 붙인 것이면 뺐다.
깊이와 검색
경로를 깊게 나누면 찾을 때 여러 단계를 열어야 하고 어느 깊이에 넣을지가 또 애매해진다. 두 단계까지만 두고 그 안에서는 이름으로 구분해서 이름 정렬이 폴더 구분과 비슷한 효과를 내게 했다.
분류는 찾기 위한 것인데 찾는 다른 방법이 있으면 분류에 힘을 덜 써도 된다. 문서 앞에 라벨과 관련 항목을 적어 Confluence 검색이 잘 되게 하는 편이 분류를 정교하게 다듬는 것보다 쉬웠다.
정리
- 분류를 미리 정하고 채우면 실제와 안 맞는다
- 무엇이 있는지 보고 나서 갈래를 정한다
05_기타가 커지면 분류가 안 맞는다는 신호다- 기타 안을 열면 실제 갈래가 나온다
- 번호 접두는
V20210303__처럼 순서에 뜻이 있을 때만 붙인다 - 보기 좋으려고 붙이면 새 것을 중간에 못 넣는다
- 깊이가 깊으면 어느 깊이에 넣을지가 또 애매해진다
- 검색이 잘 되게 하는 편이 분류를 다듬는 것보다 쉽다