본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 19. 22:20

AI 에이전트, 전문가 수준 과제에서 0% 점수 기록. 과장된 기대는 무시한다.

요약

ALE 벤치마크 결과, 최신 AI 에이전트들이 전문가 수준의 고난도 과제에서 0%의 통과율을 기록하며 기대치에 못 미치는 성능을 보였습니다. 데모 영상의 화려함과 실제 배포 가능성 사이의 간극을 경고하며, 과장된 기대 대신 객관적인 벤치마크를 바탕으로 한 엔지니어링 접근을 권고합니다.

핵심 포인트

  • ALE 벤치마크에서 전문가 수준 과제 통과율 0% 기록
  • 데모 영상과 실제 업무 적용 사이의 큰 간극 존재
  • 에이전트를 완전한 자율 주체가 아닌 보조자로 취급할 것
  • 하이프(Hype)가 아닌 실증적 데이터 기반의 의사결정 필요

ALE 벤치마크에 따르면 최고 AI 에이전트들이 전문가 수준의 전문 업무 과제에서 0%를 달성했습니다. 적은 점수가 아니었고, 좌절감을 줄 정도도 아닙니다. 단 하나도 없었습니다.

당신의 타임라인이 에이전트가 3분기까지 당신의 엔지니어링 팀 전체를 대체할 것이라는 글들로 채워지는 동안, 이 만족스러운 정수(整數)에 주목해 보세요.

ALE이 실제로 보여준 것

ALE은 Agents' Last Exam의 약자로, AI 에이전트가 실제 전문 지식이 필요한 문제들을 테스트하기 위해 고안된 벤치마크입니다. 단순히 '이 PDF 요약하기' 같은 문제가 아닙니다. 현업 전문가들이 수행하는 어렵고 도메인 특화된 작업들입니다.

결과는 암울했습니다. Fable 5와 GPT-5.5를 포함한 여러 모델들이 테스트 대상에 올랐습니다. 가장 어려운 '최종 시험(Last-Exam)' 단계의 전문가 수준 문제에서 이들은 0% 통과율을 기록했습니다 (부분 점수가 0이 아니었음에도 불구하고). 동전 던지기보다도 못했다는 뜻입니다.

많은 사람이 간과할 한 가지 세부 사항이 있습니다. 중급 난이도 과제에서의 성능은 약간 더 높았지만 여전히 그다지 인상적이지 않았으며, 최고의 에이전트들이 달성한 성공률은 15–21%에 불과했습니다. 따라서 완전히 무능력하다고 할 수는 없습니다. 단지 과장된 기대만큼의 수준은 아니라는 것입니다.

데모와 배포 사이의 간극

몇 주마다 AI 에이전트가 항공편을 예약하고, 코드를 작성하며, 심지어 프로젝트를 관리하는 새로운 시연(demonstration)이 등장합니다. 2분짜리 영상만 보면 놀라 보입니다.

하지만 실제로 당신의 업무에서 중요하게 작용하는 무언가를 맡기려고 하면 어떨까요? 모호성, 예외 케이스, 그리고 실제 이해관계가 걸린 작업 말입니다. 결국 압박감 속에서 무너집니다. 🎪

이것이 바로 데모-배포 간극(demo-to-deploy gap)이며, 그 간격은 엄청납니다. 데모는 선별된 것입니다. 벤치마크는 그렇지 않습니다.

개발자들이 관심을 가져야 하는 이유

저는 팀들이 아직 존재하지 않는 능력에 기반하여 아키텍처 결정을 내리는 것을 계속 목격합니다.

에이전트(Agents)는 중간 정도의 복잡성을 가진 업무를 위한 훌륭한 보조자입니다. 그것은 진정으로 유용합니다. 그 가치를 과소평가하는 것을 멈추세요.
전문가 수준의 자율성(Autonomy)은 아직 여기에 없습니다. 그것을 기반으로 제품을 계획하는 것은 도박입니다.
데모(Demos)보다 벤치마크(Benchmarks)가 더 중요합니다. 통제된 테스트는 언제나 선별된 스크린캐스트(Screencast)보다 우월합니다.

만약 여러분이 오늘 에이전트 기반의 기능을 구축하고 있다면, 에이전트가 "곧" 할 것이라고 키노트 연사가 약속한 기능이 아니라, 에이전트가 "오늘" 실제로 할 수 있는 것에 맞춰 구축하십시오.

하이프 머신(Hype Machine)에는 벤치마크가 없다

실증적인 결과와 업계의 서사(Narrative) 사이의 괴리는 엄청납니다. 모델이 어려운 과제에서 말 그대로 0점을 기록해도, 대화의 흐름은 전혀 변하지 않습니다. 아무도 로드맵을 수정하지 않습니다. 아무도 기대치를 재조정하지 않습니다.

하이프 머신(Hype Machine)은 데이터로 움직이지 않습니다. 그것은 펀딩 라운드와 트위터(Twitter)의 인상(Impressions)으로 움직입니다. 💸

에이전트가 개선되지 않을 것이라고 암시하는 것이 아닙니다. 아마 개선될 것입니다. 하지만 "결국에는 아마 좋아질 것"이라는 말은 여러분이 이번 분기에 내리는 엔지니어링 결정의 끔찍한 토대가 됩니다.

내가 실제로 할 일

만약 제가 지금 제품을 계획하고 있다면, 저는 에이전트를 주니어 개발자처럼 취급할 것입니다. 명확한 가드레일(Guardrails)이 있는 잘 정의된 범위의 작업에는 유용합니다. 하지만 복잡한 작업에 감독 없이 방치하면 끔찍합니다.

이는 다음을 의미합니다:

중요도가 높은 모든 작업에는 인간 참여(Human-in-the-loop)가 필요합니다. 선택 사항이 아닙니다. 필수 사항입니다.
에이전트의 작업 범위를 엄격하게 제한하십시오. 작업이 좁을수록 결과물이 더 좋습니다.
모든 것을 측정하십시오. 실제 워크로드(Workload)에서 에이전트의 성능을 벤치마크할 수 없다면, 여러분은 눈을 감고 비행하는 것과 같습니다.

지루하고 실용적인 접근 방식은 "우리는 QA 팀 전체를 에이전트로 교체했습니다"라고 트윗하는 것만큼 재미있지는 않습니다. 하지만 그것은 실제로 작동하는 소프트웨어를 출시하게 해줍니다. 🤷

요점 (The Takeaway)

전문가 수준의 과제에서 0%의 점수를 기록했다는 것은 단 하나의 모델이 실패했다는 것을 의미하지 않습니다. 오히려 이는 '모든 것에 다 들어맞는(one size fits all)' 이야기에 대한 경종입니다. 에이전트(Agents)는 도구이며 — 심지어 훌륭한 도구일 수도 있지만 — 하이프 사이클(hype cycle)이 팔고 있는 자율적인 노동력은 아닙니다. 현실에 맞춰 구축하십시오. 실제로 작동하는 것을 지지하십시오. 벤치마크(benchmarks)를 번거로운 장애물로 취급하는 사람을 경계하십시오.

여러분이 보기에 팀들이 실제로 출시하려고 시도했던 에이전트 기능 중 가장 과장된 것은 무엇인가요? 아래에 여러분의 실전 경험담(war stories)을 들려주세요.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0