하네스 엔지니어링이란?

이 글에서 다루는 내용

2026년 들어 AI 업계에서 가장 빠르게 굳어진 용어 중 하나가 하네스 엔지니어링(Harness Engineering)입니다. 모델이 점점 강해지는데도 상용 에이전트의 약 88%가 프로덕션까지 못 간다는 조사가 반복되면서, 문제의 축이 "더 좋은 모델"에서 "더 좋은 하네스"로 이동했습니다. 이 글에서는 하네스 엔지니어링의 정의, 부상 배경, 핵심 구성 요소, 그리고 Anthropic이 공개한 장시간 실행 에이전트용 하네스 설계를 순서대로 정리합니다. 설치 가이드가 아니라 개념을 먼저 잡고 싶은 분들을 위한 입문 글입니다.

---

1. 한 문장 정의

1-1. Agent = Model + Harness

가장 간결한 정의는 이 공식 하나입니다. 에이전트는 모델과 하네스의 합이며, 하네스는 "에이전트에서 모델을 제외한 모든 것"을 가리킵니다. Parallel.ai의 표현을 빌리면 "모델은 지능을 제공하고, 하네스는 손과 눈과 기억과 안전 경계를 제공한다"가 됩니다. 구체적으로는 오케스트레이션 루프, 도구 호출, 메모리, 컨텍스트 관리, 상태 저장, 오류 복구, 가드레일 같은 구성 요소 전부를 포괄합니다.

1-2. 프롬프트 엔지니어링과의 관계

프롬프트 엔지니어링이 "모델에게 한 번 무엇을 어떻게 말할 것인가"에 집중한다면, 하네스 엔지니어링은 "모델을 여러 턴·여러 도구·여러 세션에 걸쳐 어떻게 꿰어 두는가"를 다룹니다. 프롬프트 엔지니어링은 하네스 엔지니어링의 부분집합에 가깝습니다. 하네스 엔지니어링은 여기에 컨텍스트 엔지니어링(context engineering)과 시스템 설계 관점을 덧붙인 상위 개념입니다.

ℹ️ 정리하면, 프롬프트 엔지니어링이 "문장"을 설계하는 일이라면 하네스 엔지니어링은 "일하는 방식 전체"를 설계하는 일입니다.

---

2. 왜 지금 하네스 엔지니어링인가

2-1. 모델이 강해져도 프로덕션 실패율이 줄지 않았다

2026년 현재, AI 에이전트 프로젝트의 약 88%가 프로덕션에 도달하지 못한다는 수치가 업계에서 반복 인용됩니다. 모델 성능은 빠르게 향상되는데 프로덕션 안착 비율은 비슷한 범위에 머뭅니다. 업계는 이를 "모델 문제"가 아니라 주변 시스템 설계 문제로 재정의하기 시작했고, 그 명칭이 하네스 엔지니어링으로 굳어졌습니다.

2-2. 장시간 작업의 컨텍스트 한계

Anthropic은 장시간 실행 에이전트의 본질적 난이도를 이렇게 요약합니다.

💡 "장시간 실행 에이전트의 근본 과제는, 불연속적인 세션으로 쪼개서 일해야 하고, 각 세션은 이전 작업을 전혀 기억하지 못한 채 시작된다는 점이다." (Anthropic, 2026)

몇 시간에서 며칠이 걸리는 작업은 컨텍스트 윈도우 하나에 담기지 않습니다. 하네스가 허술하면 모델은 결국 두 가지 실패 중 하나로 빠집니다. 전부를 한 번에 끝내려고 하다가(one-shot) 범위가 폭주하거나, 애매한 진행 상태에서 완료를 선언하고 멈춥니다. 하네스 엔지니어링은 이 "교대 근무" 문제를 해결하기 위해 인간 엔지니어링 팀의 인계·로그·체크리스트 관행을 에이전트 구조에 이식합니다.

2-3. 모델이 똑똑해져도 경계만 이동한다

흥미로운 관찰 하나는, 모델 버전이 올라갈수록 하네스에서 명시적으로 붙여두었던 단계가 하나씩 사라진다는 점입니다. Anthropic은 새 Claude 버전이 나올 때마다 Claude Code의 하네스에서 planning 단계를 직접 삭제해 왔다고 밝혔습니다. 모델이 내재화한 능력은 빼되, 새로 드러난 다른 빈틈에 또 다른 하네스 조합이 생긴다는 뜻입니다. "공간은 줄어들지 않고 이동한다"는 말은 하네스 엔지니어의 할 일이 당분간 사라지지 않는다는 신호이기도 합니다.

---

3. 하네스의 핵심 구성 요소

여러 프로바이더의 정의를 교차 검증하면 반복되는 구성 요소가 드러납니다. 아래 다섯 개가 2026년 시점의 표준 항목입니다.

구성 요소	담당 역할	대표 기술
컨텍스트 관리	토큰 예산 내에서 필요한 정보만 유지	compaction, 요약, 상태 파일
도구 오케스트레이션	파일·셸·브라우저·API 호출을 모델에 노출	MCP, function calling, 플러그인
검증 루프	결과물을 실행·테스트로 재확인	e2e 자동화, 별도 평가자 에이전트
메모리와 상태 보존	세션 간 맥락·학습을 이어붙임	진행 로그, 벡터 메모리, git 저장소
가드레일	권한 경계·안전 규칙·오류 복구	권한 샌드박스, 정책 필터, 재시도

3-1. 컨텍스트 관리와 컴팩션

가장 먼저 부딪히는 문제입니다. 모델의 컨텍스트 윈도우는 유한한데, 긴 과제에서는 과거 대화·도구 출력·코드가 무한히 쌓입니다. Claude Agent SDK 같은 공개 하네스는 compaction이라고 불리는 요약 단계로 과거 맥락을 압축해 다시 투입합니다. 이때 무엇을 버리고 무엇을 상태 파일로 내릴지가 하네스 설계의 핵심 판단 중 하나가 됩니다.

3-2. 도구 오케스트레이션

모델은 기본적으로 토큰을 출력할 뿐입니다. 그 토큰이 파일을 읽거나 테스트를 돌리려면 외부 도구 스펙을 모델에 보여주고, 모델이 낸 JSON을 도구 실행으로 변환해 다시 모델에 결과를 돌려주는 루프가 필요합니다. MCP(Model Context Protocol)는 이 도구 연결의 표준을 제안하고 있고, Claude Agent SDK나 OpenClaw 같은 프로젝트는 이를 하네스 레벨에서 추상화합니다.

3-3. 검증 루프

모델은 스스로 코드를 썼다고 "완료"를 선언하는 경향이 강합니다. 하네스는 여기에 실행 기반 검증을 끼워 넣습니다. Anthropic의 장시간 실행 하네스 사례에서는 브라우저 자동화로 실제 UI를 띄워 기능 리스트를 하나씩 확인하는 절차가 핵심 구성 요소로 들어가 있습니다. 평가자(evaluator)를 별도의 에이전트로 분리하는 흐름도 일반화되고 있습니다.

3-4. 메모리와 아티팩트 흐름

세션 간 인계를 위해 하네스는 대화만 기억하는 것이 아니라 구조화된 아티팩트를 남깁니다. git 저장소, 진행 로그 파일, quickstart 문서, 200개 이상으로 쪼개진 기능 목록 같은 형태가 대표적입니다. 다음 세션이 시작될 때는 "Getting up to speed" 전용 프롬프트가 이 아티팩트를 읽혀 모델을 빠르게 복귀시킵니다.

---

4. Anthropic의 실전 하네스 설계

4-1. Initializer + Coding 2단 분리

Anthropic은 장시간 실행 하네스를 설명하면서 두 개의 에이전트 역할을 명시적으로 구분합니다.

• Initializer Agent: 한 번만 실행되며, 프로젝트 뼈대(git, 진행 로그, quickstart)를 세우고 수백 개 단위의 세부 기능 목록을 작성합니다.
• Coding Agent: 이후 모든 세션에서 한 번에 한 기능씩 점진적으로 진행하고, 결과와 상태를 구조화된 형태로 남깁니다.

이 분리는 "모든 걸 한 번에 끝내려 드는 모델"의 성향을 물리적으로 막는 장치이기도 합니다.

4-2. 3-에이전트 하네스

2026년 4월 InfoQ에 소개된 Anthropic의 풀스택 개발용 하네스는 planning · generation · evaluation 세 역할을 별도 에이전트로 쪼갭니다. 한 에이전트가 계획을 세우면, 다른 에이전트가 구현하고, 세 번째 에이전트가 결과를 뜯어봅니다. 이렇게 분리하면 한 모델 인스턴스가 스스로의 결과를 관대하게 평가하는 편향이 줄어듭니다.

4-3. "모델이 잘해진 단계는 삭제한다"

Anthropic의 하네스 설계 원칙 중 가장 자주 인용되는 대목입니다. Claude 모델이 자체적으로 계획을 잘 세우게 될 때마다, Claude Code 하네스에서는 별도 planning 단계가 제거됐습니다. 하네스는 "모델이 아직 못하는 일"을 대신 채우는 스캐폴드이지, 영원한 고정 구조가 아니라는 시각입니다. 따라서 하네스 엔지니어는 모델 업데이트 주기와 함께 자기 하네스를 축소·재조립하는 일에 익숙해져야 합니다.

💡 재미있는 부분은, Anthropic이 오히려 "하네스를 지우라"고 말하는 쪽이라는 점입니다. 더 정교한 래퍼를 쌓는 대신 필요 없어진 단계를 도려내는 것이 더 어려운 작업으로 취급됩니다.

---

5. 어디서부터 시작해야 할까

개발자가 실제로 하네스 엔지니어링을 손에 익히려면 아래 경로가 현실적입니다.

1. 공개 하네스를 써 본다. Claude Agent SDK, Claude Code, AutoHarness, OpenHarness 같은 도구가 이미 하네스 구조를 노출하고 있습니다. 설정 파일과 루프 코드를 따라 읽는 것만으로도 감이 잡힙니다.
2. 작은 자체 하네스를 만들어 본다. MCP 서버 1~2개와 function calling만으로도 "도구 호출 → 검증 → 반영" 루프를 수작업으로 구성해 볼 수 있습니다.
3. 평가(evals)를 먼저 세운다. Anthropic은 "하네스를 설계하기 전에 평가부터 만들라"고 반복 강조합니다. 내 에이전트가 실제로 잘하는지 재는 지표가 없으면 하네스 수정은 추측이 됩니다.
4. 한 축씩 교체하며 A/B한다. 프롬프트, 컴팩션 방식, 도구 세트, 검증 방식 중 한 번에 한 가지만 바꿉니다. 하네스 변경은 조합 폭발이 크기 때문에 동시 변경은 원인 추적을 사실상 불가능하게 만듭니다.

⚠️ 하네스 설계는 "더 많은 기능"보다 "더 좁은 역할"이 안정적입니다. 특히 실행 권한과 자율성 수준은 처음부터 보수적으로 잡고, 신뢰가 쌓일수록 풀어주는 편이 경험상 훨씬 안전합니다.

---

트러블슈팅 · 자주 헷갈리는 지점

문제 1: 하네스 엔지니어링과 MLOps는 같은 말인가

다릅니다. MLOps는 모델의 학습·배포·모니터링 파이프라인을 다루고, 하네스 엔지니어링은 이미 배포된 모델 위에서 추론 시점의 에이전트 행동을 설계하는 계층입니다. 두 영역은 겹칠 수 있지만, 대상 레이어가 다릅니다.

문제 2: 대화형 챗봇에도 하네스 엔지니어링이 필요한가

엄밀한 의미에서는 필요 없을 수 있습니다. 단발성 Q&A 챗봇은 프롬프트 엔지니어링과 간단한 함수 호출 정도로 충분합니다. 하네스 엔지니어링이 꼭 필요한 지점은 "모델이 여러 도구를 이어 쓰며 사람이 보지 않는 동안에도 진전해야 하는" 자율 에이전트 영역입니다.

문제 3: 하네스를 만들면 모델 교체가 더 어렵지 않은가

그 반대에 가깝습니다. 잘 설계된 하네스는 모델을 프로바이더 단위로 교체 가능한 부품으로 만들어 줍니다. 이 글의 OpenClaw × Ollama 연동 편처럼, 추론 백엔드를 URL 몇 줄로 갈아끼울 수 있는 구조가 되기 때문입니다.

---

마무리

하네스 엔지니어링은 "모델을 더 잘 쓰는 법"이라기보다 "모델 바깥을 어떻게 짜야 모델이 실제로 일하는가"를 다루는 새로운 엔지니어링 규율입니다. 2026년 현재 AI 팀에서 요구되는 역량은 "프롬프트 잘 쓰는 사람"에서 "컨텍스트·도구·검증·메모리·가드레일을 한 시스템으로 엮을 줄 아는 사람"으로 이동하고 있습니다.

 

• Anthropic Engineering: Effective harnesses for long-running agents
• Anthropic Engineering: Harness design for long-running application development
• Anthropic Engineering: Demystifying evals for AI agents
• InfoQ: Anthropic Designs Three-Agent Harness
• Parallel.ai: What is an agent harness
• Awesome 모음: awesome-harness-engineering