AI 메모리 도구를 도입했다가 제거한 이유

요즘 AI 관련 뉴스레터나 소셜미디어를 보다 보면 거의 매일 새로운 ‘에이전트 메모리’ 솔루션이 등장합니다. 상용과 오픈소스를 가리지 않고, 피칭 방식도 거의 동일합니다. “당신의 에이전트는 기억상실증이 있습니다.”

문제 자체는 실재합니다. 코딩 에이전트를 여러 기기와 여러 세션에 걸쳐 사용하다 보면 반드시 맞닥뜨리게 됩니다. 세션이 새로 시작될 때마다 어제 어떤 아키텍처 결정을 내렸는지, 어떤 접근 방식을 왜 포기했는지, 지금 어느 작업이 어디쯤 진행 중인지 에이전트는 전혀 모릅니다. Claude Code, OpenCode, Gemini 중 어떤 에이전트를 사용하든 매 세션마다 처음부터 다시 설명해야 합니다.

저도 같은 문제를 겪었습니다. 그래서 전용 AI 메모리 솔루션인 Mem0를 연결해봤습니다. 그러다가 결국 제거했습니다. 대신 두 개의 마크다운 파일로 이 문제를 해결하고 있습니다.

이 글에서는 Mem0를 도입했다가 제거하게 된 과정과, 대신 정착하게 된 두 파일 시스템에 대해 소개하겠습니다.

처음 선택한 해결책: Mem0

처음에 선택한 해결책은 Mem0였습니다. Mem0를 MCP 서버(에이전트가 외부 도구를 호출하는 표준 인터페이스)로 연결하고, 에이전트가 언제 메모리를 기록하고 읽어야 하는지에 대한 지침을 직접 설정했습니다. 결정의 종류에 따라 카테고리를 나누고, Claude·Gemini 같은 에이전트별로 메모리를 분리할 수 있도록 태깅을 구성했으며, 세션 시작 시 컨텍스트를 복원하기 위한 검색 쿼리도 함께 설정했습니다.

작동하기는 했습니다. 그러나 문제가 따라왔습니다.

에이전트가 중요한 결정을 내린 후 메모리를 기록해야 한다는 사실을 기억해야 했고, 세션을 시작할 때 먼저 메모리를 읽어야 한다는 사실도 기억해야 했습니다. 둘 중 하나라도 빠뜨리면 커버리지에 구멍이 생겼습니다. 한 세션에서 결정한 내용이 다음 세션에서는 없는 것처럼 동작하는 일이 반복되었습니다. 또한 모든 정보가 외부 서비스에 저장되었기 때문에, 레포지토리의 일부가 아닌 형태로 버전 관리 밖에 존재했습니다.

대신 구축한 시스템: 두 개의 마크다운 파일

결국 레포지토리 내부에 두 개의 파일로 이루어진 시스템에 정착하게 되었습니다.

• HANDOFF.md: 모든 세션 시작 시 자동으로 읽힙니다. 간결하며 항상 최신 상태입니다. 직전 세션에서 일어난 일, 프로젝트의 현재 상태, 다음 작업 목록을 담고 있으며, 누적 기록이 아니라 매 세션마다 새로 작성됩니다.
• WORKLOG.md: 세션별 전체 기록을 최신 항목이 위에 오도록 쌓아 나갑니다. 자동으로 읽히지 않으며, 더 깊은 컨텍스트가 필요할 때만 참고합니다.

이 두 파일만으로 외부 의존성 없이 세션 간, 기기 간, 에이전트 간 연속성을 유지할 수 있게 되었습니다.

자동 로딩 방식은 단순합니다. 각 에이전트에 항상 적용할 지침을 담아두는 AGENTS.md(또는 CLAUDE.md)에 “세션 시작 시 HANDOFF.md를 먼저 읽어라”는 지침을 한 줄 명시해 두면 됩니다. Claude Code, OpenCode, Gemini 중 어떤 에이전트를 사용하든 동일한 컨텍스트로 세션이 시작됩니다. 마크다운 파일을 읽을 수 있는 어떤 에이전트에서도 별도의 플러그인이나 통합 없이 작동합니다.

Mem0가 불필요해진 이유

마크다운 시스템이 자리를 잡은 후에도 한동안 Mem0를 병행해서 사용했습니다. 백업 용도도 있었고, 습관이기도 했습니다. 그런데 두 시스템이 실제로 제공하는 것을 비교해 보니 차이가 명확했습니다.

• 기억할 가치가 있는 정보는 이미 두 마크다운 파일에 모두 담겨 있었습니다.
• 두 파일은 버전 관리가 되고, 사람이 읽을 수 있으며, 표준 도구로 검색할 수 있었습니다.
• Mem0는 여전히 에이전트가 매 세션마다 직접 기록하고 읽어야 했습니다. 에이전트가 빠뜨리면 기록에 구멍이 생기는 같은 문제가 두 시스템에 걸쳐 이중으로 남아 있었습니다.
• Mem0의 실질적인 강점으로 남아 있던 것은 시맨틱 검색뿐이었는데, grep과 WORKLOG.md 상단을 읽는 것으로 검색이 필요한 경우의 대부분을 충분히 커버했습니다.

두 시스템을 함께 유지하는 것은 더 이상 의미가 없었습니다.

다만 Mem0가 더 적합한 상황도 있습니다. Mem0의 공식 사이트에서 소개하는 주요 사용처를 보면 고객 지원, 헬스케어, 교육, 영업 관리 등 다양합니다. 공통점은 다수의 사용자를 다루는 프로덕션 앱 환경이라는 점입니다. 환자마다 진료 이력과 알레르기 정보를 기억하거나, 학습자마다 진도와 선호 방식을 추적하거나, 고객마다 이전 문의 이력을 유지하는 것처럼 사용자 단위의 개인화 메모리가 필요한 경우가 Mem0의 핵심 사용처입니다. 단일 레포지토리 없이 여러 프로젝트를 넘나드는 개발 환경도 마찬가지입니다. 내 경우에는 하나의 레포지토리 안에서 혼자 작업하는 환경이었기 때문에 마크다운 파일로 충분했지만, 이 조건이 다르다면 선택도 달라질 수 있습니다.

이 시스템이 작동하는 이유: 재작성 vs. 누적

결국 두 마크다운 파일만 남겼습니다. 이 시스템이 작동하는 핵심 설계 원칙은 다음과 같습니다.

• HANDOFF.md는 작게 유지됩니다. 누적하지 않고 매 세션마다 새로 작성하기 때문입니다.
• WORKLOG.md는 제한 없이 커질 수 있습니다. 자동으로 읽히지 않으므로 에이전트는 필요한 만큼만 읽습니다.

현재 WORKLOG.md는 4,000줄이 넘습니다. 그러나 문제가 되지 않습니다. 어떤 에이전트도 전체를 컨텍스트에 올리지 않습니다. 최근 세션을 파악하려면 상위 150줄을 읽거나, 특정 주제를 찾으려면 해당 내용을 검색하면 됩니다.

결론

도구를 늘린다고 기억이 좋아지는 것은 아닙니다. 유지보수 부담만 커질 뿐입니다.

노트가 구조화되고, 버전 관리되고, 자동으로 로딩되는 시점이 되면 별도의 전용 메모리 레이어는 중간 단계의 복잡성만 추가합니다. 특히 여러 에이전트가 상태를 공유해야 하는 환경에서는 단순한 시스템이 유리합니다. 마크다운 파일은 특별한 통합 없이도 어떤 에이전트에서나 작동하기 때문입니다.

이상으로 AI 메모리 도구를 도입했다가 제거하게 된 과정과, 이를 대체한 두 파일 시스템에 대해 살펴보았습니다.