나를 컴파일한다는 것 — LLM Wiki와 페르소나 에이전트의 미래
얼마 전 안드레 카파시가 GitHub Gist 하나를 공개했다. 제목은 “LLM Wiki”. LLM으로 개인 지식 베이스를 구축하는 패턴에 대한 글이었는데, 그가 던진 한마디가 인상적이었다.
“최근 내 토큰 사용량의 상당 부분이 지식 베이스를 다듬는 데 쓰이고 있다.”
연구 주제에 대한 위키를 LLM이 알아서 유지하고 관리하게 한다는 아이디어인데, 단순해 보여도 이 패턴을 “나”라는 주제에 적용하면 얘기가 달라진다.
이전 글 나를 기록한다는 것에서 페르소나 에이전트의 기억과 망각을 다뤘다. 이번에는 기록을 넘어 나를 컴파일하는 일까지 한 걸음 더 나가보려 한다.
▍RAG 페르소나의 한계
이전 글에서 다룬 RAG 기반 페르소나의 구조를 다시 떠올려 보자. 사용자의 기록(일기, 대화 로그, 검색 기록)을 벡터 DB에 넣어두고, 에이전트가 응답할 때마다 관련 기억을 검색해 컨텍스트에 주입하는 방식이었다.
[질문] → 벡터 검색 → 관련 기록 3~5개 추출 → 컨텍스트에 주입 → 응답이 방식은 작동하기는 하지만 구조적 문제가 있다.
첫째, 매번 “나”를 재구성한다. 에이전트는 대화가 시작될 때마다 이 사람이 누구인지를 벡터 검색으로 파악해야 한다. 매일 아침 자기 일기를 다시 읽어야 하는 기억상실증 환자와 비슷해서, 어제 대화에서 만들어진 맥락이 오늘로 이어지지 않는다.
둘째, 검색 결과가 일관되지 않다. 같은 사람에 대해 물어도 쿼리 표현이 달라지면 다른 청크가 걸린다. 어떤 날은 유머를 좋아하는 사람으로 파악하고 다른 날은 진지한 사람으로 파악하니, 나라는 사람의 전체상이 아니라 매번 다른 단면만 보는 셈이다.
셋째, 지식이 쌓이지 않는다. RAG는 본질적으로 무상태(stateless)라 100번의 대화를 거쳐도 에이전트가 나에 대해 학습한 건 없다. 남는 건 검색할 원본 기록뿐이다.
▍카파시의 LLM Wiki
카파시의 LLM Wiki는 이 문제에 흥미로운 해법을 내놓는다. 핵심 아이디어는 단순하다.
쿼리할 때 지식을 조립하지 말고, 수집할 때 미리 정리해둬라.
기존 RAG가 인터프리터라면 LLM Wiki는 컴파일러다.
| RAG (인터프리터) | LLM Wiki (컴파일러) | |
|---|---|---|
| 처리 시점 | 쿼리할 때마다 | 자료를 넣을 때 한 번 |
| 상태 | 무상태, 매 질문이 독립적 | 유상태, 지식이 축적 |
| 산출물 | 일회성 응답 | 영구적인 위키 문서 |
| 모순 처리 | 감지 못 함 | 명시적으로 기록 |
카파시의 위키는 세 계층으로 이루어진다.
- Raw Sources: 원본 자료(논문, 기사, 데이터). 건드리지 않는다
- Wiki: LLM이 원본을 읽고 정리한 마크다운 문서들. 상호 참조와 요약, 종합이 들어간다
- Schema: 위키의 구조를 정의하는 설정 파일. 어떤 카테고리로 어떤 깊이까지 정리할지의 규칙
새 자료가 들어오면 LLM이 원본을 읽고, 기존 위키 페이지를 업데이트하고, 새 자료와 기존 내용 사이의 모순을 기록하고, 필요하면 새 페이지를 만든다. 지식이 복리로 쌓이는 구조다.
카파시는 이 방식으로 문서 100개가 넘는 40만 단어 규모의 개인 위키를 만들었다. 임베딩도 벡터 DB도 없이 마크다운 파일과 인덱스만으로 굴린다.
▍페르소나 위키의 구조
이 패턴을 “나”라는 주제에 적용하면 어떨까.
카파시의 3계층을 페르소나 위키로 옮기면 이렇게 된다.
| LLM Wiki 계층 | 페르소나 위키 |
|---|---|
| Raw Sources | 일기, 대화 로그, 검색 기록, SNS, 구매 내역 |
| Wiki | “나의 가치관”, “커뮤니케이션 스타일”, “의사결정 패턴” 등 정리된 문서 |
| Schema | 나를 어떤 카테고리로 나눌 것인가, 곧 정체성의 구조 |
RAG 방식이 질문이 올 때마다 내 기록을 뒤져 관련 조각을 꺼내오는 것이라면, 위키 방식은 미리 나에 대한 종합 문서를 만들어두고 새 경험이 생길 때마다 업데이트하는 것이다.
구체적으로 어떻게 도는지 보자.
raw/
2026-04-10-diary.md ← "오늘 프레젠테이션에서 즉흥 질문에 당황했다"
2026-04-11-chat-log.json ← 동료와의 슬랙 대화
2026-04-12-purchase.json ← 기술 서적 3권 구매
persona/
values.md ← 핵심 가치관 (성장, 정직, 효율)
communication.md ← 말투, 선호 표현 ("음..." 으로 시작, 비유를 자주 씀)
decision-patterns.md ← 의사결정 성향 (데이터 기반, 하지만 직감도 따름)
interests.md ← 현재 관심사 (AI 에이전트, 서버 인프라, ...)
strengths-weaknesses.md ← 강점/약점 (글쓰기 ↑, 즉흥 발표 ↓)
relationships.md ← 주요 관계와 소통 방식
contradictions.md ← 내 안의 모순들
schema.md ← 위키 구조 정의 + 업데이트 규칙4월 10일 일기가 들어오면 LLM은 이렇게 처리한다.
strengths-weaknesses.md의 “즉흥 발표 ↓” 항목에 새 사례를 추가한다decision-patterns.md에 준비된 상황과 즉흥 상황의 차이를 기록한다- 이전에 “발표를 좋아한다”는 기록이 있었다면
contradictions.md에 모순을 남긴다
이게 RAG와 갈리는 결정적 지점이다. RAG는 일기 원본을 저장만 하고 나중에 검색될 때까지 그냥 두지만, 위키 방식은 새 경험이 들어오는 순간 기존의 자아 모델을 업데이트한다.
▍개인화가 중요해지는 이유
여기서 한 발 물러나 왜 이런 게 필요한지 생각해 보자.
지금의 AI 에이전트는 대부분 범용적이다. 누가 써도 같은 성격, 같은 톤, 같은 판단 기준으로 응답한다. 코드를 짜거나 문서를 요약하는 수준이라면 이걸로 충분하다.
하지만 에이전트의 역할이 넓어지고 있다. 이미 에이전트가 이메일 초안을 쓰고, 회의를 요약하고, 코드 리뷰를 하고, 일정을 조율한다. 조만간 나를 대신해 동료에게 답장을 보내고, 내 이름으로 의견을 내고, 내가 못 간 회의에서 내 입장을 대변할 것이다.
그 순간 범용 에이전트는 쓸모없어진다.
나를 대신하는 에이전트가 “일반적으로 좋은 답변”을 해봐야 의미가 없다. 내가 했을 법한 답변을 해야 한다.
- 내가 코드 리뷰를 할 때 어떤 부분을 까다롭게 보는지
- 내가 이메일을 쓸 때 어떤 톤을 쓰는지
- 내가 의사결정을 할 때 어떤 기준을 우선하는지
- 내가 특정 동료와 대화할 때 어떤 뉘앙스를 쓰는지
이 모든 걸 에이전트가 알아야 하는데, 과거 이메일 10개를 RAG로 검색한다고 해결될 문제가 아니다.
여기에 개인화의 본질이 있다. 추천 시스템의 개인화가 이 사용자가 좋아할 만한 콘텐츠를 찾는 일이라면, 에이전트 시대의 개인화는 이 사용자라면 이렇게 행동했을 것을 재현하는 일이다.
| 개인화의 세대 | 대상 | 핵심 질문 |
|---|---|---|
| 1세대: 추천 시스템 | 콘텐츠 | “이 사람이 뭘 좋아할까?” |
| 2세대: 맞춤형 UX | 인터페이스 | “이 사람에게 뭘 보여줄까?” |
| 3세대: 페르소나 에이전트 | 행동 | “이 사람이라면 어떻게 행동할까?” |
3세대 개인화는 차원이 다르다. 취향을 파악하는 게 아니라 정체성을 모델링하는 일이라, 나에 대한 지식이 체계적으로 컴파일돼 있어야 한다.
▍스키마라는 정체성
카파시의 LLM Wiki에서 가장 흥미로운 부분이 Schema다. 위키의 구조를 정의하는 설정 파일인데, 이걸 페르소나에 적용하면 의미가 깊어진다.
페르소나 위키의 스키마를 설계한다는 건 곧 나를 어떤 축으로 정의할 것인가를 정하는 일이다.
어떤 사람은 자기를 직업으로 정의하고, 어떤 사람은 관계로, 어떤 사람은 가치관으로 정의한다. 스키마는 이 선택을 명시적으로 드러낸다.
# persona-schema.yaml
persona:
identity:
- values # 변하지 않는 핵심 가치
- worldview # 세계를 바라보는 관점
behavior:
- communication # 소통 방식과 말투
- decision # 의사결정 패턴
- work-style # 일하는 방식
context:
- interests # 현재 관심사 (자주 변함)
- relationships # 주요 관계
- goals # 현재 목표
meta:
- contradictions # 내 안의 모순
- changes # 최근 변화 기록identity는 거의 변하지 않는 것을, context는 자주 변하는 것을, meta는 변화 자체를 담는다. 이 구분이 중요한 이유는 에이전트가 어떤 정보를 항상 참조하고 어떤 정보를 상황에 따라 가져올지를 여기서 결정하기 때문이다.
그리고 contradictions, 내 안의 모순을 명시적으로 기록하는 페이지가 있다. 카파시의 위키가 새 자료와 기존 내용의 모순을 감지해 기록하듯, 페르소나 위키도 “효율을 중시한다고 했지만 실제로는 완벽주의 때문에 시간을 많이 쓴다” 같은 모순을 남길 수 있다. 모순이 없는 자아 모델이 오히려 비현실적이다.
▍정돈이라는 망각, Lint
카파시의 위키에는 Lint라는 작업이 있다. 주기적으로 위키 전체를 점검해 모순과 고아 페이지, 정보 공백을 찾아내는 일이다.
이걸 페르소나 위키에 적용하면 이전 글에서 다룬 건강한 망각의 기술적 구현이 된다.
니체는 망각이 건강의 조건이라 했다. 모든 실수와 당혹감과 후회를 완벽히 기억하는 것은 성장을 가로막는데, 페르소나 위키의 Lint도 같은 역할을 한다.
- 3년 전의 관심사가 아직
interests.md에 남아 있으면 아카이브로 내린다 - 더 이상 유효하지 않은 의사결정 패턴은
changes.md에 변화를 적고 업데이트한다 - 과거의 약점을 지금은 넘어섰다면
strengths-weaknesses.md를 고친다
Lint는 곧 자기 성찰이다. 주기적으로 지금의 나와 위키에 기록된 나를 견주고 그 간극을 좁히는 작업이라, 기술적으로는 정리지만 의미로는 성장의 기록이다.
▍컴파일된 자아의 위험
물론 이 방식에도 위험이 있다.
과도한 자기 정의는 변화를 가로막는다. “나는 이런 사람이다”라는 문서가 정교해질수록 에이전트는 그 틀에 맞춰 행동하고 사용자도 그 틀에 갇힐 수 있다. 페르소나 위키가 자기 예언이 되는 것이다.
LLM의 편향이 “나”를 왜곡할 수 있다. 원본 기록을 종합하는 주체가 LLM이라, LLM이 특정 특성을 과대 해석하거나 모순을 지나치게 단순화하면 컴파일된 자아는 원본과 달라진다.
순환의 문제도 있다. 스키마를 설계하는 것도 나고 원본을 제공하는 것도 나다. 내가 고른 구조가 내가 기록하는 방식에 영향을 주고, 기록된 내용이 다시 구조를 강화한다. 나를 객관적으로 컴파일하는 게 원리적으로 가능한지부터 의문이다.
아마 완벽한 자아 컴파일은 불가능할 것이다. 다만 불완전하더라도 구조화된 자아 모델이 매번 처음부터 검색하는 것보다 낫다는 점은 분명하다.
▍결국, 나를 아는 에이전트
미래의 에이전트 생태계를 상상해 보자.
내 에이전트가 동료의 에이전트와 회의 일정을 조율하고, 내 코딩 스타일에 맞춰 PR을 올리고, 내 말투로 이메일을 쓴다. 이 모든 게 가능하려면 에이전트가 나를 깊이 알아야 한다.
그리고 그 앎은 매 대화마다 벡터 검색으로 조립되는 게 아니라 미리 컴파일돼 있어야 한다. 내 가치관과 소통 방식, 의사결정 패턴과 현재 관심사가 구조화된 문서로 정리돼 있고, 새 경험이 붙을 때마다 자동으로 업데이트되는 시스템이 필요하다.
카파시가 연구 주제를 위해 만든 LLM Wiki 패턴은 어쩌면 “나”라는 가장 중요한 주제에 적용될 때 가장 큰 값을 할지도 모른다.
기록은 나를 저장하는 일이고 컴파일은 나를 이해하는 일이다. RAG가 매번 서랍을 뒤지는 것이라면 위키는 서랍을 미리 정리해두는 것이다. 미래의 에이전트가 나를 대신하려면 “나에 대한 데이터”가 아니라 “나에 대한 이해”가 필요하다. 그리고 그 이해는 기록하고, 정리하고, 때로는 버리는 과정을 거쳐 천천히 컴파일된다.