원문 정보

제목: What makes a harness a harness: necessary and sufficient conditions for an agent harness

출처: Sanderson Oliveira de Macedo, Federal Institute of Goiás (브라질) · arXiv:2606.10106v1 [cs.SE / cs.AI]

발행: 2026-06-08 제출 · DOI 10.48550/arXiv.2606.10106

원문 링크: https://arxiv.org/abs/2606.10106

이 위키 자체가 Claude Code 서브에이전트(article-manager·post-illustrator 등)로 굴러가는데, 그 Claude Code가 바로 이 논문이 “유효한 하니스”로 포함하는 대표 사례다. 우리가 매일 쓰는 도구가 왜 하니스인지를 조건으로 못 박아 주기에 Articles에 담는다. 그리고 이 글은 방금 정리한 프롬프트는 언제 ‘그래프’가 되는가의 자매편이다 — 같은 저자가 같은 방법론으로 인접 레이어를 정의한다.

한 줄 요약 (TL;DR)

“에이전트 하니스”는 하나 이상의 언어 모델을 감싸 외부 환경에서 과제를 수행하는 에이전트로 바꾸는 런타임 엔지니어링 레이어다. 이 논문은 새 프레임워크나 벤치마크를 제안하지 않고, 널리 쓰이지만 정의가 없던 이 용어를 4개 필요충분조건(T1 에이전트 루프 · T2 도구 인터페이스 · T3 컨텍스트 관리 · T4 제어 메커니즘)으로 규정하고, 후보 시스템을 넣고 뺄 수 있는 포함/배제 테스트로 만든다.

이 논문을 관통하는 척추는 “하니스라는 단어가 갑옷에서 에이전트 런타임으로 어떻게 자랐는가”다. 네 정거장을 한눈에 보면 이렇다.

flowchart LR
  A["① 갑옷·마구<br/>(1300–1600s)<br/>말의 힘을 통로화"]
  B["② 테스트 하니스<br/>(소프트웨어)<br/>코드를 통제·관찰"]
  C["③ 평가(eval) 하니스<br/>(2010s–2020)<br/>모델을 사후 측정<br/>(after · 밖에서)"]
  D["④ 에이전트 하니스<br/>(2023+)<br/>모델을 사중 제어<br/>(during · 런타임)"]
  A -->|"통제 하 유용한 일"| B -->|"관찰 가능성"| C -->|"사후 → 사중<br/>after → during"| D

왜 이 글을 골랐나

이 논문의 가치는 자매편과 똑같이 “이미 하던 것에 이름을 붙였다“는 데 있다. 저자 스스로 밝히듯 정의적(definitional) 논문 — 벤치마크도 새 시스템도 없다. 대신 산업이 매일 만들고 운영하지만 어휘가 뒤처져 뒤죽박죽 부르던 “하니스”에 공유 어휘 + 재현 가능한 판정 테스트를 준다.

세 가지 이유로 이 위키 맥락과 정확히 맞물린다.

핵심 내용

논문은 자매편과 같은 순서로 간다. 먼저 계보로 개념의 출처를 복원하고, 4조건으로 정의하고, 포함/배제 테스트로 도구화한 뒤, 이웃 개념과 경계를 긋고, 실제 6개 시스템에 적용하고, 4개 긴장 축의 연구 어젠다로 닫는다. 다섯 연구질문(RQ1 계보 · RQ2 구성적 정의 · RQ3 경계 · RQ4 적용 · RQ5 어젠다)이 이 구조를 지탱한다.

계보: 갑옷에서 런타임 제어까지 (RQ1)

“하니스”는 프롬프트보다 700년 오래된 단어다. 저자는 그 이동을 복원한다.

어원: 고대 프랑스어 harneis(12세기, 전쟁 장비·갑옷) → ~1300년 영어에서 군사적 의미(갑옷) → 14세기 초 견인 동물을 수레에 잇는 가죽끈(마구) → 17세기 비유적 동사(“바람을 harness하다”).
네 정거장: (1) 갑옷/마구(1300–1600s) — 힘을 안전하게 통로화 → (2) 소프트웨어 테스트 하니스 — 스크립트·목·스텁으로 코드를 통제·관찰 가능하게 실행 → (3) ML 평가(eval) 하니스(2010s–2020) — 실행 후 밖에서 결과를 측정(SWE-bench가 과제 완수를 사후 채점) → (4) 에이전트 하니스(2023+) — 실행 중 런타임에 제어.

관통하는 실 하나: 각 하니스는 힘(말·코드·모델)을 통제 하에 유용한 일로 통로화한다. 에이전트 감각의 차별점은 그 제어가 런타임에 작동한다는 것이다. 저자가 콕 집는 대목: 평가 하니스는 실행이 끝난 뒤(after the fact) 밖에서 관찰하지만, 에이전트 하니스는 실행 도중(during the fact) 안에서 제어한다. 이 시간의 절(temporal clause)이 왜 “에이전트 하니스”가 독자적 정의를 요구하는지를 봉인한다.

4개 조건 (T1–T4): 구성적 정의 (RQ2)

논문의 심장. 저자는 하니스를 예시가 아니라 조건으로 정의한다.

“에이전트 하니스는 하나 이상의 언어 모델을 감싸 외부 환경에서 과제를 수행하는 에이전트로 바꾸는 런타임 엔지니어링 레이어로, 모델에 다음을 결합한다: (i) 추론·행동·관찰을 교차하는 에이전트 루프, (ii) 모델이 환경을 지각·변경하게 하는 도구 인터페이스, (iii) 무엇이 모델 윈도에 들고 나는지 결정하는 컨텍스트 관리, (iv) 실행을 더 신뢰할 수 있고 감사 가능하며 통제되게 만드는 제어 메커니즘 — 한계·검증·결정적 행동.”

이를 네 조건으로 부른다.

T1 — 에이전트 루프(agent loop): 런타임에 추론→행동→관찰을 교차하는 루프를 유지하는가? 부재 → 단일 패스 생성기(에이전트 아님).
T2 — 도구 인터페이스(tool interface): 모델에게 외부 환경을 지각·변경할 인터페이스를 주는가? 부재 → 고립된 모델, 또는 루프를 아직 안 조립한 SDK.
T3 — 컨텍스트 관리(context management): 무엇이 모델 컨텍스트에 들고 나는지 능동적으로 결정하는가? 부재 → 이력을 그냥 쏟아붓는 순진한 래퍼로 긴 과제에서 취약. 기준은 버퍼 크기가 아니라 과제 내용·현재 관찰에 따라 결정하느냐다.
T4 — 제어 메커니즘(control mechanisms): 모델과 독립적인 제어 장치를 최소 하나 포함하는가? 부재 → 보장 없는 데모로 모델의 말만 믿는다. 기준은 효과가 모델의 협조에 의존하지 않아야 한다는 것 — 가드레일은 통과, “로그를 출력하라”는 지시는 실패.

핵심 논증은 네 조건이 각각 필요하며 함께 충분하다는 것이다. 하나씩 빼 보면 왜인지 드러난다: T1을 빼면 고정 파이프라인으로 후퇴하고, T2를 빼면 환경과 격리되며, T3을 빼면 긴 과제에서 무너지고, T4를 빼면 아무 보장 없는 데모가 된다. 그리고 저자는 다섯 번째 조건을 두지 않는다 — 관측성·비용 제어 같은 성질은 모두 이 넷의 특수화다.

에이전트 하니스의 해부 — 네 조건(T1–T4)이 중앙의 하니스를 규정한다. 하나라도 빠지면 생성기·고립 모델·순진한 래퍼·보장 없는 데모로 붕괴한다.

포함/배제 테스트: 정의를 도구로 (RQ2)

정의는 판정 절차가 될 때 도구가 된다. 후보 시스템에 T1–T4를 순서대로 물어 넷 다 yes면 하니스다. 각 no는 후보를 이웃 범주로 밀어낸다 — T1 no는 고정 파이프라인/생성기로, T2 no는 고립 모델/SDK로, T3 no는 순진한 래퍼로, T4 no는 데모로.

경계: 이웃 개념, 각자 실패하는 조건 (RQ3)

정의는 가장자리에서 자기를 증명한다. 저자는 각 이웃 개념이 어느 조건에서 걸리는지 이름 붙인다.

에이전트 프레임워크 → 여러 에이전트를 합성한다. 하니스는 각 에이전트 아래 레이어다. (프레임워크는 최소 하니스를 각 에이전트 안에 내장할 수 있다.)
에이전트 SDK → 원재료(프리미티브)만 제공. 개발자가 조립하기 전엔 도는 루프가 없다 → T1 실패.
IDE 플러그인(자동완성) → 커서 위치에서 코드를 제안할 뿐 과제 상태를 유지하거나 레포를 조작하지 않는다 → T1·T2 실패.
평가(eval) 하니스 → 에이전트를 과제에 돌려 각 과제 종료 후 밖에서 결과를 측정한다. T1의 루프는 단일 과제 내부의 추론·행동·관찰 루프인데, eval 하니스는 관찰로 다음 단계를 결정하지 않고 시스템의 결정을 기록만 한다 → T1 실패. 시간의 절이 구분을 봉인한다: eval은 사후, 에이전트 하니스는 사중.
오케스트레이터 → 고정 그래프 파이프라인, 선택이 관찰 기반이 아니고 루프가 적응적이지 않다 → T1 실패.
가드레일 vs 하니스 → 가드레일은 하니스의 부분이지 반대가 아니다. 가드레일은 제한하고, 하니스는 가능케 한다. 가드레일은 T4의 한 인스턴스일 뿐 별도 이웃이 아니다.

적용: 실제 6개 시스템 판정 (RQ4)

“종이 위에서만 되는 정의는 슬로건이다.” 저자는 다양한 설계의 실제 6개 시스템에 T1–T4를 적용하고, 모두 하니스로 포함하되 각자가 어느 조건을 가장 잘 보여 주는지로 배열한다.

시스템	무엇을 대표하는가 (T1–T4 모두 통과)
Claude Code	런타임 가드레일 — 파괴적 행동 전 확인을 요청 (T4의 대표)
Codex CLI	등급별 권한 모드를 런타임 제어로 (T4)
Aider	버전 관리로 감사·되돌리기 가능성 확보 (T4의 검증)
Cline	민감 행동 전 사람 승인, 적응 루프 유지 (T1+T4)
OpenHands	샌드박스 실행 — 결정적 격리를 주 제어 전략으로 (T4의 강한 형태)
SWE-agent	한계를 둔 구조화된 에이전트-컴퓨터 인터페이스 (T2의 최고 모범)

배제된 경계 사례도 예상대로 실패한다: 인라인 자동완성(Copilot·Tabnine)은 적응 루프도 환경 변경도 없어 T1·T2 실패, 고정 오케스트레이션 파이프라인(retrieve→generate→format)은 관찰 기반 경로 선택이 없어 T1·T3 실패.

T1–T4 적용 — 여섯 시스템은 모두 하니스로 포함되고 강점만 다르다(강조된 열이 강점). 강점 대부분이 T4에 몰려 "제어가 설계를 가장 크게 가른다"를 보여 준다. 아래 두 배제 사례는 예상대로 T1을 필두로 실패한다.

시간의 절이 T1을 가른다 — 에이전트 하니스는 실행 도중(during) 루프 안에서 제어하고, eval 하니스는 실행이 끝난 뒤(after) 밖에서 결과만 측정한다. 관찰로 다음 단계를 결정하느냐가 경계선이다.

연구 어젠다: 4개 긴장 축 (RQ5)

핵심 T1–T4는 6개 시스템이 다 통과한다. 갈라지는 곳은 선택적 성질이며, 그 불일치가 열린 설계 질문이 된다.

자율성 ↔ 제어. 속도 vs 안전. Cline(행동마다 사람 승인) ↔ 완전 자율. 열린 질문: 과제 클래스별 최적 자율 지점을 어떻게 측정하나? 자율성과 함께 확장돼 병목이 안 되는 검증자를 어떻게 설계하나?
넓은 ↔ 큐레이팅된 컨텍스트. 긴 컨텍스트에서 유용 정보가 희석되면 성능이 떨어진다. 큐레이션엔 비용이 든다(레포 맵·RAG·메모리). 열린 질문: 토큰당 성능을 극대화하는 컨텍스트 정책은? 컨텍스트 관리를 모델과 분리해 평가할 수 있나?
범용 ↔ 특화. 범용 하니스(OpenHands·Claude Code) vs 도메인 특화 검증자·핸들러. 효과적 제어는 문제-특수적이다. 열린 질문: 하니스가 도메인 간 얼마나 재사용되나? 범용 제어 코어 + 도메인 확장을 어떻게 합성하나?
열린 권한 ↔ 격리. 사용자 권한 ↔ 샌드박스(OpenHands). 강도 위계: 결정적 격리 > 권한 제한 > 프롬프트 가드레일(가장 약함). 열린 질문: 강한 격리 + 높은 유용성을, 정당한 과제를 차단하지 않으면서 어떻게 합성하나?

두 개의 횡단 발견이 특히 날카롭다. 첫째, T4(제어)가 설계를 가장 크게 가르면서도 문헌에서 가장 덜 정착됐다. 흥미롭게도 모델-하니스 분리가 전략적이다 — 좋은 하니스일수록 덜 모델-특수적이라, 모델을 교체하는 것 자체가 하나의 제어 수단이 된다. 둘째, 평가 격차: 오늘의 벤치마크는 모델-하니스 쌍을 측정하지 하니스의 기여를 고립해 측정하지 못한다.

4개 긴장 축의 스펙트럼 — 핵심 T1–T4는 여섯이 다 통과하고, 갈라지는 곳은 선택적 성질이다. Cline(CL)은 제어 끝, OpenHands(OH)는 격리 끝에 홀로 서며 T4가 설계를 가장 크게 가른다. (본문 근거를 바탕으로 한 개략 배치)

분석과 인사이트

여기서부터는 원문 요약이 아니라 내 관점이다.

두 논문을 나란히 읽으면 저자의 방법론이 곧 주장이 된다. Macedo는 “정의 없이 중심이 된 용어”를 골라, 계보 → 필요충분조건 → 포함/배제 테스트 → 경계 → 적용 → 어젠다라는 똑같은 틀을 프롬프트 그래프와 하니스 양쪽에 적용한다. 이건 우연이 아니라 방법론적 선언이다 — AI 엔지니어링의 각 레이어는 새 프레임워크를 더 만들기 전에 개념 위생(conceptual hygiene)부터 필요하다는 것. 나는 이 자매 논문 쌍이 개별 논문보다 더 큰 걸 말한다고 본다: 프롬프트 → 컨텍스트 → 하니스 → 루프라는 스택 전체를 조건으로 정의하려는 프로그램이다.

가장 값진 대목은 자매편과의 ‘같은 도구, 다른 판정’이다. Claude Code는 이 harness 논문에선 T1–T4를 모두 통과해 대표 하니스로 포함되지만, prompt-graph 논문에선 서브에이전트 위임이 창발적이라 배제된다. 처음엔 모순처럼 보이지만, 정확히 두 정의가 다른 것을 묻기 때문이다. Harness 논문은 “이 시스템이 모델을 에이전트로 바꿔 런타임에 제어하는가?”를 묻고 — Claude Code는 루프·도구·컨텍스트·가드레일을 다 갖췄으니 yes. Prompt-graph 논문은 “실행 전에 열거할 수 있는 저작된 그래프가 있는가?”를 묻고 — Claude Code의 위임 위상은 오케스트레이터 모델이 런타임에 창발적으로 정하니 no. 같은 시스템의 ‘루프가 도는 방식’을 한 정의는 자격으로, 다른 정의는 결격으로 읽는 것이다. 이 이중성은 설계 공간에 두 개의 독립적인 축이 있음을 보여 준다: (축 A) 모델을 에이전트로 만드는 런타임 레이어가 있는가(harness), (축 B) 그 레이어 안의 호출 합성이 명시적 그래프인가 창발적 대화인가(prompt graph). Claude Code는 축 A에서 yes, 축 B에서 no인 사분면에 산다. LangGraph 위에 세운 프로덕션 파이프라인은 둘 다 yes다.

T4가 “가장 크게 가르지만 가장 덜 정착됐다”는 진단이 실무적으로 가장 중요하다. 나는 이게 현재 코딩 에이전트 경쟁의 진짜 전장이라고 본다. T1·T2·T3은 이제 상향 평준화됐다 — 루프·도구·컨텍스트 관리는 어느 하니스나 갖췄다. 차별화는 제어에서 난다: 결정적 격리(OpenHands 샌드박스)냐, 권한 등급(Codex CLI)이냐, 사람 승인(Cline)이냐, 버전 관리 되돌리기(Aider)냐. 저자의 강도 위계 — 결정적 격리 > 권한 제한 > 프롬프트 가드레일 — 는 “모델에게 하지 말라고 부탁하는” 가장 약한 제어에 의존하는 데모들에 대한 냉정한 경고다. “효과가 모델의 협조에 의존하면 그건 제어가 아니다”는 T4의 기준은, 프롬프트로 안전을 확보하려는 수많은 프로덕션 시스템이 통과하지 못하는 문턱이다.

‘모델 교체가 곧 제어 수단’이라는 관찰이 가장 반직관적이면서 깊다. 좋은 하니스일수록 덜 모델-특수적이라, 모델을 갈아끼우는 것 자체가 통제 레버가 된다는 것. 이건 우리 위키 운영에도 그대로 적용된다 — article-manager가 특정 모델에 하드코딩돼 있지 않고 하니스(서브에이전트 정의 + 도구 + 승인 게이트)로 추상화돼 있으면, 모델을 바꿔도 하니스는 그대로다. 하니스의 품질이 모델 독립성으로 측정된다는 통찰은, “어느 모델을 쓰느냐”보다 “어떤 하니스로 감싸느냐”가 더 오래가는 자산임을 시사한다.

약점도 자매편과 같다. 단일 분석가의 분류라 inter-rater 합의가 미검증이고, 제품 분류는 회색 문헌 기반 날짜 스냅샷이다. 그리고 저자 스스로 남기는 마지막 질문 — “하니스의 기여를 그것이 감싼 모델과 분리해 어떻게 측정하는가?” — 은 이 논문이 못 답하는, 그러나 가장 중요한 실증 과제다. 벤치마크가 모델-하니스 쌍만 재는 한, 우리는 “좋은 하니스”에 얼마를 투자해야 하는지 근거를 갖지 못한다.

적용 포인트

에이전트 시스템을 만들 때 T1–T4를 체크리스트로 써라. “런타임에 추론→행동→관찰 루프를 도는가(T1)? 모델이 환경을 지각·변경하나(T2)? 컨텍스트에 무엇이 들고 나는지 능동적으로 정하나(T3)? 모델 협조 없이도 작동하는 제어가 하나라도 있나(T4)?” 넷 중 하나라도 no면, 당신이 만든 건 하니스가 아니라 생성기·SDK·순진한 래퍼·데모다.
제어(T4)에 설계 예산을 몰아라. 루프·도구·컨텍스트는 상향 평준화됐다. 차별화는 제어에서 난다. 강도 위계를 기억하라 — 결정적 격리(샌드박스) > 권한 제한 > 프롬프트 가드레일. 프롬프트로만 안전을 확보하려 하지 마라.
“효과가 모델의 협조에 의존하는가”로 제어를 검증하라. “위험하면 멈추라고 프롬프트에 썼다”는 T4를 통과하지 못한다. 모델이 지시를 무시해도 강제되는 장치(승인 게이트·샌드박스·버전 되돌리기)여야 진짜 제어다.
컨텍스트 관리를 버퍼 크기가 아니라 과제 기반으로 설계하라(T3). 이력을 그냥 쏟아붓지 말고, 현재 관찰·과제 내용에 따라 무엇을 넣고 뺄지 결정하라. 이 지점은 자매편의 “노드 분해 = 컨텍스트 관리” 관점과 만난다 — prompt graph engineering의 각 노드가 큐레이팅된 창을 보게 하는 것과 같은 규율이다.
하니스를 모델 독립적으로 만들어 ‘모델 교체’를 제어 레버로 확보하라. 좋은 하니스일수록 덜 모델-특수적이다. 특정 모델에 로직을 용접하지 말고 하니스로 추상화하면, 모델을 갈아끼우는 것 자체가 안전·비용·성능의 조정 수단이 된다.
“창발 vs 명시”를 의식적으로 고르라. 열린·예측 불가 과제(코딩 에이전트)엔 창발적 위임(하니스)이 맞다. 라우팅·병렬·검증이 예측 가능한 프로덕션 파이프라인이라면 명시적 그래프(prompt graph)로 들어올려 검사·최적화 가능성을 확보하라. 두 정의가 이 선택의 양 끝이다.

마무리

실천이 어휘를 앞질렀다 — “에이전트 하니스”는 정의가 되기 전에 소프트웨어 엔지니어링의 중심이 됐고, 저자는 그 순서를 뒤집는다. 갑옷에서 마구로, 테스트 하니스에서 평가 하니스로, 그리고 실행 도중 제어하는 에이전트 하니스로 이어지는 계보를 복원하고, 4조건으로 정의하고, 포함/배제 테스트로 도구화하고, 이웃 다섯과의 경계를 “명명 가능한 이유”로 그은 뒤, 설계가 제각각인 6개 하니스를 하나의 어휘로 일관되게 분류했다. 자매편 prompt graph engineering과 나란히 놓으면 이 논문은 더 큰 그림의 한 조각이다: 프롬프트 → 컨텍스트 → 하니스 → 루프라는 AI 엔지니어링 스택을, 각 층마다 필요충분조건으로 못 박으려는 프로그램. 남긴 다음 질문은 이 분야 전체의 숙제이기도 하다 — 하니스의 기여를 그것이 감싼 모델과 분리해 어떻게 측정할 것인가.

더 읽어보기

원문 — What makes a harness a harness (arXiv:2606.10106) — Sanderson Oliveira de Macedo의 정의적 논문 원문
프롬프트는 언제 ‘그래프’가 되는가: Prompt Graph Engineering의 필요충분조건 — 자매편. 같은 저자가 같은 방법론으로 하니스 안쪽 층(호출 합성 그래프)을 정의한다. Claude Code가 여기선 배제되고 harness에선 포함되는 대비가 핵심
Loop Engineering (Addy Osmani) — 스택의 가장 바깥 층(루프)을 실무 관점에서 다룬 글 — 하니스가 그 루프를 어떻게 담는지와 맞물린다
Codex의 agent loop를 펼쳐 보기 — T1(에이전트 루프)·T2(도구 인터페이스)가 실제 코딩 하니스에서 어떻게 도는지의 실무 사례
신뢰할 수 있는 Agentic AI 시스템 만들기 — T3(컨텍스트 관리)·T4(제어)를 신뢰성 관점에서 다룬 실전 사례

무엇이 하니스를 하니스로 만드는가: 에이전트 하니스의 필요충분조건 (Sandeco Macedo)

댓글