Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 AI 에이전트의 자동 메모리 기능에 대한 한계를 지적하며, 인간과 여러 AI가 공통으로 참조할 수 있는 공유 지식 기반 'kaiba' 제작 과정을 다룹니다. kaiba는 단순한 기억 기능을 넘어, 정보의 의미와 권위를 인간이 관리하는 구조로 설계되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AI 에이전트의 메모리 기능에 대해서는 이전부터 약간의 이질감을 느꼈다.
편리하기는 하지만, 대부분의 경우 '무엇을 기억할지'를 AI 측에서 판단한다. 인간 입장에서는 중요하다고 생각하지 않는 것이 남거나, 반대로 나중에 참조하고 싶은 설계 결정이나 실측 결과가 남아있지 않은 경우가 있었다.
또 하나 불편했던 점은 내가 하나의 AI만 사용하지 않는다는 것이다. Claude Code, Codex, OpenCode를 거치는 worker, Antigravity 등 용도나 비용에 따라 여러 AI 에이전트를 번갈아 사용하고 있다.
Claude가 기억하는 것을 Codex는 모른다. 다른 worker도 모른다. 세션을 넘어가면 같은 AI라도 전제가 빠진다.
내가 원했던 것은, AI가 나 개인을 기억해주는 기능이 아니었다.
인간과 여러 AI가 동일한 사실을 보고 업무를 계속할 수 있는 장소.
이것을 만들고 싶었다.
그래서 만든 것이 MCP를 통해 여러 에이전트로부터 참조 가능한 공유 지식 기반 kaiba(海馬) 이다.
만들기 시작했을 때는 '공유 메모리' 하나면 충분하다고 생각했다.
실제로 사용해보니, 그렇지 않았다.
'기억'이라는 하나의 단어 안에 의미도, 수명도, 권위도 다른 정보들이 너무 많이 뒤섞여 있기 때문이다.
본고에서는 단순한 remember / recall에서 시작했던 kaiba가 왜 conclusion / agenda / progress / inbox 네 가지로 나뉘게 되었는지, 그리고 추가적으로 Skill이나 개발 워크플로우와 역할 분담을 하게 되었는지를 실제 운영 과정에서 발생한 문제들과 함께 정리한다.
인간 팀에서는 모든 정보를 '기억'이라는 같은 상자에 넣지 않는다.
예를 들어, 아래 항목들은 모두 업무에 필요한 정보이지만 의미가 상당히 다르다.
그런데 AI의 memory라는 단위로 생각하면, 이것들이 같은 장소에 들어가기 쉽다.
게다가 무엇을 저장할지 AI 자신이 판단하게 되면, 인간이 가지고 있는 '이것은 공식적인 지식', '이것은 아직 미검증', '이것은 임시 메모'와 같은 구분과도 어긋난다.
업무의 지식으로 원했던 것은, AI가 멋대로 키우는 개인 메모리가 아니었다.
인간 측에서 정보의 의미와 권위를 관리할 수 있는 공유 지식이었다.
이것은 단순히 '메모리를 편집할 수 있는 UI가 갖고 싶다'는 문제가 아니다.
무엇을 공식적인 공통 지식으로 할 것인지, 그 경계 자체를 인간이 가지고 싶다는 이야기이다.
단일 AI만 사용할 경우, 해당 AI 고유의 memory로는 어느 정도 기능한다.
하지만 여러 AI를 사용하기 시작하면 구조적으로 문제가 생긴다.
인간
├─ Claude가 아는 것
├─ Codex가 아는 것
...
이 상태에서는 AI를 전환할 때마다 인계가 발생한다.
더 골치 아픈 것은, 같은 프로젝트를 여러 AI로 지속적으로 다룰 경우이다.
어떤 AI가 실패하여 얻은 지견을 다른 AI가 다음 날 다시 밟는다. 똑같은 조사를 반복한다. 과거에 채택하지 않았던 설계안을 다른 AI가 또 제안한다.
인간 팀으로 치면, 멤버 전원이 자신만의 노트만 가지고 있는 상태와 가깝다.
원했던 구성은 그 반대였다.
지식은 AI 안에 가두지 않고 외부에 둔다.
각 AI는 필요할 때 거기서 읽는다.
그리고 인간도 같은 내용을 UI로 확인한다.
이 형태라면, 'Claude는 알고 있지만 Codex는 모른다'라는 상태 자체를 줄일 수 있다.
AI를 교체해도 공유 지식은 남는다.
remember
과 recall만 있었다
3. 처음에는 kaiba가 매우 단순했다.
remember(content)
— 결론을 기록한다 -
recall(query)
— 태스크 설명 등에서 의미 검색한다
처음에는 Honcho를 저장소로 사용하고, 그 위에 최소한의 MCP 인터페이스만 만들었다. Honcho 자체에 풍부한 기능이 있지만, kaiba에서 공개한 것은 거의 이 두 가지뿐이었다.
이유는 AI에게 다기능적인 '기억 관리'를 시키고 싶었던 것이 아니라, 검수 완료된 결론을 작성하고 다른 에이전트가 나중에 가져갈 수 있게 하고 싶었기 때문이다.
그 후 저장소는 SQLite로 옮겼다. 현재는 임베딩에 bge-m3을 사용하며, 검색은 이 규모에서는 전건 비교를 한다.
문서의 생성, 요약, 재해석에는 LLM을 사용하지 않는다.
이것 역시 의도적이다.
업무에 필요한 결론은 '대체로 같은 의미의 요약'이 아니다.
누군가 검수(検収)한 문서를 그대로 나중에 꺼내 쓰고 싶다.
LLM에게 한 번 요약하게 만들면, 그 문서는 '검수한 사람이 작성한 것'에서 '아무도 검수하지 않은 LLM의 의역'으로 변해버린다.
임베딩(embedding)은 검색을 위해 사용하지만, 저장된 내용 자체에는 관여하지 않는다. 이 경계는 지금도 유지하고 있다.
가장 큰 초기 실패는 kaiba에 너무 많은 것을 쓰게 한 것이었다.
운영 초기에는 다음과 같은 것들까지 공유 메모리에 들어갔다.
언뜻 보기에는 모두 유용해 보인다.
하지만 나중에 되돌아보면, 46건 중 '지속적인 결론'으로 정말 남기고 싶었던 것은 단 4건에 불과했다.
여기서 문제의 본질이 드러났다.
검색 정밀도(検索精度)가 아니다.
입력되는 정보의 의미 자체가 뒤섞여 있다는 것이 문제였다.
검색 모델을 아무리 똑똑하게 만들어도, 잡다한 정보를 똑똑하게 검색할 수 있게 할 뿐이다.
그래서 정보의 의미와 라이프사이클(life cycle)별로 상자를 나누기로 했다.
현재 kaiba에는 네 종류의 상자가 있다.
| 상자 | 의미 | 읽는 법 | 수명 |
|---|---|---|---|
| conclusion | 검수된 지속적인 사실/실측 | 의미 검색 | 장기 |
| ... | |||
| 처음에는 모두 'memory'처럼 보였다. |
하지만 운영하다 보니, 이 4가지는 완전히 다른 것이었다.
예를 들어,
와 같은, 나중 작업에서도 재활용할 수 있는 사실들이다.
이것은 의미 검색으로 가져온다.
중요한 것은, 작업 완료 보고 자체는 넣지 않는다는 것이다.
'PR을 병합했다(マージした)'는 GitHub가 정본이며, kaiba에 복제할 필요는 없다.
남겨야 할 것은 그 작업으로부터 얻은 재활용 가능한 지식이다.
agenda는 과거의 기억이 아니라, 공유된 다음 액션(next action)이다.
'조사해 보는 게 좋을 것 같다'는 후보가 아니라, '다음에는 이것을 하겠다'고 선택한 것을 넣는다.
순서에도 의미가 있기 때문에, 의미 검색이 아닌 목록으로 취급한다.
progress는 작업 중인 상태이다.
구현 중인 상황, 리뷰 경과, 도중의 조사 결과 등, 일시적으로는 유용하지만 미래의 사실로 다루고 싶지 않은 것들을 넣는다.
이것은 권위가 없다.
기본적으로 TTL(Time To Live)을 가지며, 오래되면 삭제된다. 또한, kusabi의 job이 종료하면, 그 job에 연결된 progress만 즉시 삭제할 수 있도록 했다.
인간도 작업 중인 화이트보드를 영구 보관하지 않는다.
같은 생각이다.
가장 최근에 추가된 것이 inbox이다.
계기는 직접 만든 개발 워크플로우 kusabi가 chain 종료 통지(chain終了通知)를 kaiba의 agenda에 작성하고 있었기 때문이다.
처음에는 편리해 보였다.
하지만 chain을 많이 돌리다 보니, agenda가 기계 생성된 완료 통지로 채워지기 시작했다.
그래서 깨달았다.
'무언가가 일어났다(何かが起きた)'와 '다음에는 이것을 하겠다(次にこれをやると決めた)'는 별개라는 것을.
Inbox = observed fact / incoming signal
Agenda = chosen next action
외부 시스템은 inbox에 통지한다.
인간이나 오케스트레이터가 내용을 확인하고, 필요하다면 agenda로 승격시킨다.
이를 통해, 기계가 단순히 이벤트를 통지했을 뿐인데도 인간의 작업 우선순위까지 결정된 상태를 피할 수 있게 되었다.
다음으로 문제가 된 것은 누가 쓸 수 있느냐였다.
서브 에이전트가 작업 중에 무언가를 발견했다고 가정하자.
그 worker 자신이 '이것은 미래에도 올바른 사실이다'라고 판단하여 kaiba에 직접 쓰면, 검수 전의 내용이 공식적인 공유 지식이 되어버린다.
그래서 현재는, worker에게 원칙적으로 recall만 부여하고 있다.
작업 중에 발견한 지속적인 사실은 최종 보고서의 Durable facts에 넣는다.
그것을 kaiba에 기록할지 여부는 검수하는 측인 오케스트레이터가 판단한다.
여기서 중요한 것은, 프롬프트로 '임의로 쓰지 말라'고 요청하는 것만으로는 부족하다.
쓰기 도구 자체를 worker에게 넘겨주지 않는 것이다.
이것은 sunaba에서도 여러 번 경험했지만, AI 에이전트의 중요한 제약 조건을 프롬프트에만 두면 긴 작업 과정 중 어딘가에서 빠져나간다.
지키게 하고 싶은 경계는 Capability 자체를 넘겨주지 않는 것이 더 강력하다.
kaiba에서도 같은 생각이었다.
또 하나 알게 된 점이 있다.
지식 기반(Knowledge Base)을 만들었다고 해서 에이전트가 반드시 기억해주지는 않는다.
그래서, 구현 worker의 작업 규칙 쪽에 다음 문장을 추가했다.
착수 시점에 한 번, 태스크 설명에서 kaiba recall을 호출한다.
즉, worker는 구현을 시작하기 전에 해당 태스크와 관련된 과거 지식을 한 번 검색한다.
태스크 수령
↓
태스크 내용으로 kaiba recall
...
이것은 작은 규칙이지만, 상당히 중요하다고 생각한다.
기억의 저장 방법뿐만 아니라, 회상(Recall)의 타이밍도 설계해야 공유 메모리가 사용된다.
인간 조직에서도 과거 장애 사례가 Wiki에 존재하는 것만으로는 재발 방지가 되지 않는다.
작업 전에 읽는 시스템이나, 문제가 생겼을 때 과거 사례를 찾는 습관이 필요하다.
AI 에이전트도 마찬가지였다.
여기까지 만들다 보면, '과거 주의사항이라면 Skill에 전부 적으면 되지 않을까'라고 생각할 수 있다.
실제로 경계는 가깝다.
나에게서는 다음과 같이 구분하고 있다.
kaiba는 '무엇을 알고 있는가'
Skill은 '어떻게 행동해야 하는가'
예를 들어, 어떤 작업에서 다음 사실을 알게 되었다고 가정하자.
관련 테스트만 거쳐 publish했더니, 다른 영역의 회귀(regression)를 놓쳤다.
이것은 우선, 과거에 관찰된 사실로서 kaiba에 남길 수 있다.
하지만 같은 종류의 실패가 반복되어 충분히 일반화되었다는 결과로,
publish 전에는 반드시 full test를 거치게 되었다면, 이것은 더 이상 과거 지식이 아니다.
앞으로의 행동을 제한하는 작업 규칙이므로, Skill 쪽으로 승격시킨다.
인간 조직에서도 한 번 사고가 날 때마다 절차서에 규칙을 추가하면, 결국 아무도 읽지 않는 거대한 절차서가 생긴다.
우선 사례로 남긴다.
반복적으로 사용되어 정말 일반화될 수 있는 지식만 표준 작업으로 승격시킨다.
AI 에이전트도 같은 구조를 만드는 것이 더 자연스러웠다.
또 다른 차이는 정보 전달 방식이다.
Skill은 작업 시작 때부터 읽게 하는 push형의 정보이다.
모르는 상태로 작업을 시작하는 것 자체가 위험한 규칙은 여기에 둔다.
반면, kaiba는 태스크 내용에서 필요한 과거 지식만 끌어오는 pull형이다.
모든 과거 지식을 매번 컨텍스트에 넣으면 토큰도 주의력(attention)도 소모한다.
그래서 현재는 대체로 다음과 같이 나누고 있다.
| 종류 | 배치 장소 |
|---|---|
| 반드시 지켜야 할 작업 규칙 | Skill |
| ... | |
| 이 분리를 통해 '무엇이든 Skill', '무엇이든 memory'가 되는 것을 피하고 있다. |
RAG나 벡터 검색 이야기에서는, 방대한 정보를 어떻게 고속으로 검색할지가 화제가 되기 쉽다.
kaiba에서는 현재 반대 방향을 중시하고 있다.
실제 운영에서는, 저장 건수가 175건 정도여도 top-5로 반환된 내용을 인간이나 AI가 읽는 주의력이 먼저 병목(bottleneck)이 되었다.
그래서 pgvector나 ANN을 도입해서 거대한 스토어를 목표로 하기보다, 불필요한 지식을 은퇴시키고 단명하는 정보 자체를 장기 저장하지 않는 쪽을 선택하고 있다.
conclusion에는 retired_at을 두어, 필요 없어진 지식은 이유와 함께 명시적으로 은퇴시킨다.
progress는 반대로 권위가 없으므로 TTL로 삭제한다.
같은 '잊는다'라도 정보의 의미에 따라 방법을 다르게 하고 있다.
인간 사내 Wiki도 페이지 수가 많다고 유용하지 않다.
AI를 위한 지식도 마찬가지라고 생각한다.
kaiba에는 읽기 전용의 Dashboard도 있다.
이것은 단순한 관리 화면이 아니라, 설계상 상당히 중요하다고 생각한다.
AI 내부의 메모리만으로는, 인간 입장에서 '현재의 공유 지식이 무엇인지' 알 수 없다.
공유 스토어를 UI로 볼 수 있게 하면,
를 인간도 확인할 수 있다.
즉, AI들끼리의 공유 메모리가 아니라, 인간과 AI가 공통 인식을 확인하는 장소가 된다.
'AI가 무엇을 기억하고 있는지 알 수 없다'는 상태를 피한다는 의미에서도 UI는 중요했다.
kaiba는 기능을 늘릴수록 좋은 종류의 시스템이 아니라고 생각한다.
현재 기본 구성은 상당히 단순하다.
KAIBA_AGENT으로 기록 - readonly worker에는 쓰기 도구를 등록하지 않음또한, 외부 producer를 위해서는 읽기 전용 모드인 채로 inbox_append만 예외적으로 공개할 수 있도록 했다.
kusabi 같은 외부 시스템이 알림을 작성하기 위해 remember나 agenda_edit까지 전달할 필요는 없다.
여기서도 '필요한 Capability만 전달한다'라는 방침을 관철하고 있다.
확장시키기 위한 메커니즘을 늘리기보다, 의미의 경계를 무너뜨리지 않는 것을 우선시했다.
kaiba를 만들기 시작했을 때는 '복수 AI의 공유 메모리'라고 생각했었다.
지금은 조금 다르다.
인간 조직에서도 과거의 실패를 지식으로 남긴다.
필요하면 재발 방지 규칙으로 승격시킨다.
작업 중의 메모는 버린다.
알림과 TODO는 분리한다.
그리고 팀 멤버가 교체되어도, 조직으로서 지식을 계승할 수 있도록 한다.
kaiba, Skill, kusabi, shiori를 조합하여 하고 있는 것도 상당히 이에 가깝다.
| 인간의 조직 | AI를 포함한 현재 시스템 |
|---|---|
| 과거 사례・장애 지식 | kaiba conclusion |
| ... | |
| 즉, AI에게 인간 같은 기억을 심어주고 싶었던 것은 아니다. |
인간과 복수의 AI가, 동일한 경험으로부터 배우고 동일한 사실을 참조하여 업무를 지속할 수 있는 시스템
을 만들고 싶었다.
그 의미에서 kaiba는 AI memory라기보다, AI를 포함한 팀의 조직 기억에 가깝다.
AI 에이전트의 메모리를 생각하기 시작했을 때, 저장 방식이나 벡터 검색이 중심이 될 것이라고 생각했다.
실제로 사용해 보니, 어려웠던 것은 다른 부분이었다.
즉, AI의 메모리는 단순한 스토리지 문제가 아니라, 팀의 지식을 어떻게 운영할 것인지라는 문제였다.
그리고 복수의 AI를 사용할수록, 특정 AI 내부의 기억에 담기게 하는 것보다 외부 공용 지식을 두는 가치가 커진다.
앞으로도 실제 개발에서 사용하면서, '어떤 지식을 남기고, 어떤 지식을 잊고, 어떤 지식을 규칙으로 승격시켜야 할지'를 다듬어 나갈 예정이다.
