Wiki gardening rules
- 2024-09-25 (modified: 2025-04-05)
- 별칭: 위키 가드닝 규칙
내가 옵시디언에 노트를 정리하며 적용하고 있는 정리 규칙. 위키는 정원이랑 비슷하다. 완벽한 설계가 아니라 꾸준한 관리가 중요하다.
폴더 안쓰기
폴더 구조는 단일한 관점에 기반한 배타적 분류를 강제하기 때문에 정보를 왜곡하거나 파편화하는 문제가 있으며 우연한 발견 가능성을 낮추기 때문에 지식 관리 시스템에 쓰기에 적절하지 않다. “생물철학”에 대한 책은 “생물학” 분류에 담아도 이상하고 “철학” 분류에 담아도 이상하다. 참고: 지배적 분해에 의한 폭정.
그러므로 폴더는 배타적 소속성이 분명한 경우에 한하여 최소한으로만 사용하며, 폴더를 여러 단계로 중첩해서 쓰지 않는다. 즉, 폴더 안에 폴더를 만들지 않는다.
현재 사용 중인 폴더는 다음과 같다.
/dates: 1984년, 2020년 5월 22일, 2000년대 등 날짜에 해당하는 문서/media: Wonder (영화) 등 영상 및 음악에 대한 문서/people: 한강 (작가), Petunia Dursley (소설 속 인물) 등 인물에 대한 문서/publications: 공리주의: 짧은 소개 등 책, 논문, 기사 등 출판물에 대한 문서/: 나머지 모든 문서는 분류하지 않고 최상위 폴더에 담는다.
태그 안쓰기
태그 또는 포크소노미(folksonomy)는 폴더와 달리 배타적 소속성을 강제하지 않는다는 점에서 나은 면이 있지만, 관리하는 자료의 양이 증가함에 따라 태그의 이점은 점점 줄어든다. 왜냐하면 태그의 이점은 다음 두 조건이 성립해야만 발휘되기 때문이다.
- 태그가 지나치게 많지 않아야 한다: 태그가 너무 많아지면 관리 비용이 커지고 태그를 붙이거나 태그로 검색할 때 기억 부담이 커진다.
- 하나의 태그에 속한 자료가 지나치게 많지 않아야 한다: 특정 태그로 검색한 결과가 지나치게 많으면 검색의 효용이 낮아진다. 특히 랭킹(어떤 자료가 중요한지 우선순위를 세우기)을 부여하기 어렵기 때문에 더욱 그렇다.
그런데 자료가 늘어나면 위 두 가지 조건은 반드시 상충한다. 하나의 태그에 속한 자료가 지나치게 많지 않으려면 자료가 증가함에 따라 태그의 수도 선형적으로 증가해야 한다. 하지만 태그가 선형적으로 증가하면 태그가 지나치게 많아진다. 그러므로 자료가 많아지면 위 두 가지 조건이 동시에 만족될 수 없다.
태그에 다면 분류(faceted classification)를 적용하면 일부 문제를 개선할 수 있지만 관리와 사용이 복잡해진다.
이 위키에서는 태그는 전혀 쓰지 않고 있다.
링크 적극적으로 쓰기
따라서 폴더나 태그 대신 링크를 적극적으로 써서 정보를 분류한다. 링크와 폴더의 근본적인 차이 중 하나는 폴더가 트리 구조인 반면 링크는 그래프 구조라는 점에 있다. 트리는 특정한 제약이 있는 그래프의 일종인데 이 제약으로부터 오는 문제가 크다(참고: 도시는 나무가 아니다).
몇 가지 규칙들:
- 외톨이 없애기: 다른 문서와의 링크(역링크 포함)가 하나도 없는 문서를 외톨이(orphan)라고 부른다. 링크로만 구조화를 할 경우 외톨이 문서는 검색 이외의 수단으로 도달할 수 없으므로 외톨이가 있어서는 안된다. 가장 좋은 방법은 새 페이지를 만들 때 일단 기존 페이지 어디엔가서 링크를 걸어놓고 시작하는 것.
- 맥락 살리기: “관련 링크”만 따로 모아두는 방법보다는 되도록 본문 텍스트 안에 자연스럽게 링크를 걸어줘서 링크의 맥락을 살린다. 맥락 없이 “관련 링크”에 모여 있으면 어떤 점에서 관련이 있는지 따로 설명을 해야하기 때문에 좋지 않다.
- “See also”는 예외적으로만 허용: 맥락 안에 링크를 넣기 어려우면 임시로 “See also” 섹션에 담아둔다. 이 섹션에 링크가 많이 쌓이지 않도록 꾸준히 관리하는 게 좋다. 점진적으로 본문을 적당히 수정해서 본문 안으로 옮겨야 한다.
- 없는 문서에 링크 걸기: 대부분의 위키 엔진에서는 아직 만들어지지 않은 문서에 대한 링크를 미리 걸어둘 수 있는데 이 기능을 적극적으로 사용하면 좋다. 옵시디언을 쓴다면 “Dataview” 플러그인을 이용해서 “Most wanted pages” 목록을 자동으로 관리할 수 있다.
링크를 꾸준히 걸어주려면 지속적인 노력이 필요한데 이는 단점보다는 장점에 가깝다. 새로 생긴 지식과 연결되는 기존 지식을 찾는 과정에서의 의식적 노력이 기억을 상기하고 머릿속에서 지식을 서로 연결시킬 수 있도록 장려하기 때문이다.
생성 AI 등을 잘 쓰면 자동으로 링크를 걸어줄 수 있겠지만 이런 식의 과도한 자동화는 좋지 않다. 과정에 담긴 가치가 있기 때문이다.
좋은 이름
문서 사이에 링크가 풍성하게 걸리려면, 그리고 링크가 글의 맥락 안에 자연스럽게 담기려면 문서의 이름을 잘 지어주는 게 중요하다. 프로그래밍을 할 때 변수나 함수 이름을 지어주는 것과 유사하게 충분히 구체적이면서도 되도록 간결하면 좋다.
옵시디언의 별칭 기능도 잘 활용하면 좋다.
점진적으로 꾸준히 관리하기
처음부터 완벽한 구조를 설계한 뒤에 정보를 모으기 시작하는 전략은 잘 작동하지 않는다. 또는 연례행사처럼 1년에 한 번 몰아서 거대한 “설계 변경”을 하는 방식도 좋지 않다.
정보 구조의 설계는 꾸준히, 점진적으로 해야 한다. 예:
- 찾기 어려웠던 문서에 링크 추가하기: 어떤 문서를 찾기가 어려워서 고생 끝에 간신히 찾았다면? 찾았으니 읽고 끝내는 대신 다음에 쉽게 찾을 수 있도록 적당한 관련 문서와 이어지는 링크들을 추가해주면 좋다. 한번에 정리를 완전하게 하는 게 아니라 꾸준히 가꾼다는 느낌.
- 긴 문서 분리하기: 어떤 문서의 내용 중 일부를 지칭하고 싶은 일이 자주 발생하면 문서의 해당 부분만 분리해서 별도의 문서로 만들어준다.
프로그래밍에서 말하는 리팩토링과 같다. 꾸준히 점진적으로 하기. 한번에 완벽하게 하려고 하지 않기. 오래 쌓아뒀다가 몰아서 하지 않기.