대부분의 에이전트는 세션이 끝나는 순간까지는 인상적입니다.

도구를 호출할 수 있습니다. 컨텍스트를 이해할 수 있습니다. 다른 에이전트와 협업할 수도 있습니다.

하지만 런타임이 바뀌거나, 클라이언트가 바뀌거나, 세션이 끝나면 메모리는 대개 그 제품 안에서 리셋됩니다.

이것이 AMCP가 해결하려는 갭입니다.

빠져 있던 계층

에이전트 인프라에는 이제 비교적 선명한 세 가지 계층이 보입니다.

MCP는 에이전트가 도구와 데이터 소스에 연결하는 방법을 다룹니다. A2A는 에이전트가 다른 에이전트에게 위임하고 협업하는 방법을 다룹니다. AMCP는 에이전트가 세션, 런타임, 클라이언트를 넘어 연속성을 유지하는 방법을 다룹니다.

이 셋은 경쟁하지 않습니다. 서로를 보완합니다.

에이전트는 MCP로 도구에 접근하고, A2A로 전문가와 협업하고, AMCP로 시간이 지나도 중요한 것을 기억할 수 있습니다.

AMCP가 표준화하는 것

AMCP, Agent Memory Continuity Protocol은 이식 가능한 장기 에이전트 메모리를 위한 오픈 프로토콜입니다.

이것은 모델 프로토콜이 아닙니다. 프롬프트 형식도 아닙니다. 추론 프레임워크도 아닙니다.

AMCP는 메모리 계약입니다.

AMCP v0.1은 다음을 정의합니다.

목표는 모든 메모리 시스템을 처음부터 다시 만들게 하는 것이 아닙니다. 실제 시스템이 채택할 수 있는 안정적인 상호 운용성 계층을 만드는 것이 목표입니다.

실제 예시: Claude Channels + Nexus

이 구분은 실제 흐름에서 더 분명해집니다.

Claude Channels는 실행 중인 세션이 외부 이벤트를 받을 수 있게 합니다. 즉, 에이전트는 더 이상 사용자가 터미널 앞에 앉아 있을 때만 반응하는 존재가 아닙니다. 메시지는 비동기적으로 도착할 수 있습니다.

하지만 Channels만으로는 장기 메모리가 생기지 않습니다.

우리는 Claude Channels와 Nexus를 함께 두고 다음과 같은 흐름을 확인했습니다.

  1. Claude를 공식 fakechat 채널과 함께 실행합니다.
  2. 채널을 통해 "이 사실을 기억해. 프로젝트 키워드는 blue-heron이야" 같은 메시지를 보냅니다.
  3. Claude가 nexus_remember를 호출해 그 사실을 Nexus에 저장합니다.
  4. Claude가 같은 채널로 응답합니다.
  5. Claude 세션을 완전히 재시작합니다.
  6. 새 세션에서 "아까 기억해달라고 한 프로젝트 키워드가 뭐였지?"라고 묻습니다.
  7. Claude가 nexus_recall을 호출해 메모리를 불러오고, 정확히 blue-heron이라고 답합니다.

이 흐름이 보여주는 것은 단순합니다.

접근성과 메모리는 다릅니다. Channels만으로는 연속성이 해결되지 않습니다. 별도의 메모리 계층이 필요합니다.

왜 지금 중요한가

에이전트는 이제 프로토타입을 넘어 실제 운영 환경으로 이동하고 있습니다. 프로덕션 환경에서는 연속성이 선택 사항이 아닙니다.

지금은 대부분의 제품이 각자 메모리 계층을 만듭니다. 임시적이고, 서로 호환되지 않고, 대개 제품 안에 잠깁니다.

AMCP는 여기에 대한 대안을 제시합니다. 에이전트 메모리를 위한 공유 표준입니다.

문서만으로는 충분하지 않다

프로토콜은 문서로 선언했다고 해서 실재하는 것이 아닙니다. 사람들이 구현하고, 검증하고, 시스템 간 동작을 비교할 수 있어야 합니다.

AMCP에는 이미 작동하는 참조 구현체가 있습니다.

표준은 문장이 아니라 실행되는 시스템으로 증명되어야 합니다.

마무리

MCP는 에이전트에게 도구를 줍니다. A2A는 에이전트에게 협업을 줍니다. AMCP는 에이전트에게 메모리 연속성을 줍니다.

세션, 런타임, 클라이언트를 넘어 기억이 이어져야 하는 에이전트를 만들고 있다면, AMCP는 그 빠져 있던 계층을 채우기 위한 프로토콜입니다.