WeirdML은 LLM에게 낯선 머신러닝 문제를 주고, 직접 PyTorch 코드를 작성해 풀게 하는 벤치마크다. 단순히 알고 있는 지식을 맞히는 시험이 아니다. 모델이 데이터를 이해하고, 구조를 설계하고, 실행 오류와 정확도 피드백을 바탕으로 최대 5번까지 수정하는 능력을 본다.1
그래서 WeirdML에서 중요한 질문은 “어떤 모델이 1등인가”에 그치지 않는다. 더 실용적인 질문은 이것이다. AI가 만든 ML 코드를 사람이 실제로 검토하고 운영할 수 있는가?
이번 결과에서 Claude Opus 4.8 xhigh는 82.9% 정확도를 기록했다. GPT-5.5 xhigh보다 낮은 점수였지만, 주목할 만한 차이는 코드 길이였다. Claude Opus 4.8 xhigh는 129줄의 코드로 실행됐고, GPT-5.5 xhigh는 517줄의 코드로 실행됐다는 비교가 나왔다.2 성능 차이만큼이나 “간결한 해결책”의 가치가 드러난 대목이다.
WeirdML은 무엇을 측정하나
많은 벤치마크는 모델이 이미 알고 있을 법한 문제를 얼마나 잘 푸는지에 가까울 때가 있다. WeirdML은 방향이 다르다. 낯선 데이터와 제한된 실행 환경에서 모델이 실제로 문제를 해결하도록 만든다.
Epoch AI 설명에 따르면 코드는 격리된 Docker 환경에서 실행되며, TITAN V 12GB GPU와 600초 제한이 적용된다.3 즉 모델은 무한한 자원으로 답을 찾는 것이 아니라, 제한된 조건 안에서 작동하는 코드를 만들어야 한다.
이 때문에 WeirdML 점수는 단순한 “코딩 능력”보다 넓은 의미를 갖는다. 문제 정의를 해석하고, 모델링 전략을 세우고, 실패를 수정하는 에이전트형 ML 작업 능력에 가깝다.
82.9%보다 흥미로운 129줄
Claude Opus 4.8 xhigh의 82.9%는 GPT-5.5 xhigh의 83.9%에 근접한 수치다.4 점수만 보면 GPT-5.5 xhigh가 앞선다. 하지만 실제 업무 관점에서는 코드 길이도 중요한 판단 기준이다.
짧은 코드는 보통 검토하기 쉽고, 수정하기 쉽고, 실패 원인을 찾기 쉽다. 반대로 긴 코드는 더 많은 전략을 담을 수 있지만, 그만큼 디버깅과 유지보수 비용이 커질 수 있다. WeirdML 결과가 흥미로운 이유는 바로 여기에 있다. 최고 점수와 가장 실용적인 산출물이 항상 같은 방향을 가리키지는 않을 수 있다.
물론 코드가 짧다고 항상 더 좋은 것은 아니다. 하지만 비슷한 정확도라면, 더 간결한 코드는 팀이 AI 산출물을 받아들이는 데 유리한 조건이 된다.
“생각하는 모드”가 성능에 미치는 영향
이번 결과에서 또 하나 중요한 신호는 Claude의 thinking 기능이다. Claude에서 thinking을 비활성화했을 때 정확도가 70.5%로 떨어졌다는 보고가 있다.2
이는 WeirdML 같은 고난도 ML 작업에서 “빠르게 답을 내는 모델”보다 “문제를 더 깊게 분석하고 수정할 수 있는 모델”이 유리할 수 있음을 보여준다. 특히 데이터 실험, 모델 구조 설계, 오류 수정이 함께 필요한 작업에서는 추론 모드가 단순 옵션이 아니라 성능 변수로 작동할 수 있다.
모델을 비교할 때 봐야 할 것
Claude Opus 4.8과 GPT-5.5는 Vellum 리더보드 기준 모두 100만 토큰 컨텍스트를 지원한다.5 긴 문제 설명이나 큰 코드베이스를 넣을 수 있다는 점만으로는 두 모델을 뚜렷하게 구분하기 어렵다.
차이가 나는 부분도 있다. Vellum 기준 GPT-5.5의 지식 컷오프는 2026년 4월, Claude Opus 4.8의 지식 컷오프는 2026년 1월로 표시된다.5 최신 정보가 중요한 작업이라면 이 차이를 고려해야 한다.
다만 WeirdML 같은 벤치마크에서는 “누가 더 최신 정보를 아는가”만으로 판단하기 어렵다. 실제 선택 기준은 더 복합적이어야 한다.
정확도는 충분히 높은가
생성된 코드는 사람이 검토할 수 있는 수준인가
디버깅과 수정이 쉬운가
추론 모드가 성능에 얼마나 영향을 주는가
제한된 실행 환경에서 안정적으로 작동하는가
실무에서 얻을 수 있는 교훈
WeirdML은 단순한 모델 순위표라기보다 실전형 ML 에이전트 테스트에 가깝다. AI에게 데이터 실험이나 모델링 코드를 맡길 때는 최고 점수만 보면 부족하다. 생성 코드의 길이, 복잡도, 디버깅 가능성까지 함께 봐야 한다.
이번 결과가 주는 핵심 메시지는 명확하다. 좋은 ML 에이전트는 높은 정확도뿐 아니라, 사람이 이해하고 관리할 수 있는 해결책을 만들어야 한다. WeirdML은 그 차이를 드러내는 유용한 기준점이 되고 있다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.