MCP 기반 장기 기억 시스템 아키텍처: “저장”이 아니라 “기억”을 설계하는 법

MCP 기반 장기 기억 시스템 아키텍처: “저장”이 아니라 “기억”을 설계하는 법

LLM 애플리케이션을 만들다 보면 금방 부딪히는 문제가 있습니다.
대화가 길어질수록 맥락은 흐려지고, 중요한 정보와 덜 중요한 정보가 같은 무게로 쌓입니다. 결국 “기억하는 시스템”이 아니라 “쌓아두는 시스템”이 되기 쉽습니다.

이번 글에서는 제가 작업한 Memento 프로젝트를 바탕으로, MCP(Model Context Protocol) 환경에서 장기 기억 시스템을 어떻게 아키텍처로 분해했는지 정리해보겠습니다. 핵심은 단순합니다.

• 기억을 저장(memory)만 하지 않는다.
• 필요할 때 찾고(search), 불필요하면 잊고(forgetting), 맥락을 고정(anchor)한다.
• 이 흐름을 도메인 단위로 분리해 운영 가능하게 만든다.

왜 “장기 기억”은 아키텍처 문제인가

초기에는 보통 이렇게 시작합니다.

• 입력을 받아 DB에 저장
• 임베딩 생성 후 벡터 검색
• 유사한 결과를 프롬프트에 붙여 응답

이 방식은 빠르게 만들 수 있지만, 서비스가 커질수록 문제가 드러납니다.

• 검색 정확도보다 “최근성”이나 “중요도”가 더 중요할 때가 있다.
• 오래된 기억이 계속 상위에 떠서 현재 맥락을 오염시킨다.
• 사용자가 지금 집중하는 주제를 반영한 국소 탐색이 어렵다.
• 운영 중 로그/재시도/설정 관리가 분산되어 디버깅 비용이 커진다.

그래서 Memento는 기능이 아니라 책임을 기준으로 도메인을 나눴습니다.

전체 구조 한눈에 보기

[MCP/HTTP Entry]
      |
      v
[Memory Domain] <-> [Embedding Domain]
      |                    |
      v                    v
[Search Domain] <------ [Vector/Text Index]
      |
      +--> [Anchor Domain]  (현재 맥락 고정/국소 검색)
      |
      +--> [Relation Domain] (기억 간 연결)
      |
      +--> [Forgetting Domain] (보존/감쇠/정리 정책)
      |
      v
[Infrastructure: DB/Cache/Scheduler/Config/Monitoring]

핵심은 “검색 엔진 하나”가 아니라, 기억 라이프사이클 전체를 독립 모듈로 다루는 점입니다.

도메인별 책임 분리

1) Memory: 기억의 단위와 생명주기

memory 도메인은 기억의 생성/수정/조회/삭제 같은 CRUD를 넘어서, 기억 타입과 메타데이터를 다룹니다.

• 작업 중 정보(working)
• 사건 기록(episodic)
• 일반 지식(semantic)
• 절차 지식(procedural)

이 타입 분리는 이후 검색 전략과 망각 정책의 기준점이 됩니다.

2) Embedding: 의미 공간으로의 변환

embedding 도메인은 외부 모델 호출을 캡슐화합니다.

• 모델 교체 가능성 확보
• 재시도/오류 처리 정책 일원화
• 호출 실패가 전체 파이프라인을 깨지 않도록 격리

즉, 검색 품질의 기반이지만 운영 리스크도 큰 영역이라 분리가 필수입니다.

3) Search: 하이브리드 검색의 실행 계층

search 도메인은 벡터 유사도와 텍스트 기반 검색을 조합합니다.

• 벡터: 의미적으로 비슷한 기억 탐색
• 텍스트: 정확 키워드/식별자 매칭
• 랭킹: 중요도·신선도·정합성 등을 함께 반영

검색이 단일 알고리즘이 아니라 “정책 엔진”으로 동작하게 만든 것이 포인트입니다.

4) Anchor: 지금 맥락을 고정하는 장치

실사용에서 가장 체감이 큰 기능입니다.
앵커는 “지금 이 대화/작업에서 무엇이 중심인지”를 명시적으로 고정합니다.

• A/B/C 슬롯으로 즉시·보조·확장 맥락 관리
• 전역 검색 전에 앵커 주변 국소 탐색 가능
• 맥락 점프를 줄여 응답 일관성 향상

RAG에서 흔히 놓치는 “현재 의도 유지” 문제를 해결해줍니다.

5) Forgetting: 장기 기억 품질 유지 장치

망각은 삭제 기능이 아니라 품질 관리 정책입니다.

• 중요도 기반 보존/감쇠
• 접근 빈도와 시간 축 반영
• 노이즈 정리로 검색 효율 유지

기억 시스템은 “무한 저장”이 아니라 “유한한 주의력”을 흉내 내야 장기적으로 건강해집니다.

6) Relation: 기억 간 연결 그래프

기억을 점이 아니라 그래프로 다루면 탐색이 달라집니다.

• 사건 ↔ 개념 연결
• 근거 관계(supported_by) 추적
• N-hop 탐색으로 간접 연관 지식까지 확장

단일 유사도 검색만으로는 못 찾는 맥락을 관계 그래프가 보완합니다.

운영 관점에서 중요한 설계 포인트

아키텍처는 예쁜 다이어그램보다 운영 시나리오에서 검증됩니다.
Memento에서 특히 중요했던 포인트는 다음입니다.

• 로깅 표준화: console.* 의존을 줄이고 구조화 로그로 통일
• 재시도 정책 통일: 외부 API 실패를 예측 가능한 방식으로 흡수
• 설정 외부화: 랭킹 가중치/임계값을 코드 밖에서 조정
• 마이그레이션 체계화: 스키마 변경을 스크립트가 아닌 시스템으로 관리

이 네 가지가 없으면 검색 품질보다 먼저 운영비가 폭증합니다.

이 구조가 실제로 주는 이점

• 기능 추가가 쉽다: 도메인 경계가 명확해서 변경 파급이 작다.
• 품질 개선이 빠르다: 검색/망각/앵커 정책을 독립적으로 실험 가능하다.
• 장애 대응이 쉽다: 로그·재시도·설정 경로가 표준화되어 원인 추적이 빠르다.
• MCP 친화적이다: 툴/리소스/API를 같은 모델로 노출하기 좋다.

마무리: 장기 기억은 “기능”이 아니라 “시스템”이다

장기 기억 시스템을 만들 때 가장 흔한 실수는 저장소를 먼저 고르는 것입니다.
실제로 먼저 정해야 하는 건 라이프사이클입니다.

• 무엇을 기억할지
• 언제 꺼내 쓸지
• 언제 잊을지
• 현재 맥락을 어떻게 고정할지

Memento의 결론은 명확합니다.
장기 기억 품질은 모델 성능보다 아키텍처에서 더 많이 결정됩니다.