Skip to content
Published on

두 번째 뇌 재설계 — AI 시대의 개인 지식 관리(PKM)

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며 — 읽은 것은 많은데 남는 게 없다

HN 프론트페이지, GeekNews, 뉴스레터 대여섯 개, 회사 슬랙의 아티클 공유 채널. 우리는 역사상 가장 많이 읽는 세대지만, 일주일 전에 읽은 글의 내용을 설명해 보라고 하면 대부분 말문이 막힙니다. Hacker News에서 "Obsidian에 노트 4,000개가 있는데 아무것도 찾지 못한다"는 고백 글이 화제가 됐던 것도, GeekNews에서 로컬 LLM과 노트 결합 글이 반복적으로 상위에 오르는 것도 같은 갈증의 표현입니다.

2026년의 또 다른 배경도 있습니다. AI 코딩 에이전트가 보편화되면서 CLAUDE.md나 AGENTS.md처럼 에이전트에게 컨텍스트를 공급하는 문서를 쓰는 것이 새 관행이 됐습니다. 잘 정리된 개인 노트는 이제 사람만 읽는 것이 아니라, 내 AI의 컨텍스트 소스가 됩니다. 노트가 곧 나만의 RAG(Retrieval-Augmented Generation) 데이터베이스가 되는 시대입니다.

이 글은 고전 PKM 방법론의 핵심만 추리고, AI가 바꾼 부분을 명확히 한 다음, 수집-처리-연결-활용의 실전 시스템과 4주 구축 플랜을 제시합니다.

PKM 고전 빠른 정리 — Zettelkasten과 PARA

방법론 책 한 권을 읽을 필요는 없습니다. 핵심만 추리면 다음과 같습니다.

Zettelkasten — 연결이 지식을 만든다

사회학자 니클라스 루만이 평생 9만 장의 메모 카드로 책 70권을 쓴 시스템입니다. 핵심 원리 세 가지:

  1. 원자성: 노트 하나에 아이디어 하나. 그래야 연결이 가능해집니다.
  2. 자기 언어로: 인용 복사가 아니라 내 문장으로 다시 씁니다. 이 변환 과정이 곧 이해입니다.
  3. 연결 우선: 새 노트를 만들 때마다 "이건 어떤 기존 노트와 연결되나?"를 묻습니다. 지식은 노트 안이 아니라 노트 사이에 쌓입니다.

PARA — 행동 가능성으로 분류한다

Tiago Forte의 PARA는 폴더 구조론입니다. 주제가 아니라 행동 가능성 기준으로 4개만 둡니다.

P - Projects   : 마감이 있는 진행 중 작업 (예: 6월 블로그 리뉴얼)
A - Areas      : 마감 없이 계속 책임지는 영역 (예: 건강, 팀 운영)
R - Resources  : 언젠가 쓸 관심 주제 자료 (예: Rust, 요리 레시피)
A - Archives   : 끝났거나 비활성화된 것들

판별 질문은 하나입니다. "이 노트는 지금 무엇을 움직이는가?" 프로젝트를 움직이면 P, 책임 영역이면 A, 그냥 흥미면 R, 아무것도 아니면 Archives.

두 방법론 비교

항목ZettelkastenPARA
초점아이디어의 연결과 발효실행과 프로젝트 추진
단위원자적 영구 노트폴더와 문서
강점글쓰기, 연구, 장기 사고일 처리, 자료 회수 속도
약점초기 비용 높음, 과설계 위험깊은 연결 구조 부재
적합한 사람쓰는 사람, 연구하는 사람프로젝트 많은 실무자

결론부터 말하면 둘은 경쟁 관계가 아닙니다. 실무 자료 관리는 PARA로, 생각의 발효는 Zettelkasten 원리로 — 섞어 쓰는 것이 현실적인 답입니다.

AI가 바꾼 것 — 노트의 역할 재정의

검색에서 대화로

과거 노트의 회수 수단은 키워드 검색과 폴더 탐색이었습니다. 이제는 노트 전체를 임베딩해 두고 자연어로 질문합니다. "작년에 읽었던 분산 트랜잭션 관련 글에서 사가 패턴 단점이 뭐였지?"가 작동하는 쿼리가 됐습니다.

요약의 자동화 — 그러나 함정

읽을거리를 AI가 요약해 주는 시대에 "하이라이트를 옮겨 적기"의 가치는 떨어졌습니다. 하지만 중요한 반전이 있습니다. 요약을 읽는 것과 이해하는 것은 다릅니다. AI 요약은 수집 단계의 필터로는 훌륭하지만, 내 언어로 다시 쓰는 처리 단계를 건너뛰면 지식은 쌓이지 않습니다. 루만의 원리 2번은 AI 시대에도 유효합니다.

노트의 RAG화

가장 큰 변화입니다. 노트가 사람의 기억 보조에서 AI의 컨텍스트 소스로 확장됐습니다.

[과거]  나 -> 노트 작성 -> 미래의 내가 검색해서 읽음

[2026]  나 -> 노트 작성 -+-> 미래의 내가 검색/질문
                         |
                         +-> AI 에이전트가 컨텍스트로 사용
                             (글쓰기 보조, 코딩 에이전트의 참고 문서,
                              주간 리뷰 자동 요약, 노트 간 연결 제안)

이 관점에서 좋은 노트의 기준이 하나 추가됩니다. 기계가 읽기 좋은가? 명확한 제목, 일관된 메타데이터, 자기완결적 단위 — 공교롭게도 Zettelkasten의 원자성 원칙과 정확히 일치합니다.

도구 지형 — local-first와 프라이버시

도구저장 방식AI 결합강점주의점
Obsidian로컬 마크다운플러그인 + 로컬 LLM소유권, 플러그인 생태계플러그인 과다 설치 유혹
Logseq로컬 마크다운플러그인아웃라이너, 일일 노트개발 속도 변동
Notion클라우드내장 AI협업, DB 뷰데이터가 회사 서버에
Anytype로컬 + P2P제한적local-first 철학생태계 작음
일반 텍스트 + Git로컬CLI로 자유완전한 통제, 영속성UI 편의 없음

2026년의 핵심 논점은 프라이버시입니다. 노트를 AI에 연결한다는 것은 내 생각 전체를 어딘가에 보낸다는 뜻이 될 수 있습니다. 선택지는 셋입니다.

  1. 클라우드 LLM + 민감 노트 제외: 편하지만 분류 규율이 필요합니다.
  2. 로컬 LLM (Ollama, llama.cpp 류): 일기와 평가 메모까지 안심하고 연결할 수 있습니다. 요약·태깅·질문 답변 수준은 로컬 모델로 충분해진 것이 2026년의 현실입니다.
  3. 하이브리드: 임베딩과 검색은 로컬, 긴 글 생성만 클라우드.

개인적 권장: 저장은 무조건 로컬 마크다운(도구가 망해도 노트는 남는다), AI 결합은 하이브리드로 시작.

실전 시스템 설계 — 수집, 처리, 연결, 활용

전체 파이프라인을 먼저 그림으로 봅시다.

+----------+     +----------+     +----------+     +----------+
|  수집     | --> |  처리     | --> |  연결     | --> |  활용     |
| (Inbox)  |     | (Process)|     | (Link)   |     | (Output) |
+----------+     +----------+     +----------+     +----------+
 RSS/HN 큐레이션   하이라이트를      링크/태그       주간 리뷰
 read-later 앱     영구 노트로       MOC 작성        글쓰기/발표
 일일 노트         자기 언어 변환    AI 연결 제안     AI 질문

1단계: 수집 — 읽을거리 인박스

원칙: 읽는 시간과 발견하는 시간을 분리합니다. 발견 즉시 읽으면 하루가 산산조각 납니다.

  • read-later 도구(또는 단순 북마크 폴더) 하나를 유일한 인박스로 지정합니다. 흩어진 인박스가 둘 이상이면 둘 다 죽습니다.
  • HN/GeekNews 큐레이션 루틴 예시:
HN/GeekNews 루틴 (하루 15분, 아침 1회)
1. 프론트페이지를 훑되, 절대 본문을 열지 않는다 (5분)
2. 제목+댓글 수로 후보를 고르고 인박스에 저장만 한다 (5분)
3. 어제 인박스에서 "오늘 읽을 1~2개"만 고른다 (5분)
   나머지는 그대로 둔다. 일주일 지난 항목은 자동 삭제되어도 좋다.
  • 핵심 규칙: 인박스는 의무가 아니라 후보 목록입니다. 다 읽어야 한다는 강박이 시스템을 죽입니다.

2단계: 처리 — 하이라이트를 영구 노트로

읽으면서 하이라이트한 것은 아직 지식이 아닙니다. 변환 규칙:

영구 노트 변환 규칙 (하이라이트 1개당 1~3분)
1. 하이라이트를 보지 않고, 내용을 내 문장으로 한 단락 쓴다
   (못 쓰면 이해 못 한 것 -> 다시 읽거나 버린다)
2. 제목은 완결된 주장 문장으로
   나쁨: "캐싱에 대해"
   좋음: "캐시 무효화 전략은 TTL보다 이벤트 기반이 안전하다"
3. 출처 링크를 남긴다
4. 마지막 줄에 묻는다: "이 노트는 어떤 기존 노트와 연결되는가?"

모든 하이라이트를 영구 노트로 만들 필요는 없습니다. 현실적인 비율은 10개 중 1~2개입니다. 나머지는 그냥 흘려보내세요.

3단계: 연결 — 링크와 태그 전략

  • 태그는 적게, 링크는 많이. 태그는 상태 관리용 소수만(예: seed, growing, evergreen). 주제 분류는 태그 대신 링크와 MOC로.
  • MOC(Map of Content): 특정 주제의 노트가 10개를 넘으면, 그 노트들을 묶는 목차 노트를 만듭니다. 폴더보다 유연하고, 하나의 노트가 여러 MOC에 속할 수 있습니다.
  • AI 활용 포인트: 새 노트를 쓰면 "이 노트와 의미적으로 가까운 기존 노트 5개"를 임베딩 검색으로 제안받는 워크플로가 효과적입니다. 연결의 후보 발견은 AI가, 연결의 판단은 내가.

4단계: 활용 — 출력이 없으면 시스템은 죽는다

  • 주간 리뷰 (30분 고정): 이번 주 만든 노트 훑기, 인박스 비우기, 다음 주에 발전시킬 노트 1개 선정.
  • 글쓰기로 출력: 노트 3~5개가 연결되면 블로그 글 하나의 재료가 됩니다. 이 글 자체가 그렇게 만들어졌습니다.
  • 출력의 최소 단위는 거창할 필요 없습니다. 팀 슬랙에 TIL 한 단락 공유하기도 훌륭한 출력입니다.

일일 노트 — 시스템의 심장 박동

수집-처리-연결-활용 루프를 매일 돌게 만드는 엔진이 일일 노트(Daily Note)입니다. 아침에 자동 생성되는 템플릿 하나로 시작합니다.

# 2026-06-12 (금)

## 오늘의 초점
- (어제 저녁 또는 오늘 아침에 한 줄로)

## 작업 로그
- 09:40 결제 마이그레이션 PR 리뷰 — 어댑터 경계 설계가 좋았음
- 11:20 HN에서 본 로컬 임베딩 글, 인박스로
- 15:00 장애 회고 회의 — 알림 임계값 논의가 겉돌았다. 왜?

## TIL
- (3줄: 배운 것 / 삽질한 것 / 내일의 나에게)

## 인박스로 보낸 것
- 링크 2개, 회의 중 떠오른 아이디어 1개

## 내일로
- 알림 임계값 관련 생각을 영구 노트로 발전시킬 것

운영 원칙:

  • 일일 노트는 버리는 노트입니다. 잘 쓰려고 하지 마세요. 여기서 살아남은 문장만 영구 노트로 승격됩니다.
  • 작업 로그에 시각을 붙이면 주간 리뷰 때 시간 사용 패턴이 공짜로 보입니다.
  • 회의 중 떠오른 잡생각도 일단 일일 노트에 적습니다. 머리에서 꺼내 두는 것 자체가 집중력을 지킵니다.

분류가 막힐 때의 결정 트리

새로운 정보를 어디에 둘지 3초 안에 결정하는 트리입니다.

새 정보가 들어왔다
   |
   +-- 지금 진행 중인 프로젝트에 쓰이나?
   |      예 -> Projects 폴더의 해당 프로젝트 노트에 바로
   |
   +-- 아니오 -> 읽을거리인가?
   |      예 -> 인박스로 (판단은 나중에)
   |
   +-- 아니오 -> 내 생각/아이디어인가?
   |      예 -> 일일 노트에 일단 기록
   |
   +-- 아니오 -> 언젠가 참고할 자료인가?
          예 -> Resources에 링크만 저장
          아니오 -> 버린다 (버리는 것도 시스템의 기능이다)

이 트리의 존재 이유는 단 하나, 분류 고민으로 흐름이 끊기는 것을 막는 것입니다. 어디에 둘지 3초 이상 고민된다면 일단 일일 노트에 적고 넘어가세요.

AI 통합 레시피

레시피 1 — 노트 폴더를 임베딩해서 질문하기

개념: 노트를 청크로 쪼개 임베딩 벡터로 저장하고, 질문도 임베딩해서 가까운 노트를 찾아 LLM에 컨텍스트로 전달합니다. 동작하는 최소 예제입니다.

# pip install chromadb ollama
# 사전 준비: ollama pull nomic-embed-text && ollama pull llama3.2
import os
import glob
import chromadb
import ollama

client = chromadb.PersistentClient(path="./note_index")
col = client.get_or_create_collection("notes")

# 1) 노트 폴더 인덱싱 (단락 단위 청크)
for path in glob.glob("vault/**/*.md", recursive=True):
    with open(path, encoding="utf-8") as f:
        text = f.read()
    chunks = [c.strip() for c in text.split("\n\n") if len(c.strip()) > 80]
    for i, chunk in enumerate(chunks):
        emb = ollama.embeddings(model="nomic-embed-text", prompt=chunk)
        col.upsert(
            ids=[f"{path}:{i}"],
            embeddings=[emb["embedding"]],
            documents=[chunk],
            metadatas=[{"source": path}],
        )

# 2) 자연어로 질문
question = "사가 패턴의 단점에 대해 내가 정리했던 내용은?"
q_emb = ollama.embeddings(model="nomic-embed-text", prompt=question)
hits = col.query(query_embeddings=[q_emb["embedding"]], n_results=5)

context = "\n---\n".join(hits["documents"][0])
sources = [m["source"] for m in hits["metadatas"][0]]

answer = ollama.chat(
    model="llama3.2",
    messages=[
        {"role": "system",
         "content": "다음은 사용자의 개인 노트 발췌다. 노트에 근거해서만 답하고, "
                    "노트에 없는 내용은 없다고 말하라."},
        {"role": "user", "content": f"노트:\n{context}\n\n질문: {question}"},
    ],
)
print(answer["message"]["content"])
print("출처:", sorted(set(sources)))

50줄도 안 되는 코드로 "내 노트에게 묻기"가 작동합니다. 전부 로컬에서 돌므로 일기를 인덱싱해도 안전합니다. Obsidian 사용자라면 같은 일을 해 주는 커뮤니티 플러그인도 있지만, 원리를 한 번 직접 구현해 보면 어떤 도구를 쓰든 한계와 가능성이 보입니다.

레시피 2 — 요약 프롬프트 템플릿

수집 단계에서 긴 아티클을 1차 필터링할 때 쓰는 템플릿입니다.

다음 아티클을 분석하라.

1. 핵심 주장 (3문장 이내)
2. 근거 중 가장 강한 것과 가장 약한 것 각 1개
3. 저자가 다루지 않은 반론 1개
4. 내 기존 관심사와의 연결: [분산 시스템, 개발자 생산성, LLM 평가]
   중 관련 있는 것과 그 이유
5. 판정: 정독 가치 (높음/중간/낮음) + 이유 한 줄

아티클: (본문 붙여넣기)

포인트는 4번입니다. 요약에 내 관심사와의 연결 판단을 시키면, 단순 압축이 아니라 큐레이션 도구가 됩니다.

레시피 3 — 주간 리뷰 자동 초안

다음은 이번 주에 작성된 노트 목록과 본문이다.

1. 이번 주 노트들을 관통하는 주제가 있다면 무엇인가?
2. 서로 연결되면 좋을 노트 쌍을 최대 3개 제안하라 (이유 포함)
3. 발전시키면 글 한 편이 될 수 있는 씨앗 노트 1개를 골라라
4. 한 달 전 노트 중 이번 주 주제와 연결되는 것이 있으면 알려라

(노트 본문 붙여넣기 또는 RAG 컨텍스트)

주의: AI의 제안은 초안입니다. 연결을 승인하고 의미를 부여하는 것은 항상 사람의 일입니다.

메모 부채 방지 — 완벽주의 경계

PKM이 실패하는 가장 흔한 이유는 게으름이 아니라 완벽주의입니다.

  • 폴더 구조를 먼저 완성하려 하지 마세요. 구조는 노트 100개가 쌓인 뒤에 발견되는 것입니다.
  • 모든 글을 노트로 만들지 마세요. 인박스의 70%는 읽히지 않고 버려지는 것이 정상 작동입니다.
  • 노트 형식을 통일하느라 멈추지 마세요. 형식이 깨진 노트 10개가 완벽한 노트 0개보다 낫습니다.
  • 진단 기준: 지난 한 달간 노트 덕분에 더 나아진 결정이나 산출물이 하나라도 있는가? 없다면 시스템이 아니라 수집 취미를 갖고 있는 것입니다.

개발자 특화 노트 3종

코드 스니펫 노트

제목: PostgreSQL에서 중복 행 안전하게 삭제하기
태그: snippet, postgres
맥락: 2026-05 정산 테이블 중복 적재 사고 처리 중 사용
주의: CTID는 VACUUM 후 바뀔 수 있음 — 트랜잭션 안에서만 신뢰
(코드 블록)
검증: 스테이징 200만 행에서 테스트, 4.2초

핵심은 코드만이 아니라 맥락과 주의사항을 함께 적는 것입니다. 6개월 뒤의 나는 맥락을 전부 잊습니다.

TIL (Today I Learned)

하루의 끝에 3줄. "오늘 배운 것 / 삽질한 것 / 내일의 나에게". 부담이 낮아 가장 오래 지속되는 형식이고, 연말 회고와 이력서 업데이트의 원천 데이터가 됩니다.

포스트모템 노트

장애·실수 후 작성하는 개인 버전 포스트모템입니다. 회사 문서와 별개로, "내 판단의 어디가 틀렸나"를 기록합니다. 이 노트들의 모음이 곧 시니어다움의 실체입니다.

4주 구축 플랜

주차목표해야 할 일하지 말아야 할 일
1주수집 라인 가동인박스 1개 지정, HN/뉴스레터 루틴 시작, 일일 노트 시작도구 비교 영상 보기
2주처리 습관하루 1개 영구 노트 변환, 제목을 주장 문장으로과거 북마크 일괄 이전
3주연결 시작노트마다 링크 1개 이상, 첫 MOC 1개 작성태그 체계 정교화
4주활용과 AI첫 주간 리뷰, 임베딩 인덱스 구축(레시피 1), 출력 1개(TIL 공유나 짧은 글)플러그인 5개 이상 설치

4주 후 판정: 주간 리뷰가 2회 이상 실행됐고 출력이 1개 이상 나왔다면 시스템이 작동하는 것입니다. 그렇지 않다면 도구를 바꾸지 말고 루틴의 크기를 절반으로 줄이세요.

안티패턴 모음

안티패턴증상처방
도구 호핑분기마다 노트 앱 이주마크다운 고정, 1년 이주 금지 서약
수집만 하는 병인박스 3,000개, 영구 노트 0개수집 중단하고 처리만 1주
완벽한 구조 강박폴더 재설계만 반복구조는 사후 발견물로 취급
하이라이트 복사기인용만 가득, 내 문장 없음원문 안 보고 다시 쓰기 규칙
AI 전부 위임요약만 쌓이고 이해는 없음처리 단계는 수동 유지
출력 없는 정원노트는 느는데 쓰는 글 없음월 1회 출력을 캘린더에 고정

함정과 비판적 시각

  • PKM 자체가 생산성 연극이 될 수 있습니다. 노트 시스템을 가꾸는 일은 실제 일을 하는 것 같은 만족감을 주는, 가장 정교한 미루기일 수 있습니다. 출력 기준으로 스스로를 감사하세요.
  • **"AI가 다 기억해 주면 노트가 왜 필요한가"**라는 반론이 있습니다. 일리가 있습니다. 단순 사실 회수는 점점 AI 검색이 대체할 것입니다. 그러나 노트의 본질적 가치는 저장이 아니라 쓰는 행위가 강제하는 사고의 명료화입니다. 그것은 외주가 불가능합니다.
  • 임베딩 검색은 만능이 아닙니다. 시맨틱 검색은 표현이 달라도 의미가 비슷하면 찾아주지만, 정확한 키워드·코드 검색은 여전히 grep 류가 낫습니다. 둘은 보완재입니다.
  • 노트의 RAG화에는 품질 전제가 있습니다. 쓰레기 노트를 인덱싱하면 쓰레기 컨텍스트가 나옵니다(garbage in, garbage out). AI 통합은 처리 단계가 자리 잡은 뒤의 증폭기이지, 엉망인 시스템의 구원자가 아닙니다.

최종 체크리스트

시스템

  • 인박스가 정확히 1개인가
  • 저장 포맷이 로컬 마크다운(또는 이주 가능한 형식)인가
  • 발견 시간과 읽기 시간이 분리되어 있는가
  • 주간 리뷰가 캘린더에 고정되어 있는가

노트 품질

  • 영구 노트 제목이 완결된 주장 문장인가
  • 인용이 아니라 내 문장으로 쓰여 있는가
  • 노트마다 링크가 1개 이상 있는가
  • 출처가 남아 있는가

AI 통합

  • 민감 노트의 처리 방침(로컬/제외)이 정해져 있는가
  • 임베딩 인덱스가 주기적으로 갱신되는가
  • AI 제안(연결, 요약)을 사람이 승인하는 단계가 있는가
  • 처리(자기 언어 변환) 단계를 AI에 위임하지 않았는가

건강도

  • 지난달 노트에서 나온 출력(글, 결정, 공유)이 1개 이상인가
  • 도구를 1년 안에 갈아타지 않았는가
  • 인박스를 다 읽어야 한다는 강박이 없는가

마치며

정보의 홍수는 멈추지 않을 것이고, AI는 그 홍수를 더 빠르게 만들 것입니다. 그 속에서 차이를 만드는 것은 더 많이 읽는 능력이 아니라, 읽은 것을 자기 언어로 소화하고 연결하고 출력하는 루프입니다. 도구는 거들 뿐이고, AI는 증폭기일 뿐입니다. 오늘 할 일은 단순합니다. 인박스 하나를 정하고, 노트 하나를 내 문장으로 쓰는 것. 두 번째 뇌는 그렇게 한 장씩 만들어집니다.

참고 자료

Discuss on Twitter • View on GitHub