같은 모델, 17.5배 청구서: FrontierHarness가 코딩 에이전트의 숨은 변수를 노출한 이유
코딩 에이전트를 평가할 때 모델을 하나로 고정하면, 남는 변수는 하네스(harness) 하나뿐입니다. 그런데 그 하나의 변수가 같은 모델 위에서 pass rate를 17%p, 완수 작업당 비용을 최대 약 17.5배까지 벌립니다. 코딩 에이전트를 운영하거나 그 비용을 책임지는 ThakiCloud 같은 플랫폼 엔지니어라면, “모델을 어떻게 고를 것인가”라는 질문 옆에 “하네스를 어떻게 고를 것인가”를 같은 무게로 놓아야 하는 이유를 이 글에서 얻습니다.
이번 글의 출발점은 Runta의 FrontierHarness Eval v1.0(2026년 9월 1일)입니다. 같은 모델(Kimi K3, Fireworks 서빙)을 고정하고 하네스만 9종으로 바꿔 벤치마크를 돌렸더니, 품질과 비용과 속도가 하네스 선택에 따라 크게 갈린다는 것이 핵심입니다. 그리고 그 벤치마크를 자기 근거로 들며 MIT 라이선스로 오픈소스화한 MiniMax Code CLI(2026년 9월 18일 전후)가 같은 주에 발표됐습니다. 벤치마크의 발견과 제품의 자기 보고가 겹친 주라, 둘을 함께 읽는 것이 이 글의 틀입니다.
글의 핵심 개념을 형상화했습니다.
쉽게 말하면
같은 엔진을 사서 여러 차체에 얹는다고 생각하십시오. 마력수는 동일합니다. 그런데 한 차체는 그 엔진을 200km/h 순항에 최적화했고, 다른 차체는 급가속에, 또 다른 차체는 연비에 맞게 달립니다. 엔진을 재면 전부 같은 마력이 나오지만, “킬로미터당 연료”는 차체 설계에 따라 몇 배로 벌어집니다. 코딩 에이전트에서 모델이 엔진이고, 하네스가 차체입니다. 같은 모델이면 품질이 비슷할 것이라고 믿기 쉽지만, FrontierHarness가 재고 있는 것은 연비, 즉 완수한 작업 하나당 쓰는 비용과 시간입니다. 그리고 연비는 엔진이 아니라 차체에서 정해졌습니다.
개요
FrontierHarness Eval은 코딩 에이전트 벤치마크를 “모델 고정, 하네스 변동” 축으로 세워 둔 실험입니다. 설계는 단순합니다. 단일 모델(Kimi K3)을 Fireworks가 서빙하게 고정하고, 코딩 에이전트 하네스를 9종으로, 구성을 12개로, 작업을 30개로(Terminal-Bench 2.1 21개 + DeepSWE v1.1 9개) 조합해 총 360회를 평가합니다. 모델은 그대로 두고, 그 모델을 감싸는 장치만 바꾸어 어떤 지표가 벌어지는지를 재는 것입니다.
이 축 선택이 중요한 이유는, 코딩 에이전트 논의가 “어떤 모델이 강한가”에 갇혀 있을 때, 실제로 청구서를 좌우하는 변수가 모델 바깥에 있다는 것을 보여 주려는 데 있습니다. 벤더가 “우리 모델이 SOTA”라고 말할 때, 그 SOTA가 모델 때문인지 그 모델을 돌리는 하네스 때문인지를 갈라 놓으려면, 모델을 고정하고 하네스를 바꿔야 합니다. FrontierHarness는 바로 그 갈림을 세운 실험입니다.
같은 모델만 고정해도 청구서가 17.5배
Runta의 v1.0 리포트 기준, 같은 Kimi K3 위에서 하네스를 바꾸면 지표가 이렇게 벌어집니다.
| 축 | 범위 | 비고 |
|---|---|---|
| pass rate | 50.0% ~ 66.7% | 17%p 차이, 품질은 하네스에 따라 대동소이 |
| 완수 작업당 비용 | $1.05 ~ $18.34 | 최대 약 17.5배 차이 |
| 완료 속도 | 중앙 5분 41초(DSH Minimal) 등 | 하네스별 상이 |
여기서 읽어 낼 것은 두 가지입니다. 먼저, 품질(pass rate)은 50~67% 사이에 몰려 있어 “하네스가 품질을 크게 바꾸진 않는다”는 인상을 줍니다. 그러나 완수 작업당 비용은 $1.05에서 $18.34로, 같은 품질을 재는 데 17.5배의 청구서 차이가 납니다. 리포트가 든 예는 품질 1위(Codex, 66.7%), 균형형(Pi, 60.0% / $2.43·pass), 저비용(Exo Harness, $1.05), 최고속(DSH Minimal, 중앙 5분 41초)으로, 같은 모델 위에서 “무엇을 우선할 것인가”에 따라 다른 하네스가 전면에 나옵니다.
이것이 이 벤치마크의 진짜 발견입니다. 하네스는 품질의 변수가 아니라, 같은 품질의 비용과 속도의 변수입니다. 품질은 비슷하게 유지되는 동안, 하네스 선택이 청구서를 최대 17.5배까지 움직입니다. “모델을 고르는 것”과 “하네스를 고르는 것”을 같은 비용 체계로 묶어 볼 수 없는 이유가 여기에 있습니다.
MiniMax의 76.7%: 자기 보고, 그리고 그 경계
같은 주에 MiniMax Code CLI가 v0.4.12로 MIT 라이선스 오픈소스화했습니다. 계획 모드·서브에이전트·플러그인·미디어/검색 도구를 갖춘 코딩 에이전트 CLI로, 저장소는 github.com/MiniMax-AI/minimax-code입니다. MiniMax는 이 CLI를 FrontierHarness 기준으로 평가해 30개 작업(Kimi K3)에서 76.7% pass rate, 성공 런 중앙 완료 시간 4분 33초, 평균 완료 속도 1위·토큰 사용량 최저 근접이라고 자기 보고했습니다.
여기서 경계를 분명히 해야 합니다. 76.7%는 Runta의 v1.0 공식 리포트가 제시한 50.0~66.7% 범위를 벗어납니다. 즉 이 수치는 MiniMax의 자기 보고이며, 공식 리포트의 공개 베이스라인과 같은 조건으로 확인된 값은 아닙니다. 벤치마크의 버전·조건·서빙 설정이 어떻게 다른지는 확인되지 않았습니다. 그래서 이 글은 76.7%를 “SOTA 사실”이 아니라 “벤더가 같은 벤치마크를 근거로 든 자기 보고”로만 취급합니다.
이 구분이 왜 중요한지는, 이 글의 주제 자체가 “모델이 아니라 하네스가 변수”이기 때문입니다. MiniMax Code CLI가 FrontierHarness에서 76.7%를 낸다면, 그 수치의 상당 부분은 MiniMax의 모델이 아니라 그 모델을 감싼 하네스 설계에서 나올 가능성이 있습니다. 17.5배의 비용 차이가 하네스에서 나왔다는 FrontierHarness의 발견을, MiniMax의 자기 보고를 검증하는 렌즈로 다시 씁니다. “우리 하네스가 강하다”는 주장에 가장 잘 맞는 대조군이 바로 이 벤치마크입니다.
구조: 하네스가 변수가 되는 지점
아래 도표가 이 축을 보여 줍니다. 모델은 하나(Kimi K3)로 고정되고, 그 위에서 하네스 9종이 pass rate·비용·속도 세 축을 동시에 움직입니다. 품질 축은 좁게, 비용·속도 축은 넓게 벌어지는 것이 FrontierHarness의 모양입니다.
flowchart TB
M[(고정 모델<br/>Kimi K3, Fireworks 서빙)] --> H[하네스 계층<br/>9종 x 12구성]
H --> T1[pass rate<br/>50.0~66.7%]
H --> T2[완수 작업당 비용<br/>$1.05~$18.34]
H --> T3[완료 속도<br/>중앙 5분 41초 등]
T1 -.좁은 범위.-> Q[품질은 대동소이]
T2 -.넓은 범위 17.5배.-> C[청구서는 하네스가 정한다]
T3 -.하네스별 상이.-> L[속도도 하네스가 정한다]
이 도표에서 주목할 것은 화살표의 방향입니다. 품질은 하네스를 거쳐도 좁게 변하고, 비용과 속도는 하네스를 거쳐 넓게 변합니다. 같은 모델을 두고 “어떤 에이전트가 비싸고 느린가”를 정하는 것은 모델이 아니라 하네스 계층입니다. ThakiCloud가 에이전트 서빙 비용을 최적화할 때 최적화 대상이 모델 선택에서 하네스 선택으로 넘어가야 하는 이유가, 이 도표에 그대로 들어 있습니다.
ThakiCloud 관점: Metis의 서빙 최적화와 Paxis의 하네스 계층
ThakiCloud는 이 발견을 두 제품의 교차점에서 읽습니다.
Metis 관점(주). FrontierHarness의 “같은 모델, 하네스 17.5배”는 Metis가 푸는 서빙 비용 최적화와 같은 문제입니다. Metis가 서빙하는 대상은 모델이고, 그 모델을 감싸는 실행 장치(컨텍스트 처리, 도구 호출, 캐시, 배치)가 하네스에 해당합니다. 같은 모델을 Metis 위에서 서빙할 때, 그 실행 장치를 어떻게 세우느냐가 토큰당 원가와 완료 속도를 정한다는 것은, 17.5배라는 외부 검증과 같은 방향입니다. ThakiCloud의 백서에서 이미 서빙 설정(컴파일, 배치 상한, KV 캐시)이 처리량과 단가를 지배하는 것을 재고 있었는데, FrontierHarness는 그 지배가 “모델 바깥”에서 일어난다는 점을 코딩 에이전트 축에서 확인해 줍니다. 온프레미스·소버린 환경에서 그 실행 장치를 직접 세울 수 있다는 Metis의 장점은, 하네스 비용을 외부 벤더의 17.5배 변동이 아니라 자기 클러스터의 cap으로 고칠 수 있다는 뜻입니다.
Paxis 관점(보완). Paxis의 Skill Harness·격리 샌드박스·정책 게이트·감사 로그는, 하네스 계층 그 자체를 1급 리소스로 다루는 설계입니다. FrontierHarness가 “하네스가 비용과 속도의 변수”라고 재면, Paxis는 “그 변수를 일급 리소스로 관리한다”는 쪽에 섭니다. 17.5배의 차이가 하네스 설계에서 나온다면, 기업 에이전트 운영에서 하네스 계층을 표준화·측정·통제하는 것이 곧 청구서 통제는 됩니다. Paxis가 스킬 선택·실행 격리·비용 회계를 한 평면에서 다뤄야 하는 이유가, 이 발견이 외부에서 확인해 준 것입니다.
한계 및 반론
첫째, FrontierHarness는 단일 모델(Kimi K3)을 고정한 실험입니다. 모델이 바뀌면 “하네스 변동”의 크기도 바뀔 수 있고, 이 17.5배는 Kimi K3 위에서 재진 값입니다. 다른 모델에서는 하네스의 비용 지배가 더 강할 수도, 더 약할 수도 있습니다.
둘째, 30개 작업·360회 평가는 코딩 에이전트 전체 분포를 대표한다고 단정할 수 없는 규모입니다. Terminal-Bench 2.1과 DeepSWE v1.1이라는 두 벤치의 조합에 의존하며, 작업 난이도 분포가 특정 영역에 쏠려 있으면 비용 범위가 그 영역에 과대 표현될 수 있습니다.
셋째, MiniMax의 76.7%는 공식 리포트 범위 밖의 자기 보고입니다. 이 글은 그 수치를 사실로 인용하지 않고, 검증의 렌즈로만 씁니다. 벤더의 자기 보고를 벤치마크의 발견과 같은 무게로 놓는 것은, 정확히 이 글이 경계하는 오류입니다.
넷째, pass rate와 비용이 “같은 품질”을 재는 지표인지에 주의가 필요합니다. $1.05의 하네스가 $18.34의 하네스보다 “아주 조금” 품질이 낮다면, 그 미세 품질 차이를 비용 17.5배와 같은 축으로 비교하는 것은 위험합니다. FrontierHarness의 원리에는 그 품질 미세차를 어떻게 보상했는지가 함께 확인돼야 하며, 이 글은 그 세부 보정까지 검증하지는 않았습니다.
그래서 무엇을 바꿀 수 있나
읽고 나면 바로 적용할 수 있는 것은 세 가지입니다.
하나, 코딩 에이전트의 벤치마크를 “모델 비교”로만 세우지 마십시오. 모델을 하나 고정하고 하네스를 2~3종만 바꿔 완수 작업당 비용과 완료 속도를 재는 최소 실험을, 도입 전에 한 번 돌리십시오. 17.5배는 모델 벤치마크가 아니라 하네스 벤치마크에서만 보입니다.
둘, 청구서 최적화 대상을 모델 선택에서 하네스 선택으로 한 번 더 넓히십시오. ThakiCloud의 Metis에서 서빙 설정(컨텍스트·캐시·배치)을, Paxis에서 실행 격리와 비용 회계를 최적화 대상으로 두는 것은, FrontierHarness가 “모델 바깥이 변수”라고 확인해 준 방향과 일치합니다.
셋, 벤더의 SOTA 자기 보고에는 대조군을 붙이십시오. MiniMax의 76.7%가 공식 리포트 범위 밖이라면, 그 주장에 “같은 조건에서 재봤나”를 묻는 대조가 먼저입니다. 큰 승리 폭은 축하가 아니라, 기준선이 무엇인지를 확인하라는 경보입니다.
코딩 에이전트의 숨은 변수는 모델이 아니라 하네스입니다. FrontierHarness는 그 변수를 17.5배라는 청구서로 확인해 주었고, MiniMax는 그 벤치마크를 근거로 자기 하네스를 내밀었습니다. ThakiCloud의 Paxis는 같은 전장을 이미 하네스 계층의 1급 리소스로 다루는 쪽에 섭니다.
