<aside> 📌

Part 1 · Ch04 — Harness Engineering 개론

모델은 우리가 못 바꾼다. 하지만 모델을 둘러싼 환경(맥락·제한·흐름·검증)은 우리가 설계할 수 있다. 그 환경 설계가 Harness Engineering.

한 줄 요약: 같은 Claude인데 결과가 들쭉날쭉한 이유는 모델이 아니라 하네스다. 본 챕터는 구조 → 맥락 → 계획 → 실행 → 검증 → 개선 6축을 한 바퀴 돈다.

</aside>

1. 하네스란 무엇인가 — 모델은 못 바꿔도 환경은 바꾼다

🎯 1-1. 같은 Claude, 다른 결과 — 왜?

<aside> 🎯

같은 모델, 같은 질문인데 어떤 사람은 한 방에 끝내고 어떤 사람은 하루 종일 헤맨다.

차이는 모델이 아니라 모델을 둘러싼 작업 환경 — 무엇을 알려줬고, 어디까지 허용했고, 어떻게 검증하게 했는가.

"말 잘하기"(프롬프트)가 아니라 "일하는 방법 설계하기"(하네스) 가 결과를 가른다.

</aside>

실패했을 때 던지는 질문이 바뀐다:

• ❌ "모델이 부족했나?" (우리가 못 바꾸는 변수)
• ✅ "내 하네스의 어느 축이 약했나?" (우리가 설계하는 변수)

📈 1-2. 증거 — 빠른 테크 회사는 이미 하네스에 투자한다

<aside> 💡

모델 교체로 얻는 5%보다, 하네스 설계로 얻는 15%가 현실적이다.

모델은 Anthropic이 바꾼다. 하네스는 오늘 내가 바꾼다.

</aside>

🔄 1-3. 진화 3단계 — 프롬프트 → 컨텍스트 → 하네스

① 프롬프트 엔지니어링   "이렇게 말해봐"
        ↓               (한 번의 대화를 잘 짜기)
② 컨텍스트 엔지니어링   "이 배경을 알아둬"
        ↓               (필요한 맥락을 미리 깔기)
③ 하네스 엔지니어링     "환경 자체를 설계하자"
                        (맥락·제한·흐름·검증을 포괄하는 작업 환경)

하네스 = 맥락·제한·흐름·검증을 포괄하는 "작업 환경" 전체. 넓게 보면 가드레일·목적별 툴셋, 그리고 개발 밖의 워크플로우(콘텐츠·리서치)까지 포함한다.

🧭 1-4. 챕터의 지도 — 6축 순환 구조