OpenAI Anthropic 하네스 논쟁: 더 강력한 모델, 상반된 엔지니어링 선택

OpenAI 엔지니어들이 Anthropic과의 중요한 논쟁을 다시 불러왔다. 더 강력한 AI 모델에는 더 가벼운 하네스가 필요해야 하지만, 까다로운 작업일수록 더 강한 감독이 여전히 효과적이라는 주장이다.

이 OpenAI Anthropic 하네스 논쟁은 단순히 프롬프트나 인터페이스 선호도에 관한 이야기가 아니다. 도구, 메모리, 권한, 계획, 평가, 인간 승인 등을 포함해 모델을 둘러싼 소프트웨어에 관한 문제다.

OpenAI는 과도한 보조 구조가 차세대 모델에는 더 이상 없는 한계를 코드화할 수 있다고 주장한다. Anthropic의 최근 실험은 보다 조건부적인 결론에 도달했다. 더 나은 모델은 일부 오케스트레이션의 필요성을 줄였지만, 작업이 모델의 한계에 가까워질 때는 플래너와 독립 평가자가 여전히 유용했다.

이견의 영향은 Codex와 Claude Code를 넘어선다. 기업들은 범용 모델을 리포지토리 편집, 브라우저 조작, 문서 분석, 장기 프로젝트 조율을 수행하는 에이전트로 전환하고 있다. 제어 장치를 하나 더 추가할 때마다 신뢰성은 높아질 수 있지만, 지연 시간과 복잡성도 늘어나며 시간이 지나면 낡을 수 있는 또 하나의 가정도 더해진다.

따라서 핵심 질문은 하네스가 중요한지 여부가 아니다. 양사의 엔지니어링 작업은 그것이 중요하다는 점을 보여준다. 문제는 발전이 가치를 모델 내부로 옮기는지, 하네스 쪽으로 옮기는지, 혹은 두 계층 사이를 반복적으로 오가는지에 있다.

OpenAI와 Anthropic이 실제로 바꾼 것

두 회사 모두 이제 에이전트 하네스를 제품을 규정하는 계층으로 본다. 다만 그 계층에 어느 정도의 지능을 담아야 하는지에는 의견이 다르다.

에이전트 하네스는 모델을 도구, 컨텍스트, 메모리, 피드백 루프, 사용자 제어와 연결하는 런타임이다. 모델은 결정을 생성한다. 하네스는 모델이 어떤 정보를 보고, 어떤 행동을 취할 수 있으며, 오류가 어떻게 포착되는지를 결정한다.

OpenAI의 입장은 소프트웨어 개발을 넘어 에이전트를 확장하려는 노력에 관한 8월 보도에서 뚜렷하게 드러났다. OpenAI 엔지니어들은 좋은 하네스 엔지니어링이란 모델을 불필요한 규칙으로 둘러싸지 않으면서, 필요한 정확한 도구와 정보를 제공하는 것이라고 설명했다.

엔지니어 Nick Gershenson은 TechCrunch에 조건부 로직과 도구를 복잡하게 조합하면 단기적 성과를 낼 수 있다고 말했다. 그러나 그는 새 모델이 몇 달 안에 그런 추가 요소를 쓸모없게 만들 수 있다고 주장했다. 그가 선호하는 방향은 유능한 모델이 문제의 더 많은 부분을 스스로 해결하도록 하는 절제된 인터페이스다.

이 원칙은 쓴 교훈, 즉 광범위한 인간 지식을 중심으로 구축된 시스템보다 일반 연산이 더 뛰어날 수 있다는 Rich Sutton의 영향력 있는 주장과 맞닿아 있다. 에이전트에 적용하면, 이 교훈은 예상되는 모든 실패를 위해 사람이 설계한 워크플로보다 폭넓은 역량을 갖춘 모델을 선호한다.

OpenAI가 하네스 엔지니어링을 포기한 것은 아니다. 자체 Codex 엔지니어링 설명은 리포지토리, 문서화, 테스트, 피드백 루프, 기계가 읽을 수 있는 계획을 필수 인프라로 제시한다. 회사는 한 내부 프로젝트에서 엔지니어 1인당 하루 평균 3.5개의 pull request를 처리했다고 보고했다.

차이는 OpenAI가 복잡성이 존재하기를 원하는 위치에 있다. OpenAI 엔지니어들은 모델이 어떻게 추론해야 하는지를 지시하는 점점 더 복잡한 분기 대신, 이해하기 쉬운 환경과 명확한 피드백을 선호한다.

Anthropic의 3월 24일 연구는 다른 방식의 스트레스 테스트를 제시했다. 연구원 Prithvi Rajasekaran은 플래너, 생성기, 평가자를 활용해 장시간의 자율 세션에 걸쳐 완전한 애플리케이션을 구축했다.

플래너는 짧은 요청을 구조화된 사양으로 변환했다. 생성기는 그 계획을 구현했다. 평가자는 애플리케이션을 실행하고, 합의된 기준을 점검한 뒤, 수정할 결함을 반환했다.

Anthropic의 초기 비교에서는 단일 에이전트 실행이 핵심 게임플레이 기능이 작동하지 않는 애플리케이션을 만들었다. 다중 에이전트 하네스는 결함이 남아 있었지만 더 폭넓고 작동하는 결과를 제공했다.

이는 무거운 하네스가 항상 이긴다는 증거는 아니었다. Anthropic은 Claude Opus 4.6이 장기 작업을 더 일관되게 처리하자 이후 스프린트 수준의 분해를 제거했다. 그러나 플래너와 평가자는 여전히 빠졌거나 피상적인 기능을 찾아냈다.

따라서 이 사례는 수렴과 이견을 동시에 보여준다. OpenAI와 Anthropic 모두 모델이 기존 책임을 흡수하면 하네스를 단순화한다. 차이는 개발자가 그 이전을 얼마나 빠르게 신뢰해야 하는지에 있다.

지금 OpenAI Anthropic 하네스 논쟁이 중요한 이유

에이전트가 범위가 제한된 코딩 작업을 넘어, 성공을 정의하기 어렵고 실패를 되돌리기 어려운 업무로 이동하면서 압력이 커지고 있다.

코딩은 에이전트에 처음으로 유리한 환경을 제공했다. 리포지토리에는 구조화된 파일이 있고, 컴파일러는 오류를 드러내며, 테스트는 종종 명확한 통과 또는 실패 신호를 만든다. 하네스는 이러한 신호를 모델의 다음 시도로 전환할 수 있다.

일반적인 지식 업무에는 신뢰할 만한 검증 수단이 더 적다. 전략 메모는 취약한 가정에 기반하면서도 일관성 있어 보일 수 있다. 스프레드시트는 계산은 정확하지만 잘못된 비즈니스 질문에 답할 수 있다. 에이전트는 근거가 오래되었다는 사실을 알아차리지 못한 채 완성도 높은 프레젠테이션을 끝낼 수 있다.

OpenAI는 이러한 덜 구조화된 환경으로 에이전트 접근법을 확장하고 있다. 이 움직임은 더 강력한 모델과 연관된 단순성을 유지하면서도 일반 사용자가 요구하는 제어 장치를 추가해야 한다는 압박을 회사에 가한다.

Anthropic은 반대 방향의 압박에 직면해 있다. Claude Code는 가시적인 진행 상황, 빈번한 상호작용, 사용자 참여를 중심으로 큰 매력을 구축했다. 이 접근법은 더 안전하게 느껴질 수 있지만, 반복되는 질문과 승인은 운영자의 업무량을 늘린다.

이 경쟁은 두 가지 제품 본능을 반영한다. OpenAI는 종종 목표를 부여하고 완성된 결과를 받는 경험을 추구해 왔다. Anthropic은 일반적으로 계획, 대안, 권한 요청을 통해 중간 추론 과정을 더 많이 드러냈다.

어느 본능도 보편적으로 더 낫지는 않다. 목표가 명확하고 검증 비용이 낮을 때는 자율성이 매력적이다. 선호가 명시되지 않았거나 결과를 측정하기 어려울 때는 협업이 가치 있다.

이것이 인터페이스가 동일한 모델의 체감 품질을 바꿀 수 있는 이유다. 하네스는 컨텍스트 선택, 도구 설명, 재시도 동작, 파일 접근, 사용자 개입 시점을 제어한다. 이러한 결정은 모델이 취하는 모든 행동을 형성한다.

독립적인 프레임워크 개발자들도 같은 의존성을 관찰했다. LangChain은 모델별 하네스 프로필이 기본 구성과 비교해 tau2-bench의 일부 하위 집합에서 10~20포인트의 개선을 보였다고 보고했다. 하네스 프로필은 모델별 행동에 맞춰 프롬프트, 도구, 미들웨어를 조정한다.

이 결과는 OpenAI 주장의 단순한 버전에 이의를 제기한다. 하네스가 일시적인 보조 장치에 불과하다면, 기반 모델이 고정된 상태에서 하네스를 바꾼다고 큰 성능 차이가 생겨서는 안 된다.

그러나 이는 불필요한 추상화에 대한 OpenAI의 불만도 뒷받침한다. LangChain은 모든 모델을 개선하는 하나의 점점 더 복잡한 아키텍처를 찾지 못했다. 대신 서로 다른 모델이 서로 다른 구성에 반응한다는 사실을 발견했다.

실질적인 압력은 제품 팀에 가해진다. 이들은 한 제공업체에 맞춰 긴밀하게 최적화할지, 여러 모델 전반에서 이식 가능한 계층을 유지할지 결정해야 한다.

밀접한 최적화는 더 나은 즉각적 결과를 제공할 수 있다. 그러나 제공업체별 도구, 프롬프트, 컨텍스트 동작에 대한 의존성을 만들 수도 있다. 이식성은 그러한 의존성을 제한하지만, 범용 하네스는 모델 역량을 충분히 활용하지 못할 수 있다.

에이전트가 더 넓은 권한을 받으면서 이러한 선택은 더욱 중요해진다. 패치를 제안하는 코딩 도우미의 역할은 제한적이다. 커뮤니케이션을 읽고, 공유 문서를 편집하고, 비즈니스 시스템을 작동시키는 에이전트는 여러 신뢰 경계를 넘는다.

따라서 이들 제품을 평가하는 팀은 모델 벤치마크를 넘어 살펴봐야 한다. 현실적인 권한, 데이터, 실패 조건에서 완전한 모델과 하네스의 조합에 관한 증거가 필요하다.

OpenAI는 모델이 주도하기를 원한다

OpenAI의 가벼운 하네스 주장은 개발자가 환경을 명확하게 드러낸 뒤, 대부분의 적응적 행동은 모델이 수행하도록 해야 한다는 것이다.

이 입장이 테스트, 권한, 컨텍스트 관리를 제거한다는 뜻은 아니다. 사라질 것으로 예상되는 한계를 보완하기 위한 수작업 추론 절차에 저항한다는 의미다.

첫 Codex 웹 애플리케이션에 대한 OpenAI의 경험은 이러한 확신을 설명하는 데 도움이 된다. 회사는 처음에 최소한의 사용자 개입으로 모델이 작업을 완료할 수 있다는 데 베팅했다. Anthropic의 더 상호작용적인 Claude Code 접근법은 당시 모델이 안정적으로 수행할 수 있는 범위에 더 잘 부합했다.

OpenAI는 이후 사용자가 Codex를 안내할 수 있는 기회를 더 많이 추가했다. 한 엔지니어는 이전 제품이 모델과 하네스가 지원할 수 있는 수준보다 앞서 있었다고 인정했다.

이 이력은 양쪽 모두의 위험을 보여주기 때문에 중요하다. 하네스에는 지나치게 많은 경직된 로직이 들어갈 수 있다. 반대로 사용자가 실제로 받는 것보다 더 높은 모델 역량을 전제할 수도 있다.

OpenAI의 현재 접근법은 더 명확한 환경과 강한 피드백을 통해 또 다른 불일치를 피하려 한다. 회사의 내부 엔지니어링 설명은 구조화된 문서화, 리포지토리 규칙, 계획, 자동화된 검사를 강조한다.

이 요소들은 모든 추론 단계를 규정하는 워크플로보다 가볍다. 그러나 여전히 상당한 엔지니어링을 의미한다. 하네스는 판단을 위임하는 동시에 성공을 더 쉽게 점검할 수 있게 한다.

이 접근법은 OpenAI의 제품 목표에도 부합한다. 범용 업무용 에이전트는 사용자가 요청할 수 있는 모든 순서를 디자이너가 예측하는 방식에 의존할 수 없다. 가능한 작업의 범위가 너무 넓기 때문이다.

모델 주도 시스템은 조건이 변하면 도구를 선택하고 계획을 수정할 수 있다. 사용자가 하나의 과제 안에서 리서치, 스프레드시트, 메시지, 코드, 프레젠테이션으로 이동할 때 이러한 유연성은 매력적이다.

그러나 최소한의 하네스는 더 많은 책임을 모델로 옮긴다. 모델은 모호함을 감지하고, 누락된 정보를 요청하며, 어떤 행동에 확인이 필요한지 판단해야 한다.

이러한 행동은 일반 역량만으로 보장되지 않는다. 모델은 지시 실행 능력이 향상되면서도 결함 있는 목표를 감지하는 능력이 똑같이 향상되지 않을 수 있다.

사용자 경험은 그 위험을 더한다. 업무용 AI를 연구하는 Wharton 교수 Ethan Mollick은 즉시 작업 완료를 시도하는 시스템과 비교를 보여주고 피드백을 요청하는 시스템을 대조해 왔다.

더 자율적인 설계는 에이전트가 목표를 정확히 해석할 때 마찰을 줄인다. 그렇지 않을 경우 사용자는 일관성은 있지만 방향이 빗나간 긴 작업 연쇄가 끝난 뒤에야 오류를 발견할 수 있다.

이 때문에 컨텍스트 품질이 핵심이 된다. 가벼운 하네스는 간결하고 관련성이 높으며 최신인 정보를 제공할 때 가장 잘 작동한다. 모델이 긴 컨텍스트 윈도우를 지원하더라도, 대량의 필터링되지 않은 컨텍스트는 우선순위를 묻어버릴 수 있다.

지식 근로자에게 이러한 근거를 정리하는 일은 별도의 엔지니어링 과제로 남아 있다. 검색 가능한 지식 베이스는 에이전트가 행동하기 전에 검색 노이즈를 줄일 수 있다.

OpenAI의 주장은 기계 피드백이 밀도 높은 작업에서 가장 강력하다. 컴파일러, 테스트 스위트, 린터, 브라우저 검사는 지속적인 인간 판단 없이도 에이전트가 진행 상황을 평가하도록 돕는다.

완료가 취향, 조직의 역사, 또는 기록되지 않은 기대에 좌우될수록 그 성능은 약해진다. 모델은 자신의 컨텍스트에 한 번도 들어오지 않은 증거를 추론할 수 없다.

따라서 OpenAI는 계산된 베팅을 하고 있다. 모델이 개선될수록 더 많은 계획과 복구를 내부적으로 처리하게 될 것이다. 하니스 설계자들은 어제의 모델 한계를 내일의 제품에 고정하기보다 범용성을 보존해야 한다.

Anthropic은 더 어려운 작업에는 여전히 더 많은 구조가 필요하다고 말한다

Anthropic의 더 무거운 하니스 증거는 강력한 모델이 오케스트레이션을 없애는 것이 아니라, 그것이 유용한 경계를 더 어려운 작업으로 옮긴다는 점을 보여준다.

Anthropic의 장기 실행 하니스는 반복적으로 나타나는 두 가지 약점에서 출발했다. 모델은 장시간 작업 중 일관성을 잃었고, 자신의 결과물을 지나치게 관대하게 평가했다.

첫 번째 문제는 컨텍스트였다. 긴 작업에는 의사결정, 도구 결과, 오류, 부분 구현이 쌓인다. 컨텍스트 윈도우가 그 자료를 담을 수 있더라도, 그 자료가 어떻게 구성되는지는 모델이 무엇을 인지하는지에 영향을 미친다.

Anthropic은 구조화된 인계 파일과 함께 컨텍스트 재설정을 사용했다. 재설정은 핵심 진행 상황과 다음 단계를 보존하면서 새 에이전트 세션에 깔끔한 작업 상태를 제공했다.

두 번째 문제는 자기 평가였다. 애플리케이션을 만든 동일한 모델은 결과가 약해도 이를 받아들이는 경우가 많았으며, 특히 품질이 디자인 판단에 좌우될 때 그 경향이 두드러졌다.

Anthropic은 생성과 검토를 분리했다. 평가자는 명시적인 기준과 브라우저 자동화를 사용해 기능을 테스트했다. 생성자는 구체적인 발견 사항을 전달받아 수정을 시도했다.

첫 번째 완전한 하니스는 한 문장짜리 게임 요청을 열 번의 스프린트에 걸친 16개 기능으로 확장했다. 평가자는 각 스프린트에 세부 계약을 적용했으며, 한 레벨 에디터 단계에는 27개의 기준이 포함됐다.

Anthropic은 다중 에이전트 결과가 단일 에이전트 시도에는 없던 작동하는 핵심 기능을 제공했다고 보고했다. 다만 훨씬 더 많은 실행 시간, 오케스트레이션, 모델 사용량이 필요했다.

이러한 트레이드오프는 이 실험을 단순한 벤치마크 승리보다 더 유용하게 만든다. 추가 구조가 무엇을 제공할 수 있는지 보여주는 한편, 팀이 평가자를 무분별하게 추가할 수 없는 이유도 드러낸다.

Anthropic은 이후 더 강력한 모델로 이 과정을 반복했다. Opus 4.6은 이전의 스프린트 분해 없이도 두 시간 넘게 주요 빌드를 유지했다.

이는 OpenAI의 핵심 관찰을 뒷받침했다. 이전에는 하니스가 제공하던 역량이 모델 내부로 옮겨가면서, 일부 스캐폴딩이 불필요해졌다.

평가자는 여전히 중대한 공백을 발견했다. 핵심 오디오 기능이 얕은 인터페이스 요소나 플레이스홀더로만 존재한다는 점을 식별했다. 생성자는 이후 그러한 누락 중 몇 가지를 해결했다.

Anthropic의 결론은 모든 작업에 세 개의 에이전트가 필요하다는 것이 아니었다. 평가는 작업이 생성자가 안정적으로 완료할 수 있는 범위의 경계에 있을 때 가장 큰 가치를 냈다.

그 경계는 동적이다. 모델 출시가 이를 바깥으로 밀어낸다. 더 까다로운 작업은 다시 이를 안쪽으로 끌어들인다.

이는 쓰라린 교훈에 대한 다른 해석을 낳는다. 범용 모델은 어제의 문제를 위한 수작업 솔루션을 대체하지만, 이전에는 비현실적이었던 목표에도 도달하게 만든다.

팀이 그런 목표를 시도하기 시작하면 새로운 실패 양식이 나타난다. 하니스는 사라지지 않는다. 역량의 최전선을 따라간다.

Anthropic의 입장은 평가 역시 제품의 일부라는 점을 인정한다. 더 많은 결과물을 생성하는 시스템이 자동으로 더 유용한 것은 아니다. 누군가 또는 무언가가 그 결과물이 실제 요구사항을 충족하는지 판단해야 한다.

개발자에게는 테스트 스위트가 그러한 판단의 상당 부분을 제공할 수 있다. 디자인, 리서치, 관리 업무에서는 에이전트가 행동하기 전에 기준을 명시해야 하는 경우가 많다.

플래너-평가자 아키텍처는 그러한 기대를 명시화한다. 또한 잘못된 기준을 증폭할 수도 있다. 평가자는 사용자가 가치를 두는 것을 놓치는 경우에도 자신이 받은 측정 가능한 대리 지표를 집행한다.

따라서 더 무거운 하니스는 자체적인 거버넌스 문제를 만든다. 구성 요소가 많아질수록 유지해야 할 프롬프트, 권한, 로그, 인계, 실패 경로도 늘어난다.

Anthropic의 증거는 영구적인 복잡성이 아니라 선택적 구조를 뒷받침한다. 더 강력한 모델이 이제 처리할 수 있는 것은 제거하고, 검증이 여전히 의미 있는 이득을 내는 곳에 엔지니어링 노력을 다시 투입하라.

모델 대 하니스의 검증은 아직 결론 나지 않았다

어느 쪽도 자신이 선호하는 아키텍처가 모델, 작업, 예산, 위험 수준 전반에서 승리한다는 점을 보여주지 못했다.

OpenAI와 Anthropic의 하니스 논쟁은 내부 실험과 제품 관찰에 크게 의존한다. 이러한 출처는 엔지니어링 선택을 드러내지만, Codex와 Claude Code 사이의 통제된 비교를 제공하지는 않는다.

OpenAI의 설명은 자사 모델, 리포지토리, 팀 관행을 반영한다. Anthropic의 사례는 선별된 애플리케이션 구축 작업에서 Claude 모델을 사용한다. 각 회사는 환경과 성공 기준을 선택했다.

Anthropic의 상세 비교조차 한 번에 여러 변수를 바꿨다. 전체 시스템은 계획, 평가, 분해, 더 긴 실행, 더 많은 모델 호출을 추가했다. 이 결과만으로는 어떤 구성 요소가 각각의 개선을 만들었는지 분리할 수 없다.

회사는 이후 이 질문을 이해하기 위해 구성 요소 제거 방식을 사용했다. 그러나 그 결론 역시 폭넓은 독립적 재현이 아니라 소수의 시연 사례에서 나왔다.

제3자 벤치마크는 도움이 되지만, 추가적인 복잡성을 초래한다. 하니스는 벤치마크가 자신이 선호하는 워크플로와 유사하기 때문에 좋은 성능을 낼 수 있다. 다른 구성은 토큰 사용량, 통과율, 지연 시간, 또는 복구 가능성을 최적화할 수 있다.

같은 점수도 서로 다른 운영 위험을 숨길 수 있다. 한 에이전트는 눈에 띄게 실패하고 멈출 수 있다. 다른 에이전트는 자동 검사를 통과하는 그럴듯하지만 잘못된 결과를 만들 수 있다.

프로덕션 코딩 시스템 연구는 점점 더 모델과 하니스를 결합된 단위로 다룬다. 최근 소스 코드 연구는 Claude Code, Codex CLI, Gemini CLI, Pi, OpenCode, OpenHands를 포함한 11개 코딩 하니스를 조사했다.

이러한 다양성은 단 하나의 최적 하니스라는 생각을 약화시킨다. 이 시스템들은 설계자가 서로 다른 사용자를 겨냥하기 때문에 컨텍스트 관리, 확장 지점, 계획, 격리, 도구 실행에서 차이를 보인다.

이식성은 또 다른 미해결 문제다. 보도에 따르면 오픈소스 Pi 하니스가 동일한 OpenAI 모델을 사용하면서 Codex보다 우수한 성능을 보인 비교가 있었다.

이와 같은 결과는 모델 제공업체가 모든 작업에 가장 좋은 환경을 자동으로 구축하는 것은 아니라는 점을 시사한다. 벤치마크 설정과 구성은 여전히 결정적이므로, Pi가 광범위하게 승리한다는 사실을 입증하지는 않는다.

오픈 하니스는 독점 제품이 숨기는 실행 추적, 토큰 사용량, 구성 세부 정보를 드러낼 수 있다. 이러한 투명성은 팀이 실패를 진단하고 제공업체를 전환하는 데 도움을 준다.

제공업체가 통제하는 하니스는 모델별 기능에 더 이르게 접근한다. 개발자는 문서화되지 않은 동작에 맞춰 조정하고, 조율된 업데이트를 배포할 수 있다.

사업적 유인도 중요하다. OpenAI와 Anthropic 모두 고객이 자체 인터페이스를 통해 모델을 사용할 때 이익을 얻는다. 하니스를 소유하면 유통력이 강화되고, 저장된 컨텍스트, 통합, 학습된 워크플로를 통해 전환 비용이 높아질 수 있다.

그렇다고 그들의 엔지니어링 주장이 거짓이 되는 것은 아니다. 이는 고객이 기술적 증거와 플랫폼 전략을 분리해야 한다는 뜻이다.

공개 가격 수치를 비교하지 않더라도 비용 역시 또 다른 불확실성이다. 다중 에이전트 계획과 평가는 추가 토큰과 시간을 소비한다. 실패 비용이 큰 경우에는 더 높은 완료율이 그러한 오버헤드를 정당화할 수 있다.

일상적이고 되돌릴 수 있는 작업에는 반대가 적용된다. 사소한 수정마다 평가자를 실행하는 것은 가끔 발생하는 오류를 고치는 것보다 더 많은 자원을 소비할 수 있다.

안전성은 더 가벼운 하니스 논지를 더욱 복잡하게 만든다. 더 나은 모델은 더 긴 행동 시퀀스를 실행하고 도구를 더 효과적으로 사용할 수 있다. 이러한 개선은 잘못 이해한 지시의 결과를 더 크게 만든다.

권한 경계, 감사 로그, 샌드박싱, 확인 절차는 모두 하니스 기능이다. 더 강한 역량은 계획 스캐폴드의 필요성을 줄이는 동시에 이들의 중요성을 높일 수 있다.

따라서 팀은 일차원적인 테스트를 거부해야 한다. 유용한 평가는 작업 완료, 숨은 결함, 사람의 검토 시간, 자원 소비, 실패 후 복구를 측정해야 한다.

또한 같은 모델에서 구성을 비교해야 한다. 그렇지 않으면 컨텍스트나 도구 변경으로 해결할 수 있었던 문제에 더 유능한 모델을 구매하게 될 수 있다.

현재의 증거는 조건부 규칙을 뒷받침한다. 정의된 신뢰성 임계값을 충족하는 가장 가벼운 하니스를 사용하고, 관찰된 실패가 정당화하는 곳에 구조를 추가하라.

이 규칙은 타협처럼 들리지만, 까다로운 운영 작업을 만든다. 구성 요소가 언제까지 유용한지 알기 위해 팀에는 반복 가능한 평가, 실행 추적 검사, 버전 관리되는 구성이 필요하다.

그러한 증거가 없으면 “더 가벼운”은 다음 모델에 대한 믿음이 된다. “더 무거운”은 프롬프트와 워크플로 분기에 인코딩된 축적된 관행이 된다.

세 가지 신호가 어느 접근법이 승리할지 결정할 것이다

다음 단계는 어느 회사가 선호하는 아키텍처 설명이 아니라 비교 증거에 의해 결정될 것이다.

첫 번째 신호는 하니스를 교체했을 때의 성능이다. 연구자와 프레임워크 구축자는 모델, 작업, 도구 접근, 자원 한도를 일정하게 유지하는 통제된 테스트를 수행해야 한다.

제3자 하니스가 동일한 모델을 사용하면서 제공업체 인터페이스를 반복적으로 능가한다면, 가치는 오케스트레이션 쪽으로 이동하고 있다. 그러한 결과는 모델 발전이 자연스럽게 제품 차별화의 대부분을 흡수한다는 믿음을 약화할 것이다.

잘 설계된 하니스 간 성능 차이가 좁혀진다면 OpenAI의 논지가 힘을 얻는다. 이는 더 강력한 모델이 더 적은 특수 개입을 필요로 하며, 더 단순하고 표준화된 환경에서 작동할 수 있음을 시사한다.

두 번째 신호는 Anthropic과 OpenAI가 각 모델 출시 후 자체 시스템을 어떻게 단순화하는지다. Anthropic은 이미 Opus 4.6 워크플로에서 스프린트 분해를 제거하며 이 테스트의 한 버전을 보여줬다.

다음으로 어떤 구성 요소가 사라지는지 지켜봐야 한다. 계획, 컨텍스트 재설정, 독립 평가, 빈번한 승인은 각각 모델 한계에 대한 서로 다른 가정을 나타낸다.

작업 품질을 낮추지 않고 구성 요소를 제거하면 더 가벼운 하니스의 근거가 강화된다. 그 구성 요소를 더 어려운 작업군으로 옮기면 Anthropic의 이동하는 최전선 해석을 뒷받침한다.

세 번째 신호는 소프트웨어 엔지니어링 밖에서의 도입이다. 코딩 에이전트는 리포지토리, 테스트, 디지털화된 피드백의 이점을 얻는다. 지식 업무에는 더 약한 신호와 더 많은 암묵적 선호가 존재한다.

사람들이 광범위한 수정 없이 완료된 작업을 받아들인다면 모델 주도 에이전트는 설득력 있어 보일 것이다. 사용자가 일관되게 미리보기, 비교, 승인 체크포인트를 필요로 한다면 협업형 하니스가 더 강해 보일 것이다.

가장 유용한 도입 지표는 시작된 작업 수가 아니다. 사람의 검토와 재작업을 고려한 뒤 올바르게 완료된 작업의 비율이다.

개발자는 실패의 심각도도 추적해야 한다. 더 적은 작업을 완료하더라도 안전하게 멈추는 하니스는, 감지하기 어려운 실수를 하면서 더 많은 작업을 끝내는 하니스보다 바람직할 수 있다.

엔터프라이즈 구매자는 자사의 문서, 권한, 워크플로를 사용한 평가를 요구해야 한다. 공개 리더보드는 조직별 정확성 정의를 대표할 수 없다.

지식 근로자도 이 과정의 더 단순한 버전을 수행할 수 있다. 익숙하고 되돌릴 수 있는 작업부터 시작해 에이전트의 결과를 확립된 인간 기준선과 비교하라.

모델이 컨텍스트를 부족하게 가졌던 지점, 잘못된 도구를 선택했던 지점, 또는 주관적 안내가 필요했던 지점을 기록하라. 이러한 관찰은 다음 개입이 지침, 검색, 승인 규칙, 독립 검토 중 어디에 속하는지 보여준다.

OpenAI와 Anthropic의 하네스 논쟁은 한 회사는 얇은 계층을 선택하고 다른 회사는 두꺼운 계층을 구축하는 식으로 끝나지 않을 것입니다. 두 회사 모두 모델과 작업이 변화함에 따라 이미 구성 요소를 추가하고 제거하고 있습니다.

지속 가능한 우위는 이러한 변화를 빠르게 측정할 수 있는 팀에 돌아갈 것입니다. 그들은 어떤 제약이 여전히 실패를 막는지, 또 어떤 제약이 이전 세대 모델의 가정만을 유지하는지를 알게 될 것입니다.

에이전트를 배포하는 모든 이에게 당장의 조치는 간단합니다. 모델과 하네스를 함께 테스트하고, 실제 트레이스를 검토하며, 더 폭넓은 자율성을 부여하기 전에 성공의 기준을 정의하십시오. 더 강력한 모델은 엔지니어링의 경계를 바꾸지만, 그 경계를 찾아야 할 필요까지 없애지는 않습니다.