에이전트가 컨텍스트 창의 80%에 도달합니다. 압축이 실행되어 가장 오래된 턴을 제거합니다. 10분 뒤에는 이미 읽은 파일을 다시 읽고, 이미 답한 질문을 다시 묻습니다.
임계값은 공간이 부족하다는 것은 알았습니다. 무엇을 잃어도 안전한지는 전혀 몰랐습니다.
이 글은 BEACON(저장대학교, arXiv:2605.06078)을 자세히 읽고 시작한 장기 작업 에이전트 설계 시리즈의 세 번째 노트입니다. 첫 번째는 정체 감지, 두 번째는 마일스톤 설계를 다뤘습니다.
저희의 구현부터 살펴보기
Orkas는 멀티 에이전트 데스크톱 클라이언트입니다. 긴 작업이 일반적이므로 압축은 매일 일어납니다. 저희 구현은 토큰 임계값에 따라 작동하며, 컨텍스트가 창의 약 80%에 도달하면 압축합니다. 이 글을 쓰기 전까지는 누구도 여기에 문제가 있다고 생각하지 않았습니다.
현장에서 흔히 쓰는 경계는 대략 세 가지입니다. 창의 일정 비율, 턴 수, 또는 모델이 이전 내용을 포함하는 요약을 작성하게 하는 것입니다. 저희 방식은 첫 번째입니다.
앞의 두 방식은 내용을 전혀 보지 않습니다. 세 번째는 내용을 보지만 무엇이 중요한지에 관한 판단 전체를 모델에 맡깁니다.
세 방식 모두 언제 무언가를 버려야 하는가에 답합니다. 실제 질문은 무엇을 버려도 안전한가입니다. 임계값에서 자르면 가장 덜 중요한 내용이 아니라 가장 오래된 내용을 버립니다.
마일스톤 경계와 그 아래의 가정
이전 노트의 마일스톤은 세 방식 중 어느 것보다 나은 경계를 제공할 수 있습니다. 하지만 여기에 함정이 있으며, 이전 노트는 그 부분을 조금 쉽게 넘어갔습니다.
BEACON에는 마일스톤 마르코프 성질이라는 가정이 있습니다. 쉽게 말하면 마일스톤에 도달한 뒤의 일은 남은 하위 목표에만 의존하며, 거기에 어떻게 도달했는지에는 의존하지 않는다는 것입니다. 열쇠를 얻었다면 중요한 것은 어떤 문을 여는지이지 열쇠를 어떻게 찾았는지가 아닙니다.
압축해도 된다는 허가처럼 들립니다. 마일스톤을 넘었으니 앞 구간은 접어 넣어도 된다는 것입니다.
하지만 이는 사실이 아니라 가정입니다. 논문도 =가 아니라 ≈를 쓰며, 저자들은 이 가정이 성립하지 않는 경우를 논의합니다.
학습에는 충분해도 압축에는 부족합니다
같은 가정을 두 용도로 쓰지만 요구되는 엄격함에는 자릿수가 다를 만큼 큰 차이가 있습니다.
학습에서는 통계적으로만 성립하면 됩니다. 수천 번의 롤아웃 중 수십 번이 이를 위반해도 편향은 평균화됩니다. 학습에는 안전장치로 아래에 궤적 수준 신호도 작동합니다. 그 계층을 제거하면 ALFWorld 점수가 91.4에서 23.4로 떨어져 아무것도 하지 않는 것보다 훨씬 낮아집니다.
압축에서는 눈앞의 단일 실행에 대해 개별적으로 성립해야 합니다. 잘못된 내용을 한 번 버리면 그 작업은 끝장납니다. 평균을 낼 대상이 없습니다.
따라서 논문이 이 가정에 의존한다고 해서 압축에 그대로 적용할 수 있는 것은 아닙니다. 두 용도는 그 가정에 같은 것을 요구하지 않습니다.
가정이 깨지는 네 가지 경우
압축 정책을 검토할 때 다음을 체크리스트로 사용합니다.
1. 과정에서 쌓인 암묵적 지식. 초반 어느 단계에서 특정 API가 타임스탬프를 UTC로 반환한다는 사실을 확인합니다. 이는 어떤 마일스톤에도 속하지 않지만 이후의 모든 단계에 필요합니다.
2. 이미 소모한 자원. 토큰 예산, 호출 할당량, 남은 시간입니다. 마일스톤은 예산의 60%를 썼다고 기록하지 않지만, 그 숫자가 재시도 비용을 아직 감당할 수 있는지 결정합니다.
3. 경로에 따른 부수 효과. 마일스톤에는 리팩터링 완료라고 되어 있습니다. 디버깅을 시작하는 순간 실제로 어떤 다섯 파일을 수정했는지 알아야 합니다.
4. 마일스톤 자체의 명세 부족. 네 가지 중 가장 심각합니다. 논문에서 마일스톤은 완전한 환경 상태입니다. 열쇠가 있거나 없을 뿐 모호함이 없습니다. 계획의 한 단계는 자연어 한 문장입니다. "데이터 정리 완료"로는 그 구간에서 일어난 일을 턱없이 부족하게 설명합니다.
대신 무엇을 이어서 보존해야 할까요?
요약만 보관하지 마세요. 요약은 모델이 작성하며, 모델은 무엇이 중요했는지 감으로 결정합니다.
사람이 선택한 고정 필드 세트를 보관하세요. 최소 네 가지입니다.
- 현재 작업 공간의 상태 — 어떤 파일을 수정했고 어떤 상태가 되었는지.
- 남은 예산 — 토큰, 호출 할당량, 시간.
- 확인된 사실 — UTC라는 사실과 이후 결정에 영향을 줄 유사한 모든 사실.
- 아직 미해결인 사항 — 한 번 막혔다가 우회했지만 다시 문제가 될 수 있는 것.
위의 네 가지 실패 사례와 대조하면 일대일로 대응합니다. 이 대응 관계는 압축 정책이 충분한지 판단하는 가장 단순한 방법입니다.
이 중 절반은 비용이 거의 들지 않습니다. 이전 노트에서 설명했듯 호스트는 매 도구 호출 뒤에 파일이 실제로 다시 쓰였는지, 명령이 실제로 실행되었는지 같은 확정적인 사실을 이미 기록합니다. 그 데이터는 마일스톤 검증을 위해 수집했지만 그 자체가 작업 공간 스냅샷입니다. 따라서 모델에게 다시 요약해 달라고 하지 않고도 압축 이후로 직접 가져갈 수 있습니다.
어려운 절반은 나머지 두 가지입니다. 확인된 사실과 미해결 사항은 현재 모델이 적어 둔 경우에만 존재합니다. 그래서 압축에서 가장 먼저 희생됩니다.
논쟁할 일이 아니라 측정할 일입니다
압축 후 에이전트가 압축으로 사라진 파일을 다시 읽거나 이미 답한 질문을 다시 묻는다면, 그 작업에서 가정이 실패한 것이며 증거도 바로 거기에 있습니다.
계측은 단순합니다. 압축 지점 이후 읽은 파일 경로와 그 이전에 기록된 경로의 교집합을 구합니다.
그 숫자가 있으면 어떤 작업 유형은 과감하게 압축해도 되고 어떤 유형은 안 되는지가 설계 논쟁이 아니라 조회 문제가 됩니다. 이 시리즈의 첫 노트와 같은 접근입니다. 먼저 측정하고 그다음 바꿉니다.
감안해서 읽어야 할 부분
이 내용은 아직 어느 것도 출시되지 않았습니다. 현재는 설계와 계측 단계입니다.
어떤 필드를 어느 정도 세밀하게 보존할지는 실제로 무엇을 다시 가져오는지에 관한 데이터에서 나와야 합니다. 지금 결정하면 잘못 결정하기 쉽습니다.
또한 이는 여러 접근 중 하나입니다. 다른 형태의 제품에서는 경계를 어디에 두고 필드를 어떻게 정의할지 완전히 달라질 수 있습니다. 네 가지 사례의 체크리스트는 다른 곳에도 적용할 수 있지만 구체적인 답은 그렇지 않습니다.
이 시리즈의 다음이자 마지막 노트는 자기 성찰을 다룹니다. 에이전트가 정리한 교훈이 왜 계속 "더 조심하자"처럼 일반적인 말로 나오는지, 그리고 그 입력에 무엇이 들어 있고 무엇이 없는지에 관한 매우 놀라운 사실 하나를 살펴봅니다.