당신이 에이전트를 위해 직접 작성하려는 메모리의 절반은 이미 당신의 코드베이스에 자리 잡고 있습니다. 나머지 절반은 그 어떤 인덱서(Indexer)도 결코 찾아낼 수 없습니다.

에이전트의 입장에서는 두 가지 공백이 모두 동일하게 느껴집니다. 에이전트는 당신의 시스템에 대해 아무것도 모르는 상태로 매 세션을 시작하며, 따라서 본능적으로 하나의 메모리 저장소(Memory store)를 제공하고 넘어가려 합니다. 하지만 이 두 가지 공백은 서로 다릅니다. 하나는 유도할 수 있는 것이고, 다른 하나는 그렇지 않습니다. 첫 번째 공백을 메우는 도구는 두 번째 공백에는 아무런 도움이 되지 않습니다.

에이전트가 이미 열 번이나 본 저장소(Repo)를 여는 모습을 지켜보십시오. 에이전트는 grep을 수행합니다. 똑같은 40개의 파일을 읽습니다. 어제 구축했던 것과 똑같은 호출 그래프(Call graph)를 다시 구축하며, 코드가 이미 명시하고 있는 내용을 다시 배우기 위해 수십만 개의 토큰(Tokens)을 소비합니다. 그러고 나서 코드에 나와 있지 않기 때문에, 어떤 데이터베이스가 진실의 원천(Source of truth)인지 당신에게 묻습니다.

코드가 이미 알고 있는 부분

에이전트가 다시 배우는 내용의 대부분은 구조적입니다. 누가 ProcessOrder를 호출하는지, 이 시그니처(Signature)를 변경하면 무엇이 망가지는지, 어떤 경로(Routes)가 죽어 있는지와 같은 것들입니다. 그러한 지식은 누군가 기록했는지 여부와 상관없이 소스(Source)에 인코딩되어 있으므로 사실입니다.

그러니 이를 유도하십시오. 코드 지식 그래프(Code knowledge graph)는 저장소를 한 번 파싱(Parse)하여 지속적인 인덱스(Persistent index)로부터 구조적인 질문에 답합니다. 제가 테스트해 온 codebase-memory-mcp는 158개 언어에 대해 tree-sitter를 사용하여 해당 그래프를 구축하고, MCP를 통해 모든 에이전트에게 이를 제공합니다. 에이전트는 grep을 멈추고 쿼리(Querying)를 시작합니다. 함수의 호출자(Callers)를 추적하고, diff의 영향 범위(Blast radius)를 매핑하며, 죽은 코드(Dead code)를 나열합니다. 이는 grep이 어떤 속도로도 답할 수 없는 것들입니다.

토큰 절감 효과는 실질적이지만, 측정된 수치를 읽어보십시오. 이 프로젝트의 프리프린트(Preprint)는 31개의 저장소에 대해 토큰을 약 10배 적게 사용하며 답변 품질은 83%에 달한다고 보고합니다. README의

AST에 포함되지 않은 나머지 부분입니다. 세 개의 users 테이블 중 어떤 것이 정식(canonical)인지. 결제 서비스가 레거시 청구 API를 절대 건드려서는 안 되는 이유. 스테이징 클러스터가 실제로는 가지고 있지 않은 지연 시간을 보고하는 경우 등입니다. 이들 중 어느 것도 구조(structure)가 아닙니다. 이것은 판단, 역사, 그리고 결과입니다. 사람 안에 존재하며, 사람들은 떠납니다.

OKF는 이를 기록하기 위한 형식입니다. Open Knowledge Format으로, Google이 2026년 6월에 발표한 오픈 스펙이며 YAML 프론트매터(frontmatter)를 가진 마크다운 파일들의 디렉토리입니다. 파일당 하나의 개념을 담습니다. 여러 개념의 폴더는 번들(bundle)입니다. 이를 git에서 버전 관리하고, 풀 리퀘스트(pull request)에서 검토하며, MCP를 통해 자원(resource)으로 모든 에이전트에게 제공합니다. 의도적으로 지루합니다. 파일을 cat 할 수 있다면 읽을 수 있고, git clone 할 수 있다면 배포할 수 있습니다.

잘못은 하나를 다른 것으로 사용하는 것입니다

그래프 인덱서(graph indexer)를 조직 지식(tribal knowledge)에 겨누면 침묵만 돌아옵니다. 왜냐하면 AST에는

대규모이거나 익숙하지 않은 코드베이스(codebase)에 투입된 개발자에게는 파생된 지식(derived knowledge)이 필요합니다. 질문은 구조적이며, 코드가 그 답을 가지고 있습니다. 이때는 그래프(graph)를 활용하십시오.

데이터 플랫폼, 내부 API, 운영 런북(ops runbooks) 등 많은 시스템을 가로지르는 에이전트를 사용하는 운영자에게는 저술된 지식(authored knowledge)이 필요합니다. 가치는 개별 시스템 내부가 아닌 시스템들 사이에 존재하며, 단일 리포지토리(single-repo) 파서는 이를 볼 수 없습니다. 이때는 OKF 번들(OKF bundles)을 활용하십시오.

대부분의 실제 설정에는 두 가지 모두가 필요하며, 이 둘은 어느 하나만 있을 때보다 함께 구성될 때 더 효과적입니다. 인리치먼트 에이전트(enrichment agent)가 코드 그래프(code graph)를 탐색하며 도출할 수 있는 아키텍처에 대한 OKF 개념(concepts)을 생성하게 하십시오. 그런 다음 사람이 그래프가 볼 수 없는 부분, 즉 정전(canonical), 이유(why), 그리고 절대 일어나지 않는 일(never)을 편집합니다. 그래프는 번들이 구조에 대해 정직함을 유지하도록 돕고, 사람은 번들이 의도(intent)에 대해 정직함을 유지하도록 돕습니다.

코드가 알고 있는 것을 도출하십시오. 오직 사람만이 할 수 있는 것을 저술하십시오. 절반은 거의 비용이 들지 않지만, 나머지 절반이 실제 업무입니다.

따라서 에이전트에 또 다른 메모리 서버(memory server)를 결합하기 전에, 지식을 먼저 두 부류로 분류하십시오. 이 분류는 제가 프로덕션 에이전트(production agent)를 구축할 때 가장 먼저 설정하는 작업입니다. 다음 두 가지 질문이 이를 결정합니다:

1. 코드가 이미 명시하고 있음에도 에이전트가 계속해서 다시 배우고 있는 것은 무엇인가?
2. 아무도 기록해 두지 않았기 때문에 에이전트가 계속해서 추측하고 있는 것은 무엇인가?

저는 실제 구축 사례 — AI 통합, cron 기반 자동화, 그리고 프로덕션에서 고장 나는 부분들에 대한 현장 노트를 작성합니다. 2주마다 새로운 게시물이 올라옵니다. 이 글이 유용했다면, 작업 관리자로부터의 에이전트 메모리(agent memory from your task manager)가 동반 가이드가 될 것입니다.