AI 에이전트는 질문에 답하고, 도구를 사용하며, 작업을 자동화할 수 있습니다. 하지만 세션 전반에 걸쳐 컨텍스트를 유지하고 결정이 변경될 때 일관성을 유지하는 에이전트를 구축하는 것은 또 다른 도전 과제를 제시합니다.
FalkorDB Graph Hacks 2026에서 저는 AgentMesh를 만들었습니다. 이는 AI 에이전트가 프로젝트 지식을 유지하고, 이전 결정을 검색하며, 모순을 식별하도록 돕기 위해 설계된 그래프 기반의 영구 메모리 및 조정 계층입니다.
핵심 아이디어는 간단합니다. 프로젝트 지식을 고립된 텍스트로 취급하는 대신, 기억(memories), 관계(relationships), 에이전트(agents), 결정(decisions)으로 구성된 연결된 그래프로 표현하는 것입니다.
문제점: AI 에이전트는 대화 기록 이상의 것이 필요하다
소프트웨어 프로젝트에서 AI 비서와 작업한다고 상상해 보세요.
월요일에, 당신은 Flutter를 사용하여 모바일 애플리케이션을 구축하기로 결정합니다. 또한 API 속도 제한(rate limit)을 설정하고 베타 테스트 날짜를 선택합니다.
화요일에, 새로운 세션을 시작하여 비서에게 그 결정들에 대해 질문합니다. 관련 컨텍스트가 사용 불가능하다면, 모든 것을 다시 설명해야 할 수도 있습니다.
요구사항이 변경될 때 문제는 더욱 복잡해집니다. 만약 Flutter를 네이티브 iOS 및 Android 개발로 대체한다면, 시스템은 두 가지 모두를 동시에 유효하게 취급하기보다는 새로운 결정이 이전 결정과 충돌한다는 것을 인식해야 합니다.
이는 세 가지 질문을 촉발했습니다:
- 에이전트는 이전 세션에서 관련 정보를 어떻게 검색할 수 있을까요?
- 저장된 결정들 사이의 관계를 어떻게 이해할 수 있을까요?
- 역사적 컨텍스트를 잃지 않으면서 충돌하는 정보를 어떻게 감지할 수 있을까요?
AgentMesh는 그래프 기반 메모리를 통해 이러한 질문들을 탐구합니다.
AgentMesh 소개
AgentMesh는 다중 에이전트 AI 시스템을 위한 영구 메모리 계층입니다.
이는 세 가지 전문화된 에이전트를 사용합니다:
Researcher: 사용자 상호작용에서 중요한 정보를 추출하여 구조화된 메모리로 저장합니다.
Planner: 관련 메모리를 검색하고 이를 사용하여 근거가 되는 문맥과 함께 질문에 답합니다.
Reviewer: 기존 정보와 새로운 결정 간의 모순을 식별하여 사용자가 이를 해결하도록 돕습니다.
각 에이전트는 고유한 책임을 가지며, 그래프 데이터베이스는 프로젝트 지식의 공유된 표현을 제공합니다.
목표는 모든 책임을 하나의 범용 에이전트 안에 넣기보다 메모리 관리, 검색, 그리고 충돌 검토를 분리하는 것입니다.
FalkorDB를 사용하는 이유?
AgentMesh의 핵심 기술은 FalkorDB입니다.
전통적인 대화 기록은 주로 순차적입니다. 하지만 프로젝트 지식은 메시지의 단순한 순서로만 이루어지는 경우는 거의 없습니다. 하나의 결정은 특정 작업과 관련되거나, 다른 결정에 영향을 미치거나, 세션에 속하거나, 또는 더 새로운 요구사항과 충돌할 수 있습니다.
그래프는 이러한 연결을 표현하는 자연스러운 방법을 제공합니다.
AgentMesh에서 데이터 모델은 다음과 같은 엔티티를 표현할 수 있습니다:
메모리(Memories)
에이전트(Agents)
세션(Sessions)
작업(Tasks)
충돌(Conflicts)
관계(Relationships)는 이러한 엔티티들을 연결하고, 정보가 어떻게 생성되고, 관련되며, 지원되거나, 모순되는지를 포착합니다.
예를 들어, Flutter에 대한 저장된 결정은 그것이 생성된 프로젝트 세션과 연결될 수 있습니다. 만약 나중에 Swift와 Kotlin을 도입하는 결정이 내려지면, 시스템은 새로운 정보를 이전 결정과 연관시키고 충돌 여부를 표시할 수 있습니다.
이는 관계가 단순히 키워드 매칭에 의존하기보다 메모리 모델의 일부가 되게 합니다.
구조(Architecture) 작동 방식
워크플로우는 네 가지 주요 단계를 따릅니다.
1. 추출 및 저장(Extract and Store)
사용자가 프로젝트 정보를 제공합니다. Researcher는 유용한 사실과 결정을 식별하고, 이를 FalkorDB에 그래프 데이터로 저장합니다.
예를 들어, 사용자는 모바일 기술, API 속도 제한, 계획된 베타 날짜 등을 지정할 수 있습니다. 이러한 사실들은 검색 가능한 메모리가 됩니다.
2. 관련 문맥 검색(Retrieve Relevant Context)
사용자가 나중에 상호작용에서 질문을 합니다.
Planner는 그래프에서 관련 메모리를 검색하여 이를 사용하여 답변을 구성합니다. 목표는 사용자가 이전의 모든 결정을 반복할 필요 없이 유용한 프로젝트 컨텍스트를 제공하는 것입니다.
3. 모순 감지(Detect Contradictions)
사용자가 모바일 애플리케이션 전략을 Flutter에서 Swift와 Kotlin을 사용한 네이티브 개발로 변경한다고 가정해 봅시다.
Reviewer는 새로운 정보를 관련 기존 메모리와 비교합니다. 만약 두 결정이 충돌한다면, AgentMesh는 이 모순을 검토를 위해 제시할 수 있습니다.
4. 기록 보존(Preserve the History)
결정을 변경한다고 해서 이전 결정이 존재했다는 사실 자체가 지워져야 하는 것은 아닙니다.
역사적 기록을 보존하는 것은 프로젝트가 어떻게 발전해 왔는지에 대한 유용한 컨텍스트를 제공합니다. 또한 이는 이전 결정과 현재 방향을 구별하는 데 도움을 줍니다.
이는 중요한 설계 원칙입니다: 지식의 변화는 조용히 파괴되는 것이 아니라 추적 가능해야 합니다.
AgentMesh 시연(Demonstrating AgentMesh)
시연은 간단한 프로젝트 워크플로우를 따릅니다.
먼저, 사용자는 여러 아키텍처 결정을 제공합니다. AgentMesh는 이 정보를 추출하고 저장합니다.
다음으로, 사용자는 시스템에 이전 기술 결정들을 요약해 달라고 요청합니다. Planner가 관련 컨텍스트를 검색합니다.
그 후, 사용자가 모바일 개발 전략을 변경합니다. Reviewer가 이전 결정과 새로운 결정 사이의 모순을 식별합니다.
마지막으로, 사용자는 새 세션을 시작하고 이전에 확립된 API 속도 제한에 대해 질문합니다. AgentMesh는 영구 메모리에서 저장된 값을 검색합니다.
이 순서는 프로젝트 지식의 의도된 수명 주기: 생성(creation), 검색(retrieval), 수정(revision), 그리고 회상(recall)을 시연합니다.
기술적 과제 및 설계 결정(Technical Challenges and Design Decisions)
그래프 기반 메모리 시스템을 구축하는 것은 데이터베이스에 텍스트를 저장하는 것 이상의 것을 포함합니다.
정보를 의미 있게 표현하기: 유용한 검색을 지원하려면 메모리에는 충분한 구조와 관계가 필요합니다. 잘못 모델링된 데이터는 그래프 데이터베이스조차도 효과적으로 쿼리하기 어렵게 만들 수 있습니다.
적절한 컨텍스트 검색: 저장된 모든 메모리를 검색하는 것은 비효율적이며 관련 없는 정보를 도입할 수 있습니다. 시스템은 사용자의 현재 질문과 관련된 메모리를 식별해야 합니다.
상충되는 결정 처리: 새로운 진술이 항상 이전의 진술을 대체하는 것은 아닙니다. 그것은 모순될 수도, 정제될 수도, 또는 다른 상황에서 적용될 수도 있습니다. 이러한 구분을 하는 것이 일관성을 유지하는 데 중요합니다.
추적 가능성 유지: 사용자가 근거를 확인할 수 있을 때 답변이 더 유용합니다. 검색된 정보를 출처와 연결하는 것은 설명 가능한 검색(explainable retrieval)의 기반을 제공합니다.
이러한 과제들은 AgentMesh의 설계에 영향을 미쳤으며, 메모리를 구조화되고 진화하는 프로젝트 지식으로 다루는 것의 중요성을 강조했습니다.
배운 점
AgentMesh 작업을 통해 여러 교훈을 얻었습니다.
첫째, 메모리는 단순한 저장소가 아닙니다. 시스템은 방대한 양의 정보를 보유하고 있어도 올바른 사실을 검색하는 데 실패할 수 있습니다. 관계와 검색 전략이 중요합니다.
둘째, 그래프 모델링은 문제에 따라야 합니다. 그래프를 사용하는 목적은 단순히 노드와 엣지를 저장하는 것이 아닙니다. 모델은 애플리케이션의 실제 문제를 해결하는 데 도움이 되는 관계를 나타내야 합니다.
셋째, 변경되는 정보는 신중한 처리가 필요합니다. 요구사항이 진화할 때, 역사적 결정과 현재 결정을 구분하여 보존하는 것이 필수적입니다.
마지막으로, 다중 에이전트 아키텍처는 명확한 책임이 필요합니다. 추출(extraction), 계획(planning), 검토(review)를 분리하는 것은 모든 작업을 동일한 작업으로 취급하는 것보다 더 이해하기 쉬운 설계를 만듭니다.
FalkorDB는 연결된 데이터를 기반으로 영구적인 에이전트 메모리를 위한 아이디어를 탐색할 수 있는 방법을 제공했습니다.
향후 계획
AgentMesh를 개선할 여지가 많습니다.
잠재적인 다음 단계로는 더욱 정교한 검색 전략, 강화된 충돌 분류, 풍부해진 메모리 출처(provenance), 그리고 검색 정확도와 충돌 감지 품질을 측정하는 평가가 포함될 수 있습니다.
또한 아키텍처가 그래프를 확장함에 따라 어떻게 동작하는지, 그리고 더 많은 에이전트들이 장기적으로 진행되는 프로젝트에서 이를 어떻게 지원할 수 있는지 탐구하고 싶습니다.
이러한 개선 사항들은 이 접근 방식이 통제된 데모 시연을 넘어 계속 유용성을 유지하는지 확립하는 데 도움이 될 것입니다.
결론
AgentMesh는 에이전트형 AI(agentic AI)의 실질적인 과제를 탐구합니다: 프로젝트가 진화함에 따라 에이전트들이 유용한 컨텍스트를 유지하도록 돕는 것입니다.
특화된 에이전트들을 FalkorDB의 그래프 기반 데이터 모델과 결합함으로써, 이 프로젝트는 영속적인 메모리, 관계 인식 검색(relationship-aware retrieval), 그리고 모순 검토(contradiction review)를 하나로 통합합니다.
더 큰 교훈은 유용한 AI 메모리가 단순히 무엇이 말해졌는지 기억하는 것 이상을 해야 한다는 것입니다. 시스템이 정보가 어떻게 연결되는지 이해하고, 결정이 언제 바뀌었는지 식별하며, 필요할 때 과거 지식을 사용할 수 있도록 도와야 합니다.
목표는 현재 메시지에 응답할 뿐만 아니라 프로젝트의 진화하는 이력과 함께 작업할 수 있는 AI 에이전트를 구축하는 것입니다.
프로젝트 링크
GitHub 저장소: https://github.com/MOHITPRADHAN35/agentmesh
기술: FalkorDB, Python, FastAPI, React, 그리고 LLM 제공업체
FalkorDB Graph Hacks 2026을 위해 제작됨.