위키 가드닝 규칙

내가 옵시디언에 노트를 정리하며 적용하고 있는 정리 규칙. 위키는 정원이랑 비슷하다. 완벽한 설계가 아니라 꾸준한 관리가 중요하다.

2025년 7월 18일의 모습:

폴더: 최소한으로 쓴다

폴더 구조는 단일한 관점에 기반한 배타적 분류를 강제하여 정보를 왜곡하거나 파편화하는 문제가 있으며 우연한 발견 가능성을 낮추기 때문에 지식 관리 시스템에 쓰기에 적절하지 않다. “계산생물학”에 대한 책은 “생물학” 분류에 담아도 이상하고 “전산학” 분류에 담아도 이상하다. 참고: 지배적 분해에 의한 폭정, 정보 구조는 나무가 아니다.

그러므로 폴더는 배타적 소속성이 분명한 경우에 한하여 최소한으로만 사용하며, 폴더를 여러 단계로 중첩해서 쓰지 않는다. 즉, 폴더 안에 폴더를 만들지 않는다.

현재 이 위키에서 사용 중인 폴더는 다음과 같다.

• /dates: 21세기, 2000년대 2005년, 2005년 8월 25일, 8월, 8월 25일 등 각종 날짜에 해당하는 문서
• /media: Wonder (영화) 등 영상 및 음악에 대한 문서
• /people: 한강 (작가), Petunia Dursley (소설 속 인물) 등 인물에 대한 문서
• /publications: 공리주의: 짧은 소개 등 책, 논문, 기사 등 출판물에 대한 문서
• /: 나머지 모든 문서는 분류하지 않고 최상위 폴더에 담는다.

꼭 특정 정보를 트리 구조로 정리할 필요가 있다면 페이지를 하나 만들고 해당 페이지 안에서 링크를 트리 구조로 정리하면 된다. 예: 내가 쓴 글들.

태그: 쓰지 않는다

태그 또는 포크소노미(folksonomy)는 폴더와 달리 배타적 소속성을 강제하지 않는다는 점에서 나은 면이 있지만, 관리하는 자료의 양이 증가함에 따라 태그의 이점은 점점 줄어든다. 왜냐하면 태그의 이점은 다음 두 조건이 성립해야만 발휘되기 때문이다.

• 태그가 지나치게 많지 않아야 한다: 태그가 너무 많아지면 관리 비용이 커지고 태그를 붙이거나 태그로 검색할 때 기억 부담이 커진다.
• 하나의 태그에 속한 자료가 지나치게 많지 않아야 한다: 특정 태그로 검색한 결과가 지나치게 많으면 검색의 효용이 낮아진다. 특히 랭킹(어떤 자료가 중요한지 우선순위를 세우기)을 부여하기 어렵기 때문에 더욱 그렇다.

그런데 자료가 늘어나면 위 두 가지 조건은 반드시 상충한다. 하나의 태그에 속한 자료가 지나치게 많지 않으려면 자료가 증가함에 따라 태그의 수도 선형적으로 증가해야 한다. 하지만 태그가 선형적으로 증가하면 태그가 지나치게 많아진다. 그러므로 자료가 많아지면 위 두 가지 조건이 동시에 만족될 수 없다. 태그를 처음 도입했을 때 깔끔하게 정돈되고 유용한 느낌이 드는 이유는 대체로 자료가 적기 때문이며, 자료가 어느 정도 쌓이면 유용성이 급격히 낮아지지만 습관적으로 계속 태깅을 한다.

태그에 다면 분류(faceted classification)를 적용하면 일부 문제를 개선할 수 있지만 관리와 사용이 복잡해진다. 게다가 태그로 할 수 있는 모든 일은 링크로도 할 수 있다. 이 위키에서는 옵시디언의 태그 기능을 쓰지 않고 위키 태그를 대신 쓰고 있다.

링크: 적극적으로 쓴다

따라서 폴더나 태그 대신 링크를 적극적으로 써서 정보를 분류한다. 링크와 폴더의 근본적인 차이 중 하나는 폴더가 트리 구조인 반면 링크는 그래프 구조라는 점에 있다. 트리는 특정한 제약이 있는 그래프의 일종인데 이 제약으로부터 오는 문제가 크다(참고: 도시는 나무가 아니다).

몇 가지 규칙들:

• 외톨이 없애기: 다른 문서와의 링크(역링크 포함)가 하나도 없는 문서를 외톨이(orphan)라고 부른다. 링크로만 구조화를 할 경우 외톨이 문서는 검색 이외의 수단으로 도달할 수 없으므로 외톨이가 있어서는 안된다. 가장 좋은 방법은 새 페이지를 만들 때 일단 기존 페이지 어디엔가서 링크를 걸어놓고 시작하는 것.
• 맥락 살리기: “관련 링크”만 따로 모아두는 방법보다는 되도록 본문 텍스트 안에 자연스럽게 링크를 걸어줘서 링크의 맥락을 살린다. 맥락 없이 “관련 링크”에 모여 있으면 어떤 점에서 관련이 있는지 따로 설명을 해야하기 때문에 좋지 않다.
• “See also”는 예외적으로만 허용: 맥락 안에 링크를 넣기 어려우면 임시로 “See also” 섹션에 담아둔다. 이 섹션에 링크가 많이 쌓이지 않도록 꾸준히 관리하는 게 좋다. 점진적으로 본문을 적당히 수정해서 본문 안으로 옮겨야 한다.
• 없는 문서에 링크 걸기: 대부분의 위키 엔진에서는 아직 만들어지지 않은 문서에 대한 링크를 미리 걸어둘 수 있는데 이 기능을 적극적으로 사용하면 좋다. 옵시디언을 쓴다면 “Dataview” 플러그인을 이용해서 “Most wanted pages” 목록을 자동으로 관리할 수 있다.
• 주요 엔티티에 링크 걸기: 인명, 지명, 날짜, 책 제목에는 반드시 링크를 건다.

링크를 꾸준히 걸어주려면 지속적인 노력이 필요한데 이는 단점보다는 장점에 가깝다. 새로 생긴 지식과 연결되는 기존 지식을 찾는 과정에서의 의식적 노력이 기억을 상기하고 머릿속에서 지식을 서로 연결시킬 수 있도록 장려하기 때문이다.

LLM이나 임베딩 모델을 걸 써서 자동으로 링크를 걸어줄 수 있겠지만 이런 식의 과도한 자동화는 좋지 않다. 과정에 담긴 가치를 잃을 수 있기 때문이다.

좋은 이름

문서 사이에 링크가 풍성하게 걸리려면, 그리고 링크가 글의 맥락 안에 자연스럽게 담기려면 문서의 이름을 잘 지어주는 게 중요하다. 프로그래밍을 할 때 변수나 함수 이름을 지어주는 것과 유사하게 충분히 구체적이면서도 되도록 간결하면 좋다.

이름을 잘 지으려면 각 문서가 되도록 단일한 내용을 담고 있는 게 좋다. 좋은 이름을 지어주기 어렵다면 문서를 적당한 단위로 분리하는 게 좋다.

이름에 의해 링크를 거는 방식은 위키의 가장 핵심적인 특징 중 하나다. 덕분에 아직 만들어지지 않은 문서로 향하는 링크를 미리 걸어둘 수 있게 된다.

옵시디언의 별칭 기능도 잘 활용하면 좋다.

기록보다 인출

기록 자체가 아닌 인출이 목적이어야 한다.

사람에 따라 “모든 것이 보존되었다”는 안전한 느낌을 선호하는 경우도 있을텐데 난 보존보다는 목적이 아니라 적극적 인출을 중요하게 여긴다. 이 관점에서는 기록되었으나 인출되지 않는 정보가 많은 건 나쁜 신호다.

외재화된 믿음

개인 위키는 단순히 정보 덩어리여서는 안된다. 필요한 게 방대한 정보 덩어리라면 위키백과를 쓰는 편이 낫다. 개인 위키는 외재화된 믿음이어야 한다. 어떤 정보가 내 위키에 담겨 있는 이유는 내가 의식적으로 검토하고 담기로 결정했기 때문이어야 한다.

예를 들어 LLM으로 생성한 내용을 면밀하게 검토하지 않고 복붙해서 담아서는 안된다. 생성한 내용을 담는 경우에는 반드시 GeneratedContentWarning 태그를 붙인다.

중복 제거

같은 내용을 여기저기 반복되게 적지 않는다. 코드 중복과 마찬가지 이유에서 나쁘다:

• 복사본 1을 고칠 때 항상 복사본 2도 고쳐야하므로 내용의 중복이 행위의 중복으로 이어진다.
• 복사본 1만 고치고 복사본 2는 고치지 않는 식의 실수를 해서 일관성이 낮아질 수 있다.
• 복사본 1로 향하는 링크와 복사본 2로 향하는 링크가 분산된다. (이는 코드 중복이 핫스팟을 분산시켜서 성능 최적화를 방해하는 것과 유사하다.)

점진적이고 꾸준한 관리

처음부터 완벽한 구조를 설계한 뒤에 정보를 모으기 시작하는 전략은 잘 작동하지 않는다. 또는 연례행사처럼 1년에 한 번 몰아서 거대한 “설계 변경”을 하는 방식도 좋지 않다.

정보 구조의 설계는 꾸준히, 점진적으로 해야 한다. 예:

• 찾기 어려웠던 문서에 링크 추가하기: 어떤 문서를 찾기가 어려워서 고생 끝에 간신히 찾았다면? 찾았으니 읽고 끝내는 대신 다음에 쉽게 찾을 수 있도록 적당한 관련 문서와 이어지는 링크들을 추가해주면 좋다. 한번에 정리를 완전하게 하는 게 아니라 꾸준히 가꾼다는 느낌.
• 긴 문서 분리하기: 어떤 문서의 내용 중 일부를 지칭하고 싶은 일이 자주 발생하면 문서의 해당 부분만 분리해서 별도의 문서로 만들어준다.

프로그래밍에서 말하는 리팩토링과 같다. 꾸준히 점진적으로 하기. 한번에 완벽하게 하려고 하지 않기. 오래 쌓아뒀다가 몰아서 하지 않기.

정량화

정량 목표를 정하고 점진적으로 개선하면 좋다.

지금 정한 목표:

• 문서들 사이의 최단 경로의 평균을 낮추기 (2025년 7월 현재 평균 최단 경로는 4.9)

정량 목표 예시:

• 처음에는 외톨이 문서 줄이기가 목표였다. 모든 문서가 어딘가에 연결되도록 관리하는 것.
• 외톨이 문서가 완전히 사라진 다음에는 분리된 그래프 줄이기가 목표였다.
• 분리된 그래프가 완전히 사라진 다음에는 임의의 두 문서 사이를 이어주는 최단 경로의 길이 줄이기를 목표로 하고 있다. (현재 상황)

규칙에 대한 규칙

• 정리된 결과가 아니라 정리하는 과정에 담긴 가치도 고민하기. 과도한 자동화 경계하기.
• 무엇을 자동화할지 고민해보기. 특히 LLM 및 임베딩 활용할 방안:
  • 어디가 어떻게 엉망인지 힌트를 주고 내가 점진적으로 개선하도록(그 과정에서 내 생각도 더 정리되도록) 도와주는 방향으로. 예: 서로 다른 문서의 중복된 내용 찾아주기, 의미가 유사하지만 링크가 안걸린 문서를 찾아 링크 걸기를 (자동으로 해버리는 대신) 내게 제안하기.
• 규칙도 꾸준히 점진적으로 개선하기.

TODO

• 수정한지 가장 오래된 문서를 정기적으로 재검토할 방법
• 인용문을 잘 관리할 방법 찾기 (Bases와 호환되는 방법이면 좋으나 크게 중요하지는 않음. 호환은 좋지만 종속은 나쁨)
• Semantic Link 유사한 것 지원할 수 있으면 좋겠음