11장. 널리지 트리와 객체별 운영 규칙으로 구조 고정

정리는 감각이 아니라 규칙으로 굳어져야 한다

객체별 운영 규칙으로 구조를 고정

앞선 글에서 Organize의 출발점은 객체와 분류 체계라고 말했다.

그렇다면 다음 질문은 자연스럽다.
그 구조를 실제로 어떻게 흔들리지 않게 유지할 것인가.

개인지식관리는 한두 번 정리하고 끝나는 시스템이 아니다.
매일 새로운 입력이 들어오고, 프로젝트는 바뀌고, 예외는 계속 생긴다.

이런 환경에서 구조를 유지하려면 사람의 기억에만 기대면 안 된다.
구조는 바깥으로 꺼내져 있어야 한다.

파일명 규칙, 위치 규칙, 메타데이터 규칙, 링크 규칙이 필요한 이유가 여기에 있다.
기억이 아니라 규칙으로 운영해야 같은 종류의 정보가 같은 방식으로 쌓인다.

이 장에서는 그중에서도 Knowledge 구조를 대표 사례로 설명한다.
하지만 고정해야 하는 것은 Knowledge만이 아니다.
Evidence와 Decision도 같은 원리로 구조화되어야 Organize 전체가 흔들리지 않는다.

Knowledge Tree는 지식을 쌓는 기준축이다

Knowledge Tree는 재사용 지식을 어디에, 어떻게 둘지 정해주는 구조다.

중요한 것은 이것이 단순한 폴더 목록이 아니라는 점이다.
기획자가 나중에도 다시 꺼내 쓸 수 있는 지식을 어떤 축으로 분류할지 정하는 운영 모델에 가깝다.

예를 들어 어떤 내용은 도메인 축으로 들어갈 수 있고,
어떤 내용은 AI 활용 축이나 업무 방법론 축으로 들어갈 수 있다.

이 기준축이 있어야 같은 성격의 지식이 흩어지지 않는다.
그래야 나중에 Distill, 즉 흩어진 기록에서 패턴을 끌어올리는 단계에서도 반복을 발견하기 쉬워진다.

Knowledge Tree가 하는 일은 두 가지다.

하나는 지금 이 지식을 어디에 둘지 판단 기준을 주는 일이다.
다른 하나는 나중에 비슷한 지식을 다시 모아보고 연결할 수 있게 만드는 일이다.

같은 원리는 Evidence와 Decision에도 적용된다

Knowledge Tree가 재사용 지식의 기준축이라면, Evidence와 Decision에도 각자의 구조 기준이 필요하다.
Evidence는 어떤 유형의 근거인지, 어디서 수집되었는지, 어떤 판단과 연결되는지가 드러나야 한다.
Decision은 언제 어떤 맥락에서 내려졌는지, 어떤 근거를 참조했는지, 무엇을 포기하고 무엇을 선택했는지가 드러나야 한다.

즉 Organize에서 고정해야 하는 것은 특정 폴더 하나가 아니라 객체별 운영 규칙이다.
Knowledge는 Tree와 축으로, Evidence와 Decision은 유형과 연결 기준으로 구조를 고정한다.
이 기준이 함께 있어야 입력이 들어왔을 때 어디에 둘지 덜 흔들리고, 나중에 다시 찾을 때도 맥락을 복원할 수 있다.

파일명 규칙은 입력 순간의 판단을 단순하게 만든다

개인지식관리는 매번 새로 고민하면 오래가기 어렵다.

그래서 파일명만 봐도 노트의 유형이 드러나는 규칙이 필요하다.

용어-*, 개념-*,산출물-*,프레임워크-*,기법-*,체크리스트-*,MOC-*

같은 방식이 대표적이다.

이 규칙은 단순해 보이지만 효과는 크다.

노트를 만드는 사람도 덜 흔들린다.
AI도 어떤 유형의 노트인지 더 안정적으로 파악할 수 있다.
검색할 때도 같은 유형의 노트를 빠르게 묶어볼 수 있다.

결국 파일명 규칙은 보기 좋게 정리하려는 장치가 아니다.
입력 순간의 판단 비용을 줄이고, 나중에 다시 찾는 비용까지 낮추는 장치다.

메타데이터는 구조를 반복 가능하게 만든다

메타데이터는 노트의 속성 정보다.
이 노트가 어떤 유형인지, 어떤 축에 속하는지, 어떤 상태인지를 일정한 형식으로 남기는 방식이다.

중요한 것은 메타데이터가 구조의 본질은 아니라는 점이다.
본질은 여전히 객체와 분류 체계에 있다.
메타데이터는 그 구조를 반복 가능하게 만드는 장치다.

같은 유형의 노트에 같은 핵심 속성이 들어가야
나중에 정렬도 가능하고, 탐색도 가능하고, 자동화도 가능해진다.

Knowledge Note라면 최소한 노트 유형, 속한 축, 상태 정도는 드러나야 한다.
Decision 쪽 노트라면 결정 시점, 맥락, 관련 근거와의 연결이 보여야 한다.

이 정보가 일정하게 들어가야 Dataview, MOC, 링크 탐색, AI 보조도 안정적으로 작동한다.

다만 메타데이터는 많다고 좋은 것이 아니다.
지속 가능하려면 꼭 필요한 정보만 남겨야 한다.
좋은 규칙은 정교한 규칙이 아니라 계속 쓸 수 있는 규칙이다.

링크와 허브가 있어야 구조가 살아난다

파일명과 메타데이터만으로는 충분하지 않다.
개인지식관리는 연결 구조가 살아 있어야 한다.

어떤 개념 노트는 관련 산출물 노트와 연결되어야 하고,
어떤 체크리스트는 특정 프레임워크와 묶여야 한다.
Decision Log는 관련 Evidence Note와 이어져야 하고,
프로젝트 허브는 지금 맥락에서 중요한 노트들을 한 곳에 묶어줘야 한다.

그래서 Organize에서는 저장보다 연결이 더 중요하다.

폴더 안에 잘 넣는 것만으로는 부족하다.
어떤 노트가 어떤 판단과 연결되고, 어떤 지식으로 이어지는지가 보여야 한다.

MOC(Map of Contents), 즉 관련 노트를 모아두는 허브 노트도 이 맥락에서 이해하는 편이 좋다.
단순한 목차가 아니라, 흩어진 노트를 다시 의미 있는 흐름으로 묶어주는 장치다.

구조를 고정해야 AI도 안정적으로 협업할 수 있다

AI는 구조가 없어도 그럴듯한 초안은 만들 수 있다.

하지만 구조가 없으면 초안의 품질은 쉽게 들쭉날쭉해진다.
기존 노트와 어떤 관계를 맺어야 하는지도 불안정해진다.

반대로 Knowledge Tree, 파일명 규칙, 메타데이터, 링크 기준이 정해져 있으면
AI는 훨씬 더 정확하게 도울 수 있다.

어떤 입력이 어느 축으로 가야 하는지,
새 노트를 만들지 기존 노트를 업데이트할지,
어떤 유형의 초안이 맞는지 더 일관되게 제안할 수 있다.

결국 구조를 고정하는 이유는 사람만 편해지기 위해서가 아니다.
사람과 AI가 같은 규칙 위에서 협업할 수 있게 만들기 위해서다.

좋은 구조는 확장을 막지 않고 흡수한다

개인지식관리는 시간이 갈수록 새로운 유형이 생기고 예외도 늘어난다.

좋은 구조는 이런 변화를 억지로 막는 구조가 아니다.
기본 규칙 위에서 새로운 것을 받아들일 수 있는 구조다.

예를 들어 새로 등장한 방법론이 생겼을 때
큰 폴더 개편 없이도

개념, 프레임워크, 기법

가운데 어디에 둘지 판단할 수 있어야 한다.

실행 과정에서 반복되는 패턴이 보이면
그것을 체크리스트나 가이드로 끌어올릴 수 있어야 한다.

관련 노트가 충분히 많아지면
MOC로 묶어 더 큰 구조로 연결할 수도 있어야 한다.

그러니 구조를 고정한다는 말은 구조를 굳힌다는 뜻이 아니다.
확장 규칙까지 포함해 운영 기준을 분명히 만든다는 뜻에 가깝다.

이장의 결론

구조를 고정한다는 것은 지식을 딱딱하게 묶어두는 일이 아니다.

Knowledge Tree, 파일명 규칙, 메타데이터, 링크 기준을 분명히 만들어
사람이 매번 처음부터 고민하지 않아도 같은 방식으로 운영할 수 있게 만드는 일이다.

규칙이 바깥으로 드러나 있어야 기억에 덜 의존하게 된다.
그리고 그래야 AI도 그 규칙 위에서 일관되게 협업할 수 있다.

이 원리는 Knowledge에만 해당하지 않고 Evidence와 Decision에도 함께 적용된다.

좋은 구조는 확장을 막지 않는다.
오히려 예외를 흡수하고, 반복을 받아들이고, 새로운 유형을 수용한다.

여기서 중요한 것은 단단함보다 운영 가능성이다.
계속 써도 무너지지 않는 구조인가, 그리고 시간이 지나도 다시 꺼내 쓸 수 있는 구조인가.

다음 글에서는 이 구조 위에서 AI가 Organize 단계에서 실제로 어떤 일을 맡을 수 있는지 이어서 보려고 한다.