아무도 이야기하지 않는 에이전트 간 연속성 격차 (The Agent-to-Agent Continuity Gap)

요약 (TL;DR): 대부분의 AI 에이전트 메모리(Memory) 논의는 여전히 하나의 에이전트가 세션 전반에 걸쳐 스스로와 대화하는 것을 가정합니다. 하지만 실제 코딩 워크플로우에서는 이미 Claude, Codex, Cursor, Gemini가 같은 주에 동일한 리포지토리(Repo)를 다루고 있습니다. 어려운 문제는 "에이전트가 어떻게 기억하는가"가 아닙니다. "여러 에이전트가 서로 방해하지 않으면서 어떻게 동일한 프로젝트에서 협업 상태를 유지하는가"입니다. 그 문제는 단일 에이전트 내부에 있지 않습니다. 리포지토리(Repo) 안에 존재합니다.

저는 지난주에 AI 코딩 에이전트의 메모리는 채팅창이 아니라 리포지토리에 속해야 한다고 주장하는 글을 썼습니다. 대화 기록(Transcript)이 아닌 체크포인트(Checkpoint)가 필요하다는 내용이었습니다.

그 주장을 며칠간 검토하면서, 저는 이것이 제가 아직 명시적으로 밝히지 않았던 더 큰 문제의 하위 개념이라는 것을 깨달았습니다. 체크포인트라는 기본 단위(Primitive)가 중요한 이유는 현재의 에이전트 스택(Agent Stack)이 아직 이름을 붙이지 못한 문제 때문입니다.

그 문제를 말씀드리겠습니다.

업계 지도에는 사각지대가 있습니다

현재 Paolo Perrone이 만든 매우 훌륭한 2026년 에이전트 스택(Agent Stack) 지도가 유통되고 있습니다. 모델(Models), 프로토콜(Protocols), 메모리(Memory), 프레임워크(Frameworks), 평가(Eval), 가드레일(Guardrails)의 6개 계층으로 구성되어 있습니다. 매우 유용한 지도입니다.

하지만 메모리(Memory) 계층을 주의 깊게 읽어보면 무언가를 발견하게 됩니다.

그 지도의 모든 메모리 단계는 단일 에이전트를 가정하고 있습니다.

인컨텍스트 상태(In-context state)는 단일 에이전트의 컨텍스트 윈도우(Context window) 내에 존재합니다.
벡터 검색(Vector retrieval)은 단일 에이전트의 RAG 파이프라인 내에 존재합니다.
Letta, Zep, Mem0와 같은 지속성 메모리 서비스(Persistent memory services)는 단일 에이전트가 세션 전반에 걸쳐 학습하도록 설계되었습니다.

이는 실제적인 문제이며 해결할 가치가 있습니다. 하지만 이것은 대부분의 코딩 워크플로우가 실제로 겪고 있는 문제는 아닙니다.

대부분의 코딩 워크플로우는 이미 여러 에이전트를 사용하고 있습니다

현재 진지하게 코드를 배포(Shipping)하고 있는 사람들이 어떻게 작업하는지 보십시오.

아키텍처 설계 및 리뷰를 위한 Claude.
구현을 위한 Codex.
인라인 반복(Inline iteration)을 위한 Cursor.
탐색을 위한 Gemini.
그리고 이 모든 것을 승인하고 편집하는 인간.

이것은 미래의 시나리오가 아닙니다. 평범한 화요일의 일상입니다.

그리고 그 에이전트들 하나하나가 자신만의 컨텍스트 윈도우 (Context Window), 자신만의 세션 (Session), 자신만의 메모리 (Memory), 그리고 코드베이스에 대한 자신만의 의견을 가지고 있습니다. 그들 중 누구도 다른 에이전트가 한 시간 전에 무엇을 했는지 알지 못합니다.

연속성 문제 (Continuity problem)는 "Claude가 우리가 어제 논의한 내용을 잊어버렸다"가 아닙니다.

연속성 문제는 "Claude는 Codex가 오늘 아침에 무엇을 구현했는지, Cursor가 점심시간에 그중 절반을 어떻게 되돌렸는지, 그리고 인간이 다른 브랜치에서 다른 무언가를 병합(Merge)했는지 알지 못한다"는 것입니다.

이것은 메모리 문제로 위장된 조정 (Coordination) 문제입니다.

에이전트 간 메모리 (Agent-to-Agent Memory)는 아직 존재하지 않는다

Perrone의 지도(Map)는 이 사실을 솔직하게 기록하고 있습니다. MCP는 에이전트가 도구 (Tools)를 호출하는 방식을 표준화했습니다. 하지만 에이전트들이 서로 어떻게 대화하는지에 대해서는 아무것도 말하지 않습니다. IBM에는 ACP가 있고, Google에는 A2A가 있습니다. 하지만 그 어느 것도 표준이 아닙니다. 어느 것도 널리 채택되지 않았습니다. 어느 것도 코딩 워크플로우 (Coding workflow) 사례를 해결하지 못합니다.

따라서 실제로 멀티 에이전트 (Multi-agent) 코딩 워크플로우를 실행하는 모든 팀은 이 문제를 스스로 해결하고 있습니다. 대개는 서투른 방식으로 말이죠. 보통은 새로운 세션이 시작될 때마다 수동으로 컨텍스트 (Context)를 다시 설명하는 방식을 사용합니다.

전용 메모리 벤더 (Memory vendors)들도 이 문제를 해결하지 못합니다. 왜냐하면 그들은 단일 에이전트 (Single-agent)에게 더 긴 메모리를 제공하도록 설계되었기 때문입니다. Cursor와 Claude Code를 동일한 Mem0 인스턴스에 연결하고 그들이 서로 조정하기를 바라는 것은 오늘날 작동하는 방식이 아닙니다.

메모리 인프라 (Memory infrastructure)는 단일 에이전트 인프라입니다. 멀티 에이전트 조정 레이어 (Multi-agent coordination layer)가 누락되어 있습니다.

리포지토리 (Repo)가 유일한 공유 접점이다

제 머릿속을 계속 때린 사실은 이것입니다.

Claude, Codex, Cursor, 그리고 Gemini가 모두 동일한 프로젝트에서 작업할 때, 그들 모두가 이미 보고 있는 인프라는 정확히 단 하나뿐입니다.

바로 리포지토리 (Repository)입니다.

그들은 모두 그것을 읽습니다. 모두 그것에 씁니다. 모두 MCP 또는 그에 상응하는 방식을 통해 이미 파일 시스템 (File system) 접근 권한을 가지고 있습니다. Git은 이미 누가, 무엇을, 언제 변경했는지 추적하고 있습니다.

리포지토리는 공유된 기질 (Shared substrate)입니다. 유일하게 공유된 기질입니다. 그 외의 모든 것은 에이전트별 (Per-agent)입니다.

따라서 에이전트 간의 연속성 (Continuity)을 원한다면, 연속성 아티팩트 (Continuity artifacts)는 리포지토리 (Repo) 안에 존재해야 합니다. 한 에이전트가 연결된 벡터 데이터베이스 (Vector database)에 있어서도 안 되고, 다른 에이전트가 알지 못하는 호스팅된 메모리 서비스 (Hosted memory service)에 있어서도 안 됩니다. 리포지토리에 있어야 합니다. 파일 형태로 존재해야 합니다. 버전 관리 (Versioned)가 되어야 하고, 감사 (Auditable) 가능해야 하며, 차이점 비교 (Diffable)가 가능해야 합니다. 또한 파일 시스템을 읽을 수 있는 모든 에이전트에게 가시적이어야 합니다.

이것이 체크포인트 (Checkpoints)가 올바른 프리미티브 (Primitive)인 이유입니다. 벡터 검색 (Vector search)이 나쁘기 때문이 아닙니다. 벡터 검색은 그 역할에 매우 훌륭합니다. 하지만 다음 에이전트가 들어본 적도 없는 벡터 스토어 (Vector store)에서 정보를 검색할 수는 없습니다.

재정의 (The Reframe)

문제를 "에이전트 메모리 (Agent memory)"로 정의하는 것을 멈추고, "공유된 아티팩트 (Shared artifact) 상에서의 멀티 에이전트 조정 (Multi-agent coordination)"으로 정의하기 시작하면, 많은 도구 관련 논쟁들이 무너집니다.

더 큰 컨텍스트 윈도우 (Context windows)는 도움이 되지 않습니다. 다음 에이전트는 다른 컨텍스트 윈도우를 가지고 있습니다.
더 나은 RAG (Retrieval-Augmented Generation)도 도움이 되지 않습니다. 다음 에이전트는 다른 RAG 파이프라인 (Pipeline)을 가지고 있거나, RAG를 전혀 사용하지 않을 수도 있습니다.
호스팅된 메모리 서비스 (Hosted memory services)는 워크플로우 내의 모든 에이전트가 동일한 서비스에 연결되어 있지 않는 한 도움이 되지 않으며, 실제로 그렇지 않습니다.
트랜스크립트 (Transcripts)는 도움이 되지 않습니다. 그것들은 노이즈이며, 다음 에이전트는 당신의 트랜스크립트를 가지고 있지 않기 때문입니다.

도움이 되는 것은 무엇이 결정되었는지, 무엇이 진행 중인지, 무엇이 위험 요소인지, 그리고 다음 에이전트가 무엇을 이어받아야 하는지에 대한 작고 구조화되며 버전 관리된 기록입니다. 리포지토리에 위치하며, 누구나 볼 수 있는 곳에 있어야 합니다.

그것이 바로 현재의 스택 맵 (Stack map)에는 자리가 없는 연속성 프리미티브 (Continuity primitive)입니다.

내가 만들고 있는 것

Holistic은 이 아이디어를 탐구하는 오픈 소스 CLI (Open source CLI)입니다. 리포지토리 네이티브 체크포인트 (Repo-native checkpoints)를 지향합니다. 에이전트 불가지론적 (Agent-agnostic)입니다. 벤더 계정, 호스팅된 서비스, 에이전트별 SDK (Per-agent SDK)가 필요 없습니다. 그저 어떤 에이전트든 읽을 수 있고 어떤 에이전트든 업데이트할 수 있는 당신의 리포지토리 내 파일들일 뿐입니다.

아직 초기 단계입니다. 지금 제가 가장 관심을 두고 압박 테스트 (Pressure testing)하고 있는 것은 바로 이 논지 (Thesis)입니다.

만약 당신이 멀티 에이전트 코딩 워크플로우 (Multi-agent coding workflow)를 실행 중이며, 조정 문제 (Coordination problem)에 대한 자신만의 해답을 가지고 있다면, 그 이야기를 듣고 싶습니다. 만약 리포지토리가 올바른 기질 (Substrate)이라는 제 생각이 틀렸다고 생각하신다면, 그 의견 또한 정말 듣고 싶습니다.

Repo: https://github.com/lweiss01/holistic

컨텍스트 윈도우 (Window)가 아니라 리포지토리 (Repo)가 기억합니다. 그리고 그 어떤 단일 에이전트 (Agent)도 다른 에이전트들을 위해 기억하지 않습니다.