많은 에이전트 코드에는 하나의 조용한 가정이 깔려 있습니다. 바로 컨텍스트 윈도우(Context Window)가 더 크다는 것이 더 나은 메모리를 의미한다는 것입니다. 벤더(Vendors)들은 200K, 1M, 그리고 2M 토큰 윈도우를 출시하며, "모든 것을 그냥 집어넣기만 하면 모델이 기억할 것이다"라는 암묵적인 약속을 내겁니다. 몇 주 동안 실행되는 에이전트들을 구축해 본 결과, 저는 이것이 서로 다른 두 가지를 혼동하고 있다는 결론에 도달했습니다. 그리고 이 둘을 동일하게 취급하는 것이 바로 장기 실행 에이전트들이 시간이 지남에 따라 점점 더 멍청해지는 정확한 이유입니다.

컨텍스트 윈도우(Context Window)는 작업 기억(Working Memory)입니다. 진짜 메모리는 윈도우가 사라졌을 때 살아남는 것입니다. 이 둘을 혼동하는 것은 당신의 책상과 서류 보관함을 혼동하는 것과 같습니다.

두 개의 서로 다른 시계

작업 기억(Working Memory, 컨텍스트 윈도우)은 한 세션, 어쩌면 단 한 번의 턴(Turn) 동안만 존재합니다. 그것은 빠르고, 비용이 많이 들며, 휘발성(Volatile)입니다. 바로 '지금' 추론(Reasoning)이 일어나는 곳입니다.

지속 가능한 메모리(Durable Memory)는 세션 전반에 걸쳐 존재합니다. 그것은 느리고, 저렴하며, 영구적(Persistent)입니다. 그것은 에이전트가 빈 윈도우를 가진 채 내일 깨어났을 때 알고 있는 정보입니다.

이들은 수명, 비용, 그리고 액세스 패턴(Access Patterns)이 서로 다릅니다. 하나가 다른 하나의 역할을 수행하도록 시도하는 순간, 문제가 발생합니다:

• 윈도우를 메모리로 사용하면 → 당신이 "기억"하는 모든 것을 매 턴마다 다시 불러와야 하며, 매 턴마다 비용을 지불해야 하고, 세션이 종료되는 즉시 사라집니다.
• 지속 가능한 저장소(Durable Storage)를 작업 기억으로 사용하면 → 단 30초 동안만 유효한 것들을 위해 추론(Reasoning) 도중에 파일을 읽고 쓰게 됩니다.

훌륭한 에이전트는 의도적으로 이 둘을 분리하여 유지합니다.

왜 "그냥 더 큰 윈도우를 사용하라"는 방식이 실패하는가

당신에게 1M 토큰 윈도우가 있고 전체 이력을 그 안에 채워 넣는다고 가정해 봅시다. 세 가지 문제가 나타나며, 이 중 어느 것도 숫자가 커진다고 해결되지 않습니다:

1. 비용은 세션 전체가 아닌 매 턴마다 발생합니다. 1M 토큰이 한 번에 지불되는 것이 아닙니다. 다중 턴(multi-turn) 작업의 각 단계에서 재전송됩니다. 20단계 작업이라면, 대부분 동일한 오래된 이력을 다시 읽는 것만으로 청구서가 20배가 될 수 있습니다.
2. 어텐션이 희석됩니다. '중간에 묻히기(Lost in the middle)' 현상은 실제로 존재합니다: 모델은 긴 컨텍스트의 시작과 끝 부분에 가장 신뢰성 있게 어텐션을 기울입니다. 중요한 한 가지 사실을 900K 토큰 분량의 대본 속에 묻으면, 기술적으로는 '컨텍스트 안에' 있음에도 불구하고 회상 품질이 떨어집니다.
3. 여전히 영속적이지 않습니다. 세션을 종료하면, 백만 토큰 창은 증발합니다. 내일의 에이전트는 공백 상태로 시작합니다. 큰 창은 메모리가 아니라 큰 책상입니다.

더 큰 창은 _단일 긴 세션(single long session)_을 더 유능하게 만듭니다. 그것들은 사람들이 실제로 '메모리'라고 의미하는 _세션 간의 연속성(continuity across sessions)_에는 아무런 도움이 되지 않습니다.

작동하는 분할 방식

창(window)은 임시 작업 공간으로 취급하고, 작고 선별된 별도의 영구 저장소(durable store)를 유지합니다:

• 영구 저장소 (Durable store) (일반 Markdown 파일의 경우): 신원(identity), 선호도(preferences), 결정 사항(decisions), 세션이 지나도 살아남아야 하는 소수의 사실들. 읽기 쉬울 만큼 작습니다. 이것이 서류 캐비닛입니다.
• 작업 컨텍스트 (Working context) (창): 이 작업에 지금 필요한 것만 — 현재 목표, 관련 검색된 사실(fetched facts), 즉각적인 대본. 이것이 책상입니다.

이 둘 사이의 다리 역할을 하는 것은 두 가지 저렴한 연산입니다:

• 로드(Load): 세션 시작 시, 알고 있는 것들의 한 줄짜리 _인덱스(index)_를 창으로 가져옵니다. 전체 저장소를 가져오는 것이 아닙니다. 그런 다음 작업이 실제로 필요할 때 특정 항목을 요청하여 가져옵니다.
• 영속화(Persist): 세션 도중에 영구적으로 학습된 무언가가 있다면, 창이 기억하지 못하고 사라지기 전에 지금 저장소에 기록합니다.

이것이 바로 30K 토큰 창을 가진 에이전트가 체계적인 저장소를 갖추고 있을 때, 단순히 이력을 쏟아내는 1M 토큰 창의 에이전트를 능가할 수 있는 이유입니다. 작은 쪽은 무엇을 보존하고 어디에 둘지 알고 있습니다. 큰 쪽은 어텐션이 알아서 정리해주기를 바랄 뿐입니다.

구체적인 테스트 사례

작업 메모리(working memory)와 실제 메모리(real memory)를 구분하는 질문은 다음과 같습니다: 만약 지금 당장 세션이 충돌하여 빈 윈도우(window)로 재시작된다면, 에이전트는 무엇을 여전히 알고 있을까요?

그 답변이 무엇이든 — 그것이 당신의 실제 메모리입니다. 그 외의 모든 것은 세션이 아직 종료되지 않았기 때문에 메모리처럼 느껴졌을 뿐인 작업 컨텍스트(working context)였습니다. 만약 솔직한 답변이 "아무것도 없다"라면, 당신은 메모리 시스템을 가진 것이 아니라, 그저 큰 윈도우와 낙관적인 가정을 가지고 있는 것입니다.

해결책은 더 큰 윈도우를 만드는 것이 아닙니다. 무엇이 임시 공간(scratch space)에서 기록된 무언가로 넘어갈지를 명시적으로 결정하는 것입니다.

왜 다시 파일인가

내구성이 있는(durable) 측면을 위해 저는 벡터 DB(vector DB)가 아닌 일반 마크다운(Markdown)을 사용합니다. 제가 블랙박스(black box)에 쿼리를 날리는 것보다 서류 캐비닛을 읽는 것을 선호하는 것과 같은 이유입니다. 마크다운은 열어볼 수 있고, grep할 수 있으며, diff를 통해 에이전트가 내일 정확히 무엇을 알게 될지 확인할 수 있습니다. 윈도우는 설계상 일시적(ephemeral)입니다. 저장소(store)는 그 반대여야 합니다 — 즉, 읽기 쉽고 안정적이어야 합니다. 작업이 다르면 도구도 달라야 합니다.

요점 (Takeaway)

컨텍스트 윈도우(context window)는 책상과 같습니다. 넓으면 좋지만, 매일 밤 깨끗이 치워집니다. 메모리는 서류 캐비닛입니다. 더 작고 느리지만, 아침이 되어도 여전히 그 자리에 남아 있는 유일한 것입니다. 이 둘을 혼동하면 세션조차 버티지 못하는 기록을 다시 읽기 위해 계속 비용을 지불하게 될 것입니다. 이 둘을 분리하십시오 — 윈도우에는 임시 공간(scratch space)을, 디스크에는 작고 큐레이션된 저장소(curated store)를 두십시오. 그러면 연속성(continuity)은 토큰 수(token-count)의 문제가 아니라, _무엇을 기록할 것인가_의 문제로 변하며, 이것이야말로 해결할 가치가 있는 문제입니다.

저는 이 내구성 있는 측면 — 파일 레이아웃, 에이전트가 스스로 적용하는 로드/지속(load/persist) 규칙, 그리고 작고 읽기 쉬운 저장소가 실제로 어떻게 작동하는지 볼 수 있는 완전한 작업 예시 에이전트 — 을 바로 사용할 수 있는 키트(drop-in kit)로 패키징했습니다. 직접 구성하는 것보다 작동하는 설정을 복사하는 것을 선호하신다면: AI Soul Kit (Core ¥980 / Plus ¥3,800).

하지만 중요한 것은 책상과 캐비닛을 분리하는 개념입니다. 이 아이디어를 가져가십시오.