노트

하네스 엔지니어링

Harness Engineering

개발 문화#ai · 연결된 개념 9개

쉽게 말하면

하네스 엔지니어링은 자전거를 배우는 아이에게 보조 바퀴와 헬멧을 맞춰 주는 일과 비슷해요. 같은 아이라도 장비에 따라 얼마나 멀리, 얼마나 안전하게 가는지가 크게 달라지죠.

비유가 깨지는 곳 보조 바퀴는 실력이 늘면 짐이 되지만 헬멧은 계속 써요. 모델 약점을 메우던 우회책은 다음 모델에서 dead weight가 되니 얇게 두고, 테스트·훅 같은 결정론적 검증은 두껍게 둬요.

하네스(Harness)는 AI(Artificial Intelligence) 에이전트를 둘러싼 모든 장치다. 시스템 프롬프트와 지침 파일, 도구, 훅, 권한, 작업 분해 방식, 검증기가 여기에 든다. 모델이 같아도 하네스에 따라 결과와 비용이 크게 달라지므로, 이것을 설계 대상으로 다루는 일을 하네스 엔지니어링이라고 부른다. 미첼 하시모토(Mitchell Hashimoto)는 2026년 2월 글에서 "에이전트가 실수하면, 다시는 그 실수를 하지 않도록 해결책을 만드는 데 시간을 쓴다"는 습관을 이 이름으로 불렀다. 단순한 실수는 AGENTS.md를 고치고, 그 밖에는 스크린숏을 찍거나 테스트를 골라 돌리는 스크립트처럼 에이전트가 스스로 확인할 도구를 만든다.

우회책은 낡는다

Anthropic의 사례가 대표적이다.

  • Claude Sonnet 4.5는 컨텍스트 한도에 가까워졌다고 느끼면 실제로는 여유가 있어도 일을 서둘러 마무리했다. 이를 컨텍스트 불안(Context Anxiety)이라 부른다. 그래서 하네스에 컨텍스트를 비우고 새로 시작하는 컨텍스트 리셋을 넣었다
  • 같은 하네스를 Claude Opus 4.5에 썼더니 그 행동이 사라져 있었다. Anthropic은 리셋이 "dead weight(아무 일도 안 하면서 무게만 차지하는 짐)"가 됐다고 썼다
  • 장기 실행 앱 개발 하네스에서는 일을 스프린트 단위로 잘라 주던 구조를 Opus 4.6에서 통째로 뺐다. 모델이 그 분해 없이도 일을 해냈기 때문이다
  • Claude Code 팀은 Claude Opus 5·Fable 5 세대를 위해 시스템 프롬프트의 80% 이상을 지웠는데 코딩 평가에서 측정 가능한 손실이 없었다고 밝혔다. 예시(few-shot)를 주면 오히려 모델의 탐색 범위를 좁힌다는 관찰도 덧붙였다(2026 기준)

Anthropic은 이를 "하네스의 모든 구성 요소는 모델이 혼자 못 하는 일에 대한 가정을 담고 있고, 그 가정은 모델이 좋아지면 낡는다"고 정리한다. 지침에 넣은 "반드시 N단계로 나눠라", "길어지면 요약하라" 같은 문장이 특정 모델의 약점을 메우는 우회책이라면, 모델을 바꿀 때마다 빼 보고 비교할 후보다. 지침을 계속 손질하는 습관은 프론티어 팀의 습관에서도 다룬다.

검증은 두껍게

반대로 테스트·타입 검사·린터, 파괴적인 명령을 막는 훅 같은 결정론적 검증은 모델이 바뀌어도 가치가 그대로다. 같은 Anthropic 하네스도 Opus 4.6에서 스프린트 분해는 뺐지만 계획자와 평가자는 남겼다. 생성과 평가를 나누는 구조는 생성과 평가 분리에서 다룬다.

  • 지시보다 환경: Claude Code 문서는 CLAUDE.md가 강제 설정이 아니라 맥락일 뿐이라며, 무슨 일이 있어도 막아야 하는 행동은 PreToolUse 훅으로 막으라고 안내한다. "항상 X를 확인하라"는 문장이 생기면 훅이나 CI(Continuous Integration) 규칙으로 옮길 수 있는지 먼저 묻는다
  • 테스트가 곧 스펙: 에이전트가 오래 혼자 일하려면 스스로 끝났는지 확인할 기준이 필요하다 → 자가 테스트 코드
  • 무엇을 어디에 둘지: 규칙·절차·기억을 어떤 파일에 나눌지는 에이전트 컨텍스트 파일 (AGENTS.md·스킬·메모리)에서 다룬다

비용도 설계 변수다

Anthropic의 실험에서 같은 앱을 혼자 도는 에이전트는 20분, 9달러에 만들었고, 계획자·생성자·평가자를 갖춘 Opus 4.5 하네스는 6시간, 200달러가 들었다(결과물 품질은 하네스 쪽이 확연히 나았다). Opus 4.6에서 하네스를 줄인 뒤에는 약 4시간, 124.70달러였다. 무거운 하네스는 그만한 값을 할 때만 쓴다. 글쓴이의 표현으로는 평가자가 "작업이 현재 모델이 혼자서 안정적으로 해내는 범위를 넘을 때" 비용을 치를 가치가 있다.

  • effort: 응답에 쓰는 토큰 양을 low부터 max까지 고른다. 단순한 조회·수정은 낮게, 설계·디버깅은 높게 둔다
  • 프롬프트 캐시: 캐시는 도구 정의 → 시스템 프롬프트 → 메시지 순서의 접두부가 똑같을 때만 맞는다. 세션 중간에 도구 목록이나 시스템 프롬프트를 바꾸면 캐시를 버리게 된다. 캐시 읽기는 대부분의 모델에서 기본 입력 단가의 10%다(2026 기준)
  • 서브에이전트: 서브에이전트는 새 컨텍스트로 시작해 자기 시스템 프롬프트와 지침 파일을 다시 읽는다. 독립적인 일을 병렬로 돌리거나 시끄러운 출력을 메인 컨텍스트에서 떼어 낼 때 쓴다
  • 회로 차단기: 모든 루프에 최대 턴 수와 예산 상한을 둔다 → 에이전트 루프

에이전트에게 무엇을 맡기고 사람이 무엇을 쥘지는 AI 시대 엔지니어의 역할 변화, 맡긴 변경의 책임은 AI 시대 변경에 대한 책임 질문, 빠르게 쌓이는 코드를 이해하는 문제는 인지 부채와 이해 병목에서 다룬다.

출처: Harness design for long-running application development Prithvi Rajasekaran, Anthropic(2026-03-24) · Scaling Managed Agents: Decoupling the brain from the hands Anthropic(2026-04-08) · The new rules of context engineering for Claude 5 generation models Thariq Shihipar(2026-07-24) · My AI Adoption Journey Mitchell Hashimoto(2026) · Claude Code 문서: How Claude remembers your project

참고: Effort · Prompt caching

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 구성요소 줄이기

    셀 수 있는 모든 구성요소(파일, 폴더 깊이, 클래스, 함수, 분기, 변수, 테이블, 필드, 테스트 케이스…)는 비용이라는 관점. 심플 디자인의 네 번째 규칙을 실무 기준으로 풀어낸 것이다.

  • 소프트웨어 공학의 법칙들

    소프트웨어 시스템과 팀, 의사결정에 반복해서 나타나는 경험칙들을 모아 부르는 말. 법칙이라고 부르지만 대부분 증명된 정리가 아니라 관찰과 격언이다. 판단할 때 떠올릴 이름표로 쓴다. 따로 노트를 둔 것은 링크로, 나머지는 한 줄로 적었다.

  • 테스트 냄새

    테스트 코드나 테스트 습관에서 나는, 더 깊은 문제를 알리는 신호. 제라드 메스자로스의 xUnit 테스트 패턴 정리가 이름을 붙였다.

  • 심플 디자인

    켄트 벡이 XP(Extreme Programming)에서 제시한 단순한 설계의 네 가지 규칙. 우선순위 순으로 ① 모든 테스트를 통과하고 ② 의도를 드러내고 ③ 중복이 없고 ④ 요소가 가장 적다. 마틴 파울러가 이렇게 정리한 형태가 널리 쓰인다.

  • 언어적 안티패턴

    이름, 타입, 주석이 말하는 것과 코드가 실제로 하는 일이 어긋나는 것. 읽는 사람을 잘못된 추측으로 이끈다.

보기 옵션