11장. Knowledge Tree와 운영 규칙
앞 장에서 Organize의 출발점은 객체와 분류 체계라고 설명했다.
그렇다면 다음 질문은 이것이다.
그 구조를 실제로 어떻게 흔들리지 않게 고정할 것인가.
개인지식관리는 한두 번 정리해서 끝나는 시스템이 아니다.
매일 새로운 입력이 들어오고, 프로젝트가 바뀌고, 예외가 생긴다.
이런 환경에서 구조를 유지하려면 사람의 기억에만 의존하면 안 된다.
구조는 파일명 규칙, 위치 규칙, 메타데이터 규칙, 링크 규칙으로 외부화되어야 한다.
이 장에서는 그중에서도 Knowledge 구조를 대표 사례로 설명한다.
하지만 고정해야 하는 것은 Knowledge만이 아니다.
Evidence와 Decision도 같은 원리로 구조화되어야 Organize 전체가 흔들리지 않는다.
[도식: fig-knowledge-tree-structure-lock] — Knowledge Tree, 파일명, 메타데이터, 링크 규칙이 함께 구조를 고정한다
Knowledge Tree는 지식을 축적하는 기준축이다
Knowledge Tree는 재사용 지식을 어디에 어떻게 둘지 정해주는 구조다.
중요한 점은 이것이 단순 폴더 목록이 아니라는 점이다.
기획자가 다시 꺼내 쓸 수 있는 지식을 어떤 축으로 분류할지 결정하는 운영 모델이다.
예를 들어 어떤 개념은 도메인 축으로 갈 수 있고, 어떤 기법은 AI 활용 축이나 업무 방법론 축으로 갈 수 있다.
이 축이 있어야 같은 성격의 지식이 한곳에 모이고, 이후 Distill 단계에서 패턴을 보기 쉬워진다.
Knowledge Tree의 역할은 두 가지다.
첫째, 지금 어떤 위치에 두어야 하는지 판단 기준을 제공한다.
둘째, 나중에 유사한 지식을 모아보고 연결할 수 있게 만든다.
같은 원리는 Evidence와 Decision에도 적용된다
Knowledge Tree가 재사용 지식의 기준축이라면, Evidence와 Decision에도 각자의 구조 기준이 필요하다.
Evidence는 어떤 유형의 근거인지, 어디서 수집되었는지, 어떤 판단과 연결되는지가 드러나야 한다.
Decision은 언제 어떤 맥락에서 내려졌는지, 어떤 근거를 참조했는지, 무엇을 포기하고 무엇을 선택했는지가 드러나야 한다.
즉 Organize에서 고정해야 하는 것은 특정 폴더 하나가 아니라 객체별 운영 규칙이다.
Knowledge는 Tree와 축으로, Evidence와 Decision은 유형과 연결 기준으로 구조를 고정한다.
이 기준이 함께 있어야 입력이 들어왔을 때 어디에 둘지 덜 흔들리고, 나중에 다시 찾을 때도 맥락을 복원할 수 있다.
파일명 규칙은 입력 순간의 판단을 단순하게 만든다
개인지식관리는 매번 새로 고민하면 오래 못 간다.
그래서 파일명만 봐도 노트의 유형이 보이게 만드는 규칙이 필요하다.
예를 들어 용어-*, 개념-*, 산출물-*, 프레임워크-*, 기법-*, 체크리스트-*, MOC-* 같은 규칙은 단순하지만 강력하다.
이름에서 유형이 먼저 드러나면 작성자도 덜 흔들리고, AI도 더 안정적으로 분류와 초안 생성을 도울 수 있다.
같은 원리로 Evidence와 Decision도 파일명이나 제목만 봐도 성격이 보이게 만드는 편이 좋다.
예를 들어 근거-*, 의사결정-* 같은 규칙을 쓰면 검색과 연결이 쉬워지고, 프로젝트 노트나 허브에서 관련 객체를 묶어보기에도 수월해진다.
파일명 규칙의 장점은 검색에서도 드러난다.
같은 유형의 노트를 빠르게 묶어볼 수 있고, 특정 주제의 지식이 어떤 형태로 쌓였는지 한눈에 파악하기 쉽다.
메타데이터는 구조를 반복 가능하게 만드는 장치다
메타데이터는 구조의 본질이 아니라 반복성을 보장하는 장치다.
같은 유형의 노트에 같은 핵심 속성이 들어가야 나중에 정렬, 탐색, 자동화가 가능해진다.
Knowledge Note라면 최소한 이것이 어떤 유형의 노트인지, 어떤 축에 속하는지, 어떤 상태인지가 드러나야 한다.
Decision 쪽 노트라면 결정 시점, 맥락, 관련 근거와의 연결이 드러나야 한다.
Evidence 쪽 노트라면 근거 유형, 출처, 수집 시점, 신뢰도 같은 정보가 드러나야 한다.
이 정보가 일정하게 들어가야 Dataview, MOC, 링크 탐색, AI 보조가 모두 안정적으로 작동한다.
따라서 메타데이터는 부가 옵션이 아니라 운영 규칙의 일부다.
다만 메타데이터가 많다고 좋은 것은 아니다.
지속 가능하려면 꼭 필요한 정보만 남겨야 한다.
링크와 허브가 있어야 구조가 살아난다
파일명과 메타데이터만으로는 충분하지 않다.
개인지식관리는 연결 구조가 살아 있어야 한다.
어떤 개념 노트는 관련 산출물 노트와 연결되어야 하고, 어떤 체크리스트는 특정 프레임워크와 묶여야 한다.
Decision Log는 관련 Evidence Note와 이어져야 하고, Project 허브는 현재 맥락의 핵심 노트들을 묶어줘야 한다.
그래서 Organize는 저장보다 연결이 중요하다.
폴더 안에 잘 넣는 것보다, 어떤 노트가 어떤 판단과 어떤 지식으로 이어지는지 링크가 보이게 만드는 것이 더 중요하다.
MOC나 허브 노트도 이 맥락에서 이해해야 한다.
이들은 단순한 목차가 아니라, 흩어진 노트를 다시 의미 있는 흐름으로 묶어주는 연결 장치다.
구조를 고정해야 AI도 안정적으로 협업할 수 있다
AI는 구조가 없을 때도 초안은 만들 수 있다.
하지만 구조가 없으면 초안의 품질이 들쭉날쭉해지고, 기존 노트와의 관계도 불안정해진다.
반대로 Knowledge Tree, 파일명 규칙, 메타데이터, 링크 기준이 정해져 있으면 AI는 훨씬 정확하게 도울 수 있다.
어떤 입력이 어느 축으로 가야 하는지, 기존 노트를 업데이트해야 하는지, 어떤 유형의 초안이 맞는지 더 일관되게 제안할 수 있다.
결국 구조를 고정하는 이유는 사람만 편하려는 것이 아니다.
사람과 AI가 같은 규칙 위에서 협업할 수 있게 만들기 위해서다.
좋은 구조는 확장을 막지 않고 확장을 흡수한다
개인지식관리는 시간이 지날수록 새로운 유형이 생기고, 예외도 늘어난다.
좋은 구조는 이를 억지로 막는 구조가 아니라, 기본 규칙 위에서 예외를 흡수할 수 있는 구조다.
예를 들어 새로 등장한 방법론을 당장 큰 폴더 개편 없이도 개념, 프레임워크, 기법 중 어디에 놓을지 판단할 수 있어야 한다.
실행 과정에서 반복되는 패턴이 보이면 체크리스트나 가이드로 승격할 수 있어야 한다.
관련 노트가 충분히 많아지면 MOC로 묶을 수도 있어야 한다.
즉 구조를 고정한다는 말은 구조를 굳힌다는 뜻이 아니라 확장 규칙까지 포함해 운영 기준을 명확히 만든다는 뜻이다.
이 장의 결론
구조를 고정한다는 말은 구조를 굳힌다는 뜻이 아니다. Knowledge Tree, 파일명 규칙, 메타데이터, 링크 기준을 명확히 만들어 사람이 매번 새로 고민하지 않아도 같은 방식으로 운영할 수 있게 만드는 것이다. 규칙이 외부화되어야 기억에 의존하지 않아도 되고, AI도 그 규칙 위에서 일관되게 협업할 수 있다. 이 원리는 Knowledge에만 해당하지 않고 Evidence와 Decision에도 함께 적용된다.
좋은 구조는 확장을 막지 않고 확장을 흡수한다. 예외가 생겨도 기본 기준 위에서 판단할 수 있어야 하고, 반복되는 패턴이 보이면 새로운 유형으로 수용할 수 있어야 한다. 다음 장에서는 이 구조 위에서 AI가 Organize 단계에서 실제로 어떤 일을 맡을 수 있는지 살펴본다.