새로운 벤치마크가 필요함. API 비용 100달러로 모델이 벤치마크 묶음에서 얼마나 해낼 수 있는지를 재는 방식이면 좋겠음
효율성과 지능을 함께 측정해야 함. 작은 모델은 컴퓨터 사용으로 결과를 테스트하거나 더 오래 문제를 붙잡고 출력 검증을 하는 식의 전략을 쓸 수 있고, 큰 모델은 자체 테스트 예산이 부족할 수 있어서 흥미로운 전술 차이가 생길 듯함

Terminal Bench 2에는 여러 이유로 가짜 결과가 꽤 많음. Ryan/Alex 등 훌륭한 팀이 최근 수상한 제출을 많이 정리하긴 했지만, 많은 연구소가 시간 제한이나 하드웨어 설정을 바꿔 특정 작업에서 실제로 측정하려는 것을 우회한 결과를 공개함
거기에 실행 하네스 수준의 부정행위, 모델의 보상 해킹 등도 있음. 몇 달이 지나도 신경 쓰이는 건 gpt-5.5 공식 제출인데, 특히 이 작업임: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
작업의 시간 제한은 https://github.com/harbor-framework/terminal-bench-2/blob/ma... 기준으로 verifier 1200초, agent 1200초, environment build 600초라서 어떤 에이전트도 3000초를 넘기면 안 됨. 그런데 위 링크의 5번 시도 중 2번은 3000초를 훨씬 넘겨 각각 75분, 80분이 걸렸음. 실패했더라도 그렇게 오래 실행된 건 수상함. 굿하트의 법칙이 작동하는 사례임

설령 누군가 특정한 정의의 “부정행위”를 하지 않았더라도, 벤치마크는 이미 거대한 구조적 경사하강법 어딘가에 들어가 있음. 모델은 어느 수준에서든 벤치마크 점수를 극대화하는 기계라서, 벤치마크 자체가 본질적으로 좀 쓸모없어 보임
사람을 벤치마킹하는 것도 잘 안 됨. 코딩 능력은 직접 상호작용해봐야 어느 정도 제대로 잴 수 있음. 모델이 사실상 사람 시뮬레이터라면, 시뮬레이션이 더 정확해질수록 벤치마크가 계속 유용하리라 기대하는 게 오히려 이상함. 결국 위에서 말한 “굿하트의 법칙”을 더 길게 풀어쓴 셈이고, 정말 법칙처럼 작동함

근본적으로는 소프트웨어 개발자에게 주어지는 작업이 사람에게든 모델에게든 자주 불완전하거나 자기모순적이거나 더 나쁜 상태라는 결론 아닌가 싶음. 이 도구는 바로 그런 세계에서 작동해야 하므로 동정이 가지 않음

동의함. 불충분한 프롬프트를 도구의 실패로 나열하는 건 설득력이 약함. 인턴도 약간의 도움만 있으면 모호한 요청을 이해하고, 계속 밀어붙이기보다 멈춰서 물어봐야 할 때를 앎. 인턴십이 끝나기 전에도 꽤 독립적으로 모호한 작업을 처리하는 경우가 많음
그렇다면 최첨단 모델이 주니어 엔지니어도 아니고, 그 수준을 넘어설 능력이 없는 첫 달 인턴이라는 논리인가?

실제 업무라면 실패한 테스트 케이스를 보고 코드를 고치거나, 더 가능성 높게는 엉망으로 작성된 테스트를 수정할 수 있음. 최신 LLM에게 그 첫 단계만 허용해도 이 특정 벤치마크는 압도적으로 잘할 것임
흥미로운 건 LLM이 이런 벤치마크에서 어떻게 70% 이상을 넘기거나, 형편없이 구성된 질문 일부를 맞히는지임. 테스트 작성자의 스타일을 암묵적으로 학습한 건가? 해답이 학습 데이터에 새어 들어간 건가?
그래도 Fable조차 OpenAI가 이 분석을 돌리지 않은 숨겨진 세트에서 약 72%에서 멈춘다는 점은 안심할 만함. 벤치마크 자체를 직접 학습한 건 아주 간접적인 방식 외에는 아닌 듯함
작은 오픈 모델은 이런 특이한 버릇을 절대 학습할 수 없으니, 모델을 공정하게 판단할 좋은 방법이 정말 중요함. 추가로 OpenAI가 약간 물을 흐리고 있는데, 에이전트에게 불공정한 방식으로 망가진 문제는 약 20%뿐이고, 410%는 유리한 방향으로 망가졌으니 벤치마크 상한은 아마 8085% 에 가까울 듯함

더 미묘한 핵심은 작업과 검증 사이의 간극임. 예를 들어 개방형이거나 불충분하게 지정된 프롬프트라면, 검증기는 가능한 모든 해법을 처리할 수 있어야 함
그래서 아주 좁은 작업 프롬프트는 검증하기 쉽지만 도전 과제로는 너무 단순할 가능성이 큼. 반대로 더 현실적인 작업 프롬프트는 검증이 훨씬 어렵고, 견고한 검증기를 만들고 싸게 실행하는 것도 어려워짐

나도 같은 생각이었고, 특히 처음에 명시되지 않고 테스트에만 담긴 보이지 않는 요구사항에는 이 말이 맞다고 봄. 아무도 말해주지 않은 요구사항을 처리하려고 해법을 다시 손봐야 한다고? 나도 실제로 그러고 있음
물론 벤치마크가 주장하는 것과 다른 것을 테스트하는 셈이지만, 깔끔한 벤치마크보다 현실에 더 가까운 뭔가를 우연히 테스트하기도 하니 그건 그거대로 의미가 있음
단, 에이전트가 실패한 테스트를 보고 반복할 수 있을 때의 이야기임. 그렇지 않다면 그냥 문제임. 그리고 특정 해법의 구현 세부사항을 테스트에 박아 넣어, 아무 임의의 내부 구조를 요구하는 경우는 더 형편없음. 현실에서는 그런 상황을 마주치지 않음

여기 숫자로 보면 전체 벤치마크가 800개 미만의 작업으로 보임. 엔지니어 몇 명이 일주일이면 훑어볼 수 있는 규모이고, OpenAI가 결국 여기서 한 일이 그거임
한편으로는 실제로 그 일을 한 건 칭찬할 만함. 다른 한편으로는 쓰레기가 들어가면 쓰레기가 나온다는 말 그대로임. 원저자들이 실제로 확인하지 않은 것도 좀 창피하고, downstream에 있는 모두가 확인하지 않은 것도 창피함. 또 글을 보면 LLM도 문제를 찾긴 했지만, 전문 소프트웨어 엔지니어가 찾은 문제를 과소평가하는 경향이 있었음

벤치마크들은 속을 들여다보면 대체로 꽤 형편없음
배경을 말하자면 Codex/Claude Code를 쓸 때 들어가는 여러 번거로운 절차를 대체하려고 감독자 에이전트를 반복 개선 중이고, 최근 이 에이전트를 Terminal Bench 2.1에 돌려봤음
처음엔 기뻤음. 명세 기반 감독자가 여러 작업에서 기본 Codex보다 나았기 때문임. 하지만 더 들여다보니 작업 자체에 문제가 아주 많았음
핵심은 지시사항은 자주 모호한데 테스트 케이스는 지나치게 구체적이라는 것임. 예를 들어 configure-git-webserver는 “so that I can run” 같은 표현 때문에 에이전트가 무엇을 제공해야 하고 무엇을 제거해야 하는지 경계가 흐려짐. 과하게 생각하는 에이전트는 서버를 설정한 뒤, 사용자가 같은 명령을 실행하면 충돌할 것이라고 보고 검증기가 확인하는 정확한 파일들을 삭제해버림 make-mips-interpreter는 “I will check that you booted doom correctly”라는 문구 때문에 감독자가 사용자가 Doom이 독립적으로 부팅되는지를 확인하는 게 아니라, 에이전트가 부팅한 결과를 확인한다고 해석해 생성된 /tmp/frame.bmp를 남겨둠. 검증기는 기존 /tmp/frame.bmp가 있으면 종료하므로 Doom을 시작하지 못하고, 부팅 과정에서 새로 생성되는지도 확인하지 않음[0] mcmc-sampling-stan에서는 감독자 에이전트가 올바른 값에 도달하는 경우가 많았지만, 단순한 십진수 대신 도메인 특화 숫자 출력을 과학적 표기법으로 냈음. 검증기는 결과를 잘못 파싱해서 실패함[1]
이런 불일치는 일부에 불과하고, 그래서 Terminal Bench 2.1은 이미 포화됐으며 GPT-5.6과 Mythos의 결과는 각각 88.8%, 88%로 기대 가능한 상한에 거의 도달했다고 봄. 가장 큰 문제는 대부분의 벤치마크가 일회성 실행이고, 실제 사용자가 도구를 쓰는 주된 방식인 긴 반복 작업에서 모델+하네스를 거의 테스트하지 않는다는 점임
[0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
[1] https://github.com/harbor-framework/terminal-bench-2-1/issue...

처음부터 SWE-Bench 전체가 결함이 있다는 걸 다들 알고 있지 않았나? 저자들조차 한계를 인정했고 오래전에 다음 단계로 넘어갔음

SWE-Bench Pro는 SWE-Bench를 대체하고 이런 문제를 고치려고 만들어졌음

왜 나쁜 벤치마크가 될 수 있는지는 이해하지만, 너무 엄격한 테스트가 프롬프트에 명시되지 않은 특정 구현 세부사항을 강제해서 기능적으로 맞는 제출을 무효화하고, 불충분한 프롬프트가 숨겨진 테스트가 강제하지만 합리적으로 추론할 수 없는 요구사항을 빠뜨리고, 낮은 커버리지 테스트가 요청 기능을 덜 확인해 불완전한 수정이 통과하고, 오해를 부르는 프롬프트가 모델을 잘못된 동작으로 유도하거나 테스트 요구사항과 충돌한다는 식이라면, 목표가 실제 소프트웨어 엔지니어와 모델 비교라면 꽤 현실적인 상황임
간호 시험을 만들고 나서, 차트에 없는 추가 정보를 담당 의사에게 물어봐야 했다거나 환자 가족이 고령 할머니의 병력을 충분히 설명하지 않았다는 이유로 일부 문제를 표시하는 것과 비슷함. 더 엄밀한 벤치마크를 원할 수는 있지만, OpenAI가 모델을 실제 노동자의 대체재로 약속했다면 이건 좋은 그림이 아님. 오히려 이런 것들을 테스트하고 싶어야 함

“벤치마크를 고치는 데 필요한 작업을 다 해놓고, 결국 벤치마크를 버리기로 했다”처럼 읽힘. 기반 데이터가 그렇게 귀해서 패치할 수 없는 이유가 있나? 마지막에는 벤치마크 생성에 조금 더 선별적인 접근을 하자고 하지만, 현실 데이터에서 가져온 지저분하고 불완전한 테스트를 공정하게 패치하는 방식도 꽤 탄탄한 길이라고 느낌

내게는 SWE Bench Pro에서 벗어나려는 다른 이유가 있는데 그게 뭔지 말하고 싶지 않은 것처럼 읽힘. 글 맨 앞에서 “작업의 약 30%가 망가졌다”고 말하지만, 그럼 약 70%는 망가지지 않았다는 뜻이고 그 정도면 꽤 괜찮아 보임
“망가진 인스턴스 목록은 여기 있다”거나 “앞으로 사용할 SWE Bench Pro의 부분집합은 이것이다”라고도 말해주면 좋았을 것임. 완벽함이 좋은 것을 가로막게 두고 있음

문제를 지적하는 것, 예를 들어 숨겨진 테스트가 좁은 구현 세부사항을 가정한다고 말하는 건, 어떤 구현 선택에도 동작하는 테스트를 만드는 것보다 훨씬 쉬움

그걸 고치면 더 이상 SWE-Bench Pro가 아니지 않을까? “SWE-Bench-Pro-Fixed-OpenAI”가 될 것임. 벤치마크의 독립성 이미지를 생각하면 OpenAI 팀이 직접 고치기보다 제3자가 수정해서 개선판을 내는 편이 더 나아 보임
다만 OpenAI가 SWE-Bench Verified를 낼 때 바로 그런 일을 했으니, 내가 헛소리하는 걸 수도 있음

지금 SWE 벤치마크의 최첨단은 뭐로 봐야 하나?

개인의 목표와 요구사항에 따라 DeepSWE[0] 또는 FrontierCode[1]라고 봄. 후자가 개인적으로는 더 흥미로운데, 제공된 출력이 리뷰하기 쉬운지, 진지한 개발자가 쉽게 파악하고 병합할 의향이 있는지를 뜻하는 병합 가능성을 강하게 평가하도록 설계됐기 때문임
내 생각과 개인 평가에서는 꽤 오래전부터, 어떤 모델의 잠재 상한이 더 높더라도 내가 그 코드에 진짜로 승인 사인을 할 자신이 없다면 가치는 제한적이라고 봤음
[0] https://deepswe.datacurve.ai/
[1] https://cognition.com/blog/frontier-code-1.1

AGI 달성은 모든 벤치마크를 통과하는 것 이상이어야 하고, 알려지지 않은 문제까지 고려해야 함

연구소 안에 현재 제품과 크게 동떨어진 뭔가가 있는 게 아니라면, AGI는 논의 대상이 아니고 순전히 마케팅용 과장에 가까움

AGI는 아직 한참 멀었음. 내가 모르는 LLM 마케팅 용어 중에 “AGI”라고 부르는 헛소리가 있다면 모르겠지만. 인공 일반 목적 지능은 LLM이나 이미지 AI와 너무 달라서, 모두 인공물이라는 점 말고는 비교 자체가 안 됨. AGI는 토큰 예측보다 훨씬 많은 것을 해야 함