2026년 6월, Peter Steinberger는 보고하기를 자신의 시스템이 30일 동안 1,305,088.81달러를 지출했으며, 3명의 팀원이 운영하는 약 100개의 Codex 인스턴스 전반에 걸쳐 6030억 개 이상의 토큰(tokens)을 처리했다고 밝혔습니다. 이는 벤치마크도, 주말 실험도 아니었습니다. 에이전트가 가질 수 있는 모든 약점을 드러낼 만큼 충분히 큰 실제 프로덕션 워크로드(production workload)였습니다.

대부분의 반응은 즉시 당연한 질문으로 향했습니다: 어떤 모델이 이를 구동했는가? 시작하기에 적절한 질문입니다. 더 나은 모델은 더 깨끗한 코드를 작성하고, 지시 사항을 더 신뢰성 있게 따르며, 작업이 잘못되었을 때 더 잘 복구합니다. 만약 코딩 에이전트(coding agents)를 구축하고 있다면, 사용 가능한 가장 강력한 모델을 선택하는 것이 가장 중요한 결정처럼 느껴질 것입니다.

하지만 100개의 Codex 인스턴스에 걸쳐 130만 달러를 사용했다면, 더 흥미로운 질문이 있습니다.

하네스(harness)는 무엇이었을까요?

모델 주변의 시스템이 장기 실행되는 작업을 어떻게 궤도에 유지시키는지 설명해 주는 질문임에도 불구하고, 거의 아무도 이를 묻지 않았습니다. 또한 이것은 수백 개의 병렬 에이전트(parallel agents)를 동시에 지원하고, 수천 번의 도구 호출(tool calls)과 결정 이후에도 유용한 결과물을 계속해서 만들어내는 역할을 합니다. 이 중 그 어느 것도 모델 단독의 속성이 아닙니다. 그것은 프로덕션 하네스(production harness)의 역할이며, 이를 잘 구축하는 규율에는 이제 이름이 생겼습니다: 에이전트 하네스 엔지니어링 (agent harness engineering).

Frontier models는 자율적인 문제 해결 (autonomous problem solving)의 가능성을 계속해서 확장하고 있으며, 그 진보는 실재합니다. 하지만 프로덕션 시스템 (production systems)은 벤치마크가 거의 포착하지 못하는 이유들로 인해 실패합니다. 에이전트가 긴 호흡 (long horizons)으로 실행되며, 도구 (tools)를 호출하고, 다른 에이전트들과 협업하게 되면, 모델 선택 (model selection)은 더 이상 의사결정의 전부가 아닙니다. 그것은 더 큰 시스템의 한 부분이 되며, 이 시점부터의 모든 것은 당신이 일회성 에이전트 작업 (one-off agent task)을 실행하는 것이 아니라, 프로덕션 에이전트 시스템 (production agentic system)을 구축하고 있다고 가정합니다.

요약 (TL;DR)

• AI 에이전트의 출시 여부를 결정하는 것은 모델의 선택이 아니라, 그 주변의 하네스 (harness)입니다.

• 올해 발표된 두 연구는 서로 경쟁하는 주장이 아니라 서로 다른 제약 조건들을 측정하며, 이 둘을 종합하면 하네스의 품질이 모델과 독립적으로 출력을 변화시킨다는 것을 보여줍니다.

• 안정적으로 제품을 출시하는 팀들은 동일한 패턴으로 수렴합니다: 상태 (state)는 모델 외부에 존재하며, 검증 (verification)은 생성 (generation)과 분리되어 있고, 컨텍스트 (context)는 첫 번째 프롬프트 (prompt)가 입력되기 전에 로드됩니다.

• 진짜 질문은 어떤 모델을 사용할 것인가가 아닙니다. 그 주변의 하네스가 충분한 역할을 수행하고 있는가입니다.

모델이 할 수 없는 AI 에이전트 하네스의 역할

모델은 추론 (reasoning)을 담당하지만, 프로덕션 AI 에이전트 하네스는 다른 직무를 가집니다. 하네스는 모델의 추론을 신뢰할 수 있는 실행 (execution)으로 전환하는 데 필요한 작업을 조정하는 모델 주변의 런타임 (runtime)입니다. 시스템에 따라 여기에는 지시 사항과 컨텍스트 (context)의 조립, 도구 (tool) 액세스 및 실행 관리, 지속적인 상태 (persistent state) 유지, 그리고 모델 라우팅 (model routing), 검증 (verification), 관찰 가능성 (observability)과 같은 기능과의 통합이 포함됩니다. 이러한 책임들은 추론 작업이 아니라 시스템 엔지니어링 (systems engineering)의 관심사이기 때문에 모델 외부에 존재합니다.

이러한 관점으로 바라보면 모델 주변의 시스템이 왜 계속해서 커지는지를 설명할 수 있습니다. 팀들은 프레임워크가 권장한다는 이유만으로 더 나은 컨텍스트 관리 (context management), 샌드박스 (sandbox), 더 풍부한 관찰 가능성 (observability) 또는 더 강력한 가드레일 (guardrails)을 추가하는 경우가 드뭅니다. 이러한 기능들은 대개 동일한 운영 이슈가 반복적으로 발생한 후에야 등장하며, 엔지니어가 수동으로 수행해야 할 작업이 아닌 영구적인 해결책으로 자리 잡게 됩니다.

모든 하네스 (harness) 구성 요소는 무언가가 먼저 실패했기 때문에 존재합니다

이 중 그 어느 것도 한 번에 하나의 조각으로 구축되지 않았습니다. 이는 운영 시스템을 계층으로 분리하는 것이 애플리케이션 코드에서 작동하는 방식과 동일합니다. 각 구성 요소는 하나의 작업만을 담당하므로, 한 곳에서의 실패가 하류 (downstream)의 모든 것을 함께 무너뜨리지 않습니다. 시스템 프롬프트 (system prompt)가 실패한다고 해서 샌드박스가 손상되지 않습니다. 샌드박스 침해 (sandbox breach)가 발생한다고 해서 관찰 가능성 (observability) 로그가 삭제되지 않습니다. 이러한 분리가 핵심이며, 이것이 하네스 설계자들이 어떤 모델이나 프레임워크를 사용하든 상관없이 유사한 아키텍처로 수렴하는 이유입니다.

이런 방식으로 생각하면 대화의 주제가 기능 (features)에서 하네스 수준의 실패 모드 (failure modes)로 전환됩니다. 특정 구성 요소가 무엇을 하는지 묻는 대신, 그것이 없을 때 무엇이 고장 나는지를 물으십시오. 이것이 에이전트 시스템을 감사 (audit)하는 가장 빠른 방법입니다. 누락된 모든 계층은 식별 가능한 패턴을 남기기 때문입니다.

한번 찾아보기 시작하면 그 패턴은 결코 미묘하지 않습니다. 컨텍스트 부패 (Context rot)는 프롬프트 엔지니어링 (Prompt engineering)의 문제가 아니라 컨텍스트 관리 (Context management)의 문제입니다. 또한 장기 실행 (Long-horizon execution) 실패는 모델의 추론 능력이 갑자기 저하되어 발생하는 것이 아닙니다. 그것은 에이전트를 둘러싼 컨텍스트가 시간이 지남에 따라 자율적인 작업을 지속할 수 있도록 설계되지 않았기 때문에 발생합니다. 에이전트가 잘못된 도구를 반복적으로 호출하거나, 중간 작업 내용을 분실하거나, 무언가 고장 난 후 디버깅이 불가능해지는 경우에도 동일한 논리가 적용됩니다. 이것들은 하네스 솔루션 (Harness solutions)이 필요한 하네스 문제 (Harness problems)입니다.

그러한 관점으로 에이전트를 바라보기 시작하면 질문이 바뀝니다. 다른 모델을 사용했다면 더 잘 수행했을지 묻는 대신, 시스템의 어느 부분이 애초에 실패를 허용했는지를 묻기 시작합니다. 이것이 더 유용한 질문입니다. 왜냐하면 누락된 모든 구성 요소는 구체적이고 문서화 가능한 실패 모드 (Failure mode)를 남기기 때문입니다.

모델 우선론 진영이 설명해야 할 증거들

더 나은 모델이 에이전트의 성능을 높이는 이유라고 가정한다면, 모델을 개선하는 것만으로도 프로덕션에서 보이는 성능 향상의 대부분을 설명할 수 있어야 합니다. 이는 합리적인 가정입니다. 하지만 올해 발표된 가장 흥미로운 두 가지 증거와는 조화시키기 어렵습니다.

METR가 측정하는 한계치 (Ceiling)

Model Evaluation and Threat Research (METR)의 코딩 에이전트 평가부터 시작하겠습니다. Claude Code는 단순한 Reason-Act (ReAct) 루프보다 50.7% 더 높은 성능을 보였습니다. 이 결과는 주목할 가치가 있는데, 단순히 개별 모델(raw models)만을 비교한 것이 아니라, 동일한 소프트웨어 엔지니어링 작업을 수행하는 완전한 에이전트 시스템(agent systems)을 평가했기 때문입니다. 동일한 연구에 따르면 Codex는 METR가 사용하는 또 다른 범용 스캐폴드(scaffold)인 Triframe보다 성능이 떨어져, 단 14.5%의 승률만을 기록했습니다. 만약 특정 목적을 위해 구축한 하네스(harness)가 범용 하네스에게 패배한다면, 그것은 모델의 문제가 아닙니다. 그것은 하네스 설계(harness-design)의 문제이며, 모델을 감싸고 있는 시스템이 도움을 주는 만큼이나 쉽게 해를 끼칠 수 있다는 것을 보여주는 가장 명확한 증거 중 하나입니다.

METR의 연구는 여러분이 결국 마주하게 될 제약 사항도 식별합니다. 작업이 길어지고 더 지속적인 추론(reasoning)을 요구할수록, 오늘날의 코딩 에이전트들은 신뢰성이 떨어집니다. 이들은 일관성(coherence)을 잃고, 실수로부터 효과적으로 회복하지 못하며, 결국 실행 기간이 길어지는 작업을 완료하는 데 어려움을 겪습니다. 여러분이 구축하는 모든 에이전트는 작업 지속 시간이 길어짐에 따라 신뢰성이 감소하기 시작하는 실질적 시간 지평 (practical time horizon)에 결국 도달하게 됩니다.

Anthropic은 한계치(ceiling) 내에서의 품질을 측정합니다

Anthropic의 엔지니어링 사후 분석 (engineering postmortem)은 앞서 언급한 한계치(ceiling)와는 분리하여 살펴볼 가치가 있는 다른 변수를 조사합니다. 이 연구는 기반이 되는 모델은 동일하게 유지하면서 프로덕션 하네스(production harness)가 변경될 때 어떤 변화가 일어나는지를 묻습니다.

이 조사는 사용자들이 Claude Code의 코딩 품질이 눈에 띄게 저하되었다고 보고하면서 시작되었습니다. Anthropic은 이러한 성능 퇴보(regressions)의 원인이 모델 자체 외부의 세 가지 변화에 있음을 추적했습니다: 지연 시간(latency)을 줄이기 위해 기본 추론 노력(reasoning effort)을 낮춘 것, 유휴 세션 이후 이전 추론 내용을 반복적으로 폐기하는 컨텍스트 관리(context-management) 캐싱 버그, 그리고 장황함을 줄이기 위해 의도되었으나 예상치 못하게 코딩 품질을 저하시킨 시스템 프롬프트(system prompt) 변경입니다. 조사 과정 내내 기반이 되는 모델은 결코 변경되지 않았습니다.

두 가지 제약 조건, 하나의 프로덕션 시스템

언뜻 보기에 두 연구는 서로 다른 방향을 가리키는 것처럼 보입니다. 프로덕션 하네스(production harness)를 개선하면 더 나은 결과로 이어진다고 가정한다면, 왜 더 긴 작업이 여전히 에이전트의 실패를 유발하는지 의문이 생길 수 있습니다. 반대로 오늘날의 모델이 실질적인 시간 지평(time-horizon)의 한계를 가지고 있다는 점을 받아들인다면, 모델을 변경하지 않고 하네스를 변경하는 것이 어떻게 성능을 눈에 띄게 개선하거나 저하시킬 수 있는지 의문이 생길 수 있습니다.

정답은 두 연구가 서로 다른 것을 측정하고 있다는 것입니다. METR는 코딩 에이전트가 작업이 길어지고 더 까다로워짐에 따라 얼마나 신뢰성 있게 작업을 완료하는지를 살펴봅니다. Anthropic은 모델이 동일하게 유지되는 동안 하네스의 변화가 출력 품질에 어떤 영향을 미치는지 살펴봅니다. 이들은 서로 다른 질문에 답하고 있으며, 이것이 바로 그 결과들이 서로 모순되는 것이 아니라 상호 보완적인 이유입니다.

output quality on one axis, task duration ceiling on the other, a point showing they're set independently.

나란히 비교해 보면 그 차이를 더 쉽게 확인할 수 있습니다.

이러한 결과들을 함께 읽어보면 직교하는 제약 조건 (orthogonal constraints)을 설명한다는 것을 알 수 있습니다. 만약 여러분이 실제 프로덕션의 병목 현상 (bottleneck)이 어디에 있는지 찾으려 한다면, 이것이 중요한 이유입니다. 하나는 장기적 실행 (long-horizon execution)의 한계를 측정하고, 다른 하나는 그 한계 내에서의 실행 품질을 측정합니다.

Anthropic의 사후 분석 (postmortem)은 조사 과정 내내 기반 모델 (underlying model)이 동일하게 유지되었기 때문에 이 주장을 뒷받침합니다. 따라서 모델은 일정하게 유지되는데 프로덕션 하네스 (production harness)가 변경될 때, 프로덕션 성능이 모델의 능력에 의해서만 결정된다고 주장하기는 어렵습니다.

여기서 얻을 수 있는 교훈은 모델이 더 이상 중요하지 않다는 것이 아닙니다. 더 나은 모델은 에이전트가 시도할 수 있는 범위를 확장할 수 있습니다. 더 나은 프로덕션 하네스 (production harness)는 그러한 능력들이 얼마나 신뢰성 있게 프로덕션 결과물로 이어질지를 결정합니다. 오늘날의 모델들은 여전히 컨텍스트 손실 (context loss), 실행 드리프트 (execution drift), 그리고 장기 실행 조정 실패 (long-running coordination failures) 문제를 겪고 있으며, 이는 오직 주변 시스템 (surrounding system)만이 해결할 수 있습니다.

프로덕션에 배포하는 팀들이 실제로 구축한 것

이러한 결과들은 동일한 결론을 가리킵니다. 만약 신뢰성이 모델 외부에서 깨진다면, 하네스 (harness)가 해결책을 책임져야 합니다. 에이전트를 프로덕션에 배포하고 있는 상황이라면, 단순히 모델을 교체하는 것만으로는 신뢰성 문제를 해결할 수 없습니다. 대신 중요한 책임들을 모델에서 하네스 (harness)로 옮겨야 합니다. 모델은 다음 행동을 생성하는 데 능숙하지만, 프로덕션 팀은 모델이 장기적인 작업 전반에 걸쳐 상태 (state)를 유지하거나, 자신의 출력을 검증하거나, 변경을 시작하기 전에 익숙하지 않은 코드베이스를 재구성하는 것에 의존하지 않습니다. 이러한 책임들은 대신 주변 시스템 (surrounding system)으로 이동합니다.

상태 (State)는 모델 외부에 존재한다

모델에게 모든 것을 기억하라고 요구하지 마세요. 작업 상태 (task state), 중간 결과 (intermediate results), 실행 이력 (execution history) 및 아티팩트 (artifacts)를 독립적으로 저장하세요. 그렇게 하면 에이전트가 중단되거나, 재시도하거나, 다른 에이전트에게 작업을 넘길 때도 작업이 계속될 수 있습니다. 이는 협업을 실용적으로 만들어 주기도 합니다. 에이전트 간에 계속해서 커지는 컨텍스트 윈도우 (context window)를 전달하는 대신, 각 에이전트가 현재 상태를 읽고, 자신의 작업을 기여하며, 결과를 다시 기록하는 방식입니다.

피드백 루프 (Feedback loops)는 생성 (generation)과 분리되어 있다