AI 에이전트에 영구 기억을 부여하는 설계: 가설·확정·실행의 3계층

AI 에이전트를 장기간 운용하다 보면 벽에 부딪히는 경우가 있습니다. 똑똑한 모델을 사용하고 있음에도 불구하고, 대화가 바뀌면 전제 조건이 매번 리셋되어 판단의 무게감만 남게 됩니다. 이는 '기억(Memory)'을 설계하지 않았기 때문입니다.

이 기사에서는 AI 에이전트에 영구 기억을 부여하기 위한 구현 설계를 가설(tentative)·확정(confirmed)·실행(working)의 3계층과 저장(capture)·승격(promote)·소환(recall)의 3단계 파이프라인으로 정리합니다. 여러 AI를 실제 운용하는 과정에서 정립된 설계를 기반으로 하고 있습니다.

왜 '대화 이력'만으로는 부족한가

먼저, 혼동하기 쉬운 두 가지를 구분하겠습니다.

대화 이력 (Context): 현재 열려 있는 스레드의 흐름. 모델이 그대로 읽음. 윈도우(Window)를 벗어나면 참조되지 않음. 휘발됨.

기억 (Memory): 이력으로부터 '다음에도 필요할 전제·결정·취향'을 추출하여 외부에 영구화한 것. 대화를 넘나들며 쌓임.

이력을 그대로 전부 쌓아두고 매번 밀어넣는 단순한 구현은 금방 파산합니다. 토큰(Token)이 팽창하고, 오래된 전제와 새로운 전제가 뒤섞이며, 관련 없는 문맥이 판단에 섞여 들어갑니다. 필요한 것은 '전부 기억하는 것'이 아니라, 무엇을 남기고, 무엇을 믿고 움직이며, 언제 꺼낼 것인가에 대한 설계입니다.

기억의 3계층 모델: 가설·확정·실행

기억을 평면적인 창고로 두지 않고, 확신도에 따라 계층을 나눕니다. 인간도 '일단 들은 이야기'와 '확신한 사실'을 무의식적으로 구분합니다.

계층	역할	판단에 대한 사용
`tentative` (가설)	방금 들어온 정보. 미검증.	사용하지 않음 (참고만 함)
`confirmed` (확정)	반복적으로 확인된 전제·결정.	판단의 토대로 사용
`working` (실행)	현재 태스크에 직접적으로 작용.	즉시 최우선으로 참조

포인트는 새로 들어온 정보가 갑자기 판단을 덮어쓰지 않게 하는 것입니다. 단 한 번의 발언으로 확정된 전제가 뒤집히는 사고를 방지할 수 있습니다.

스키마의 최소 형태는 다음과 같은 이미지입니다.

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

type은 기억의 성질입니다. episodic (언제 무엇이 일어났는지), semantic (확립된 사실·전제), procedural (절차). 이 세 가지가 갖춰지면 에이전트는 "그것과 같은 패턴이네요"라며 과거를 바탕으로 한 판단을 할 수 있습니다.

저장·승격·소환의 3단계 파이프라인

기억을 기능하게 하는 흐름은 3단계입니다.

1. 저장 (capture)

대화가 끝날 때, 남길 가치가 있는 전제·결정·실패를 추출하여 tentative로 기록합니다. 여기서 전부를 confirmed로 만들지 않는 것이 핵심입니다.

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

2. 승격·강등 (promote / demote)

반복적으로 등장하여 확실하다고 판명된 것만 confirmed로 올립니다. 반대로, 새로운 사실과 모순되는 확정 전제는 tentative나 과거 로그로 내립니다. 올리는 것뿐만 아니라 내리는 것이 기억을 낡은 지도처럼 만들지 않는 비결입니다.

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

저빈도 배치(cron 등)로 돌리면 대화의 레이턴시(Latency)에 영향을 주지 않습니다.

3. 소환 (recall)

다음 대화에서, 지금 필요한 기억만 추출하여 문맥에 주입합니다. 전부를 매번 넣지 않습니다. 이 부분이 설계의 실력을 보여주는 대목이며, 양보다 '꺼내는 방법'에서 차이가 납니다.

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

소환의 3원칙:

scope를 넘지 않음: 다른 용도나 다른 프로젝트의 기억을 섞지 않음.
tier로 필터링: 판단 시에는 confirmed / working을 사용하며, tentative는 기본적으로 포함하지 않음.
토큰 예산 내에서 중단: 관련도 상위 항목부터 예산 범위 내에서 채움. "전부 넣기"를 지양함.

MCP로 기억 레이어를 분리하기

이 기억을 모델 내부가 아닌 **외부의 독립된 레이어 (Layer)**에 두면 효과적입니다. MCP (Model Context Protocol) 서버로서 memory.save / memory.recall을 공개하면, 어떤 에이전트나 어떤 모델에서도 동일한 기억을 읽고 쓸 수 있습니다.

// MCP 도구 예시 (개념)
{
"tools": [
...

외부에 두었을 때의 장점은 3가지입니다.

이식성 (Portability): 모델을 교체해도 기억은 그대로 유지됩니다. 모델 교체가 "다시 키우기"가 아닌 "연결 갈아끼우기"가 됩니다.
공유 (Sharing): 여러 에이전트나 팀이 하나의 기억을 공유할 수 있어, 특정 개인에게 종속되는 현상이 줄어듭니다.
소유 (Ownership): 내용을 볼 수 있고, 수정할 수 있으며, 가지고 나올 수 있습니다. 자신의 자산으로 다룰 수 있습니다.

흔히 빠지는 함정

전부 confirmed로 설정: 검증 없이 판단에 사용하여, 단 한 번의 발언으로 전제가 무너짐. → 가설 단계를 거치게 함.
scope를 나누지 않음: 다른 문맥의 기억이 섞여 판단이 흔들림. → 저장 시 반드시 scope를 부여함.
recall 시 전체 데이터 주입: 토큰 폭발과 정확도 저하 발생. → 관련도 + 예산 범위 내에서 중단함.
강등 (Demotion) 미구현: 오래된 전제를 바탕으로 계속 실행됨. → 모순 감지를 통해 강등시킴.

구현 체크리스트

기억은 1 레코드 = 1 사실로 구성.
scope와 tier를 반드시 포함.
저장은 기본적으로 tentative로 수행. 승격은 evidenceCount로 판정.
모순 감지를 통한 강등 구현.
recall은 scope 제한 + tier 우선 + 토큰 예산 내 중단.
회상은 관련 검색 (Embedding)을 통해 필요한 것만 수행.
승격 및 압축은 저빈도 배치 (Batch) 작업으로 분리.

요약

AI 에이전트의 기억은 쌓아두는 대상이 아니라 정리해서 꺼내 쓰는 대상입니다. 가설(Tentative)·확정(Confirmed)·실행(Working)으로 확신도를 나누고, 저장·승격·회상의 흐름을 만들며, scope와 토큰 예산으로 추출 범위를 좁힙니다. 그리고 기억을 모델 외부에 두면 이식성, 공유, 소유권을 얻을 수 있습니다.

모델은 일회용이지만, 기억은 성장하는 자산입니다. 어느 쪽에 설계 시간을 투자하느냐에 따라 에이전트의 수명이 달라집니다.

기억 레이어의 설계와 실전 기록은 에이전트 메모리즈 (Agent Memories)에서 지속적으로 공개하고 있습니다.