이번 글에서는 최근 AI 진영에서 자주 등장하는 하네스 엔지니어링(Harness Engineering) 에 대해 정리한다.
용어의 어원부터 시작해서 정의를 잡고, 실제 사례를 통해 하네스 설계가 왜 중요한지 살펴본다.
하네스 엔지니어링이 화두인 이유
요즘 AI 엔지니어링 커뮤니티에서 가장 자주 등장하는 단어 중 하나가 하네스 엔지니어링이다. Anthropic 엔지니어링 블로그, Thoughtworks, Cursor 같은 곳에서 다 같은 단어를 쓰고 있다.
그런데 막상 "하네스가 뭐냐?"라고 물어보면 명확히 답하는 사람이 많지 않다. 이번 글에서 그 답을 정리해보려 한다.
1. Harness의 어원
본격적인 내용에 앞서 단어 자체의 어원을 살펴본다.
Harness 원래 의미 : 마구(馬具). 말이나 소에게 채워서 수레나 쟁기를 끌게 하는 장비.
고대 프랑스어 harneis("장비, 군장")에서 왔고, 더 거슬러 가면 고대 노르드어 hernest(군대를 뜻하는 herr + 식량/장비를 뜻하는 nest)에서 비롯됐다. 원래는 "전투 장비, 갑옷" 같은 넓은 의미였다가 중세 영어 시기에 "말에 채우는 장비"로 의미가 좁아졌다.
여기서 동사 to harness 가 갖는 두 가지 뉘앙스가 핵심이다.
1) 속박 / 제어 : 말이 제멋대로 뛰지 못하게 묶어둔다.
2) 활용 / 일하게 만들기 : 그 힘을 끌어내 유용한 일을 시킨다.
"harness the power of the sun(태양의 힘을 활용하다)" 같은 표현에서 두 번째 뉘앙스가 잘 드러난다. 강력한 무언가를 제어하면서 동시에 그 힘을 끌어다 쓴다 — 이 이중성이 키워드다.
2. 왜 AI에 이 단어를 쓰는가
사실 소프트웨어 엔지니어에게 harness는 새로운 단어가 아니다. Test Harness 라는 개념이 오래 전부터 있었다. 코드를 실행시키고, 입력을 주입하고, 출력을 수집/검증하는 둘러싸는 인프라를 가리킨다. JUnit 같은 테스트 프레임워크가 일종의 test harness다.
즉 harness는 이미 "실행 주체를 감싸서 통제하고 관찰하는 외부 인프라" 라는 의미로 친숙했고, AI 에이전트 시대에 자연스럽게 확장된 셈이다.
비유의 적합성을 보면 거의 완벽하다.
| 마구(Horse Harness) | AI Harness |
| 말 자체는 건드리지 않음 | 모델 자체는 건드리지 않음 |
| 말의 힘은 살리되 방향을 제어 | 모델의 능력은 살리되 행동을 제약 |
| 고삐, 멍에, 끈으로 구성 | 툴, 가드레일, 검증 루프로 구성 |
| 없으면 말은 강하지만 쓸모없음 | 없으면 모델은 똑똑하지만 신뢰 불가 |
| 마부가 고삐로 조종 | 엔지니어가 하네스로 조종 |
추가로 등산용 안전 하네스(climbing harness)의 이미지도 같이 연상된다. 추락을 막아주는 안전장치. 그래서 harness라는 단어 하나에 제어, 활용, 안전 세 가지가 동시에 담긴다.
3. 하네스 엔지니어링의 정의
핵심 공식은 아래와 같다.
Agent = Model + Harness
모델은 추론 능력을 제공하고, 하네스는 그 추론이 실제 세계에서 신뢰성 있게 행동으로 옮겨지도록 만드는 규칙, 환경, 검증, 관찰 레이어를 제공한다.
정리하면 하네스 엔지니어링은 AI 모델 자체를 제외한 모든 것 — 모델을 둘러싸고 그것을 안정적, 안전하게, 유용하게 일하게 만드는 시스템 — 을 설계하는 분야다.
프롬프트 엔지니어링과의 차이
세 가지 개념을 나란히 놓으면 이해가 쉽다.
프롬프트 엔지니어링 : 모델에게 무엇을 물어볼지.
컨텍스트 엔지니어링 : 모델이 자신있게 답할 수 있도록 무엇을 함께 제공할지.
하네스 엔지니어링 : 전체 시스템이 어떻게 작동할지. 모델의 단어나 토큰뿐 아니라, 모델을 둘러싼 환경 전체.
프롬프트 엔지니어링이 한 번의 대화 턴을 다듬는 것이라면, 하네스 엔지니어링은 에이전트가 사람의 감독 없이 수백 번의 의사결정을 거치며 몇 시간 동안 안정적으로 동작하게 만드는 일 이다.
왜 갑자기 화두가 됐는가?
답은 단순하다. 에이전트들이 "쓸만큼 똑똑해졌지만, 혼자 믿고 맡길 만큼 안정적이지는 않다" 는 상황에 도달했기 때문이다.
모델 성능은 어느 정도 상향 평준화됐고, 진짜 병목은 "코드를 생성할 수 있느냐" 가 아니라 "실제 시스템 안에서 안정적으로 행동하게 만들 수 있느냐" 로 옮겨갔다. 프롬프트만 가지고는 안 풀리는 문제다.
하네스의 핵심 구성요소
일반적으로 5가지가 핵심 축으로 꼽힌다.
Tool Orchestration : 에이전트가 쓸 수 있는 도구와 호출 방식, 권한 정의.
Guardrails : 해서는 안 되는 일, 인간 승인이 필요한 일의 경계.
Context Management : 컨텍스트 윈도우 오버플로우와 정보 손실을 막는 레이어.
Feedback Loop : 출력 결과를 검증하고, 틀렸으면 재시도시키는 메커니즘.
Observability : 사람이 에이전트 행동을 모니터링/추적/재현할 수 있는 레이어.
4. 실제 사례
같은 frontier 모델(Claude, GPT 등)을 쓰지만 하네스 설계가 달라서 전혀 다른 도구가 된 세 가지 사례를 비교해본다.
사례 1. Claude Code
Claude Code는 출시 6개월 만에 연간 매출 10억 달러를 돌파했다. 이 성과는 "더 좋은 프롬프트" 때문이 아니라 "올바른 모델 주위에 올바른 하네스를 구축했기 때문" 이라는 평가가 일반적이다. 같은 Claude Opus 4.7 모델이라도, Claude Code 안에서 쓸 때와 다른 도구에서 쓸 때 체감이 완전히 다른 이유가 여기 있다.
3단 권한 모델
모든 도구 호출을 위험도에 따라 세 단계로 나눈다.
1단계 (자동 승인) : 파일 읽기, 검색처럼 상태를 바꾸지 않는 작업은 중단 없이 실행.
2단계 (확인 요청) : 파일 편집, 일부 셸 명령. 백그라운드 분류기가 자동 처리 가능 여부를 판단.
3단계 (항상 명시적 허가) : 시스템 파일 수정, 외부 네트워크 호출 등.
여기서 진짜 영리한 부분은, 분류기는 사용자 요청과 도구 호출은 보지만 모델이 쓴 산문(prose)은 보지 않는다는 점이다. 즉, "이건 안전합니다, 믿어주세요" 라고 모델이 아무리 그럴듯하게 설득해도 분류기는 그 설득에 노출되지 않는다. 손상되었거나 prompt injection을 당한 모델이 말로 안전 검사를 우회할 수 없게 만든 의도적 설계다.
모델은 직접 손대지 않는다
모델은 "의도" 를 표현할 뿐, 실제 파일시스템/셸 실행은 모두 하네스가 통제된 인터페이스를 통해 수행한다. 모델은 "어떤 함수를 수정하면 좋겠다" 고 제안하고, 하네스는 그 제안이 안전한지, 권한이 맞는지, 결과를 어떻게 다시 보여줄지를 판단하고 집행한다.
컨텍스트 관리
도구 결과를 자동 요약/압축하고, 중요한 결정은 `CLAUDE.md` 같은 영속 메모리에 기록한다. "Claude는 잊는다. 프레임워크가 기억한다" 는 표현이 이 설계 철학을 잘 보여준다.
한 마디로 Claude Code의 본질은 모델을 똑똑하게 만드는 게 아니라, 모델이 똑똑함을 발휘할 수 있는 안전한 작업장을 만든 것 이다.
사례 2. Cursor
Cursor는 Claude Code와 거의 정반대 방향에서 출발했다. "개발자는 에디터 안에 있어야 한다" 는 전제 위에, 모델을 IDE에 깊이 결합하는 길을 택했다.
모델별 맞춤 하네스 튜닝
Cursor 엔지니어링 블로그에서 가장 자주 등장하는 표현이 "새 frontier 모델이 나올 때마다 몇 주씩 우리 하네스를 그 모델에 맞춰 커스터마이즈한다" 는 말이다. 모델마다 같은 프롬프트에 다르게 반응하기 때문이다. 어떤 모델은 셸 워크플로우에 강해서 dedicated search tool보다 grep을 선호하고, 어떤 모델은 편집 후 린터 호출을 명시적으로 지시해야 한다.
여기서 알 수 있는 사실은 같은 모델도 하네스가 다르면 다른 결과가 나오고, 같은 하네스도 모델이 다르면 다른 튜닝이 필요하다 는 점이다.
멀티 에이전트로의 진화
최근 Cursor는 단일 에이전트에서 서브에이전트(subagent) 구조로 옮겨가고 있다. 플래닝은 한 에이전트, 빠른 편집은 다른 에이전트, 디버깅은 또 다른 에이전트 — 각자 잘하는 일에만 집중한다. 이걸 조율하는 게 곧 하네스의 일이다.
디프 UI를 통한 인간 검증
Cursor의 안전 모델은 Claude Code와 다르다. "모든 변경을 에디터의 디프 뷰에서 사람이 한번 본다" 는 흐름에 기댄다. 가드레일이 자동 분류기가 아니라 사람의 눈 인 셈이다.
한 마디로 Cursor의 본질은 "하네스가 곧 제품이다(The harness is the product)" — 모델은 갈아끼울 수 있지만, 그 위에 얹는 통합/UX/튜닝이 진짜 가치라는 철학이다.
사례 3. Devin
Cognition Labs의 Devin은 또 다른 방향이다. "사람이 에이전트 옆에 있으면 안 된다. 외주를 주듯 작업을 의뢰하고 결과만 받는다" 는 전제로 설계됐다.
클라우드 샌드박스
Devin은 로컬에서 돌지 않는다. "인간 엔지니어가 일할 때 필요한 모든 것" 을 갖춘 클라우드 VM 위에서 작동한다 — 셸, 코드 에디터, 브라우저까지. 자율성에는 격리가 필수이기 때문이다. 사람이 옆에서 매 단계 검토하지 않을 거라면, 에이전트가 실수해도 그 폭발 반경(blast radius)을 묶어두는 환경이 있어야 한다.
스코프 명확한 티켓 단위 작업
Devin은 Slack이나 Jira로 작업을 받는다. 결과는 GitHub PR로 돌아온다. 이 흐름은 에이전트를 "주니어 개발자처럼" 다루는 모델이다 — 범위가 명확한 일을 던지고, 결과를 리뷰한다. 대신 모호하거나 아키텍처적인 결정이 필요한 일에는 약하다.
멀티 에이전트 계층
Coordinator(계획 분해) → Implementer(실행) → Verifier(검증)로 역할을 나눈다. 이 분업 자체가 하네스 설계의 일부다.
한 마디로 Devin의 본질은 "에이전트가 사람 없이 오래 일할 수 있는 격리된 작업장을 만든다" 이다.
5. 비교를 통해 보이는 것
이 세 도구는 같은 frontier 모델에 접근할 수 있다. 그런데 사용 경험은 완전히 다르다. 그 차이는 거의 전부 하네스 설계 철학의 차이에서 나온다.
| Claude Code | Cursor | Devin | |
| 실행 환경 | 로컬 터미널 | IDE 안 | 클라우드 샌드박스 |
| 가드레일 방식 | 자동 분류기 + 권한 등급 | 사람이 디프로 검토 | 샌드박스 격리 |
| 사람의 위치 | 옆에 앉은 페어 | 에디터 안 동료 | 외주 받은 동료 |
| 컨텍스트 전략 | 영속 메모리 + 압축 | 모델별 튜닝 + 인덱싱 | 멀티 에이전트 역할 분담 |
| 잘 맞는 일 | 탐색/디버깅 | 빠른 반복 작성 | 스코프 명확한 티켓 |
| 신뢰 모델 | 단계별 승인 | 변경 단위 검토 | 결과(PR) 단위 검토 |
여기서 얻을 수 있는 교훈들을 정리한다.
1) 모델이 같아도 하네스가 다르면 다른 도구다.
가장 강력한 교훈이다. "Claude를 그냥 부르는 것" 과 "Claude Code" 는 다른 제품이다. 하네스 설계가 사용자 경험의 90%를 만든다.
2) "잘 만든 하네스"는 하나의 답이 아니다.
Claude Code의 권한 분류기, Cursor의 디프 UI, Devin의 샌드박스 격리 — 모두 잘 만든 하네스다. 단지 전제하는 사용 시나리오가 다를 뿐이다. 어떤 제품을 만들지에 따라 답이 달라진다.
3) 모델과 하네스는 함께 진화한다.
오늘날의 모델들은 하네스가 끼워진 상태로 후속 학습된다. Anthropic이 Claude를 학습시킬 때 Claude Code의 도구들과 함께 학습시키는 것이 대표적이다. 그래서 같은 모델도 다른 하네스 안에서는 미묘하게 다른 성능을 보인다.
4) 하네스 변경은 회귀(regression)를 일으킬 수 있다.
도구 하나의 인터페이스를 바꿨더니 멀쩡하던 워크플로우가 갑자기 깨지는 일이 흔하다. 그래서 하네스 엔지니어링에는 evals와 관찰성이 필수다. 프롬프트 엔지니어링과 달리, 하네스는 시스템 변경이 멀리까지 영향을 미친다.
마무리
이번 글에서는 하네스 엔지니어링의 어원, 정의, 그리고 실제 사례를 정리했다.
만약 우리 팀이 AI를 단순히 "API를 호출하는 기능" 이 아니라 "에이전트로 활용하는 제품" 으로 만든다면, 다음 질문들이 곧 우리 일이 된다.
- 권한과 가드레일 — 우리 에이전트가 할 수 있는 일과 없는 일의 경계는?
- 컨텍스트 전략 — 긴 작업에서 어떻게 정보를 유지하고 압축할까?
- 인간 개입 지점 — 어디서 사람의 승인을 받고, 어디는 자동으로 가는가?
- 관찰성 — 에이전트가 무엇을 했는지 어떻게 추적하고 재현하는가?
- 검증 루프 — 출력이 틀렸을 때 어떻게 알아채고 재시도시키는가?
이 질문들을 잘 푸는 게 곧 하네스 엔지니어링이다.
모델은 점점 상품화된다. 차이를 만드는 건 그 주위에 무엇을 짓느냐다. 이제는 프롬프트가 아니라 *하네스*가 경쟁력이 된다.
### Reference
Anthropic Engineering — Harness design for long-running application development : <https://www.anthropic.com/engineering/harness-design-long-running-apps>
Martin Fowler — Harness engineering for coding agent users : <https://martinfowler.com/articles/harness-engineering.html>
Cursor Blog — Continually improving our agent harness : <https://cursor.com/blog/continually-improving-agent-harness>
Addy Osmani — Agent Harness Engineering : <https://addyosmani.com/blog/agent-harness-engineering/>