AI 에이전트의 기억 인프라: LLM 위키와 의미 검색 레이어 구축

문제 정의

Claude Code는 결과를 기록하지만 과정은 기록하지 않는다

Claude Code는 git 커밋과 PR로 "무엇이 바뀌었는지"를 자동으로 남기지만, "왜 그렇게 바꿨는지"는 어디에도 기록되지 않는다. 세 가지 선택지 중 하나를 골랐을 때 나머지 두 개를 왜 버렸는지는 세션이 끝나면 휘발됐고, 다음 세션에서 같은 배경을 처음부터 다시 설명하는 비용이 누적됐다. 표준 해결책으로 5계층 Obsidian 위키링크 볼트를 먼저 설계했지만, 위키링크는 정확한 이름을 알 때만 동작하는 레일이었고 "예전에 Stop 훅 왜 포기했지?" 같은 흐릿한 기억은 grep 0건으로 떨어졌다. 더 근본적인 제약은 인프라가 깔려도 호출이 일어나지 않으면 dormant로 내려앉는다는 점이었다. 04-12에 "consumer 없는 인프라"로 식별된 의미 검색 레이어 gbrain은 이틀 뒤 Docker daemon 사망과 함께 silent fail에 진입했고, 설치한 것과 호출되는 것 사이의 갭이 명확히 드러났다.

가설 수립

Karpathy의 LLM 위키 패턴 위에 의미 검색과 강제 게이트를 얹는다

Andrej Karpathy가 트윗에서 "사람이 안 쓰고 LLM이 위키를 컴파일한다"는 패턴을 제시했다. 이 구조를 업무 의사결정 기록에 적용하면 raw 데이터(git 커밋, 작업 로그)에서 LLM이 5계층 DAG를 따라 시간축으로 컴파일하고, 사람은 Obsidian에서 열람하는 흐름이 만들어진다. 물론 의미 검색 엔진 하나만 붙이는 단순한 방식도 고려할 수 있었으나, raw 데이터 자체에 추상 개념을 묶는 요약 노드가 없으면 검색 정답률이 무너진다는 판단으로 5계층 구조를 먼저 깔고 그 위에 의미 검색을 얹는 방향을 택했다. 위키링크가 잡지 못하는 흐릿한 기억은 Postgres + pgvector + Google gemini-embedding-001 조합으로 따로 잡고, 인프라가 dormant로 죽지 않도록 데이터 전파의 강제와 호출의 강제 두 종류 게이트를 시스템에 같이 박는다는 가설을 세웠다.

솔루션 도출

5계층 DAG와 의미 검색을 강제 게이트 세 개로 묶는다

Git 커밋에서 LLM이 Daily로 "왜"를 복원하고, Daily가 Projects/Tasks(자동 파생)와 Concepts(30일 이상 반복 패턴)로 컴파일되는 5계층 DAG를 구축했다. 그 위에 gbrain 의미 검색 레이어를 붙여 Worklog 101페이지에서 145개 청크로 시작했고, 단독 소비자가 된 04-14 시점에 Docker에서 Homebrew native postgresql@18 + pgvector 0.8.2로 옮겨 RAM 오버헤드를 1/10 수준으로 떨어뜨렸다. 강제 게이트는 세 곳에 박았다. session-end-worklog.mjs로 전파 체크리스트 미통과 시 세션을 차단했고, worklog-search-priority.md로 과거 시제 트리거 시 의미 검색 호출을 첫 툴 호출 전에 강제했고, commands/worklog.md와 skills/worklog/SKILL.md를 같은 inode로 symlink하여 drift가 by-construction으로 발생 불가능하게 닫았다.

결과 & 배운 점

4/10에서 10/10, 모델 변경 없이 구조 개선만으로 달성

가장 의미 있는 수치는 retrieval 정답률이다. 자체 10문항 벤치마크에서 baseline 4/10이던 정답률이 heading-aware chunker, mergeShortChunks, wikilink auto-parser, Concept 허브 네 가지 적용 후 10/10으로 올라갔다. links 테이블은 0에서 531로, content_chunks는 173에서 415로 늘었다. 모델을 바꾸지도 인덱스 크기를 늘리지도 않은 상태에서 Karpathy 원칙(요약이 인덱스다)을 정확히 지킨 것만으로 정답률이 2.5배가 됐다. 강제 전파 훅을 도입한 날에는 한 번의 백필 세션으로 Daily 42개에 머물러 있던 시스템 전체가 살아나, Projects 35건·Tasks 13개·Concepts 8개가 자동 채워졌다. RAM도 Docker 시절 1~2GB에서 Homebrew native 100MB 미만으로 떨어졌고, DB URL을 동일하게 유지해 .mcp.json도 훅도 한 글자 바꾸지 않은 상태로 마이그레이션을 끝냈다.

이 경험은 Karpathy 원칙의 진짜 의미를 다시 읽게 했다. "사람이 안 쓰고 LLM이 쓴다"는 자동화 원칙으로 처음 받아들였지만, 실제로는 retrieval 인덱스 설계 원칙이었다. Concepts는 사람이 읽으려고 만드는 문서가 아니라 LLM이 raw를 찾을 때 쓰는 라우팅 테이블이고, 정답률 변화는 모델이 강해져서가 아니라 이 구조를 지켰기 때문에 일어난 일이었다. 또 하나 배운 것은 drift는 감지보다 구조로 막는 쪽이 우선이라는 점이다. 감지 가능한 drift는 이미 한 번 발생한 drift이고, symlink by-construction처럼 발생 자체가 불가능한 구조가 사후 감지 인프라보다 항상 앞선다. 도구의 유통기한은 모델 발전과 함께 짧아지지만, AI가 읽을 수 있는 형태로 정리된 의사결정 맥락은 도구가 바뀌어도 누적된다는 것이 이 4일이 남긴 자산화의 결론이었다.