AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

같은 모델로 Top 30에서 Top 5로, 하네스 엔지니어링이 바꾸는 것

Claude Code를 쓰는데 동료는 훨씬 빠르고 정확하게 결과를 냅니다. 같은 Claude Opus 4.6을 쓰고 있는데도요. 모델이 같다면 차이는 어디서 오는 걸까요?

사진 출처: addyosmani.com

구글 엔지니어링 디렉터 Addy Osmani가 최근 블로그에서 이 질문에 정면으로 답했습니다. AI 코딩 에이전트의 성능을 결정하는 건 모델이 아니라 하네스(harness), 즉 모델 주변에 구축하는 모든 것이라는 주장입니다. Terminal Bench 2.0 벤치마크에서 같은 모델로 하네스만 바꿨더니 순위가 Top 30에서 Top 5로 뛰었다는 데이터가 이를 뒷받침합니다.

출처: Agent Harness Engineering – addyosmani.com

에이전트 = 모델 + 하네스

하네스란 모델 그 자체를 제외한 모든 것입니다. 시스템 프롬프트, AGENTS.md 파일, 도구 설명, 샌드박스 환경, 오케스트레이션 로직, 훅(hook), 로그와 비용 추적까지. 모델이 실제로 작동하는 데 필요한 모든 스캐폴딩이 하네스입니다.

Osmani는 이걸 한 줄로 정리합니다.

“당신이 모델이 아니라면, 당신은 하네스다.” (“If you’re not the model, you’re the harness.”)

Claude Code, Cursor, Codex, Aider, Cline 모두 각자의 하네스입니다. 같은 모델을 사용하더라도 행동이 다른 이유가 여기에 있습니다. 우리가 “어떤 모델이 더 좋냐”는 논쟁에 집중하는 동안, 실제 성능 레버는 하네스 쪽에 있었던 셈입니다.

모델 탓이 아니라 설정 탓이다

에이전트가 실수를 하면 대부분 “모델 문제”로 치부하고 다음 버전을 기다립니다. 하네스 엔지니어링은 이 습관에 정면으로 반박합니다.

에이전트가 특정 컨벤션을 몰랐다면 AGENTS.md에 추가하면 됩니다. 파괴적인 명령(rm -rf, DROP TABLE)을 실행했다면 훅으로 차단할 수 있습니다. 40단계짜리 작업에서 길을 잃었다면 플래너와 실행자로 분리하면 됩니다. 테스트를 주석 처리한 채 PR을 올렸다면 pre-commit 훅이 이를 잡아낼 수 있습니다.

HumanLayer가 이를 ‘스킬 이슈(skill issue)’라고 부릅니다. “모델 문제가 아니라 설정 문제”라는 뜻이죠. 이 관점에서 보면 에이전트 실패의 대부분은 고칠 수 있는 문제입니다.

실수가 쌓일수록 하네스는 강해진다

하네스 엔지니어링의 핵심 습관은 에이전트의 실수를 영구적인 신호로 다루는 것입니다. ‘운 나쁜 실행’으로 넘기는 대신, 규칙으로 고착시킵니다.

Osmani는 이를 래칫(ratchet) 이라고 부릅니다. 한 번 조인 나사는 풀리지 않는 방향으로만 움직이듯, 에이전트의 실수를 마주할 때마다 하네스가 한 단계씩 강해지는 방식입니다.

  1. 에이전트가 주석 처리된 테스트를 포함한 PR을 올린다
  2. AGENTS.md에 “테스트는 주석 처리하지 말고 삭제하거나 고쳐라” 규칙을 추가한다
  3. pre-commit 훅이 .skip(xit(을 diff에서 감지하면 차단한다
  4. 리뷰어 서브에이전트가 이를 블로커로 플래그한다

좋은 AGENTS.md의 모든 줄은 실제로 잘못됐던 일로 추적 가능해야 합니다. “있으면 좋을 것 같아서” 추가된 규칙은 노이즈입니다. 규칙은 파일럿의 체크리스트처럼, 짧고 각각 이유가 있어야 합니다.

모델이 개선되면 하네스도 이동한다

더 좋은 모델이 나오면 하네스가 필요 없어지는 게 아닐까요? Osmani는 하네스의 공간이 줄어드는 게 아니라 이동한다고 봅니다.

Claude Opus 4.5는 컨텍스트 한계가 다가오면 작업을 조기 종료하는 문제가 있었습니다. 그래서 이 불안을 완화하는 스캐폴딩이 필요했죠. Opus 4.6이 이 문제를 해결하면서 그 스캐폴딩은 이제 불필요한 코드가 됐습니다. 그런데 Opus 4.6이 열어준 새로운 가능성, 즉 더 복잡한 장기 작업을 처리하는 데는 또 다른 하네스가 필요합니다. 다중 일정의 메모리 정책, 여러 특화 에이전트의 협조, UI 품질을 평가하는 이밸류에이터 같은 것들이죠.

Anthropic의 표현을 빌리자면, “하네스의 모든 컴포넌트는 모델이 혼자 할 수 없는 일에 대한 가정을 담고 있습니다.” 모델이 더 잘하게 된 부분의 컴포넌트는 제거되고, 모델이 새로 열어준 영역에는 새 스캐폴딩이 들어옵니다.

현재 상위 코딩 에이전트들(Claude Code, Cursor, Codex, Aider, Cline)이 서로 다른 모델을 사용하면서도 점점 비슷한 모습을 띠는 이유가 이것입니다. 하네스 패턴이 수렴하고 있는 거죠.

원문에는 Claude Code 아키텍처의 레이어별 분석, 장기 실행 작업을 위한 Ralph Loop 메커니즘, 그리고 Harness-as-a-Service 개념으로의 전환까지 더 깊은 내용이 담겨 있습니다.

참고자료:


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다