에이전트 메모리를 둘러싼 대화가 점점 커지고 있는데, 저는 지금 모두가 질문을 잘못 던지고 있다고 생각합니다.

최근 Letta의 CTO인 Sarah Wooders는 "메모리는 플러그인이 아니라 하니스다"라고 썼고, LangChain의 CEO인 Harrison Chase는 하니스를 소유하지 못하면 메모리도 소유하지 못한다고 이어서 주장했습니다. 문제 진단은 둘 다 맞습니다. 하지만 해법은 둘 다 틀렸다고 봅니다.

그들이 짚은 문제

진단 자체는 정확합니다. Anthropic의 Managed Agents는 모든 것을 API 뒤에 넣어버립니다. 에이전트의 메모리가 그 플랫폼 안에 잠깁니다. OpenAI의 Codex는 그 생태계 밖에서는 쓸 수 없는 암호화된 compaction summary를 만듭니다. 모델 제공자가 메모리를 소유하는 순간, 전환 비용은 감당하기 어려워집니다.

Harrison은 인상적인 사례를 하나 들었습니다. 자기 이메일 에이전트가 실수로 삭제됐고, 같은 템플릿으로 다시 만들어도 경험이 훨씬 나빠졌다는 이야기입니다. 학습된 선호, 말투, 맥락이 전부 사라졌습니다.

이건 진짜 문제입니다. 메모리는 에이전트를 "내 것"으로 만드는 요소입니다. 메모리가 없으면 어떤 에이전트든 쉽게 대체 가능합니다.

제가 동의하지 않는 지점

Sarah의 해법은 메모리를 하니스 안에 더 깊게 넣는 것입니다. Harrison의 해법은 하니스를 오픈소스로 만드는 것입니다.

둘 다 메모리와 하니스가 분리될 수 없다고 전제합니다. 저는 그렇지 않다고 봅니다. 오히려 서로 다른 두 책임을 한데 묶는 것이 락인 문제를 만드는 원인이라고 생각합니다.

Sarah가 하니스의 "보이지 않는 결정들"을 말할 때, 무엇이 compaction 이후에도 남는지, 어떻게 컨텍스트를 불러오는지, 무엇을 queryable하게 둘지를 말할 때, 사실은 두 가지를 동시에 설명하고 있습니다.

컨텍스트 관리: 무엇을 프롬프트에 넣을지, 토큰을 어떻게 배분할지, 언제 compaction할지, 도구 결과를 어떻게 보여줄지. 이건 정말 하니스의 일입니다.

메모리 저장과 회상: 세션을 넘어 지식을 저장하고, 관련 히스토리를 꺼내고, 도구와 워크플로우를 넘어 연속성을 유지하는 일. 이건 별도 레이어가 될 수 있고, 그래야 합니다.

하니스는 무엇을 기억할지 결정합니다. 메모리 레이어는 어떻게 저장하고 꺼낼지 결정합니다. 둘은 생명주기도 다르고, 책임도 다릅니다.

왜 분리가 중요한가

하니스는 일시적입니다. Claude Code, Cursor, Windsurf, Codex, Aider, 판은 몇 달마다 바뀝니다. 메모리가 하니스 안에 박혀 있으면, 마이그레이션할 때마다 처음부터 다시 시작해야 합니다. Harrison의 삭제된 이메일 에이전트 사례는 약한 버전입니다. 더 심한 버전은, 어떤 기업이 6개월 동안 쌓은 에이전트 지식을 한 하니스 안에 넣어뒀는데, 그 하니스가 폐기되는 경우입니다.

오픈소스 하니스도 이 문제를 완전히 해결하지는 못합니다. Deep Agents는 Mongo/Postgres/Redis 플러그인에 메모리를 저장하지만, 메모리 스키마, recall 로직, atom 구조는 모두 Deep Agents 전용입니다. 다른 하니스로 옮기려면 커스텀 ETL을 써야 하고, 옮긴 쪽이 그 지식을 해석할 수 있으리라는 보장도 없습니다.

정말 필요한 건 어떤 하니스든 말할 수 있는 메모리 계약입니다.

AMCP: 메모리 프로토콜

그래서 제가 AMCP(Agent Memory Continuity Protocol)를 만들고 있습니다. 도구를 위한 MCP, 에이전트 협업을 위한 A2A 옆에 서는, 에이전트 메모리를 위한 세 번째 인프라 레이어로 위치시키는 오픈 표준입니다.

AMCP는 에이전트가 메모리를 저장하고 회상하는 방식을 위한 벤더 중립 계약을 정의합니다. 하나의 item shape. 하나의 recall 인터페이스. 하나의 export format. AMCP를 말할 수 있는 어떤 하니스든, 어떤 AMCP 호환 백엔드에든 읽고 쓸 수 있습니다.

스펙은 Apache 2.0으로 github.com/goldberg-aria/amcp에 있습니다.

3122: 이 아키텍처가 실제로 된다는 증명

이론은 싸게 만들 수 있습니다. 분리된 메모리가 내장형 메모리만큼 깊게 통합될 수 있다는 걸 증명하려고, 저는 AMCP 네이티브이면서 모델 중립적인 코딩 하니스 3122를 만들었습니다.

3122는 의도적으로 두 층을 나눕니다.

Continuity Runtime State (하니스 소유, 로컬에 남음):

Portable Memory (AMCP 소유, 이동 가능):

하니스는 Sarah가 말한 모든 컨텍스트 결정을 내립니다. 프롬프트에 무엇을 넣을지, 세션이 길어질 때 토큰을 어떻게 배분할지, compaction 때 무엇을 남길지. 하지만 그 결정의 결과물은 AMCP를 통해 이식 가능한 메모리 item으로 흘러갑니다.

이게 가능하게 하는 것은 이렇습니다.

# 메모리 내보내기
3122 memory export --format amcp-jsonl --output my-knowledge.jsonl

# 호스팅 백엔드로 이동
3122 memory migrate --from local-amcp --to nexus-cloud

# 워크스페이스를 지우고 새로 세팅해도 다시 연결하면 메모리는 살아 있음
3122 memory recall 10

하니스 인스턴스는 죽어도 됩니다. 메모리는 살아남습니다.

레포는 github.com/goldberg-aria/3122-harness에 있습니다.

"깊은 통합" 우려에 대한 답

Sarah의 주장 중 가장 강한 버전은, 분리된 메모리 레이어는 내장형만큼 깊게 통합될 수 없다는 것입니다. 3122의 설계는 바로 그 지점을 반박합니다.

Trajectory-aware recall: 작업 중일 때 recall은 현재 trajectory와 관련된 atom을 우선합니다. 지금 만지는 파일, 맞닥뜨린 에러, 실행한 verification 단계가 기준이 됩니다. 이건 단순 similarity search가 아닙니다. 하니스의 운영 맥락이 recall 대상을 바꿉니다.

Budget-aware context: 긴 세션은 점진적으로 degrade됩니다. 컨텍스트 예산이 줄어들면 3122는 conversation recall부터, 그다음 오래된 memory, 그다음 recent history, 마지막으로 instructions를 줄입니다. 메모리 레이어가 여기에 참여하려면 하니스 안에 박혀 있을 필요가 없습니다. 예산 신호를 받으면 됩니다.

Handoff continuity: 세션 중간에 모델을 바꾸면 (/model claude-sonnet-4-20250514 -> /model gpt-4.1) 3122는 handoff snapshot을 저장하고 새 모델의 첫 턴에 임시 컨텍스트 부스트를 줍니다. 이식 가능한 메모리 레이어는 세션 간 연속성을 주고, 하니스는 세션 내 연속성을 줍니다. 깔끔하게 분리되면서도 빈틈이 없습니다.

Compaction without loss: 하니스가 컨텍스트를 compaction할 때, 무엇을 떨어뜨렸는지 그 신호를 메모리 레이어에 보낼 수 있습니다. 아무것도 조용히 사라지지 않습니다. 하니스의 "보이지 않는 결정"이 보이는 결정이 되고, 복구 가능한 결정이 됩니다.

락인 논리를 뒤집어 보면

Harrison은 메모리가 락인을 만들기 때문에 오픈 하니스가 필요하다고 말합니다. 저는 반대로 봅니다. 메모리가 락인을 만드는 이유는 바로 하니스와 결합되어 있기 때문입니다.

메모리를 하니스에서 떼어내고, 프로토콜을 표준화하면, 락인은 사라집니다. 오늘은 Claude Code를 쓰고, 내일은 Cursor로 옮기고, 다음 주엔 Codex를 써도, 그동안 쌓은 지식을 그대로 가져갈 수 있습니다. 모든 하니스가 오픈소스여서가 아니라, 모두가 AMCP를 말하기 때문입니다.

이건 웹이 작동하게 된 방식과 같습니다. HTTP는 오픈소스 브라우저를 요구하지 않았습니다. 어떤 브라우저든 구현할 수 있는 열린 프로토콜을 요구했습니다. AMCP는 에이전트 메모리를 위한 그런 프로토콜입니다.

생태계

현재 스택은 이렇습니다.

레이어구성요소역할
표준AMCP벤더 중립 메모리 계약
백엔드Nexus에이전트/개발자용 레퍼런스 AMCP 백엔드
백엔드Norfolk개인 평생 메모리
백엔드MaaS엔터프라이즈 메모리 인프라
클라이언트3122계약이 실제로 작동한다는 걸 보여주는 레퍼런스 하니스

Nexus는 첫 번째 호스팅 백엔드입니다. 하지만 AMCP는 누구나 백엔드를 만들 수 있도록, 그리고 어떤 하니스든 클라이언트가 될 수 있도록 설계됐습니다. 목표는 Claude Code나 Deep Agents를 대체하는 게 아닙니다. 모든 하니스가 자신보다 오래 사는 메모리 레이어를 갖게 하는 것입니다.

다음에 만들 것

분리는 됩니다. 다음 단계는 경계를 더 풍부하게 만드는 일입니다.

써보기

메모리는 당신의 것이어야 합니다. 하니스 벤더의 것도, 모델 제공자의 것도 아니라, 당신의 것이어야 합니다.