AgentMemory, AI 에이전트에게 공용 기억 창고가 필요할까?

AI 에이전트를 며칠만 진지하게 써보면 이상한 장면을 자주 만난다.

어제는 분명히 같이 밤새 디버깅했다.

파일 구조도 봤고, 포트도 맞췄고, “이 프로젝트에서는 이 명령 쓰면 안 된다” 같은 뼈아픈 교훈도 얻었다.

그런데 오늘 새 세션을 열면?

안녕하세요. 무엇을 도와드릴까요?

약간 서운하다.

“우리 어제 꽤 친해진 줄 알았는데?” 싶은 순간이다.

그래서 나온 질문이 있다.

AI 에이전트에게도 장기기억이 필요하지 않을까?

오늘 살펴본 AgentMemory는 바로 그 질문에 꽤 정면으로 답하는 프로젝트다.

AgentMemory가 말하는 한 줄 소개

AgentMemory는 AI coding agent를 위한 persistent memory runtime이다.

조금 쉽게 말하면 이렇다.

Claude Code, Codex, Cursor, Hermes 같은 에이전트들이
각자 흩어져 기억하지 말고,
공용 기억 창고를 하나 두자는 아이디어

공식 사이트의 메시지는 꽤 세다.

• 모든 세션을 캡처한다
• 밀리초 단위로 다시 찾는다
• 외부 DB 없이 로컬에서 돈다
• MCP와 REST API로 여러 에이전트가 붙을 수 있다
• BM25 + vector + knowledge graph로 검색한다
• raw observation을 semantic memory로 압축한다

그러니까 단순한 “메모 파일”이 아니다.

좀 더 비유하자면, 에이전트 옆에 앉아 있는 기록 담당자다.

에이전트: 방금 이 파일 고쳤어.
기록 담당자: 적어둘게.

에이전트: 이 명령은 실패했어.
기록 담당자: 그것도 적어둘게.

다음 세션의 에이전트: 이 프로젝트 처음인데?
기록 담당자: 아니야. 어제 여기서 미끄러졌어. 이쪽으로 가.

이게 잘 되면 꽤 강력하다.

왜 흥미로운가: 기억은 도구가 아니라 작업 방식이다

AI 에이전트에게 memory가 중요한 이유는 “정보를 많이 저장해서”가 아니다.

진짜 이유는 작업의 마찰을 줄이기 때문이다.

개발 작업에는 반복 설명이 많다.

이 repo는 여기 있어.
테스트는 이 명령으로 돌려.
이 포트는 이미 쓰고 있어.
이 API는 문서랑 실제 동작이 달라.
이 프로젝트는 하드코딩 싫어해.
이 고객 문서에는 내부 구현을 쓰면 안 돼.

사람 동료라면 한두 번 말하면 점점 익숙해진다.

그런데 에이전트는 세션이 바뀔 때마다 기억이 끊기기 쉽다.

그래서 우리는 README, AGENTS.md, CLAUDE.md, skills, memory, session_search 같은 장치를 만든다.

AgentMemory는 이 흐름을 한 단계 더 밀어붙인다.

“각 에이전트 안에 기억을 조금씩 넣자”가 아니라,

에이전트 바깥에 독립적인 기억 레이어를 두자

라고 말한다.

이 관점이 재미있다.

Hermes와 비교하면 무엇이 다른가

내가 쓰는 Hermes에는 이미 기억 장치가 있다.

• 사용자 선호를 저장하는 memory
• 과거 대화를 찾는 session_search
• 반복 절차를 저장하는 skills
• 프로젝트별 작업 규칙
• cron/gateway/context 기반 자동화

그래서 “Hermes만 쓸 건데 AgentMemory가 꼭 필요한가?”라고 물으면, 내 답은 아직 “필수는 아니다”에 가깝다.

Hermes의 내장 방식은 꽤 실용적이다.

예를 들어 사용자가 “고객용 문서는 쉬운 한국어로, 내부 구현은 빼고”라고 선호를 말하면 memory에 남길 수 있다.

반복되는 QueryPie QCP 작업 방식은 skill로 만들 수 있다.

지난 대화에서 어디까지 했는지는 session_search로 찾을 수 있다.

즉 Hermes 내부에서는 이미 세 가지 층이 나뉘어 있다.

memory: 오래가는 사용자/환경 사실
skills: 반복 가능한 절차
session_search: 과거 대화의 실제 기록

이 구조가 꽤 건강하다.

그런데 AgentMemory의 강점은 다른 곳에 있다.

바로 “여러 에이전트가 같이 쓸 수 있는 외부 기억 레이어”라는 점이다.

AgentMemory가 빛나는 순간

AgentMemory가 가장 좋아 보이는 상황은 이런 경우다.

Hermes도 쓰고
Claude Code도 쓰고
Codex CLI도 쓰고
Cursor도 쓰고
가끔 Gemini CLI도 쓴다

각 에이전트가 자기 세션 안에서만 배운다면 비효율이 생긴다.

Claude Code가 어제 빌드 실패 원인을 찾아냈는데, 오늘 Codex가 같은 repo에서 다시 삽질할 수 있다.

Hermes가 어떤 프로젝트의 배포 함정을 기억하고 있는데, Cursor는 그걸 모를 수 있다.

이때 AgentMemory 같은 공용 기억 창고가 있으면 그림이 달라진다.

어제 Claude가 배운 것
오늘 Hermes가 이어받고
내일 Codex가 재사용한다

이건 꽤 매력적이다.

특히 MCP를 중심으로 에이전트 생태계가 연결되는 흐름에서는 더 그렇다.

도구는 이미 MCP로 공유되기 시작했다.

그 다음은 기억이다.

하지만 “기억력 좋은 에이전트”는 무조건 좋은가?

여기서부터 조심해야 한다.

기억은 강력하지만, 무조건 많을수록 좋은 건 아니다.

사람도 그렇다.

회의에서 한 말, 실수, 임시 비밀번호, 고객 이름, 아직 확정 안 된 아이디어를 전부 영원히 기억하는 동료가 있다고 생각해보자.

유능할 수도 있지만 조금 무섭다.

AgentMemory류 시스템에서도 같은 문제가 생긴다.

첫 번째 리스크: 민감정보

AgentMemory는 “capture everything”에 가까운 방향을 강조한다.

이건 편하지만 위험하다.

에이전트 작업에는 민감한 정보가 자주 지나간다.

API key
access token
고객사 이름
Jira 티켓 내용
내부 서버 주소
DB 접속 문자열
로그에 찍힌 개인정보

물론 AgentMemory 문서에는 privacy filter와 secret stripping 흐름이 언급되어 있다.

그래도 실제 운영에서는 확인해야 한다.

“기능이 있다”와 “내 환경에서 안전하게 켜져 있다”는 다른 말이다.

특히 고객 지원, 재무, OCR, 회계, 사내 Slack/Jira를 다루는 환경이라면 더 보수적으로 봐야 한다.

두 번째 리스크: 잡음

기억이 많아지면 똑똑해질 것 같지만, 실제로는 잡음이 늘 수 있다.

중요하지 않은 실패 로그.

임시로 바꾼 설정.

지금은 폐기된 설계.

어제는 맞았지만 오늘은 틀린 우회 방법.

이런 것들이 recall에 섞이면 에이전트는 과거의 유령과 같이 일하게 된다.

“예전에 이렇게 했던 것 같은데요?”

이 말이 도움이 될 때도 있지만, 발목을 잡을 때도 있다.

좋은 memory system은 많이 기억하는 시스템이 아니다.

잘 잊는 시스템이다.

AgentMemory가 consolidation, decay, stale row 처리 같은 기능을 강조하는 이유도 여기에 있다.

세 번째 리스크: 기존 기억 시스템과의 중복

Hermes에는 이미 memory, skills, session_search가 있다.

여기에 AgentMemory를 그대로 붙이면 이런 일이 생길 수 있다.

Hermes memory도 말한다
Hermes skill도 말한다
session_search도 말한다
AgentMemory도 말한다

그러면 에이전트 입장에서는 회의실에 조언자가 너무 많아진다.

다들 좋은 말을 하지만, 누가 최종 기준인지 헷갈린다.

그래서 통합할 때는 역할을 분리해야 한다.

내 기준은 이렇다.

Hermes memory: 사용자 선호와 안정적인 환경 사실
Hermes skills: 반복 절차와 검증된 workflow
Hermes session_search: 실제 과거 대화 추적
AgentMemory: 여러 coding agent가 공유하는 프로젝트 작업 기억

이렇게 나누면 충돌이 줄어든다.

반대로 “전부 다 AgentMemory에 넣자”는 방향은 아직 위험해 보인다.

내가 추천하는 도입 방식

바로 메인 워크플로우에 넣지는 않겠다.

대신 이렇게 해볼 것 같다.

1. 샌드박스 프로젝트 하나에서만 시작

중요한 고객 데이터나 사내 민감정보가 없는 테스트 repo를 고른다.

거기서만 AgentMemory를 켠다.

목표는 단순하다.

정말 다음 세션에서 유용한 기억을 잘 꺼내주는가?

2. 로컬 only로 둔다

처음부터 team sync나 peer-to-peer sync를 켜지 않는다.

일단 로컬에서 어떤 데이터가 저장되는지 본다.

저장 위치, 삭제 방식, export 방식, viewer 노출 범위도 확인한다.

3. secret redaction을 실제로 검증한다

문서에 있다고 믿지 말고, 테스트 값을 넣어 확인한다.

가짜 API key를 tool output에 흘렸을 때
정말 저장 전에 제거되는가?
viewer에는 어떻게 보이는가?
export에는 남지 않는가?

이건 꼭 해봐야 한다.

4. Hermes에는 MCP로 얇게 붙인다

처음부터 Hermes의 기본 memory처럼 쓰지 않는다.

MCP 도구로 필요한 때만 recall하는 방식이 좋다.

에이전트 시작 시 자동 주입되는 context도 너무 크지 않게 제한한다.

기억은 도움이 되어야지, 회의 시작 5분 전부터 혼자 떠들면 안 된다.

5. 1~2주 뒤 평가한다

평가 기준은 기능 목록이 아니다.

실제 작업에서 이 질문에 답해야 한다.

반복 설명이 줄었나?
잘못된 recall이 늘지는 않았나?
민감정보 저장 위험은 관리 가능한가?
Hermes skills/session_search와 역할이 겹치지 않는가?
여러 에이전트가 같은 프로젝트에서 더 자연스럽게 이어달리기 하는가?

여기에 “그렇다”가 많으면 계속 쓴다.

아니면 과감히 끈다.

결론: 기억 창고는 필요하다. 하지만 문지기도 필요하다.

AgentMemory는 꽤 흥미로운 프로젝트다.

특히 여러 AI coding agent를 동시에 쓰는 사람에게는 방향성이 좋다.

앞으로 에이전트 세계는 아마 이렇게 갈 가능성이 높다.

도구는 MCP로 연결되고
기억은 독립 memory layer로 공유되고
작업 규칙은 skills/playbooks로 축적된다

AgentMemory는 그중 “기억” 쪽을 정면으로 파고든다.

다만 기억은 항상 양날의 검이다.

잘 쓰면 동료가 된다.

잘못 쓰면 잡음 많은 CCTV가 된다.

그래서 내 결론은 이렇다.

Hermes만 쓴다면 필수는 아니다.
여러 coding agent를 섞어 쓴다면 PoC 해볼 만하다.
단, 민감정보와 recall noise를 먼저 검증해야 한다.

AI 에이전트에게 필요한 건 완벽한 기억력이 아니다.

필요한 순간에, 필요한 만큼만, 안전하게 떠올리는 능력이다.

AgentMemory가 그 역할을 얼마나 잘 해낼지.

샌드박스에서 한 번쯤 시험해볼 이유는 충분해 보인다.