Docs | Src |   A-  |  A+   | -/-

Metadata
sourcehttps://addyosmani.com/blog/agent-harness-engineering/
created2026-04-28
byopenai:gpt-5.4
style번호식

(요약) Agent Harness Engineering

  1. 코딩 에이전트는 모델 자체가 아니라, 모델 주위에 구축한 모든 것을 포함한 시스템임.
  2. 하네스 엔지니어링(harness engineering)은 그 주변 스캐폴딩(scaffolding)을 실제 산출물로 다루는 접근임.
  3. 에이전트가 실수할 때마다, 다시는 같은 실수를 하지 않도록 해결책을 하네스에 반영하는 방식임.
  4. 지난 2년간 업계는 어떤 모델이 더 똑똑한지, 더 깔끔한 React를 쓰는지, 환각이 덜한지에 집중해 왔음.
  5. 그러나 그 논의는 시스템의 절반만 다룬 것임.
  6. 모델은 실행 중인 에이전트의 하나의 입력에 불과함.
  7. 나머지는 하네스임.
  8. 하네스에는 프롬프트, 도구, 컨텍스트 정책, 훅(hooks), 샌드박스, 서브에이전트, 피드백 루프, 복구 경로가 포함됨.
  9. 좋은 하네스를 갖춘 준수한 모델이, 나쁜 하네스를 갖춘 뛰어난 모델보다 낫다는 것이 핵심 주장임.
  10. 저자는 자신의 작업에서 이 현상을 반복적으로 봤다고 말함.
  11. 점점 더 흥미로운 엔지니어링은 모델 선택보다 스캐폴딩 설계에 있다고 봄.
  12. 이 분야에는 이제 이름이 붙었음.
  13. Viv Trivedy가 harness engineering이라는 용어를 만들었음.
  14. 그의 “Anatomy of an Agent Harness” 글은 하네스가 무엇이며 각 구성요소가 왜 존재하는지 가장 명확하게 설명한 자료로 평가됨.
  15. Dex Horthy는 이 패턴의 형성을 추적해 왔음.
  16. HumanLayer는 에이전트 실패 대부분을 모델 가중치가 아니라 설정(configuration) 문제로 봄.
  17. Anthropic 엔지니어링 팀은 장기 실행 작업용 하네스 설계에 대한 뛰어난 공개 분석을 내놓았음.
  18. Birgitta Böckeler는 사용자 관점에서의 개요를 잘 정리했음.
  19. 이 글은 그런 논의들을 하나로 엮으려는 시도임.

What is a harness, really?

  1. Viv의 한 줄 정의가 핵심을 설명함.
  2. “Agent = Model + Harness”임.
  3. “모델이 아니라면 그것이 곧 하네스”라는 뜻임.
  4. 하네스는 모델 자체가 아닌 모든 코드, 설정, 실행 로직임.
  5. 원시 모델(raw model)은 그 자체로 에이전트가 아님.
  6. 하네스가 상태(state), 도구 실행, 피드백 루프, 강제 가능한 제약을 부여할 때 비로소 에이전트가 됨.
  7. 하네스에는 시스템 프롬프트, CLAUDE.md, AGENTS.md, 스킬 파일, 서브에이전트 프롬프트가 포함됨.
  8. 도구, 스킬, MCP 서버, 그리고 그 설명도 포함됨.
  9. 파일시스템, 샌드박스, 브라우저 같은 번들 인프라도 포함됨.
  10. 서브에이전트 생성, 핸드오프, 모델 라우팅 같은 오케스트레이션 로직도 포함됨.
  11. 압축(compaction), 지속(continuation), 린트 검사 같은 결정적 실행을 위한 훅과 미들웨어도 포함됨.
  12. 로그, 트레이스, 비용 및 지연시간 계측 같은 관측 가능성(observability)도 포함됨.
  13. Simon Willison은 에이전트를 “목표 달성을 위해 도구를 반복 실행하는 시스템”으로 요약함.
  14. 실력은 도구와 루프 모두의 설계에 있다고 봄.
  15. 하네스의 표면적(surface area)은 매우 넓음.
  16. 그 표면적은 모델 제공자가 아니라 사용자 자신의 책임 범위임.
  17. Claude Code, Cursor, Codex, Aider, Cline은 모두 하네스임.
  18. 그 아래 모델이 같을 때도 있음.
  19. 그러나 사용자가 체감하는 행동은 하네스가 무엇을 하느냐에 더 크게 좌우됨.
  20. coding agent = AI model(s) + harness라는 식이 실제 작업이 어디에 있는지 보여줌.
  21. 왼쪽 항에 대한 논쟁은 시끄럽지만, 실제 지렛대(leverage)는 대체로 오른쪽 항에 있음.

The “skill issue” reframe

  1. 엔지니어들은 에이전트가 어리석은 행동을 하면 모델을 탓하고 다음 버전을 기다리려는 경향이 있음.
  2. 하네스 엔지니어링 사고방식은 그 기본 반응을 거부함.
  3. 실패는 대체로 읽을 수 있고 설명 가능하다고 봄.
  4. 에이전트가 관례를 몰랐다면 AGENTS.md에 추가하면 됨.
  5. 파괴적 명령을 실행했다면 그것을 막는 훅을 추가하면 됨.
  6. 40단계 작업에서 길을 잃었다면 계획자(planner)와 실행자(executor)로 분리하면 됨.
  7. 고장 난 코드를 계속 “완료”로 판단했다면 타입체크(typecheck) 역압력(back-pressure) 신호를 루프에 연결하면 됨.
  8. HumanLayer는 이것이 모델 문제가 아니라 설정 문제라고 말함.
  9. 하네스 엔지니어링은 그 말을 진지하게 받아들일 때 시작됨.
  10. Viv의 글과 HumanLayer 모두에 등장하는 인상적인 데이터 포인트가 있음.
  11. Terminal Bench 2.0에서 Claude Code 내부의 Claude Opus 4.6은, 같은 모델을 커스텀 하네스에서 실행할 때보다 훨씬 낮은 점수를 기록함.
  12. Viv 팀은 하네스만 바꿔서 코딩 에이전트를 Top 30에서 Top 5로 끌어올렸음.
  13. 모델은 사후학습(post-training) 단계에서 자신이 훈련된 하네스와 결합됨.
  14. 더 나은 코드베이스 도구, 더 촘촘한 프롬프트, 더 날카로운 역압력을 가진 다른 하네스로 옮기면, 기존 하네스가 놓치고 있던 능력을 끌어낼 수 있음.
  15. 이것은 “GPT-6을 기다리면 된다”는 서사의 반대편에 있음.
  16. 오늘날 모델이 실제로 할 수 있는 것과 사용자가 보는 성능 사이의 격차는 대체로 하네스 격차임.

The ratchet: every mistake becomes a rule

  1. 하네스 엔지니어링의 가장 중요한 습관은 에이전트 실수를 영구적 신호로 다루는 것임.
  2. 웃고 넘길 일회성 에피소드나 재시도할 “나쁜 런”으로 취급하지 않음.
  3. 신호로 취급함.
  4. 에이전트가 주석 처리된 테스트가 포함된 PR을 만들고, 저자가 실수로 그것을 병합했다면 그것은 입력값이 됨.
  5. 다음 버전의 AGENTS.md에는 “테스트를 절대 주석 처리하지 말고, 삭제하거나 고쳐라”라는 규칙이 추가됨.
  6. 다음 버전의 pre-commit 훅은 diff에서 .skip(와 xit(를 grep함.
  7. 다음 버전의 리뷰어 서브에이전트는 주석 처리된 테스트를 차단 사유로 표시함.
  8. 제약은 실제 실패를 본 뒤에만 추가해야 함.
  9. 제약은 더 유능한 모델이 그것을 불필요하게 만들었을 때만 제거해야 함.
  10. 좋은 AGENTS.md의 모든 줄은 구체적으로 무엇이 잘못됐는지에 추적 가능해야 함.
  11. 그래서 하네스 엔지니어링은 프레임워크가 아니라 규율(discipline)임.
  12. 코드베이스에 맞는 올바른 하네스는 그 팀의 실패 이력에 의해 형성됨.
  13. 그것은 다운로드해서 바로 쓸 수 있는 것이 아님.

Working backwards from behaviour

  1. 저자가 하네스를 실제로 설계할 때 가장 유용하다고 느끼는 Viv의 틀은 원하는 행동에서 거꾸로 출발하는 것임.
  2. 패턴은 “우리가 원하거나 고치고 싶은 행동 → 모델이 그 행동을 하도록 돕는 하네스 설계”임.
  3. 이렇게 도출하면 각 하네스 구성요소가 구체적인 역할을 갖게 됨.
  4. 어떤 구성요소가 어떤 행동을 위해 존재하는지 설명할 수 없다면, 아마 거기 없어야 함.
  5. 이어지는 절은 Viv의 순서를 대체로 따라가며 훔칠 만한 패턴을 설명함.

Filesystem and Git: durable state

  1. 파일시스템은 가장 기초적인 프리미티브(primitive)임.
  2. 지루해 보여서 과소평가되는 경향이 있음.
  3. 모델은 컨텍스트에 들어가는 범위 내의 것만 직접 다룰 수 있음.
  4. 파일시스템이 없으면 채팅창에 복사 붙여넣기만 하게 됨.
  5. 그것은 워크플로가 아님.
  6. 파일시스템이 있으면 에이전트는 데이터, 코드, 문서를 읽을 작업공간을 얻음.
  7. 중간 산출물을 컨텍스트에 들고 있지 않고 외부로 오프로드할 장소를 얻음.
  8. 여러 에이전트와 사람이 공유 파일을 통해 협업할 수 있는 표면도 생김.
  9. 여기에 Git을 더하면 버전 관리를 공짜로 얻음.
  10. 에이전트는 진행 상황을 추적하고, 오류를 롤백하고, 실험용 브랜치를 만들 수 있음.
  11. 다른 많은 하네스 프리미티브도 결국 파일시스템을 향하게 됨.

Bash and code execution: the general-purpose tool

  1. 오늘날 주된 에이전트 루프는 ReAct 루프임.
  2. 모델이 추론하고, 도구 호출을 통해 행동하고, 결과를 관찰하고, 이를 반복함.
  3. 그러나 하네스는 자신이 실행 로직을 가진 도구만 실행할 수 있음.
  4. 가능한 모든 행동에 대해 미리 도구를 만들 수도 있음.
  5. 또는 bash를 줘서 에이전트가 필요할 때 도구를 직접 만들게 할 수도 있음.
  6. Willison은 에이전트가 이미 셸 명령에 강하다고 봄.
  7. 대부분의 작업은 잘 고른 몇 개의 CLI 호출로 축약됨.
  8. 하네스는 여전히 특화 도구를 제공하지만, bash와 코드 실행이 자율적 문제 해결의 기본 범용 전략이 되었음.
  9. 이는 하나의 주방 기구만 쓰는 법을 가르치는 것과, 주방 전체를 건네는 것의 차이로 비유됨.

Sandboxes and default tooling

  1. bash는 안전한 곳에서 실행될 때만 유용함.
  2. 에이전트가 생성한 코드를 개인 노트북에서 실행하는 것은 위험함.
  3. 단일 로컬 환경은 많은 병렬 에이전트에도 확장되지 않음.
  4. 샌드박스는 에이전트에 격리된 운영 환경을 제공함.
  5. 하네스는 로컬 실행 대신 샌드박스에 연결해 코드 실행, 파일 검사, 의존성 설치, 작업 검증을 수행함.
  6. 명령 allow-list를 둘 수 있음.
  7. 네트워크 격리를 강제할 수 있음.
  8. 필요할 때 새 환경을 띄울 수 있음.
  9. 작업이 끝나면 환경을 제거할 수 있음.
  10. 좋은 샌드박스는 좋은 기본값을 함께 제공함.
  11. 사전 설치된 언어 런타임과 패키지, Git과 테스트 CLI, 웹 상호작용용 헤드리스 브라우저가 포함됨.
  12. 브라우저, 로그, 스크린샷, 테스트 러너는 에이전트가 자기 작업을 관찰하고 자기 검증 루프를 닫게 해 줌.
  13. 모델은 실행 환경을 구성하지 않음.
  14. 어디서 실행할지, 무엇을 사용할 수 있을지, 출력을 어떻게 검증할지는 모두 하네스 수준의 결정임.

Memory and search: continual learning

  1. 모델은 자신의 가중치와 현재 컨텍스트를 넘는 추가 지식을 갖지 않음.
  2. 가중치를 직접 수정할 수 없다면, 지식을 추가하는 유일한 방법은 컨텍스트 주입(context injection)임.
  3. 여기서도 파일시스템이 핵심 프리미티브임.
  4. 하네스는 AGENTS.md 같은 메모리 파일 표준을 지원하고, 이를 시작할 때마다 주입함.
  5. 에이전트가 그 파일을 수정하면 하네스는 그것을 다시 로드함.
  6. 한 세션의 지식이 다음 세션으로 이어짐.
  7. 이는 거칠지만 효과적인 지속 학습(continual learning) 형태임.
  8. 훈련 시점 이후에 생긴 지식에는 웹 검색과 Context7 같은 MCP 도구가 컷오프(cutoff)를 메워 줌.
  9. 새 라이브러리 버전, 최신 문서, 오늘의 데이터가 여기에 해당함.
  10. 이런 기능은 사용자에게 맡기기보다 하네스에 내장할 만한 프리미티브임.

Battling context rot

  1. 컨텍스트 부패(context rot)는 컨텍스트 창이 차오를수록 모델의 추론과 작업 완료 능력이 악화된다는 관찰임.
  2. 컨텍스트는 희소 자원임.
  3. 하네스는 대체로 좋은 컨텍스트 엔지니어링을 전달하는 장치임.
  4. 반복해서 등장하는 세 가지 기법이 있음.
  5. 첫째는 압축(compaction)임.
  6. 컨텍스트 창이 거의 찼을 때는 무언가를 줄여야 함.
  7. 프로덕션 하네스에서 API 에러를 그냥 허용할 수는 없음.
  8. 그래서 하네스는 오래된 컨텍스트를 지능적으로 요약하고 오프로드해 에이전트가 계속 일하게 함.
  9. 둘째는 도구 호출 오프로드(tool-call offloading)임.
  10. 2,000줄짜리 로그 같은 큰 도구 출력은 신호는 적고 컨텍스트만 어지럽힘.
  11. 하네스는 일정 임계값 이상일 때 앞부분과 끝부분 토큰만 남김.
  12. 전체 출력은 파일시스템으로 오프로드함.
  13. 에이전트는 필요할 때 그것을 읽음.
  14. 셋째는 점진적 공개(progressive disclosure)를 갖춘 스킬(skills)임.
  15. 시작 시점에 모든 도구와 MCP를 컨텍스트에 넣으면, 에이전트가 행동하기도 전에 성능이 떨어짐.
  16. 스킬은 작업에 실제로 필요할 때만 지침과 도구를 드러내게 함.
  17. Anthropic은 매우 긴 작업을 위한 추가 기법도 제시함.
  18. 전체 컨텍스트 리셋(full context reset)임.
  19. 하네스가 세션을 종료하고 압축된 핸드오프 파일로부터 다시 세션을 구성하는 방식임.
  20. Anthropic은 긴 작업에서 압축만으로는 충분하지 않았다고 명시함.
  21. 때로는 구조화된 브리프(brief)와 함께 새로 시작해야 함.
  22. 이는 보통 우리가 기억(memory)을 떠올리는 방식보다, 새로운 엔지니어를 온보딩하는 인간 방식에 더 가까움.

Long-horizon execution: Ralph Loops, planning, verification

  1. 자율적 장기 작업은 이상적인 목표이면서 가장 어려운 문제임.
  2. 오늘날 모델은 조기 종료(early stopping), 복잡한 문제의 미흡한 분해, 여러 컨텍스트 창에 걸친 작업에서의 일관성 저하 문제를 가짐.
  3. 하네스는 이 모든 문제를 우회하도록 설계되어야 함.
  4. 저자는 자율 코딩 루프인 Ralph Loop를 이전 글들에서 다룬 바 있음.
  5. 여기서 다시 말하면, 훅이 모델의 종료 시도를 가로채고 원래 프롬프트를 새 컨텍스트 창에 다시 주입함.
  6. 이렇게 해서 에이전트가 완료 목표를 향해 계속 진행하도록 강제함.
  7. 각 반복은 깨끗한 컨텍스트에서 시작함.
  8. 그러나 파일시스템을 통해 이전 반복의 상태를 읽음.
  9. 이것은 단일 세션 에이전트를 다중 세션 에이전트로 바꾸는 놀랄 만큼 단순한 기법임.
  10. 그리고 “더 똑똑한 모델을 쓰라”는 사고방식만으로는 도출되지 않을 프리미티브임.
  11. 계획(planning)은 모델이 목표를 일련의 단계로 분해하는 것임.
  12. 보통 디스크의 계획 파일로 작성됨.
  13. 하네스는 프롬프팅과 계획 파일 사용에 대한 리마인더로 이를 지원함.
  14. 각 단계 후 에이전트는 자기 검증(self-verification)으로 작업을 점검함.
  15. 훅은 미리 정의된 테스트 스위트를 실행함.
  16. 실패는 에러 텍스트와 함께 모델로 다시 루프백됨.
  17. 또는 모델이 명시적 기준에 비추어 자기 출력을 검토함.
  18. 계획자(planner) / 생성자(generator) / 평가자(evaluator) 분리 패턴도 중요함.
  19. Anthropic은 생성과 평가를 별도 에이전트로 분리하는 것이 자기 평가보다 낫다고 명시함.
  20. 에이전트는 자기 작업을 채점할 때 긍정적으로 치우치기 때문임.
  21. 이는 산문에 대한 GANs 같은 방식으로 비유됨.
  22. 관련 패턴으로 스프린트 계약(sprint contract)이 있음.
  23. 생성자와 평가자가 코드 작성 전에 무엇이 완료(done)인지 협상하는 방식임.
  24. 저자의 워크플로에서는 시작 전에 done-condition을 적는 것이 어떤 프롬프트 변경보다도 더 많은 범위 이탈(scope drift)을 잡아냈음.

Hooks: the enforcement layer

  1. 훅은 “에이전트에게 X를 하라고 말했다”와 “시스템이 X를 강제한다”를 구분하는 요소임.
  2. 훅은 특정 생애주기 시점에서 실행되는 스크립트임.
  3. 도구 호출 전, 파일 편집 후, 커밋 전, 세션 시작 시 등이 그 시점임.
  4. 에이전트가 절대 잊어선 안 되지만 자주 잊는 일을 배치하기에 적합함.
  5. 모든 편집 후 타입체크, 린트, 테스트를 실행하고 실패를 노출할 수 있음.
  6. rm -rf, git push --force, DROP TABLE 같은 파괴적 bash를 차단할 수 있음.
  7. PR 생성이나 main 브랜치 푸시 전에 승인을 요구할 수 있음.
  8. 저장 시 자동 포맷을 걸어 공백 문제에 토큰을 낭비하지 않게 할 수 있음.
  9. HumanLayer가 강조하고 저자도 동의하는 원칙은 “성공은 조용하고, 실패는 시끄럽다”는 것임.
  10. 타입체크가 통과하면 에이전트는 아무 말도 듣지 않음.
  11. 실패하면 에러 텍스트가 루프에 주입되고 에이전트가 자가 수정함.
  12. 이는 일반적인 경우 피드백 비용을 거의 0에 가깝게 만들고, 문제 발생 시에는 바로 행동 가능한 신호를 제공함.

AGENTS.md and tool choice

  1. 저장소 루트의 평범한 마크다운 규칙집은 여전히 가장 지렛대가 큰 설정 지점임.
  2. 그것이 매 턴 시스템 프롬프트에 들어가기 때문임.
  3. 패키지 관리자, 테스트 프레임워크, 포맷팅, “/legacy는 절대 건드리지 말 것”, “항상 우리 로거를 사용할 것” 같은 관례가 여기에 들어감.
  4. 여기서 얻은 두 가지 교훈이 있음.
  5. 첫째는 짧게 유지하라는 것임.
  6. HumanLayer는 이를 60줄 이하로 유지함.
  7. 모든 줄은 주의를 두고 경쟁함.
  8. 규칙이 많아질수록 각 규칙의 중요성은 줄어듦.
  9. 스타일 가이드가 아니라 조종사 체크리스트여야 함.
  10. 둘째는 각 줄을 벌어야 한다는 것임.
  11. 규칙은 구체적인 과거 실패나 단단한 외부 제약에 연결되어야 함.
  12. 그렇지 않으면 잡음임.
  13. 브레인스토밍하지 말고 래칫(ratchet) 방식으로 쌓아야 함.
  14. 같은 규율이 도구에도 적용됨.
  15. 각 도구의 이름, 설명, 스키마는 매 요청마다 프롬프트에 찍혀 들어감.
  16. 메뉴를 모델이 머릿속에 유지할 수 있기 때문에, 겹치는 50개 도구보다 집중된 10개 도구가 더 낫음.
  17. HumanLayer는 여기서 실제 보안 우려도 지적함.
  18. 도구 설명이 프롬프트를 구성하므로, 설치하는 어떤 MCP 서버도 모델이 읽게 되는 신뢰된 텍스트가 됨.
  19. 부주의하거나 악의적인 MCP는 사용자가 입력하기도 전에 에이전트에 프롬프트 인젝션을 할 수 있음.

What this looks like in production

  1. 저자가 본 가장 명확한 성숙한 하네스의 공개 사례는 Fareed Khan이 추정한 Claude Code 아키텍처 분석임.
  2. 그 도식을 잠시 들여다볼 가치가 있다고 말함.
  3. 이전 절의 거의 모든 개념이 그 도식에 이름 붙은 구성요소로 등장함.
  4. 컨텍스트 주입은 지식 계층(knowledge layer)임.
  5. 루프 상태는 메모리 저장소(memory store)와 워크트리 격리기(worktree isolator)에 있음.
  6. 파괴적 행동 훅은 권한 게이트(permission gate) 뒤에 있음.
  7. 서브에이전트 컨텍스트 방화벽은 멀티에이전트 계층 전체를 이룸.
  8. 도구 디스패치 레지스트리는 MCP 서버와 bash가 연결되는 곳임.
  9. Khan의 주장은 Viv의 주장과 동일함.
  10. 단지 실제 제품에 적용해 풀어낸 형태임.
  11. Claude Code의 발전은 그 아래 모델만큼이나 하네스에도 크게 달려 있다는 주장임.

Harnesses don’t shrink, they move

  1. Anthropic 글의 더 좋은 관찰 중 하나는 모델이 좋아질수록 흥미로운 하네스 조합의 공간이 줄어들지 않는다는 것임.
  2. 그 공간은 이동함.
  3. 순진한 서사는 더 나은 모델이 하네스를 쓸모없게 만든다고 봄.
  4. 모델이 계획할 수 있으면 계획자가 필요 없고, 긴 작업에서도 일관성이 있으면 컨텍스트 리셋이 필요 없다는 식임.
  5. 실제로 Opus 4.6은 컨텍스트 불안(context-anxiety) 실패 모드를 크게 줄였음.
  6. Sonnet 4.5는 자신이 컨텍스트 한계에 다가간다고 생각하면 작업을 조기에 마무리하는 경향이 있었음.
  7. 그래서 저자가 6개월 전 작성하던 불안 완화 스캐폴딩의 상당수는 이제 죽은 코드(dead code)가 되었음.
  8. 그러나 모델과 함께 성능 상한도 이동했음.
  9. 과거에는 닿을 수 없던 작업이 이제 가능해졌고, 그 작업들은 새로운 실패 모드를 가짐.
  10. 불안 완화 스캐폴딩은 사라짐.
  11. 대신 다중 일자 메모리 정책, 세 개의 특화 에이전트를 조정하는 하네스, 생성된 UI의 디자인 품질을 평가하는 평가자 같은 새 스캐폴딩이 필요해짐.
  12. 가정이 바뀌고, 그것을 코드화하는 스캐폴딩도 바뀜.
  13. Anthropic은 “하네스의 모든 구성요소는 모델이 혼자서는 할 수 없는 것에 대한 가정을 인코딩한다”고 정리함.
  14. 모델이 어떤 일을 더 잘하게 되면 그 구성요소는 더 이상 하중을 받지 않는 부품이 되며 제거되어야 함.
  15. 모델이 새로운 가능성을 열면, 그 새 상한에 도달하기 위한 새 스캐폴딩이 필요함.

The model-harness training loop

  1. Viv가 명시적으로 이름 붙인 또 다른 현상은 하네스 설계와 모델 훈련 사이의 피드백 루프임.
  2. 유용한 프리미티브가 하네스에서 발견됨.
  3. 그것이 제품에 표준화됨.
  4. 다음 세대 모델을 훈련할 때 사용됨.
  5. 그러면 다음 모델은 그 프리미티브를 더 잘 사용하게 됨.
  6. 그리고 이 순환이 반복됨.
  7. 오늘날 에이전트 제품은 하네스를 루프 안에 둔 채 사후학습됨.
  8. 모델은 하네스 설계자가 중요하게 여기는 행동에서 특히 더 잘하도록 학습됨.
  9. 파일시스템 조작, bash, 계획, 서브에이전트 디스패치가 그 예임.
  10. 그래서 Opus 4.6은 Claude Code 안에서 다른 하네스 안에 있을 때와 다르게 느껴짐.
  11. 그래서 도구 로직을 바꾸면 이상한 퇴행(regression)이 생기기도 함.
  12. 진정으로 일반적인 모델이라면 apply_patch를 쓰든 str_replace를 쓰든 상관없어야 함.
  13. 그러나 공동 훈련(co-training)은 과적합(overfitting)을 낳음.
  14. 여기서의 실질적 함의는 두 가지임.
  15. 하네스는 한 번 설정하고 끝나는 설정 파일이 아니라 살아 있는 시스템임.
  16. 그리고 “최고의” 하네스는 반드시 모델이 훈련된 하네스가 아님.
  17. 그것은 사용자의 과업에 맞게 설계된 하네스임.
  18. Viv의 Terminal Bench Top 30에서 Top 5로의 도약이 그 가장 분명한 증거임.

Harness-as-a-Service

  1. Viv의 또 다른 기여는 HaaS(Harness-as-a-Service)라는 틀임.
  2. 업계는 완성(completion)을 주는 LLM API 위에서 구축하는 단계에서, 런타임(runtime)을 주는 하네스 API 위에서 구축하는 단계로 이동하고 있다는 관찰임.
  3. Claude Agent SDK, Codex SDK, OpenAI Agents SDK가 모두 같은 방향을 가리킴.
  4. 루프, 도구, 컨텍스트 관리, 훅, 샌드박스 프리미티브를 기본 제공하고, 사용자는 그것을 커스터마이즈함.
  5. 이 전환이 중요한 이유가 있음.
  6. 예전의 기본 경로는 직접 루프를 만들고, 직접 도구 호출을 연결하고, 직접 대화 상태를 관리하고, 직접 승인 흐름을 발명하는 것이었음.
  7. 이제의 기본 경로는 하네스 프레임워크를 고르는 것임.
  8. 그리고 네 개 기둥인 시스템 프롬프트, 도구, 컨텍스트, 서브에이전트에 따라 구성함.
  9. 나머지 노력은 도메인 특화 프롬프트와 도구 설계에 투입함.
  10. 그래서 “skill issue”를 현실적으로 다룰 수 있게 됨.
  11. 뭔가 잘못될 때마다 에이전트를 처음부터 다시 만들 필요가 없음.
  12. 이미 잘 분해된 설정 표면(configuration surface)을 조정하면 됨.
  13. Viv는 “좋은 에이전트 구축은 반복의 연습이며, v0.1이 없으면 반복도 할 수 없다”고 말함.
  14. 이것은 지저분하게라도 빨리 시작해야 한다는 가장 좋은 논거로 제시됨.

Where this is going

  1. 상위 코딩 에이전트들을 나란히 보면 Claude Code, Cursor, Codex, Aider, Cline은 서로 닮아 있음.
  2. 그들의 기반 모델들이 서로 닮은 정도보다 하네스 패턴이 더 수렴하고 있음.
  3. 저자는 이것이 우연이 아니라고 봄.
  4. 산업이 생성 모델을 실제 출하 가능한 시스템으로 바꾸는 하중 지지형(load-bearing) 스캐폴딩을 천천히 찾아가고 있다는 뜻임.
  5. Viv가 제시한 열린 문제들 중 저자가 특히 흥미롭게 보는 것이 있음.
  6. 공유 코드베이스에서 병렬로 일하는 많은 에이전트의 오케스트레이션임.
  7. 자신의 실행 추적(trace)을 분석해 하네스 수준 실패 모드를 찾아내고 고치는 에이전트임.
  8. 시작 시 미리 구성된 상태가 아니라, 과업에 맞는 도구와 컨텍스트를 적시(just-in-time)에 동적으로 조립하는 하네스임.
  9. 특히 마지막 문제는 중요하게 보임.
  10. 그 지점에서 하네스는 정적인 설정을 넘어, 컴파일러에 가까운 무언가가 되기 시작함.