연구 결과, 실제 테스트에서 AI 코드의 성능이 과대평가된 것으로 드러났다
METR 연구소의 연구에 따르면, AI 프로그래밍 능력을 평가하는 데 널리 사용되는 ‘SWE-bench Verified’ 벤치마크가 실제 소프트웨어 개발 환경에서 AI 에이전트의 성능을 상당히 과대평가할 가능성이 있는 것으로 나타났다. 이 연구는 벤치마크에서 ‘합격’ 판정을 받은 AI 생성 코드 솔루션 중 약 절반이 실제 프로젝트 유지보수 담당자에 의한 코드 검토 과정에서 거부될 가능성이 높다는 사실을 밝혀냈으며, 이는 자동화된 평가 결과와 실제 코드 품질 사이에 상당한 격차가 존재함을 보여준다.
SWE-bench Verified는 오랫동안 AI 지원 소프트웨어 공학을 평가하는 핵심 표준으로 여겨져 왔으며, 모델이 오픈소스 프로젝트에서 실제 프로그래밍 과제를 해결할 수 있는지 테스트하고, 코드 변경 사항이 프로젝트의 자동화 테스트 스위트를 통과하는지 검증해 왔다. Anthropic과 OpenAI를 비롯한 여러 AI 기업들은 모델의 발전을 입증하기 위해 이 벤치마크의 결과를 자주 인용한다.

이번 연구에서 METR 팀은 오픈소스 프로젝트인 scikit-learn, Sphinx, pytest를 관리하는 숙련된 개발자 4명을 모집하여 AI가 생성한 코드 296개를 수동으로 검토하게 했습니다. 이 코드 샘플들은 Claude 3.5 Sonnet, Claude 3.7 Sonnet, Claude 4 Opus, Claude 4.5 Sonnet, GPT-5 등 5가지 서로 다른 모델에 의해 생성되었습니다. 결과에 따르면, 유지보수 담당자들의 실제 승인률은 SWE-bench의 자동 평가 점수보다 평균 약 24%포인트 낮았으며, 이는 통계적으로 유의미한 차이였습니다.
또한 이 연구는 거부된 AI 코드가 주로 스타일상의 문제가 아니라 보다 중대한 엔지니어링 결함 때문이라는 점을 확인했습니다. 유지보수 담당자들은 문제를 세 가지 주요 유형으로 분류했습니다: 프로젝트 사양을 충족하지 못하는 코드 품질, 기존 코드 구조의 파괴, 그리고 근본적인 기능적 오류입니다. 상당수의 사례는 자동화된 테스트를 통과했음에도 불구하고 코드가 의도된 문제를 올바르게 해결하지 못한 기능적 오류와 관련이 있었습니다.
모델 비교와 관련하여, 연구 결과 Claude 3.5 Sonnet에서 Claude 3.7 Sonnet으로 업그레이드했을 때 벤치마크 통과율은 크게 향상되었으나, 유지보수 담당자가 지적한 기능적 오류의 수도 증가한 것으로 나타났다. Claude 3.7 Sonnet에서 Claude 4 Opus로 전환할 때는 코드 품질 문제가 더 많이 발생했으나, Claude 4.5 Sonnet에서는 코드 품질이 개선된 것으로 나타났습니다. 반면, 이번 수동 평가에서 GPT-5는 전반적으로 Anthropic 모델 시리즈보다 현저히 낮은 성능을 보였습니다.

연구팀은 또한 "작업 완료 시간"에 대한 추정 분석을 수행했다. SWE-bench 자동 평가 결과에 따르면, Claude 4.5 Sonnet이 50%의 성공률로 작업을 완료하는 데는 약 50분의 인간 노동력이 소요될 것으로 나타났다. 그러나 유지보수 담당자들의 점수를 기준으로 할 때, 추정 시간은 약 8분으로 줄어들어 벤치마크가 능력을 최대 7배까지 과대평가했을 가능성을 시사한다.
하지만 연구진은 이번 연구가 AI 프로그래밍 에이전트의 능력에 근본적인 한계가 있음을 시사하는 것은 아니라고 강조했다. 프롬프트 전략을 개선하거나, 더 많은 인간 피드백을 반영하거나, 반복적인 수정 과정을 거친다면 자동 평가와 수동 검토 간의 격차는 줄어들 수 있다. 또한 실험 환경은 실제 개발 과정과 차이가 있다. 예를 들어, AI 에이전트는 단 한 번의 제출 기회만 주어진 반면, 인간 개발자는 일반적으로 피드백을 바탕으로 코드를 반복적으로 수정할 수 있다.
요약하자면, 이 연구는 AI 프로그래밍 에이전트의 실용적 유용성을 평가할 때 벤치마크 점수에만 의존하는 것은 체계적인 편향을 초래할 수 있다고 결론지었다. AI 코딩 모델이 급속히 진화함에 따라, 실제 개발 환경을 더 잘 반영하는 평가 시스템을 개발하는 것이 AI 소프트웨어 공학 분야의 중요한 연구 방향으로 부상했다.
관련 기사
리눅스 재단에 6대 기술 거대기업이 1250만 달러를 지원해 AI 취약성 소음 문제 해결에 나서다
AI 자동화 도구가 생성한 저품질 보안 보고서의 홍수를 처리하기 위해, 앤트로픽(Anthropic), 아마존(AWS), 깃허브(GitHub), 구글(Google), 마이크로소프트(Microsoft), 오픈AI(OpenAI) 등 6대 주요 기술 기업은 리눅스 재단(Linux Foundation) 이니셔티브에 총 1,250만 달러의 자금을 공동으로 기부했습니다. 이 투자는 오픈 소스 소프트웨어(FOSS) 유지 관리자가 수동 선별의 부담에서 벗어나
[[IMG_BASE64_PLACEHOLDER]] 머스크, 오픈AI를 자녀들에게 넘길 가능성 고려… 알트만 증언
오늘 아침, 오픈에이아이(OpenAI)의 샘 알트만(Sam Altman) 최고경영자(CEO)는 회사의 기업 구조에 이의를 제기한 전 공동 창업자 일론 머스크(Elon Musk)의 소송에 대응하기 위해 증언대에 섰습니다.머스크가 비영리 자선단체를 사적 이익을 추구하는 자회사로 전환하여 AI 기반 제품을 마케팅한 다른 창업자들이 “자선단체를 훔쳤다”고 주장한 것과 관련해 질문을 받자, 알트만은 뚜렷한 망설임으로 응답했습니다.“그런 프레임으로 받
관련 특별 주제 추천
의견 (2)
0/500
Interesting findings! I've always suspected those benchmarks were too good to be true. Real-world coding is messy, and it's no surprise that AI agents struggle with edge cases. 😅
Interessant, aber irgendwie auch nicht überraschend. Benchmarks sind oft zu optimistisch, weil sie in einer kontrollierten Umgebung laufen. In der echten Welt mit Legacy-Code, unklaren Anforderungen und Teamarbeit sieht es dann anders aus. 🤔 Vielleicht sollten wir weniger auf die Marketing-Hypes hören und mehr auf praktische Tests setzen. Wer hat schon Erfahrung mit AI-Coding-Tools im Alltag gemacht?
METR 연구소의 연구에 따르면, AI 프로그래밍 능력을 평가하는 데 널리 사용되는 ‘SWE-bench Verified’ 벤치마크가 실제 소프트웨어 개발 환경에서 AI 에이전트의 성능을 상당히 과대평가할 가능성이 있는 것으로 나타났다. 이 연구는 벤치마크에서 ‘합격’ 판정을 받은 AI 생성 코드 솔루션 중 약 절반이 실제 프로젝트 유지보수 담당자에 의한 코드 검토 과정에서 거부될 가능성이 높다는 사실을 밝혀냈으며, 이는 자동화된 평가 결과와 실제 코드 품질 사이에 상당한 격차가 존재함을 보여준다.
SWE-bench Verified는 오랫동안 AI 지원 소프트웨어 공학을 평가하는 핵심 표준으로 여겨져 왔으며, 모델이 오픈소스 프로젝트에서 실제 프로그래밍 과제를 해결할 수 있는지 테스트하고, 코드 변경 사항이 프로젝트의 자동화 테스트 스위트를 통과하는지 검증해 왔다. Anthropic과 OpenAI를 비롯한 여러 AI 기업들은 모델의 발전을 입증하기 위해 이 벤치마크의 결과를 자주 인용한다.

이번 연구에서 METR 팀은 오픈소스 프로젝트인 scikit-learn, Sphinx, pytest를 관리하는 숙련된 개발자 4명을 모집하여 AI가 생성한 코드 296개를 수동으로 검토하게 했습니다. 이 코드 샘플들은 Claude 3.5 Sonnet, Claude 3.7 Sonnet, Claude 4 Opus, Claude 4.5 Sonnet, GPT-5 등 5가지 서로 다른 모델에 의해 생성되었습니다. 결과에 따르면, 유지보수 담당자들의 실제 승인률은 SWE-bench의 자동 평가 점수보다 평균 약 24%포인트 낮았으며, 이는 통계적으로 유의미한 차이였습니다.
또한 이 연구는 거부된 AI 코드가 주로 스타일상의 문제가 아니라 보다 중대한 엔지니어링 결함 때문이라는 점을 확인했습니다. 유지보수 담당자들은 문제를 세 가지 주요 유형으로 분류했습니다: 프로젝트 사양을 충족하지 못하는 코드 품질, 기존 코드 구조의 파괴, 그리고 근본적인 기능적 오류입니다. 상당수의 사례는 자동화된 테스트를 통과했음에도 불구하고 코드가 의도된 문제를 올바르게 해결하지 못한 기능적 오류와 관련이 있었습니다.
모델 비교와 관련하여, 연구 결과 Claude 3.5 Sonnet에서 Claude 3.7 Sonnet으로 업그레이드했을 때 벤치마크 통과율은 크게 향상되었으나, 유지보수 담당자가 지적한 기능적 오류의 수도 증가한 것으로 나타났다. Claude 3.7 Sonnet에서 Claude 4 Opus로 전환할 때는 코드 품질 문제가 더 많이 발생했으나, Claude 4.5 Sonnet에서는 코드 품질이 개선된 것으로 나타났습니다. 반면, 이번 수동 평가에서 GPT-5는 전반적으로 Anthropic 모델 시리즈보다 현저히 낮은 성능을 보였습니다.

연구팀은 또한 "작업 완료 시간"에 대한 추정 분석을 수행했다. SWE-bench 자동 평가 결과에 따르면, Claude 4.5 Sonnet이 50%의 성공률로 작업을 완료하는 데는 약 50분의 인간 노동력이 소요될 것으로 나타났다. 그러나 유지보수 담당자들의 점수를 기준으로 할 때, 추정 시간은 약 8분으로 줄어들어 벤치마크가 능력을 최대 7배까지 과대평가했을 가능성을 시사한다.
하지만 연구진은 이번 연구가 AI 프로그래밍 에이전트의 능력에 근본적인 한계가 있음을 시사하는 것은 아니라고 강조했다. 프롬프트 전략을 개선하거나, 더 많은 인간 피드백을 반영하거나, 반복적인 수정 과정을 거친다면 자동 평가와 수동 검토 간의 격차는 줄어들 수 있다. 또한 실험 환경은 실제 개발 과정과 차이가 있다. 예를 들어, AI 에이전트는 단 한 번의 제출 기회만 주어진 반면, 인간 개발자는 일반적으로 피드백을 바탕으로 코드를 반복적으로 수정할 수 있다.
요약하자면, 이 연구는 AI 프로그래밍 에이전트의 실용적 유용성을 평가할 때 벤치마크 점수에만 의존하는 것은 체계적인 편향을 초래할 수 있다고 결론지었다. AI 코딩 모델이 급속히 진화함에 따라, 실제 개발 환경을 더 잘 반영하는 평가 시스템을 개발하는 것이 AI 소프트웨어 공학 분야의 중요한 연구 방향으로 부상했다.
리눅스 재단에 6대 기술 거대기업이 1250만 달러를 지원해 AI 취약성 소음 문제 해결에 나서다
AI 자동화 도구가 생성한 저품질 보안 보고서의 홍수를 처리하기 위해, 앤트로픽(Anthropic), 아마존(AWS), 깃허브(GitHub), 구글(Google), 마이크로소프트(Microsoft), 오픈AI(OpenAI) 등 6대 주요 기술 기업은 리눅스 재단(Linux Foundation) 이니셔티브에 총 1,250만 달러의 자금을 공동으로 기부했습니다. 이 투자는 오픈 소스 소프트웨어(FOSS) 유지 관리자가 수동 선별의 부담에서 벗어나
[[IMG_BASE64_PLACEHOLDER]] 머스크, 오픈AI를 자녀들에게 넘길 가능성 고려… 알트만 증언
오늘 아침, 오픈에이아이(OpenAI)의 샘 알트만(Sam Altman) 최고경영자(CEO)는 회사의 기업 구조에 이의를 제기한 전 공동 창업자 일론 머스크(Elon Musk)의 소송에 대응하기 위해 증언대에 섰습니다.머스크가 비영리 자선단체를 사적 이익을 추구하는 자회사로 전환하여 AI 기반 제품을 마케팅한 다른 창업자들이 “자선단체를 훔쳤다”고 주장한 것과 관련해 질문을 받자, 알트만은 뚜렷한 망설임으로 응답했습니다.“그런 프레임으로 받
Interesting findings! I've always suspected those benchmarks were too good to be true. Real-world coding is messy, and it's no surprise that AI agents struggle with edge cases. 😅
Interessant, aber irgendwie auch nicht überraschend. Benchmarks sind oft zu optimistisch, weil sie in einer kontrollierten Umgebung laufen. In der echten Welt mit Legacy-Code, unklaren Anforderungen und Teamarbeit sieht es dann anders aus. 🤔 Vielleicht sollten wir weniger auf die Marketing-Hypes hören und mehr auf praktische Tests setzen. Wer hat schon Erfahrung mit AI-Coding-Tools im Alltag gemacht?





집







