ContextPilot: 긴 작업에서 에이전트가 맥락을 스스로 정리하는 방법 | DAKER 커뮤니티
긴 조사, 검색, 코딩처럼 여러 턴에 걸쳐 이어지는 작업에서는 답을 잘 만드는 능력만으로는 부족합니다. 앞에서 모은 정보를 어떻게 남기고, 무엇을 덜어내고, 언제 다시 꺼내 쓸지까지 함께 설계해야 작업이 무너지지 않습니다.
2026년 8월 28일 arXiv에 공개된 ContextPilot은 바로 이 지점을 다룹니다. 모든 기록을 계속 붙여 넣는 대신, 에이전트가 작업 맥락을 스스로 정리하도록 도구와 학습 방식을 함께 제안합니다. 이 글은 arXiv:2608.28476 초록과 공개 정보 범위 안에서만 내용을 옮깁니다.
2026년 8월 28일 Zhuoshi Pan 연구팀이 긴 구간 에이전트 작업에서 맥락을 스스로 정리하는 ContextPilot을 arXiv에 공개했습니다. EMNLP 2026 Main Track에 채택되었습니다.
논문은 2026년 8월 28일 arXiv에 올라왔습니다. 초록은 arXiv:2608.28476에서 확인할 수 있습니다. 저자는 Zhuoshi Pan, Qizhi Pei, Junru Lu, Honglin Lin, H. Vicky Zhao, Di Yin, Xing Sun입니다. 코멘트에는 10 pages, 6 figures, 5 tables, accepted to EMNLP 2026 (Main Track)라고 적혀 있습니다. PDF는 같은 번호의 pdf입니다. 코드는 GitHub Tencent/ContextPilot에 공개되어 있습니다.
긴 작업에서 왜 맥락 관리가 문제인지
긴 구간 에이전트 과제는 모델이 여러 턴에 걸쳐 흩어진 정보를 가져오고, 합치고, 유지해야 하는 작업입니다. 이때 모든 상호작용 기록을 그대로 남기면 작업 맥락이 계속 커집니다. 최근에는 전용 도구를 써서 작업 맥락을 능동적으로 편집하는 방법들이 나왔지만, 초록은 여기에 여전히 한계가 남아 있다고 설명합니다.
첫째, 도구셋이 검색·삭제·요약에 머물러 전역 계획, 장기 기억, 적응적 압축을 충분히 지원하지 못합니다. 둘째, 맥락 관리 행동이 최종 결과에 미치는 영향은 서로 다른데도 탐색 과정에서 이를 균일하게 다루기 쉽습니다. 셋째, RL에서는 궤적 단위의 최종 보상을 중간의 여러 맥락 편집에 거칠게 나누어 주는 문제가 있습니다.
기록이 늘어날수록 계획·기억·오프로딩 도구를 함께 설계해야 합니다.
이 문제의식은 긴 조사나 deep search 성격의 작업을 다루는 팀에도 그대로 이어집니다. 단순히 컨텍스트 창을 키우는 것과, 작업 맥락을 편집하는 도구와 학습을 설계하는 것은 같은 문제가 아닙니다.
ContextPilot이 더한 것
ContextPilot은 도구셋을 계획, 장기 기억, 소프트 맥락 오프로딩까지 확장합니다. 초록에 따르면 기존의 검색·삭제·요약 중심 접근을 넘어, 앞으로 필요한 정보를 미리 정리하고, 작업 맥락 밖에 둘 내용을 저장하고, 지금 창에서 덜어낸 내용을 다시 불러올 수 있게 하는 방향입니다.
여기에 맥락 관리에 맞춘 RL도 더합니다. 맥락과 엔트로피 변화를 이용해 중요한 편집 결정을 고르고, 분기 샘플링을 하며, 해당 맥락 편집 행동을 지나는 모든 분기 궤적에서 행동 단위 어드밴티지를 추정한다고 초록은 설명합니다.
ContextPilot은 계획·장기 기억·소프트 오프로딩을 도구에 더하고, 맥락·엔트로피 변화로 중요한 편집을 고르는 세분 RL을 제안합니다.
무엇을 개선하려는 접근인지
초록이 강조하는 핵심은 맥락 관리 행동의 영향이 서로 다르다는 점입니다. 모든 편집을 같은 무게로 다루면 중요한 압축이나 오프로딩 결정이 묻힐 수 있습니다. ContextPilot은 이 차이를 반영해 중요한 편집 지점을 더 잘 찾고, 그 편집이 최종 결과에 어떤 기여를 했는지 더 세밀하게 보려는 접근으로 읽힙니다.
또 하나의 포인트는 압축과 성능을 함께 본다는 점입니다. 초록은 긴 맥락 QA와 deep search 과제에서 ContextPilot이 더 작은 작업 맥락으로도 더 강한 성능을 낸다고 말합니다. 여러 베이스 모델과 벤치에서 기존 기준선을 일관되게 앞섰다고도 적고 있습니다. 다만 이 글은 초록 범위만 다루므로, 초록에 없는 벤치 이름이나 퍼센트 수치는 옮기지 않습니다.
더 압축된 작업 맥락과 더 강한 성능을 함께 보고합니다.
실무에서 읽을 만한 지점
이 논문이 바로 제품 처방을 대신해 주는 것은 아니지만, 긴 작업을 다루는 팀이 체크할 기준은 분명하게 남깁니다. 맥락 관리 도구가 검색·삭제·요약에만 머물러 있는지, 계획과 장기 기억, 오프로딩까지 포함하는지 먼저 구분해 볼 수 있습니다.
또 맥락 편집 로그를 볼 때도 길이 변화만이 아니라 어떤 편집이 중요한 전환점이었는지 함께 살펴보는 것이 좋습니다. 최종 답이 맞았는지만 보는 방식으로는 중간 편집의 실패를 놓치기 쉽고, 반대로 길이만 줄었다고 해서 좋은 맥락 관리라고 보기도 어렵습니다.
특히 deep search처럼 출처를 모으고 중간 결론을 누적하는 작업에서는, 무엇을 현재 작업 맥락에 두고 무엇을 바깥 기억으로 내릴지 구분하는 설계가 중요해집니다. ContextPilot은 이 구분을 도구 차원과 학습 차원에서 함께 다루려는 시도라고 볼 수 있습니다.
이 글이 다루는 범위
이 글은 논문의 초록과 공개 정보만 바탕으로 정리했습니다. 따라서 특정 벤치 점수표를 소개하는 글이 아니며, 초록에 없는 수치나 비교 결과는 덧붙이지 않았습니다. 또한 컨텍스트 창만 키우면 된다는 주장도 아니고, 특정 회사 제품 출시 공지도 아닙니다.
핵심은 능동 맥락 관리의 범위를 넓히고, 그 편집 행동을 더 세밀하게 학습시키려는 제안이 나왔다는 점입니다. 긴 작업을 다루는 에이전트 설계에서 이 문제를 따로 떼어 볼 필요가 있다는 점도 함께 남습니다.
참고 자료
arXiv:2608.28476 — ContextPilot
PDF
GitHub Tencent/ContextPilot
긴 작업을 다루는 에이전트를 만들고 있다면, 여러분 팀에서는 맥락 관리 도구를 어디까지 분리해 보고 계신가요?