기획자의 지식트리 아키텍처
흔들리지 않게 만드는 3축 설계
기획자의 지식트리를 정리하려고 마음먹는 순간, 거의 반드시 마주치는 문제가 있다.
“이렇게 분류하면 저기서 흔들리고, 저렇게 분류하면 여기서 흔들린다.”
분류가 흔들리는 이유는 대개 하나다. 한 가지 기준으로 모든 걸 담으려 하기 때문이다.
업무는 흐름을 갖고, 지식은 형태를 갖고, 보관은 수명을 갖는다.
이 셋을 한 칸에 넣으려 하면 트리는 꼬일 수밖에 없다.
이 글은 어디 교과서에 정리된 이론이라기보다, 계속 흔들리던 분류를 멈추게 만든 개인의 방식에 가깝다.
나는 이 구조를 **‘HAKO 지식트리 v1.0’**이라고 부르기로 했다.
1. PKM 대분류에서 흔한 3대 아키텍처 타입
업무 흐름 기준만 쓰면: 데이터/기술/조직 같은 교차 지식이 섞여 트리가 꼬인다.
자산 형태 기준만 쓰면: “언제/왜 쓰는지” 맥락이 약해진다.
PARA만 쓰면: PM/PO 업무 역량과 산출물 재사용 구조가 약해진다.
그래서 실무적으로는 한 기준으로 통일하려는 시도를 멈추고, 애초에 ‘3축(3-layer)’로 분리하는 방식이 가장 덜 흔들린다.
2. 추천 표준: “3축 지식 아키텍처”
핵심은 단순하다.
폴더(보관) 는 단순해야 한다 → PARA
목차/탐색(업무 맥락) 은 업무 흐름이 가장 직관적이다 → Why~Run
재사용/AI(자산 형태) 는 형태가 핵심이다 → Evidence/Decision/Template…
즉, 옵시디언의 노트는 항상 3개의 좌표를 갖는다.
어디에 두나(PARA) / 언제 쓰나(업무 흐름) / 어떤 자산인가(형태)
이 3축은 노트 상단 메타데이터로 고정하는 게 가장 효과적이다.
예를 들어 자산 형태는 asset_type 같은 필드로 붙여 두면, 검색과 재사용이 흔들리지 않는다.
이 좌표가 생기는 순간, 분류는 “정답 맞히기”가 아니라 "좌표 찍기”가 된다. 흔들릴 이유가 줄어든다.
3.표준안 제안
A. 보관: PARA (폴더/공간 운영)
Projects / Areas / Resources / Archive
→ 폴더는 “어디에 둘지”만 해결한다. 의미를 과적하지 않아서 충돌이 줄어든다.
B. 업무 맥락: 기획 업무 흐름(탐색용)
Strategy & Business (Why)
Discovery & Research (Problem)
Definition & UX (What)
Delivery & Execution (How)
Operations & Growth (Run)
Enablers (Cross-cutting): Data/AI, Tech/Architecture, Org/Process, Legal/Security, Comms
→ “지금 내가 하는 일” 기준으로 찾기 쉬워서 운영 난이도가 낮다.
C. 자산 형태: 재사용/AI용(가장 중요)
Evidence (출처/근거/리서치 요약)
Decision (결정로그: 선택/대안/근거/리스크)
Pattern/Playbook (반복 해결법)
Template/Checklist (재사용 가능한 문서 틀)
Artifact (최종 산출물: PRD/정책/가이드/기획서)
Prompt/Automation (AI 프롬프트/워크플로/에이전트 규칙)
→ 지식이 재사용 가능한 단위로 쌓여서 RAG/에이전트 연결이 쉬워진다.
4.운영 규칙: 흔들림을 막는 5문장
폴더는 PARA로만: 폴더에서 의미를 과도하게 만들지 않는다
탐색은 업무 흐름으로: Why~Run에 맞춰 “지금 단계”를 태그/필드로 준다
재사용은 자산 형태로: Evidence/Decision/Template… 중 하나를 반드시 부여한다
도메인은 태그로: 이커머스/호스팅/CRM은 대분류가 아니라 태그/속성으로 둔다
결정은 반드시 남긴다: 지식의 가치는 ‘정보’보다 결정+근거에 있다
5.“자기화”를 만드는 최소 구조: 모든 노트에 꼭 3줄
분산된 지식이 “내 것”이 되려면, 노트가 최소한 이 3가지를 가져야 한다.
What: 핵심 요약(1~3문장)
So what: 내 해석/적용 포인트
Now what: 다음 행동/연결(링크, 템플릿, TODO)
이 3요소가 있어야 AI가 붙었을 때도 노트가 “저장물”이 아니라 생성 재료가 된다.
6.AI 연결 관점에서, 이 구조가 유리한 이유
RAG/에이전트는 결국 세 가지를 먹고 자란다.
잘 쪼개진 지식 단위
일관된 메타데이터
재사용 가능한 템플릿
자산 형태(Evidence/Decision/Template…)가 있으면 검색/조합 정확도가 올라간다.
특히 Decision·Pattern·Template 비중이 늘수록, PRD/정책/가이드 같은 문서가 “그럴듯한 글”이 아니라 근거 기반 산출물로 생성된다.
7.바로 적용하는 7단계: 판단 부담을 줄이는 순서
흩어진 자료를 일단 Resources에 몰아넣기
자료마다 asset_type만 먼저 붙이기 (Evidence/Decision/Template…)
그 다음에 업무 단계(Why~Run) 를 붙이기
반복되는 것을 Pattern/Template로 승격
결정은 Decision 로그로 따로 분리
상위 요약 페이지(MOC)로 연결
AI는 Template + Decision + Evidence부터 연결
MOC는 관련 노트들을 한 페이지에서 묶어주는 “요약/목차 허브”다.
8.“좌표 찍기”가 되면 분류가 멈춘다
어떤 자료든 먼저 “이건 뭐냐(자산 형태)”를 고르고
그 다음 “지금 어느 단계에서 쓰냐(업무 흐름)”를 고르고
마지막으로 “어디에 보관하냐(PARA)”로 수명을 결정한다
분류는 더 이상 흔들리는 나뭇가지가 아니라, 좌표를 찍는 지도 작업이 된다.
그리고 그 지도 위에서, 기획은 더 빨리 재사용되고 더 정확히 자동화된다.