AI 요약
최근 개발 환경에서는 비용 효율성을 위해 대량의 코드 생성에는 저렴한 Cursor(Sonnet 4)를, 복잡한 비즈니스 로직 설계에는 고성능 Claude Code(Opus)를 혼용하는 방식이 일반적입니다. 그러나 각 LLM의 메모리가 해당 플랫폼 내에만 국한되어 있어, 사용자는 모델을 바꿀 때마다 과거의 설계 판단이나 파일 구조를 수동으로 다시 입력해야 하는 번거로움을 겪고 있습니다. 이러한 컨텍스트 재공유는 토큰 소모량을 5배까지 늘리고 컨텍스트 윈도우의 약 30%를 낭비하게 만듭니다. 이를 해결하기 위해 MCP 서버인 'Linksee Memory'는 ~/.linksee-memory/memory.db라는 단일 SQLite 파일을 생성하여 5개의 LLM이 동일한 기억을 읽고 쓰도록 지원합니다. 결과적으로 토요일에 Codex에서 결정한 DB 설계 방식이 수요일의 Claude Code 작업에 즉시 반영되는 등, AI 간의 심리스한 지식 전승이 가능해졌습니다.
핵심 인사이트
- 멀티 LLM 최적화 전략: 사용자는 양적 작업(Cursor)과 질적 작업(Claude Code/Opus)으로 LLM을 구분하여 사용하며, 이는 비용 및 품질 관리를 위한 필수적인 접근임.
- 컨텍스트 단절의 비용: 수동으로 50개 이상의 파일 구조를 다시 전달할 경우 토큰 비용이 5배 증가하며, 컨텍스트 윈도우의 30%가 중복 정보로 채워짐.
- 중앙 집중식 메모리: Anthropic, OpenAI, Google의 각기 다른 메모리 툴을 대신하여 MCP 기반의 통합 SQLite 저장소를 사용해 플랫폼 종속성을 극복함.
- 구조화된 기억 관리: 단순 텍스트 저장이 아닌 중요도(importance: 0.9), 보호 여부(protected), 주의사항(caveat) 등 구체적인 메타데이터를 포함한 지식 관리가 이루어짐.
주요 디테일
- 실제 사례 적용: 토요일에 Codex로 9개의 migration 파일을 생성하며 RLS(Row Level Security) 정책과 날짜 포맷("MM-DD")을 caveat으로 저장하면, 수요일에 Claude Code가 이를 별도 입력 없이 즉시 참조하여 API를 설계함.
- 기술적 구성 요소: Linksee Memory는 MCP 서버로 작동하며, 로컬 환경의
~/.linksee-memory/memory.db파일을 통해 데이터 지속성을 확보함. - 대상 LLM 범위: Claude (Anthropic memory), ChatGPT (Custom GPT), Cursor (manual rules), OpenAI Codex (config), Gemini CLI (settings.json) 등 5개 주요 도구를 통합 타겟으로 삼음.
- 효율성 지표: 컨텍스트 재공유에 소요되는 시간을 0으로 줄이고, 수동 작업으로 소모되던 약 5분 이상의 개발 흐름 단절을 방지함.
- 계층적 정보 기록: 단순 대화 내역이 아닌 goal(목표), learning(학습 내용), implementation(구현 방식) 등 4개 카테고리로 정보를 분류하여 기록함.
향후 전망
- 멀티 LLM 오케스트레이션 가속화: 특정 모델에 종속되지 않고 작업 특성에 맞춰 LLM을 교체하며 사용하는 '파워 유저' 중심의 개발 문화가 MCP를 통해 더욱 확산될 것임.
- 로컬 지식 베이스의 중요성 증대: AI 모델 자체의 성능보다 개발자의 의도와 과거의 판단 근거를 얼마나 체계적으로 관리하고 AI에게 전달하느냐가 생산성의 핵심 변수가 될 전망임.