## 한눈에 보기
 
- **무엇인가**: AI 모델 자체를 제외한 모든 제어 구조(컨텍스트 파일, MCP, 훅, CI 게이트 등)를 설계하는 엔지니어링 분야
- **왜 필요한가**: 프롬프트는 '부탁'에 불과하기 때문에, 반복되는 실수를 막기 위해서는 '구조적 강제'가 필요함
- **누가 제안했는가**: 미첼 하시모토(Mitchell Hashimoto), 2026년 2월
- **검증 사례**: OpenAI 엔지니어 3명이 5개월간 서비스 코드 수정 없이 하네스 개선만으로 성능 향상 입증
---
 
## 1. 문제 인식: 왜 AI 비서는 같은 실수를 반복하는가
 
최신 AI 코딩 에이전트를 업무에 도입한 사용자라면 한 번쯤 깊은 좌절을 경험합니다. "분명히 그렇게 하지 말라고 했는데"라며 프롬프트를 수정해도, AI는 얼마 지나지 않아 동일한 실수를 반복하거나 작업 중간에 길을 잃습니다.
 
이것은 단순히 모델 지능의 문제가 아닙니다. 미첼 하시모토는 AI 코딩 에이전트의 반복적 실패를 해결하기 위해 **'하네스 엔지니어링(Harness Engineering)'** 개념을 제시했습니다. AI에게 '부탁'하는 수준을 넘어, 실수가 반복될 수 없는 **시스템적 구조**를 만드는 것이 핵심입니다.
 
---
 
## 2. 하네스란 무엇인가
 
초원을 자유롭게 달리는 야생마는 힘이 대단하지만, 경마장에 그대로 풀어놓으면 본능적으로 울타리를 넘거나 관중석으로 돌진합니다. 이때 필요한 것이 바로 마구(Harness)입니다. 고삐로 방향을 잡고, 안장으로 인간의 의도를 전달하며, 끈으로 트랙 안에서만 달리게 유도합니다.
 
하네스는 모델의 지능을 억누르는 장치가 아닙니다. 오히려 모델의 강력한 에너지를 올바른 방향으로 집중시켜 더 빠르고 정확하게 목표에 도달하게 하는 구조적 제약(Structural Constraint)입니다.
 
> **"모델이 아닌 모든 것이 하네스다."**
 
Claude의 `claude.md` 파일, MCP(Model Context Protocol), 스킬, 훅(Hook) 등 AI 모델 자체를 제외하고 모델을 제어하기 위해 설계된 모든 아키텍처적 요소가 하네스에 해당합니다.
 
---
 
## 3. 프롬프트 엔지니어링과의 차이
 
| 구분 | 프롬프트 엔지니어링 | 하네스 엔지니어링 |
|------|--------------------|--------------------|
| 본질 | 부탁(Request) | 강제(Enforcement) |
| 동작 방식 | AI의 판단에 의존 | 결정적 강제(Deterministic) |
| 실패 시 | AI가 망각·이탈 가능 | 시스템이 다음 단계 차단 |
| 비유 | "안전모를 꼭 써주세요" | 안전모 미착용 시 출입문 자체가 열리지 않음 |
 
프롬프트는 본질적으로 "이렇게 해주세요"라는 부탁입니다. 강제성이 없기 때문에 AI는 언제든 망각하거나 어길 수 있습니다.
 
반면 하네스 엔지니어링은 "이 규칙을 지키지 않으면 다음 단계로 넘어갈 수 없다"는 시스템을 구축합니다. 실수를 AI의 지능이나 판단에 맡기는 것이 아니라, **실수가 불가능한 환경을 설계**하여 성능을 보장합니다.
 
---
 
## 4. 컨텍스트 부패와 기억의 닻
 
AI 작업이 길어질수록 성능이 급격히 떨어지는 현상을 컨텍스트 부패(Context Decay)라고 합니다. AI의 컨텍스트 창(Context Window)에는 한계가 있어, 대화가 길어지면 앞부분의 중요한 지침을 잊어버리게 됩니다.
 
하네스 엔지니어링은 이를 해결하기 위해 `claude.md`나 `agent.md` 같은 컨텍스트 파일을 활용합니다. 이는 휘발되는 채팅 이력과 대비되는 **기억의 닻(Anchor)** 역할을 합니다.
 
- **매 세션의 온보딩**: AI는 매번 새로 출근하는 신입 사원과 같습니다. 세션이 리셋되거나 대화가 길어져 앞 내용을 잊더라도, 하네스 시스템은 AI가 작업을 시작할 때마다 이 파일을 다시 읽도록 강제합니다.
- **지속성 확보**: 프로젝트의 핵심 규칙을 파일로 고정함으로써, 에피소드 중심의 기억이 아닌 **시스템 중심의 지속적 맥락**을 유지하게 합니다.
---
 
## 5. 사례: OpenAI의 검증
 
OpenAI의 엔지니어 3명은 **5개월 동안 실제 서비스 코드는 단 한 줄도 수정하지 않은 채**, 오직 시스템 구조 개선만으로 비약적인 성능 향상을 증명했습니다. 그들이 주목한 명제는 다음과 같습니다.
 
> **"지능(Intelligence)이 아니라 하네스(Harness)가 병목이다."**
 
### OpenAI가 구축한 하네스의 4대 요소
 
1. **`agent.md` 제작** — AI가 반드시 준수해야 할 명시적 업무 지침서 확립
2. **CI 게이트(CI Gate) 구축** — 코드를 저장할 때마다 사람이 아닌 시스템이 자동으로 테스트를 수행하여 무결성 검증
3. **도구 경계 설정** — 에이전트가 접근할 수 있는 권한과 작업 범위를 기계적으로 제한
4. **피드백 루프** — AI가 스스로 결과를 리뷰하고 규칙을 보강하는 자기 교정 구조 설계
### 추가 사례: LangChain
 
LangChain의 사례에 따르면, 모델은 그대로 둔 채 하네스만 개선했을 때 에이전트 성능 순위가 **30위권에서 5위권으로 급상승**했습니다. 이는 AI 성능을 좌우하는 핵심 레버가 모델의 체급이 아닌 **하네스의 정교함**에 있음을 시사합니다.
 
---
 
## 6. 하네스를 지탱하는 3가지 기둥
 
### 6.1. 컨텍스트 파일: 60라인의 법칙
 
1,000페이지짜리 매뉴얼은 AI를 압도하여 오히려 성능을 저하시킵니다. OpenAI는 보편적인 지침을 담은 파일을 **60라인 이하**로 유지할 것을 권장합니다.
 
**점진적 강화(Incremental Hardening)**
 
미첼 하시모토는 처음부터 완벽한 가이드를 쓰지 않습니다. 에이전트가 실패할 때마다 그 원인을 분석하여 '딱 한 줄의 규칙'을 추가합니다. 이를 통해 하네스는 살아있는 교훈의 아카이브가 됩니다.
 
### 6.2. 자동 강제 시스템: 성공은 조용히, 실패는 시끄럽게
 
린터(Linter)와 훅(Hook)을 통해 AI의 결과물을 기계적으로 검사해야 합니다.
 
성공한 테스트 로그 4,000줄을 AI에게 모두 보여주는 것은 컨텍스트 윈도우를 낭비하고 AI를 산만하게 만듭니다.
 
> **"Success is quiet, failure is loud."**
> 성공은 침묵하고, 실패만 소란스럽게 보고하여 AI가 오직 수정이 필요한 부분에만 지능을 집중하도록 해야 합니다.
 
불필요한 성공 로그는 AI의 시야를 가리는 노이즈가 됩니다.
 
### 6.3. 가비지 컬렉션(Garbage Collection)
 
나쁜 코드 패턴이나 낡은 문서가 쌓이면 AI는 이를 학습하여 실수를 복제합니다. 주기적으로 가비지 컬렉션 에이전트를 가동해 불필요한 코드를 청소하고, 실제 코드와 문서 간의 괴리를 바로잡아 시스템의 청결도를 유지해야 합니다.
 
---
 
## 7. 엔지니어 역할의 진화: 코더에서 감독으로
 
이제 엔지니어의 역할은 직접 코드를 한 줄씩 짜는 '선수'에서, AI가 최상의 성과를 낼 수 있는 환경을 설계하는 '감독'으로 변모하고 있습니다. 리처드 파울러(Richard Fowler)는 이를 '엄밀함의 재배치(Relocation of Rigor)'라고 정의했습니다.
 
- **과거의 엄밀함**: 코드의 구문(Syntax)을 정확히 맞추는 것
- **현재의 엄밀함**: 에이전트가 올바르게 동작할 수밖에 없는 **시스템적 제약(Constraints)** 설계
---
 
## 8. 자가 진단 질문
 
AI 에이전트가 기대만큼 성능을 내지 못한다면, 더 비싼 모델로 바꾸기 전에 스스로에게 질문해 보아야 합니다.
 
> **"나는 AI에게 성능을 내달라고 '부탁'하고 있는가, 아니면 성능이 나올 수밖에 없는 '하네스'를 설계했는가?"**
 
---
 
## 핵심 용어 정리
 
| 용어 | 의미 |
|------|------|
| **하네스(Harness)** | 모델 자체를 제외한 모든 제어 구조 |
| **컨텍스트 부패(Context Decay)** | 작업 길이에 비례해 AI 성능이 저하되는 현상 |
| **결정적 강제(Deterministic Enforcement)** | 시스템 구조를 통해 규칙 준수를 강제하는 방식 |
| **점진적 강화(Incremental Hardening)** | 실패 사례를 분석해 한 줄씩 규칙을 누적하는 방법론 |
| **엄밀함의 재배치(Relocation of Rigor)** | 코드 구문에서 시스템 제약 설계로 엔지니어링 초점이 이동하는 현상 |
 
---
 
## 참고 인물 및 출처
 
- **미첼 하시모토(Mitchell Hashimoto)**: 'Harness Engineering' 개념 제안 (2026년 2월)
- **OpenAI 엔지니어링 팀**: 하네스 개선만으로 성능 향상 검증
- **리처드 파울러(Richard Fowler)**: '엄밀함의 재배치' 개념 제시
- **LangChain**: 모델 변경 없이 하네스 개선만으로 에이전트 성능 순위 상승 사례

AI 에이전트의 성능 병목은 모델의 지능이 아니라, 모델을 둘러싼 구조(Harness)에 있다.

하네스 엔지니어링(Harness Engineering)

코드 리뷰

착수보고란 무엇인가