Claude Projects에서 기술 담당, 사업 담당, 학습 코치 담당 등 역할이 다른 여러 개의 AI 에이전트를 병렬로 운영하고 있습니다. 현재는 8체를 운용 중입니다.

한동안 운영하면서 알게 된 것은 'AI에게 같은 설명을 반복하는 것'이라는 문제가 모델의 성능만으로는 해결할 수 없다는 것이었습니다.

세션이 바뀔 때마다, 지난번 어디까지 진행했는지, 무엇을 결정했는지, 무엇을 보류했는지가 사라집니다. 에이전트가 늘어날수록 이 문제는 더 커졌습니다.

그 결과 만든 것이 Agent Memory Server(AMS)라는 셀프 호스팅형 메모리 서버입니다. 이번에 OSS로 공개했습니다.

본 글에서는 기능 목록을 나열하기보다, '무엇이 원활하지 않았고 왜 이런 설계가 되었는지'를 중심으로 작성하겠습니다.

AI 에이전트를 늘리니 무엇이 망가졌나

처음에는 하나의 에이전트에게 대화 기록만 읽히면 충분했습니다.

그런데 역할이 다른 에이전트들을 병렬로 사용하게 되자 몇 가지 문제가 발생했습니다.

같은 설명을 반복하는 문제

기술 담당에게 이야기한 내용을 사업 담당은 알지 못합니다.

그 자체는 당연하지만, 세션을 넘어서도 같은 담당이라 하더라도 이전의 맥락이 끊어집니다.

• 지난번 어디까지 작업했는지
• 이전에 어떤 설계 판단을 했는지
• 해당 에이전트가 무엇을 담당하고 있는지
• 무엇이 완료되었고, 무엇이 미완료인지
• 건드려서는 안 되는 설정은 무엇인지

이런 것들을 매번 사람이 설명해 주고 있으면, AI를 늘릴수록 인계 부담도 커져 버립니다.

다른 담당 영역에 기록을 남기는 문제

여러 에이전트가 같은 메모리 기반을 사용하면, 어떤 에이전트가 다른 에이전트의 기억을 덮어쓸 가능성이 있습니다.

예를 들어, 기술 담당이 사업 담당의 판단으로 저장된 기억을 수정해 버리는 경우입니다.

단순히 기억을 공유하는 것만으로는 부족했고, '누가 그 기억을 소유하고 있는지'도 필요하게 되었습니다.

에이전트의 자발성에 의존하는 문제

처음에는 에이전트에 다음과 같은 지시를 넣으면 될 것이라고 생각했습니다.

• 세션 시작 시 메모리를 검색한다
• 확정된 정보는 메모리에 저장한다

하지만 실제로는 안정적이지 않았습니다.

대화가 길어지거나 다른 지시가 늘어나면, 에이전트가 메모리를 보지 않는 경우가 있었습니다. 저장해야 할 확정 사항이 나와도, 저장 도구를 호출하지 않을 때가 있었습니다.

프롬프트에 규칙을 적는 것만으로는 매번 확실하게 실행된다고 장담할 수 없었습니다.

'사용자를 기억하는 메모'와는 달랐다

AI용 메모리 시스템을 조사해 보면, 대부분 user_id나 session_id를 중심으로 설계되어 있습니다.

예를 들어, 다음과 같은 정보를 저장합니다.

• 이 사용자는 아침 회의를 선호한다
• 이 사용자는 특정 음식을 좋아한다
• 지난번 문의 내용은 무엇이었는지
• 이 채팅 세션에서 무슨 이야기가 오갔는지

이것은 여러 이용자에게 AI 서비스를 제공할 때 필요한 메모리입니다.

반면, 제가 필요했던 것은 이용자를 분리하기 위한 메모리가 아니었습니다. 이용자는 저 혼자입니다. 대신, 여러 개의 AI가 각기 다른 담당을 가지고 있습니다.

한 명의 인간
├── 기술 지원을 담당하는 AI
├── 사업이나 경영을 담당하는 AI
...

필요했던 것은 각각의 AI가 자신의 담당, 판단, 작업 이력을 지속적으로 가질 수 있는 시스템이었습니다.

말하자면,

사용자를 기억하는 AI 메모가 아니라, 업무를 인계할 수 있는 AI 팀의 기억 기반입니다.

일시적인 서브 에이전트와도 다르다

'멀티 에이전트(Multi-agent)'라는 단어는 여러 의미로 사용되고 있습니다.

Codex 등에서는 큰 태스크를 여러 개의 서브 태스크로 분해하고, 여러 에이전트가 병렬로 처리할 수 있습니다. 이 방식에서는 관리자가 그 자리에서 작업자를 편성하고, 태스크가 끝나면 팀도 해산합니다.

AMS가 목표하는 것은 그것과는 다른 멀티 에이전트입니다.

태스크 분해형
태스크 발생 → 일시적으로 작업자 편성 → 완료 → 해산
장기 페르소나형
...

AMS의 핵심은 후자에 가깝습니다.

기술 담당은 과거의 기술 판단을 기억합니다. 사업 담당은 이전의 시장 검토나 방침을 기억합니다. 학습 담당은 지난번까지의 진척도를 기억합니다.

AI를 일회성 답변 장치가 아니라, 담당을 가진 지속적인 팀으로 사용하기 위한 설계입니다.

AMS의 기본 구조

AMS는 FastAPI로 동작하며, 메모리는 SQLite에 저장합니다.

검색에는 FTS5와 sqlite-vec를 사용하여 전체 텍스트 검색과 벡터 검색 결과를 Reciprocal Rank Fusion으로 통합합니다.

기억은 크게 3가지 종류로 나누었습니다.

Semantic memory (의미론적 기억)

프로젝트의 상태, 확정된 사실, 설계 판단, 담당자 등 나중에 참조하고 싶은 지식입니다.

{
"key": "project_api_policy",
"value": "외부 API 실패 시 재시도를 최대 3회까지 수행한다",
...

Procedural memory (절차적 기억)

에이전트가 작업할 때 준수해야 하는 절차나 규칙입니다.

"코드를 변경하기 전에 기존 구조를 확인한다", "작업 종료 시 확정 사항을 저장한다"와 같이 행동에 관한 기억을 다룹니다.

Episodic memory (일화적 기억)

세션이나 사건의 기록입니다.

무엇을 수행했는지, 어디까지 진행되었는지, 어떤 문제가 발생했는지를 남깁니다. 다음 세션에서는 이를 사용하여 이전 작업의 이어서 작업을 재개합니다.

기억에는 소유자가 필요했다

여러 에이전트가 동일한 데이터베이스를 사용하면, 다른 담당자의 기억을 실수로 덮어쓸 가능성이 있습니다.

그래서 AMS에서는 semantic memory에 owner를 부여했습니다.

이미 소유자가 설정되어 있는 키를 다른 에이전트가 업데이트하려고 하면, HTTP 403으로 거부합니다.

engineer가 저장한 기억
↓
owner = engineer
...

이것은 고도의 RBAC (Role-Based Access Control, 역할 기반 액세스 제어)는 아닙니다. 개인이 운용하는 소규모 AI 팀을 위한 단순한 경계 침범 방지책입니다.

현재 REST/MCP를 통해 직접 저장한 기억과 수동으로 승인된 기억에는 owner gate가 작동합니다.

반면, 스케줄러의 자동 승인 경로를 통해 저장된 기억은 현재 owner=NULL 상태입니다. 이 경로에서는 owner gate가 작동하지 않습니다.

이는 알려진 제한 사항으로서 README와 Issue에 명시되어 있으며, 다음 버전에서 통일할 예정입니다.

AI의 자발성에만 의존하지 않는다

당초 설계는 "에이전트가 세션 시작 시 메모리 서버를 확인하러 간다"는 방식이었습니다.

하지만 에이전트가 확인하는 것을 잊거나, 그 시점에는 필요하지 않다고 판단하여 건너뛰는 경우가 있었습니다.

그래서 기억을 저장하고 검색하는 API뿐만 아니라, 각 에이전트의 문맥 (Context)을 생성하여 세션 시작 시 전달하는 메커니즘을 만들었습니다.

저의 운용 환경에서는 스케줄링 작업(Scheduled job)이 각 에이전트용 agent_context.md를 생성하여 Claude Projects로 전달합니다.

목표는 "AI가 알아서 잘 기억해 주는 것"이 아닙니다.

기억하는 타이밍과 회상하는 타이밍을 가능한 한 시스템 측에서 결정론적으로 만드는 것입니다.

오래된 기억을 어떻게 다룰 것인가

기억은 계속해서 늘어납니다.

오래된 판단이나 이미 완료된 태스크를 그대로 남겨두면 검색 결과의 노이즈가 됩니다. 게다가 오래된 전제가 현재도 유효한 정보로 참조될 가능성이 있습니다.

초기 AMS에는 semantic memory를 물리적으로 삭제하는 MCP 도구가 없었습니다. "진부화되었다"라는 표시를 본문에 쓰는 것만 가능할 뿐, 삭제할 수 없는 상태였습니다.

OSS (Open Source Software)로 공개할 준비를 하는 과정에서 이 문제를 인지하였고, delete_memory를 추가했습니다.

이와 함께 진부화를 나타내는 마커가 붙은 기억을 추출하여, 사람이 확인한 후 삭제하는 방식으로 운용하고 있습니다.

장기 기억에서는 저장 방법뿐만 아니라 정정, 삭제, 그리고 재고 조사 (Inventory)도 필요했습니다.

저장 전에 후보를 확인할 수 있다

AI에 의한 기억은 저장 누락뿐만 아니라 잘못된 기억의 혼입도 문제가 됩니다.

한 번 잘못된 전제가 저장되면, 이후의 세션에서도 반복해서 참조될 가능성이 있습니다. 장기 기억은 편리하지만 오류까지 장기화시킵니다.

AMS에는 직접 저장하는 save_memory와는 별개로, 후보로서 저장하는 save_candidate가 있습니다. 후보는 대기 큐 (Pending queue)에 들어가며, 승인하거나 거부할 수 있습니다.

현재는 카테고리에 기반한 자동 승인 경로도 있으며, Codex에서 제안된 후보는 수동 리뷰 대상이 됩니다.

모든 것을 자동으로 저장하는 것도, 모든 것을 사람이 수동으로 입력하는 것도 아닌, 정보원이나 용도에 따라 저장 경로를 나누고 있습니다.

왜 SQLite인가

AMS는 많은 사람이 이용하는 SaaS용 기반이 아닙니다.

한 명의 개인이 자신의 Mac이나 소규모 서버에서 자신의 AI 팀을 구동하는 것을 상정하고 있습니다.

따라서 외부의 Redis나 벡터 데이터베이스를 필수 사항으로 두지 않았습니다.

• 하나의 SQLite 파일로 소유할 수 있음
• 백업하기 쉬움
• 내용을 직접 확인할 수 있음
• 외부 서비스에 기억을 맡기지 않아도 됨
• 개인 운용에 필요한 규모에서는 충분히 기능함

스케일(Scale)보다는 소유할 수 있다는 점과 운용의 단순함을 우선시하고 있습니다.

MCP와 REST를 모두 준비했다

AMS는 REST API와 MCP를 모두 공개합니다.

REST API는 스케줄러(Scheduler)나 외부 연동 등, 결정적으로 구동하고 싶은 처리부터 이용합니다.

MCP는 Claude Desktop이나 Claude Code 등, MCP에 대응하는 클라이언트로부터 기억을 검색·저장하기 위해 사용합니다.

주요 MCP 도구(Tool)는 다음과 같습니다.

search_memory

get_memory

list_memories

get_context

save_memory

save_candidate

list_pending_candidates

delete_memory

inbox_add

기억을 특정 채팅 서비스 내부에 가두지 않고, 외부의 공통 레이어(Layer)로 다루기 위한 구성입니다.

Redis Agent Memory Server와 이름은 같지만 대상이 다르다

공개 준비를 진행하던 중, Redis에도 동일한 이름의 Agent Memory Server가 있다는 것을 알게 되었습니다.

Redis 버전은 사용자나 세션(Session)을 축으로, AI 애플리케이션에 메모리 기능을 제공하는 프로덕션(Production)용 기반입니다.

이 AMS는 에이전트의 페르소나(Persona)를 축으로, 한 명의 인간이 여러 전문 AI를 지속적으로 운용하기 위한 기반입니다.

Redis Agent Memory Server
다수의 이용자 × AI 애플리케이션
이 AMS
...

같은 "메모리 서버"라도 분리하는 단위와 해결하려는 문제가 다릅니다.

Redis 버전을 작게 다시 만든 것이나, 그것을 대체하려는 것도 아닙니다.

도입 방법

리포지토리(Repository)를 clone하고, Python 가상 환경을 생성합니다.

git clone https://github.com/kscscafe/agent-memory-server.git
cd agent-memory-server
python -m venv .venv
...

.env

에 최소한으로 필요한 값을 설정하고, REST API를 기동합니다.

uvicorn main:app --host 127.0.0.1 --port 8000

MCP 서버는 별도 프로세스로 기동합니다.

python mcp_server.py

상세한 환경 변수, 인증, Claude 등록 방법은 README를 참조해 주세요.

현재 위치

AMS는 저 자신의 AI 에이전트 운용에서 탄생한 소프트웨어입니다.

2026년 7월 23일에 첫 공개 버전인 v0.1.0을 릴리스했습니다.

현 시점에서 다음과 같은 기능이 있습니다.

• semantic／procedural／episodic memory
• 전문 검색(Full-text search)과 벡터 검색(Vector search)을 결합한 검색
• 에이전트 단위의 owner gate
• 기억 후보와 승인 플로우(Flow)
• 세션 시작 시의 컨텍스트(Context) 취득
• 기억의 삭제와 정리
• MCP／REST API
• LINE／Slack／Notion／Google Drive와의 임의 연동
• 스케줄러와 자동 실행 처리

한편으로, 누구나 바로 도입할 수 있는 완성품이 되었다고는 생각하지 않습니다.

현재는 제 환경에서 실제로 돌아가고 있는 것을 다른 사람이 읽고 시도해 볼 수 있는 형태로 정리한 단계입니다.

향후에는 셋업(Setup) 절차의 개선, 자동 승인 경로에서의 owner gate 통일, 실제 이용자로부터 얻은 문제의 수정을 진행할 예정입니다.

마치며

AI 에이전트를 늘린다고 해서 그대로 AI 팀이 되는 것은 아닙니다.

팀으로서 지속시키기 위해서는 적어도 다음과 같은 것들이 필요했습니다.

• 담당
• 기억
• 소유권
• 인수인계
• 인간에 의한 확인과 정정

AMS는 이것들을 하나의 작은 셀프 호스트(Self-hosted)형 서버로 모은 것입니다.

"혼자서 여러 AI를 지속적으로 운용하고 싶다", "매번 똑같은 설명을 하는 것에서 벗어나고 싶다"는 분들에게 설계나 코드가 어떤 참고가 되기를 바랍니다.

GitHub에서 공개하고 있습니다.

시도해 본 소감이나, 다른 멀티 에이전트(Multi-agent) 운용에서의 과제가 있다면 Issue로 알려주세요.

Discussion