말로 던지면 알아서 정리되는 지식 창고: AI가 관리하는 PKM 세컨드 브레인 만들기 | 동작 원리·셋업 가이드

대상: 처음 접하는 분(1부) + 직접 세팅하려는 분(2부)  ·  형식: 설명 가이드  ·  2026-07-09

이 글은 그 시스템의 설명서다. 어떻게 동작하는지(1부), 그리고 직접 따라 만들려면 어떻게 하는지(2부)를 담았다. 왜 이렇게까지 만들었나 하는 분투의 이야기는 따로 세 편에 풀어뒀으니, 궁금하면 본문 곳곳의 링크를 따라가면 된다. 여기서는 완성된 구조를 차분히 뜯어본다.

1부. 개념과 사용법

먼저 이게 뭔지, 그리고 실제로 어떻게 쓰는지. 코드 한 줄 몰라도 읽히게 썼다.

01 한 문장으로

"떠오르면 말로 던지고, 정리는 AI에게 맡기는 개인용 지식 창고." 이 한 문장이 전부다.

핵심 차이는 딱 하나다. 보통의 메모 앱은 사람이 폴더를 정하고, 태그를 붙이고, 나중에 찾아 들어간다. 이 시스템은 그 일을 AI가 대신하니까 사람은 형식을 안 지켜도 된다.

발상을 뒤집은 이유는 단순하다. 메모를 아무리 많이 쌓아도 정리할 시간이 없으면 결국 더미가 되거든. 그래서 읽고 정리하는 주체를 사람이 아니라 AI로 바꿨다. 내가 할 일은 생각났을 때 한 줄 던지기뿐이고, 분류·요약·연결·최신화는 시스템이 맡는다.

사실 이건 지난 이야기의 다음 장이다. 노트 수백 개를 AI가 빠르게 쓰게 만든 과정은 온톨로지를 시도하다 더 가벼운 걸 찾은 기록에 썼고, 쌓인 지식이 실행까지 순환하게 만든 하루는 스스로 진화하는 지식 시스템에 있다. 이 글은 그 결과물을 정면에서 설명한다.

02 전체 동작, 세 칸으로 보기

구조는 세 칸이면 다 그려진다. 사람 → AI → 창고. 가운데 AI가 비서 역할을 한다.

사람은 던지기만, AI는 정리를, 창고는 보관과 검색을 맡는다. 비밀은 창고 맨 위에 놓인 규칙 파일 하나에 있다. CLAUDE.md라는 이름의 사용설명서다.

AI는 작업을 시작하기 전에 이 파일을 먼저 읽는다. "이런 말이 들어오면 이렇게 처리해라"가 전부 적혀 있어서, 매번 다시 가르치지 않아도 늘 같은 방식으로 일한다. 이 한 파일이 시스템의 뇌이자 계약서다.

03 두 얼굴, 사람은 옵시디언 AI는 클로드

같은 텍스트 파일을 두 쪽에서 다루는데, 사람에게는 보는 화면이 필요하고, AI에게는 정리하는 손이 필요하다.

이미지: 백엔드는 클로드, 프런트엔드는 옵시디언. 한 파일 더미를 두 얼굴이 공유한다.

화면이 두 개다. 사람은 옵시디언(메모 앱)으로 대시보드·캘린더·그래프를 보고, AI는 클로드 코드(Claude Code)로 규칙대로 파일을 만든다. 둘 다 똑같은 .md 텍스트 파일 위에서 일한다.

그래서 AI가 만든 걸 사람이 옵시디언에서 바로 보고, 사람이 캘린더에서 옮긴 걸 AI가 읽는다. 무거운 정리·생성·검색은 클로드가, 매일 눈으로 확인하고 체크하고 드래그하는 건 옵시디언 대시보드가 맡는다.

옵시디언이 없어도 파일은 그대로 열리는데, 캘린더나 그래프 같은 보는 맛만큼은 옵시디언이 준다. 뒤에서 보겠지만 이 프런트엔드는 있으면 좋은 옵션이지, 시스템의 필수는 아니다.

04 창고는 어떻게 생겼나, 폴더 구조

집에 비유하면 빠른데, 방마다 역할이 정해져 있고, 물건이 어느 방에 있는지가 곧 그 물건이 무엇인지를 말해준다.

이미지: 위치가 곧 의미다. 어느 방에 있느냐가 분류를 대신한다.

폴더는 여섯 개에 규칙 파일 하나다. 00-inbox는 일단 던지는 캡처함, 01-core는 늘 읽는 규칙, 02-skills는 필요할 때 꺼내는 방법 문서, 03-reference는 정제된 지식, 04-context는 진행 중인 프로젝트, 05-outputs는 완성 산출물이다. 99-archive는 손대지 않는 창고 뒤편이다.

이 배치의 핵심은 위치가 곧 의미라는 점이다. 파일이 어느 폴더에 있는지만 봐도 본문을 열지 않고 분류를 안다. AI도 사람도 길을 헤맬 일이 없거든.

05 정보 한 조각이 정리되는 과정

아이디어 하나가 들어와서 제자리를 찾기까지를 따라가 보자. 던질 때는 한 곳, 정리는 세 갈래다.

무엇이 떠오르면 자연어로 한 줄, 00-inbox에 일단 쌓인다. 여기서 사람의 일은 끝나고, 나중에 "inbox 처리해줘" 한마디면 AI가 캡처를 열어보고 세 갈래로 나눈다.

재사용할 지식이면 03-reference로, 진행할 일감이면 04-context로, 버릴 것이면 99-archive로. 사람은 이 분류를 고민하지 않는다. 던질 때 한 곳만 알면 되고, 나머지는 판단의 몫을 AI에게 넘긴 셈이다.

06 프로젝트는 4단계로 자란다

하나의 일이 생각에서 실행으로, 운영으로, 돌아보기로 자란다. 이 흐름을 한 파일에 욱여넣지 않고 단계마다 별도 파일로 남긴다.

이미지: 단계를 덮어쓰지 않고 나란히 남긴다. 그래서 나중에 한 흐름으로 다시 읽힌다.

기획·구현·운영·회고, 네 단계가 각각 자기 파일을 가진다. 그래서 "이 프로젝트 처음부터 끝까지 보여줘"라고 하면 AI가 1에서 4까지 순서대로 깔끔하게 모아 보여준다. 맥락이 끊기지 않는다.

숨은 보너스가 하나 있다. 회고에서 "글로 쓸 만하다" 싶은 건은 블로그 글감으로, "실력 증명" 싶은 건은 포트폴리오 항목으로 표시된다. 나중에 "블로그 후보 정리해줘" 한마디면 글 재료가 모인다.

기록이 그대로 콘텐츠 자산이 되는 구조인데, 이 되먹임을 시스템 전체에 배선한 이야기가 바로 스스로 진화하는 지식 시스템 편이다. 쌓기만 하면 죽은 창고, 순환이 돌면 산 시스템이라는 게 요지다.

07 일정과 태스크, 별도의 한 축

"언제까지 뭘 해야 한다"는 일반 메모와 성격이 다르다. 그래서 할 일과 일정은 전용 입력 파일(00-inbox/일정-태스크.md)에서 따로 관리된다.

내가 자연어로 말하면 AI가 옵시디언 Tasks 문법으로 형식화해 넣고, 캘린더와 Tasks 플러그인, 그리고 일정·태스크 패널 대시보드가 그걸 시각화한다. 나는 #task나 날짜 기호를 직접 쓸 일이 없다.

카드를 옮길 땐 입력 파일에서 체크박스를 대기에서 진행중, 완료로 바꾸면 패널이 자동 갱신된다. 우선순위도 입력 파일의 마커로 표기된다. 겉으로는 예쁜 칸반이지만, 밑바탕은 여전히 텍스트 파일 한 장이다.

08 실제로는 이렇게 쓴다

기억할 명령어는 없다. 그냥 평소 말투로 던지면 되고, 아래 왼쪽이 내가 던지는 말이고, 오른쪽이 그때 일어나는 일이다.

핵심은 이거다. #task나 폴더 규칙을 사람이 외울 필요가 없다. 그건 전부 AI가 채우거든. 사람은 무엇을 원하는지만 평소 말로 전하면 된다.

09 그래서 무엇이 좋아지나

기능 목록보다 중요한 건 일상이 어떻게 바뀌느냐다. 네 가지로 정리된다.

이미지: 던질 때는 한 곳으로. 분류는 시스템이 세 갈래로. 사람은 어디에 넣을지 고민하지 않는다.

정리 부담이 0이 된다. 분류·태그·폴더를 고민하지 않는다. 던지면 끝인데, 무슨 더미가 쌓이겠나. 다시 찾기 쉽다. 같은 형식과 이름표로 쌓여서 "그거 보여줘" 한마디로 꺼낸다.

맥락이 안 끊긴다. 프로젝트가 단계별로 이어져, 몇 달 뒤에도 흐름을 그대로 복원한다. 기록이 자산이 된다. 잘된 일은 자동으로 블로그와 포트폴리오 재료로 쌓인다.

형식은 AI가, 생각은 내가. 정리에 쓰던 시간을 생각하고 던지는 데 쓴다.

2부. 동작 원리와 직접 만들기

여기서부터는 이 시스템을 직접 만들거나 이식하려는 사람을 위한 부분으로, 내부 동작과 단계별 셋업을 본다.

이미지: 특별한 앱도 서버도 없다. 표면은 텍스트 파일 더미, 그 밑에서 규칙과 스크립트가 돈다.

한 장으로 요약하면 이렇다. AI가 읽는 규칙 파일(CLAUDE.md) + 정해진 폴더 구조 + 인덱스를 만드는 파이썬 스크립트 몇 개가 전부다. 특별한 앱도, 서버도, 데이터베이스도 없다. 평범한 텍스트 파일 더미이고, 그 위에서 클로드 코드(또는 GPT·Codex)가 규칙을 읽고 일하며, 폴더째 복사하면 그대로 이식된다.

10 핵심 동작 하나, 세션마다 일어나는 로딩 절차

AI가 일을 시작할 때 "무엇을 읽을지" 고르는 방식이 첫 번째 장치이고, 이게 비용을 좌우한다.

모든 지식을 매번 읽으면 비싸고 느리다. 여기서 비싸다는 건 토큰, 즉 AI가 글을 읽고 쓰는 양에 비례하는 요금을 말한다. 그래서 항상 읽을 것(규칙)과 필요할 때만 읽을 것(지식)을 나눈다.

이 분기를 결정하는 건 파일 맨 위 꼬리표(머리말)의 load_priority 값이다. always면 매번 읽고, on-demand면 필요할 때만 열고, locked면 아예 안 본다.

여기서 왜 하필 "최대 3개"냐가 중요하다. 지식 파일이 수백 개라도, 한 작업에 실제로 필요한 건 보통 두세 개다. 각 파일 머리말의 use_when("이런 상황에 쓰는 파일")을 보고 AI가 매칭한다.

적게 읽을수록 빠르고, 싸고, 정확하다. 이건 직관과 반대거든. 다 읽으면 더 똑똑할 것 같지만, 관련 없는 문서가 많이 딸려 들어올수록 답이 흐려지고 요금만 오른다. 무엇을 안 읽을지 정하는 게 무엇을 읽을지 정하는 것만큼 중요하다.

실제로 이 로딩이 얼마나 도는지, 어떤 파일이 실제로 다시 읽히는지를 5주간 로그로 측정한 이야기가 내 AI가 나를 학습하는 줄 알았다 편이다. 재부상률을 실측해 보니 생각보다 낮았고, 그게 이 "적게 로드" 원칙을 더 단단하게 만들었다.

11 핵심 동작 둘, Digest 색인

진행 중인 프로젝트가 100개여도 파일 100개를 다 열지 않고, 색인 하나만 읽는다. 이게 두 번째 장치다.

프로젝트 문서는 단계별로 계속 늘어난다. "진행 중인 거 보여줘" 한마디에 수십 개 파일을 일일이 여는 건 낭비다. 그래서 각 파일의 머리말만 뽑아 한 줄짜리 JSON으로 모은 색인(_digest.jsonl)을 둔다.

AI는 이 색인 하나만 먼저 읽고 전체 상태를 파악한 뒤, 필요한 파일만 골라 연다. 상태를 파악하는 비용이 파일 개수와 무관하게 일정해진다는 게 핵심이다. 책 뒤에 붙은 찾아보기(색인)를 떠올리면 된다. 본문을 다 읽지 않아도 어디에 뭐가 있는지 안다.

같은 발상이 지식 폴더에도 적용된다. build_index.py는 02-skills와 03-reference 각 파일의 머리말 설명을 모아 도메인별 목차(index.md)를 자동 재생성한다. 그래서 10번 절차의 "도메인 목차 읽기"가 늘 최신 목록을 가리킨다.

이 가벼운 색인으로 갈아탄 배경에는 실패가 하나 있다. 처음엔 형식 온톨로지 같은 무거운 구조를 시도했다가, 토큰만 먹고 실익이 없어 접었다. 그 시행착오는 온톨로지를 시도하다 더 가벼운 걸 찾은 기록에 정직하게 적어뒀다.

12 전체 아키텍처, 4개 층으로 보기

위에서 아래로 네 층이다. 진입, 항상 읽는 규칙, 필요할 때 읽는 지식, 그리고 작업과 자동화.

위 두 층(진입·규칙)은 운영체제에 해당하고, 아래 두 층(작업·자동화)은 데이터와 도구에 해당한다. 99-archive는 어느 층에서도 읽지 않는다. 이 분리가 있어야 "규칙은 안정, 지식은 증식"이 충돌 없이 굴러간다.

13 데이터 모델, 머리말이 곧 데이터베이스

파일 본문은 사람이 읽고, 머리말은 기계가 읽는다. 이 머리말이 색인·검색·리마인더의 원천이고, 데이터베이스 없이 데이터베이스 역할을 하는 자리다.

프로젝트 문서는 파일명과 머리말에 구조가 박혀 있는데, 파일명은 {단계번호}_{단계}_{슬러그}.md 꼴이고, 머리말은 14개 필드다. 코드처럼 보여도 겁먹을 것 없다. 그냥 파일 맨 위에 붙은 꼬리표이고, 사람이 읽는 본문은 그 아래에 따로 있다.

# 04-context/2_구현_갤럭시워치.md 의 머리말
---
title: "갤럭시워치 페이지"
lifecycle: 구현            # 기획 | 구현 | 운영 | 회고
domain: engineering       # 5개 도메인 중 하나
role: [기획, 바이브코더]    # 4역할 중 복수 (아래 참조)
project: "갤럭시워치"       # 묶음 키, 같으면 같은 프로젝트
status: in-progress       # planning|in-progress|paused|completed
next_review: 2026-06-23   # 리마인더 트리거 (이번 주 할일 계산)
next_action: "비교표 카피 확정"
outcomes: [{metric: CTR, value: "+18%", period: Q2}]  # 정량 성과
blog_candidate: false
portfolio_candidate: true # 사용자 확인 후에만 true
---
# 빈 칸은 산문으로 채우지 않는다 → <!-- empty: source 미기록 --> (환각 방지)

여기 함정이 하나 숨어 있다. 빈 칸을 그럴듯한 문장으로 채우면 AI가 없는 사실을 지어내는 환각이 된다. 그래서 값이 없으면 산문 대신 "미기록" 표시를 남기게 규칙으로 박았다. 비어 있음을 정직하게 비워두는 게, 채워 보이게 만드는 것보다 낫다.

역할은 4개, 한 문서가 여러 모자를 쓴다

이 창고의 주인은 한 사람이 네 역할을 겸한다. 마케터·분석가·바이브코더·기획자다. role 필드를 복수로 달기 때문에, 문서 하나가 프로젝트 관리·블로그·포트폴리오를 동시에 충족한다. "포트폴리오 정리해줘"라고 하면 역할별로 묶여 나온다.

이 설계에는 이유가 있고, 그 이유가 곧 효과다.

14 운영 규칙, 이미지와 스프레드시트

매일 부딪히는 두 가지가 있다. 첨부 이미지 정리와 구글 시트 연동인데, 둘 다 매번 같은 실수를 부르는 자리라, 규칙으로 못박아 사고를 막는다.

이미지·에셋 규칙

• 모든 이미지는 그 파일이 속한 폴더의 assets/ 아래에 둔다. 폴더 루트에 두지 않는다.
• 본문 참조는 ![..](assets/파일명) 꼴로 (공백은 %20).
• 노션 export는 이미지를 루트에 쏟으므로, 정리 시 assets/로 옮기고 링크를 고친다.
• 일괄 정리는 organize_images.py (기본은 미리보기, 적용은 별도 플래그, 원본 백업).

스프레드시트 연결 규칙

• 구글 시트 읽기·쓰기는 항상 커넥터 스크립트(pkm_sheets.py) 하나로. 매번 인증을 새로 짜지 않는다.
• 인증 키는 .env의 경로만 참조하고, 레포에 키를 커밋하지 않는다.
• 대상 시트는 커넥터 계정 이메일에 편집자로 공유해야 열린다.
• 자주 쓰는 시트는 별칭으로 등록해 별칭으로 부른다.

규칙으로 박은 이유는 하나다. 이미지 경로가 깨지거나 시트 인증을 반복하는 실수는, 사람이 아무리 조심해도 다음 세션에서 또 난다. CLAUDE.md에 규칙으로 고정해두면 어느 세션의 AI가 와도 같은 방식으로 처리한다.

15 그대로 따라 만들기, 30분 셋업

앱 설치가 아니라 폴더와 규칙 파일을 만드는 일이다. 30분이면 뼈대가 선다.

STEP 1~2. 준비물과 폴더 뼈대. 필수는 둘뿐이다. 클로드 코드 CLI(또는 CLAUDE.md를 읽는 GPT·Codex)와 파이썬 3에 PyYAML. 선택은 클라우드 동기화, iOS 단축어, 시트용 서비스 계정 키다.

# 빈 폴더에서 한 번에 생성 (mac / linux / WSL)
mkdir -p my-pkm/{00-inbox,01-core,02-skills,03-reference,04-context,05-outputs,99-archive,templates,scripts}
cd my-pkm
mkdir -p 03-reference/{engineering,workflow,thinking,writing,marketing}

STEP 3. CLAUDE.md, 시스템의 뇌. 가장 중요한 파일이다. 도메인 분류, 폴더 구조, 그리고 작업 시작 절차(로딩 알고리즘)를 여기 적는다. 절차의 뼈대는 이렇다.

# CLAUDE.md 작업 시작 절차 (로딩 알고리즘)
1. 이 파일을 읽는다
2. 01-core/ 를 전부 읽는다 (always)
3. 요청을 분석해 도메인을 정한다
4. 그 도메인 index.md 를 읽는다
5. use_when 이 맞는 파일 최대 3개를 고른다
6. 로드 후 [로드: 경로] 를 출력한다

01-core/에는 세 파일을 둔다(모두 always). 말투와 역할을 담은 persona.md, 로딩·금지 규칙의 core-rules.md, 파일명과 머리말 규칙의 project-management.md다.

STEP 4~6. 스크립트, 첫 실행, 확장. 스크립트는 둘이면 시작된다. 프로젝트 색인을 만드는 build_digest.py와 지식 목차를 만드는 build_index.py. 둘 다 표준 라이브러리에 PyYAML만 있으면 된다.

첫 실행은 이렇게 확인한다. "테스트 기획 시작해줘"라고 하면 1_기획_*.md가 14필드를 갖춰 생기고, "진행 중인 거 보여줘"라고 하면 색인을 읽어 필터한다. 첫머리에 [로드: …]가 뜨면 정상이다.

확장은 전부 옵션이다. 1~5단계의 코어(마크다운 + CLAUDE.md + 스크립트 2개 + 클로드 코드)만으로 캡처·분류·프로젝트 관리·블로그와 포트폴리오 적재가 모두 돈다. 옵시디언은 보는 맛을 더하는 프런트엔드일 뿐, 코어를 대체하지 않는다.

16 마지막, 따라 할 때 지킬 6가지

구조를 다 봤으니, 이제 직접 만들 때 손에 쥐고 갈 원칙만 추리는데, 하나하나가 앞에서 이유까지 봤던 것들이다.

반대로, 이 시스템이 하지 않는 것도 분명하다. 사용자에게 기호를 직접 입력하라고 시키지 않고, 단계 전환 때 파일 이름을 바꾸지 않고, 빈 칸을 그럴듯한 문장으로 채우지 않는다. 안 하는 것을 정해두는 게 하는 것을 정하는 것만큼 시스템을 지킨다.

그래도 하나만 챙긴다면, 이것이다.

사람은 형식을 버리고 생각만 남기고, 형식은 전부 AI에게 넘긴다.

근거·출처

• 노트를 AI가 빠르게 쓰게 만든 과정 (온톨로지 시행착오): 노트 수백 개를 AI가 빠르게 쓰게 만들기
• 쌓인 지식을 순환하게 만든 하루 (되먹임 루프): 쌓이기만 하는 세컨드 브레인은 죽어 있다
• 로딩·재부상률 5주 실측 (적게 로드의 근거): 내 AI가 나를 학습하는 줄 알았다
• 클로드 코드 (AI 실행기): Claude Code 공식 문서
• 옵시디언 (프런트엔드): Obsidian

이 글은 필자 개인의 지식 관리 시스템을 설명한 가이드다. 폴더·필드 개수 등 수치는 2026년 7월 기준이며, 구성은 사람마다 달라질 수 있다.