하네스 엔지니어링이란 무엇인가 — AI 에이전트의 고삐를 설계하는 시대
이 시리즈의 1편에서 프롬프트 엔지니어링의 퇴장을 이야기했다. CLI 기반 도구가 등장하면서 정교한 프롬프트를 수작업으로 다듬는 행위의 가치가 줄어들고 있다고.
그런데 2026년 들어, 프롬프트 엔지니어링을 대체한 것이 단순히 "더 나은 도구"가 아니라는 걸 깨닫게 됐다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 그리고 지금, 하네스 엔지니어링이라는 완전히 새로운 패러다임이 자리잡고 있다.
이 글에서는 하네스 엔지니어링이 무엇인지, 왜 지금 이것이 중요한지, 그리고 어떤 구성 요소로 이루어져 있는지를 정리한다.
말에게 씌우는 마구, 에이전트에게 씌우는 하네스
하네스(Harness)는 원래 말에게 장착하는 마구를 뜻한다. 고삐, 안장, 등자 — 말의 강력한 힘을 억누르는 것이 아니라, 올바른 방향으로 전달하기 위한 장비다.
AI에서 하네스는 정확히 같은 의미다. AI 에이전트의 강력한 능력을 올바른 방향으로 제어하고 전달하는 외부 시스템 전체.
공식으로 쓰면 이렇다.
Agent = Model + Harness
모델이 아닌 모든 것이 하네스다. 시스템 프롬프트, 도구 정의, 샌드박스 환경, 오케스트레이션 로직, 피드백 루프, 메모리 관리, 미들웨어 훅. 에이전트를 감싸는 이 모든 것을 설계하는 행위가 하네스 엔지니어링이다.
왜 모델만으로는 부족한가
LLM은 본질적으로 이런 한계를 가진다.
- 세션 간 상태를 유지하지 못한다
- 코드를 직접 실행하지 못한다
- 실시간 정보에 접근하지 못한다
- 자기가 만든 결과물을 스스로 검증하지 못한다
ChatGPT와의 "대화"도 사실 기본적인 하네스의 산물이다. 이전 메시지를 추적하고, while 루프를 돌리는 것. 그 자체가 원시적인 하네스다.
Anthropic은 이 한계를 직접 경험했다. Claude Opus 4.5에게 "claude.ai의 클론을 만들어라"라는 고수준 지시를 주었을 때, 반복적으로 같은 실패 패턴이 나타났다.
- 컨텍스트 윈도우가 차면서 구현이 미완성으로 끝남
- 컨텍스트 한계에 가까워지면 "컨텍스트 불안(context anxiety)"이 발생해 조기에 작업을 마무리하려 함
- 자기 작업을 스스로 평가하면, 형편없는 결과에도 자신감 있게 칭찬함
이건 모델의 지능 문제가 아니다. 인수인계 문서, 진행 상황 보드, 테스트 환경 — 이런 것 없이 일하라고 하면 아무리 뛰어난 엔지니어도 같은 문제를 겪는다. 에이전트에게도 마찬가지다. 환경이 필요하다.
프롬프트 → 컨텍스트 → 하네스: 세 개의 층위
이 세 개념은 서로를 대체하지 않는다. 포함하고 확장한다.
| 영역 | 핵심 질문 | 설계 대상 |
|---|---|---|
| 프롬프트 엔지니어링 | "무엇을 물어볼까?" | LLM에 보내는 지시문 |
| 컨텍스트 엔지니어링 | "무엇을 보여줄까?" | 추론 시 모델에 제공되는 모든 토큰 |
| 하네스 엔지니어링 | "전체 환경을 어떻게 설계할까?" | 에이전트 외부의 제약, 피드백, 운영 시스템 전체 |
비유를 해보자. 프롬프트는 "오른쪽으로 돌아"라는 음성 명령이다. 컨텍스트는 지도와 이정표다. 하네스는 고삐, 안장, 울타리, 도로 정비를 합친 전체 환경이다.
2022~2024년은 프롬프트 엔지니어링의 전성기였다. 질문을 어떻게 구성하느냐가 결과의 질을 결정했다.
2025년 중반, Andrej Karpathy가 "컨텍스트 엔지니어링"이라는 표현을 쓰면서 패러다임이 이동했다. RAG, MCP, 메모리 시스템 — 모델에게 올바른 정보를 올바른 시점에 제공하는 시스템 수준의 설계가 핵심이 됐다.
그리고 2026년 2월, Terraform 창시자 Mitchell Hashimoto가 블로그에서 "하네스 엔지니어링"이라는 용어를 명시적으로 사용했다. 같은 시기, OpenAI가 코드를 직접 타이핑하지 않고 에이전트만으로 프로덕션 소프트웨어를 완성한 실험 보고서를 발표했다. 비결은 모델 성능이 아니라 정교한 환경 설계였다.
하네스 엔지니어링의 시대가 공식적으로 열린 것이다.
하네스의 다섯 가지 핵심 구성 요소
Anthropic의 공식 엔지니어링 블로그와 다양한 실전 사례를 종합하면, 하네스는 다섯 가지 핵심 요소로 구성된다.
1. 파일시스템과 지속적 저장소
에이전트에게 작업 공간을 제공하는 것. 이것이 가장 기본이 되는 하네스 요소다.
LLM은 세션이 끝나면 모든 것을 잊는다. 하지만 파일시스템은 남아 있다. Anthropic은 이 단순한 사실을 활용해 세션 간 연속성을 확보했다.
핵심 패턴은 claude-progress.txt 파일이다. 각 세션이 수행한 작업을 기록하고, 다음 세션이 이 파일과 Git 로그를 읽고 현재 상태를 파악한다. 효과적인 소프트웨어 엔지니어가 매일 하는 일 — 어제 어디까지 했는지 확인하고, 오늘 할 일을 파악하는 것 — 을 코드로 구현한 것이다.
Git과 결합하면 더 강력해진다. 버전 관리, 실험적 브랜치 생성, 문제가 생기면 이전 커밋으로 복구. 여러 에이전트가 같은 저장소에서 협업할 수도 있다.
파일시스템은 에이전트의 장기 기억이다.
2. 코드 실행과 샌드박스
에이전트의 손과 발. 도구 호출(tool use)이 이 역할을 한다.
모든 가능한 행동을 미리 도구로 만들 수 없다. 그래서 범용 도구 — bash 실행, 파일 읽기/쓰기, 코드 실행 — 가 중요하다. 에이전트가 필요한 도구를 즉석에서 코드로 생성할 수 있어야 한다.
하지만 에이전트가 생성한 코드를 무조건 실행하면 위험하다. 샌드박스가 필요한 이유다. 격리된 환경에서 허용된 명령만 실행하고, 네트워크를 제한하며, 필요에 따라 생성하고 폐기한다.
Anthropic의 최신 아키텍처(Managed Agents)에서는 이것을 "Brain과 Hands의 분리"라고 부른다. Brain(LLM + 제어 로직)과 Hands(샌드박스 실행 환경)를 물리적으로 분리한 것이다. Hands는 상태가 없고(stateless), 장기 자격 증명에 접근할 수 없으며, 필요할 때만 생성된다.
이 분리의 보안적 이점은 명확하다. 기존에는 신뢰할 수 없는 코드가 자격 증명이 있는 같은 컨테이너에서 실행됐다. 프롬프트 인젝션 하나로 환경 변수를 읽을 수 있었다. 분리하면 이 공격 표면이 사라진다.
3. 컨텍스트 관리와 컨텍스트 부패 방지
"컨텍스트 부패(Context Rot)" — 컨텍스트 윈도우가 채워질수록 모델의 추론 능력이 저하되는 현상.
Chroma의 연구에 따르면 컨텍스트 길이가 증가할수록 성능이 저하되며, 질문과 관련 정보 간 의미적 유사도가 낮을수록 더 심각하다. 컨텍스트 윈도우가 크다고 좋은 게 아니다. 더 큰 건초더미일 뿐, 바늘을 찾는 능력이 향상되는 건 아니다.
하네스는 이 문제를 여러 전략으로 대응한다.
컴팩션(Compaction): 컨텍스트 한계에 도달하면 기존 내용을 요약하고 덜어내 작업을 지속한다. Claude Code에서는 토큰 사용이 98%에 도달하면 자동으로 이전 히스토리를 요약한다.
도구 호출 오프로딩: 대용량 도구 출력의 앞뒤만 남기고 전체를 파일로 분리하여 필요 시만 참조한다.
스킬(Skills)을 활용한 점진적 노출: 모든 지침을 처음부터 컨텍스트에 넣지 않고, 에이전트가 실제 필요할 때만 관련 지침과 도구를 로드한다.
"성공은 조용히, 실패만 시끄럽게" 원칙: HumanLayer 팀의 실전 교훈이다. 초기에는 전체 테스트 스위트를 매번 실행해서 4,000줄 통과 결과로 컨텍스트가 범람했다. 실패한 테스트만 보고하도록 바꾸자 컨텍스트 효율이 극적으로 개선됐다.
4. 서브 에이전트와 컨텍스트 격리
서브 에이전트의 진정한 가치는 "프론트엔드 담당", "백엔드 담당" 같은 역할 분담이 아니다. 컨텍스트 격리다.
서브 에이전트가 조사, 탐색, 구현의 중간 과정 노이즈를 전부 흡수하고, 상위 에이전트에게는 최종 결과만 간결하게 전달한다. 일종의 "컨텍스트 방화벽"이다.
비용 통제에도 유리하다. 상위 세션에는 비싼 모델(Opus), 서브 에이전트에는 저렴한 모델(Sonnet, Haiku)을 사용할 수 있다. 범위가 좁고 명확한 작업은 덜 강력한 모델로도 충분하기 때문이다.
필요한 것은 더 긴 컨텍스트가 아니라, 더 나은 컨텍스트 격리다.
5. 훅과 백프레셔 메커니즘
훅(Hooks)은 에이전트 생명주기의 특정 시점에 자동 실행되는 사용자 정의 스크립트다. Git 훅과 유사하지만 더 유연하다.
Claude Code의 훅 시스템은 21개의 생명주기 이벤트를 지원한다. 도구 호출 전(PreToolUse), 도구 호출 후(PostToolUse), 세션 시작(SessionStart), 세션 종료(Stop) 등. 예를 들어:
- 파일 수정 후 자동으로 타입 체크와 포매터를 실행
git commit에서--no-verify플래그 사용을 차단- 설정 파일 수정을 자동으로 차단
**백프레셔(Back-pressure)**는 에이전트가 자기 작업을 스스로 검증하게 하는 메커니즘이다. 타입 체크, 테스트 실행, 커버리지 리포트, 브라우저 자동화 테스트.
HumanLayer 팀은 이것을 "가장 레버리지가 높은 투자"라고 평가했다. 에이전트의 작업 성공 확률은 자기 검증 능력과 강하게 상관된다.
Anthropic이 Puppeteer MCP(브라우저 자동화)를 에이전트에게 제공했을 때, 코드만 봐서는 발견할 수 없었던 버그를 에이전트가 직접 찾아 수정했다. 기능 "완료" 표시 전에 실제 사용자처럼 테스트하게 만든 것이 핵심이다.
하네스의 힘을 증명한 실험들
LangChain Terminal Bench 2.0
모델은 그대로 두고 하네스만 개선한 결과:
- 점수: 52.8점 → 66.5점 (13.7포인트 상승)
- 순위: 30위권 → 5위권 (25단계 상승)
모델 가중치를 한 바이트도 바꾸지 않았다. 시스템 프롬프트, 도구, 미들웨어, 피드백 루프만 조정했다.
Hashline 파일 편집 실험
Can Boluk이 파일 편집 형식만 개선한 실험이다. 각 줄에 해시를 붙여 모델이 위치를 참조하게 했더니:
- Grok Code Fast 1: 6.7% → 68.3% (61.6포인트 상승)
- 전체 모델 평균: 출력 토큰 약 20% 감소
모델 가중치 변경 없이, 하네스의 도구 인터페이스 하나만 바꾼 결과다.
Anthropic의 3-에이전트 하네스
한 줄짜리 프롬프트 "레트로 게임 메이커를 만들어라"를 두 가지 방식으로 비교했다.
- 단일 에이전트: 20분, $9 — 화려한 인터페이스지만 게임 메커닉이 깨져 있음
- 3-에이전트 하네스: 6시간, $200 — 16개 기능, 10개 스프린트를 거친 완성도 높은 결과물
200짜리 결과물은 AI 기반 스프라이트 생성, 기능적인 게임플레이까지 포함한 프로덕션에 가까운 수준이었다.
모델과 하네스의 공진화, 그리고 역설
흥미로운 사실이 있다. 프론티어 코딩 모델은 자신의 하네스 안에서 후훈련된다. Claude는 Claude Code 하네스에서, Codex 모델은 Codex 하네스에서 훈련된다.
이것이 역설적 결과를 만든다. Terminal Bench 2.0에서 Claude Opus 4.6은 Claude Code(자신의 훈련 하네스)에서 33위였지만, 다른 하네스에서는 5위권으로 올라갔다.
모델이 자신의 기본 하네스에 "과적합"될 수 있다는 뜻이다. 기본 하네스를 그대로 쓰는 것이 최선이 아닐 수 있으며, 작업 특성에 맞게 하네스를 커스터마이징하면 의미 있는 성능 향상을 얻을 수 있다.
엔지니어 역할의 근본적 전환
하네스 엔지니어링의 등장이 의미하는 것은 명확하다.
"코드를 작성하는 것" → "AI가 코드를 올바르게 작성할 수 있는 환경을 설계하는 것"
OpenAI Codex 팀의 표현을 빌리면, "가장 어려운 도전은 이제 환경, 피드백 루프, 제어 시스템을 설계하는 것"이다.
Chad Fowler는 이것을 **"엄밀함의 재배치"**라고 불렀다. 코드를 한 줄 한 줄 정확하게 짜는 엄밀함이, 에이전트가 올바르게 작동하도록 시스템을 설계하는 엄밀함으로 이동하고 있다.
그렇다고 모델이 더 똑똑해지면 하네스가 불필요해질까? 아니다. 프롬프트 엔지니어링이 아직 유용한 것처럼, 잘 구성된 환경, 적절한 도구, 지속적 상태, 검증 루프는 모델의 기본 지능과 무관하게 어떤 에이전트든 더 효과적으로 만든다.
HumanLayer 팀의 결론이 이것을 가장 잘 요약한다.
"모델은 아마 괜찮다. 하네스의 문제일 뿐이다."
코딩 에이전트가 기대만큼 작동하지 않으면, 모델을 탓하기 전에 하네스를 점검하라. CLAUDE.md 파일 내용, 연결된 도구, 피드백 루프 존재 여부, 컨텍스트의 효율적 관리. 답은 거의 항상 거기에 있다.
다음 글에서는 하네스를 실제로 어떻게 적용하는지 — Anthropic의 구체적인 아키텍처 패턴과 구현 사례를 다룬다.
댓글
댓글 쓰기