💻 computer science

Beyond Final Code: A Process-Oriented Error Analysis of Software Development Agents in Real-World GitHub Scenarios

이 논문은 SWE-Bench 벤치마크의 500 개 GitHub 이슈를 해결하는 8 개 최상위 에이전트의 실행 로그를 분석하여 최종 코드 생성뿐만 아니라 실행 중 발생하는 오류와 디버깅 과정이 해결률에 미치는 영향을 규명하고, 벤치마크 플랫폼의 3 가지 결함을 발견하여 공정성과 정확성 문제를 제기했습니다.

원저자: Zhi Chen, Wei Ma, Lingxiao Jiang

게시일 2026-04-10

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Zhi Chen, Wei Ma, Lingxiao Jiang

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

이 논문은 **"AI 프로그래머가 실제로 코드를 작성할 때, 최종 결과물만 보는 게 아니라 '과정'에서 어떤 실수를 반복하는지"**를 파헤친 연구입니다.

마치 유명 요리사 (AI 에이전트) 가 요리를 완성한 접시만 평가하는 것이 아니라, 주방에서 재료를 다듬고, 냄비를 태우며, 맛을 보고 고치는 전 과정을 녹화해서 분석한 것과 같습니다.

이 논문의 핵심 내용을 쉽게 풀어서 설명해 드릴게요.

🍳 1. 연구의 배경: "완성된 요리는 맛있지만, 주방은 혼란스러웠다"

지금까지 AI 프로그래머 (소프트웨어 개발 에이전트) 를 평가할 때는 **"최종 코드가 잘 작동하느냐?"**만 확인했습니다. 마치 요리를 다 해낸 뒤 "맛있네?"라고 묻는 것과 비슷하죠.

하지만 연구진은 의문을 가졌습니다.

"AI 가 왜 실패했는지, 중간에 어떤 실수를 하고 얼마나 헤맸는지 모르면, 어떻게 더 똑똑하게 만들 수 있겠지?"

그래서 AI 가 500 개의 실제 GitHub(소프트웨어 개발 사이트) 이슈를 해결하는 **3,977 개의 작업 과정 (트레이젝토리)**과 3,931 개의 테스트 로그를 모두 분석했습니다.

🔍 2. 주요 발견 4 가지 (AI 의 주방 실수 분석)

① 실수가 많을수록 요리 실패 확률이 높아진다 (RQ1)

비유: 요리사가 재료를 자르다가 칼을 떨어뜨리고 (실수 1 개), 냄비를 태우고 (실수 2 개), 다시 재료를 사러 나가는 식으로 실수가 쌓이면, 결국 요리를 제대로 완성할 확률은 급격히 떨어집니다.
결과: AI 가 중간에 오류를 겪지 않고 바로 해결하면 성공률이 비슷했지만, 오류가 10 개 이상 쌓이면 성공 확률이 20% 대로 뚝 떨어졌습니다. 오류를 고치려고 노력할수록 오히려 더 복잡해지고 지쳐서 실패하는 것입니다.

② 가장 많이 하는 실수: "재료가 없어서"와 "문법 틀림" (RQ2)

비유: 요리사가 레시피를 보는데 "소금"이 없다는 말을 하거나, "소금"을 넣으라고 했는데 "설탕"을 넣는 실수를 반복합니다.
결과: AI 가 가장 자주 겪는 실수는 **ModuleNotFoundError (필요한 라이브러리/재료를 찾지 못함)**와 **TypeError (데이터 타입을 잘못 이해함)**였습니다. 즉, 환경 설정이나 기본적인 문법에서 자주 막히는 것입니다.

③ 가장 고치기 힘든 실수: "시스템 오류"와 "데이터베이스" (RQ3)

비유: 요리사가 "불이 꺼졌다 (시스템 오류)"거나 "냉장고 문이 잠겼다 (데이터베이스 오류)"는 상황에서, 아무리 시도해도 다시는 열리지 않아서 좌절하는 상황입니다.
결과: **OSError (파일/시스템 관련 오류)**와 **IntegrityError (데이터베이스 무결성 오류)**는 AI 가 한 번 겪으면 여러 번 반복해서 실패하는 '악성 실수'였습니다. AI 는 이런 복잡한 시스템 문제를 스스로 고치는 데 매우 서툴렀습니다.

④ AI 가 놓친 치명적인 실수와 플랫폼의 버그 (RQ4)

비유: 요리사가 "완성했다!"고 외치며 접시를 내놨는데, 실제로는 소금기 없이 나왔거나, 심지어 평가하는 요리사 (SWE-Bench 플랫폼) 가 실수로 점수를 잘못 매긴 경우도 있었습니다.
결과:
1. AI 가 중간에 발견한 오류를 고치지 않고 넘어가서, 최종 테스트에서 실패하는 경우가 많았습니다.
2. 놀라운 사실: 연구진이 분석하던 중, 평가 플랫폼 (SWE-Bench) 자체에 버그가 3 개 있다는 것을 발견했습니다. AI 가 다 잘했는데도 "실패"로 판정받거나, 테스트 환경 자체가 깨져있던 것입니다. 연구진은 이 버그를 개발자에게 보고했고, 이미 수정 중이거나 해결되었습니다.

💡 3. 이 연구가 우리에게 주는 교훈

이 논문은 AI 프로그래머에게 다음과 같은 조언을 합니다:

실수를 빨리 감지하라: "칼을 떨어뜨리면 바로 줍고, 재료를 찾지 못하면 미리 확인하라." (실수 예방)
복잡한 시스템은 전문가의 도움을 받아라: "냉장고 고치는 건 AI 가 아니라 인간이 하거나, 더 강력한 도구를 써라." (데이터베이스/시스템 오류 대응)
기록을 표준화하라: "모든 요리사가 사용하는 주방 기록장 (로그) 을 통일해야 서로의 실수를 비교하고 배울 수 있다." (데이터 포맷 통일 필요)

🎯 결론

이 연구는 **"AI 가 코드를 짜는 과정에서의 실수 패턴을 분석해야만, 진짜 똑똑한 AI 를 만들 수 있다"**는 것을 증명했습니다. 단순히 "코드가 작동하나요?"라고 묻는 것을 넘어, **"어디서 왜 막혔나요?"**를 물어봄으로써 AI 의 능력을 한 단계 더 끌어올릴 수 있는 길을 제시했습니다.

1. 연구 배경 및 문제 제기 (Problem)

배경: 대규모 언어 모델 (LLM) 을 기반으로 한 소프트웨어 개발 에이전트 (Software Development Agents) 가 등장하여 복잡한 리포지토리 수준의 작업을 수행하고 있습니다.
현재의 한계: 기존 평가들은 주로 에이전트가 생성한 최종 코드 (Final Code) 의 정적 분석 (버그 수, 취약점 등) 에 집중하고 있습니다.
문제점: 실제 소프트웨어 개발은 최종 결과물뿐만 아니라, 문제 해결을 위한 반복적인 추론, 도구 사용, 디버깅, 환경 상호작용 등의 동적 과정을 포함합니다. 그러나 현재까지 에이전트가 문제를 해결하는 과정 (Process) 에서 발생하는 오류에 대한 체계적인 분석은 이루어지지 않았습니다.
연구 목표: 최종 코드뿐만 아니라 에이전트의 해결 단계 (Solving Phase) 와 테스트 단계 (Testing Phase) 에서 발생하는 오류 데이터를 분석하여, 에이전트의 실제 문제 해결 능력과 한계를 파악하는 것입니다.

2. 연구 방법론 (Methodology)

데이터셋: SWE-Bench Verified 벤치마크를 사용했습니다.
- 범위: 12 개의 인기 있는 Python 오픈소스 리포지토리에 있는 500 개의 실제 GitHub 이슈.
- 대상 에이전트: 리더보드 상위 30 개 중 8 개의 에이전트 (W&B Programmer, Blackbox AI, Devlo, CodeAct 등) 를 선정하여 분석했습니다.
- 데이터 수집:
  - 해결 단계 (Solving Phase): 3,977 개의 에이전트 행동 궤적 (Trajectory) 파일 (내부 추론, 도구 실행 로그, 오류 메시지 포함).
  - 테스트 단계 (Testing Phase): 3,931 개의 테스트 실행 로그 (패치 적용 및 테스트 통과/실패 결과).
분석 프레임워크 (4 가지 연구 질문, RQs):
1. RQ1 (탐색적 분석): 해결 단계의 Python 실행 오류가 최종 패치 품질과 추론 단계 수에 미치는 영향.
2. RQ2 (빈도 분석): 에이전트가 가장 빈번하게 마주치는 오류 유형은 무엇인가?
3. RQ3 (어려운 오류 분석): 에이전트가 회복하기 가장 어려운 (반복적으로 발생하는) 오류 유형은 무엇인가?
4. RQ4 (실패 및 교차 단계 분석): 패치 실패의 근본 원인과 해결 단계에서 발견되었으나 해결되지 않고 테스트 단계로 이어진 오류는 무엇인가?

3. 주요 기여 (Key Contributions)

최초의 과정 중심 분석: GitHub 이슈 해결 에이전트의 '해결 단계 궤적'과 '테스트 로그'를 동시에 분석하여, 최종 코드만 보는 기존 연구의 한계를 극복했습니다.
오류 패턴 식별: 에이전트가 직면하는 가장 흔한 오류와 특히 회복하기 어려운 '어려운 오류'를 체계적으로 분류하고 정량화했습니다.
벤치마크 결함 발견: SWE-Bench 플랫폼의 공정성과 정확성을 해치는 3 개의 치명적인 버그를 발견하여 개발자에게 보고하고 확인받았습니다.
오픈 데이터 공유: 투명성과 재현성을 위해 분석에 사용된 데이터셋과 스크립트를 공개했습니다.

4. 주요 연구 결과 (Key Results)

RQ1: 오류 발생과 성능의 상관관계

오류 발생 여부 vs. 빈도: 단순히 오류가 한 번 발생했다고 해서 해결률이 크게 떨어지지는 않지만, 오류의 빈도가 증가할수록 해결률은 급격히 하락합니다 (오류 11~15 개 발생 시 해결률 37.2% → 20 개 이상 시 22.6%).
추론 단계: 오류 횟수와 추론 단계 수는 강한 양의 상관관계 ( $r=0.59$ ) 를 보입니다. 오류가 많을수록 에이전트는 이를 수정하기 위해 더 많은 단계를 수행하게 되며, 이는 계산 비용 증가와 추가 오류 발생의 악순환을 초래합니다.

RQ2: 흔한 오류 유형 (Prevalent Errors)

상위 오류: ModuleNotFoundError (1,053 건), TypeError (992 건), AttributeError (841 건) 가 가장 빈번했습니다.
카테고리:
- 의존성 및 환경: 외부 라이브러리 import 실패 (ModuleNotFoundError, ImportError).
- 파싱 및 타입: 문법 오류 (SyntaxError), 타입 불일치 (TypeError).
- 데이터베이스: django.db.utils.OperationalError, IntegrityError 등 DB 관련 오류가 빈번하게 발생하여 에이전트의 DB 스키마 이해 부족을 시사합니다.

RQ3: 회복하기 어려운 오류 (Challenging Errors)

재발률 (Recurrence Ratio) 기준: 에이전트가 한 번 마주친 후 다시 해결하지 못하고 반복되는 오류를 분석했습니다.
가장 어려운 오류:
1. OSError (재발률 71.43%): 파일 시스템 또는 시스템 호출 관련 오류로, 에이전트가 해결하기 매우 어렵습니다.
2. django.db.utils.IntegrityError (재발률 57.69%) 및 sqlite3.IntegrityError: 데이터 무결성 위반으로, SQL 쿼리나 스키마 제약 조건을 올바르게 처리하지 못해 반복됩니다.
3. IndentationError (재발률 50.00%): 고급 에이전트조차 Python 코드 들여쓰기 오류를 쉽게 해결하지 못합니다.
대조적 발견: ModuleNotFoundError 는 빈번하게 발생하지만 재발률은 낮아 (14.01%), 에이전트가 의존성 문제는 비교적 잘 해결한다는 것을 알 수 있습니다.

RQ4: 패치 실패 원인 및 교차 단계 오류

실패 원인: 대부분의 실패는 테스트 단계에서의 파싱/런타임 오류 때문입니다. 에이전트는 패치가 실행 가능하다고 잘못 판단하고 제출하는 경우가 많습니다.
교차 단계 오류 (Cross-Phase Errors): 해결 단계에서 발견되었으나 수정되지 않고 테스트 단계로 넘어가 패치 실패를 초래한 오류들 (예: TypeError, ModuleNotFoundError 등) 이 확인되었습니다.
SWE-Bench 플랫폼 버그 발견:
- astropy-7606: 모든 테스트를 통과했으나 '해결되지 않음'으로 잘못 표시됨.
- astropy-8707, astropy-8872: 테스트 설정 또는 수집 단계에서 실패하여 패치 평가 자체가 불가능함.
- 이 3 건은 모두 SWE-Bench 유지보수팀에 보고되어 확인되었으며, 1 건은 수정 완료, 2 건은 수정 진행 중입니다.

5. 의의 및 시사점 (Significance)

에이전트 개선 방향 제시: 단순한 코드 생성 능력 향상뿐만 아니라, 오류 감지, 디버깅, 회복 (Recovery) 능력을 강화해야 함을 강조합니다. 특히 DB 무결성, 시스템 오류, 재귀적 오류 처리에 대한 훈련이 필요합니다.
프로액티브 오류 방지: 에이전트 워크플로우 초기에 정적 분석 도구 (MyPy, Pylint 등) 를 도입하여 의존성 및 문법 오류를 사전에 차단하는 전략이 필요합니다.
지속 가능한 개발 (Green AI): 오류 반복으로 인한 불필요한 계산 자원 낭비를 줄이고, 에너지 효율적인 소프트웨어 개발 에이전트 개발의 중요성을 제기합니다.
표준화 필요성: 에이전트 간 비교 분석을 위해 궤적 (Trajectory) 로그의 표준 형식이 필요함을 강조합니다.

이 연구는 AI 기반 소프트웨어 공학의 평가 패러다임을 '최종 결과'에서 '과정 중심의 오류 분석'으로 전환하여, 보다 견고하고 효율적인 개발 에이전트 개발을 위한 중요한 통찰을 제공합니다.