상하이교통대 연구팀이 발표한 SWE-Pruner Pro는 별도 분류기 없이 백본 LLM의 히든 스테이트를 읽어 도구 출력을 라인 단위로 정리한다. 토큰을 최대 39.4% 절감하면서 SWE-Bench Verified 해결률을 3.8%포인트 끌어올렸다.

코더 LLM은 이미 무엇을 버려야 할지 알고 있다. SWE-Pruner Pro

구분	내용
논문	SWE-Pruner Pro: The Coder LLM Already Knows What to Prune
발표	arXiv:2607.18213 (2026년 7월 20일 제출)
저자	Yuhang Wang와 Yuling Shi 외. 상하이교통대학(SJTU) 주도 연구팀
원문	arxiv.org/abs/2607.18213

코딩 에이전트를 운영해본 팀이라면 안다. 파일 읽기와 grep 그리고 테스트 트레이스백 같은 도구 출력이 컨텍스트에 쌓이면서 토큰 비용이 폭증한다. 정작 중요한 정보는 노이즈에 묻혀 품질까지 떨어진다. 이번 주 arXiv에 올라온 SWE-Pruner Pro는 이 문제에 우아한 답을 내놨다. 별도 모델 없이 에이전트 백본이 프리필 과정에서 이미 계산한 히든 스테이트를 그대로 읽어 컨텍스트를 잘라낸다.

핵심 통찰

기존 접근인 전작 SWE-Pruner는 컨텍스트를 정리하기 위해 별도의 분류기 모델을 붙였다. 추가 모델 호출과 추가 지연이 따라온다.

이 논문의 출발점은 간단한 실험이다. Qwen3-Coder-Next의 마지막 레이어 히든 스테이트에 선형 프로브(linear probe) 하나만 얹었더니 도구 출력의 라인별 중요도를 AUC 0.83으로 판별했다. 다수결 베이스라인의 F1이 0.46인데 프로브는 0.63을 기록했다. 백본이 도구 출력을 프리필하는 순간 이미 어떤 라인이 중요한지를 내부 표현에 인코딩하고 있다는 뜻이다. 남은 일은 그것을 읽어내는 것뿐이다.

방법

핵심은 프리필에 무임승차하는 프루닝 헤드다. 새 도구 응답이 프리필될 때 생성되는 히든 스테이트를 경량 헤드가 그대로 읽기 때문에 추가 포워드 패스가 없다. 헤드는 추론 엔진 내부에 코로케이션되어 프로세스 간 히든 스테이트 전송도 발생하지 않는다.

구성 요소	설명
길이 인식 임베딩	도구 출력의 라인 수 N에 따른 학습 임베딩 e(N)을 더한다. 5줄짜리 출력에서 2줄을 잘못 지우면 치명적이지만 300줄에서는 무시할 만하다는 직관을 반영한다
토큰별 분류기	LayerNorm과 2개의 Linear GELU Dropout 블록 뒤에 sigmoid로 토큰별 유지 확률을 계산한다
라인 단위 결정	토큰별 판정을 라인 단위 다수결로 집계한다
에이전트 루프 통합	현재 턴의 생성은 도구 응답 전문을 그대로 보고 다음 턴부터 프루닝된 버전이 히스토리를 대체한다. 유지되는 라인은 평균 원본의 약 30%다

학습 데이터는 실제 멀티턴 궤적 6,252개에서 뽑은 22,609개 샘플이다. Claude Sonnet 4.6이 라인별 유지 여부 레이블을 달았다. 백본은 동결하고 헤드만 학습하며 캐시된 피처 기준으로 8xH200 한 노드에서 약 15분이면 끝난다.

결과

MiMo-V2-Flash(309B MoE)와 Qwen3-Coder-Next(80B MoE) 두 백본에서 SWE-Bench Verified 등 4개 벤치마크로 검증했다.

벤치마크	토큰 절감	품질 변화
SWE-QA-Pro (Qwen3)	39.4% 절감 (607K에서 368K로)	judge 점수 0.24 상승
SWE-QA (Qwen3)	34.7% 절감 (590K에서 385K로)	judge 점수 0.02 상승
Oolong (MiMo)	30.1% 절감	정확도 2.2점 상승
SWE-Bench Verified (MiMo)	경쟁 프루너의 절반 수준 오버헤드	345/500 해결로 베이스라인(326) 대비 3.8%p 상승

비교 대상 프루너 중 모든 벤치마크에서 토큰을 줄인 것은 SWE-Pruner Pro가 유일하다. 흥미로운 것은 여러 항목에서 토큰을 줄이면서 품질이 오히려 올랐다는 점이다. 노이즈 제거가 곧 품질 개선이라는 방증이다. 오버헤드는 전체 생성 시간 대비 평균 15% 수준이다.

한계

히든 스테이트 접근이 필요하므로 오픈웨이트 백본 전용이다. GPT나 Claude 같은 클로즈드 API에는 적용할 수 없다. 벤치마크가 파이썬 중심이라는 점과 백본을 바꾸면 헤드를 재학습해야 한다는 점도 한계다.

Cortexys의 시각

코딩 에이전트의 비용 구조에서 도구 출력은 가장 큰 항목이다. 이 논문의 메시지는 명확하다. 컨텍스트 관리를 외부 모듈이 아니라 모델 내부 표현의 재활용 문제로 보라는 것이다. 자체 GPU에 오픈웨이트 코딩 모델을 서빙하는 팀이라면 15분 학습으로 토큰 30~40%를 절감하는 이 기법은 투자 대비 효과가 이례적으로 크다. vLLM 같은 추론 엔진에 이런 헤드가 표준 기능으로 들어오는 흐름도 머지않아 보인다.