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