3.3.1 Harness Engineering이란?
AI 에이전트를 신뢰성 있게 운영하기 위한 제약·피드백 루프·컨텍스트·거버넌스 시스템 전체를 설계하는 공학 규율이다. “Agent = Model + Harness” — 모델 선택보다 하네스 설계가 실제 성능을 좌우한다. 업데이트: 2026-03-16
핵심 요약
| 구분 | 내용 |
|---|---|
| 📖 정의 | AI 에이전트가 실제 소프트웨어 개발 수명주기에서 안정적으로 작동하도록 설계된 제약·피드백 루프·문서 구조·린팅 규칙·관찰 가능성 파이프라인의 설계 규율 |
| 🚀 공식화 | 2026년 2월 OpenAI가 “0줄의 수동 코드”로 제품을 출시하며 Harness Engineering이라는 용어를 공식 명명 |
| 💡 핵심 공식 | Agent = Model + Harness — 모델은 추론 엔진, 하네스는 현실 세계와 상호작용하는 방법을 부여하는 시스템 |
| 🎯 대상 | AI 에이전트를 프로덕션에 배포하거나 LLM 앱의 품질을 체계적으로 관리하려는 엔지니어 |
| ⚠️ 주의 | 하네스는 단순한 테스트 도구가 아니다. 에이전트가 작동하는 환경 자체를 설계하는 아키텍처 개념이다 |
문서 탐색
목차
- Harness라는 용어의 기원
- AI 컨텍스트에서의 세 가지 의미
- 왜 필요한가 — 기존 방식의 한계
- 에이전트 시대의 새로운 문제
- Stripe Minions가 보여준 전환점
- 두 갈래의 Harness — 평가 vs 운영
- 흔한 오해 바로잡기
1. Harness라는 용어의 기원
Harness는 원래 말 장구(horse tack)를 뜻한다 — 굴레, 안장, 재갈. 강력하지만 예측 불가능한 동물을 올바른 방향으로 이끄는 장비 일체다.
“말(horse)은 AI 모델이다 — 강력하고 빠르지만, 혼자서는 어디로 가야 할지 모른다. 하네스는 그 힘을 실용적인 방향으로 안내하는 시스템이다.” — Martin Fowler, Harness Engineering (2026-03)
소프트웨어 공학에서는 이미 오래전부터 “테스트 하네스(test harness)“라는 용어가 존재했다 — 테스트를 자동화하기 위한 스캐폴딩 코드 일체. AI 분야의 Harness Engineering은 이 개념을 에이전트 시스템 전체로 확장한 것이다.
2. AI 컨텍스트에서의 세 가지 의미
AI/LLM 분야에서 “Harness”는 문맥에 따라 세 가지 의미로 사용된다.
| 용어 | 정의 | 주요 목적 |
|---|---|---|
| AI Test Harness | LLM 출력을 자동화된 방식으로 실행·측정·채점하는 평가 인프라 | 모델 품질 측정, 벤치마크 |
| Agent Harness | AI 에이전트에게 도구·환경·컨텍스트·제약을 제공하는 실행 스캐폴딩 | 에이전트 신뢰성 확보 |
| Harness Engineering | 에이전트가 대규모로 안정적으로 동작하도록 제약·피드백 루프·거버넌스를 설계하는 공학 규율 | 프로덕션 AI 시스템 설계 |
이 세 가지는 서로 연관되어 있으나 범위가 다르다. Test Harness가 측정 인프라라면, Agent Harness는 실행 환경이고, Harness Engineering은 이 두 가지를 포함하는 시스템 설계 전체 규율이다.
graph TD HE["Harness Engineering<br/>(공학 규율)"] AH["Agent Harness<br/>(실행 환경 설계)"] TH["Test Harness<br/>(평가 인프라)"] HE --> AH HE --> TH AH --> Sandbox["샌드박스 격리"] AH --> Tools["도구 접근 제어"] AH --> Gates["결정론적 게이트"] TH --> Task["태스크 정의"] TH --> Metric["메트릭 측정"] TH --> Runner["자동화 실행"]
3. 왜 필요한가 — 기존 방식의 한계
수동 평가의 한계
AI 앱이 등장하기 전, 소프트웨어는 단위 테스트와 통합 테스트로 품질을 보장했다. 하지만 LLM의 출력은 확률적이고 자연어 형식이라 기존 테스트 방법론이 직접 적용되지 않는다.
| 문제 | 설명 |
|---|---|
| 확장 불가 | 수천 개의 프롬프트를 인간이 일일이 평가할 수 없다 |
| 재현 불가 | 평가자마다 기준이 다르고 결과가 일관되지 않는다 |
| 회귀 감지 불가 | 모델 업데이트 후 품질 저하를 즉각 감지하지 못한다 |
| 비용 | 대규모 A/B 테스트에 막대한 인적 비용이 소요된다 |
단순 실행과 하네스의 차이
❌ 기존 방식: 프롬프트 → 모델 → 출력 확인 (수동)
✅ Harness: 프롬프트 + 데이터셋
↓
모델 (자동 실행)
↓
자동화된 메트릭 채점
↓
결과 집계 → 리포트 → CI/CD 통합
4. 에이전트 시대의 새로운 문제
에이전트가 단순 텍스트 생성을 넘어 도구를 호출하고 코드를 실행하면서 전혀 새로운 평가 문제가 등장했다.
graph TD A["텍스트 생성 시대<br/>(LLM App)"] B["에이전트 시대<br/>(AI Agent)"] A --> A1["출력 = 텍스트<br/>평가 = 문장 비교"] A --> A2["단일 호출<br/>결정론적에 가까움"] B --> B1["출력 = 행동 시퀀스<br/>평가 = 목표 달성 여부"] B --> B2["다단계 루프<br/>비결정적, Pass@k 필요"] B --> B3["도구 호출 정확성<br/>올바른 도구·순서·인자"] B --> B4["환경 의존성<br/>파일·API·DB 격리 필요"]
| 문제 | 구체적 도전 |
|---|---|
| 행동 평가 | 최종 텍스트가 아니라 “도구를 올바르게 선택했는가?”, “올바른 순서로 행동했는가?”를 측정해야 한다 |
| 다단계 추적 | 여러 단계에 걸친 작업에서 어느 단계에서 실패했는지 추적해야 한다 |
| 비결정성 | 같은 입력에도 다른 결과가 나올 수 있어 Pass@k 같은 확률적 메트릭이 필요하다 |
| 환경 의존성 | 파일 시스템, API, 데이터베이스 등 외부 환경을 격리하고 제어해야 한다 |
Pass@k: k번의 시도 중 최소 1번 성공하는 비율. 에이전트 시스템에서는 단일 시도 성공률(Pass@1)만으로 성능을 판단하기 어려워 도입된 메트릭이다.
5. Stripe Minions가 보여준 전환점
2025년 중반, Stripe는 “Minions” 시스템을 공개했다. 주당 1,300개 이상의 PR을 인간 코드 없이 병합하는 이 시스템이 업계에 던진 메시지는 명확했다.
“엔지니어들은 코드를 작성하지 않았다. 그들은 AI가 신뢰성 있게 코드를 작성할 수 있게 해주는 시스템을 설계했다.”
이 시스템이 바로 하네스다. Stripe Minions의 성공 비결은 더 강력한 모델이 아니었다 — 모델이 실수하더라도 시스템이 안전하게 작동하도록 설계된 6개 레이어의 하네스 아키텍처였다.
이 사례 이후 업계에서 하네스 없이 모델만으로는 프로덕션 수준의 안정성을 달성할 수 없다는 인식이 확산됐다.
6. 두 갈래의 Harness — 평가 vs 운영
Harness는 목적에 따라 크게 두 갈래로 나뉜다.
graph TD H["Harness Engineering"] H --> EH["평가 하네스<br/>(Evaluation Harness)"] H --> AH["운영 하네스<br/>(Agent Harness)"] EH --> EH1["모델 벤치마크<br/>lm-evaluation-harness"] EH --> EH2["LLM 앱 평가<br/>DeepEval / RAGAS"] EH --> EH3["프롬프트 테스트<br/>PromptFoo / Braintrust"] EH --> EH4["관찰 가능성<br/>Langfuse / LangSmith"] AH --> AH1["실행 스캐폴딩<br/>Stripe Minions 패턴"] AH --> AH2["샌드박스 격리<br/>Docker / VM"] AH --> AH3["도구 제공<br/>MCP / Toolshed"] AH --> AH4["결정론적 게이트<br/>린터 / 테스트 자동화"]
| 구분 | 평가 하네스 | 운영 하네스 |
|---|---|---|
| 목적 | 모델/앱의 품질 측정 | 에이전트의 신뢰성 있는 실행 |
| 주요 사용자 | ML 엔지니어, 연구자 | 소프트웨어 엔지니어, DevOps |
| 핵심 결과물 | 메트릭, 리포트, 순위 | PR, 배포, 프로덕션 아티팩트 |
| 대표 도구 | lm-eval-harness, DeepEval | Stripe Minions, Claude Agent Teams |
| 작동 시점 | 배포 전 (오프라인 평가) | 배포 중 (온라인 실행) |
7. 흔한 오해 바로잡기
| 오해 | 실제 |
|---|---|
| ”하네스는 단순한 테스트 도구다” | 테스트는 하네스의 일부다. 운영 하네스는 샌드박스 격리, 도구 접근 제어, 관찰 가능성까지 포함하는 아키텍처 레이어다 |
| ”좋은 모델이면 하네스가 필요 없다” | 어떤 모델도 완벽하지 않다. 결정론적 게이트(린터, 테스트)는 모델의 창의성이 실수로 이어지는 것을 방지한다 |
| ”하네스는 에이전트를 느리게 한다” | 하네스는 안전성과 신뢰성을 높여 재작업 비용을 줄인다. Stripe는 하네스 덕분에 주당 1,300+ PR을 인간 개입 없이 처리했다 |
| ”평가 하네스와 운영 하네스는 별개다” | 평가 하네스에서 측정한 메트릭은 운영 하네스 설계를 개선하는 데 사용된다. 둘은 피드백 루프로 연결된다 |
| ”Claude Code에는 이미 내장되어 있다” | Claude Code는 강력한 도구지만, 프로덕션 에이전트 시스템에는 별도의 하네스 설계가 필요하다. CLAUDE.md, 권한 설정, CI/CD 통합이 그 일부다 |