동일한 모델이라도 서로 다른 제품처럼 느껴질 수 있습니다. 누락된 변수는 바로 하네스 (Harness)입니다.

저는 Kimi K3를 두 가지 설정으로 실행해 왔습니다. Moonshot의 자체 제품인 Kimi Code CLI와 Claude Code에 연결된 K3입니다. 동일한 모델임에도 불구하고 경험은 눈에 띄게 달랐습니다. 제 경험상, 호환성 설정이 저하되어 있고 일부 도구를 사용할 수 없음에도 불구하고 Claude Code 측이 더 매끄럽게 느껴졌습니다.

이는 통제된 벤치마크 (Benchmark)가 아닌 개인적인 관찰입니다. 더 흥미로운 증거는 Moonshot 자체에서 나옵니다.

공식 K3 모델 카드 (Model Card)에 따르면, K3가 Kimi Code에서 실행될 때 Kimi Code Bench 2.0 점수는 72.9점을 기록합니다. 각주에는 Claude Code 환경에서 실행했을 때 73.7점이라고 보고되어 있습니다. 동일한 결과 내의 두 가지 코딩 벤치마크와 두 가지 에이전트적 (Agentic) 벤치마크 또한 Claude Code 환경에서 K3를 실행했습니다.

0.8점의 차이가 어느 한쪽의 하네스 (Harness)가 더 우수하다는 것을 증명하지는 않습니다. 그것은 더 중대한 사실을 증명합니다. Moonshot은 하네스를 공개할 가치가 있는 평가 조건 (Evaluation condition)으로 취급한다는 점입니다.

모델과 하네스는 분리 가능한 계층이며, 하네스는 결과의 일부입니다.

이것은 해킹이 아니라 공식적으로 지원되는 사항입니다. Moonshot은 Claude Code 통합 가이드를 게시했습니다. 몇 가지 환경 변수 (Environment variables)를 설정하기만 하면 K3가 경쟁사의 셸 (Shell) 내부에서 실행됩니다. 한 제3자 통합 가이드는 전환 비용 (Switching cost)을 깔끔하게 포착했습니다: “모델을 바꾸는 것은 환경 변수 하나를 바꾸는 것이지만, 하네스를 바꾸는 것은 주말을 통째로 써야 하는 일이다.”

설정 (Configuration)은 빠르게 이전됩니다. 하지만 당신의 훅 (Hooks), MCP 서버, 저장소 지침 (Repository instructions), 안전 습관, 그리고 툴체인 (Toolchain)이 언제 실패하는지에 대해 축적된 감각은 쉽게 바뀌지 않습니다.

과업을 지탱하는 두 개의 기둥

이제 저는 에이전트 (Agent)를 동일한 하중을 지탱하는 두 개의 기둥으로 상상합니다.

첫 번째 기둥은 모델 (Model)입니다. 모델은 판단의 상한선을 설정합니다. 모델의 능력이 충분하지 않다면, 어떤 오케스트레이션 (Orchestration)도 이를 구원할 수 없습니다. 더 많은 도구는 단지 약한 판단력이 더 빨리 실패하게 만들 뿐입니다.

두 번째 기둥은 하네스 (Harness)입니다. 모델 주변에서 컨텍스트 (Context)를 선택하고, 도구를 노출하며, 권한을 강제하고, 메모리 (Memory)를 운반하며, 작업을 조정하고, 결과를 검증하는 시스템을 의미합니다.

과업 (Task)은 그 위에 쌓인 하중입니다.

질문에 답하거나 문단을 번역하는 것과 같은 가벼운 하중(load)의 경우에는 아주 얇은 하네스 기둥(harness pillar)이라도 견뎌냅니다. 이것이 채팅 시대에 하네스에 대한 논의가 거의 없었던 이유입니다. 하지만 저장소(repository), 긴 연구 작업, 또는 프로덕션 출시(production release)를 슬래브(slab) 위에 올려놓으면, 더 얇은 기둥이 가장 먼저 무너집니다.

얼마나 높이 쌓을 수 있는가는 더 두꺼운 기둥에 달려 있지 않습니다. 그것은 더 얇은 기둥에 달려 있습니다.

벤더(Vendors)들은 우리를 위해 모델 기둥을 계속 두껍게 만들고 있습니다. 위험한 부분은 하네스 기둥이 따라잡기도 전에 우리가 즉시 더 무거운 작업을 그 위에 올려놓는다는 점입니다.

수치는 모델의 이득보다 더 큽니다

백서(position paper)인 _Stop Comparing LLM Agents Without Disclosing the Harness_는 측정 문제(measurement problem)를 명확히 드러냅니다. 장기적 코딩 과업(long-horizon coding tasks)에서 공개 모니터링 결과에 따르면, 모델을 고정하고 하네스(harness)를 교체하는 것만으로도 SWE-bench Verified 성능이 무려 15%포인트까지 변동합니다. Verified Mini 서브셋(subset)에서는 단일 모델의 변동 폭이 48%포인트에 육박합니다.

동일한 논문은 연구 논문들이 흔히 2~4%포인트의 차이를 의미 있는 모델의 발전으로 제시한다는 점을 지적합니다.

이 비교에는 범위(scope)가 있습니다. 해당 증거는 코딩 에이전트(coding agents)와 그에 상응하는 프런티어 모델(frontier models)에서 도출된 것입니다. 이를 모든 도메인에 맹목적으로 이식해서는 안 됩니다. 그러나 그 범위 내에서 시사하는 바는 무시하기 어렵습니다. 즉, 하네스로 인해 발생하는 실현 격차(realization gap)는 우리가 출시 주간 내내 논쟁하는 모델 격차(model gap)보다 더 클 수 있다는 것입니다.

하네스의 6가지 역할

구성 요소 목록은 유용하지만, 어디에 먼저 투자해야 하는지는 알려주지 않습니다. 저는 하네스를 기능에 따라 다음과 같이 나눕니다:

1. 컨텍스트 엔지니어링 (Context engineering). 각 단계에서 유한한 윈도우(window) 안에 적절한 정보를 배치합니다. 검색 (Retrieval), 압축 (compression), 그리고 세션 내 레이어링 (in-session layering)은 프롬프트 장식 (prompt decoration)이 아니라 정보 아키텍처 (information architecture)입니다.
2. 도구 사용 및 안전성 (Tool use and safety). 모델이 행동하게 하되, 절대 건드려서는 안 되는 것에는 손대지 못하게 합니다. 샌드박스 (Sandboxes), 권한 계층 (permission tiers), 그리고 실패 시 차단되는 기본 설정 (fail-closed defaults)이 여기에 속합니다.
3. 인간 상호작용 (Human interaction). 조종 (Steering), 승인 (approvals), 중단 (interruption), 그리고 검토 (review). 사람은 루프 (loop) 자체가 되지 않으면서도 루프 안으로 들어올 수 있어야 합니다.
4. 메모리 (Memory). 출처 (provenance), 만료 (expiry), 그리고 이의를 제기할 권리와 함께 세션 및 태스크를 관통하는 지식입니다.
5. 멀티 에이전트 오케스트레이션 (Multi-agent orchestration). 분해 (Decompose), 파견 (dispatch), 병렬화 (parallelize), 검증 (verify), 그리고 수렴 (converge). 이는 모델의 단일 샷 판단 능력 (single-shot judgment ceiling)을 높이는 것이 아니라, 처리량 (throughput)과 신뢰성 (reliability)을 높입니다.
6. 수락 및 평가 루프 (Acceptance and the eval loop). 단일 결과물을 독립적으로 검증한 다음, 시스템이 단순히 실행된 것처럼 보였는지 여부가 아니라 실제로 도움이 되었는지를 측정합니다.

오늘날의 코딩 에이전트들은 처음 5가지 작업에 대해서는 서로 다른 강점을 가지고 있습니다. 공통된 약점은 여섯 번째 작업입니다.

모델이 "완료되었습니다"라고 말하면, 기본 전달 경로에는 실제 작업 공간을 읽고, 실제 체크를 다시 실행하며, 증거가 일치하지 않을 때 배포를 차단하는 독립적인 심판이 없는 경우가 많습니다. 사용량 대시보드 (Usage dashboards)는 활동량을 측정할 뿐, 결과가 올바랐는지에 대해서는 답하지 않습니다.

수락(Acceptance)은 실현이 현실이 되는 지점입니다

저의 멀티 에이전트 시스템에서 코디네이터 (coordinator)는 실행자 (executor)의 보고를 곧바로 결과물로 취급하지 않습니다. 태스크 접수 시점에 우리는 완료 정의 (Definition of Done)를 작성합니다. 전달 후, 코디네이터는 독립적으로 테스트를 다시 실행하고, 그 정의에 따라 결과를 확인하며, 변경 사항의 규모와 민감한 작업 신호 (sensitive-operation signals)를 검토한 뒤, 인간의 검토가 필요한지 결정합니다.

이것이 완벽한 시스템은 아닙니다. 테스트가 약화되었거나 완료 정의 (Definition of Done)가 잘못되었다면, 게이트는 여전히 잘못된 작업을 통과시킬 수 있습니다. 하지만 "가짜 완료 (fake done)"를 통과시키는 것은 실질적으로 훨씬 더 어려워졌습니다.

기계적인 절반—테스트를 재실행하고 고정된 기준을 비교하는 것—은 당신이 어떤 모델을 사용하는지 상관하지 않습니다. 판단의 절반—실패를 해석하고 리스크를 에스컬레이션(escalating)하는 것—은 검토자(reviewer)로 앉아 있는 모델에 달려 있습니다. 이 두 절반을 분리하는 것이 핵심입니다.

이 시리즈의 다음 기사는 그 수용(acceptance) 문제를 끝까지 추적합니다: 위조된 확인(forged confirmations), 잘못된 통과(falsely green) 테스트, 배포되었으나 한 번도 전원이 켜지지 않은 방어 체계, 그리고 제가 그 이후에 구축한 게이트(gate)까지 말입니다.

모델은 천장을 설정합니다. 하네스(harness)는 실현을 관리합니다.

모델의 발전은 타인에 의해 당신에게 주어집니다. 하네스의 신뢰성은 스스로 쟁취하는 것입니다.

원문은 OctoBlog에 게시되었습니다. Into the Harness 시리즈의 파트 1입니다.

당신에게 드리는 질문: 당신이 사용하는 에이전트에서 여섯 가지 하네스 역할 중 가장 취약한 기둥(thinnest pillar)은 무엇입니까?