메모리가 표준이 된다: 에이전트 인프라의 다음 전선
LangChain 창업자가 '메모리 오픈 스탠더드'를 선언하고, Mozilla 보고서가 '하네스가 승부처'라고 외부 검증했다. 세 오픈소스 프로젝트의 동시 등장이 뜻하는 것을 AI PM 관점으로 분석한다.
지난주 LangChain 창업자 해리슨 체이스(hwchase17)가 선언 하나를 꺼냈습니다.
“메모리도 오픈 스탠더드로 가야 한다.”
OKF(Open Knowledge Foundation)와 OpenWiki 프로젝트를 언급하며, 에이전트가 기억하는 방식이 벤더마다 달라서는 안 된다는 주장입니다. 같은 주 Mozilla 재단이 발표한 보고서는 이 주장에 힘을 실어줬습니다. 보고서의 결론은 단순합니다. “AI 에이전트의 승부는 모델이 아니라 하네스에서 난다.”
여기에 gstack 전문가 55명이 참여한 오픈 표준 논의, Grok Build, Vercel Eve — 실행 레이어 오픈소스 프로젝트 세 건이 한 주 안에 동시 공개됐습니다.
세 신호가 같은 방향을 가리킵니다. 메모리가 에이전트 인프라의 다음 표준 전선으로 이동하고 있습니다.
왜 지금 메모리인가
에이전트 경쟁 1라운드는 모델 성능이었습니다. GPT-4 vs Claude vs Gemini — 누가 더 똑똑한가를 벤치마크로 겨뤘습니다. 모델 API를 바꾸면 성능이 오른다는 믿음이 시장을 지배했습니다.
2라운드는 오케스트레이션이었습니다. 어떤 프레임워크가 에이전트 역할을 잘 분리하고 툴 호출을 잘 연결하는가. LangGraph, AutoGen, CrewAI가 이 전선에서 경쟁했고, MCP가 툴 연결의 공통 언어로 자리를 잡았습니다.
3라운드가 시작됐습니다. 메모리입니다.
지금 에이전트 시스템에서 메모리는 완전히 파편화돼 있습니다. 한 에이전트는 벡터 DB에 저장하고, 다른 에이전트는 요약 파일에 씁니다. 멀티에이전트 환경에서 에이전트 A가 기억한 것을 에이전트 B가 읽을 방법이 없습니다. 표준이 없기 때문입니다.
hwchase17은 이 문제를 정확히 짚었습니다. 메모리가 표준화되지 않으면 오케스트레이션이 파편화된 채로 남는다고. MCP가 툴 연결의 표준이 됐듯, 메모리도 같은 경로를 따를 것이라는 예측입니다.
하네스가 모델을 이긴다: Mozilla가 확인한 명제
Mozilla 보고서의 “승부는 하네스다”라는 결론은 벤더 중립 기관의 외부 검증이라는 점에서 무게가 다릅니다. 에이전트 인프라 회사들이 자사 제품을 팔기 위해 하는 주장이 아니라, 제3자 기관이 내린 결론입니다.
이 명제가 중요한 이유는 하나입니다. 메모리는 하네스의 핵심입니다.
컨텍스트 엔진이 없으면 에이전트는 매번 처음부터 시작합니다. 사용자는 같은 맥락을 반복해 입력해야 하고, 에이전트는 이전 실행에서 아무것도 배우지 못합니다. 토큰 비용은 올라가고 품질은 제자리입니다.
반대로 메모리 레이어가 설계된 에이전트는 다릅니다. NAVER의 통합 Context Provider 사례가 이를 잘 보여줍니다. 메타데이터와 계보(lineage)까지 포함한 단일 컨텍스트 소스를 구성했을 때, 같은 모델을 쓰면서도 에이전트 응답 품질이 크게 달라졌습니다. 모델 교체 없이, 메모리 레이어 하나로.
gstack 55명이 참여한 오픈 표준 논의가 이 방향을 뒷받침합니다. 전문가 커뮤니티가 메모리 인터페이스 표준을 직접 설계하기 시작했다는 것은 시장이 여기에 실질적인 문제를 느끼고 있다는 신호입니다.
AI PM이 지금 물어야 할 질문
세 신호가 수렴하는 시점에서 AI PM이 해야 할 질문은 이겁니다.
우리 에이전트는 지금 무엇을 기억하고 있는가?
기억 체계가 없다면 에이전트는 반복 작업을 반복 비용으로 처리합니다. 기억 체계가 있어도 벤더 종속형이라면 스택 이동 시 메모리를 잃습니다. 멀티에이전트 환경에서 공유되지 않는 기억은 고립된 사일로입니다.
지금 설계해야 할 메모리 레이어는 세 가지 조건을 만족해야 합니다.
첫째, 지속성(persistence). 세션이 끝나도 기억이 남아야 합니다. 대화 창을 닫으면 모든 맥락을 잃는 구조는 에이전트가 아니라 더 비싼 챗봇입니다.
둘째, 공유 가능성(shareability). 에이전트 A의 기억을 에이전트 B가 접근할 수 있어야 합니다. 멀티에이전트 시스템에서 메모리 사일로는 오케스트레이션의 병목이 됩니다.
셋째, 감사 가능성(auditability). 에이전트가 왜 그것을 기억하고 있는지 추적 가능해야 합니다. 이 조건이 종종 빠집니다. 메모리는 저장이 아니라 신뢰의 레이어이기 때문입니다. 에이전트가 기억한 것이 맞는지, 편향됐는지, 오래된 것인지를 운영자가 볼 수 있어야 합니다.
세 번째 조건이 없으면 메모리는 블랙박스가 됩니다. 에이전트가 왜 그런 판단을 내렸는지 설명할 수 없는 시스템은 엔터프라이즈 환경에서 신뢰를 얻지 못합니다.
표준이 되기 전에 움직이는 팀이 이긴다
hwchase17의 “오픈 스탠더드 메모리” 주장은 아직 제안 단계입니다. OKF, OpenWiki 등의 논의가 MCP처럼 업계 표준으로 굳어지기까지 시간이 필요합니다.
하지만 표준화 논의가 시작됐다는 것 자체가 신호입니다.
MCP가 공식 표준으로 자리잡기 전에 먼저 채택한 팀이 에이전트 스택에서 유리한 위치를 가져갔듯, 메모리 레이어를 먼저 설계한 팀이 다음 라운드에서 앞서게 됩니다. 표준이 정해지면 기존 설계를 표준에 맞추는 비용이 발생합니다. 반대로 표준 논의에 맞게 먼저 설계한 팀은 마이그레이션 비용 없이 생태계 확장의 혜택을 가져갑니다.
모델 경쟁은 수렴합니다. 하네스 경쟁은 분화합니다. 그리고 하네스의 핵심은 메모리입니다.
지금 에이전트 스택에서 메모리 레이어가 없다면, 표준이 만들어지기 전에 자체 기준부터 세워야 할 때입니다.
당신의 에이전트는 지금 무엇을 기억하고 있습니까?