이번 주에 나는 나의 코딩 에이전트 (coding agent)에게 다소 불편한 과제를 주었다. 바로 우리가 시간을 낭비해 왔는지 알아내라는 것이었다.

이 블로그의 모든 모델 대결 (Model Showdown) 라운드는 우리가 직접 작성한 도구들로 실행된다. 즉, 베이크오프 하네스 (bakeoff harness), 채점 루브릭 (scoring rubric), thermal-test.sh, 그리고 수십 개의 포스트에 걸쳐 짜깁기된 임시 토큰 카운팅 (ad hoc token counting) 도구들이다. 나의 코딩 에이전트는 이 모든 과정에서 나의 연구 파트너이기도 하다. 구조적으로 우리 둘 다 코더 (coder)이다. 그리고 나는 이것이 강점이 아니라 편향 (bias)이 아닐까 하는 의구심이 들기 시작했다. 만약 당신이 가장 잘하는 도구가 코드를 작성하는 것이라면, 당신에게 주어지는 모든 문제는 코드를 더 작성함으로써 해결해야 하는 문제처럼 보이기 시작한다. 소비자용 AI 하드웨어를 테스트하고 싶은가? 그렇다면 하네스 (harness)를 구축하라. 물론 우리는 여기저기서 라이브러리 (libraries)를 재사용하기도 하지만, 누군가 이미 이 문제를 해결했는지 묻는 대신 매번 직접 모든 것을 하나하나 이어 붙이고 있다.

그래서 이번 과제는 코딩이 아닌 조사였다. 취미 활동가들 — Linus Tech Tips / Gamers Nexus / Level1Techs 팬층 — 과 더 넓은 AI 벤치마킹 (benchmarking) 세계가 이미 무엇을 발표하고 있는지 찾아내는 것이다. 그런 다음, 우리가 직접 만드는 대신 그것들 중 무엇이라도 사용했어야 했는지 나에게 솔직하게 말해달라는 것이었다.

이미 나와 있는 것들

하드웨어 리뷰 전문 채널들. LTT Labs는 MarkBench를 운영하고 있는데, 이는 오케스트레이션 (orchestration) 및 데이터 수집 프레임워크로, LTT 영상에서 수치를 생성하는 것과 동일한 실제 테스트 하네스 (test harnesses) 코드가 GitHub에 오픈 소스로 공개되어 있으며 분기별로 업데이트됩니다. 이는 LLM이 아닌 GPU와 게임을 위해 구축되었습니다. 한 하네스는 PyAutoGUI 스크립트를 사용하여 메뉴를 클릭하며, 다른 하나는 화면상의 텍스트를 찾기 위해 OCR (광학 문자 인식) 서비스를 실행합니다. Gamers Nexus는 동일한 문제에 대해 정반대의 접근 방식을 취합니다. 재사용 가능한 프레임워크가 아니라, 어떤 표준 운영 절차 (SOPs), 테스트 벤치 (test benches), 그리고 설정이 어떤 차트를 만들어냈는지를 정확히 기록한 공개적인 리빙 도큐먼트 (living document)를 제공하며, 리뷰가 진행될 때마다 업데이트됩니다. 두 곳 모두 LLM 워크로드 (workload)를 다룬 적은 없습니다. 그리고 GN은 내가 질문을 마치기도 전에 내 논지에 대한 가장 강력한 반론을 제시했습니다. 2025년에 그들은 완전히 새로운 측정 방법론인 "애니메이션 오류 (animation error)"를 발표했습니다. 지난 10년 동안 업계 표준이었던 프레임 레이트 (framerate) 및 프레임 타임 (frametime) 테스트가 플레이어가 실제로 느끼는 끊김 현상 (stutter)을 여전히 포착하지 못했기 때문입니다. 업계에서 가장 자원이 풍부한 리뷰어들조차 때로는 기존의 그 어떤 것도 자신들이 필요로 하는 것을 측정하지 못한다고 결론짓고, 새로운 것을 직접 만들어내기도 합니다. 이것은 자동으로 편향 (bias)을 의미하는 것이 아닙니다. 때로는 그것이 단지 정답일 뿐입니다.

벤더 중립적인 AI-PC 스위트 (vendor-neutral AI-PC suites). AMD, Intel, Microsoft, NVIDIA, Qualcomm이 모두 참여하여 MLCommons가 구축한 MLPerf Client는 현재 v1.6 버전이며, Windows, macOS 또는 Linux 클라이언트가 요약 및 콘텐츠 생성과 같은 실제 생성형 AI (generative AI) 작업을 어떻게 처리하는지 측정합니다. UL의 Procyon AI 텍스트 생성 벤치마크 (UL's Procyon AI Text Generation Benchmark)는 동일한 작업의 기업용 버전입니다. Phi-3.5-mini, Mistral-7B, Llama-3.1-8B, Llama-2-13B를 대상으로 7개의 고정된 프롬프트를 사용하며, 라이선스가 필요합니다. 두 가지 모두 실제적이고 신뢰할 수 있지만, 우리에게는 완전히 쓸모가 없습니다. 우리가 실제로 실행하는 모델이 단 하나도 포함되지 않은 고정된 모델 목록을 사용하며, 두 가지 모두 에이전트가 50번의 도구 호출 (tool calls)에 걸쳐 작업을 유지할 수 있는지 여부가 아니라 단일 턴 추론 (single-turn inference)만을 측정하기 때문입니다.

정확히 우리의 스택을 위해 구축된 도구들. llama-bench는 llama.cpp 내부에 포함되어 있으며, 가공되지 않은 프롬프트 처리 (prompt-processing) 및 토큰 생성 (token-generation) 속도에 대한 사실상의 커뮤니티 표준입니다. llama-benchy는 동일한 측정 방식을 모든 OpenAI 호환 백엔드 (OpenAI-compatible backend)로 확장하며, 이것이 바로 제가 지난 7월에 이를 깔끔한 승리라고 표시한 이유이자, 실제 비교 테스트 (bakeoff)에 연결하지 않았던 이유입니다. OpenBenchmarking.org는 Phoronix Test Suite를 실행하는 누구나 참여할 수 있도록 llama.cpp 결과를 크라우드소싱하며, 선택 사항(opt-in)으로 분산(variance)이 안정될 때까지 자동으로 재실행합니다. 이 세 가지 중 그 어떤 것도 처리량 (throughput) 이상의 것은 측정하지 않습니다. 그 어떤 것도 평가 기준 (rubric)을 대체할 수는 없었습니다. 하지만 그럴 필요도 없었습니다. 그것들은 우리가 건너뛴 그 아래의 계층일 뿐입니다.

우리의 실제 동료 그룹. Level1Techs 포럼 멤버가 Strix Halo LLM 벤치마크 하네스 (benchmark harness)를 처음부터 구축하여, 최신 MoE 아키텍처를 대상으로 엄격한 스윕 (sweeps)을 수행하고, 커뮤니티가 분석할 수 있도록 전체 결과를 GitHub에 커밋했습니다. 이것은 이 블로그가 몇 주마다 수행하는 것과 동일한 행보입니다. 분명히 말해둘 가치가 있습니다. "한 취미가가 자신만의 하네스를 구축하고 이를 공개한다"는 것은 저나 제 에이전트의 습관에 결함이 있다는 뜻이 아닙니다. 그것은 바로 이 커뮤니티가 작동하는 정상적이고 존중받는 방식입니다.

우리에게 실제로 중요한 계층. Model Showdown는 처리량 (throughput) 테스트가 아닙니다. 그것은 에이전트 정확성 (agentic-correctness) 테스트이며, 그 분야는 양상이 다릅니다. Aider의 Polyglot 벤치마크 (benchmark)는 Aider 자체의 구조화된 편집 루프 (edit loop) 내에서 가장 어려운 225개의 Exercism 연습 문제를 통해 모델을 평가하며, 커뮤니티가 기여한 결과는 PR을 통해 병합됩니다. SWE-bench Verified는 실제 GitHub 이슈와 인간이 검증한 테스트 스위트 (test suite)를 기준으로 패치를 등급화하지만, 주목할 만한 복잡성은 에이전트 하네스 (agentic harness)와 기반 모델을 함께 평가한다는 점입니다. 이것이 바로 서로 다른 연구소들이 동일한 모델에 대해 서로 다른 수치를 보고하는 정확한 이유입니다. Terminal-Bench와 METR의 RE-Bench는 컨테이너화된, 도구 사용 (tool-using), 장기적 작업 (long-horizon work) 영역으로 더 깊이 나아갑니다. 최근의 post-SWE-bench 환경에 대한 조사는 제가 직접 말하는 것만큼이나 직설적으로 다음과 같이 설명했습니다. 평가는 저장소 복구 (repository repair), 터미널 실행 (terminal execution), 그리고 도구 사용 신뢰성 (tool-use reliability)을 함께 테스트하는 하네스 포트폴리오 (harness portfolios)를 향해 이동하고 있으며, 단일 벤치마크는 하나의 신호일 뿐 결정의 전체 근거가 될 수 없다고 말입니다.

솔직한 답변

두 부분으로 나누어 생각해야 합니다. 왜냐하면 우리 스택의 두 절반은 서로 다른 성적을 받기 때문입니다.

처리량 계층 (The throughput layer): 네, 우리는 바퀴를 재발명했으며, 우리도 그 사실을 알고 있었습니다. llama-bench와 llama-benchy는 이미 "이 하드웨어에서 이 모델이 얼마나 빨리 실행되는가"라는 문제를 해결하고 있으며, 인프라 변경 없이 우리의 기존 엔드포인트에 바로 적용할 수 있습니다. 저는 특히 지난 7월의 연구 포스트에서 llama-benchy를 명확한 승리 요인으로 지목했었습니다. 하지만 그다음 Model Showdown 라운드에서도 여전히 비공식적인 토큰 카운팅(informal token counting) 방식이 보고되었습니다. 이것은 근소한 차이가 아닙니다. 이것은 우리 자신의 블로그에서 현행 중인 편향(bias)이 발각된 것입니다.

에이전트 계층 (The agentic layer): 아니요, 깔끔하게 해결되지 않았으며, 이는 단순히 고집을 부리는 문제가 아닙니다. Aider Polyglot는 Model Showdown이 수행하는 작업과 가장 유사하지만, 여전히 더 좁은 범위를 테스트하고 있습니다. 즉, 샌드박스 내에서의 고립된 Exercism 퍼즐, 단 한 번의 수정 및 재시도 루프(edit-and-retry loop)를 수행하며, 실제 리포지토리(repo)도, git도, Playwright도, 조용히 잘못될 수 있는 50회 차례의 세션도 없습니다. Terminal-Bench는 정신적인 측면에서는 더 가깝지만, Coder Agents 채팅에 연결되어 있지 않으며 우리의 평가 기준(rubric)을 알지 못합니다. 이 중 어느 하나를 통째로 채택하는 것은, 더 좁은 신호(signal)를 얻는 대가로 이미 우리 자체 테스트 프레임워크(harness)가 요구하던 것만큼이나 많은 통합 코드를 구축해야 함을 의미했습니다. 이는 이 블로그에서 습관이 된 보안 감사 작업과 같은 형태입니다. 때로는 "구매할 것인가, 구축할 것인가(buy vs. build)"에 대한 답이 정말로 구축인 경우가 있으며, 그 답변의 정직한 버전은 단순히 기본값으로 선택하는 대신 구체적인 이유를 명시하는 것입니다.

다음 단계 (What's Next)

그러한 구분은 단순한 느낌(vibe)이 아니라 하나의 주장(claim)이며, 그러한 주장은 단순히 멋진 단락으로 남겨두는 대신 데이터로 검증되어야 합니다. 따라서 다음 단계는 실제 실험입니다. 동일한 모델에 대해 우리가 임시로(ad hoc) 측정한 타이밍과 llama-bench/llama-benchy를 대조하여 실행하고, 최근 Model Showdown 라운드의 두 모델을 대상으로 Aider의 Polyglot 벤치마크의 일부를 우리의 자체 루브릭(rubric)과 나란히 실행하며, 각 접근 방식에 설정 시간(setup time)이 얼마나 소요되었는지 정직하게 기록하는 것입니다. 왜냐하면 만약 타인의 테스트 프레임워크(harness)를 구축하는 것이 직접 만든 자체 라운드를 실행하는 것보다 더 오래 걸린다면, 그 자체로 누구의 수치가 더 유용한지와는 별개로 편향(bias)에 대한 증거가 되기 때문입니다.

저는 기존 도구들이 처리량(throughput) 측면에서 압도적으로 승리할 것이며, 자체 제작한 루브릭은 Polyglot이 구조적으로 찾아낼 수 없는 것들을 계속해서 발견할 것이라고 예측합니다. 제가 틀릴 수도 있습니다. 다음 포스트에서 어느 쪽이든 말씀드리겠습니다.

다시 논제로 돌아가겠습니다. 곧 다시 뵙겠습니다.