코딩 에이전트는 압축보다 편집할 파일 전체를 보여줄 때 더 많은 이슈를 해결한다

무엇인가

이 논문은 코딩 에이전트가 저장소 전체를 컨텍스트에 넣을 수 없을 때, 고정된 토큰 예산을 어떻게 써야 이슈를 더 많이 해결하는지를 다룬다. 이슈 패치는 바꿔야 할 파일과 그 파일의 코드가 원문 그대로 있어야 한다. 모델이 수정할 줄을 그대로 인용해야 하기 때문이다. 그런데 검색기는 이슈와 비슷한 코드를 우선해 실제로 고쳐야 할 파일을 놓치고, 압축기는 예산에 맞추려고 텍스트를 삭제해 코드를 바꾼다. 논문은 SWE-bench 코드베이스가 평균 3,010개의 비테스트 파일과 438K줄이라는 규모를 들어 이 문제를 실무적인 질문으로 만든다.

어떻게 동작하나

제안 방법 CQ2-CARE는 압축 모델 없이 파일 단위 선택에 예산을 쓴다. 먼저 이슈와 단어를 가장 많이 공유하는 경로 목록을 τ=1/2 min(|P|,32K) 토큰까지 알파벳순으로 보여주고, 모델에게 '어떤 파일이 바뀌어야 하나'를 독립적으로 두 번 묻는다. 두 답이 모두 지목한 파일을 고르고, 테스트·문서 디렉터리는 제외하며, 남는 파일이 없으면 첫 답으로 폴백한다. 이어 모델이 이슈와 선택 파일을 읽고 최대 네 개의 타입 지정 검색을 요청하면 grep으로 정의·호출자·문자열을 찾아 최대 8개 파일의 근거 span을 붙인다. 최종 컨텍스트는 선택 파일을 전체 원문으로 넣고 근거 span을 덧붙이며, 각 블록은 앞 c개 토큰으로 자르고 80K 토큰을 넘길 블록은 건너뛴다. 이 방식의 핵심은 샘플 합의 자체가 아니라 적은 수의 파일을 잘 고르는 데 있다. 같은 수의 파일로 자른 단일 답도 비슷한 성능을 냈다.

무엇과 다른가

실험은 SWE-rebench 리더보드에서 저장소당 하나씩 뽑은 300개 이슈로 한다. 2025년 1월부터 2026년 5월 사이 생성된 Python 이슈이며, 340개 후보 중 gold 패치가 해결하고 빈 패치가 해결하지 못하는 328개를 추린 뒤 처음 300개를 썼다. 모든 방법은 같은 파이프라인에서 컨텍스트 단계만 바꾸고, 이슈별 예산 B_i는 CQ2-CARE 컨텍스트의 실제 토큰 수로 맞춘다. 비교 대상은 LLMLingua-2, LongLLMLingua, LongCodeZip 압축기 세 개와 청크 BM25, CodeRankEmbed 밀집 검색, SWE-bench의 파일 단위 BM25 검색기 세 개다. 여기에 이슈 해결용으로 학습된 SWE-Pruner와 SweRank, gold 파일을 보여주는 상한 오라클, 이슈만 주는 no-source 조건을 더했다. 모델은 GPT-5.6과 Claude Opus 5를 모든 호출에 쓰고, 공식 하네스의 테스트로 채점하며 파싱·적용 실패 패치는 미해결로 센다.

어떻게 쓰나

결과는 CQ2-CARE가 GPT-5.6에서 43.7%, Claude Opus 5에서 46.7%의 이슈를 해결했다는 것이다. 이는 두 모델 각각에서 가장 좋은 압축기보다 6.3포인트 높고, 가장 좋은 검색기보다 9.3포인트와 12.7포인트 높다. 파일 단위 BM25도 전체 파일을 보여주지만 이슈 유사도로 고르기 때문에 9.3포인트와 12.7포인트 뒤진다. 학습된 방법과 비교하면 SWE-Pruner를 2.0포인트와 7.3포인트 앞서고, SweRank에는 0.7포인트와 1.7포인트 앞선다. gold 파일을 직접 보여주는 오라클은 GPT-5.6에서 CQ2-CARE보다 5.7포인트 높을 뿐이고 Claude에서는 차이가 없었다. 가장 좁은 유의차는 Claude에서 LLMLingua-2를 상대로 한 p=0.027이다.

전제와 한계

분석은 두 베이스라인 계열의 실패가 서로 다르다는 점을 보여준다. 청크 BM25와 밀집 검색은 컨텍스트 줄의 5분의 1 이하만 실제 수정 파일에 넣고, 4분의 1이 넘는 이슈에서는 수정 파일을 아예 보여주지 않는다. CQ2-CARE는 그 비율이 절반이다. 압축기는 파일을 남겨도 텍스트를 바꿔 패치 적용률을 떨어뜨린다. LongCodeZip은 원문 줄 96.8%와 패치 적용률 89.7%, LLMLingua-2는 17.5%와 70.7%, CQ2-CARE는 98.0%다. CQ2-CARE가 해결하고 LLMLingua-2가 해결하지 못한 48개 이슈 중 28개는 패치가 적용되지 않은 경우다. SWE-Pruner는 원문 줄을 91.7% 유지하지만 파일 안에 남긴 구멍 때문에 GPT-5.6에서 93.0%, Claude에서 73.7%만 적용됐고, CQ2-CARE는 98.0%와 83.3%다. 통제 실험에서 자체 컨텍스트의 모든 줄에서 토큰 20%를 지우면 적용률이 98.0%에서 78.7%로 떨어지고 해결률은 9.7포인트 낮아졌다(p<0.001). 같은 파일에서 시작해 줄 단위로 자르는 압축기는 CQ2-CARE와 비슷했다. LongCodeZip은 CQ2-CARE의 후보 파일을 잘라 44.7%를 해결해 43.7%를 앞섰다. 저자들은 이를 순위가 아니라 규칙으로 읽는다. 후보 파일을 잘 고른 뒤, 잘라야 한다면 줄 단위로 잘라야 한다.

개발자에게 이 논문은 컨텍스트 예산을 검색기나 토큰 압축기에 맡기기 전에 파일 선택과 원문 보존을 먼저 설계하라는 근거가 된다. 코드 수정 에이전트는 이슈와 비슷한 코드가 아니라 실제로 바뀌어야 할 파일을 보여줘야 하고, 모델이 인용할 줄은 압축으로 변형되지 않아야 한다. 비용 측면에서 CQ2-CARE 전체 파이프라인은 GPT-5.6 기준 이슈당 0.151달러로, 단일 드로우 0.199달러와 압축기 컨텍스트의 API 호출만 0.168~0.177달러보다 낮다. 토큰도 GPT-5.6에서 0.68배, Claude에서 0.73배를 쓴다. 압축기들은 이슈당 중앙값 34~37초의 GPU 시간을 썼고 Claude의 더 큰 컨텍스트에서는 84~97초가 걸렸으며 LongCodeZip은 48GB에서 4개 이슈에 OOM이 났다. 다만 이 수치는 한 번의 패치 호출을 전제로 한 것이고, 파일을 다시 읽는 멀티턴 에이전트 루프에서의 이득은 측정하지 않았다.

저자들이 밝힌 한계는 분명하다. 실험은 하나의 벤치마크에서 Python 이슈를 대상으로 컨텍스트당 한 번의 패치 호출만 평가했고, 여러 턴에 걸쳐 파일을 더 읽거나 테스트를 실행하는 에이전트는 다루지 않았다. 예산 B_i가 CQ2-CARE 컨텍스트의 실제 크기라서 자기 방법의 동작점에서 비교한 것이며, 100개 이슈 rate sweep이 다른 예산을 일부 덮는다. 파일 단위 BM25, 통제 실험, SWE-Pruner의 단일 턴 모드, SweRank는 주 결과 이후에 추가됐고, SweRank는 같은 저장소의 다른 PR로 학습했을 수 있어 작은 차이가 동등한 성능을 뜻하지 않는다. 대부분 셀은 패치 표본이 하나라 두 번째 표본에서 결과의 8.7~18.9%가 뒤집혔고, Claude 대 LLMLingua-2의 p=0.027 같은 작은 차이는 취약하다. 이슈가 모델 학습 데이터와 겹칠 수 있지만 최신 이슈에서 격차가 줄어드는 것은 관측되지 않았고, 일부는 CQ2-CARE 개발 중 본 저장소에서 나왔을 수 있다.