에이전트를 깨우기 위해 30,000 토큰의 채팅 기록을 강제로 주입하는 것을 멈추세요. DUMEdb를 구축했습니다.

안녕하세요! 만약 자율 에이전트(autonomous agents)를 구축하거나 여러 세션에 걸쳐 페어 프로그래밍(pair-program)을 했다면, 아마도 이 벽에 부딪혔을 것입니다. 에이전트가 컨텍스트를 전환하거나 프로젝트를 재개할 때마다, 대부분의 프레임워크에서 표준 관행은 30,000 토큰 이상의 원시 채팅 기록을 프롬프트 메모리에 덤프하는 것입니다.

이 아키텍처가 깨지는 이유:

KV-Cache / 컨텍스트 부족 현상(Context Choke): 실제 작업을 수행하기도 전에 첫 번째 턴(Turn 1)에서 모델의 컨텍스트 한계치(context ceiling) 중 25%~70%를 소모하고 있습니다.
무음 압축 / 기억 상실증(Silent Compaction / Amnesia): 컨텍스트가 가득 차면, IDE나 하네스(harness)는 이전 턴을 조용히 요약하고 잘라냅니다. 가장 먼저 손실되는 것은 보통 중요한 아키텍처 규칙이나 운영자 선호도입니다.
확률적 표류(Probabilistic Drift): 변수와 운영 상태가 결정론적인 사실이 아니라 다중 턴 프롬프트에 걸쳐 추측 게임이 됩니다.
비용 및 지연 시간(Cost & Latency): 매번 깨어날 때마다 방대한 기록을 재처리하는 과정은 지연 시간과 API 비용을 급증시킵니다.

1959년 IBM 1401 접근 방식:

이 문제를 해결하기 위해, 저는 70년간 검증된 컴퓨팅 원리, 즉 **IBM 1401 유닛-레코드 처리 시스템(unit-record processing system)**으로 돌아가야겠다는 아이디어를 얻었습니다. 그 펀치 시스템은 크기에 따라 분리하여 기계에 무엇을 해야 할지 알려주기만 했습니다. 그래서 엄청나게 빨랐고, 드리프트 없이 100% 사실이었습니다! 블로트 플로트(bloat float)를 사용하는 에이전트는 한 가지 기능을 고치려다가 실수로 다른 기능을 제거하는 상황으로 전락할 수 있습니다. 무슨 말인지 아시죠? LOL

1959년, IBM 시스템에는 기가바이트급 디지털 RAM이 없었고, 현재 잔액을 알기 위해 스택에 있는 모든 펀치 카드를 다시 계산하지도 않았습니다. 그들은 하드웨어 라인 속도로 읽는 80열 카드에서 고정적이고 이산적인 열 레지스터(column registers)를 읽었습니다. 우리의 1959년 엔지니어 페르소나 프랭크(Frank)가 말했듯이:

“삭제되는 곳에 거짓말이 산거야. 원장을 지우거나 모든 펀치 카드를 다시 계산해서 총액을 읽는 게 아니야. 레지스터를 읽는 거지.”

DUMEdb란 무엇인가요?

**DUMEdb (결정론적 단위 기록 메모리 엔진)**은 트랜스크립트 리플레이(transcript replay)를 메모리 매핑된 불변 레지스터(memory-mapped immutable registers)로 대체합니다:

• 220 토큰 제로-턴 웨이크(Zero-Turn Wake): 30,000개 이상의 토큰을 리플레이하는 대신, 에이전트는 구조화된 cabinet_wake 핸드셰이크를 실행합니다. 이 과정에서 운영자 신원(operator identity), 모드(mode), 접촉한 파일(touched files), 그리고 즉각적인 다음 이동(immediate next move)을 220 토큰 미만으로 입력받습니다 (~컨텍스트 사용량 0.2%, 깨끗한 여유 공간 99.8% 확보).
• 제로 파일시스템 탐색(Zero Filesystem Rummaging): 에이전트는 상태를 "기억하기 위해" ripgrep을 실행하거나 디렉토리를 크롤링하도록 지시받지 않습니다. 상태는 레지스터에 존재합니다.
• 4.2 µs 제로-카피 LMDB 엔진(Zero-Copy LMDB Engine): Lightning Memory-Mapped Database (LMDB)를 기반으로 구축되었습니다. 페이지는 힙 할당(heap allocations)이 없고, 사용자 공간 복사(userspace copying)가 없으며, JSON 역직렬화 오버헤드(JSON deserialization overhead)가 없는 상태로 OS 가상 메모리(OS virtual memory)에 직접 매핑됩니다.
• 실제 컨텍스트 오도미터 (Ground-Truth Context Odometer) (실측 수학): 대부분의 IDE(통합 개발 환경) 내 컨텍스트 바는 부드럽고 가짜인 백분율을 표시합니다. DUMEdb는 디스크에 있는 transcript.jsonl에서 실제 압축 후 JSON Lines 바이트 수를 감사하여, 하드웨어 한계 대비 실제 여유 공간(real runway)을 추적합니다.
• 최상급 MCP 서버(First-Class MCP Server): 표준 모델 컨텍스트 프로토콜(Model Context Protocol)을 통해 Antigravity, Cursor, Windsurf, Claude Code, Copilot에 네이티브하게 연결됩니다. 이것이 무엇인지 모른다면 저에게 연락 주세요. 명확하게 이해할 수 있도록 도와드리겠습니다! :-)
• 100% 로컬 및 개인 정보 보호(Local & Private): Apache 2.0 오픈 소스입니다. 모든 레지스터, LMDB 환경, 로그는 오직 사용자의 기기에만 존재합니다. 클라우드 원격 측정(cloud telemetry)은 없습니다.

로컬에서 사용해 보기:

# 패키지 설치
pip install dumedb
# 포트 8095에서 내장 시각 검사기(visual inspector)와 함께 엔진 실행
python -m dume -p 8095
Quick MCP Config (mcp_config.json):
json {
  "mcpServers": {
    "dumedb": {
      "command": "python",
      "args": ["-m", "dume.mcp_server"],
      "env": {
        "DUME_PORT": "8095"
      }
    }
  }
}

링크 및 자료:
GitHub (Apache 2.0): https://github.com/madbradsmith/DUMEdb
실시간 워크스루 비디오:

여기서 여러분들이 장기 실행 에이전트 워크플로우에서 크로스-세션 상태 지속성(cross-session state persistence)을 처리하고 KV-캐시 압축(KV-cache compaction)을 피하는 방법에 대해 듣고 싶습니다.
피드백과 Pull Request(PR)를 환영합니다! 컨텍스트를 명확하게 유지하세요! :- ) 평화!
제출자: /u/MadBradSmith [링크] [댓글]