Nunchi AI 메모리 생태계 아키텍처

AI 에이전트는 도구를 쓰는 데 점점 능숙해지고 있습니다. 웹을 검색하고, API를 호출하고, 코드를 쓰고, 파일을 관리합니다. 그런데 지난주에 무슨 이야기를 했는지, 프로젝트를 가로질러 어떤 결정을 내려왔는지, 내 선호가 어떻게 바뀌어 왔는지를 물어보면 아무것도 없습니다.

도구 레이어에는 MCP가 있습니다. 협업 레이어에는 A2A가 있습니다. 메모리 레이어에는 아직 아무것도 없습니다. 모든 에이전트가 매 세션마다 0에서 시작합니다.

Nunchi AI는 그 빠진 레이어를 만들기 위해 존재합니다.

한 문장으로 요약한 문제

당신의 AI 메모리는 한 도구, 한 세션, 한 벤더의 독점 포맷 안에 갇혀 있고, 맥락을 바꾸는 순간 사라집니다.

이건 사소한 불편이 아닙니다. 메모리는 범용 AI를 당신의 AI로 바꾸는 요소입니다. 지속적이고 이식 가능한 메모리가 없다면, 어떤 에이전트든 같은 모델 접근권과 같은 도구 통합을 가진 경쟁자로 쉽게 대체됩니다. 메모리가 해자입니다.

그런데 지금 이 문제를 풀겠다고 나온 거의 모든 시도, Claude 내장 메모리, ChatGPT 메모리, Mem0, Zep, MemPalace는 지식을 한 플랫폼 안에 잠급니다. 도구를 바꾸면 히스토리를 잃고, 모델을 바꾸면 다시 시작합니다. 데이터 사일로에서 보던 락인 패턴이 반복되는 건데, 이번에는 그 사일로 안에 갇히는 데이터가 당신이 축적한 지능이라는 점이 다를 뿐입니다.

다섯 컴포넌트, 하나의 아키텍처

Nunchi AI 생태계는 하나의 단순한 확신 위에 서 있습니다. 메모리는 어떤 단일 제품의 기능이 아니라 인프라여야 한다는 것.

이 생태계는 네 개 레이어에 걸친 다섯 개 컴포넌트로 이루어져 있습니다. 각자 하나의 일을 맡습니다. 함께 보면 어느 단일 제품도 종단 간으로 독점하지 않는 완전한 메모리 스택이 됩니다.

Layer 1: Synapsis Engine — 기반층

모든 메모리 시스템은 먼저 한 질문에 답해야 합니다. 지저분하고 길게 늘어진 대화를 어떻게 구조화된 지식으로 바꿀 것인가?

Synapsis는 그 질문에 답하는 atomization 엔진입니다. 원시 대화를 가져와 atom이라는 이산적 지식 단위로 쪼갭니다. 각 atom에는 type, confidence, temporal scope, domain, 그리고 다른 atom과의 relational link가 붙습니다. 예를 들어 하나의 대화에서 이런 atom이 나올 수 있습니다.

이건 원문 대화 텍스트를 그대로 저장한 뒤 나중에 검색하는 것과 근본적으로 다릅니다. Raw storage는 retrieval, 즉 "우리가 auth를 논의한 대화를 찾아라"에 최적화됩니다. Atomization은 이해에 최적화됩니다. "지금 우리의 auth provider는 무엇이고, 왜 그렇게 정했는가?"

Synapsis는 이 생태계의 세 백엔드를 모두 구동합니다. 어떤 제품을 쓰더라도 일관된 지식 표현을 보장하는 공통 기반입니다.

광범위한 벤치마킹, LongMemEval 6회 이터레이션 테스트를 통해 세 가지 설계 법칙이 나왔습니다.

  1. Atom은 절대 삭제하지 말고 temporal marker로 invalidate할 것
  2. Atom 순서는 절대 바꾸지 말 것. 삽입 순서 자체가 암묵적 시간 신호다
  3. Retrieval score에 비유사도 신호를 주입하지 말 것. Recall 경로는 깨끗하게 유지할 것

이건 이론이 아니라, 실제 테스트에서 나온 경험적 결과입니다.

Layer 2: AMCP — 계약

AMCP(Agent Memory Continuity Protocol)는 하니스와 백엔드 사이에 놓이는 오픈 표준입니다. Apache 2.0 라이선스입니다. 다음을 정의합니다.

핵심 통찰은 이겁니다. 메모리는 제품이 아니라 프로토콜이어야 한다. MCP가 어떤 에이전트든 어떤 도구든 연결할 수 있게 만들었다면, AMCP는 어떤 하니스든 어떤 메모리 백엔드든 연결할 수 있게 만듭니다.

이 말은 곧:

AMCP는 portability 문제에 대한 답입니다. 메모리는 도구 벤더가 아니라 당신의 것입니다.

Spec: github.com/goldberg-aria/amcp

Layer 3: 세 개의 백엔드, 세 종류의 사용자

세 백엔드는 모두 AMCP를 구현하고 Synapsis 위에서 돌아갑니다. 하지만 각기 다른 사용자와 다른 요구를 담당합니다.

Nexus는 에이전트와 개발자를 위한 레퍼런스 백엔드입니다. Atomization pipeline, recall 알고리즘, 벤치마크가 가장 먼저 일어나는 곳입니다. 지속 메모리가 필요한 에이전트를 만든다면, Nexus가 연결할 백엔드입니다. AMCP 엔드포인트 (/v1/amcp/remember, /v1/amcp/recall, /v1/amcp/export, /v1/amcp/import)를 노출하고, atom 저장, relation 관리, scope-aware retrieval의 복잡성을 처리합니다.

Norfolk는 개인용 지식 백엔드입니다. Nexus가 에이전트 워크플로우에 최적화돼 있다면, Norfolk는 한 사람의 평생 지식, 노트, 대화, 문서, 그리고 그 사이 연결에 최적화됩니다. CLI-first 구조로, 서버는 저장과 검색을 맡고, 웹 인터페이스는 보기와 정리를 맡고, 모바일은 수집을 맡습니다. Citation graph와 provenance grading 덕분에 모든 지식 조각이 어디서 왔는지 추적할 수 있습니다.

MaaS (Memory as a Service)는 엔터프라이즈 배포 모델입니다. Nexus와 같은 atomization과 recall 기능을 제공하지만, multi-tenant isolation, team-level scoping, enterprise knowledge API path가 추가됩니다. TravelSpeak(언어 학습 앱)와 IndiePulse(AI 운영 에디토리얼 매거진) 같은 제품이 MaaS 위에서 돌아가며, 사용자는 뒤의 기계를 의식하지 않아도 시간이 지날수록 더 나아지는 지속 메모리를 얻습니다.

세 제품. 하나의 atom shape. 하나의 프로토콜. 하나의 엔진.

Layer 4: 3122 — 레퍼런스 클라이언트

동작하는 클라이언트 없는 프로토콜은 그냥 PDF입니다. 3122는 AMCP가 실제로 작동한다는 증명입니다.

3122는 terminal-first, model-neutral 코딩 하니스입니다. 내장 모델은 없습니다. Anthropic, OpenAI, Ollama 등 API를 직접 붙이거나 Claude Code와 Codex용 authenticated adapter를 쓸 수 있습니다. 나머지, 프롬프트, 권한, 도구 실행, 세션 연속성, 백엔드 선택은 하니스가 처리합니다.

3122에서 중요한 설계 결정은 두 종류 상태를 명시적으로 분리한 것입니다.

Continuity Runtime State는 하니스 로컬에 남습니다.

Portable Memory는 AMCP를 통해 흐릅니다.

하니스는 모든 context management 결정을 내립니다. 무엇을 프롬프트에 넣을지, 세션이 길어질수록 토큰을 어떻게 배분할지, compaction 때 무엇을 남길지. 하지만 그 결정의 결과는 portable memory로 흘러갑니다. 워크스페이스를 지우고 다시 만들고 같은 백엔드에 연결해도, 지식은 살아 있습니다.

3122 memory export --format amcp-jsonl --output my-knowledge.jsonl
3122 memory migrate --from local-amcp --to nexus-cloud

Repo: github.com/goldberg-aria/3122-harness

왜 이 아키텍처인가

지금 업계의 에이전트 메모리 논의는 두 입장 사이에 갇혀 있습니다.

한쪽은 메모리는 하니스 안에 박혀 있어야 한다고 말합니다. Context management와 너무 밀접해서 분리할 수 없다는 입장입니다. Letta/MemGPT 쪽 시각입니다. 문제는 메모리가 하니스 선택과 함께 죽는다는 점입니다.

다른 쪽은 하니스를 오픈소스로 만들면 된다고 말합니다. LangChain/Deep Agents 쪽 시각입니다. 문제는 오픈소스 하니스도 여전히 독점 메모리 포맷을 쓴다는 점입니다. 하니스를 바꾸는 순간 커스텀 ETL을 써야 하고, 번역 과정에서 뭘 잃지 않기를 바랄 수밖에 없습니다.

Nunchi AI 생태계는 세 번째 입장을 택합니다. 관심사를 분리하고, 인터페이스를 표준화한다.

하니스는 context management를 맡고, 메모리 레이어는 persistence와 recall을 맡고, AMCP가 둘을 연결합니다. 어느 쪽도 닫힌 시스템이 아니기 때문에 락인을 만들지 않습니다.

이건 인터넷을 만든 것과 같은 패턴입니다. HTTP는 오픈소스 브라우저를 요구하지 않았습니다. 어떤 브라우저든 구현할 수 있는 열린 프로토콜을 요구했습니다. AMCP는 에이전트 메모리의 그런 프로토콜입니다.

현재 상태

다음 단계

하니스와 메모리의 분리는 이미 작동합니다. 다음 단계는 그 경계를 더 풍부하게 만드는 일입니다.

Trajectory auto-promotion — 하니스에서 성공한 작업 패턴이 자동으로 portable memory atom이 되게 하기.

Budget-negotiated recall — 하니스가 메모리 백엔드에 "내 예산은 2,000토큰이니 가장 중요한 atom만 줘"라고 말하게 하기.

Compaction checkpoints — 하니스가 context를 compact할 때 무엇이 떨어졌는지 AMCP에 알려, 보이지 않는 결정을 보이게 하고 복구 가능하게 만들기.

Capability advertisement — AMCP 백엔드가 연결 시점에 지원 기능을 선언하게 해서, 최소한의 서드파티 구현도 동작하고, 풀 구현은 고급 기능을 열 수 있게 하기.

이 베팅

우리는 메모리가 에이전트 스택에서 가장 중요한 레이어가 된다고 보고 있습니다. 도구는 이미 상품화되고 있습니다. 어떤 에이전트든 어떤 API든 호출할 수 있습니다. 모델도 상품화되고 있습니다. 성능은 수렴하고 가격으로 경쟁합니다. 상품화되지 않는 것은 축적된 이해입니다. 몇 달, 몇 년의 상호작용 동안 에이전트가 당신과, 당신의 프로젝트와, 팀과, 선호에 대해 쌓아가는 지식입니다.

그 지식은 당신의 것이어야 합니다. 모델 제공자의 것도, 하니스 벤더의 것도, 다른 누군가 서버 위 독점 데이터베이스에 갇혀 있는 것도 아니라.

그걸 만들고 있는 것이 Nunchi AI입니다.

---

AMCP: github.com/goldberg-aria/amcp 3122: github.com/goldberg-aria/3122-harness Nunchi AI: nunchiai.com