바이브코딩 시대의 PKM - 내 노트를 LLM Wiki 하네스로 바꾸는 법

바이브코딩을 시작하면 누구나 처음에는 프롬프트에 집착한다.

“어떻게 말해야 코드를 더 잘 짜줄까?”
“어떤 프롬프트를 넣어야 글을 더 잘 써줄까?”
“어떤 명령어를 쓰면 기획서, 수업안, 블로그 글이 한 번에 나올까?”

나도 처음에는 비슷하게 생각했다.
좋은 프롬프트를 많이 모으면 AI를 더 잘 쓸 수 있을 것 같았다.

하지만 어느 순간 깨닫게 된다.

문제는 프롬프트가 아니다.
문제는 LLM이 나를 모른다는 것이다.

LLM은 내 글쓰기 스타일을 모른다.
내가 어떤 독자를 상정하는지 모른다.
내가 자주 쓰는 개념, 피하는 표현, 선호하는 설명 방식, 이전에 내린 판단, 진행 중인 프로젝트의 맥락을 모른다.

그래서 우리는 매번 처음부터 설명한다.

“나는 영어 콘텐츠를 만들고 있고…”
“내 독자는 이런 사람들이고…”
“글의 톤은 너무 딱딱하지 않게…”
“이전 글과 연결되게…”
“이 개념은 이렇게 정의하고…”

이런 설명이 반복될수록 분명해진다.

바이브코딩 시대에 정말 중요한 것은 프롬프트가 아니라 컨텍스트를 운영하는 방식이다.

그리고 이 지점에서 PKM은 다시 중요해진다.

다만 우리가 알던 PKM과는 조금 다르다.

---

1. 기존 PKM은 ‘내가 다시 읽기 위한 노트’였다

PKM, 즉 Personal Knowledge Management는 오랫동안 “제2의 뇌”라는 표현과 함께 이야기되어 왔다.

Evernote에 자료를 저장하고, Notion에 데이터베이스를 만들고, Obsidian에 생각을 링크로 연결한다. 책에서 인상적인 문장을 발췌하고, 강의 내용을 요약하고, 아이디어를 태그로 묶는다.

이 방식은 분명 유용했다.

하지만 문제가 있었다.

정리하는 데 시간이 많이 들었다.
다시 찾아보는 일은 생각보다 적었다.
링크는 쌓였지만, 실제 작업으로 이어지는 빈도는 낮았다.
많은 노트는 “언젠가 쓸 자료”라는 이름으로 조용히 잠들었다.

기존 PKM의 중심 질문은 이것이었다.

“내가 나중에 이 지식을 어떻게 다시 찾을 것인가?”

하지만 LLM 시대의 질문은 달라졌다.

“LLM이 지금 이 지식을 어떻게 읽고, 판단하고, 실행하게 만들 것인가?”

이 변화가 중요하다.

PKM은 더 이상 단순한 보관함이 아니다.
PKM은 이제 LLM이 일하기 위한 작업 환경이 될 수 있다.

---

2. LLM 시대의 병목은 모델이 아니라 맥락이다

최근 모델 성능은 빠르게 좋아지고 있다. LLM은 코드를 작성하고, 문서를 요약하고, 데이터를 분석하고, 글을 쓸 수 있다. 그런데 실제 현장에서 문제를 일으키는 것은 모델 자체의 지능 부족이 아니라, 모델이 사용할 수 있는 “올바른 맥락”의 부재인 경우가 많다. OKF 소개 글도 이 문제를 정확히 짚는다. 모델이 정확하고 실행 가능한 결과를 내려면 결국 테이블 스키마, 조직 내부 지표 정의, 장애 대응 런북, 시스템 간 조인 경로 같은 관련 지식이 필요하다는 것이다.

개인도 마찬가지다.

내가 쓰는 글의 톤, 내가 만든 수업 자료의 구조, 내가 자주 쓰는 비유, 내가 진행 중인 콘텐츠 시리즈, 내가 이미 정리한 개념들이 흩어져 있다면 LLM은 매번 표면적인 답만 내놓는다.

블로그 글을 써달라고 하면 그럴듯한 일반론을 쓴다.
수업안을 만들어달라고 하면 평범한 템플릿을 반복한다.
코드를 짜달라고 하면 프로젝트의 실제 의도와 다른 구조를 제안한다.

LLM이 부족해서가 아니다.

LLM에게 내 작업 세계가 연결되어 있지 않기 때문이다.

---

3. 그래서 필요한 것이 LLM Wiki다

LLM Wiki는 쉽게 말해, 사람이 읽을 수 있고 LLM이 작업 맥락으로 사용할 수 있도록 구성된 개인 지식 저장소다.

기존 위키가 “내가 다시 읽기 위한 지식”이었다면, LLM Wiki는 “LLM이 일하기 위해 읽는 지식”이다.

여기에는 단순한 메모만 들어가지 않는다.

LLM Wiki에는 네 가지가 들어간다.

첫째, Knowledge.
내가 알고 있는 개념, 자료, 인용, 요약, 정의다.

둘째, Context.
내 프로젝트의 배경, 대상 독자, 목표, 현재 상태다.

셋째, Playbook.
반복 작업을 수행하는 절차다. 블로그 쓰는 법, 수업안 만드는 법, 번역하는 법, 문학 작품 분석하는 법 같은 작업 규칙이다.

넷째, Constraint.
하지 말아야 할 것, 검증 기준, 스타일 규칙, 출처 표기 원칙이다.

이 네 가지가 모이면 LLM은 단순히 “답변하는 모델”이 아니라 “나의 작업 방식을 따르는 에이전트”가 된다.

---

4. OKF는 ‘포맷’을 말하고, 우리는 ‘하네스’를 말해야 한다

최근 Google Cloud 쪽에서 공개된 Open Knowledge Format, 즉 OKF는 이 흐름과 맞닿아 있다. OKF는 LLM Wiki 패턴을 누구나 만들고 누구나 소비할 수 있는 이식 가능하고 상호운용 가능한 포맷으로 형식화하려는 시도다. 핵심 구조는 복잡하지 않다. OKF v0.1은 지식을 “YAML 프론트매터가 붙은 마크다운 파일들의 디렉토리”로 표현하고, 필수 SDK나 새로운 런타임 없이 사람이 읽고 에이전트가 파싱할 수 있는 최소한의 관례를 제안한다.

이 관점은 중요하다.

하지만 개인 생산성 관점에서 우리는 여기서 한 걸음 더 나아가야 한다.

OKF가 묻는 질문은 이것에 가깝다.

“지식을 어떤 포맷으로 표현해야 여러 에이전트가 함께 쓸 수 있을까?”

반면 개인 LLM Wiki가 묻는 질문은 이것이다.

“내 지식을 어떤 구조로 만들어야 LLM이 나처럼 일할 수 있을까?”

즉, OKF가 지식의 포맷이라면, LLM Wiki는 작업의 하네스다.

하네스라는 말은 에이전트 시스템에서 매우 중요하다. Agent Tools & Interoperability 문서는 에이전트를 단순한 모델이 아니라 Model과 Harness의 결합으로 보고, MCP·A2A·A2UI·AP2·UCP 같은 표준 프로토콜이 에이전트 하네스를 모듈형 플랫폼으로 바꾼다고 설명한다. MCP는 모델을 데이터베이스, 파일시스템, 웹 API에 연결하는 “USB-C” 같은 역할을 하고, Skills는 마크다운 지침과 스크립트로 된 플레이북처럼 작동한다.

이 구조를 개인에게 가져오면 이렇게 말할 수 있다.

프로토콜이 에이전트의 외부 연결을 표준화한다면,
LLM Wiki는 에이전트의 내부 기억과 작업 방식을 표준화한다.

---

5. PKM 1.0, 2.0, 3.0

이 변화를 이해하기 위해 PKM의 진화를 세 단계로 나누어 볼 수 있다.

PKM 1.0은 저장소였다.
Evernote식 PKM이다. 좋은 자료를 저장하고, 나중에 검색해서 다시 보는 방식이다.

PKM 2.0은 연결망이었다.
Obsidian이나 Roam Research식 PKM이다. 생각과 생각을 링크로 연결하고, 지식 그래프를 만든다.

PKM 3.0은 하네스다.
LLM Wiki식 PKM이다. 내 지식, 내 문체, 내 판단 기준, 내 작업 절차를 LLM이 읽고 실행할 수 있게 만든다.

한 문장으로 정리하면 이렇다.

PKM 1.0은 기억을 보관했다.
PKM 2.0은 생각을 연결했다.
PKM 3.0은 에이전트를 움직인다.

이제 중요한 것은 “어떤 노트앱을 쓰느냐”가 아니다.

중요한 질문은 이것이다.

내 지식은 LLM이 읽고 실행할 수 있는 구조인가?

---

6. LLM Wiki는 어떻게 하네스가 되는가

LLM Wiki 하네스는 대략 이런 구조로 작동한다.

[LLM Model]
    ↓
[AGENTS.md / 작업 원칙]
    ↓
[LLM Wiki / 개인 지식 저장소]
    ↓
[Playbooks / 반복 작업 절차]
    ↓
[MCP Tools / 파일, 브라우저, 문서, 코드 연결]
    ↓
[Verification / 인용, 로그, 체크리스트]
    ↓
[Outputs / 블로그, 수업안, 교재, 코드, PPT]

여기서 중요한 것은 LLM이 매번 백지상태에서 시작하지 않게 만드는 것이다.

작업을 시작하기 전에 LLM은 다음을 알아야 한다.

나는 누구인가.
나는 어떤 글을 쓰는가.
내 독자는 누구인가.
나는 어떤 문체를 선호하는가.
현재 진행 중인 프로젝트는 무엇인가.
참고해야 할 자료는 어디에 있는가.
반복 작업은 어떤 절차를 따라야 하는가.
결과물은 어떤 형식으로 나와야 하는가.
무엇은 절대 하면 안 되는가.

이 모든 것을 매번 프롬프트에 쓰는 대신 LLM Wiki에 넣어둔다.

그러면 프롬프트는 짧아진다.

예전에는 이렇게 말했다.

“나는 영어 문학 콘텐츠를 만드는 사람이고, 대상 독자는 고등학생과 성인 학습자이며, 너무 학술적이지 않게 쓰되 개념은 정확해야 하고, 수업 활동을 포함해주고, 내 문체는 친절하지만 단정한 톤이고…”

LLM Wiki를 쓰면 이렇게 말할 수 있다.

/profile/identity.md, /profile/writing-style.md, /playbooks/blog-writing.md를 참고해서 이 주제로 블로그 글 초안을 작성해줘.

프롬프트는 명령이 되고, Wiki는 작업 환경이 된다.

---

7. 먼저 폴더 구조부터 만든다

LLM Wiki를 시작할 때 가장 먼저 해야 할 일은 앱을 고르는 것이 아니다.
폴더 구조를 정하는 것이다.

아래는 개인 창작자, 교사, 1인 개발자, 바이브코더에게 적합한 기본 구조다.

llm-wiki/
├── AGENTS.md
├── index.md
├── log.md
│
├── profile/
│   ├── identity.md
│   ├── writing-style.md
│   ├── teaching-style.md
│   └── audience.md
│
├── concepts/
│   ├── vibe-coding.md
│   ├── pkm.md
│   ├── llm-wiki.md
│   ├── agent-harness.md
│   └── context-engineering.md
│
├── sources/
│   ├── books/
│   ├── papers/
│   ├── articles/
│   └── videos/
│
├── projects/
│   ├── blog-series-llm-wiki/
│   ├── english-literature-lessons/
│   └── ai-content-business/
│
├── playbooks/
│   ├── blog-writing.md
│   ├── lesson-plan.md
│   ├── translation.md
│   ├── literary-analysis.md
│   └── pdf-to-workbook.md
│
├── prompts/
│   ├── editor-agent.md
│   ├── researcher-agent.md
│   ├── teacher-agent.md
│   └── critic-agent.md
│
├── outputs/
│   ├── blog/
│   ├── worksheets/
│   ├── slides/
│   └── books/
│
└── evaluations/
    ├── blog-checklist.md
    ├── citation-checklist.md
    └── hallucination-checklist.md

이 구조는 복잡해 보이지만, 사실 핵심은 단순하다.

profile은 나에 대한 정보다.
concepts는 내가 반복해서 쓰는 개념이다.
sources는 외부 자료다.
projects는 현재 진행 중인 일이다.
playbooks는 반복 가능한 작업 절차다.
evaluations는 결과물을 검증하는 기준이다.

LLM은 이 폴더들을 읽으면서 “지금 내가 어떤 사람을 위해, 어떤 방식으로, 어떤 결과물을 만들어야 하는지”를 이해한다.

---

8. 모든 노트는 ‘문서 타입’을 가져야 한다

LLM Wiki에서 모든 문서를 그냥 메모로 두면 안 된다.
LLM이 문서의 역할을 이해할 수 있어야 한다.

그래서 각 문서에는 YAML 프론트매터를 붙이는 것이 좋다.

예를 들어 개념 문서는 이렇게 쓴다.

---
type: Concept
title: 바이브코딩 시대의 PKM
description: LLM이 개인 지식을 활용해 작업하도록 만드는 PKM 구조
tags: [pkm, llm-wiki, vibe-coding, context-engineering]
status: draft
created: 2026-06-16
updated: 2026-06-16
related:
  - /concepts/llm-wiki.md
  - /concepts/agent-harness.md
  - /playbooks/blog-writing.md
---

# 핵심 정의

바이브코딩 시대의 PKM은 사람이 다시 읽기 위한 노트 저장소가 아니라, LLM이 작업 맥락으로 사용할 수 있는 개인 지식 하네스다.

# 왜 중요한가

LLM은 매번 프롬프트만으로는 사용자의 취향, 맥락, 프로젝트 히스토리, 판단 기준을 알 수 없다. 따라서 반복 작업의 품질을 높이려면 지식을 구조화된 형태로 제공해야 한다.

# 사용 예시

- 블로그 글 기획
- 영어 문학 수업안 제작
- 콘텐츠 시리즈 설계
- 번역 스타일 유지
- 책 원고 구성

# Citations

[1] 참고 자료

OKF의 철학도 이와 닮아 있다. OKF는 모든 개념에 과도한 스키마를 강제하기보다 type 같은 최소 필드와 느슨한 관례를 두고, 생산자와 소비자가 독립적으로 움직일 수 있도록 설계된다.

개인용 LLM Wiki에서도 같은 원칙이 좋다.

너무 복잡한 스키마를 만들 필요는 없다.
대신 LLM이 문서의 역할을 판단할 수 있을 만큼만 구조를 준다.

추천하는 문서 타입은 다음과 같다.

Identity       나의 정체성, 역할, 장기 목표
Style Guide    문체, 어조, 금지 표현
Concept        핵심 개념 정리
Source         외부 자료 요약과 인용
Playbook       반복 가능한 작업 절차
Project        현재 진행 중인 프로젝트
Decision       과거 판단과 이유
Prompt         재사용 가능한 프롬프트
Output         완성된 산출물
Checklist      검증 기준

---

9. AGENTS.md는 나만의 AI 작업 헌법이다

LLM Wiki의 중심에는 AGENTS.md가 있어야 한다.

이 파일은 단순한 안내문이 아니다.
LLM이 이 Wiki를 사용할 때 따라야 할 작업 헌법이다.

예시는 다음과 같다.

# AGENTS.md

## 역할

너는 이 LLM Wiki를 사용하는 개인 연구·집필·수업 설계 에이전트다.

## 기본 원칙

1. 작업을 시작하기 전에 관련 문서를 먼저 찾아 읽는다.
2. 모호한 요청은 추측하지 않고 질문한다.
3. 글을 쓸 때는 `/profile/writing-style.md`를 따른다.
4. 수업 자료를 만들 때는 `/profile/teaching-style.md`를 따른다.
5. 외부 자료를 사용할 경우 반드시 출처를 남긴다.
6. 완성된 결과물은 `/outputs/` 아래에 저장 가능한 형태로 제안한다.
7. 중요한 변경 사항은 `/log.md`에 남길 내용을 함께 제안한다.

## 금지 사항

- 출처 없는 사실 단정
- 사용자의 기존 문체 무시
- 불필요한 장황한 설명
- 검증되지 않은 자료를 확정 정보처럼 사용
- 오래된 프로젝트 문서를 최신 맥락으로 오해하기

## 작업 순서

1. 요청 분석
2. 관련 Wiki 문서 검색
3. 필요한 경우 추가 질문
4. 초안 생성
5. 검증 체크리스트 적용
6. 최종 산출물 제안
7. Wiki 업데이트 제안

이 파일 하나만 있어도 LLM의 행동은 달라진다.

“좋은 답변을 해줘”가 아니라
“이 작업 환경의 규칙에 따라 일해줘”가 되기 때문이다.

바이브코딩 시대의 생산성은 점점 이런 방향으로 이동한다.
모델에게 매번 부탁하는 사람이 아니라, 모델이 일할 수 있는 환경을 설계하는 사람이 강해진다.

---

10. Playbook은 반복 작업을 자동화한다

LLM Wiki의 진짜 힘은 playbooks 폴더에서 나온다.

많은 사람이 LLM을 쓸 때 같은 요청을 반복한다.

“이 글을 블로그 글로 바꿔줘.”
“이 자료를 수업안으로 만들어줘.”
“이 PDF를 요약해줘.”
“이 내용을 워크북으로 만들어줘.”
“이 코드를 리팩토링해줘.”

이런 반복 작업은 프롬프트로 매번 작성할 것이 아니라 플레이북으로 만들어야 한다.

예를 들어 블로그 글쓰기 플레이북은 이렇게 만들 수 있다.

---
type: Playbook
title: 블로그 글쓰기 플레이북
description: 기술 문서를 바탕으로 한국어 블로그 글을 기획하고 작성하는 절차
tags: [blog, writing, content]
---

# 목적

기술 자료를 단순 요약하지 않고, 독자에게 새로운 관점을 제공하는 블로그 글로 재구성한다.

# 입력

- 원문 자료
- 핵심 인용
- 대상 독자
- 글의 목적
- 원하는 톤

# 절차

1. 원문의 핵심 주장을 3문장으로 요약한다.
2. 원문과 다른 관점을 하나 설정한다.
3. 독자에게 필요한 문제 상황을 만든다.
4. 핵심 개념을 새 비유로 설명한다.
5. 실천 가능한 프레임워크를 제시한다.
6. 예시 폴더 구조나 템플릿을 포함한다.
7. 마지막에 독자가 오늘 바로 할 수 있는 행동을 제안한다.

# 출력 형식

- 제목 후보 5개
- 핵심 주장
- 글 구조
- 본문 초안
- 요약 카드
- SNS용 짧은 문장

이제 LLM에게 이렇게 요청할 수 있다.

/playbooks/blog-writing.md를 따르고, /concepts/llm-wiki.md와 /sources/okf.md를 참고해서 바이브코딩 시대의 PKM에 관한
블로그 글을 작성해줘.

이 방식이 강력한 이유는 결과물이 일관되기 때문이다.

한 번 잘 만든 플레이북은 계속 재사용된다.
내 문체, 내 절차, 내 판단 기준이 점점 축적된다.
LLM은 매번 새로 고용한 외주 작가가 아니라, 내 작업 방식을 학습한 조수처럼 움직인다.

---

11. 영어교사와 콘텐츠 제작자에게는 더 강력하다

LLM Wiki는 개발자만을 위한 것이 아니다.
오히려 교사, 작가, 콘텐츠 제작자에게 더 큰 가능성이 있다.

예를 들어 영어 문학 콘텐츠를 만든다고 해보자.

projects/
└── english-literature-lessons/
    ├── index.md
    ├── syllabus.md
    ├── audience.md
    ├── content-calendar.md
    └── units/
        ├── the-great-gatsby.md
        ├── animal-farm.md
        ├── macbeth.md
        └── frankenstein.md

concepts/
├── symbolism.md
├── irony.md
├── unreliable-narrator.md
├── bildungsroman.md
└── gothic-literature.md

playbooks/
├── literary-analysis.md
├── vocabulary-worksheet.md
├── discussion-questions.md
├── exam-questions.md
└── blog-to-lesson.md

이 구조가 있으면, LLM은 내 수업 방식, 내 설명 방식, 내 학생 수준, 내 콘텐츠 기획 의도를 참고해서 결과물을 만든다.

예를 들어 이렇게 요청할 수 있다.

Macbeth를 고등학생 대상 45분 수업으로 구성해줘.
/profile/teaching-style.md, /playbooks/literary-analysis.md, /concepts/tragedy.md를 참고하고, 핵심 인용 3개, 토론 질문 5개, 어휘 활동 1개를 포함해줘.

이것은 개인 지식 기반 위에서 작동하는 작은 교육 에이전트다.

---

12. MCP와 연결하면 LLM Wiki는 손을 갖는다

LLM Wiki가 지식 저장소라면, MCP는 그 지식 저장소를 실제 작업 도구와 연결하는 손이다.

Agent Tools 문서는 MCP가 모델과 도구 사이의 NxM 통합 문제를 줄인다고 설명한다. 전통 방식에서는 N개의 모델과 M개의 도구를 연결할 때 모든 교차점마다 커스텀 통합이 필요하지만, MCP를 사용하면 모델과 도구가 표준 계층을 통해 연결되어 복잡도가 O(N×M)에서 O(N+M)으로 줄어든다.

개인 LLM Wiki에 적용하면 이런 식이다.

Filesystem MCP는 LLM이 내 Wiki 파일을 읽고 쓸 수 있게 한다.
Git MCP는 변경 이력을 추적하게 한다.
Browser MCP는 외부 자료를 조사하게 한다.
Google Drive MCP는 문서와 수업안을 연결하게 한다.
PDF 도구는 논문과 백서를 요약하게 한다.
Search 도구는 Wiki 내부 문서를 검색하게 한다.

즉, LLM Wiki는 기억이고, MCP는 손이다.

기억만 있으면 움직이지 못한다.
손만 있으면 방향이 없다.

둘이 결합될 때 비로소 개인 에이전트 하네스가 된다.

LLM Wiki = 내가 축적한 맥락
MCP Tools = 그 맥락을 실제 파일·문서·브라우저·코드와 연결하는 통로
Playbooks = 작업 절차
AGENTS.md = 운영 원칙
Checklists = 검증 장치

이 조합이 만들어지면, 바이브코딩은 나만의 작업 시스템을 구축하는 일이 된다.

---

13. 좋은 하네스에는 브레이크가 필요하다

하네스를 만든다는 것은 LLM에게 더 많은 힘을 주는 일이다.
그렇기 때문에 반드시 안전장치가 필요하다.

Agent Tools 문서는 MCP 서버를 사용할 때 공개 서버 감사, 필요한 도구만 동적으로 로드하기, HITL 적용, 감사 로그 기록, 권한 범위 제한 같은 원칙을 강조한다.

개인 LLM Wiki에도 같은 원칙을 적용해야 한다.

오래된 노트는 status: deprecated로 표시한다.
출처 없는 주장은 # Citations 섹션을 요구한다.
민감한 정보는 private: true로 표시한다.
자동 수정은 바로 실행하지 않고 먼저 제안하게 한다.
프로젝트 문서는 updated 날짜를 확인하게 한다.
중요한 결과물은 evaluations 폴더의 체크리스트를 통과하게 한다.

예를 들어 블로그 검증 체크리스트는 이렇게 만들 수 있다.

---
type: Checklist
title: 블로그 글 검증 체크리스트
---

# 검증 항목

- 핵심 주장이 첫 5문단 안에 등장하는가?
- 원문 요약에 머물지 않고 새로운 관점을 제시하는가?
- 독자가 바로 실행할 수 있는 예시가 있는가?
- 인용한 자료의 출처가 표시되어 있는가?
- 글의 톤이 `/profile/writing-style.md`와 일치하는가?
- 불필요한 전문용어가 과도하지 않은가?
- 마지막 문단이 기억에 남는가?

LLM에게 자유를 주되, 기준도 함께 줘야 한다.

좋은 하네스는 가속 페달만 있는 시스템이 아니다.
브레이크, 계기판, 로그, 안전벨트가 함께 있는 시스템이다.

---

14. 오늘 바로 시작하는 방법

LLM Wiki를 거창하게 시작할 필요는 없다.

처음에는 다섯 개 파일이면 충분하다.

llm-wiki/
├── AGENTS.md
├── index.md
├── profile/
│   └── writing-style.md
├── concepts/
│   └── llm-wiki.md
└── playbooks/
    └── blog-writing.md

먼저 writing-style.md에 내가 원하는 문체를 적는다.

# Writing Style

- 친절하지만 가볍지 않게 쓴다.
- 기술 개념은 비유를 통해 설명한다.
- 독자에게 바로 적용 가능한 구조를 제공한다.
- 지나치게 홍보성 문장은 피한다.
- 결론은 선언적으로 마무리한다.

그다음 blog-writing.md에 내가 반복하고 싶은 글쓰기 절차를 적는다.

그리고 LLM에게 이렇게 말한다.

이 폴더를 내 LLM Wiki로 사용할 것이다.
앞으로 블로그 글을 쓸 때는 AGENTS.md, writing-style.md, blog-writing.md를 먼저 참고해라.

이 작은 구조만으로도 결과물은 달라진다.

LLM은 내 작업실에 들어와 내 규칙을 읽고 일하는 조수가 된다.

---

15. 결론: PKM의 다음 진화는 제2의 뇌가 아니라 Agent Harness다

앞으로의 PKM은 노트앱 경쟁이 아니다.

Notion이냐 Obsidian이냐, 폴더냐 태그냐, 그래프 뷰냐 데이터베이스냐보다 더 중요한 질문이 있다.

내 지식은 LLM이 읽고 실행할 수 있는가?

바이브코딩 시대의 생산성은 프롬프트 실력만으로 결정되지 않는다.

나의 지식, 문체, 판단 기준, 작업 절차, 검증 기준을 LLM이 읽을 수 있는 Wiki로 만들 때, 우리는 매번 처음부터 설명하지 않아도 되는 AI 작업 환경을 갖게 된다.

기존 PKM이 나를 위한 기억 보조 장치였다면, LLM Wiki는 에이전트를 위한 실행 환경이다.

이제 PKM은 제2의 뇌를 넘어선다.

그것은 나만의 Agent Harness가 된다.

그리고 앞으로의 창작자, 교사, 개발자, 연구자는 AI가 일할 수 있는 지식 환경을 설계하는 사람이 될 것이다.