
하네스 엔지니어링이란 ― AI 에이전트의 성능을 결정하는 '발판 층'을 숫자로 읽다
요약
AI 에이전트의 성능을 결정하는 모델 주변의 설계 요소인 '하네스 엔지니어링'의 개념과 이를 추상화한 '메타 하네스'를 소개합니다. Databricks와 Neon이 공개한 오픈 소스 구현체 Omnigent를 통해 에이전트의 합성, 통제, 협업 방식을 설명합니다.
핵심 포인트
- 에이전트는 모델과 하네스(프롬프트, 도구, 메모리 등)의 결합으로 정의됨
- 메타 하네스는 하네스들을 통합 관리하는 상위 추상화 계층임
- Omnigent는 YAML 설정을 통해 에이전트의 구성 요소를 쉽게 교체하고 통제함
- MCP(Model Context Protocol)를 활용해 도구와 데이터 소스를 공통 규격으로 연결함
AI 에이전트를 실무에 적용하면, 모델 자체의 똑똑함보다 '그 주변의 설계'에 따라 결과가 달라진다는 것을 깨닫는 경우가 많다. 같은 모델이라도 지시(Instruction), 도구(Tool), 재시도 방식에 따라 동작은 완전히 달라진다. 이 '모델 주변의 발판'을 설계하는 업무를 2026년에 들어서며 **하네스 엔지니어링 (Harness Engineering)**이라고 부르게 되었다.
이는 특정 도구의 사용법이 아니라, AI 에이전트에게 생겨난 새로운 '층(Layer)'에 관한 이야기다. LLM (대규모 언어 모델)을 API로 한 번이라도 호출해 본 적이 있다면, 직접 구축하지 않았더라도 이 관점은 설계에 그대로 적용될 수 있다.
LLM 단독으로는 똑똑하지만, 지시를 기다리는 '상자'에 불과하다. 실용화하기 위해서는 상자 주변에 발판이 필요하다. 지시를 구성하는 프롬프트, 도구, 기억(Memory), 실패 시의 복구 절차, 비용 및 권한 규칙——이 한 덩어리를 에이전트 하네스 (Agent Harness), 줄여서 하네스(Harness) = 발판이라고 부른다. 이 발판을 설계하는 것이 앞서 말한 하네스 엔지니어링이다.
이 관점을 확산시킨 제창자는 "Agent = Model + Harness (에이전트 = 모델 + 발판)"라고 정식화했다. 어떤 팀은 내부 모델을 바꾸지 않고 발판만 새로 구축하여, 벤치마크인 Terminal Bench에서 순위를 상위 30위에서 상위 5위로 끌어올렸다고 보고했다.
**메타 하네스 (Meta-Harness)**는 이러한 발판들을 한 단계 위에서 묶어주는 층을 말한다. 즉, 하네스 = 발판 그 자체, 메타 하네스 = 발판을 묶는 층이라고 구분해서 이해하면 된다.
발판은 각 기업과 각 도구에서 제각각 성장해 왔다. 그러다 보니 비슷한 발판을 복사해서 다시 만들어야 하거나, 특정 설정을 다른 도구로 옮길 수 없거나, 개수가 늘어날수록 비용과 권한을 통제할 수 없는 등의 병목 현상이 발생한다.
Databricks는 이를 서버를 한 대씩 수동으로 관리하던 시대에서 Kubernetes를 통해 서버 군을 선언적으로 다루는 시대로의 변화에 비유하며, 메타 하네스는 그 '한 단계 높은 추상화'라고 설명한다. 묶어주는 층이 제공하는 기능은 크게 세 가지다. **합성 (Composition)**은 발판을 한 줄로 교체한다. **통제 (Control)**는 비용이나 권한의 상한을 정책(Policy)으로서 강제한다. **협업 (Collaboration)**은 실행 중인 세션을 URL로 전달하여 리뷰나 인수인계에 사용한다. 본 기사에서는 앞의 두 가지를 코드로 살펴보고, 협업은 이름을 언급하는 것에 그친다.
핵심은 어떤 발판이라도 입구와 출구의 형태를 맞추는 공통 인터페이스다. Omnigent는 Databricks와 Neon이 2026년 6월에 공개한 이 층의 OSS (오픈 소스 소프트웨어) 구현체 (Apache 2.0 라이선스)이다.
Omnigent는 하나의 에이전트를 짧은 YAML (설정 파일)로 정의한다. 다음 키 이름은 공식 리포지토리의 README와 동봉된 예시 examples/polly/config.yaml을 대조한 것이다.
# === Omnigent의 에이전트 정의 (최소 예시) ===
name: my_agent
prompt: 당신은 유능한 데이터 분석가입니다.
...
주목할 점은 세 가지다. executor.harness의 한 줄을 claude-sdk에서 codex 등으로 바꾸거나 --harness 플래그를 전달하는 것만으로, 프롬프트와 도구는 그대로 유지한 채 아래의 발판만 교체된다——이것이 '합성'이다. type: mcp의 MCP (Model Context Protocol)는 도구와 데이터 소스를 LLM에 연결하는 공통 규격이다. policies가 '통제'에 해당하며, max_cost_usd로 비용 상한을, ask_thresholds_usd로 중간 승인을, ask_on_os_tools로 셸 실행 전 인간의 승인을 선언한다. 중요한 점은 이것이 요청이 아니라 층(Layer) 차원의 강제 규칙이라는 점이다. 동봉된 예시에서는 push나 merge는 자동으로 진행하되, force-push나 rm -rf /만은 항상 거부(DENY)한다.
발판만으로 그렇게 변할 수 있을까? 실제로 이를 실행하는 기업의 수치로 확인해 보자.
OpenAI는 발판 구축을 전문적인 규율로 다루며, 이를 하네스 엔지니어링이라고 부른다. 해당 기업의 공개 기사에 따르면, 3~7명 규모의 팀이 수동 코드 0줄로 약 100만 행 규모의 사내 프로덕트를 코딩 에이전트인 Codex를 사용하여 약 5개월 만에 만들어냈다고 한다 (1인당 하루 약 3.5건의 Pull Request). 이들이 수행한 것은 모델의 개량이 아니라, 지시서인 AGENTS.md를 얇은 '목차'로 만들고 상세 내용은 docs/에 두며, 규약을 lint를 통해 기계적으로 강제하는 발판을 정비한 것이었다.
발판(Harness)은 품질뿐만 아니라 비용에도 영향을 미친다. 법무용 AI인 Harvey가 Fireworks AI와 공개한 구성은, 오픈 모델인 GLM 5.1(중국에서 공개된 LLM)을 주역으로 삼고, 난도가 높은 부분에서만 고성능인 Claude Opus를 '호출 가능한 조언자'로 사용한다. Fireworks의 측정에 따르면, 품질과 비용 양면에서 Opus 단독 사용을 상회했다고 한다.
| 구성 | 100문제 중 전체 합격 | 비용 |
|---|---|---|
| Opus 단독 | 14문제 | 954달러 |
| GLM 5.1 + Opus 조언자 | 18문제 | 368달러 |
숫자의 규모는 크지만, 하고 있는 일은 앞서 언급한 YAML과 같다. 즉, 발판을 교체하고 정책(Policy)으로 묶는 것뿐이다. 자신의 PoC(Proof of Concept, 개념 증명)에서도 사용할 수 있는 수단은 다르지 않다.
냉정하게 바라보기 위한 세 가지 유보 사항이 있다. 첫째, 용어가 가리키는 범위가 아직 흔들리고 있다. "발판 = 모델 이외의 모든 것"이라는 정의는 너무 넓고 모호하다는 비판이 있다. 둘째, 사실상의 표준(De facto standard)이 아직 없다. 유사한 결합 계층이 "1,000개의 AI 네이티브 기업에서 독립적으로 재발명되고 있다"는 관찰도 있어, 이것이 피할 수 없는 기반이 될지는 알 수 없다. 셋째, 여기서 언급한 수치들은 모두 당사자가 공표한 값이며, 제삼자가 동일한 조건에서 재현한 데이터는 아직 부족하다. 상위 30위에서 상위 5위로 올라간 사례 또한 단일 팀의 예시일 뿐이다. 개별 배율이나 금액을 그대로 믿지는 않는 것이 좋다.
그럼에도 불구하고, 모델을 키우는 것 외에 "발판을 설계한다"라는 레버(Lever)가 등장했다는 사실 자체는 코드나 해외 기업의 실천을 통해 확인할 수 있다. 당신의 에이전트—앞으로 구축할 것을 포함하여—를 한 단계 위에서 묶어준다면 무엇이 편해질까? 하네스 엔지니어링(Harness Engineering)은 그것을 고민하기 위한 입구로서 가치가 있다.
- Databricks - Introducing Omnigent: a meta-harness to combine, control, and share your agents - https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents
- Omnigent 공식 리포지토리 (GitHub, Apache 2.0. 에이전트 정의 YAML · executor.harness · policies의 API 명칭 대조 원천) - https://github.com/omnigent-ai/omnigent
- Omnigent 공식 사이트 - https://omnigent.ai/
- Omnigent - examples/polly/config.yaml (샌드박스의 DENY 방침 = force-push / rm -rf / 의 출처) - https://github.com/omnigent-ai/omnigent/blob/main/examples/polly/config.yaml
- Addy Osmani - Agent harness engineering (Agent = Model + Harness / Terminal Bench에서 Top 30 → Top 5) - https://addyosmani.com/blog/agent-harness-engineering/
- OpenAI - Harness engineering (수기 작성 0줄 · 약 100만 줄 · 1인당 하루 3.5 PR · AGENTS.md / docs / lint) - https://openai.com/index/harness-engineering/
- Fireworks AI - Open-source agents with frontier advisors (Harvey: 18/100 · 368달러 vs 14/100 · 954달러) - https://fireworks.ai/blog/open-source-agents-frontier-advisors
- Martin Fowler - Harness engineering (개념 입도의 흔들림 · behavioral harness) - https://martinfowler.com/articles/harness-engineering.html
- Latent Space (swyx) - It's Meta-Harness Summer (계보와 "1,000개사에서 독립적 재발명" · 표준 부재에 대한 유보) - https://www.latent.space/p/ainews-its-meta-harness-summer
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기