매일 AI를 사용하는 대부분의 개발자들은 동일하고 이상한 문제에 직면해 왔습니다.

모델들은 점점 좋아지고 있지만, 워크플로우는 여전히 이상할 정도로 상태가 유지되지 않는 (stateless) 느낌을 줍니다.

ChatGPT에 프로젝트를 설명합니다. 그다음 Claude에 다시 설명합니다. 그다음 Cursor에 또 다시 설명합니다. 로컬 모델을 사용하려고 하면 처음부터 다시 시작해야 합니다. 그러다 이전 채팅이 지저분해지면 새 채팅을 열고, 동일한 컨텍스트 (context)를 다시 구축합니다.

문제는 AI가 쓸모없다는 것이 아닙니다.

문제는 유용한 컨텍스트 (context)가 잘못된 곳에 갇혀 있다는 것입니다.

어떤 도구는 당신이 코드를 어떻게 리뷰받기를 원하는지 알고 있습니다. 다른 도구는 당신의 프로젝트 아키텍처 (architecture)를 알고 있습니다. 또 다른 도구는 당신이 만들고 있는 제품을 알고 있습니다. 또 다른 도구는 당신의 글쓰기 스타일을 알고 있습니다. 또 다른 도구는 아무것도 모릅니다. 각 어시스턴트 (assistant)는 당신에 대한 부분적인 그림을 그려내지만, 그 어떤 컨텍스트 (context)도 도구 간에 깔끔하게 이동하지 않습니다.

결국 개발자가 전송 레이어 (transport layer)가 됩니다.

이전 요약본을 복사합니다. 프로젝트 설명을 붙여넣습니다. 프롬프트 (prompt) 파일을 관리합니다. 동일한 제약 사항을 다시 설명합니다. 모델에게 무엇을 하지 말아야 할지 계속해서 말해줍니다. AI 도구를 실제로 사용하기도 전에, 그것들을 유용하게 만들기 위한 작은 의식(ritual)을 만들어냅니다.

저에게는 이것이 잘못된 것처럼 느껴졌습니다.

AI가 개발 환경의 일부가 되고 있다면, 메모리 (memory)는 개별 채팅 제품 안에 갇혀 있어서는 안 됩니다. 메모리 레이어 (memory layer)는 모델 (model) 및 인터페이스 (interface)와 독립적이어야 합니다.

그것이 제가 Deja Vu를 만든 이유입니다.

Deja Vu는 AI 도구를 위한 로컬 우선 (local-first) 메모리 레이어 (memory layer)입니다. 유용한 컨텍스트 (context)를 로컬 SQLite 데이터베이스에 저장하고, MCP를 포함하여 개발자 친화적인 인터페이스를 통해 이를 노출함으로써, 서로 다른 AI 도구들이 각각 처음부터 시작하는 대신 동일한 지속 가능한 메모리 (durable memory)에 접근할 수 있도록 합니다.

아이디어는 간단합니다:

당신의 모델 (model)은 바뀔 수 있습니다.

당신의 어시스턴트 (assistant)는 바뀔 수 있습니다.

당신의 에디터 (editor)는 바뀔 수 있습니다.

당신의 메모리 (memory)는 지속되어야 합니다.

*진정한 문제는 컨텍스트 파편화 (Context Fragmentation)입니다
*
많은 사람들이 이를 "AI가 잊어버린다"라고 설명합니다.

그것은 정확하지 않습니다.

AI 도구들도 무언가를 기억합니다. 어떤 도구는 채팅 기록 (Chat History)을 통해 기억합니다. 어떤 도구는 명시적인 메모리 (Memory) 기능을 가지고 있습니다. 어떤 도구는 선호도를 추론합니다. 어떤 도구는 프로젝트 컨텍스트 (Project Context)를 저장합니다. 어떤 도구는 긴 컨텍스트 윈도우 (Long Context Windows)에 의존합니다. 어떤 도구는 문서 업로드를 허용합니다. 어떤 도구는 규칙 (Rules)을 설정할 수 있게 해줍니다.

문제는 모든 도구가 각기 별개로 기억한다는 점입니다.

그것이 파편화 (Fragmentation)를 만듭니다.

개발자에게 컨텍스트 (Context)는 단 하나의 요소가 아닙니다. 그것은 지속적인 사실 (Durable Facts), 일시적인 작업 상태 (Temporary Task State), 프로젝트 관례 (Project Conventions), 개인적 선호도 (Personal Preferences), 아키텍처 결정 (Architectural Decisions), 폐기된 접근 방식 (Abandoned Approaches), 배포 세부 사항 (Deployment Details), 명명 패턴 (Naming Patterns), API 가정 (API Assumptions), 팀의 습관 (Team Habits), 그리고 취향 (Taste)이 뒤섞인 것입니다.

그중 일부는 문서화 (Documentation)에 포함되어야 합니다.

일부는 코드 주석 (Code Comments)에 포함되어야 합니다.

일부는 이슈 트래커 (Issue Trackers)에 포함되어야 합니다.

일부는 커밋 히스토리 (Commit History)에 포함되어야 합니다.

하지만 그 중 상당수는 당신과 AI 시스템 사이의 작업 관계 (Working Relationship) 속에 존재합니다.

예를 들어:

• 당신은 동기 부여를 위한 피드백 대신 직접적인 코드 리뷰 (Code Review)를 선호합니다.
• 별도의 언급이 없는 한 TypeScript 예제를 원합니다.
• 당신의 앱은 특정 인증 제공자 (Auth Provider)를 사용합니다.
• 당신의 백엔드에는 꼭 필요한 경우가 아니면 건드려서는 안 되는 보기 싫은 레거시 서비스 (Legacy Service)가 하나 있습니다.
• 당신의 프론트엔드 컴포넌트는 특정 명명 규칙 (Naming Convention)을 따릅니다.
• 당신은 이미 한 가지 아키텍처를 시도했다가 거부했습니다.
• 당신은 디버깅 중에는 짧은 답변을 좋아하지만, 학습 중에는 더 깊은 설명을 원합니다.

이것들은 항상 README에 기록할 가치가 있는 것은 아닙니다. 그렇다고 무작위적인 채팅 기록도 아닙니다. 이것들은 메모리 (Memory)입니다.

그리고 현재, 그 메모리는 흩어져 있습니다.

채팅 기록은 메모리가 아니다

유혹적인 해결책 중 하나는 더 긴 채팅 기록을 유지하는 것입니다.

그것이 도움이 되긴 하지만, 메모리와 동일한 것은 아닙니다.

대화 기록 (Transcript)은 가공되지 않은 재료입니다. 메모리는 구조화된 연속성 (Structured Continuity)입니다.

만약 시스템이 모든 것을 기억한다면, 그것은 메모리 문제를 해결한 것이 아닙니다. 검색 문제 (Search Problem), 개인정보 보호 문제 (Privacy Problem), 그리고 결국 신뢰 문제 (Trust Problem)를 만들어낸 것입니다.

유용한 메모리 레이어 (Memory Layer)는 무엇을 앞으로 가져갈 가치가 있는지 결정할 수 있어야 합니다.

사용자가 입력한 모든 문장을 저장하는 것과 다음을 기억하는 것 사이에는 큰 차이가 있습니다:

사용자는 로컬 우선 (Local-first) AI 메모리 도구를 구축하고 있다.

이 프로젝트는 기본 로컬 저장소로 SQLite를 사용합니다.

사용자는 과하게 설계된 추상화 (over-engineered abstractions)를 싫어합니다.

사용자는 기업적인 느낌보다는 창업자가 직접 쓴 것 같은 느낌의 출시 문구 (launch copy)를 선호합니다.

사용자는 이미 특정 포지셔닝 각도를 거절했습니다.

이것들은 지속적인 컨텍스트 (context) 조각들입니다. 이 정보들은 다시 중요해질 가능성이 높습니다.

메모리 레이어는 이러한 종류의 정보를 추출하고, 중복을 제거하며, 변경될 때 업데이트하고, 관련이 있을 때 사용할 수 있도록 만들어야 합니다.

모든 것을 맹목적으로 쌓아두어서는 안 됩니다.

그 차이점이 Deja Vu의 핵심이 되었습니다.

목표는 무한한 회상 (infinite recall)이 아닙니다.

목표는 유용한 연속성 (useful continuity)입니다.

왜 챗봇 외부의 메모리를 원했는가

AI 도구를 더 많이 사용할수록, 어시스턴트가 메모리를 소유해서는 안 된다는 사실이 점점 더 분명해졌습니다.

어시스턴트는 단지 하나의 인터페이스일 뿐입니다.

오늘 저는 전략 수립에는 ChatGPT를, 글쓰기에는 Claude를, 코딩에는 Cursor를, 개인적인 작업에는 로컬 모델을, 그리고 특정 작업을 위한 특화된 에이전트 (agent)를 사용할 수도 있습니다. 내일은 그 스택 (stack)이 바뀔 수도 있습니다. 더 나은 모델들이 나올 것입니다. 더 나은 에디터들이 등장할 것입니다. 새로운 에이전트들이 유용해질 것입니다. 어떤 제품은 사라질 것입니다. 어떤 제품은 너무 비싸질 것입니다. 어떤 제품은 정책을 변경할 것입니다. 어떤 제품은 제가 일하는 방식과 맞지 않게 될 것입니다.

메모리가 제가 지난달에 우연히 사용했던 인터페이스 안에 갇혀 있어서는 안 됩니다.

이것은 개발자들에게 특히 중요한데, 우리는 이미 이식 가능한 상태 (portable state)의 가치를 이해하고 있기 때문입니다.

우리는 우리의 소스 코드가 하나의 IDE 안에 갇히는 것을 원하지 않습니다.

우리는 우리의 환경 변수 (environment variables)가 하나의 호스팅 제공업체 안에 갇히는 것을 원하지 않습니다.

우리는 우리의 데이터베이스가 하나의 대시보드를 통해서만 접근 가능한 것을 원하지 않습니다.

우리는 우리의 자격 증명 (credentials)이 우리가 떠날 수 없는 브라우저에 저장되는 것을 원하지 않습니다.

그렇다면 왜 우리의 AI 메모리는 하나의 챗봇 안에 머물러야 할까요?

AI가 더 유용해질수록, 메모리는 더 가치 있어집니다. 만약 메모리가 플랫폼 소유로 남는다면, 그것은 매우 조용한 형태의 락인 (lock-in)이 됩니다.

코드를 통한 락인이 아닙니다.

컨텍스트를 통한 락인입니다.

도구가 당신을 알고 있기 때문에 당신은 머무릅니다. 다른 곳에서 그 컨텍스트 (context)를 다시 구축하는 것이 번거롭기 때문에 당신은 머무릅니다. 비록 어딘가에 더 나은 모델 (model)이나 인터페이스 (interface)가 존재하더라도, 어시스턴트 (assistant)가 시간이 흐르며 유용해졌기 때문에 당신은 머무릅니다.

그것은 제가 원하는 미래가 아닙니다.

저는 메모리 (memory)가 사용자에게 속하기를 원합니다.

아키텍처 (Architecture)는 의도적으로 지루합니다

Deja Vu는 메모리를 SQLite에 로컬 (local)로 저장합니다.

이러한 선택은 우연이 아닙니다.

SQLite는 가능한 가장 좋은 의미에서 지루합니다. 그것은 신뢰할 수 있고, 이식성이 높으며, 검사 가능하고, 이미 어디에나 존재합니다. 클라우드 (cloud) 계정이 필요하지 않습니다. 새로운 백엔드 (backend)가 필요하지 않습니다. 어떤 플랫폼이 당신의 컨텍스트 (context)를 계속해서 당신에게 다시 노출해 줄 것이라고 믿을 필요도 없습니다.

SQLite 파일은 복사할 수 있습니다.

백업할 수 있습니다.

검사할 수 있습니다.

암호화할 수 있습니다.

기기 간에 이동할 수 있습니다.

그것을 생성한 앱 (app)보다 더 오래 지속될 수 있습니다.

AI 메모리 (AI memory)에게 있어, 그것은 매우 중요합니다.

메모리는 다음 위치에 존재합니다:

~/.dejavu/memories.db

이 단 하나의 설계 결정이 사용자와 시스템 사이의 관계를 변화시킵니다.

메모리가 제품 내부의 숨겨진 프로필 (profile)이 되는 대신, 사용자가 소유하는 로컬 아티팩트 (local artifact)가 됩니다.

파일에는 이름이 있습니다.

파일에는 위치가 있습니다.

파일은 인프라 (infrastructure)처럼 취급될 수 있습니다.

그것이 핵심입니다.

*Deja Vu가 실제로 하는 일
*
높은 수준 (high level)에서, Deja Vu는 단순한 루프 (loop)를 중심으로 구축되었습니다:

1. 유용한 컨텍스트 (context)를 관찰합니다.
2. 지속 가능한 메모리 (durable memory)를 추출합니다.
3. 이를 로컬 (locally)에 저장합니다.
4. 시간이 지남에 따라 중복을 제거하고 업데이트합니다.
5. AI 도구가 컨텍스트 (context)를 필요로 할 때 관련 메모리를 검색합니다.

목적은 모든 메시지를 저장하는 것이 아닙니다. 목적은 다시 중요해질 가능성이 있는 정보를 보존하는 것입니다.

여기에는 다음과 같은 것들이 포함됩니다:

프로젝트 세부 사항 (Project details)

사용자 선호도 (User preferences)

기술 스택 (Technical stack)

글쓰기 스타일 (Writing style)

반복되는 제약 사항 (Recurring constraints)

중요한 결정 (Important decisions)

거부된 접근 방식 (Rejected approaches)

유용한 사실 (Useful facts)

진행 중인 작업 (Ongoing work)

그러면 메모리 레이어 (memory layer)는 다른 도구들이 사용할 수 있는 인터페이스 (interfaces)를 통해 이러한 사실들을 사용할 수 있게 만듭니다.

Deja Vu는 CLI, 로컬 REST API, Python SDK, 그리고 MCP 지원을 포함합니다. MCP 부분이 중요한 이유는 AI 도구들이 각각 고립된 메모리 시스템을 가질 필요 없이, 외부 컨텍스트 소스 (external context source)로서 메모리에 연결할 수 있게 해주기 때문입니다.

모델이 당신의 메모리를 사용하기 위해, 당신의 메모리를 직접 소유할 필요는 없어야 합니다.

그것이 기본적인 아키텍처 (architecture)입니다.

*MCP가 중요한 이유
*
MCP가 중요한 이유는 더 모듈화된 AI 스택 (modular AI stack)을 향하고 있기 때문입니다.

모든 AI 제품이 자체적인 도구, 메모리, 문서, 그리고 개인 상태 (private state)를 가진 폐쇄된 컨테이너 (closed container)가 되는 대신, MCP는 어시스턴트 (assistants)가 더 표준화된 방식으로 외부 시스템에 연결할 수 있도록 해줍니다.

메모리의 경우, 이것이 정확히 올바른 추상화 (abstraction)입니다.

AI 도구는 다음과 같은 질문을 던질 수 있어야 합니다:

이 사용자는 보통 무엇을 선호하는가?

그들은 어떤 프로젝트를 작업 중인가?

이 작업에 관련 있는 컨텍스트 (context)는 무엇인가?

답변하기 전에 내가 알아야 할 제약 사항 (constraints)은 무엇인가?

하지만 도구 스스로 그 모든 것을 저장할 필요는 없어야 합니다.

메모리는 어시스턴트 외부에 존재할 수 있습니다.

그 분리가 중요합니다.

메모리가 외부화되면, 어시스턴트는 교체 가능한 존재가 됩니다. 서로 다른 모델과 도구들을 동일한 내구성 있는 컨텍스트 레이어 (durable context layer)에 연결할 수 있습니다. 호스팅된 모델 (hosted models)과 로컬 모델 (local models)을 모두 사용할 수 있습니다. 코딩 에이전트 (coding agents)와 글쓰기 어시스턴트 (writing assistants)를 사용할 수 있습니다. 연속성을 잃지 않으면서 새로운 인터페이스 (interfaces)를 실험할 수 있습니다.

그것이 Deja Vu가 설계된 미래입니다.

추론할 수 있는 모델.

행동할 수 있는 도구.

지속될 수 있는 메모리.

이것들은 서로 분리된 레이어 (layers)여야 합니다.

*로컬 퍼스트 (Local-First)가 안티 클라우드 (Anti-Cloud)를 의미하지는 않습니다
*
여기서 정확히 짚고 넘어갈 가치가 있습니다.

로컬 퍼스트 (Local-first)가 클라우드가 나쁘다는 것을 의미하지는 않습니다.

동기화 (sync)가 나쁘다는 뜻도 아닙니다.

AI 도구가 원격 추론 (remote inference)을 절대 사용해서는 안 된다는 뜻도 아닙니다.

그것은 사용자의 복사본이 기본 (primary)이라는 것을 의미합니다.

사용자는 자신이 직접 제어할 수 있는 형태로 메모리를 보유해야 합니다. 거기서부터 사용자는 어떻게 동기화할지, 백업할지, 암호화할지, 공유할지, 또는 다른 도구에 연결할지를 결정할 수 있습니다.

그 기본 설정 (default)이 중요합니다.

만약 당신의 AI 메모리 유일한 복사본이 특정 플랫폼 계정 내부에만 존재한다면, 당신은 접근성, 휴대성 (portability), 가격 책정, 내보내기 (export), 정책, 그리고 지속성을 위해 해당 플랫폼에 의존하게 됩니다.

만약 기본 복사본이 로컬 (locally)에 존재한다면, 당신에게는 영향력 (leverage)이 생깁니다.

여전히 클라우드 모델 (cloud models)을 사용할 수 있습니다.

여전히 호스팅된 AI 도구 (hosted AI tools)를 사용할 수 있습니다.

여전히 기기 간 동기화 (sync)를 할 수 있습니다.

하지만 메모리 그 자체가 특정 벤더 (vendor) 시스템 안에 갇힌 채 태어나지는 않습니다.

개발자들에게 이 개념은 익숙하게 느껴질 것입니다. 이는 클라우드 서비스 (cloud service)를 사용하는 것과, 당신의 핵심 프로젝트 상태 (core project state)가 그 클라우드 서비스 안에 갇혀 있는 것의 차이와 같습니다.

이 둘은 같은 것이 아닙니다.

*어려운 부분은 저장이 아닙니다
*
Deja Vu를 단순히 "메모리를 SQLite에 넣는 것"으로 오해하기 쉽습니다.

그것은 일부에 해당하지만, 어려운 부분이 아닙니다.

어려운 부분은 무엇을 메모리로 만들 것인지 결정하는 것입니다.

좋은 메모리는 선택적이어야 합니다. 지속적인 사실 (durable facts)과 일시적인 지침 (temporary instructions)을 구분해야 합니다. 동일한 선호도를 열 가지 다른 방식으로 중복하는 것을 피해야 합니다. 무언가 변경되면 업데이트해야 합니다. 오래된 가설 (stale assumptions)을 보존하는 것을 피해야 합니다. 모델에 과부하를 주지 않으면서 적절한 시점에 적절한 컨텍스트 (context)를 검색해야 합니다.

나쁜 메모리는 메모리가 없는 것보다 더 나쁩니다.

시스템이 너무 공격적으로 기억하면, 기분 나쁘고(creepy) 소음이 심해집니다. 너무 적게 기억하면 쓸모가 없습니다. 오래된 정보를 기억하면 오류를 생성합니다. 무엇을 기억하는지 숨기면 신뢰하기 어려워집니다.

따라서 설계는 보수적이어야 합니다.

Deja Vu는 메모리가 유용하고, 검사 가능하며 (inspectable), 제어 가능해야 (controllable) 한다는 아이디어를 중심으로 구축되었습니다.

좋은 메모리 레이어 (memory layer)는 사용자가 다음 질문에 답할 수 있도록 도와야 합니다:

무엇이 저장되었는가?

왜 저장되었는가?

어디에 저장되어 있는가?

내가 수정할 수 있는가?

내가 삭제할 수 있는가?

다른 도구가 접근할 수 있는가?

그것이 여전히 사실인가?

이것이 인프라로서의 메모리와 블랙박스 (black-box) 제품 기능으로서의 메모리의 차이입니다.

*간단한 예시
*
당신이 TypeScript 프로젝트를 작업하고 있다고 가정해 봅시다.

시간이 흐르면서, 당신의 AI 도구들은 몇 가지 사항을 학습합니다:

당신은 최소한의 의존성 (minimal dependencies)을 선호합니다.

당신은 PostgreSQL을 사용합니다.

당신은 Prisma를 사용합니다.

당신은 엄격한 TypeScript (strict TypeScript)를 원합니다.

당신은 클래스 중심의 패턴 (class-heavy patterns)보다 함수형 유틸리티 (functional utilities)를 선호합니다.

당신은 요청하지 않는 한 생성된 코드 (generated code)를 원하지 않습니다.

당신의 인증 흐름 (auth flow)에는 아직 변경할 수 없는 레거시 제약 사항 (legacy constraint)이 있습니다.

당신의 배포 대상 (deployment target)은 Railway입니다.

당신은 이미 콜드 스타트 (cold starts) 문제가 있었기 때문에 서버리스 아키텍처 (serverless architecture)를 거부했습니다.

이러한 컨텍스트 (context)는 끊임없이 중요합니다.

하지만 이 정보들은 아마도 여러 채팅, 에디터 세션, 문서, 그리고 당신의 개인적인 기억 속에 흩어져 있을 것입니다.

공유 메모리 레이어 (shared memory layer)가 있다면, 코딩 어시스턴트가 매번 이 모든 것을 다시 찾아낼 필요가 없습니다. 구현 방법을 제안하기 전에 관련 사실들을 검색할 수 있습니다.

그렇다고 해서 모델이 마법처럼 정확해지는 것은 아닙니다.

하지만 당신이 다음과 같이 말해야 하는 횟수를 줄여줍니다:

"아니요, 기억하세요, 우리는 그런 방식으로 하지 않습니다."

그것이 실질적인 가치입니다.

철학적인 가치는 더 큽니다:

컨텍스트 (context)는 어시스턴트의 것이 아니라, 바로 당신의 것입니다.