AI 에이전트를 장기간 운용하다 보면, "똑똑한데 대화가 바뀌면 전제 조건이 매번 리셋된다"라는 벽에 부딪힙니다. 원인은 기억을 구현하지 않았기 때문입니다. 이 기사는 영구 기억을 최소 구성으로 구현하는 절차와 운용 시 빠지기 쉬운 함정 및 체크리스트를 코드 중심으로 정리합니다.

설계 사상의 배경은 별도의 기사로 나누었습니다. 여기서는 실제로 구현을 진행하는 측면에 집중합니다.

• 기억을 확도(Certainty)에 따라 3계층으로 구분:
  tentative (가칭) / confirmed (확정) / working (실동) - 흐름은 3단계:
  저장(Save) → 승격/강등(Promotion/Demotion) → 회상(Recall)

이것만 지켜도 단순하게 "모두 쌓아서 모두 밀어넣는" 구현 방식의 파탄(토큰 폭발, 오래된 전제의 혼입, 문맥 오인)을 피할 수 있습니다.

1. 기억 = 1사실. scope (용도 경계)와 tier (확도)를 반드시 갖게 합니다.

type MemoryTier = "tentative" | "confirmed" | "working";
interface MemoryRecord {
  id: string;
  ...
}

DB는 Postgres + pgvector를 사용해도 되고, SQLite + 자체 코사인 유사도(Cosine Similarity)를 사용해도 상관없습니다. 처음에는 scope/tier/embedding 세 가지만 뽑을 수 있으면 충분합니다.

2. 대화가 끝날 때 요점을 추출하여, 기본값인 tentative로 기록합니다. 여기서 바로 confirmed로 만들지 않는 것이 사고 방지의 핵심입니다.

async function capture(turn: ConversationTurn) {
  const facts = await extractSalientFacts(turn); // LLM으로 요점 추출
  for (const f of facts) {
    ...
  }
}

3. 반복적으로 확인된 기억만 confirmed로 승격합니다. 모순되는 것은 강등합니다. 강등(Demotion) 처리를 넣지 않으면 오래된 지도만 보고 계속 달리게 됩니다.

async function reconcile(memo: MemoryRecord, incoming: Fact) {
  if (semanticallyEqual(memo, incoming)) {
    memo.evidenceCount++;
    ...
  }
}

대화의 레이턴시(Latency)에 영향을 주지 않도록, 낮은 빈도의 배치(Batch, cron 등)로 돌리는 것이 요령입니다.

4. 다음 대화에서 필요한 만큼만 주입합니다. 전체를 넣지 않습니다.

async function recall(query: string, scope: string, tokenBudget: number) {
  const hits = await db.search({
    scope, // 경계를 넘지 않음
    ...
  });
}

회상의 3원칙: scope를 넘지 않는다 / tier로 압축한다 / 토큰 예산(Token Budget)으로 끊는다.

5. 기억을 모델 외부로 빼내어, memory_save / memory_recall을 MCP 툴로서 공개하면, 어떤 에이전트나 어떤 모델에서도 동일한 기억을 사용할 수 있습니다.

{
  "tools": [
    { "name": "memory_save", "description": "사실을 저장 (기본 tier=tentative)" },
    ...
  ]
}

외부에 두는 이점: 이식성(Portability) (모델 교체 시에도 기억을 잃지 않음) / 공유(Sharing) (복수의 에이전트 및 팀) / 소유(Ownership) (보이고, 수정할 수 있고, 가져올 수 있음).

체크리스트

• 기억 1개 = 1사실인가?
• scope와 tier를 필수 항목으로 했는가?
• 저장은 기본 tentative인가? 갑자기 confirmed로 만들고 있지는 않은가?
• evidenceCount로 승격하고, 모순 감지로 강등을 구현했는가?
• recall은 scope 제한 + tier 우선 + 토큰 예산으로 제한하는가?
• 회상은 관련 검색(Embedding)을 통해 필요한 만큼만 수행하는가?
• 승격 및 압축 처리를 저빈도 배치로 분리했는가?
• 다른 용도의 기억이 섞이지 않았는가? (scope 구분 방식 점검)

기억은 "쌓는 것"이 아니라 "정리해서 꺼내는 것"입니다. 3계층으로 확도를 나누고, 저장 → 승격/강등 → 회상의 흐름으로 흘려보내며, scope와 토큰 예산으로 범위를 좁힙니다. MCP를 통해 외부로 빼내면 이식성, 공유, 소유권을 얻을 수 있습니다.

모델은 일회용이지만, 기억은 성장하는 자산입니다. 구현의 주전장은 저장이 아니라 **회상(꺼내는 방법)**입니다.

기억 레이어의 설계와 실록은 Agent Memories에서 공개하고 있습니다.