코딩 에이전트는 문맥을 압축하기보다 수정할 파일을 잘 고르는 편이 나을까
300개 Python 이슈의 단일 수정 실험에서, 파일 선택과 원문 줄 보존이 압축률보다 중요한 이유를 분석합니다.
쉽게 말하면비유하자면 두꺼운 설명서에서 고칠 쪽을 찾아 수리공에게 넘기는 일이다. 글자를 듬성듬성 지워 얇게 만들기보다, 고칠 쪽을 정확히 골라 원문 그대로 보여 주는 편이 중요했다. 수리공은 고칠 줄을 원문대로 짚어야 하기 때문이다.
- 왜 봐야 하나
- 코딩 에이전트에 보여 줄 코드를 줄여야 한다면 고칠 파일을 고르는 데 먼저 공을 들이고, 그 파일은 줄 단위 원문으로 보여 주라는 뜻이다. 다만 수정안을 한 번만 만드는 Python 실험이고, 같은 후보 파일을 준 압축 방식 LongCodeZip도 비슷한 점수를 냈다.
이 논문은 코딩 에이전트가 제한된 문맥 예산으로 버그를 고칠 때, 무엇을 읽고 어떤 형태로 보존해야 하는지 비교한다. 저자들의 CQ2-CARE는 수정할 파일을 좁힌 뒤 코드 원문과 추가 근거 구간을 보여준다. 서로 다른 저장소의 Python 이슈 300개에서 한 번의 패치 생성으로 평가한 결과, 해결률은 GPT-5.6 43.7%, Claude Opus 5 46.7%였다. 이는 처음 비교한 일반 압축·검색 기준선보다 높았지만, 나중에 추가한 학습형 검색기 SweRank와의 차이는 0.7~1.7%p로 유의하지 않았다. 같은 후보 파일을 준 LongCodeZip도 GPT에서 44.7%로 비슷했다. 따라서 모든 압축을 버리라는 결론보다는, 바꿀 파일을 잘 찾고 수정 도구가 대조할 원문 줄을 지키라는 설계상의 교훈이 핵심이다.
알아낸 것
- Python 이슈 300개에서 선택한 코드 문맥을 한 번 전달하고, 한 번 생성한 패치를 테스트하는 조건으로 비교했습니다.
- GPT 조건에서 CQ2-CARE의 해결률은 43.7%였으며, 패치 적용 성공률 98.0%와는 다른 지표입니다.
- 동일한 후보 파일을 제공한 LongCodeZip의 해결률은 44.7%였습니다. 파일 선택의 차이를 압축 자체의 효과와 분리해 읽어야 합니다.
한계와 주의할 점
- 공개 논문의 저자 실험을 검토했으며 동료 심사 통과나 독립 재현을 확인한 것은 아닙니다.
- Python 이슈와 정해진 모델의 단일 패치 생성 조건입니다. 파일을 다시 읽고 테스트하며 수정하는 다중 턴 에이전트 전체에 일반화할 수 없습니다.
- 비교 문맥 예산은 이슈·모델별로 새 방법이 실제 사용한 길이에 맞췄습니다. 모든 모델과 과제에 동일한 고정 예산을 준 실험은 아닙니다.
- 같은 후보 파일을 주었을 때의 반대 결과도 있어, 압축이 언제나 불리하다거나 파일 선택법이 모든 비교 방법보다 우월하다고 결론 내릴 수 없습니다.
용어 풀이
- 패치 적용률 (patch applicability)
- 모델이 생성한 패치가 원본 코드에 실제로 적용될 수 있는 비율. 패치가 적용되지 않으면 이슈가 해결될 수 없으므로, 압축으로 인한 텍스트 변형이 해결률에 미치는 영향을 보여주는 중간 지표다.
- 통합 diff (unified diff)
- 코드 변경 사항을 표현하는 표준 형식. 파일 경로와 줄 번호, 변경 내용을 포함한다. 이 연구에서 모델은 이 형식으로 패치를 출력하며, 패치가 적용 가능하려면 원본 코드의 줄을 정확히 인용해야 한다.
더 깊이 읽기 읽는 데 약 9분
배경과 문제
코딩 에이전트는 이슈를 읽고 저장소를 탐색한 뒤 테스트를 통과하는 패치를 작성한다. 하지만 저장소는 보통 모델의 컨텍스트 창보다 훨씬 크다. SWE-bench 저장소는 평균 3,010개의 비테스트 파일과 438K줄의 코드를 가지므로, 모든 코드를 프롬프트에 넣을 수 없다. 따라서 저장소를 '압축된 뷰'로 만들어 모델에게 보여주는 것이 필요하다. 이때 뷰는 두 가지를 반드시 유지해야 한다. 첫째, 수정해야 할 파일이 포함되어야 하고, 둘째, 그 파일의 텍스트가 원문 그대로여야 한다. 왜냐하면 모델은 편집할 줄을 정확히 인용해야 하기 때문이다.
기존 연구는 작은 모델이 덜 중요하다고 판단한 토큰이나 문장을 삭제하는 프롬프트 압축, 이슈와 유사한 코드 조각이나 파일을 찾는 검색, 에이전트가 읽을 내용을 가지치기하거나 알려진 결함 위치 주변만 줄이는 방식 등을 다룬다. 이 논문은 각 방법이 어떤 파일을 문맥에 넣을지 결정하도록 허용한 뒤, 이슈별 예산을 맞춰 패치 해결률과 실패 원인을 비교한다. 코드 편집에서는 내용의 의미뿐 아니라 수정할 문자열이 실제 저장소와 일치하는지도 중요하다는 점에 초점을 둔다.
기존 접근의 한계
검색기는 코드를 이슈와의 유사성으로 순위 매긴다. 그런데 이슈 보고서의 단어를 반복하는 다른 코드나 문서가 수정할 파일보다 높은 순위를 차지할 수 있다. 표 2의 GPT 분석은 정답 패치가 기존 파일을 고치는 298개 이슈를 대상으로 한다. 청크 BM25와 밀집 검색의 문맥에서 수정 대상 파일에 속한 줄은 각각 20.9%, 16.5%였고, 수정할 파일을 하나도 보여주지 못한 이슈는 각각 26.2%, 27.5%였다. 파일 단위 BM25는 전체 파일을 보여주므로 패치가 적용되는 경우는 많아지지만, 어떤 파일을 골랐는지의 문제는 남는다.
토큰 압축기는 수정할 파일을 남기더라도 코드 텍스트를 바꿀 수 있다. 예를 들어 LLMLingua-2가 f-string의 f 접두사를 삭제하면, 모델은 원본에 존재하지 않는 줄을 대상으로 패치를 작성할 수 있다. 표 1의 GPT 조건에서 LLMLingua-2 문맥의 원문 그대로인 줄은 17.5%, 패치 적용률은 70.7%였고, CQ2-CARE의 적용률은 98.0%였다. 이는 코드가 대강 이해되는 것과 원본에서 변경 위치를 정확히 찾는 것이 다르다는 점을 보여준다. 다만 모든 압축기가 같은 방식으로 문자를 지우는 것은 아니므로, 전체 줄을 유지하는 방식까지 같은 위험으로 묶으면 안 된다.
연구방법을 단계별로
CQ2-CARE는 먼저 저장소 경로 목록만 보고 어떤 파일을 고쳐야 할지 모델에게 묻는다. 실험에서는 독립 순위 목록 다섯 개를 만들고 해시로 교집합용 두 목록과 대체용 한 목록을 정한다. 두 목록에 함께 나온 파일 중 테스트·문서 경로를 제외해 선택하고, 남는 파일이 없으면 대체 목록을 쓴다. 이후 선택 파일을 읽고 정의나 호출자 등을 찾는 검색을 최대 4개 요청하며, 추가 파일 최대 8개의 근거 구간을 더한다. 선택 파일과 근거를 합치지만 코드 블록 60K·근거 블록 12K·전체 80K 토큰 상한이 있으므로, 매우 큰 파일도 언제나 완전히 보존되는 것은 아니다. 정답 패치는 선택 과정에 제공하지 않는다.
이슈별 예산은 CQ2-CARE가 만든 문맥의 실제 토큰 수로 정하고, 다른 방법의 길이를 그 예산에 맞춘다. 압축기는 자체 설정으로 ±2%를 목표로 조정하고, 검색기는 순위대로 채우지만 정확한 일치는 항상 가능하지 않았다. 모델은 GPT-5.6의 gpt-5.6-sol 중간 추론 설정과 Claude Opus 5이며, 같은 모델이 해당 조건의 모든 호출을 맡는다. SWE-rebench에서 저장소당 한 이슈를 해시로 골라 정답 패치는 통과하고 빈 패치는 실패하는지 검사한 뒤 300개를 평가했다. 각 이슈는 문맥을 받아 unified diff 패치 하나를 만들고 공식 테스트 계열의 채점으로 해결 여부를 판단한다. 비교는 이슈별 짝을 이룬다.
결과와 숫자의 의미
표 1에서 해결률은 CQ2-CARE가 GPT 43.7%, Claude 46.7%였다. 처음 비교한 압축기 세 가지 중 최고는 GPT의 LongCodeZip 37.3%, Claude의 LLMLingua-2 40.3%로, 각각 6.3%p 차이다. 나중에 추가한 SWE-Pruner는 41.7%와 39.3%여서 GPT에서는 차이가 2.0%p로 줄고 유의하지 않았다. 처음 비교한 검색 기준선 중 최고 대비 차이는 9.3%p와 12.7%p지만, 추가된 학습형 SweRank는 43.0%와 45.0%로 0.7·1.7%p 뒤였다. 이 작은 차이는 유의하지 않으며, 그렇다고 두 방법의 동등성을 증명한 것도 아니다. 모든 비교군을 합쳐 최고 압축기·검색기보다 큰 폭으로 앞섰다고 읽으면 틀린다.
패치 적용률과 해결률도 구분해야 한다. CQ2-CARE의 적용률은 GPT 98.0%, Claude 83.3%이며, 적용된 패치라도 테스트를 통과하지 못할 수 있다. GPT에서 CQ2-CARE만 해결하고 LLMLingua-2가 실패한 48개 이슈 중 28개는 후자의 패치가 적용되지 않았다. 같은 파일을 둔 채 자체 문맥의 모든 줄에서 토큰 20%를 지운 통제 실험에서는 적용률이 98.0%에서 78.7%, 해결률은 43.7%에서 34.0%로 떨어졌다. 이는 문자 손상의 영향을 보여주지만 실제 압축기 모두와 동일한 실험은 아니다. 평균 문맥은 GPT 13.8K, Claude 27.1K로, 두 모델 사이까지 같은 토큰 예산으로 비교한 결과도 아니다.
구체적인 예시
그림 1은 pypa__twine-1225 이슈를 보여준다. 일부 오류 메시지에 f-string의 f가 빠져 있다는 보고이며 정답 패치는 twine/sdist.py를 수정한다. 청크 BM25는 이슈 템플릿 파일로 예산을 채워 수정할 파일을 보여주지 못했고, 모델이 추측한 줄의 패치가 적용되지 않았다. LLMLingua-2는 해당 파일을 남겼지만 이미 올바르던 다른 줄의 f를 삭제해 원본에 없는 코드를 보여주었다. 반면 CQ2-CARE는 원문을 보여주어 모델이 실제로 f가 빠진 줄을 고쳤다. 저자가 설명을 위해 고른 사례이며, 이 한 건으로 전체 실패 원인의 빈도를 판단할 수는 없다.
또 다른 예로 표 3의 iterative__dvc-10844 이슈가 있다. 이 이슈는 dvc add와 dvc diff를 실행하는 셸 스크립트에 관한 것이다. 정답 패치는 dvc/repo/diff.py를 수정한다. 청크 BM25는 그 명령어를 공유하는 테스트 파일 7개로 예산을 채웠고, 밀집 검색도 diff 명령의 테스트로 채웠다. 두 검색기 모두 수정할 파일을 보여주지 못했다. 파일 단위 BM25는 cli/parser.py와 commands/diff.py를 보여주었지만, 실제 수정 파일은 repo/diff.py였다. CQ2-CARE만이 repo/diff.py 전체와 호출자, 관련 테스트 2개를 보여주어 이슈를 해결했다. 이 예시는 검색기가 이슈의 단어를 반복하는 다른 코드에 끌리는 문제를 잘 보여준다.
한계와 오해하기 쉬운 점
이 연구는 단일 패치 호출을 평가한다. 파일을 다시 읽거나 테스트를 실행하며 수정하는 다중 턴 코딩 에이전트 전체의 성능은 검증하지 않았다. 실제 에이전트는 압축된 뷰에서 힌트를 얻고 원본을 다시 읽어 손실을 일부 회복할 수 있다. 다만 그만큼 턴과 토큰이 들고, 모델이 변형된 문자열을 원본으로 믿으면 재확인을 하지 않을 수도 있다. 따라서 이 실험의 해결률을 그대로 완전한 개발 에이전트의 성공률이나 다른 프로그래밍 언어의 성능으로 옮겨서는 안 된다.
예산 설정에도 주의가 필요하다. 기준 예산 Bi는 CQ2-CARE의 실현 길이이므로, 이 방법의 동작점에서 비교한 것이다. 압축기가 예산 미만으로 떨어지는 경우가 있고, LongCodeZip 한 건은 1.97Bi까지 초과했다. 100개 이슈에 대한 예산 비율 실험은 다른 동작점을 다루지만, 모든 조건에서 완벽한 동일 길이를 보장하지는 않는다. 또한, 대부분의 셀은 패치 표본이 1회뿐이며, 재실행 시 8.7~18.9%의 이슈 결과가 바뀌었다. 따라서 Claude의 LLMLingua-2에 대한 작은 우위(p=0.027)는 취약할 수 있다. 학습 데이터 오염 가능성도 남으며, 저자 분석에서는 새로운 이슈에서 격차가 작아진다는 뚜렷한 증거를 찾지 못했다. 이것이 오염이 없음을 입증하지는 않는다.
실제로 어떻게 활용할까
코딩 에이전트를 구축할 때 컨텍스트를 줄여야 한다면, 먼저 수정할 파일을 잘 선택하는 데 예산을 쓰는 것이 좋다. 선택한 파일은 원문 그대로, 가능하면 전체 줄 단위로 보여주어야 한다. 만약 추가로 줄여야 한다면, 토큰 단위 압축보다는 전체 줄을 유지하는 방식이 낫다. 통제 실험에서 같은 후보 파일을 LLMLingua-2의 점수로 줄 단위로 선택하면 40.7%, 토큰 단위로 선택하면 36.3%로 차이가 났다. LongCodeZip은 같은 후보 파일을 압축했을 때 44.7%로 CQ2-CARE의 43.7%와 비슷했다. 이는 파일 선택이 동일하다면 압축 방식의 차이가 줄어든다는 것을 의미한다.
평가할 때는 중간 지표보다 최종 테스트 해결률을 사용해야 한다. 예를 들어, 두 샘플 간 합의는 파일 수준 F1을 0.430에서 0.613으로 크게 높였지만, 같은 수의 파일로 자른 단일 샘플도 0.600에 도달했고 해결률도 비슷했다. 따라서 합의 자체가 독립적인 성공 요인이라고 단정할 수 없다. 또한, 종료 코드만으로 평가하면 빈 패치가 해결로 잘못 인정될 수 있다. 저자들은 이전에 종료 코드 기반 평가를 사용했을 때 6개 이슈 중 4개에서 빈 패치가 해결로 인정된 것을 발견했다. 따라서 벤치마크의 공식 테스트로 평가하는 것이 중요하다.
원문에서 확인한 근거 5곳
- CQ2-CARE의 해결률은 GPT-5.6 43.7%, Claude Opus5 46.7%다. GPT의 SWE-Pruner는41.7%, SweRank는43.0%이며, Claude의 SweRank는45.0%다. 처음 비교한 일반 압축·검색 기준선과 사후 추가 학습형 방법을 구분해야 한다.Table 1
- 정답 패치가 기존 파일을 수정하는 GPT 조건298개 이슈에서, 청크BM25·밀집검색 문맥의 수정대상 파일 줄 비율은20.9·16.5%, 해당 파일을 하나도 못 보여준 이슈는26.2·27.5%다.Table 2
- GPT-5.6 조건에서 LLMLingua-2 문맥의 원문 그대로인 줄은17.5%, 패치 적용률은70.7%였고 CQ2-CARE 적용률은98.0%였다.Table 1
- GPT-5.6에서 같은 후보 파일을 준 LongCodeZip은 해결44.7%로 CQ2-CARE43.7%와 비슷했고, LLMLingua-2 점수의 줄 단위 선택은40.7%, 토큰 단위 선택은36.3%였다.Table 8
- GPT-5.6에서 CQ2-CARE 문맥 모든 줄의 토큰20%를 삭제한 통제실험은 패치 적용률98.0→78.7%, 해결률43.7→34.0%였다.Table 8
10월 20일(화) 정리 · AI가 쓰고 원문과 대조