AI 메모리 레이어 세 번의 릴리스. 최고의 버그는 다른 사람들에 의해 발견되었습니다.

저는 다중 에이전트 시스템을 위한 오픈 소스 공유 메모리 레이어인 Agent Brain Hub를 구축하고 있습니다.

여행 상담원, 수리 상담원, 금융 상담원 등이 모두 같은 사용자에게 이야기한다고 상상해 보세요. 각 에이전트는 민감한 데이터(건강 기록이나 소득 등)가 서로 유출되지 않으면서도 다른 에이전트들이 무엇을 배웠는지 알아야 합니다. 이 아키텍처는 인지 심리학에서 느슨하게 차용되었습니다: 세션별 단기 작업 기억, 사실 및 에피소드를 위한 장기 저장소, 그리고 하나를 다른 것으로 통합하는 비동기 '수면 주기'가 있습니다.

지난 며칠 동안 저는 세 번의 릴리스를 진행했습니다. 무엇이 고장 났는지, 벤치마크는 어떤 결과를 보여줬는지, 그리고 왜 최고의 엣지 케이스들이 제 테스트 스위트에서 나온 것이 아닌지 알려드리겠습니다. 그것들은 제 게시물을 읽은 사람들에게서 나왔습니다.

v0.5: 특정 시점의 정확성 (시간 여행 메모리)

v0.5 이전에는 대체되거나 만료된 사실이 다음 수면 주기에서 삭제되었습니다. 이제 사실은 유효성 간격으로 무효화됩니다: '사이공으로 이사했습니다'는 타임스탬프와 상위 기록에 대한 포인터를 사용하여 '하노이에 거주합니다'를 닫습니다.

어떤 시점의 브레인 상태든 조회할 수 있습니다:

await brain.recall({
  customerId,
  text: '집에서 택시를 예약해 줘',
...

다중 에이전트 루프를 디버깅할 때, 이것은 정확히 답해야 할 질문입니다: '여행 상담원이 실제로 그 전화를 걸었을 때 무엇이라고 믿었는가?'

벤치마크가 포착한 버그: 시간적 질의(temporal queries)를 추가하면서 릴리스 전에 개인 정보 유출이 발생했습니다. 과거 상태를 조회하는 것이 최근 대화 턴에 대한 개인 정보 필터를 건너뛰어, 한 에이전트의 사적인 대화가 다른 에이전트에게 도달할 수 있었습니다. 새로운 시간적 벤치마크 시나리오가 이것이 배포되기 전에 포착했습니다.

v0.6: 개체 그래프와 정직한 벤치마크

사실들은 이제 고객별 엔티티로 그룹화됩니다('내 차' = 'xe' = '車' = 'Honda Civic'), 그리고 검색은 그들 사이의 링크를 따릅니다:

Mia (개인 에이전트): "제 차는 혼다 시빅입니다"
Kai (수리점 에이전트): "차에 문제가 생겨서 3일 동안 수리점에 있을 겁니다"

...

Penny의 질문에는 '차'나 '수리점'이라는 단어가 언급되지 않았다는 점에 주목하세요. 그래프는 '시빅(Civic)'을 차와 연결하고, 그 차를 수리와 연결합니다. 탐색은 요청하는 에이전트가 이미 볼 수 있도록 허용된 메모리 위에서만 실행되므로, 사적인 사실을 도메인 간에 전달할 수 없습니다 (예: 의료 알레르기가 예약 에이전트에게 전송되지 않습니다).

그래프가 실제로 가치가 있는지 확인하기 위해 --no-graph 옵션으로 벤치마크를 실행했습니다:

현재로서는 그래프가 다음 부분에서 가치를 발휘합니다:

1. 임베딩 모델이 없는 제로-설정(Zero-config) 오프라인 모드.
2. 설명 가능성(Explainability): 어떤 사실이 왜 끌어와졌는지에 대한 결정론적 추적 기록.

현재의 시나리오는 밀집 임베딩(dense embeddings)에 비해 그 이상을 보여주기에는 충분히 어렵지 않습니다. 더 어렵고 적대적인(adversarial) 시나리오들은 현재 백로그에 있습니다.

제가 완전히 놓친 엣지 케이스들

이전에 daily.dev에서 개발 로그를 게시하고 레포지토리를 기여(contribution) 받도록 열었습니다. 독자들로부터 세 가지 실제 통찰력이 나왔습니다.

1. 기여자 영역 침범하기

한 기여자가 오픈 이슈를 주장했고 PR을 올렸습니다. 몇 시간 후, 그 사실을 알지 못한 채 저 스스로 같은 문제에 대한 수정 사항(fix)을 배포했습니다.

그들의 PR은 제가 놓친 경우를 포착했습니다: 베트남어에서 "không thích … nữa"("더 이상 … 싫다")는 이전 선호도에 대한 업데이트가 아니라 여전히 충돌로 처리되었습니다. 저는 그들의 PR을 main 브랜치 위에 리베이스(rebase)하고, 저자권을 유지했으며, 작은 후속 조치를 추가하여 병합(merge)한 뒤 v0.6.1 태그를 달았습니다. 이는 프로젝트의 첫 외부 기여였습니다.

핵심 시사점: 만약 여러분의 저장소(repo)가 공개적이라면, IDE를 열기 전에 할당된 이슈와 오픈 PR을 확인하세요.

2. "보장이라기보다는 여유 공간" (경쟁 조건, race condition)

작업 기억(working memory)은 마지막 40턴(turns)을 유지합니다. 일단 24개의 응축되지 않은 턴이 쌓이면, 스케줄러가 응축 '수면 주기(sleep cycle)'를 트리거합니다.

댓글 작성자 Ahmet Özel는 24개에서 40개 사이의 16턴은 "보장이라기보다는 여유 공간"이라고 지적했습니다. 느린 요약기나 대기열 백로그가 여전히 턴이 끝으로 떨어지게 할 수 있기 때문입니다.

그의 제안에 따라, 저는 의도적으로 느린 요약기를 사용한 버스트 테스트(burst test)를 작성했습니다. 결과: 26개 턴 중 10개가 조용히 사라졌습니다. 요약 호출 동안 도착하는 턴들은 현재 배치(batch)의 일부가 아니었고, 응축 후 버퍼 자르기(buffer trim) 과정에서 어쨌든 사라졌습니다.

v0.6.2에서 수정됨:

• 턴은 저장된 에피소드 내에 있을 때만 제거됩니다(evicted).
• 40턴 제한에 도달하는 것이 턴을 제거하기보다 즉시 응축을 트리거합니다.
• 버스트 테스트가 이제 회귀 테스트 스위트(regression suite)의 일부입니다.

3. "스크린샷은 어떻게 되나요?"

다른 독자가 응축이 스크린샷을 포함하는 턴을 어떻게 처리하는지 물었습니다.

솔직한 답변: 그렇지 않습니다. 허브는 텍스트 전용(text-only)입니다. 그리고 요약하기 위해 이미지들을 원격 멀티모달 모델에 보내는 것은 개인 정보를 노출하고 API 비용을 크게 발생시킬 것입니다. 그들의 제안, 즉 응축 루프 전에 로컬 OCR 처리를 하는 것은 현재 issue #25에서 추적되고 있습니다.

핵심 시사점

합성 벤치마크(Synthetic benchmarks)는 코드를 작성할 때 예상했던 엣지 케이스(edge cases)를 포착합니다. 독자들은 당연하게 여겼던 가정을 발견합니다. 하지만 프로젝트가 좋아 보이게 만드는 숫자들만 공유한다면 어느 쪽도 도움이 되지 않습니다.

v0.7의 다음 계획

• Open-스키마 추출(Open-schema extraction): 19개의 하드코딩된 관계 유형을 넘어설 것입니다.
• 에이전트 간 충돌 해결(Conflict resolution between agents): 에이전트 A와 에이전트 B가 동일한 개체에 대해 상반되는 사실을 주장할 때의 규칙입니다.

다중 에이전트 스택(multi-agent stacks)을 운영하는 분들께 질문드립니다:
두 개의 독립적인 에이전트가 동일한 개체에 대해 모순되는 사실을 작성했을 때 어떻게 충돌을 해결하시나요? 마지막 기록이 승리(Last write wins)? 신뢰도 점수(Confidence scores)? CRDTs? 인간에게 에스컬레이션(Escalating to a human)? 여러분이 어떻게 처리하는지 듣고 싶습니다.

Agent Brain Hub는 MIT 라이선스를 따르며, 텔레메트리(telemetry)가 없고, docker compose up 또는 모든 LLM 제공업체(OpenAI 호환, Anthropic, Gemini, Ollama 등)와 함께 완전히 로컬에서 실행됩니다: github.com/leluong141996-dev/Agent-Brain-Hub.