지식 그래프 기반 에이전트 메모리를 1년간 구축하며 겪은 5가지 치명적인 실수

지난 1년 동안 MongoDB 위에 지식 그래프랑 온톨로지를 얹어서 AI 에이전트를 위한 통합 메모리 계층을 만드느라 개고생했다. 처음엔 유행하는 건 다 따라 해봤음. 번지르르한 프레임워크부터 갖다 쓰고, 완벽한 온톨로지를 미리 설계해보겠다고 난리 쳤지. 그냥 할 수 있는 실수는 다 저질렀다고 보면 된다.

단순한 메모리 방식은 규모가 커지면 바로 나가떨어진다. 메모리가 쌓이면 파일 검색만으로도 컨텍스트 윈도우가 터져버리거든. Claude Code가 기본적으로 이런 방식을 쓰는데, 기록을 시맨틱 검색으로 뒤져봐도 사람, 주제, 사물, 위치, 선호도 사이의 관계를 제대로 엮어내질 못함. 결국 메모리를 검색 문제로 보지 말고 데이터 모델링 문제로 접근해야 답이 나온다는 걸 깨달았다.

내가 저지른 실수 5가지는 이거다:

1. 프레임워크부터 찾았다. LangGraph랑 CrewAI를 써봤는데, 커스텀 온톨로지 제약 조건이나 불변 관찰 로그, 복합 ID, 다중 홉 탐색이 필요해지는 순간 프레임워크랑 싸우게 되더라. 교훈: 메모리랑 제어 구조는 직접 짜라. 프레임워크는 니 시스템이랑 안 맞는 가정을 깔고 가는 경우가 태반이다.

2. 온톨로지에 너무 힘을 줬다. 데이터 모델링 문제라는 걸 알았으니 처음부터 완벽한 온톨로지를 설계하려고 했지. 덕분에 프로젝트가 몇 달 동안 멈춰버렸다. 교훈: 온톨로지 설계는 데이터 탐색 루프다. POLE+O(사람/사물/위치/이벤트/조직)로 시작해서 충돌 날 때만 확장해라. 예를 들어, 난 "Claude Code"를 사물인데 사람으로 태그 달아서 꼬인 적 있음.

3. 리졸루션(Resolution)이랑 중복 제거(Deduplication)를 헷갈렸다. 이름이 같다고 같은 놈이 아니다. 이걸 섞어버리면 그래프 다 망가짐. 리졸루션은 이름을 표준화하는 거고, 중복 제거는 엔티티의 맥락을 보고 동일 인물인지 판단하는 거다. 교훈: 확실한 기준을 세워라. ≥0.95면 자동 병합, >0.85면 사람 검토, ≤0.85면 새 노드 생성. 이렇게 해야 회사 "Apple"이랑 과일 "Apple"이 합쳐지는 대참사를 막는다.

4. 단기/장기 메모리만 만들었다. 추론 메모리를 빼먹었더니 에이전트가 맨날 똑같은 삽질을 반복하더라. 추론 메모리는 전략, 사용한 도구, 성공 여부를 포함한 실행 단위의 흔적이다. 교훈: 추론 메모리는 가중치 대신 데이터베이스 계층에서 돌리는 RL(강화학습) 같은 거다. 솔직히 말하면, 잘못된 흔적이 잘못된 전략을 강화할 수도 있고, 일회성 작업에는 과해서 독이 될 수도 있음.

5. 그래프를 데이터베이스에 구체화하기 전에 불변 로그 계층부터 만들려고 했다. 그래프에 버전 관리랑 시간 개념을 넣으면 멋있어 보였거든. 근데 문제는 VM RAM을 엄청나게 잡아먹는다는 거다. 비용 개비쌈. 교훈: 진짜 필요할 때만 해라.

스키마가 시스템 성능의 모든 걸 결정한다. MongoDB에서 엣지를 일급 객체(first-class document)로 처리하기로 결정하고 나서야 <code>$graphLookup</code>을 제대로 쓸 수 있었고, 시스템이 비로소 확장 가능해졌다. 이 방식이 관계 중복도 피하고 쓰기 작업도 훨씬 간단하게 만들어줌.

너희도 지식 그래프랑 온톨로지로 에이전트 메모리 만들어본 적 있냐? 있다면 어떤 실수를 했고 뭘 배웠는지 좀 알려줘라.

세 줄 요약: 에이전트 메모리는 검색이 아니라 데이터 모델링 문제다. 프레임워크에 의존하지 말고, 온톨로지 미리 설계하느라 힘 빼지 마라. 리졸루션이랑 중복 제거는 확실히 나누고 추론 메모리를 추가해라.