나를 컴파일한다는 것 — 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로 검색”해서 해결될 문제가 아니다.

여기에 개인화(Personalization)의 본질이 있다. 추천 시스템에서의 개인화가 “이 사용자가 좋아할 만한 콘텐츠”를 찾는 것이라면, 에이전트 시대의 개인화는 “이 사용자라면 이렇게 행동했을 것”을 재현하는 것이다.

개인화의 세대	대상	핵심 질문
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 as Forgetting — 정돈도 망각이다

카파시의 위키에는 Lint라는 작업이 있다. 주기적으로 위키 전체를 점검해서 모순, 고아 페이지(아무 데서도 참조하지 않는 페이지), 정보 공백을 찾아내는 것이다.

이것을 페르소나 위키에 적용하면, 이전 글에서 다뤘던 **“건강한 망각”**의 기술적 구현이 된다.

니체는 “망각은 건강의 조건”이라 했다. 모든 실수, 모든 당혹감, 모든 후회를 완벽히 기억하는 것은 성장을 가로막는다. 페르소나 위키의 Lint도 같은 역할을 한다:

3년 전의 관심사가 아직 interests.md에 남아있다면 → 아카이브
더 이상 유효하지 않은 의사결정 패턴이 있다면 → changes.md에 변화를 기록하고 업데이트
과거의 약점이 현재는 극복되었다면 → strengths-weaknesses.md를 수정

Lint는 곧 자기 성찰이다. 주기적으로 “지금의 나”와 “위키에 기록된 나”를 비교하고, 간극을 좁히는 작업. 기술적으로는 정리 작업이지만, 의미적으로는 성장의 기록이다.

📍 컴파일된 자아의 위험

물론 이 방식에도 위험이 있다.

과도한 자기 정의는 변화를 가로막을 수 있다. “나는 이런 사람이다”라는 문서가 정교하게 작성될수록, 에이전트는 그 틀에 맞춰 행동하고, 사용자도 그 틀에 갇힐 수 있다. 페르소나 위키가 자기 예언이 되는 것이다.

LLM의 편향이 “나”를 왜곡할 수 있다. 원본 기록을 종합하는 것은 LLM이다. LLM이 특정 특성을 과대 해석하거나, 모순을 과도하게 단순화하면, 컴파일된 자아는 원본과 달라진다.

그리고 순환의 문제. 스키마를 설계하는 것도 나이고, 원본을 제공하는 것도 나다. 내가 선택한 구조가 내가 기록하는 방식에 영향을 주고, 기록된 내용이 다시 구조를 강화한다. 나를 객관적으로 컴파일한다는 것이 원리적으로 가능한가?

아마 완벽한 자아 컴파일은 불가능할 것이다. 하지만 불완전하더라도 구조화된 자아 모델이, 매번 처음부터 검색하는 것보다 낫다는 점은 분명하다.

📍 결국, 나를 아는 에이전트

미래의 에이전트 생태계를 상상해 보자.

내 에이전트가 동료의 에이전트와 회의 일정을 조율한다. 내 에이전트가 내 코딩 스타일에 맞춰 PR을 올린다. 내 에이전트가 내 말투로 이메일을 쓴다. 이 모든 것이 가능하려면, 에이전트는 나를 깊이 알아야 한다.

그리고 그 “앎”은 매 대화마다 벡터 검색으로 조립되는 것이 아니라, 미리 컴파일되어 있어야 한다. 내 가치관, 소통 방식, 의사결정 패턴, 현재 관심사 — 이것들이 구조화된 문서로 정리되어 있고, 새로운 경험이 추가될 때마다 자동으로 업데이트되는 시스템.

카파시가 연구 주제를 위해 만든 LLM Wiki 패턴은, 어쩌면 “나”라는 가장 중요한 주제에 적용되었을 때 가장 큰 가치를 발휘할지도 모른다.

기록은 나를 저장하는 것이고, 컴파일은 나를 이해하는 것이다. RAG가 매번 서랍을 뒤지는 것이라면, 위키는 서랍을 미리 정리해두는 것이다. 미래의 에이전트가 나를 대신하려면, “나에 대한 데이터”가 아니라 “나에 대한 이해”가 필요하다. 그리고 그 이해는 — 기록하고, 정리하고, 때로는 버리는 과정을 통해 — 천천히 컴파일된다.