모델을 바꾸지 않았습니다. 하네스만 교체했더니 성능이 평균 52.25% 올랐습니다. 최대 수치는 82.86%였습니다.

논문 제목은 Harness-of-Harness(arXiv 2609.01481, 2026-09-01 제출). 연구자들이 한 것은 단 하나입니다. 기존 코딩 에이전트 하네스 위에 planning → coding → testing을 순환하는 상위 루프를 얹었습니다. 모델은 손대지 않았습니다. 그리고 Codex+GPT-5.5, OpenCode+DeepSeek-V4-Pro, Pi+MiniMax-M3 — 세 가지 조합 전부에서, 상위 루프가 단독 하네스를 일관되게 상회했습니다. 70회 이상 반복 배포로 FPS 게임 한 편을 사람 개입 없이 완성했습니다.

이 수치가 가리키는 방향은 하나입니다. 지금 많은 팀이 모델 선택에 쓰는 에너지를 실행 흐름 설계에 먼저 쓴다면, 더 빠르게 더 큰 차이를 만들 수 있다는 것입니다.

그런데 같은 시기에 다른 신호도 왔습니다.

하네스를 컨텍스트·검증·관측성·비용·장시간 실행 5개 축으로 분해하고 각각을 최적화하기 시작한 팀들에게서, “병목은 하네스가 아니라 도입 전 업무 설계”라는 반대 근거가 4개 채널에서 동시에 올라왔습니다. 요점은 이렇습니다. 잘못 정의된 업무를 완벽하게 실행하는 에이전트는 +52%가 아니라 +0%를 만듭니다.

OpenAI 내부에서도 같은 맥락의 기록이 있습니다. Simon Willison이 2026년 9월 공개한 수치에 따르면, OpenAI 연구자들의 코딩 에이전트 일일 지출이 6월 $80160에서 8월 말 약 $600으로 약 47.5배 올랐습니다. 하네스를 잘 갖춰도 어떤 업무에 에이전트를 붙이는지를 잘못 고르면, 비용만 올라갑니다.

PM이 이 논문을 읽을 때 유용한 질문 구조는 두 층입니다.

첫 번째 층 — 지금 에이전트에게 맡기는 업무가 맞는가. 사람이 해야 할 판단을 에이전트에게 위임하고 있지는 않은가. 이 질문은 하네스 설계보다 앞에 놓여야 합니다.

두 번째 층 — 그 업무가 적합하다고 확인됐을 때, 실행 흐름을 어떻게 설계하는가. 여기서 52%가 나옵니다. planning → coding → testing의 루프를 단계로 쪼개는 것, 각 단계의 아웃풋이 다음 단계의 인풋이 되도록 핸드오프를 설계하는 것, 이터레이션이 모델 토큰을 낭비하지 않도록 컨텍스트를 다듬는 것. 모델 교체 여부는 이 설계가 끝난 다음 이야기입니다.

하네스가 상품이 되기 시작했습니다.

OpenAI는 Agents API를 정식 상용 출시했습니다. Anthropic은 Claude Code 환경을 직접 상품화하고 있습니다. 벤더들이 하네스를 팔기 시작했다는 것은 명확한 신호입니다. 하네스 설계 역량이 이제 시장에서 거래 가능한 가치가 됐다는 것입니다.

52.25%는 모델 스펙 시트에 없는 숫자입니다. 실행 구조 설계에서 나옵니다.

지금 여러분 팀의 에이전트 성능을 제한하고 있는 층은 어디입니까 — 업무 정의, 실행 흐름, 아니면 모델 선택입니까?