SWE-bench: 언어 모델이 실제 GitHub 문제를 해결할 수 있을까?

CodeAct 논문은 LLM 에이전트를 위한 적절한 액션 형식으로 Python이 적합하다는 강력한 근거를 제시했습니다. 하지만 올바른 액션 형식을 선택하는 것은 문제의 절반에 불과합니다. 에이전트가 단순히 정제된 벤치마크가 아니라 실제 작업의 복잡성을 처리할 수 있음을 증명해야 합니다. 프린스턴 대학교의 Carlos Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan이 발표하고 ICLR 2024에서 소개된 SWE-bench (arXiv:2310.06770)는 이 격차에 정면으로 맞서게 한 논문입니다.

논문 내용

"SWE-bench: 언어 모델이 실제 GitHub 문제를 해결할 수 있을까?"는 astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy, xarray 등 12개의 인기 있는 Python 저장소에서 실제 병합된 풀 리퀘스트(PR)로부터 추출된 2,294개의 작업 인스턴스로 벤치마크를 구축합니다. 각 인스턴스는 모델에게 코드베이스 스냅샷과 GitHub 이슈 설명을 제공하며, 모델은 기존 테스트를 깨뜨리지 않으면서 지정된 실패 테스트 세트를 통과시키는 패치를 생성해야 합니다. 이 벤치마크는 약 90,000개의 PR을 마이닝하고, 연결된 이슈를 해결하면서 동시에 새로운 테스트를 추가한 PR을 필터링한 후 실행 기반의 통과/실패 전환을 검증하여 구축되었습니다. 이러한 엄격한 구축 방식은 모호하거나 쉽게 조작 가능한 정답(ground truth)이라는 일반적인 벤치마크 문제를 피합니다.

주요 개념

• 발표 당시 성능이 가장 좋았던 Claude 2는 BM25 희소 검색(모델이 스스로 관련 파일을 찾아야 하는 현실적인 배포 환경)을 사용했을 때 이슈의 1.96%만을 해결했습니다.
• 오라클 검색(모델에게 정확히 필요한 파일이 제공되는 환경)을 사용하면 Claude 2는 4.80%로 향상되지만, 이는 병목 현상이 부분적으로는 검색에 있지만 주로 편집 능력에 있음을 확인해 줍니다. 완벽한 컨텍스트가 주어져도 성공률은 5% 미만에 머뭅니다.
• GPT-4는 BM25 검색 사용 시 0.00%를 해결했으며(예산 문제로 25% 하위 집합에 대해 평가), 오라클 검색 시 1.74%를 해결했습니다. Claude 2의 경우 오라클에서 BM25로 전환 시 성능 하락이 심각했으며, GPT-4의 경우 완전한 실패로 이어졌습니다.
• 생성된 패치는 체계적으로 너무 짧습니다. Claude 2의 성공적인 패치는 평균 19.6행인 반면, 사람이 작성한 정답 패치는 74.5행입니다. 모델은 단순한 국소적 수정을 찾는 경향이 있는 반면, 사람은 여러 파일에 걸친 포괄적인 솔루션을 작성합니다.
• 더 많은 컨텍스트는 오히려 방해가 됩니다. 50k 토큰의 BM25는 13k 토큰보다 오라클 파일을 더 많이 검색하지만, 해결률은 종종 감소합니다. 긴 컨텍스트 속에 묻힌 관련 증거를 모델이 무시하는 "중간 실종(lost in the middle)" 효과는 여기서 입증된 실제 실패 모드입니다.
• 오라클 검색 컨텍스트로 미세 조정된 SWE-Llama 13b는 오라클 환경에서 4.00%를 달성하지만 BM25에서는 0.70%에 불과합니다. 완벽한 컨텍스트에서만 훈련하면 검색 환경이 현실적일 때 무너지는 취약한 에이전트가 생성됩니다.

유효한 점과 그렇지 않은 점

벤치마크 구축 방식은 매우 엄격합니다. 테스트를 실제로 실행하여 통과 여부를 확인하는 실행 기반 평가는 코드 편집 작업의 올바른 기준입니다. 이는 객관적이고 자동화가 가능하며 조작하기 어렵습니다. 단순한 패치 적용이 아니라 실패에서 통과로의 전환(fail-to-pass transitions)을 요구한 결정은 특히 중요합니다. 이는 무의미한 작업(no-ops)이나 삭제와 같이 사소하고 정확해 보이는 패치를 방지합니다.

결과는 놀라울 정도로 잘 유지되고 있습니다. SWE-bench는 2023년 10월에 발표되어 빠르게 코딩 에이전트의 사실상 표준 평가 도구가 되었습니다. 초기 1.96%의 기준선은 단순히 선별된 결과가 아니라 진정으로 유익한 정보를 제공합니다. 관련 그룹에서 2024년에 발표한 SWE-agent는 에이전트-컴퓨터 인터페이스를 재설계하여 이 수치를 12.47%로 끌어올렸으며, 이는 원래의 기준선이 얼마나 많은 개선의 여지를 남겨두었는지 확인시켜 주었습니다.

이 논문이 잘 다루지 못한 두 가지 점이 있습니다. 첫째, 벤치마크가 Python 전용이라는 점입니다. 이는 현실적인 필요에 의한 것이지만 Python의 관습에 과적합될 위험이 있습니다. 둘째, 이 논문은 검색 증강 생성(RAG) 기준선만 제안하고 에이전트 기반 접근 방식은 명시적으로 향후 연구로 미루었습니다. 2023년 당시에는 적절한 지연이었지만, 결과적으로 이 논문 자체는 어떤 에이전트 아키텍처가 도움이 되는지에 대한 신호를 제공하지 못합니다.

"오라클" 설정 또한 보기보다 약한 상한선입니다. 완벽한 파일 컨텍스트를 제공한다고 해서 해당 파일 내의 코드 위치를 찾는 문제가 해결되는 것은 아니며, 모듈 간의 상호작용에 대한 다중 파일 추론에도 도움이 되지 않습니다. 오라클 환경에서 Claude 2가 4.8%를 기록했다는 것은 컨텍스트에 올바른 파일이 있더라도 모델이 95%의 확률로 실패한다는 것을 의미합니다. 문제는 일차적으로 검색에 있는 것이 아닙니다.

금융 AI에 중요한 이유

Beancount는 GitHub에 호스팅된 Python 프로젝트입니다. Beancount를 위한 쓰기 자동화(write-back) 에이전트는 본질적으로 SWE-bench 스타일의 작업을 통과해야 하는 에이전트입니다. 즉, 장부 파일과 명령("이 트랜잭션 추가", "이 잔액 불일치 수정")이 주어졌을 때, 기존 어설션(assertion)을 깨뜨리지 않고 bean-check를 통과하는 수정을 생성해야 합니다.

검색 실패는 장부 위치 찾기 문제와 직접적으로 유사합니다. 사용자가 "3분기 사무용품 비용 과다 계상을 수정해 줘"라고 말할 때, 에이전트는 먼저 수천 행이 포함될 수 있는 파일에서 관련 항목을 찾아야 합니다. 이는 SWE-bench 인스턴스의 40~50%에서 BM25가 실패하는 파일 위치 찾기 작업과 동일합니다. "중간 실종" 성능 저하는 긴 .beancount 파일에도 똑같이 적용되며, 이전 날짜의 항목들이 무시될 가능성이 높습니다.

패치 길이의 비대칭성은 실질적인 경고입니다. 모델은 너무 좁게 패치합니다. 회계에서 이는 상쇄 항목을 놓치고 하나의 항목만 수정하거나, 실행 잔액(running balance)을 그대로 둔 채 비용 라인만 업데이트하는 결과로 이어집니다. 실무용 Beancount 에이전트에는 bean-check, 잔액 어설션 또는 명시적인 조정(reconciliation) 단계와 같은 검증 계층이 필요합니다. 이를 통해 에이전트가 단순히 국소적인 타당성만 보는 것이 아니라 수정의 전체적인 결과를 확인하도록 강제해야 합니다.

오라클과 BM25의 격차는 검색 품질이 에이전트 품질과 분리될 수 없음을 상기시켜 줍니다. 사용자의 질문에 어떤 계정이나 파일이 관련되어 있는지 안정적으로 식별하지 못하는 에이전트는 수정을 시도하기도 전에 장부 탐색 단계에서 실패할 것입니다.

다음 읽을거리

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — 직접적인 후속 연구로, 에이전트-컴퓨터 인터페이스를 재설계하여 성능을 1.96%에서 12.47%로 끌어올렸습니다. 파일 탐색 및 코드 검색을 위한 설계 원칙은 Beancount 에이전트 도구 구축에 직접 적용 가능합니다.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — 에이전트의 복잡성을 걷어내고 복잡한 구조 없는 단순한 위치 찾기 + 복구 파이프라인도 경쟁력이 있음을 보여줍니다. 인터페이스 중심 접근 방식에 대한 유용한 대조점입니다.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — 계층형 메모리 관리를 통해 긴 컨텍스트 문제를 정면으로 다룹니다. 수년간의 Beancount 장부를 추론해야 하는 에이전트와 직접적인 관련이 있습니다.