SWE-bench (benchmark) (KO)

From Systems analysis Wiki
Jump to navigation Jump to search

SWE-bench — 대규모 benchmark (테스트 과제 모음)로, 대형 언어 모델(LLM)의 자동화된 소프트웨어 개발 및 디버깅 능력을 평가하기 위해 설계되었습니다[1]. 프린스턴 대학교 및 여러 기관의 연구자 그룹이 개발하였으며, ICLR 2024 학술대회에서 발표되었습니다[2]. SWE-bench는 실제 개발 현장의 과제를 활용한다는 점에서 기존의 코드 benchmark와 차별화됩니다. 테스트 세트는 GitHub의 12개 인기 오픈소스 Python 저장소에서 수집된 종료된 이슈(issues)와 해당 수정 사항(pull request)을 기반으로 한 2,294개의 과제로 구성되어 있습니다[1][3]. 각 과제에는 문제(issue) 설명이 포함되어 있으며, 모델이 해당 프로젝트의 소스 코드에 접근할 수 있습니다. 모델의 목표는 지정된 문제를 수정하는 최소한의 코드 변경(패치)을 생성하는 것입니다[1][3].

평가 방법론 및 특성

SWE-bench는 실제 소프트웨어 개발 프로세스를 모사합니다. 각 과제에서 모델에게는 원래의 GitHub 이슈 텍스트(문제 설명)와 수정 전 버전의 저장소 코드 스냅샷이 제공됩니다[4]. 모델(또는 모델 기반 에이전트)은 소스 코드를 분석하고, 오류 또는 요구되는 변경의 성격을 파악한 후, 관련 코드 파일에 수정을 가하여 문제를 해결해야 합니다[4][5]. 솔루션 검증은 자동화되어 있습니다. 각 과제에는 해당 문제를 종료한 pull request의 실제 단위 테스트가 연결되어 있습니다. 이 테스트에는 "실패-통과" 테스트(fail-to-pass: 원본 코드에서는 통과하지 못하지만 올바른 수정 적용 후 통과해야 하는 테스트)와 회귀 테스트(pass-to-pass: 처음부터 통과하며 변경 후에도 계속 통과해야 하는 테스트)가 모두 포함됩니다[3]. 모델이 제안한 패치를 코드에 적용한 후 해당 테스트가 실행됩니다. 모든 fail-to-pass 테스트가 통과되고 pass-to-pass 테스트가 손상되지 않은 경우 해당 과제는 올바르게 해결된 것으로 간주됩니다[3]. 이러한 평가 방식은 모델이 구문적으로 올바른 코드를 생성하는 능력뿐만 아니라, 기존 기능을 손상시키지 않으면서 실제로 주어진 과제를 해결할 수 있는 능력을 검증합니다. 또한 모델은 광범위한 컨텍스트(전체 코드 저장소)를 다루고, 컴포넌트 간의 관계를 이해하며, 여러 파일에 걸친 변경을 동시에 조율해야 합니다[1]. 이는 설명을 바탕으로 함수를 작성하는 일반적인 과제보다 훨씬 더 복잡합니다.

SWE-bench 평가에는 단순한 LLM이 아닌, 모델을 보조 도구(예: 파일 탐색, 코드 실행, 디버거 사용 등)로 감싼 에이전트 시스템이 주로 참여합니다[4][6]. 이러한 시스템은 실제 개발 주기를 모방합니다. 즉, 모델은 파일을 순차적으로 검토하고, 테스트나 스크립트를 실행하며, 성공적인 결과에 도달할 때까지 솔루션을 단계적으로 개선할 수 있습니다[4]. 주목할 만한 점은 SWE-bench 과제 해결 효율이 이 "스캐폴딩"(에이전트 인프라)의 품질에 크게 의존한다는 것입니다. 동일한 기본 모델이라도 저장소 및 도구와의 상호작용 방식에 따라 다른 결과를 보일 수 있습니다[4][7]. 따라서 SWE-bench는 모델과 그 과제 해결 전략의 통합적 역량을 측정하는 지표로서, 자율 AI 개발자의 실제 작업 조건에 가까운 평가를 제공합니다[4][7].

과제 세트 변형

SWE-bench 저자들과 커뮤니티는 이후 다양한 평가 목적을 위한 여러 파생 세트를 선보였습니다:

  • SWE-bench Lite — 모델 테스트의 복잡성과 계산 비용을 줄이기 위해 선별된 약 300개의 과제를 포함하는 경량화된 benchmark 버전입니다[8]. 이 하위 세트는 모델의 빠른 실험을 위해 만들어졌으며, 가장 시간 소모가 큰 검증 과정을 제외하면서도 주요 문제의 대표성을 유지합니다[7]. 본질적으로 Lite는 더 단순하고 짧은 버그 수정 과제들을 포함하며, 가장 어려운 사례들이 제외되어 있어 Lite에서의 모델 성능은 일반적으로 전체 세트보다 높습니다[7].
  • SWE-bench Verified — 2024년 8월 OpenAI와 공동으로 발표된, 수작업 검토를 통해 필터링된 하위 세트입니다[7]. 연구자들은 93명의 전문 개발자를 참여시켜 원본 benchmark의 각 과제를 분석하고, 원본 문제 설명이 너무 모호하거나 테스트에서 요구하는 동작이 과제 조건에서 명확하게 도출되지 않는 사례들을 제거하였습니다[7]. 또한 환경 문제나 잘못된 테스트로 인해 실질적으로 해결이 불가능한 과제들도 제거되었습니다[7]. 그 결과 해결 가능하고 올바르게 구성된 500개의 과제로 이루어진 세트가 형성되었습니다[7]. SWE-bench Verified는 테스트 자체의 부적절함이나 과제 설정으로 인해 올바른 솔루션조차 거부되는 사례를 제거함으로써 보다 신뢰할 수 있는 모델 역량 평가를 제공하고자 합니다[7]. 이 세트는 모델 비교의 주요 기준으로서 기존 SWE-bench 테스트 샘플(전체 및 Lite)을 대체하였습니다[7]. 아울러 Verified와 함께 과제 난이도 평가 결과(예: 사람이 15분 이내에 해결 가능한 "쉬운" 과제와 1시간 이상이 필요한 "어려운" 과제 구분)가 공개되었으며[7], 더 안정적이고 재현 가능한 테스트 실행을 위한 Docker 기반의 새로운 도구 프레임워크도 출시되었습니다[7].
  • SWE-bench Multimodal — 2025년 1월에 발표된 benchmark의 확장판으로, 문제 설명에 텍스트뿐만 아니라 시각적 요소(예: 인터페이스 이미지, 오류 스크린샷 등)가 포함된 과제들을 담고 있습니다[8]. 이 세트(517개의 과제[8])는 모델과 에이전트가 프로그래밍 과제를 해결할 때 시각적 정보를 이해하고 활용하는 능력을 평가합니다. 멀티모달 세트에서의 평가는 유사한 방식으로 이루어지지만, 모델에게 멀티모달 기능(예: 이미지 내 텍스트 인식)이 요구됩니다. SWE-bench Multimodal의 테스트 부분은 알려진 정답에 솔루션을 맞추는 것을 방지하기 위해 비공개(숨김)로 유지됩니다. 개발자들은 원격 리더보드에 솔루션을 제출하여 이 과제들에서 자신의 모델을 평가받을 수 있습니다[2].

이러한 주요 변형 외에도 SWE-bench를 중심으로 도구 생태계가 형성되었습니다. SWE-agent는 benchmark 과제에서 최첨단 결과를 보여주는 오픈소스 에이전트-솔버이며[2], SWE-smith는 자체 개발자 모델을 훈련하기 위한 프레임워크이고, SWE-REX는 저장소에서 고급 정보 추출 및 처리를 위한 도구입니다. 이러한 프로젝트들은 결과 재현을 간소화하고 자율 프로그래밍 시스템 분야의 연구를 발전시키는 것을 목표로 합니다.

모델 결과 및 발전

SWE-bench가 처음 등장했을 때, 당시 최신 LLM과 숙련된 프로그래머의 능력 사이의 상당한 격차가 드러났습니다. 저자들에 따르면 2023년 초 가장 강력한 모델들조차 과제의 몇 퍼센트만 해결할 수 있었습니다. 예를 들어 Anthropic의 Claude 2 모델은 전체 세트의 2% 미만을 성공적으로 해결하였습니다[1]. benchmark 저자들이 훈련시킨 전문 모델(LLaMA 기반으로 SWE-Llama라 명명)과 GPT-4 같은 독점 모델들은 주로 가장 단순한 버그만 해결할 수 있었습니다[1]. 이러한 낮은 초기 지표들은 SWE-bench의 난이도를 부각시켰고 새로운 접근법 개발의 동력이 되었습니다.

2024년 한 해 동안 더욱 발전된 모델과 에이전트 체계가 등장하면서 결과가 크게 향상되었습니다. 프린스턴 대학교의 연구자들은 GPT-4와 코드 검색, 계획 수립 및 기타 도구를 결합한 SWE-agent 시스템을 발표하였습니다. 이 시스템은 전체 세트에서 약 12.5%의 과제를 해결하여 학술 모델의 새로운 기준을 세웠습니다[5]. 2024년 중반까지 SWE-bench 공식 리더보드에서 최고 솔루션(독점 포함)은 전체 benchmark에서 약 20%의 성공률을 달성하였고, 경량화된 Lite 세트에서는 43%까지 도달하였습니다[7]. 이러한 성장은 모델 개선(예: GPT-4, Claude 2 및 3의 등장)과 특히 "스캐폴딩" 발전 덕분입니다. 스캐폴딩이란 모델이 과제를 단계별로 효과적으로 분해하고, 문서를 읽고, 디버깅 세션을 실행하는 등의 작업을 가능하게 하는 외부 전략입니다[7].

2024년 말 Verified 세트(잘못된 과제를 정리한 것)가 도입된 후 측정 성능이 더욱 향상되었습니다. GPT-4(GPT-4o 변형)는 기존 세트에서의 약 16%에 비해 Verified에서 즉시 약 33%의 성공률을 보였습니다[7]. 최고의 오픈소스 에이전트 프레임워크(예: Agentless)는 Verified에서 결과를 약 16%에서 32%로 두 배 향상시켰습니다[7]. 이는 원본 benchmark가 해결 불가능한 사례들로 인해 성능을 다소 과소평가하고 있었다는 추측을 확인시켜 주었습니다[7]. 동시에 Lite 대비 Verified에서의 결과 개선이 그리 극적이지 않다는 점도 주목할 만합니다(최고 모델들은 이미 Lite에서 약 43%에 도달했습니다). 이는 논리적으로 일관됩니다. Lite는 처음부터 더 쉬운 예제들을 선별하였고, Verified는 해결 불가능한 것들을 제거하되 어려운 과제는 그대로 남겼기 때문입니다[7]. 중요한 점은 Verified로의 전환에 따른 성능 향상이 가장 어려운 과제들만 제거된 덕분이 아니라 모든 난이도 범주에 걸쳐 일어났다는 것입니다. 즉, 필터링을 통해 상대적으로 쉬운 과제들 중에도 숨겨진 해결 불가능한 사례들이 제거되었음을 의미합니다[7].

2025년 초 기준으로 선두 AI 시스템들은 검증된 과제 세트에서 인간에 가까운 성능을 보이고 있지만, 100%의 상한선은 아직 요원합니다. 2025년 1월 Anthropic은 자사의 새로운 Claude 3.5 Sonnet 모델이 개선된 에이전트와 결합하여 SWE-bench Verified 과제의 49%를 해결하였다고 발표하며 일시적으로 1위를 차지했습니다[4]. 대형 기술 기업들과 독립 팀들도 이 benchmark에서 비공식 경쟁에 활발히 참여하고 있습니다. 예를 들어, CodeStory 팀은 여러 변형을 시도하는 다중 모델 접근법("Midwit Agent")을 개발하여 Verified에서 기록적인 62.2%의 과제를 해결하는 성과를 거두었습니다(2025년 초 기준)[5][9]. 이를 위해 추론 단계의 계산 자원(소위 inference time scaling)을 대폭 확대하여 다수의 솔루션 시도를 실행하고 최선의 결과를 선택해야 했음이 언급되었습니다[5]. 한편, OpenAI 자료에서는 충분한 컴퓨팅 확장 시 실험적인 GPT-03 시스템이 Verified에서 70% 임계값을 넘었다고 언급되었습니다(비공식 데이터)[5]. 그러나 이 결과에 대한 독립적인 검증은 없으며, 이렇게 높은 수치는 달성된 기준이라기보다 미래 연구를 위한 이정표로 남아 있습니다.

Microsoft Research(2025)의 연구에 따르면, 최신 모델들도 디버깅 도구를 갖추었을 때 SWE-bench Lite의 버그 수정 성공률 50% 기준을 여전히 넘지 못하고 있습니다[6]. 이 테스트에서 최고 성능을 보인 것은 Claude 3.7 Sonnet으로 약 48.4%의 과제를 해결하였으며, GPT-4(OpenAI o1) 기반 시스템은 약 30%, 경량 모델인 o3-mini는 22%에 그쳤습니다[6]. 이러한 결과는 빠른 발전에도 불구하고 현재의 AI가 여전히 숙련된 프로그래머에 미치지 못한다는 것을 강조합니다. 코드를 이해하는 인간에게는 이러한 과제를 해결하는 것이 어렵지 않지만, 모델은 종종 디버깅 도구를 효과적으로 활용하지 못하거나 다단계 버그 수정 과정을 반영하는 훈련 데이터의 부족으로 어려움을 겪습니다[6].

한계와 전망

SWE-bench는 지능형 코드 에이전트 평가를 위한 표준화된 플랫폼이 되었지만, 연구를 통해 여러 한계점도 드러났습니다. 주요 문제는 테스트 불완전성입니다. 각 과제에 대한 검증 테스트 세트는 특정 pull request에서 가져오며, 일반적으로 버그 수정 시 변경된 단위 테스트만 포함됩니다[3]. 저장강(Zhejiang) 대학교 및 슈투트가르트 대학교 연구자 그룹(Wang et al. 2025)의 분석에 따르면, 프로젝트의 나머지 테스트를 무시하면 일부 솔루션의 부정확성이 감추어질 수 있습니다[3]. 저장소의 전체 테스트 세트로 솔루션을 재검증한 결과, SWE-bench에서 성공으로 표시된 패치의 평균 7.8%가 실제로는 프로젝트의 다른 테스트를 통과하지 못하는 것으로 나타났습니다[3]. 이는 "과제 해결" 지표를 약 4-6 퍼센트 포인트 과대평가하게 만듭니다[3]. 더 미묘한 경우는 생성된 패치가 모든 기존 테스트를 통과하지만 개발자의 솔루션과 동등하지 않으며 프로그램의 동작을 예상과 다르게 변경하는 경우입니다. 추가 테스트 케이스 생성(PatchDiff 방법론)을 통해 연구자들은 AI가 제안한 수정 사항의 거의 30%가 참조 패치와 다르게 동작하며, 약 11%는 기존 테스트로는 감지되지 않지만 명백히 잘못된 것으로 파악되었습니다[3]. 따라서 제한된 테스트 세트의 통과에만 의존할 경우 모델의 실제 능력이 과대평가될 수 있습니다. SWE-bench의 제작자들은 이 취약점을 인정하며, benchmark는 시간이 지남에 따라 발전해야 한다고 강조합니다. 즉, 테스트 커버리지가 개선되고, 원치 않는 부작용이 없는지에 대한 검사가 추가되며, 과제 유형의 범위가 확장되어야 합니다[7]. 이러한 평가 도구의 발전은 점점 더 자율적이고 강력한 AI 개발자의 등장에 대비하는 중요한 부분이며, SWE-bench의 경험은 benchmark 품질에 신중한 주의를 기울일 필요성을 보여줍니다[7].

SWE-bench는 단지 정적인 과제 집합에 불과하여 프로그래밍의 모든 측면을 포괄하지는 않지만, 코드 모델의 비교 분석을 위한 사실상의 표준이 되었습니다[3]. 새로운 방법과 알고리즘을 보여주기 위한 학술 논문에서 활용되고 있으며, 프로그래밍 자동화를 목표로 하는 시스템의 잠재력을 평가하기 위한 산업 연구 그룹에서도 사용됩니다[3]. 2023-2025년 SWE-bench에서의 지속적인 결과 향상은 실질적인 개발 과제 해결에서 LLM 역량의 급격한 개선을 명확히 보여줍니다. 동시에 난이도의 척도 역할도 합니다. 해결된 과제의 50-60%에 근접하더라도 모델들은 특히 제한된 정보 조건과 요구사항에 대한 세밀한 이해가 필요한 경우 인간을 완전히 대체하기에는 여전히 부족합니다[4][7]. 그럼에도 불구하고 발전은 계속되고 있습니다. SWE-bench와 같은 이니셔티브 덕분에 커뮤니티는 자신들의 목표와 한계를 명확히 인식하며, 인간 전문가 수준으로 자율적으로 프로그램 코드를 이해하고 수정할 수 있는 완전한 AI 개발자를 만들기 위한 여정을 계속하고 있습니다[4][7].

참조 링크

  • GitHub의 SWE-bench
  • SWE-bench 공식 리더보드

문헌

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

각주

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [1]
  2. ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [2]
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [3]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [4]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [5]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [6]
  7. ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [7]
  8. ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [8]
  9. ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [9]
Retrieved from "https://systems-analysis.info/int/index.php?title=SWE-bench_(benchmark)_(KO)&oldid=6528"