AIClaw가 중요한 부분을 놓치지 않고 긴 에이전트 대화를 압축하는 방법

장시간 실행되는 에이전트 세션은 결국 동일한 문제에 직면합니다. 모델이 채팅 기록, 도구 출력(tool outputs), 중간 결정 사항, 실행 추적(execution traces)을 계속 축적하면서 프롬프트(prompt)가 비싸지거나 불안정해지는 문제입니다. AIClaw는 이 문제에 대한 내장된 해결책을 가지고 있습니다. 단순히 오래된 메시지를 삭제하는 것이 아니라, 대화의 중간 부분을 구조화된 요약(structured summary)으로 압축하고 다음 단계에 여전히 중요한 부분들은 유지합니다.

이 글은 새로운 출시 소식이 아닙니다. 기존 AIClaw 런타임(runtime) 기능 중 하나인 컨텍스트 압축(context compression)에 대한 심층적인 분석입니다.

문제점

AIClaw는 짧은 챗봇 답변이 아닌, 도구를 사용하는 작업(tool-using work)을 위해 설계되었습니다. 단일 작업에는 다음과 같은 내용이 포함될 수 있습니다:

• 여러 차례의 셸(shell) 또는 브라우저 도구 호출
• 긴 도구 출력(tool outputs)
• 계획-상태 진행 업데이트(plan-state progress updates)
• 첫 번째 시도 이후의 후속 수정 사항
• 부모 실행(parent run)으로 다시 흘러 들어오는 하위 에이전트(sub-agent) 결과

이는 유용한 컨텍스트(context)이지만, 동시에 프롬프트가 빠르게 커진다는 것을 의미합니다. 만약 런타임이 모든 것을 모델에 영원히 다시 보낸다면, 비용이 증가하고 모델은 히스토리의 잘못된 부분에 주의를 기울이기 시작합니다.

README에서는 이 기능을 다음과 같이 짧게 설명합니다:

런타임 압축(Runtime compression): 긴 중간 컨텍스트(middle context)는 실행 중에 요약될 수 있습니다.

이 문구 뒤에 숨겨진 구현은 들리는 것보다 더 구체적입니다.

AIClaw가 압축을 결정하는 시점

이 결정은 /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/context_compressor.go에 구현되어 있으며, /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/run.go의 메인 실행 루프에 연결되어 있습니다.

각 LLM 라운드 이전에, AIClaw는 현재 프롬프트가 모델의 컨텍스트 윈도우(context window)에 비해 너무 큰지 확인합니다.

현재의 기본 설정은 다음과 같이 간단합니다:

• 프롬프트 사용량이 모델 컨텍스트 윈도우 (context window)의 50%에 도달하면 압축 수행
• 시스템 메시지 (system message)를 맨 앞(head)에 유지
• 최소 최근 20개의 메시지를 맨 뒤(tail)에 유지
• 압축을 수행할 가치가 있으려면 최소 5개의 중간 메시지가 필요함

모델 제공업체가 실제 프롬프트 토큰 (prompt-token) 사용량을 보고하는 경우, AIClaw는 해당 값을 사용합니다. 그렇지 않으면 내부 추정치를 사용합니다. 이는 트리거가 단순히 메시지 개수가 아니라 실제 프롬프트 압박 (prompt pressure)을 기반으로 하기 때문에 중요합니다.

무엇이 압축되고, 무엇이 유지되는가

AIClaw는 4단계 흐름을 사용합니다.

1. 먼저 오래된 도구 출력 (tool output)을 가지치기합니다

모델에게 요약을 요청하기 전에, AIClaw는 보호된 테일 윈도우 (tail window) 밖에 있는 오래된 도구 메시지들을 잘라냅니다. 중간 영역에 있는 도구 출력은 200 룬 (runes)으로 잘립니다. 이를 통해 거대한 로그가 요약 프롬프트를 지배하는 것을 방지합니다.

이는 중요한 설계 선택입니다. 런타임 (runtime)은 먼저 원본 노이즈를 전체 크기로 요약하려고 시도하지 않습니다. 요약 호출 비용을 지불하기 전에 명백히 가치가 낮은 대량의 데이터를 먼저 줄입니다.

2. 헤드(head)와 테일(tail)을 보호합니다

압축기는 다음을 보존합니다:

• 대화의 헤드 (head), 특히 시스템 프롬프트 (system prompt)
• 현재 작업 상태가 존재하는 대화의 최신 테일 (tail)

중간 부분은 압축 대상 후보가 됩니다.

3. LLM에 구조화된 요약을 요청합니다

모호한 문단을 생성하는 대신, AIClaw는 다음과 같은 섹션을 포함하는 엄격한 템플릿을 요청합니다:

• 목표 (Goal)
• 제약 사항 및 선호도 (Constraints And Preferences)
• 진행 상황 (Progress)
• 주요 결정 사항 (Key Decisions)
• 관련 파일 (Relevant Files)
• 다음 단계 (Next Steps)
• 핵심 컨텍스트 (Critical Context)

이는 에이전트의 연속성 (continuity)을 위한 실용적인 선택입니다. 요약의 목적은 유려한 산문을 만드는 것이 아니라 실행 상태 (execution state)를 보존하는 것입니다.

4. 요약 메시지로 대화를 재구성합니다

요약이 완료되면, AIClaw는 [Context Compression Summary] 메시지를 삽입하고, 이전 대화가 압축되었다는 노트를 시스템 프롬프트에 추가합니다.

결과물은 원래의 히스토리보다 크기가 작지만, 작업 목표(task objective), 결정 사항(decisions), 차단 요소(blockers), 수정된 파일(touched files), 그리고 다음 행동(next action)을 여전히 유지합니다.

도구 호출(Tool Calls)은 분리되지 않습니다

구현상의 미묘한 디테일은 AIClaw가 어시스턴트/도구 호출(assistant/tool-call) 그룹을 중간에 끊지 않는다는 점입니다. 압축기(compressor)는 보존된 꼬리 경계(tail boundary)를 뒤로 정렬하여, 도구 호출(tool call)과 그 도구 결과(tool results)가 함께 유지되도록 합니다.

이는 도구 호출 시퀀스가 끊어지면 다음 모델 라운드에서 혼란을 줄 수 있기 때문에 중요합니다. 만약 어시스턴트 메시지에는 도구를 호출했다고 되어 있는데, 보존된 꼬리 부분에 해당하는 도구 결과가 누락되어 있다면 재구성된 컨텍스트(context)는 오해의 소지가 생깁니다.

이러한 동작에 대한 테스트는 /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/context_compressor_test.go에서 확인할 수 있습니다.

압축은 일회성이 아닌 반복적(Iterative)입니다

AIClaw는 활성 실행(active run) 중에 이전의 압축 요약(compression summary)을 메모리에 유지합니다. 다음 압축 단계(compression pass)에서 처음부터 다시 시작하지 않고, 다음을 전송합니다:

• 이전 요약(previous summary)
• 새로 누적된 대화 슬라이스(newly accumulated conversation slice)

그런 다음 모델에게 이들을 업데이트된 구조화된 요약(structured summary)으로 병합하도록 요청합니다.

이를 통해 긴 작업에서 반복적인 압축을 더 저렴하고 안정적으로 수행할 수 있습니다. 매번 전체의 오래된 중간 히스토리를 다시 요약하는 대신, AIClaw는 중요한 상태(state)를 점진적으로 앞으로 전진(roll forward)시킵니다.

어떤 모델이 압축을 처리하는가

메인 실행 루프(main execution loop)는 압축을 위해 에이전트의 FastModelName이 설정되어 있다면 이를 우선적으로 사용하며, 그렇지 않으면 기본 모델(primary model)로 대체(fallback)합니다.

이는 로컬 우선(local-first) 에이전트 플랫폼에 좋은 기본 설정입니다:

• 비용이 많이 들거나 프리미엄인 모델은 실제 작업에 집중할 수 있습니다.
• 더 저렴하거나 빠른 모델이 요약 작업을 처리할 수 있습니다.
• 긴 세션 동안 프롬프트 크기(prompt size)를 제어할 수 있습니다.

실질적인 예시

AIClaw 에이전트가 다음과 같이 디버깅 세션을 진행한다고 가정해 봅시다:

1. 여러 Go 파일을 읽습니다.
2. 테스트를 실행합니다.
3. 로그를 조사합니다.
4. 코드를 수정합니다.
5. 테스트를 다시 실행합니다.
6. 하위 에이전트 (sub-agent)에게 실패한 서브시스템을 조사하도록 요청합니다.
7. 최종 수정을 위해 부모 실행 (parent run)으로 돌아옵니다.

압축 (compression)이 없다면, 대화 기록은 점차 오래된 도구 출력물 (tool output)의 더미가 되어버립니다. 압축을 사용하면, AIClaw는 현재의 끝부분 (tail)은 온전하게 유지하면서, 이전 작업들을 다음과 같은 내용을 기억하는 구조화된 체크포인트 (checkpoint)로 통합할 수 있습니다:

• 어떤 파일들이 이미 조사되었는지
• 어떤 명령어가 성공하거나 실패했는지
• 사용자가 무엇을 요청했는지
• 어떤 제약 조건 (constraints)이 중요한지
• 무엇이 아직 해결되지 않은 상태인지

이것이 바로 "더 짧은 프롬프트 (shorter prompt)"와 "런타임 연속성 (runtime continuity)"의 차이입니다.

이 기능이 중요한 이유

AIClaw는 실행 상태 (execution state)에 대해 확고한 견해를 가지고 있습니다. AIClaw는 이미 계획 상태 (plan state), 생성된 파일, 실행 단계, 메모리, 그리고 대화 기록을 일급 런타임 데이터 (first-class runtime data)로 취급합니다. 컨텍스트 압축 (context compression) 또한 동일한 설계 철학에 부합합니다.

목표는 단순히 대화 기록 (transcript)을 더 보기 좋게 만드는 것이 아닙니다. 목표는 긴 시간 동안 실제 작업을 수행한 후에도 에이전트가 유용하게 유지되도록 하는 것입니다.

만약 여러분이 주로 한 번의 턴 (one turn) 내에 답변하는 에이전트를 구축하고 있다면, 이 기능은 무시하기 쉽습니다. 하지만 여러 라운드에 걸쳐 브라우징하고, 편집하고, 명령어를 실행하며, 실패로부터 복구하는 에이전트를 구축하고 있다면, 이 기능은 신뢰성 (reliability)을 구성하는 핵심 요소가 됩니다.

AIClaw는 모든 부담을 프롬프트 엔지니어링 (prompt engineering)으로 떠넘기는 대신, 해당 로직을 런타임 (runtime) 내에 유지합니다.

코드에서 확인해야 할 부분

코드에서 확인해야 할 부분

• /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/context_compressor.go: 압축 임계값(compression thresholds), 보호 창(protected windows), 요약 프롬프트(summary prompt), 반복적 요약 로직(iterative summary logic)
• /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/run.go: 실행 루프(execution loop) 내에서 압축이 트리거되는 위치
• /Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/context_compressor_test.go: 요약 주입(summary injection), 반복적 업데이트, 도구 그룹 보존(tool-group preservation), 중복 노트 방지 테스트
• /Users/yu/go/src/github.com/chowyu12/aiclaw/README.md: 제품 수준의 런타임 압축 설명

AIClaw는 오픈 소스(open source)이며, 자체 호스팅(self-hosted)이 가능하고, 채팅 이상의 작업을 수행하는 에이전트를 위해 구축되었습니다. 컨텍스트 압축은 장시간 세션에서 이를 실용적으로 만드는 작지만 중요한 런타임 디테일 중 하나입니다.