LCM: Lossless Context Management

본 논문은 재귀적 컨텍스트 압축과 작업 분할을 통해 LLM 메모리를 강화하는 결정론적 아키텍처인 손실 없는 컨텍스트 관리 (LCM) 를 소개하며, 이를 통해 볼트 (Volt) 에이전트는 손실 없는 상태 검색 및 종료를 보장하면서 최대 100 만 토큰의 장문 컨텍스트 코딩 작업에서 클로드 코드 (Claude Code) 를 능가합니다.

핵심

거대한 수일 간의 미스터리를 해결하려 한다고 상상해 보세요. 당신은 천재적인 형사 (AI) 를 보유하고 있지만, 그 형사는 매우 단기적인 기억력을 가지고 있습니다. 만약 그에게 1,000 개의 단서 더미를 주면, 마지막 단서에 도달할 때쯤이면 처음 몇 개의 단서는 잊어버리게 됩니다.

오랫동안 해결책은 형사에게 더 큰 수첩 (더 큰 "컨텍스트 윈도우") 을 주는 것이었습니다. 하지만 결국 가장 큰 수첩조차 들고 다니기에 너무 무거워지고, 형사는 방대한 양의 종이 때문에 혼란에 빠지기 시작합니다.

이 논문은 형사를 돕는 새로운 방식을 제시합니다: 손실 없는 컨텍스트 관리 (Lossless Context Management, LCM). 이는 형사에게 직접 파일링 시스템을 작성하도록 요청하는 대신, 메모리를 대신 관리해 주는 초지능 자동화 사서 역할을 부여하는 것과 같습니다.

다음은 간단한 비유를 통해 작동 방식을 설명한 것입니다:

1. 문제: "GOTO" 대 "구조화" 논쟁

이 논문은 메모리를 처리하는 두 가지 방식을 비교합니다:

• 구식 방식 (RLM): 형사에게 코드 자체로 파일링 시스템을 작성하도록 요청한다고 상상해 보세요. 형사는 메모리를 어떻게 조직할지, 언제 무엇을 버릴지, 그리고 나중에 어떻게 찾을지 결정해야 합니다. 이는 프로그래머에게 코드 내 어디든 점프할 수 있는 GOTO 문장을 무제한으로 사용할 자유를 주는 것과 같습니다. 강력하지만, 형사가 파일링 스크립트에서 실수를 하면 전체 시스템이 충돌하거나 엉망이 됩니다.
• 신식 방식 (LCM): 형사에게 파일링 시스템을 작성하게 하는 대신, 엔진 (형사를 구동하는 컴퓨터) 이 미리 구축된 완벽한 파일 캐비닛을 제공합니다. 형사는 단순히 "새로운 단서입니다"라고 말하면, 엔진이 기존 단서를 언제 요약할지 그리고 어디에 저장할지 자동으로 결정합니다. 이는 구조적 프로그래밍 (루프와 if 문) 을 사용하는 것과 같습니다. 덜 유연할 수는 있지만, 나쁜 논리 때문에 결코 충돌하지 않습니다.

2. LCM 의 두 가지 마법 도구

이 논문은 LCM 이 형사의 집중력을 유지하기 위해 사용하는 두 가지 주요 트릭을 설명합니다:

A. "손실 없는" 파일 캐비닛 (계층적 DAG)

• 작동 방식: 엔진은secure 금고 (불변 저장소, Immutable Store) 에 모든 메모리, 단어 단위로 "마스터 복사본"을 보관합니다.
• 요약: 형사의 활성 작업 공간을 절약하기 위해 엔진은 기존 메모리에 대한 "요약 카드"를 생성합니다. 요약 카드는 작업 공간에 두고 전체 메모리는 금고에 숨깁니다.
• 마법: 형사가 나중에 원래 메모리를 확인해야 할 경우 요청하면, 엔진은 즉시 요약 카드를 전체 메모리로 교체합니다. 아무것도 실제로 손실되지 않으며, 필요할 때까지 압축될 뿐입니다.
• 비유: 500 페이지 분량의 책을 읽는다고 상상해 보세요. 책 전체를 들고 다니는 대신, 각 장의 한 줄 요약이 적힌 책갈피를 들고 다닙니다. 세부 사항을 확인해야 할 때 책의 특정 페이지로 돌아가면 됩니다. 원래 텍스트는 결코 잃지 않습니다.

B. "병렬" 팀 (LLM-Map)

• 문제: 형사가 1,000 개의 파일을 하나씩 읽어야 한다면, 마지막 파일에 도달할 때쯤이면 첫 번째 파일을 잊어버리고 지쳐버릴 것입니다.
• 해결책: 형사 자신이 파일을 읽는 대신, 엔진이 16 명의 조수를 고용하는 상사와 같은 역할을 합니다. 형사는 상사에게 단일 지시를 내립니다: "이 1,000 개의 파일을 읽고 각각의 주요 내용을 알려줘." 엔진은 모든 1,000 개의 파일을 동시에 조수들에게 보냅니다.
• 결과: 조수들이 병렬로 중노동을 수행합니다. 형사는 최종적으로 정리된 결과 목록만 봅니다. 형사는 한 번에 1,000 개의 파일을 머릿속에 담아둘 필요가 없습니다.

3. "무비용" 약속

이 논문의 가장 큰 주장 중 하나는 이 시스템이 작은 작업에서는 속도를 늦추지 않는다는 것입니다.

• 비유: 파일할 메모리가 5 개뿐이라면, 엔진은 복잡한 파일링 시스템을 만드는 데 시간을 낭비하지 않습니다. 형사가 직접 읽게 할 뿐입니다. "파일 캐비닛"은 더미가 너무 커질 때만 작동합니다. 이는 일반적이고 짧은 대화에서는 시스템이 표준 AI 와 마찬가지로 빠르게 느껴진다는 것을 의미합니다.

4. 결과: 경쟁사 격파

저자들은 현재 세계 최고의 AI 코딩 어시스턴트 중 하나인 Claude Code와 자신의 시스템 ( Volt 라고 명명됨) 을 테스트했습니다.

• 테스트: 두 시스템 모두 최대 100 만 단어 (토큰) 의 단서가 포함된 거대한 "미스터리"를 부여받았습니다.
• 결과:
  • 작은 단서 (32,000 단어 미만) 의 경우, 두 시스템 모두 비슷한 성능을 보였습니다.
  • 거대한 단서 (32,000 에서 100 만 단어) 의 경우, Volt 가 매번 승리했습니다.
  • 논문은 Volt 가 텍스트 양에 "혼란"을 느끼지 않았기 때문에 거대한 데이터셋에서 올바른 답을 찾는 데 훨씬 더 뛰어났다고 주장합니다. 반면 Claude Code 는 텍스트가 길어질수록 어려움을 겪기 시작했습니다.

5. 왜 이것이 중요한가 (논문에 따르면)

이 논문은 AI 에게 자신의 메모리를 관리하도록 요청하는 것 (구식 방식과 같이) 은 위험하다고 주장합니다. AI 가 자신의 코드에서 실수를 할 수 있기 때문입니다. 메모리 관리를 컴퓨터 엔진 (신식 방식) 으로 이동시킴으로써 시스템은 다음과 같이 됩니다:

1. 더 신뢰할 수 있음: AI 가 나쁜 스크립트를 작성했기 때문에 충돌하지 않습니다.
2. 더 효율적: AI 가 압도당하지 않고 방대한 양의 데이터를 처리합니다.
3. 손실 없음: 정보가 결코 실제로 삭제되지 않고 요약될 뿐임을 보장합니다.

요약하자면, 이 논문은 매우 길고 복잡한 작업의 경우, AI 가 스스로 사서가 되려고 시도하게 하는 대신, 메모리를 처리할 구조화된 자동화 어시스턴트를 제공하는 것이 더 낫다고 제안합니다.

기술 요약

기술 요약: 손실 없는 컨텍스트 관리 (LCM)

문제 정의

복잡하고 장기적인 에이전트 작업의 주요 병목 현상은 여전히 대규모 언어 모델 (LLM) 의 효과적인 컨텍스트 윈도우에 있습니다. 명목상 100 만 토큰을 초과하는 윈도우를 가진 모델조차도, 도구 호출, 파일 내용, 중간 추론의 양이 용량을 초과하는 수일 간의 세션에서는 어려움을 겪습니다. 여기에 "컨텍스트 부패 (context rot)"가 더해져, 하드 토큰 한도에 도달하기 전에 성능이 현저히 저하됩니다.

이전 연구, 특히 재귀적 언어 모델 (RLM) 은 모델이 심볼릭 재귀 (예: 자신의 프롬프트를 청크하고 처리하는 스크립트 작성) 를 통해 스스로 컨텍스트를 능동적으로 관리해야 한다고 제안했습니다. RLM 은 능동적 컨텍스트 관리의 타당성을 입증했지만, 모델의 확률적 성향을 계승합니다. 즉, 하나의 롤아웃에서 작동하는 메모리 전략이 다음 롤아웃에서는 실패할 수 있습니다. 또한, 모든 상호작용을 재귀적 구조로 감싸는 것은 표준 윈도우 내에 맞는 작업에 대해 지연 시간과 비용 ("단순 컨텍스트 페널티") 을 초래합니다. 모델이 생성하는 제어 흐름의 표현력과 생산 시스템에 필요한 신뢰성 사이에는 긴장 관계가 존재합니다.

방법론: 손실 없는 컨텍스트 관리 (LCM)

LCM 은 RLM 의 모델 중심 접근 방식에 대한 결정론적, 아키텍처 중심의 대안을 제안합니다. 모델이 메모리 전략을 고안하도록 요청하는 대신, LCM 은 메모리 아키텍처의 부담을 엔진으로 이전하여 결정론적이고 데이터베이스 기반의 인프라를 제공합니다. 이 시스템은 두 가지 핵심 기둥인 재귀적 컨텍스트 압축과 재귀적 작업 분할에 기반합니다.

1. 이중 상태 메모리 아키텍처

LCM 은 이중 상태 설계를 통해 손실 없는 검색 가능성을 보장합니다:

• 불변 스토어 (The Immutable Store): 모든 사용자 메시지, 어시스턴트 응답, 도구 결과를 원문 그대로 영구적으로 저장하고 절대 수정하지 않는 영구적이고 트랜잭션 기반의 스토어 (예: PostgreSQL) 입니다. 이는 진실의 근원 (source of truth) 입니다.
• 활성 컨텍스트 (The Active Context): 각 턴마다 LLM 에게 전송되는 윈도우로, 최근 원시 메시지와 사전 계산된 요약 노드로 구성됩니다.

요약 노드는 LLM 요약을 통해 이전 메시지들로부터 파생된 물리화된 뷰 (materialized views) 로 작동합니다. 중요하게도, 시스템은 원본 데이터에 대한 "손실 없는 포인터"를 유지합니다. 요약이 불충분한 경우, lcm_expand 도구를 통해 에이전트가 원본 콘텐츠를 원문 그대로 검색할 수 있습니다. 컨텍스트 과부하를 방지하기 위해 lcm_expand 는 하위 작업으로 제한되며, 주요 상호작용 루프는 요약만 관찰합니다.

2. 계층적 DAG 및 제어 루프

핵심 데이터 구조는 요약의 방향성 비순환 그래프 (DAG) 입니다. 활성 컨텍스트가 가득 차면, 원본은 보존된 채로 이전 메시지들이 요약 노드로 압축됩니다.

• 결정론적 제어 루프: 엔진은 소프트 ($\tau_{soft}$) 및 하드 ($\tau_{hard}$) 토큰 임계값을 사용하여 압축을 관리합니다.
• 제로 비용 연속성: $\tau_{soft}$ 미만에서는 요약을 수행하지 않으며, 시스템은 오버헤드가 없는 수동 로거로 작동합니다. 임계값을 초과하면 비동기적으로 압축이 트리거되어 LLM 턴 사이에 요약을 컨텍스트로 교체합니다.
• 3 단계 에스컬레이션: 수렴을 보장하고 "압축 실패"(요약이 입력보다 길어지는 경우) 를 방지하기 위해, LCM 은 엄격한 에스컬레이션 프로토콜을 사용합니다:
  1. 일반: 세부 정보를 보존하는 LLM 요약.
  2. 공격적: 토큰 타겟을 줄인 불릿 포인트 형태의 LLM 요약.
  3. 결정론적 폴백: 고정된 토큰 한도 (예: 512 토큰) 로의 비-LLM 잘라내기.

3. 대용량 파일 처리

컨텍스트 한도를 초과하는 파일 (예: 대규모 로그 또는 데이터셋) 의 경우, LCM 은 전체 콘텐츠를 로드하지 않습니다. 대신 참조 (경로, ID) 와 사전 계산된 **탐색 요약 (Exploration Summary)**을 저장합니다. 이 요약은 타입 인식 디스패처 (구조화된 데이터에 대한 스키마 추출, 코드에 대한 구조 분석, 텍스트에 대한 LLM 요약) 에 의해 생성되어, 모델이 파일을 로드하지 않고도 해당 파일에 대해 추론할 수 있게 합니다. 파일 ID 는 요약 DAG 를 통해 전파되어, 여러 번의 압축이 있더라도 모델이 접한 파일에 대한 인식을 유지하도록 보장합니다.

4. 연산자 수준 재귀

LCM 은 모델이 작성한 루프를 엔진이 관리하는 원시 연산자로 대체합니다:

• LLM-Map: 상태 없는 LLM 호출 (예: 분류, 추출) 을 통해 항목 목록을 병렬로 처리합니다.
• Agentic-Map: 각 항목에 대해 전체 하위 에이전트 세션을 생성하여, 다단계 추론이나 도구 사용에 적합합니다.
• 보장: 엔진은 반복, 동시성, 재시도, 스키마 검증을 처리합니다. 출력은 외부 JSONL 파일에 저장되어 컨텍스트 오염을 방지합니다.
• 범위 축소 불변성: 무한한 위임 루프를 방지하기 위해, 하위 에이전트는 유지하는 작업과 위임하는 작업을 명시해야 합니다. 에이전트가 자신의 전체 책임을 위임하려고 시도하면 엔진은 호출을 거부합니다. 이 구조적 보장은 임의의 깊이 제한 없이 종료를 보장합니다.

주요 기여

1. 아키텍처 전환: LCM 은 컨텍스트 관리를 확률적이고 모델이 생성하는 과정 (RLM) 에서 결정론적이고 엔진이 관리하는 과정으로 이동시킵니다. 이는 프로그래밍 언어에서 제한 없는 GOTO 문에서 구조화된 제어 흐름으로의 역사적 전환을 반영합니다.
2. 손실 없는 검색 가능성: RAG 나 슬라이딩 윈도우와 달리, LCM 은 컨텍스트가 얼마나 많이 압축되었는지와 상관없이 불변 스토어를 통해 이전 상태를 원문 그대로 복구할 수 있음을 보장합니다.
3. 제로 비용 연속성: 이 아키텍처는 네이티브 컨텍스트 윈도우 내에 맞는 짧은 작업에 대해 지연 시간이나 비용 오버헤드를 발생시키지 않아, 재귀적 구조의 주요 비효율성을 해결합니다.
4. 결정론적 수렴: 3 단계 에스컬레이션 프로토콜과 범위 축소 불변성은 각각 압축 실패와 무한 재귀에 대한 수학적 보장을 제공합니다.

결과

저자들은 Volt 에이전트 (LCM 구현) 를 Claude Code(v2.1.4) 및 원시 Opus 4.6과 비교하여 OOLONG 벤치마크 (특히 trec_coarse 분할) 에서 8K 에서 1M 토큰까지의 컨텍스트 길이를 테스트했습니다.

• 성능: Volt(LCM) 는 평균 절대 점수 74.8을 달성하여 Claude Code 의 70.3보다 4.5 점 높았습니다.
• 컨텍스트 길이 민감도:
  • < 32K 토큰: Volt 와 Claude Code 는 유사하게 작동했으며, 짧은 길이에서 Claude Code 가 약간 우세했습니다.
  • > 32K 토큰: Volt 는 Claude Code 를 일관되게 능가했습니다. 초장기 영역에서 격차는 크게 벌어졌습니다:
    • 256K 토큰: Volt 가 10.0 점 우세.
    • 512K 토큰: Volt 가 12.6 점 우세.
    • 1M 토큰: Volt 가 4.3 점 우세.
• 베이스라인 저하: 구조화 없이 원시 Opus 4.6 은 65K 토큰을 초과하면 급격한 저하를 보였으며, 가장 긴 길이에서는 점수가 20 미만으로 떨어졌습니다.
• 메커니즘: 성능 우위는 컨텍스트 포화를 피하기 위해 병렬 집계를 위해 LLM-Map을 사용하는 LCM 의 사용에 기인합니다. 반면, Claude Code 는 모델이 청킹 전략을 고안하도록 의존하는데, 이는 컨텍스트가 커짐에 따라 오차 분산과 인지 부하를 초래합니다.

중요성 및 주장

이 논문은 LCM 이 RLM 이 개척한 재귀적 패러다임의 승인과 확장을 나타낸다고 주장합니다. 이는 재귀적 컨텍스트 조작이 기존 LLM 뿐만 아니라 네이티브 파일 시스템 접근을 갖춘 최첨단 코딩 에이전트 (Claude Code 등) 보다도 우수할 수 있음을 보여줍니다.

저자들은 LCM 이 생산 환경에 더 나은 절충안을 제공한다고 주장합니다:

• 유연성보다 신뢰성: 모델이 작성한 루프의 최대 유연성을 희생함으로써, LCM 은 종료 보장, 제로 비용 연속성, 그리고 손실 없는 상태 검색 가능성을 얻습니다.
• 생산 타당성: 결정론적 원시 연산자는 모델이 자신의 메모리를 관리하는 메타 기술을 마스터할 때까지 기다리지 않고도 무한 컨텍스트 아키텍처를 즉시 배포할 수 있게 합니다.
• 상호 보완성: 저자들은 LCM 과 RLM 이 상호 배타적이지 않다고 제안합니다. 미래 시스템은 일반적인 경우 LCM 의 구조화된 연산자를 기본으로 사용하면서, 최대 유연성이 필요한 예외적인 작업에는 RLM 스타일의 심볼릭 재귀를 유지할 수 있습니다.

이 논문은 "아키텍처 중심" 관점 (구조화된 원시 연산자 제공) 이 현재 원시 모델 윈도우의 능력을 초과하는 컨텍스트 길이가 확장됨에 따라, 생산 집계 작업 부하에 대해 신뢰성과 비용 이점을 제공한다고 결론지었습니다.