통합 메모리 아키텍처를 처음부터 구현하는 방법

커뮤니티 반응은 대체로 실무적·실험적 경험을 공유하는 방향으로 호응을 얻었으며 온톨로지 설계와 중복 처리 정책에 대해 추가 의견을 요청하는 댓글이 다수 달렸다. 많은 참여자가 단일 저장소 접근과 LLM 기반 추출의 현실적 장단점을 공감했고, 일부는 로그 기반 보관과 비용 관련 구현 경험을 추가로 공유했다. 논쟁은 주로 자동 병합의 위험성, 로그 보존 필요성, 그리고 온톨로지 깊이 대 폭의 균형에 집중되어 분화된 토론이 이루어졌다.

• 추출 파이프라인은 문서를 청크로 분할해 LLM에 넘기고 노드·엣지 결과를 배치로 수집하되 배치 크기와 보조 저비용 모델을 조합해 토큰 비용을 통제하라.
• 해상도 단계에서 이름·표현 정규화를 먼저 수행하고 별도의 정체성 판별 단계를 둬 자동 병합으로 인한 회복 불가능한 오류를 방지하라.
• 운영 복잡도를 낮추려면 가능하면 텍스트 인덱스·임베딩·그래프를 동일 DB에 모으고 라인리지 추적 정책을 통합하되 시계열 보존 요건이 있으면 로그 전략을 별도 고려하라.
• 대형 서브그래프는 주기적으로 요약해 LLM 위키로 캐시하고 필요할 때만 원본 서브그래프를 풀어 쿼리해 컨텍스트 폭발을 방지하라.
• MCP 서버는 DB 원시 연산을 노출하지 않고 핵심 ingest와 query primitives만 제공하는 경량 메모리 앱으로 설계해 권한·검증 경로를 통제하라.

Knowledge Graph

— 개별 실체(사람·사건·위치 등)와 이들 간의 관계를 노드와 엣지로 표현하는 구조형 데이터 모델로, 본문에서는 에이전트 메모리의 중심 스키마로 작동하며 텍스트·임베딩 검색과 결합되어 컨텍스트 검색과 멀티홉 추론의 기반이 된다.

POLE+O

— Person, Object, Location, Event, Organization에 preference와 fact 노드를 추가한 온톨로지로, 문서에서 공통 스키마 사례로 제시되며 추출·검색·연결 규칙을 단순화해 일관된 질의와 정합성 검사를 가능하게 한다.

Unified Database

— 텍스트 인덱스, 벡터 임베딩, 그래프 관계를 하나의 DB에 통합해 라인리지 추적과 운영 오버헤드를 줄이는 접근 방식으로, 글에서는 MongoDB 같은 범용 DB로 통합하는 실무적 장점을 설명하고 있다.

Deduplication

— 추출 과정에서 동일 실체가 여러 노드로 생성되는 문제를 해결하기 위한 단계로, 이름·표현 해상도(resolution)와 정체성(identity) 판별을 분리하여 잘못된 병합을 방지하는 절차를 포함한다.

MCP Server

— 메모리와 검색 기능을 노출하는 경량 서버 계층으로, 원문에서는 DB의 원시 연산을 노출하지 않고 핵심 인게스트·쿼리 연산만 제공하는 메모리 앱으로 설계해야 한다고 권고하고 있다.