하네스는 목줄이 아니라 실행 구조다
하네스를 AI에게 목줄을 채우는 가드레일로 이해하는 경우가 많다. Anthropic과 OpenAI가 공개한 사례를 근거로, 하네스가 실제로 무엇을 가리키는 말인지 정리했다.
하네스는 단순히 AI에게 목줄을 채우는 가드레일만을 뜻하지 않습니다. 오히려 모델이 실제 업무를 수행할 수 있도록 둘러싼 실행 구조 전체에 가깝습니다.
이 개념을 이해하기 위해 Anthropic과 OpenAI의 사례를 다시 떠올려 보면 좋겠습니다.
Anthropic 사례
2025년 11월 Anthropic은 AI의 장기 실행을 위해 하네스가 효과적이라는 글을 블로그에 올렸습니다.
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
이 글은 장기 실행에서 발생하는 에이전트의 문제점과 해결책을 제시했습니다. 그리고 모델로 모든 것이 해결되는 것이 아니라, 모델보다 그 작업 운영체계(하네스)가 필요함을 강조합니다.
문제점
- 컨텍스트가 끊기면 “기억 없는 새 작업자”가 된다
- Compaction만으로는 부족하다
- 에이전트가 한 번에 너무 많이 하려 한다
- 너무 빨리 “다 끝났다”고 판단한다
- 기능 완료를 제대로 검증하지 않는다
- 작업 환경이 더러워진 채 다음 세션으로 넘어간다
해결책
- 초기화 에이전트와 코딩 에이전트를 분리한다
- 기능 목록을 JSON으로 만든다
- 한 세션에 한 기능만 처리한다
- git과 progress file을 인계 장치로 쓴다
init.sh로 실행 방법을 표준화한다- 세션 시작 루틴을 고정한다
그리고 2026년 3월, 검증과 테스트를 강조한 두 번째 블로그 글이 올라옵니다.
https://www.anthropic.com/engineering/harness-design-long-running-apps
문제점
- 긴 작업에서 에이전트가 점점 일관성을 잃는다
- 에이전트가 자기가 만든 결과물을 스스로 평가하면 대체로 후하게 본다
- 단일 에이전트가 만든 앱은 보기에는 좋아도 실제 기능이 깨져 있다
- “완료”의 정의가 불명확하다
- QA 에이전트도 기본 상태로는 부족하다
- 하네스는 비싸고 느리다
해결책
- Planner–Generator–Evaluator 세 역할로 나눈다
- 주관적 품질도 평가 기준으로 쪼개야 한다
- Generator와 Evaluator를 분리해야 한다
- Playwright MCP 등을 이용해 실제 사용처럼 테스트해야 한다
- Sprint contract가 중요하다
- 모델이 좋아지면 장기 작업 능력이 좋아지므로 하네스를 다시 검증해 줄여야 한다
- evaluator가 모든 상황에 무조건 필요한 것은 아니다
OpenAI 사례
OpenAI 팀은 5개월 동안 사람이 직접 코드 라인을 쓰지 않고 Codex로 내부 베타 제품을 만들었고, 이 과정에서 엔지니어의 역할이 “코드 작성자”에서 하네스·문서·도구·피드백 루프 설계자로 바뀌었다고 설명합니다.
https://openai.com/ko-KR/index/harness-engineering/
문제점
- 에이전트 성능보다 “환경 부재”가 병목이다
- 사람의 QA와 주의력이 병목이 된다
- 거대한 AGENTS.md는 실패한다
- Google Docs, Slack 대화, 사람 머릿속의 암묵지 등 에이전트는 “볼 수 없는 것”을 모른다
- 문서만으로는 일관성을 유지할 수 없다
- 처리량이 커지면 기존 개발 규범이 흔들린다
- 자율성이 커질수록 엔트로피도 커진다
해결책
- 사람은 직접 코드를 쓰기보다, 작업을 정의하고, 기준을 만들고, 에이전트가 실행·검증·리뷰·수정할 수 있는 루프를 설계한다
- 리포지터리는 에이전트의 “기록 시스템”이어야 한다
- 계획도 코드처럼 버전 관리한다
- 에이전트가 앱을 직접 읽고 조작할 수 있어야 한다
- 제약은 프롬프트보다 강해야 한다
- 리뷰 코멘트, 리팩터링 PR, 사용자 버그에서 얻은 사람의 판단은 일회성 피드백으로 끝내면 안 된다
- 에이전트 자율성은 점진적으로 키운다
그래서 하네스에는 무엇이 들어가나
하네스를 이루는 요소들은 다양하게 존재합니다. 그래서 모델을 제외한, 모델을 감싼 모든 것을 지칭하기도 합니다. 이 관점에서 보면 하네스는 다음을 모두 포함할 수 있습니다.
- 에이전트 루프
- 도구 연결
- MCP
- 권한 제어
- 컨텍스트 관리
- 메모리 관리
- 작업 분해
- 역할 분리
- 체크리스트
- 테스트와 검증
- 복구와 롤백
- 작업 인계 구조
- 사람 승인 절차
최소 단위의 하네스 세 가지
다만 이 모든 것을 한 번에 갖추기는 어렵습니다. 그래서 제가 강의에서 강조한 것은, 현장에서 빠르게 적용 가능한 최소 단위의 하네스였습니다.
제가 우선 중요하게 보는 것은 세 가지입니다.
첫째, 에이전트의 역할 설계. “너는 무엇을 판단하고, 무엇을 하지 말아야 하는가”를 명확히 정하는 것입니다.
둘째, 에이전트가 사용하는 스킬의 정의. 반복적으로 쓰는 절차, 체크리스트, 판단 기준, 산출물 형식을 스킬로 만들어두는 것입니다.
셋째, 여러 에이전트나 작업 단계를 조율하는 오케스트레이터. 기획, 실행, 검토, 수정, 보고를 한 모델에게 한꺼번에 맡기는 것이 아니라, 역할을 나누고 다시 합치는 구조입니다.
이 세 가지만 갖춰도 꽤 실용적인 수준의 하네스를 만들 수 있습니다. 또한 에이전트와 스킬의 원칙, 프로세스 정의, 체크리스트를 통해 모델을 자연스럽게 제어할 수 있고, 우리가 요청한 의도와 방향에 더 가까운 결과를 얻을 수 있습니다.
멀티 에이전트 설계는 단순히 “AI 팀원을 많이 둔다”는 의미만이 아닙니다. 컨텍스트를 역할별로 분리하고, 한 에이전트가 모든 것을 떠안으면서 생기는 혼선(Context Rot)을 줄이는 효과도 있습니다.
