셀프 컴팩트 Pi 에이전트: 과장 없는 에이전틱 코딩 개발기

---

메타데이터

title: "셀프 컴팩트 Pi 에이전트: 과장 없는 에이전틱 코딩 개발기"
title_original: "Self-Compact Pi Agent: ZERO HYPE Agentic Coding Devlog"
url: "https://www.youtube.com/watch?v=3b0U4_02bAE"
video_id: "3b0U4_02bAE"
channel: "IndyDevDan"
published_date: "2026-09-21"
source_language: "en"
content_type: "YouTube deep digest"
tags: [agentic-coding, context-window, self-compaction, harness-engineering, prompt-engineering, Pi-Coding-Agent]

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==장시간 실행되는 에이전트가 컨텍스트 윈도우를 스스로 관찰하고, 가장 적절한 순간에 압축(compaction)해 작업을 계속하도록 에이전트 하네스를 설계할 수 있는가?==

• 자동 압축 임계값을 도구의 고정 기본값에 맡기지 않고 에이전트가 자기 상태에 맞춰 판단하도록 만든다.
• self-compact라는 전용 도구, 자기 자신에게 남기는 메모(self-handoff), 세 단계 임계값, 사용자 정의 압축 프롬프트를 Pi Coding Agent에 추가한다.
• plan → build → verify 워크플로와 명확한 완료 정의·평가 루브릭으로 여러 모델이 만든 에이전트를 비교하고 장시간 자율 작업에 대한 신뢰도를 검증한다.

컨텍스트 윈도우는 에이전트 작업을 수행하는 데 필요한 가장 귀중한 자원이다. 컨텍스트가 커지면 성능 저하(context rot)와 비용 증가가 발생하지만, 너무 일찍 압축하면 아직 필요한 정보가 사라질 수 있다. 따라서 하네스가 사용량을 표시하고, 에이전트가 작업의 자연스러운 중단점을 판단해 자기 컨텍스트를 압축하게 만드는 것이 이 설계의 핵심이다.

1. 문제의 본질: 장시간 에이전트와 컨텍스트 윈도우

1.1. 모든 에이전트가 피할 수 없는 자원 제약

1. 컨텍스트 윈도우는 작업 자원이다

   1. 에이전트가 코드를 읽고 추론하며 도구를 호출할 때 컨텍스트 윈도우가 작업 공간 역할을 한다.
   2. 모델의 에이전틱 엔지니어링 능력이 아무리 좋아져도 모든 에이전트는 컨텍스트 한계에 부딪힌다.
   3. 컨텍스트를 제어하고 관리하는 능력은 아직 충분히 활용되지 않은 엔지니어링 기회다.

2. 컨텍스트가 길어질수록 비용과 품질이 함께 악화된다

   1. 장시간 작업에서 컨텍스트가 포화되면 모델의 성능이 떨어지는 context rot이 발생한다.
   2. 불필요하게 누적된 토큰은 현금 비용을 태우고, 긴 실행이 반복될수록 손실이 커진다.
   3. 자동 압축은 이미 존재하지만 고정된 기본 임계값이 모든 작업의 최적 시점을 보장하지는 않는다.

1.2. OutLoop 에이전트에서 문제가 더 커지는 이유

1. 사람이 없는 장시간 작업

   1. IndyDevDan은 10개에서 수백 개의 에이전트를 하나의 공통 목표에 투입하는 단순한 swarm 시스템을 예로 든다.
   2. 에이전트들은 몇 시간 동안 서로 조정하며 실행되므로 사람이 매번 컨텍스트를 정리해 줄 수 없다.
   3. Fable swarm이나 Astra swarm처럼 비용이 큰 모델을 사용하면 컨텍스트 폭발이 곧 큰 운영비로 이어진다.

2. 자기 인식이 필요한 에이전트

   1. OutLoop 에이전트가 계속 작업하려면 자신의 컨텍스트 잔량과 압축 시점을 알아야 한다.
   2. 사람이 개입하지 않는 시스템에서는 하네스가 압축을 실행할 뿐 아니라 작업을 이어 가는 데 필요한 상태도 보존해야 한다.
   3. 이 문제를 해결하기 위해 컨텍스트를 인식하는 Pi 에이전트와 압축 전용 도구를 직접 만든다.

2. 사람이 먼저 만드는 설계: 에이전트보다 앞서는 사고와 명세

2.1. Draft plan으로 도메인 의도를 고정한다

1. 작성 속도를 늦추는 구간을 의도적으로 둔다

   1. 소프트웨어 팩토리나 swarm을 곧바로 가동하지 않고, 먼저 노트와 키보드만으로 draft plan을 작성한다.
   2. 노트에 생각을 구체화한 뒤 에이전트가 사용할 수 있는 정보로 번역하는 능력이 에이전틱 엔지니어의 핵심 우위가 된다.
   3. 모델이 코드와 소프트웨어를 만들 수 있는 시대에는 무엇을 만들지 깊이 이해하고 정확히 요청하는 능력이 차별화 요소가 된다.

2. end draft plan.md에 문제와 목표를 기록한다

   1. 장시간 자율 에이전트가 컨텍스트를 소진하고, context rot과 비용 증가를 겪는 문제를 먼저 명시한다.
   2. 해결책은 독립적인 Pi Coding Agent에 자기 압축 능력, 세 단계 임계값, UI, 사용자 정의 프롬프트, 사람용 테스트 명령을 넣는 것이다.
   3. 작성된 계획은 이후 Codex, Cloud Code, Pi Coding Agent를 서로 다른 모델과 함께 실행하는 공통 입력이 된다.

2.2. 다섯 가지 핵심 요구사항

1. Self-compact 전용 도구

   1. 에이전트가 언제든 자기 컨텍스트를 압축할 수 있는 호출 가능한 도구를 제공한다.
   2. 다른 에이전틱 코딩 도구에서 쉽게 할 수 없는 자기 주도 압축을 하네스의 기능으로 노출한다.

2. 세 단계 임계값

   1. notice는 에이전트에게 컨텍스트 사용량이 올라가고 있음을 알린다.
   2. warning은 곧 압축해야 한다는 더 강한 신호를 보낸다.
   3. force compaction은 하네스가 더 이상의 도구 호출을 막고 압축을 강제하는 최종선이다.

3. 임계값을 보여 주는 UI

   1. UI는 cached tokens, uncached tokens, free context를 표시한다.
   2. 컨텍스트 막대 위에 notice, warning, hard cutoff를 나타내는 세 개의 마커를 둔다.

4. 상호작용별 압축 프롬프트

   1. soft notice, warning, hard cutoff에 각각 별도의 사용자 프롬프트를 둔다.
   2. Pi Coding Agent의 기본 압축 프롬프트를 그대로 쓰지 않고 작업에 맞는 지시로 교체한다.

5. Human-in-the-loop 테스트 명령

   1. self-compact info로 현재 임계값과 상태를 확인한다.
   2. self-compact now로 압축을 즉시 실행해 기능을 검증한다.
   3. 일반적인 /compact 명령은 유지하되, 수동 강제 명령은 주로 테스트와 fallback 용도로 사용한다.

2.3. 표준 워크플로와 평가 루브릭

1. plan → build → verify

   1. plan 단계에서 전용 Plan F3 skill을 사용해 구현 계획과 파일 위치를 정한다.
   2. build 단계에서 계획에 맞춰 실제 애플리케이션과 하네스를 만든다.
   3. verify 단계에서 결과가 완료 정의를 충족하는지 확인한다.

2. Definition of Done은 종료 조건이다

   1. 완료 정의는 에이전트가 언제 멈춰야 하는지 알려 주며, 단순히 작업을 계속하라는 지시보다 중요하다.
   2. 계획이 지정된 위치에 존재하고, 하네스·워크플로·self-compact 도구·UI·프롬프트가 모두 완성되어야 한다.
   3. 작업을 어떻게 구현했는지보다 요구한 최종 상태를 명확히 적는 데 초점을 둔다.

3. How you're graded는 훈련된 모델의 행동을 유도한다

   1. 모델은 훈련 과정에서 계속 평가받기 때문에, 명시적인 루브릭을 주면 평가 항목을 더 잘 따르도록 유도할 수 있다.
   2. 완료 정의의 각 bullet과 워크플로 단계의 완료 여부를 지속적으로 평가한다.
   3. working directory 밖에 프로젝트 산출물을 쓰면 즉시 실패로 간주하되, 계획 디렉터리에는 계획을 쓸 수 있도록 예외를 둔다.

4. 격리 규칙으로 다중 모델 비교를 정직하게 만든다

   1. spec* 안에서는 자기 plan 이외의 파일을 읽지 못하게 한다.
   2. 여러 에이전트가 app* 아래 각자의 하위 애플리케이션에서 실행되며, 서로의 애플리케이션을 읽거나 건드리면 즉시 실패다.
   3. 임시 파일과 지정 디렉터리 밖의 도구 실행은 허용하지만, 실수로 규칙을 위반하면 즉시 멈추고 실패를 보고하도록 한다.
   4. 이 격리는 선택 사항이지만 모델과 에이전트 코딩 도구를 비교하고, 사람이 없는 장시간 작업에서 신뢰할 수 있는 모델을 찾는 데 유용하다.

3. Self-compact Pi Agent의 설계와 구현

3.1. 압축과 자기 메모를 분리한다

1. self-compact의 두 가지 역할

   1. 도구 호출은 에이전트가 자신의 컨텍스트를 자율적으로 압축하게 한다.
   2. 같은 호출은 에이전트가 다음 사이클의 자신에게 전달할 note to self를 남기게 한다.

2. 기본 압축과 self-handoff의 관계

   1. 압축은 컨텍스트가 가득 찼거나 에이전트가 직접 트리거했을 때 실행되는 사용자 프롬프트다.
   2. note to self는 일반 압축 요약 위에 추가되는 별도의 사용자 프롬프트다.
   3. 자기 메모에는 목표, 완료 판단, 다음 행동처럼 압축 이후에도 보존해야 하는 실행 상태를 기록한다.
   4. 결과적으로 에이전트는 무엇을 보존할지 결정하고 압축 이후에도 작업을 재개할 수 있다.

3.2. 임계값과 버퍼를 수치화한다

1. CLI 입력 형식

   1. compact-at 계열 값은 퍼센트뿐 아니라 K, M 같은 thousands·millions suffix도 받을 수 있게 설계한다.
   2. 최대 사용량은 90%로 제한하는 기본값을 고려한다.
   3. working directory, compact buffer, compact prompt와 같은 실행 변수를 launch 설정에서 교체할 수 있게 한다.

2. 비용 곡선에 맞춘 Astra swarm 기본값

   1. GPT 모델은 270K 부근을 넘으면 가격이 사실상 두 배가 된다는 전제를 사용한다.
   2. soft warning은 225K, hard warning은 250K, 강제 압축은 270K로 배치한다.
   3. 이 간격은 에이전트가 작업을 마무리할 시간을 주면서 비용이 뛰기 전에 압축을 완료하도록 한다.
   4. 검증·확인 단계가 압축에 의해 잘리지 않도록 hard cutoff 전에 충분한 여유를 둔다.

3. 에이전트가 판단할 공간을 남긴다

   1. 좋은 배치는 soft notice와 warning 사이에 큰 간격을 두고, warning과 force compaction 사이에는 짧은 간격을 둔다.
   2. 큰 첫 간격은 에이전트가 스스로 자연스러운 중단점을 찾아 도구를 호출할 여지를 준다.
   3. 짧은 마지막 간격은 컨텍스트가 임계치를 넘어 비용과 context rot을 키우기 전에 하네스가 안전하게 개입하게 한다.
   4. 필요하면 warning 포인트를 여러 개 추가해 작업 유형에 맞는 더 세밀한 정책을 만들 수 있다.

3.3. UI와 사용자 프롬프트가 하네스를 설명한다

1. 컨텍스트 막대의 의미

   1. cached tokens와 uncached tokens를 나눠 보여 주고, 남은 free context를 함께 표시한다.
   2. notice는 ~ 표시, warning은 ! 표시, hard cutoff는 별도 막대로 표현하는 방식으로 테스트했다.
   3. UI는 단순한 장식이 아니라 에이전트와 사람이 같은 컨텍스트 정책을 이해하게 만드는 관찰 가능성(observability) 계층이다.

2. 기본 프롬프트를 덮어쓴다

   1. soft self-compact note는 사용량이 아직 낮지만 압축 가능성을 알려 준다.
   2. warning self-compact prompt는 곧 압축하라고 더 단호하게 지시한다.
   3. hard cutoff 메시지는 지정 시점에 압축하라는 최종 동작을 정의한다.
   4. 압축 프롬프트에는 자연스러운 stopping point가 있으면 self-compact를 고려하되, 필요한 경우 도구를 계속 사용하라는 정책을 함께 넣는다.

3. 도구별 제어 가능성의 차이

   1. Pi의 기본 압축 메시지는 교체할 수 있고 Codex도 교체 가능하다고 설명한다.
   2. Cloud Code는 해당 시점에 기본 압축 메시지를 교체할 수 없지만, 커스터마이징을 위한 플러그인 시스템을 도입하고 있다.
   3. 자신이 소유하고 확장할 수 있는 오픈소스 하네스는 프롬프트·도구·UI를 원하는 방식으로 통제할 수 있다는 장점이 있다.

3.4. 에이전트가 실패해도 신호를 남기게 한다

1. 장시간 작업용 안전장치

   1. 에이전트가 규칙을 위반하거나 실패를 일으키면 즉시 중지하고 실패를 보고하게 한다.
   2. 이는 사람이 곁에 있을 때만 가능한 대화형 코딩과, 사람이 없는 OutLoop 코딩 사이의 신뢰 차이를 측정하기 위한 장치다.

2. 핵심 네 요소를 하네스 수준에서 다룬다

   1. 모델(model), 프롬프트(prompt), 도구(tool), 컨텍스트(context)를 통제하는 것이 하네스 엔지니어링의 핵심 축이다.
   2. 이 네 요소와 도메인 전문성을 함께 관리하면 에이전트의 지식 작업 능력과 비용 효율을 확장할 수 있다.

4. 여러 에이전트로 구현하고 검증하기

4.1. 같은 설계를 세 도구에 투입한다

1. 작성에서 실행으로 전환한다

   1. 직접 입력하는 단계에서는 문제와 요구사항을 Markdown 계획 파일에 최대한 자세히 적는다.
   2. 계획이 완성되면 더 이상 손으로 구현하지 않고 just 파일로 여러 에이전트를 같은 조건에서 가동한다.
   3. 이 전환은 필요한 순간에는 천천히 생각하고, 그 외에는 에이전트 속도로 빠르게 진행한다는 작업 원칙을 반영한다.

2. 세 가지 실행 조합

   1. Cloud Code에는 GPT-6 Astra를 연결한다.
   2. Codex에는 GLM 5.2를 연결한다.
   3. Pi Coding Agent에는 Fable 5.1을 연결해 동일한 self-compact 에이전트를 각각 만들게 한다.
   4. 각 실행은 자기 디렉터리에서 plan → build → verify를 수행하고 specs와 apps에 결과를 남긴다.

3. 도구 선택은 양자택일이 아니다

   1. 에이전틱 코딩 도구와 모델의 지형은 계속 변하므로 하나의 승자를 고르는 전략은 위험하다.
   2. 여러 도구를 함께 사용하는 ands, not ors 접근이 서로 다른 장점을 활용하는 방법이다.
   3. Pi Coding Agent는 오픈소스이고 커스터마이즈·확장·소유가 가능하다는 점에서 특히 실험에 적합하다.

4.2. 첫 실행 결과는 컨텍스트 관리의 필요성을 입증한다

1. GLM 5.2의 컨텍스트 폭발

   1. GLM 5.2는 약 98% 컨텍스트를 사용한 상태에서 작업을 끝내지 못했다.
   2. 출력에는 실제 구현보다 긴 사고 과정이 많이 쌓였고, 모델의 강점과 별개로 컨텍스트 한계가 명확히 드러났다.
   3. self-compaction이 있었다면 같은 작업을 계속 진행할 가능성이 있었다는 점이 이 기능의 필요성을 직접 보여 준다.

2. Fable 5.1과 GPT-6 Astra의 완료 시간

   1. Fable 5.1은 약 50분 만에 작업을 완료했다.
   2. Codex에서 실행한 GPT-6 Astra는 약 21분 만에 완료해 Fable보다 절반 이하의 시간을 사용했다.
   3. 실행 시간이 절반이면 일반적으로 사용한 토큰도 일부에 그칠 가능성이 높아 비용 효율 차이가 발생한다.

3. 컨텍스트 사용량의 차이

   1. Fable은 1M 토큰 컨텍스트에서 약 500K 토큰을 사용했다.
   2. Astra 상태 표시에는 약 136K가 나타났다.
   3. 결과 파일이 실제 요구사항을 충족하는지 확인하지 않으면 빠른 실행 시간이나 낮은 토큰 수만으로 모델을 평가할 수 없다.

4.3. 완성된 결과를 직접 실행해 검증한다

1. 세 에이전트의 산출물 확인

   1. 세 에이전트 모두 먼저 계획하고, 구현하고, 검증한 뒤 각자의 specs에 요구한 명세를 만들었다.
   2. 각 애플리케이션을 새 워크스페이스에서 실행해 실제 컨텍스트 막대가 나타나는지 확인한다.
   3. GLM 버전은 시작 시 컨텍스트 막대가 보이지 않아 이미 요구사항을 충족하지 못한 것으로 판단하고 뒤로 물렸다.

2. 테스트 임계값을 작게 설정한다

   1. Cloud Code 쪽에서는 soft 10%, warning 20%, hard 30%로 값을 벌려 빠르게 시각적 동작을 확인한다.
   2. UI에는 10% notice의 ~, 20% warning의 !, 30% hard cutoff 막대가 나타난다.
   3. 작은 값으로 압축을 빨리 일으키면 실제 장시간 실행을 기다리지 않고 하네스와 프롬프트가 연결됐는지 확인할 수 있다.

3. 컨텍스트를 의도적으로 채운다

   1. OpenRouter를 통해 빠른 모델을 실행하고 가장 큰 파일을 찾게 해 파일 크기를 읽으며 컨텍스트를 소비하도록 한다.
   2. 파일은 40KB 단위로 나뉘어 읽히고, 에이전트가 각 조각을 순서대로 처리한다.
   3. 이 방식은 단순한 명령 실행보다 self-compact의 notice·warning·force 흐름을 실제로 관찰하기 좋다.

4.4. self-compact의 실제 사이클

1. 알림에서 강제 압축까지

   1. 컨텍스트 사용량이 soft threshold에 도달하면 Context use, soft threshold라는 notice가 표시된다.
   2. warning threshold를 넘으면 Self-compact warning, threshold passed가 나타나고 에이전트가 지금 압축해야 한다고 판단한다.
   3. 에이전트는 note to self를 쓰고, 하네스가 압축을 강제하며, 이전에 읽은 내용은 요약 사이클로 정리된다.
   4. 압축된 기록에는 목표, 결정, 완료 여부, 다음 행동과 별도의 compaction message가 함께 남는다.

2. 압축 이후의 연속성

   1. self-handoff는 일반 압축 요약에 더해 다음 에이전트 사이클에 전달되는 명시적 작업 메모다.
   2. 컨텍스트가 줄어든 뒤 에이전트는 파일의 나머지 부분을 계속 읽고 원래 작업을 이어 간다.
   3. UI의 cycle 1 표시와 압축 횟수 기록 가능성은 장시간 작업의 상태를 관찰하고 비용을 분석하는 기반이 된다.

3. 사람이 직접 호출하는 검증

   1. 컨텍스트가 12%인 시점에도 self-compact now를 호출해 도구가 독립적으로 작동하는지 먼저 확인한다.
   2. 호출 결과 note to self가 전달되고 컨텍스트가 압축되는지, Codex·Pi·Astra용 프롬프트가 실제로 실행되는지 확인한다.
   3. Fable의 compaction prompt가 Astra보다 더 구체적으로 보였고, Fable이 다른 에이전트를 위한 프롬프트 엔지니어링에서도 더 나은 결과를 보였다는 관찰이 있었다.

5. 최종 시사점: 컨텍스트 제어에서 에이전트 시스템 설계로

5.1. 장시간 자율 작업을 위한 운영 원칙

1. 에이전트가 보존과 지속을 스스로 관리하게 한다

   1. self-compaction은 언제 압축할지, 무엇을 보존할지, 압축 뒤 어떻게 계속할지를 에이전트가 결정하게 한다.
   2. 여러 임계값은 단 한 번의 자동 압축보다 작업의 자연스러운 흐름에 맞는 판단 공간을 제공한다.
   3. 비용과 context rot을 동시에 줄이면서 사람이 없는 OutLoop 실행을 더 오래 유지할 수 있다.

2. 하네스를 제품의 일부로 본다

   1. 도구의 기본값만 사용하는 데서 벗어나 프롬프트와 도구 호출, UI, 상태 저장을 직접 설계해야 한다.
   2. 모델을 바꿔도 같은 workflow와 평가 루브릭을 적용하면 결과를 비교할 수 있다.
   3. 여러 에이전트를 소프트웨어 팩토리 안에 배치하면 반복 가능한 결과를 생산하는 시스템으로 확장할 수 있다.

5.2. 인간의 우위는 요구사항의 정밀도다

1. 코드 작성 자체는 차별화가 아니다

   1. 에이전트와 swarm이 코드를 작성하고 소프트웨어를 만들 수 있는 상황에서 인간이 직접 타이핑하는 양은 핵심 경쟁력이 아니다.
   2. 문제를 세밀하게 관찰하고 원하는 최종 상태를 정확히 설명하는 능력이 더 독특한 우위가 된다.

2. 도구의 한계가 가능성의 한계가 되지 않게 한다

   1. 특정 도구의 고정된 경험에 맞춰 문제를 축소하지 말고 필요한 기능을 만들 수 있는 도구를 선택한다.
   2. PyCoding Agent처럼 커스터마이즈하고 통제할 수 있는 소프트웨어는 에이전트 기능을 하네스의 뼈대까지 확장하게 한다.
   3. Cloud Code가 플러그인 시스템을 도입하는 흐름은 이런 하네스 커스터마이징 아이디어가 도구 생태계 전체로 확산되고 있음을 보여 준다.
   4. 앞으로의 중요한 기능은 아직 여러 엔지니어의 머릿속에 있으며, 그것을 도구로 구현하는 사람이 새로운 가능성을 만든다.

주요 발언 모음

“The context window is the precious resource for accomplishing work with your agents.”

“Your agents are now intelligent enough to be self-aware of their own context windows.”

“The level of detail you add to your work is what differentiates you now.”

“Definition of done is how your agent knows when to stop.”

“We are teaching our agents to manage their own context window — when to compact, what to preserve, and how to continue.”

“If you master the core four — context, model, prompt, tool — you master the agent.”

“I think in ands, not ors. I recommend you do the same.”

“The tools you use directly limit what you believe is possible.”

핵심 데이터 & 수치

• 실행 시간: Fable 5.1 약 50분, Codex의 GPT-6 Astra 약 21분.
• GLM 5.2 컨텍스트: 약 98%까지 사용한 뒤 작업을 완료하지 못함.
• Fable 컨텍스트: 1M 토큰 컨텍스트에서 약 500K 토큰을 사용함.
• Astra 상태 표시: 약 136K로 관찰됨.
• Astra swarm 기본 임계값: soft 225K, hard warning 250K, force 270K.
• 테스트 임계값: soft 10%, warning 20%, hard 30%.
• 컨텍스트 단계: notice → warning → force compaction.
• swarm 규모 예시: 공통 목표를 위해 10개에서 수백 개의 에이전트를 투입하고 몇 시간 동안 실행함.
• 파일 읽기 테스트: 큰 파일을 40KB 단위로 나누어 컨텍스트를 의도적으로 소비함.

결론 및 시사점

1. 컨텍스트 윈도우는 에이전트 코딩의 부수적인 구현 세부사항이 아니라 비용·품질·지속성을 좌우하는 핵심 운영 자원이다.
2. 자동 압축을 도구의 기본값에 맡기지 말고, 작업의 자연스러운 중단점을 판단하는 self-compact 도구와 프롬프트를 하네스에 넣어야 한다.
3. soft notice, warning, force cutoff를 분리하면 에이전트가 스스로 압축할 기회를 주면서도 컨텍스트 폭발을 막을 수 있다.
4. note to self와 self-handoff는 일반 요약에 없는 목표·결정·다음 행동을 보존해 압축 이후 작업 연속성을 높인다.
5. plan → build → verify, Definition of Done, How you're graded를 함께 사용하면 여러 모델의 장시간 자율 작업 신뢰도를 비교할 수 있다.
6. 사람이 직접 입력해야 하는 구간은 요구사항을 정밀하게 쓰고 검증 기준을 만드는 구간이며, 구현 속도는 에이전트에게 넘길 수 있다.
7. 오픈소스와 확장 가능한 하네스는 모델 교체, 프롬프트 덮어쓰기, 도구 추가, UI 관찰 가능성 확보를 가능하게 한다.

핵심 요약 (20줄)

컨텍스트 윈도우는 에이전트가 코드를 읽고 추론하며 도구를 호출하는 핵심 작업 자원이다. 컨텍스트가 포화되면 context rot으로 성능이 떨어지고 토큰 비용이 증가한다. 장시간 OutLoop 에이전트와 수백 개 규모의 swarm은 사람이 컨텍스트를 수동으로 정리할 수 없다. 에이전트가 자신의 컨텍스트 사용량을 관찰하고 압축 시점을 판단하는 하네스가 필요하다. self-compact 도구는 에이전트가 자신의 컨텍스트를 자율적으로 압축하게 한다. self-compact 호출은 압축과 함께 다음 사이클에 전달할 note to self를 남긴다. note to self에는 목표, 완료 판단, 다음 행동처럼 압축 뒤에도 필요한 상태를 기록한다. notice, warning, force compaction의 세 임계값은 자율 판단과 안전한 강제를 함께 제공한다. 컨텍스트 UI는 cached tokens, uncached tokens, free context와 세 임계값 마커를 보여 준다. soft·warning·hard 프롬프트를 직접 설계하면 도구의 기본 압축 메시지를 작업에 맞게 바꿀 수 있다. GPT 모델의 비용이 270K 부근에서 크게 뛰는 상황에는 225K·250K·270K 임계값이 유용하다. plan → build → verify 워크플로는 에이전트가 계획부터 검증까지 일관되게 수행하게 한다. Definition of Done은 에이전트가 언제 멈춰야 하는지 명확하게 알려 주는 종료 조건이다. How you're graded 루브릭은 훈련 중 평가받은 모델의 행동 특성을 활용해 요구사항 준수를 높인다. GLM 5.2는 약 98% 컨텍스트에서 작업을 끝내지 못해 self-compaction의 필요성을 보여 줬다. Fable 5.1은 약 50분, GPT-6 Astra는 약 21분 만에 같은 종류의 구현을 완료했다. Fable은 1M 토큰 컨텍스트에서 약 500K 토큰을 사용했고 Astra 상태는 약 136K로 표시됐다. 작은 10%·20%·30% 임계값과 큰 파일 읽기로 self-compact의 전체 사이클을 빠르게 검증할 수 있다. 압축 사이클은 soft notice, warning, note to self 작성, 강제 압축, 작업 재개 순서로 진행된다. 모델·프롬프트·도구·컨텍스트를 통제하는 하네스 엔지니어링이 OutLoop 시스템 확장의 기반이다. 정밀한 요구사항과 확장 가능한 도구가 에이전트 시대에 인간이 만드는 가치와 가능성의 범위를 결정한다.