CrabRAG: Why Automated Assistants Need Graph Memory, Not More Tokens — Stephen Chin, Neo4j

한 줄 핵심

에이전트 메모리는 마크다운 파일이나 벡터 검색만으로는 한계가 뚜렷하며, 관계를 보존하는 그래프 메모리와 벡터를 함께 써야 정확하고 설명 가능한 자동화가 가능하다는 주장이다.

시간별 요약

1. 0:01
   에이전트는 도구가 많아져도 기억을 매일 잃어버리면 같은 일을 반복해서 다시 배워야 한다. 결국 핵심 문제는 도구 수가 아니라 무엇을 컨텍스트에 넣고 무엇을 기억으로 구조화하느냐에 있다.
2. 2:03
   대부분의 에이전트 메모리는 solved.md, memory files, skill files 같은 마크다운 파일에 의존해 반복적으로 전체를 적재한다. 이 방식은 소규모에서는 동작하지만, 100k 토큰 이상을 매 라운드 소모하며 대규모 환경에서는 비효율이 커진다.
3. 4:00
   기억을 더 잘 관리하려는 시도로 Hermes agent, Goose 같은 시스템과 스킬·MCP 메모리 서버가 등장했지만, 여전히 파일 기반 저장이라는 같은 한계를 공유한다. 잘못된 스킬을 불러오거나 너무 많은 메모리를 쌓아두면 문제 해결보다 혼란이 더 커진다.
4. 8:00
   벡터 데이터베이스는 관련 정보를 유사도로 잘 찾지만, 실제 관계와 다단계 추론을 보장하지 못해 환각과 오답이 생긴다. 그래서 similarity search만으로는 복잡한 도메인 문제나 digital twin 같은 상황에서 정확한 답을 안정적으로 얻기 어렵다.
5. 10:01
   그래프는 노드와 관계를 통해 연결 구조를 직접 표현하므로, 탐색 경로와 근거를 함께 제공하는 정확성·설명가능성·감사가 가능하다. 벡터로 시드 노드를 찾고 그래프로 다단계 탐색을 이어가는 방식이 가장 실용적인 조합이며, Claude가 Cypher 작성과 추출 작업까지 보조할 수 있다.
6. 12:02
   홈랩 digital twin을 대상으로 한 실제 비교에서 벡터 저장소는 구체적 세부사항을 놓친 반면, 그래프 저장소는 WAN 노출, 오래된 OS, 관리 포트 개방 같은 위험을 정확히 집어냈다. 같은 데이터라도 그래프는 경로를 따라 근거를 추적하므로 더 실무적인 보안 점검과 운영 판단에 유리하다.

실무 인사이트

• 에이전트 메모리는 단순 저장보다 '관계 유지 + 경로 추적'이 중요하므로, 벡터 검색만 쓰기보다 그래프를 메인 기억층으로 두는 구성이 효과적이다.
• 실제 운영에서는 전체 메모리를 매번 다시 읽지 말고, 벡터로 후보를 좁힌 뒤 그래프로 다단계 검증하는 2단계 검색 구조가 비용과 정확도의 균형이 좋다.
• 보안·운영 자동화처럼 오답 비용이 큰 영역은 그래프 메모리의 설명가능성과 감사 가능성을 우선 고려해야 한다.