# Wiki gardening rules

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

내가 [옵시디언](https://wiki.g15e.com/pages/Obsidian.txt)에 노트를 정리하며 적용하고 있는 정리 규칙. 위키는 정원이랑 비슷하다. 완벽한 설계가 아니라 꾸준한 관리가 중요하다.

2025년 7월 18일의 모습:

![Connected graph.png](Connected%20graph.png)

## 폴더를 쓰지 않는다

폴더 구조는 단일한 관점에 기반한 배타적 분류를 강제하여 정보를 왜곡하거나 파편화하는 문제가 있다. 예를 들어 "<계산생물학>"에 대한 책은 "<생물학>" 분류에 담아도 이상하고 "[전산학](https://wiki.g15e.com/pages/Computer%20science.txt)" 분류에 담아도 이상하다. 참고: [지배적 분해에 의한 폭정](https://wiki.g15e.com/pages/Tyranny%20of%20the%20dominant%20decomposition.txt), [정보 구조는 나무가 아니다](https://wiki.g15e.com/pages/Information%20structure%20is%20not%20a%20tree.txt).

주제에 따라 폴더를 만들고 정보를 격리하면 서로 다른 주제들 사이의 연결성을 우연히 발견할 가능성을 낮추는 부작용도 있다.

이런 이유로 폴더는 지식 관리 시스템에 쓰기에 적절하지 않다.

현재 이 위키에서는 폴더를 쓰지 않는다. 다만 옵시디언의 속성 기능을 (필요한 경우) 각 문서에 `type` 속성을 부여한다. 속성의 이름은 [schema.org](https://wiki.g15e.com/pages/schema.org.txt)의 타입 이름을 따른다. 예를 들어 인물은 `Person`, 책은 `Book`, 논문은 `ScholarlyArticle` 등.

꼭 특정 정보를 트리 구조로 정리할 필요가 있다면 그냥 문서를 하나 만들고 해당 문서 안에서 링크를 <트리 구조>로 정리하면 된다(예: [내가 쓴 글들](https://wiki.g15e.com/pages/Articles%20Ive%20written.txt)). 이 방식을 쓰면 자연스럽게 [다차원적 관심사 분리](https://wiki.g15e.com/pages/Multidimensional%20separation%20of%20concerns.txt)를 달성할 수 있고 폴더의 부작용을 최소화할 수 있다.

## 태그를 쓰지 않는다

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

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

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

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

## 링크를 적극적으로 쓴다

따라서 폴더나 태그 대신 링크를 적극적으로 써서 정보를 분류한다. 링크와 폴더의 근본적인 차이 중 하나는 폴더가 <트리 구조>인 반면 링크는 <그래프 구조>라는 점에 있다. 트리는 특정한 제약이 있는 그래프의 일종인데 이 제약으로부터 오는 문제가 크다(참고: [도시는 나무가 아니다](https://wiki.g15e.com/pages/The%20city%20is%20not%20a%20tree.txt)).

몇 가지 규칙들:

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

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

[LLM](https://wiki.g15e.com/pages/Large%20language%20model.txt)이나 [임베딩](https://wiki.g15e.com/pages/Embedding%20(machine%20learning.txt)) 모델을 걸 써서 자동으로 링크를 걸어줄 수 있겠지만 이런 식의 [과도한 자동화](https://wiki.g15e.com/pages/Over-automation.txt)는 좋지 않다. [과정에 담긴 가치](https://wiki.g15e.com/pages/Values%20in%20the%20process.txt)를 잃을 수 있기 때문이다.

## 좋은 이름을 지어준다

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

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

이름에 의해 링크를 거는 방식은 [위키](https://wiki.g15e.com/pages/WikiWikiWeb.txt)의 가장 핵심적인 특징 중 하나다. 덕분에 아직 만들어지지 않은 문서로 향하는 링크를 미리 걸어둘 수 있게 된다.

[옵시디언](https://wiki.g15e.com/pages/Obsidian.txt)의 별칭 기능도 잘 활용하면 좋다.

## 기록보다 인출이 중요하다

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

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

## 외재화된 믿음으로 쓸 수 있어야 한다

개인 위키는 단순히 정보 덩어리여서는 안된다. 필요한 게 방대한 정보 덩어리라면 [위키백과](https://wiki.g15e.com/pages/Wikipedia.txt)를 쓰는 편이 낫다. 개인 위키는 [외재화된 믿음](https://wiki.g15e.com/pages/Extended%20belief.txt)이어야 한다. 어떤 정보가 내 위키에 담겨 있는 이유는 내가 의식적으로 검토하고 담기로 결정했기 때문이어야 한다.

예를 들어 [LLM](https://wiki.g15e.com/pages/Large%20language%20model.txt)으로 생성한 내용을 면밀하게 검토하지 않고 복붙해서 담아서는 안된다. 생성한 내용을 담는 경우에는 반드시 [GeneratedContentWarning](https://wiki.g15e.com/pages/GeneratedContentWarning.txt) 태그를 붙인다.

## 중복을 제거한다

같은 내용을 여기저기 반복되게 적지 않는다. [코드 중복](https://wiki.g15e.com/pages/Duplicated%20code.txt)과 마찬가지 이유에서 나쁘다:

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

## 점진적으로 꾸준하게 개선한다

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

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

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

<프로그래밍>에서 말하는 [리팩토링](https://wiki.g15e.com/pages/Refactoring.txt)과 같다. 꾸준히 점진적으로 하기. 한번에 완벽하게 하려고 하지 않기. 오래 쌓아뒀다가 몰아서 하지 않기.

## 정량화한다

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

지금 정한 목표:

- 그래프의 지름(diameter) 낮추기. 지름이란, 가장 멀리 떨어진 두 노드 사이의 거리를 말한다.

정량 목표 예시:

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

## 규칙에 대한 규칙을 만들고 개선한다

- 정리된 결과가 아니라 정리하는 [과정에 담긴 가치](https://wiki.g15e.com/pages/Values%20in%20the%20process.txt)도 고민하기. [과도한 자동화](https://wiki.g15e.com/pages/Over-automation.txt) 경계하고 [과정에 대한 가치를 증강하는 방향으로](https://wiki.g15e.com/pages/Augmenting%20values%20in%20the%20process.txt) [LLM](https://wiki.g15e.com/pages/Large%20language%20model.txt)을 활용하기.
  - 어디가 어떻게 엉망인지 힌트를 주고 내가 점진적으로 개선하도록(그 과정에서 내 생각도 더 정리되도록) 도와주는 방향으로. 예: 서로 다른 문서의 중복된 내용 찾아주기, 의미가 유사하지만 링크가 안걸린 문서를 찾아 링크 걸기를 (자동으로 해버리는 대신) 내게 제안하기.
- 규칙도 꾸준히 점진적으로 개선하기.

## TODO

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