10장.객체와 분류 체계를 먼저 설계한다
좋은 분류 체계는 나중에 찾기 쉽게 만들고 지금 넣기 쉽게 만든다
개인지식관리를 시작할 때 많은 사람이 비슷한 순서로 움직인다.
폴더를 먼저 만들고, 태그를 정하고, 템플릿을 늘린다.
처음에는 그럴듯해 보인다.
그런데 며칠만 지나면 금방 막힌다.
이건 어느 폴더에 넣어야 하는지, 태그를 무엇으로 붙여야 하는지, 새 템플릿을 또 만들어야 하는지부터 헷갈리기 시작한다.
정리가 안 되는 이유는 대개 부지런하지 않아서가 아니다.
정리의 순서가 뒤집혀 있기 때문이다.
Organize에서 먼저 답해야 하는 질문은 따로 있다.
나는 무엇을 어떤 객체로 관리할 것인가.
이 질문에 답하지 않으면 Organize는 정리가 아니라 배치가 된다.
파일은 계속 늘어나는데 같은 종류의 정보가 같은 방식으로 쌓이지 않는다.
나중에 검색은 되더라도, 그걸 다시 읽고 해석하는 비용이 계속 든다.
Organize의 출발점은 폴더가 아니라 객체다
객체는 관리 단위다.
기획자의 개인지식관리에서는 최소한 다음 객체가 분명해야 한다.
Evidence Note
Decision Log
Knowledge Note
Project / Hub / Index
Evidence Note는 사실, 관찰, 근거, 검증 결과를 담는 객체다.
Decision Log는 어떤 판단을 왜 내렸는지 남기는 객체다.
Knowledge Note는 다음 프로젝트에서도 다시 꺼내 쓸 수 있는 재사용 지식을 담는 객체다.
Project, Hub, Index는 이 객체들을 맥락별로 묶어주는 연결 객체다.
이 구분이 선명해야 같은 종류의 입력이 같은 방식으로 축적된다.
반대로 이 구분이 흐리면 익숙한 장면이 벌어진다.
회의 메모 한 파일 안에 근거도 들어 있고, 결정도 들어 있고, 개념 정리도 있고, 당장 해야 할 일까지 같이
들어 있다.
그날은 다 이해한 것처럼 보인다.
하지만 시간이 지나면 아무것도 쉽게 꺼내 쓸 수 없다.
무엇이 사실이었는지, 무엇이 판단이었는지, 무엇이 다음에도 다시 쓸 지식이었는지 다시 분리해야 하기 때문이다.
그래서 Organize의 첫 단계는 저장 위치를 정하는 일이 아니다.
먼저 관리 단위를 분명히 하는 일이다.
객체를 먼저 정해야 분류 체계도 의미가 생긴다
분류 체계는 객체 위에 올라가야 한다.
어떤 파일이 Evidence Note인지, Knowledge Note인지도 모른 채 폴더 구조만 먼저 만들면 분류가 아니라 적재가 된다.
보기에는 정리된 것 같아도 실제로는 그저 흩어진 파일을 칸에 넣어둔 상태에 가깝다.
예를 들어
개념-하네스 엔지니어링
같은 노트가 있다고 해보자.
이 노트를 어디에 둘지 고민하기 전에 먼저 정해야 할 것이 있다.
이것이 재사용 지식인지, 근거 기록인지, 의사결정 기록인지부터 확정해야 한다는 점이다.
객체가 정해져야 파일명도 따라오고, 위치도 따라오고, 메타데이터도 자연스럽게 따라온다.
같은 이유로 Decision OS와 Knowledge도 저장 위치보다 운영 기준이 먼저다.
Decision OS는 근거와 결정을 연결하는 객체 체계이고,
Knowledge는 재사용 지식을 일관되게 축적하는 객체 체계다.
어디에 저장할지보다 먼저, 무엇으로 다룰지를 정해야 한다.
이 순서가 맞아야 구조가 오래간다.
분류 체계는 찾기 위한 장식이 아니라 판단 비용을 줄이기 위한 장치다
많은 사람이 분류 체계를 검색 보조 도구처럼 생각한다.
나중에 쉽게 찾으려고 폴더를 나누고 이름을 붙인다고 여긴다.
물론 그 기능도 있다.
하지만 실제로 더 중요한 기능은 따로 있다.
입력이 들어오는 순간의 판단 비용을 줄이는 것이다.
메모 하나가 들어왔을 때 바로 판단할 수 있어야 한다.
이건 Evidence인가, Decision인가, Knowledge인가.
Knowledge라면 한 번 더 구분할 수 있어야 한다.
용어인가, 개념인가, 산출물인가, 프레임워크인가, 기법인가.
좋은 분류 체계는 바로 이 순간에 힘을 쓴다.
나중에 찾기 쉽게 만드는 동시에, 지금 넣기 쉽게 만드는 체계다.
이 차이는 생각보다 크다.
정리가 오래가지 않는 시스템은 대개 찾는 규칙만 있고 넣는 규칙이 없다.
그래서 막상 입력이 들어오면 매번 새로 고민하게 된다.
반대로 입력 순간의 기준이 있으면 Capture에서 Organize로 넘어가는 흐름이 훨씬 매끄러워진다.
지속 가능한 개인지식관리 구조는 대체로 이 판단 비용이 낮다.
객체와 분류 체계는 메타데이터 규칙으로 고정된다
객체와 분류 기준이 정해졌다면, 그다음은 그것을 반복 가능하게 만드는 일이다.
여기서 필요한 것이 파일명 규칙, frontmatter 규칙, 템플릿, 링크 기준 같은 메타데이터 규칙이다.
예를 들어 Knowledge Note는
개념-*, 기법-*, 체크리스트-*
처럼 이름에서 유형이 드러나게 만들 수 있다.
Decision Log는 결정 시점과 맥락이 드러나는 방식으로 기록할 수 있다.
이런 규칙이 있으면 사람이 넣을 때도 덜 흔들린다.
매번 “이번에는 어떻게 적지”를 다시 고민하지 않아도 되기 때문이다.
AI와 협업할 때도 마찬가지다.
구조와 규칙이 있으면 AI는 훨씬 더 안정적으로 분류를 돕고, 초안을 만들고, 연결 후보를 제안할 수 있다.
반대로 규칙이 없으면 AI도 그럴듯한 정리는 할 수 있어도 일관된 운영을 돕기는 어렵다.
중요한 점은 메타데이터가 본질은 아니라는 점이다.
메타데이터는 객체와 분류 체계를 반복해서 같은 방식으로 운영하기 위한 고정 장치다.
본질은 언제나 관리 대상과 객체 정의에 있다.
무엇을 어떤 단위로 다룰지 먼저 서지 않으면, 규칙은 많아져도 구조는 약해진다.
Organize는 저장이 아니라 검색 가능한 구조를 만드는 일이다
기획자의 개인지식관리는 많이 저장하는 시스템이 아니다.
다시 찾고, 다시 설명하고, 다시 조합할 수 있는 시스템이어야 한다.
Organize는 바로 그 조건을 만드는 단계다.
이 단계가 약하면 Distill도 약해진다.
패턴을 발견하려 해도 같은 종류의 정보가 같은 형태로 쌓여 있지 않기 때문이다.
Express도 약해진다.
필요한 근거와 지식을 꺼내기 어렵기 때문이다.
그래서 Organize의 핵심은 생각보다 단순하다.
무엇을 어떤 객체로 다룰지 먼저 정하고,
그 객체를 일관된 분류 체계와 규칙 안에 넣는 것.
정리는 예쁘게 배치하는 일이 아니다.
같은 종류의 정보가 같은 방식으로 쌓이게 만드는 일이다.
그래야 나중에 검색이 되고, 설명이 되고, 연결이 된다.
여기서부터 개인지식관리는 비로소 저장을 넘어 구조가 된다.
이 장의 결론
Organize의 출발점은 폴더가 아니라 객체다.
Evidence Note, Decision Log, Knowledge Note 같은 관리 단위를 먼저 정의해야 같은 종류의 정보가 같은 방식으로 쌓인다.객체가 정해져야 분류 체계도 의미가 생긴다.
분류 체계가 있어야 입력 순간의 판단 비용이 내려간다.
좋은 분류 체계는 나중에 찾기 쉽게 만드는 동시에, 지금 넣기 쉽게 만드는 체계다.
이 두 조건을 함께 만족시키려면 객체 정의와 분류 기준이 먼저 선명해야 한다.
다음 글에서는 이 구조를 실제로 흔들리지 않게 고정하는 방법,
특히 Knowledge Tree와 객체별 운영 규칙을 살펴본다.