나도 똑같은 경험을 했음. 나도 내 걸 포함해서 여러 압축 확장 프로그램을 써봤는데 만족스러운 게 없었음. 압축 이벤트가 발생하면 긴 세션에서 품질이 떨어지는 변곡점이 되는 경우가 너무 많았음. 뭉텅이로 요약하는 건 이상적인 개념이 아니라고 생각함. Handoff 프롬프트가 나한테는 더 잘 맞았는데, 이것도 문제가 있음. 특히 에이전트를 큰 개발 작업이랑 같이 한동안 내버려 두고 싶을 때가 문제임.
그래서 Pi 포크를 만들었음(확장 프로그램 수준을 넘어선 것 같아서). 모델 자체가 컨텍스트를 더 직접적으로 제어하게 만든 거임. 모델이 컨텍스트 내 메시지 목록을 확인하고, 앞으로의 작업에 필요 없는 메시지는 삭제하고, 전체가 아니라 선택적으로 메시지를 요약할 수 있는 툴을 제공함. 여기에 시스템 프롬프트 인젝션을 결합해서 용량과 상관없이 당면한 작업에 집중하도록 유도했음. 관련 없는 자료는 컨텍스트를 희석해서 결과물을 약하게 만들기 때문임.
모델이 이걸 이해하게 하려고 인젝션 프롬프트랑 툴 문법을 좀 파인튜닝해야 했음. 최근에는 컨텍스트 관리에 대한 별도의 스킬을 로드해서 가이드를 좀 더 줬음(예: 사용자 메시지 가지치기는 보수적으로 하고, 최근 건 유지하고, 다시 로드할 수 있는 파일은 빨리 버리기 등). 그리고 긴 세션에서 배운 교훈을 바탕으로 모델이 스스로 이 스킬을 개선하게 했음.
며칠 동안 대규모 코드베이스 개발 프로젝트 몇 개를 진행 중인데, 주로 Qwen 3.8 flash next(지금은 GuFo 호스팅)를 128 컨텍스트로만 돌리고 있고 아주 잘 돌아감. 이론적으로는 85% 정도에서 트리거 포인트에 도달하면 Pi의 기본 압축으로 폴백되겠지만, 며칠 동안 그런 일은 없었음. Qwen은 컨텍스트를 잘 집중시키고 용량 이하로 유지해서 프로젝트 결과가 좋음.
주의할 점은 있음: Qwen에서만 아주 잘 작동함(27b, flash next, max 전부 컨텍스트를 능숙하게 관리함). 다른 모델들은 이 방식을 잘 안 쓰려고 함. 다른 프로젝트에서 GPT-6-sol을 쓰고 있는데, 툴을 사용해서 컨텍스트를 관리하긴 하지만, 품질이나 집중도 때문이 아니라 용량 압박을 느낄 때만 함.