2025년 8월, OpenAI의 엔지니어 3명이 빈 저장소 하나를 만들었다. 5개월 뒤, 그 저장소에는 약 100만 줄의 코드가 쌓여 있었다. 수동으로 작성된 코드는 0줄. 머지된 Pull Request는 약 1,500개. 엔지니어 1인당 하루 평균 3.5개의 PR을 처리한 셈이다.
이것을 가능하게 한 것은 더 똑똑한 모델이 아니었다. 모델 "주변"의 모든 것 — 도구 접근, 오류 복구, 검증 루프, 세션 간 상태 관리 — 을 체계적으로 설계한 결과였다. OpenAI는 이 기술에 이름을 붙였다. Harness Engineering(하네스 엔지니어링).
왜 지금 Harness Engineering인가
AI와 함께 일하는 방식은 세 단계를 거쳐 진화했다. 2022~2024년의 프롬프트 엔지니어링, 2025년의 Context Engineering, 그리고 2026년의 Harness Engineering. 각 단계는 이전을 대체하는 것이 아니라 포함하고 확장한다.
AI 개발 방법론의 세 시대
| Prompt Engineering | Context Engineering | Harness Engineering | |
|---|---|---|---|
| 시기 | 2022–2024 | 2025 | 2026– |
| 핵심 질문 | 모델에 뭘 물을까? | 모델에 뭘 보내줄까? | 모델 주변을 어떻게 설계할까? |
| 초점 | 단일 입력 최적화 | 맥락 조립·큐레이션 | 도구·가드레일·피드백 루프 전체 |
| 비유 | 질문을 잘 하는 기술 | 참고자료를 잘 정리하는 기술 | 사무실 전체를 설계하는 기술 |
| 대표 기법 | Few-shot, CoT | CLAUDE.md, RAG, 린터 규칙 | 체크포인트, Sub-agent, 관찰성 |
전환의 근거는 분명하다. LangChain은 2026년 3월, 동일한 모델(Claude 3.5 Sonnet)을 유지한 채 harness만 변경하여 코딩 벤치마크 성능을 13.7%p 향상시켰다. 모델을 바꾸지 않고도 Top 30에서 Top 5로 뛰어오른 것이다. 이것은 예외적 사례가 아니다. 동일한 모델을 사용하는 두 팀이 harness 품질만으로 작업 완료율에서 40%p 차이를 보인다는 분석도 있다.
한국어로 된 Harness Engineering 콘텐츠는 아직 3건에 불과하다. 영어권에서는 Anthropic, OpenAI, Martin Fowler가 이미 핵심 개념을 정립했고, 프롬프트 엔지니어링을 넘어선 다음 단계로 합의가 이루어지고 있다. 이전에 AI Agent와 챗봇의 차이를 다룬 바 있는데, harness는 그 Agent가 실제로 작동하게 만드는 층이다.
Harness Engineering이란 무엇인가
Anthropic의 정의를 빌리면, Harness Engineering은 "사용자의 요청과 에이전트의 최종 출력 사이에 있는 모든 것, 언어 모델 자체를 제외한 모든 것"을 설계하는 기술이다. 도구 연결, 오류 복구, 비용 제어, 관찰성 계측, 검증 루프 — 이 모든 것이 harness에 속한다.
"Harness"의 어원은 마구(馬具)다. 말의 힘을 방향과 속도로 전환하는 장비처럼, AI 에이전트의 지능을 생산적인 방향으로 이끄는 모든 장치를 뜻한다. LangChain은 이를 공식으로 요약했다: Agent = Model + Harness.
프로덕션에서 작동하는 Harness
이론이 아닌 실제 결과를 낸 사례 세 가지를 본다. 공통점은 모델을 교체한 것이 아니라 모델 "주변"을 설계한 것이다.
OpenAI Codex: 100만 줄의 자동 생성 코드
~100만 줄
0줄
3.5 PRs/일/인
OpenAI는 AGENTS.md 파일에 아키텍처 명세와 빌드 커맨드를 정의하고, 컨테이너화된 재현 가능 환경에서 에이전트를 실행했다. CI 통합 검증이 아키텍처 경계를 강제하여 에이전트가 설계를 벗어나는 것을 방지했다. 핵심은 "더 좋은 모델"이 아니라 "더 좋은 하네스"였다.
출처: OpenAI, "Harness engineering: leveraging Codex in an agent-first world" (2026.02) 원문
Anthropic Claude Code: Initializer + Coder 아키텍처
Anthropic은 장시간 에이전트의 핵심 과제를 정면으로 다뤘다. 컨텍스트 윈도우가 제한되어 있고, 복잡한 프로젝트는 한 세션에 끝나지 않는다. 새 세션은 이전 기억이 없다. 이 간극을 어떻게 메울 것인가?
해법은 두 단계 harness였다. 첫 세션에서 Initializer 에이전트가 프로젝트 구조, 기능 목록, 진행 추적 파일(claude-progress.txt)을 생성한다. 이후 세션에서 Coder 에이전트가 이 파일을 읽고 작업을 이어간다. 정확히 같은 모델이지만, 초기 프롬프트가 다르다.
핵심 통찰은 에이전트가 새로운 컨텍스트 윈도우에서 작업 상태를 빠르게 파악할 수 있게 하는 것이었다. claude-progress.txt 파일과 git 히스토리의 조합으로 이를 달성했다.
— Anthropic Engineering, Effective Harnesses for Long-Running Agents
이 아키텍처에서 MCP는 도구 연결 계층의 역할을 한다. 에이전트가 사내 시스템과 통신하려면 표준화된 인터페이스가 필요하고, 그것이 바로 MCP다.
Stripe Minions: 500개 도구와 격리된 실행 환경
Stripe는 자사 AI 에이전트 "Minions"에 가장 정교한 harness를 구축했다. Toolshed라는 중앙 MCP 서버를 통해 약 500개의 내부 도구를 노출하되, 각 에이전트에는 작업에 필요한 약 15개만 선별 제공한다.
모든 에이전트는 "devbox"라는 격리된 AWS EC2 인스턴스에서 실행된다. devbox는 Stripe의 전체 소스 트리, 캐시, 코드 생성 서비스가 사전 로드되어 있지만, 프로덕션 서비스와 실제 사용자 데이터에는 접근할 수 없다. 이 구조로 Stripe는 주당 1,300개 이상의 PR을 자동 처리하고 있다.
출처: Awesome Agents, "Stripe Minions: 1,300 Pull Requests Per Week" (2026.02) 원문
국내에서는 QANDA AX가 유사한 패턴을 적용하고 있다. 기획, 디자인, 개발, 데이터, 마케팅, 인프라, 콘텐츠 7개 도메인에 걸쳐 60개 이상의 AI Skills를 Wizard라는 오케스트레이션 시스템으로 운영한다. Cast(기획)에서 Spell(구현)까지 다단계 워크플로우를 관리하며, 도메인별 MCP 서버를 분리하여 에이전트에게 필요한 도구만 선별 제공하는 Stripe의 surgical subset 패턴을 따른다.
Harness를 바꾸면 성능이 올라간다: 데이터가 말하는 것
"모델이 더 좋아지면 다 해결된다"는 가설은 이미 깨졌다. 2026년 현재, 최고의 AI 에이전트를 만드는 기업들은 하나같이 동일한 결론에 도달했다.Foundation 모델은 commodity가 되고 있다. 모델을 감싸는 인프라 — 도구, 맥락 관리, 피드백 루프, 오케스트레이션 — 가 성공과 실패를 가른다.
같은 harness에서 모델을 업그레이드하면 성능 개선은 점진적이다. 도구 라우팅이 잘못되어 있으면 어떤 모델을 넣어도 실패한다.
LangChain: 모델 동일, harness만 변경 → 13.7%p 향상. 계획, 자기검증, 로컬 컨텍스트 주입 세 가지가 핵심이었다. Top 30 → Top 5.
이 패턴은 LangChain만의 것이 아니다. Anthropic, OpenAI, Cursor, Cognition(Devin), Stripe 모두 같은 아키텍처 패턴에 수렴하고 있다. Aaron Levie(Box CEO)는 이를 "지금 agent harness의 force multiplier는 미친 수준"이라고 표현했다.
Harness Engineering의 한계와 함정
Harness Engineering이 만능은 아니다. 잘못 적용하면 오히려 시스템을 더 복잡하고 취약하게 만든다.
- 과잉 엔지니어링 위험 — 아직 에이전트가 실패하지도 않은 곳에 가드레일을 미리 쌓으면, 유지보수 부담만 늘어난다. OpenAI는 "에이전트가 실제로 실패할 때만 구성을 추가하라"고 권고한다.
- 관찰성 부채(Observability Debt) — harness 자체가 블랙박스가 되면, 에이전트의 의사결정을 추적할 수 없다. 모든 도구 호출과 분기점을 로깅하는 것이 전제 조건이다.
- 체인 신뢰성 붕괴 — 20단계 체인에서 각 단계 성공률이 95%라 해도, 전체 완료율은 0.95^20 = 36%로 급락한다. 오류 복구 없이 단계를 늘리면 전체 시스템의 신뢰성이 기하급수적으로 떨어진다.
- 비용 증폭 — 도구 호출, 자기검증 루프, Sub-agent 위임은 모두 추가 API 호출을 의미한다. 한 사례에서 문서 처리 에이전트의 retry 정책 결함으로 340회 재시도가 발생해, 6시간 만에 $2,400가 과금되었다(평소 일일 $180). 비용 상한과 이상 탐지가 harness 수준에서 필수적인 이유다.
- 비결정론적 테스트 — 동일 입력에 다른 출력을 내는 에이전트 파이프라인은 전통적 단위 테스트로 검증할 수 없다. 새로운 테스트 프레임워크(평가 기반 테스트)가 필요하다.
- 인재 부족 — Harness Engineering은 전통적 소프트웨어 엔지니어링, AI 도메인 지식, 관찰성 전문성이 동시에 필요한 분야다. 이 교집합에 있는 인력은 아직 시장에 충분하지 않다.
지금 시작하는 Harness Engineering
에이전트를 프로덕션에 배포하려는 팀이 가장 먼저 할 일은 "현재 우리의 harness는 어떤 상태인가?"를 진단하는 것이다.
harness의 첫 번째 층은 도구 연결이다.MCP는 이 도구 연결을 표준화한다. 그리고 harness를 설계하려면 팀이 에이전트의 작동 원리를 이해해야 한다. 프롬프트 엔지니어링, Context Engineering, 도구 설계의 기초 없이는 harness를 진단할 수도, 개선할 수도 없다.
자주 묻는 질문
Harness Engineering과 MLOps는 어떻게 다른가요?
MLOps는 모델의 학습·배포·모니터링 파이프라인을 관리합니다. Harness Engineering은 이미 배포된 LLM이 실제로 일하게 만드는 실행 환경 — 도구 연결, 오류 복구, 세션 관리, 가드레일 — 을 설계합니다. MLOps가 '모델을 프로덕션에 올리는 기술'이라면, Harness Engineering은 '올라간 모델이 안정적으로 작동하게 만드는 기술'입니다.
어디서부터 시작하면 좋을까요?
에이전트가 가장 자주 실패하는 지점을 먼저 찾으세요. 대부분 도구 호출 오류, 무한 루프, 컨텍스트 부족이 원인입니다. 이 세 가지에 가드레일을 추가하는 것이 첫 번째 단계이고, 그 다음은 모든 에이전트 행동을 추적할 수 있는 로깅(관찰성)을 확보하는 것입니다. 보이지 않는 시스템은 개선할 수 없습니다.
AI 에이전트를 프로덕션에 배포하고 싶으신가요?
QANDA AX는 60+ 내부 AI Skills 운영 경험으로 Harness Engineering 설계부터 구축까지 지원합니다.
Harness 설계 상담 신청하기