LLM과 함께 일한 지 오래될수록, 저는 충분한 컨텍스트, 과도한 컨텍스트, 토큰 낭비, 그리고 압축이라는 전쟁 사이에서 영원히 싸우고 있는 자신을 발견하게 됩니다. 에이전트 메모리 시스템을 살펴보면, 이 싸움에 도움이 될 강력한 무기들이 있다는 것을 알 수 있습니다.
제가 살펴본 19개 시스템에서 계속해서 드러나는 발견은, 더 큰 윈도우가 예산 문제를 해결하기보다는 오히려 악화시킨다는 점입니다. 200K-토큰 윈도우가 모든 200K 토큰에 동등한 주의를 기울이지 않습니다. 윈도우가 가득 차기 훨씬 전에 성능이 저하됩니다. 성능 저하는 균일하지 않습니다: 긴 컨텍스트의 중간에 있는 자료는 가장자리에 있는 자료보다 확실히 덜 집중됩니다. 그리고 에이전트의 실제 작업은 윈도우 크기에 관계없이 고정된 윈도우 조각을 차지하므로, 그 외의 모든 것은 동일한 주의 예산을 두고 경쟁하는 오버헤드가 됩니다.
이를 잘 처리하는 시스템들은 여섯 가지 메커니즘으로 수렴했습니다. 그중 어떤 것도 특별하지 않습니다. 몇몇은 부끄러울 정도로 단순합니다. 하지만 이러한 메커니즘을 건너뛴 시스템은 그 대가를 치릅니다.
여섯 가지 메커니즘
압축 패스 (Compaction passes)
가장 눈에 띄는 메커니즘입니다. 긴 대화나 큰 메모리 세그먼트를 가져와 요약하고, 원본을 요약본으로 대체합니다. MemoryOS는 이를 세그먼트 수준에서 수행합니다. 대화 세그먼트가 임계값을 넘어 성장하면 세그먼트 요약기가 실행되어 작업 컨텍스트를 압도하기 전에 압축된 표현으로 축소합니다. Karpathy-패턴 위키(purpose.md, overview.md)는 지식 수준에서 이와 유사한 버전을 수행합니다. 위키는 에이전트가 특정 주제에 대해 학습한 모든 것을 세션에 걸쳐 유지 관리하는 압축된 형태입니다.
절충점은 정보 손실입니다. 압축은 정의상 손실이 있는 연산입니다. 요약본은 압축 당시 요약기가 관련 있다고 판단한 내용을 포착합니다. 나중에 에이전트가 관련 없다고 판단된 세부 정보가 필요하면, 그 정보는 사라집니다. 이것이 압축을 피해야 하는 이유는 아니지만, 유일한 메커니즘으로 취급하지 말아야 하는 이유입니다.
놓치기 쉬운 두 번째 비용이 있습니다. 압축은 런타임에 무료가 아닙니다. MemoryOS는 세그먼트 요약을 유지 관리하기 위해 단일 상호작용에서 20회 이상의 LLM 호출을 지불할 수 있습니다. 상호작용 빈도가 높은 시스템의 경우, 이는 실질적인 운영 비용입니다.
결과 미리보기 자르기 (Result-preview truncation)
모든 검색에서 전체 메모리 콘텐츠를 반환하는 대신, 짧은 미리보기를 반환하고 에이전트가 전체 레코드를 가져올지 결정하도록 합니다. supermemory는 호출자가 결과당 반환되는 텍스트 양을 조정할 수 있는 스니펫 길이 컨트롤을 제공합니다. mem9는 한 걸음 더 나아갑니다: 소스 턴을 세 가지 환경 변수(MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT)로 장식하여 운영자가 표시할 소스 턴의 수와 최소 관련성 점수를 정밀하게 제어할 수 있도록 합니다.
절충점은 추가 도구 호출입니다. 에이전트가 전체 콘텐츠가 필요하면 명시적으로 요청해야 합니다. 대부분의 검색 패턴에서 이는 올바른 절충점입니다. 에이전트는 전체를 읽는 토큰 비용을 지불하기 전에 레코드가 관련 있는지 판단할 수 있는 충분한 신호를 얻습니다.
2단계 검색 (Two-step retrieval)
미리보기 자르기의 특별하고 중요한 변형입니다. 검색은 식별자와 짧은 미리보기를 반환합니다. 별도의 GetByID 호출이 필요할 때 전체 레코드를 가져옵니다. mem9의 MemoryRepo 인터페이스는 이 패턴을 기반으로 구축되었습니다. 검색과 가져오기는 별개의 토큰 풋프린트를 가진 별개의 작업입니다.
숫자가 이를 명확하게 증명합니다. 각각 1,500 토큰인 10개의 일치 항목은 에이전트가 사용하든 사용하지 않든 15,000 토큰이 컨텍스트에 주입됩니다. 2단계 검색은 총 약 450 토큰으로 10개의 식별자와 짧은 미리보기를 반환한 다음, 에이전트가 실제로 필요한 레코드만 가져옵니다. 세션에서 20회의 리콜 단계에 걸쳐 이 차이는 약 200,000 토큰 절약으로 누적됩니다.
이는 채택할 수 있는 가장 저렴한 규율입니다. 메모리 저장소에 대한 아키텍처 변경, 추가 LLM 호출, 정보 손실이 필요하지 않습니다. 이는 검색 인터페이스 결정입니다.
분해 후 리콜 (Decompose-then-recall)
전체 사용자 쿼리를 검색 계층에 보내는 대신 먼저 하위 쿼리로 분해합니다. SimpleMem의 의도 인식 검색 플래너는 메모리 저장소에 도달하기 전에 들어오는 쿼리를 원자적 검색 의도로 분할합니다. GitNexus는 쿼리 도구 분해를 통해 유사한 작업을 수행합니다. 복잡한 쿼리는 대상 하위 쿼리로 분할되며, 각 하위 쿼리는 메모리 그래프의 집중된 조각을 검색합니다.
이점은 정밀도입니다. 분해된 쿼리는 관련 없는 자료를 덜 검색하므로 컨텍스트의 노이즈가 줄어듭니다. 절충점은 지연 시간입니다. 분해는 검색이 시작되기 전에 계획 단계를 추가합니다. 인터랙티브 에이전트의 경우 이는 중요합니다. 배치 또는 백그라운드 에이전트의 경우 일반적으로 그렇지 않습니다.
계층형 저장소를 예산 필터로 사용 (Tiered storage as budget filter)
이미 계층형 메모리 아키텍처(지난주 글의 주제)를 구축했다면, 부작용으로 예산 필터링 효과를 얻을 수 있습니다. supermemory의 3계층 모델은 자주 액세스되는 핫 자료가 압축되고 신호가 강한 결과를 반환하는 계층에 상주함을 의미합니다. 콜드 자료는 기본적으로 쿼리되지 않는 계층에 있습니다. Hindsight의 관찰 계층도 같은 방식으로 작동합니다. 원시 관찰은 컨텍스트에 직접 주입되지 않습니다. 검색 후보가 되기 전에 상위 계층으로 승격됩니다.
절충점은 리콜 완전성입니다. 승격되지 않은 자료는 관련성이 있더라도 표준 검색 패스에서 표면화되지 않을 수 있습니다. 이는 압축과 동일한 절충점이지만, 실패 모드는 다릅니다. 요약을 통한 정보 손실 대신 강등을 통한 정보 손실이 발생합니다.
자기 안내 도구 응답 (Self-guiding tool responses)
가장 덜 논의된 메커니즘이며, 더 흥미로운 것 중 하나입니다. 도구 호출 후 에이전트가 무엇을 할지 결정하도록 두는 대신, 도구 응답 자체에 다음에 무엇을 할지에 대한 힌트가 포함됩니다. GitNexus는 도구 응답에 ---
**Next:** 블록을 추가하여 후속 조치를 제안합니다. mem9는 소스 턴을 에이전트의 다음 검색 단계를 안내하는 구조화된 메타데이터로 장식합니다.
효과는 에이전트가 도구 호출 사이의 계획에 더 적은 토큰을 소비한다는 것입니다. 도구 응답은 다음 단계를 명확하게 만드는 충분한 구조를 전달합니다. 절충점은 프롬프트 엔지니어링 노력입니다. 좋은 자기 안내 응답을 작성하려면 에이전트가 다음에 무엇을 필요로 할지 미리 아는 것이 필요하며, 이것이 항상 가능한 것은 아닙니다.
Tolaria 한계 사례
Tolaria는 예산 규율을 극단으로 밀어붙인 논리적 종착점을 나타내기 때문에 별도로 살펴볼 가치가 있습니다. ADR-0009는 시스템에서 임베딩을 완전히 제거하기로 한 결정을 문서화합니다. Tolaria는 부분 문자열 검색만 사용합니다. 벡터 인덱스, 의미 검색, 임베딩 호출이 없습니다.
그 근거는 직접적입니다. 가장 저렴한 토큰은 처음부터 검색하지 않는 토큰입니다. 임베딩 기반 검색은 의미적으로 유사한 결과를 반환하므로, 에이전트가 명시적으로 요청하지 않은 결과를 반환합니다. 그중 일부는 유용합니다. 대부분은 그렇지 않습니다. 모든 것이 토큰 비용을 발생시킵니다.
Tolaria의 입장은 관련 없지만 유사한 결과의 비용이 세션에 걸쳐 누적될 때, 해당 사용 사례에 대한 의미 리콜의 이점을 초과한다는 것입니다. 이 절충점이 시스템에 적용되는지 여부는 시스템의 목적에 따라 다릅니다. 쿼리가 정확하고 구조화된 시스템(코드 탐색, 식별자별 문서 조회)의 경우 Tolaria의 입장은 방어 가능합니다. 쿼리가 모호하고 탐색적인 시스템의 경우 임베딩을 제거하면 복구하기 어려운 방식으로 리콜이 손상됩니다.
Tolaria 사례의 가치는 이를 복사해야 한다는 것이 아닙니다. 대부분의 시스템이 하지 않는 방식으로 의미 검색의 비용을 가시화한다는 점입니다.
압축 전용 시스템에 대한 반론
19개 시스템 중 여러 시스템은 압축을 주요 또는 유일한 예산 메커니즘으로 사용합니다. 실패 모드를 언급할 가치가 있습니다.
첫째, 요약은 압축 당시 관련성이 없다고 판단되었지만 나중에 관련성이 생기는 세부 정보를 잃게 됩니다. 이는 가상의 문제가 아닙니다. 미래의 관련성을 알 수 없는 정보에 적용되는 모든 손실 압축 방식의 표준 실패 모드입니다.
둘째, 압축은 핫패스 비용입니다. MemoryOS가 상호작용당 20회 이상의 LLM 호출을 지불하는 것은 압축 중심 시스템에서 드문 일이 아닙니다. 규모가 커지면 이 비용은 무시할 수 없습니다.
셋째, 가장 미묘한 점은, 탈출구 없는 압축은 느린 망각이라는 점입니다. 컨텍스트 크기를 줄이는 유일한 방법이 요약이고 요약이 손실이 있다면, 시스템은 복구 방법 없이 지속적으로 정보를 폐기하는 것입니다. 2단계 검색, 계층형 저장소, 결과 미리보기 자르기는 모두 원래 레코드를 보존합니다. 압축은 그렇지 않습니다.
이 모든 것이 압축이 틀렸다는 것을 의미하지는 않습니다. 압축만으로는 충분하지 않다는 것을 의미합니다.
최신성 가중치와 영구 큐 (Recency weighting and the persistent queue)
위의 여섯 가지 범주에 깔끔하게 맞지 않는 두 가지 메커니즘을 언급할 가치가 있습니다.
graymatter는 최신성에 절반 가중치를 적용한 RRF 융합을 사용합니다. 이는 엄밀한 의미의 예산 메커니즘은 아니지만, 그렇게 기능합니다. 검색 순위에서 오래된 자료의 가중치를 낮춤으로써, 오래되고 신호가 약한 레코드가 최근의 신호가 강한 레코드를 밀어낼 확률을 줄입니다. 효과는 명시적인 계층 승격보다는 순위 가중치를 통한 소프트 계층화입니다.
llm-wiki의 540라인 수집 큐 상태 머신은 다른 접근 방식을 취합니다. 큐는 수집 작업을 직렬화하고 메모리 저장소에 들어가기 전에 4-신호 관련성 랭커를 적용합니다. 예산 제어는 읽기 시간이 아닌 쓰기 시간에 이루어집니다. 관련성 임계값을 통과하지 못한 자료는 저장되지 않으며, 따라서 검색될 수 없고 컨텍스트를 소비할 수 없습니다. 이는 간접적인 예산 제어이지만, 지속적입니다. 절약 효과는 모든 미래 세션에 걸쳐 누적됩니다.
잘 설계된 시스템들의 공통점
19개 시스템을 살펴보면, 컨텍스트 예산을 잘 처리하는 시스템들은 몇 가지 속성을 공유합니다.
검색을 단일 단계 주입이 아닌 2단계 작업으로 취급합니다. 전체 레코드보다 미리보기를 먼저 반환합니다. 요약본으로 대체하지 않고 원본 레코드를 보존합니다. 하드코딩된 기본값 대신 명시적 매개변수를 통해 운영자에게 검색량 제어권을 제공합니다. 그리고 읽기 시간뿐만 아니라 쓰기 시간에도 예산을 고려합니다.
예산을 잘못 처리하는 시스템들은 일반적으로 단일 메커니즘(주로 압축)에 의존하고, 컨텍스트 윈도우를 관리해야 할 리소스가 아니라 채워야 할 버퍼로 취급하는 경향이 있습니다.
연구의 최종 입장은 간단합니다. 더 큰 윈도우는 더 적은 규율이 아닌, 더 많은 규율을 요구합니다. 윈도우를 채우는 것이 원칙적으로 잘못되었기 때문이 아니라, 잘못된 자료로 채우는 것이 공간을 비워두는 것보다 더 많은 비용이 들기 때문입니다.
다음 글에서는 메모리를 주입에서 도구로 전환하여, 19개 시스템이 컨텍스트에 자동으로 푸시되는 것과 에이전트가 명시적으로 요청해야 하는 것 사이의 경계를 어떻게 처리하는지 다룰 계획입니다.*
언제나 그렇듯, 이 글이 흥미롭거나 유용하다고 생각되거나 지식을 퍼뜨리는 데 도움이 되고 싶다면:
공유 부탁드립니다
