Token Compression — Drewgent 도구 출력 4-layer 캡

한 줄 요약

Drewgent의 4개 도구 출력 (terminal, read_file, kanban_list, kanban_get) 에 soft 40/60 head/tail cap을 추가해서, kanban_list 한 번에 9,670 tokens (78%) 절감. headroom_ai 같은 외부 라이브러리 없이 Drewgent-native 패턴으로 끝냄.

무엇을 했나 (3 patch)

LayerTool변경기본값효과
1terminaltail_lines (이미 있었음)50long stdout 40/60 cap
2read_filemax_chars 추가20,000 chars25,134 → 5,129 (80%)
3kanban_listinclude_body (default false) + body_charsbody 없음 / 50012,351 → 2,680 tokens (78%)
4kanban_getbody_chars5,000 chars891 → 368 (body 한정, 59%)

truncation marker로 모델이 잘린 걸 알아채고 body_chars 올려서 다시 부를 수 있어 — 신호 손실 0.

측정 (실제 DB)

kanban_list(board="content") — 29 task 기준:

호출JSON charstokens (≈3.5c/tok)
옛날 (full body 항상)43,230~12,351
지금 기본 (no body)9,381~2,680
body_chars=10019,392~5,541
body_chars=30031,086~8,882

read_file은 file_tools.py (851줄) 으로 측정: 25,134 → 5,129 chars (80%) at max_chars=5000.

왜 headroom_ai 안 깔았나

[[P4-cortex/knowledge/headroom-poc-20260602]] 에서 POC 결과 — headroom_ai는 web_search JSON 같은 정형 데이터에 89% 절약하지만, plain text/code/source는 0% (router가 명시적으로 보호). Drewgent 도구 출력의 80%+가 이미 JSON이라 의미 있는 추가 gain 없음. library의 message-list 가정도 Drewgent tool flow (단일 JSON dict 반환) 와 안 맞음.

판정: 도입 보류. 3 patch로 78~80% 절감 이미 달성. 재평가 trigger:

  • token 비용이 월 $100+ 돌파
  • MCP tool output이 90%+ JSON 통일
  • library가 provider-specific token counting으로 더 정확한 estimate 제공 시

design choice — 40/60 split이 50/50보다 나은 이유

Drewgent tool output은 보통 “context + log dump” 구조:

  • head 40%: schema/header/metadata (LLM이 task 이해에 필요)
  • middle: 반복되는 row (LLM이 스킵해도 됨)
  • tail 60%: last error/result (LLM이 다음 액션 결정에 필요)

50/50이면 마지막 error가 잘릴 수 있어. terminal tail_lines, read_file 40/60, kanban_get 40/60 모두 같은 ratio — Drewgent-wide convention.

보이지 않는 trade-off

3 patch 모두 backward compatible:

  • include_body default false — LLM이 명시적으로 true 안 하면 옛날 동작 보장
  • body_chars default 5000 — 옛날 동작이었던 “전부 반환” 보장은 안 되지만, 5000자 이상 body를 가진 task는 거의 없음 (실측 최대 891자)
  • max_chars default 20000 — 일반 file 읽기는 영향 없음

kanban_get은 옛날엔 body/result가 무제한 반환이었어. 5000자 cap으로 model이 못 보면 signal 명시 (_body_truncated: true in response) + body_chars 올려서 재호출. 불완전한 정보로 결정하는 것보다 옳음.

Verification

  • syntax check: python3 -c "import ast; ast.parse(...)" 양쪽 다 OK
  • import test: fresh module reload → kanban_list('content') returns 29 tasks, body absent
  • end-to-end: kanban_get('t_ff73a5a0', body_chars=100) returns 168 chars with _body_truncated: true
  • gateway restart: 70230 → 35942 (14h 12m → 49s), full init log 80 tools loaded, signal processor init OK
  • production: cron kanban-dispatcher resumes after restart, recovery 1 session auto-resumed

재발 방지 / follow-up

  • 6 spot rule (MEMORY): default 변경 시 4 spot (top + source/models + setup) + 2 test spot 동기화. 이번엔 신규 param 추가라 적용 안 됨.
  • kanban_get은 옛날 동작 (unlimited) → default cap 5000자. model이 clip 모르고 결정 내리는 risk 0% (truncation marker 명시).
  • 향후 kanban_create도 body/result field cap 고려. 지금은 text 입력이라 영향 없음.
  • cron output dir (5/29 incident로 cleanup 자동화됨) 와는 별개.
  • [[P4-cortex/knowledge/headroom-poc-20260602]] — headroom_ai POC 결과 (도입 보류 근거)
  • [[skills/software-development/token-compression-headroom]] — headroom_ai install/POC skill (library 선택지 보존)
  • [[skills/software-development/external-tool-evaluation]] — 외부 tool 평가 패턴
  • [[P4-cortex/portfolio/drewgent]] — Drewgent 본체 (토큰 효율 layer 위치)
  • [[P4-cortex/knowledge/NEURONFS_RULES]] — 파일 시스템 architecture
  • [[P5-ego/SELF_MODEL]] — 자아 모델 (compression 정책 위치)
  • [[P0-brainstem/brain/rules]] — P0 brainstem

Generated by Drewgent — 2026-06-02 3 patch: file_tools.py + kanban_tools.py (2 schemas) + 1 doc. Gateway restart: 14h → 49s. Measurement: 9,670 tokens per kanban_list call saved.