TL;DR

• 하네스(harness)는 AI 에이전트에서 모델을 제외한 나머지 전부를 가리킨다.
• 하네스 엔지니어링은 실행 환경 — 지시, 도구, 검증, 상태 — 을 설계하고 반복적으로 개선해, 에이전트가 같은 실수를 구조적으로 다시 못 하게 만드는 실천이다.
• 한 문장으로 줄이면 Agent = Model + Harness이고, 엔지니어링의 대상은 Harness다.

하네스 엔지니어링은 모델 바깥의 실행 환경을 설계하는 일이다

무엇인가

“harness”는 AI 에이전트를 구성하는 요소 중 모델 자체를 뺀 모든 것을 부르는 약칭으로 자리 잡았다. 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리, 시스템 프롬프트, 검증 장치, 가드레일이 전부 여기에 들어간다. 모델은 고정된 추론 엔진이고, 하네스는 그 엔진을 실제 작업에 물리는 외부 골격이다.

하네스 엔지니어링은 이 골격을 짓고 유지하는 실천이다. 핵심 명제는 단순하다: 에이전트가 실수를 하면 “다음엔 잘하겠지” 하고 넘기지 않고, 그 실수를 다시 못 하도록 환경을 고친다. 이 정의는 Mitchell Hashimoto가 내린 것으로 — 그는 “업계에 합의된 용어가 있는지 모르겠지만 나는 이걸 harness engineering이라 부른다”며 용어 자체를 잠정적으로 명명했다. 고침의 형태는 두 가지다:

• 암묵적 프롬프트의 명시화 — 머릿속에만 있던 규칙을 AGENTS.md(또는 동급)에 한 줄씩 적어, 암묵지(tacit knowledge)를 형식지(explicit knowledge)로 바꾼다. 암묵지는 경험과 관찰로 체득되어 언어로 코드화·전달하기 어려운 지식이고, 형식지는 문서·매뉴얼로 표출되어 여럿이 공유할 수 있는 지식이다(Polanyi, 1966; Nonaka, 1995). 사람이 코드 리뷰에서 “이건 이렇게 하지 말라”고 매번 지적하던 암묵적 판단을 AGENTS.md 한 줄로 외부화하면, 그 지식은 에이전트가 매 세션 참조할 수 있는 형식지가 된다. Böckeler의 분류로는 inferential한 피드포워드 guide다 — 에이전트가 작업을 시작하기 전에 주어지므로 피드포워드이고, 코드로 기계적으로 강제되는 게 아니라 모델이 문장을 해석해 따르길 기대하는 것이므로 inferential(비결정적)이다.
• 결정론적 도구 — 스크린샷 촬영, 필터링된 테스트 실행 같은 스크립트를 짜서 에이전트가 스스로 틀렸는지 빠르게 알게 한다. computational한 피드백 sensor다 — 결과가 나온 뒤에 측정해 돌려주므로 피드백이고, 코드가 통과·실패를 정확히 판정하므로 computational(결정론적)이다.

”harness”라는 단어의 범위는 맥락에 따라 다르다

Agent = Model + Harness는 의도적으로 넓은 정의다. 그래서 실제로는 bounded context마다 가리키는 대상이 달라진다. 코딩 에이전트를 예로 들면 하네스는 동심원처럼 겹쳐 있다:

• 빌더 하네스 — 에이전트 제공자가 이미 내장한 부분 (시스템 프롬프트, 코드 검색 메커니즘, 장기 실행용 오케스트레이션).
• 유저 하네스 — 사용자가 자기 시스템에 맞춰 바깥에 덧대는 부분.

엔지니어링의 여지가 큰 쪽은 바깥의 유저 하네스다. Böckeler는 이 바깥 하네스를 두 방향의 제어로 나눈다. 피드포워드(guides) 는 에이전트가 처음부터 맞게 하도록 미리 주는 지침이고, 피드백(sensors) 는 결과를 측정해 사람 손에 닿기 전에 스스로 교정하게 하는 감지기다. 각 방향은 다시 실행 방식에 따라 갈린다.

방향	역할	computational (결정론적·빠름)	inferential (의미 판단·느리고 비결정적)
피드포워드 (guides)	처음부터 맞게 하는 사전 지침	코드모드, LSP, 스크립트	AGENTS.md, Skills
피드백 (sensors)	사람 손에 닿기 전 자가 교정	테스트, 린터, 타입체커, 정적 분석	리뷰 에이전트, LLM-as-judge

하네스는 이 둘을 합쳐 코드베이스를 원하는 상태로 끌고 가는 사이버네틱 거버너(governor) 처럼 작동한다.

인간은 루프 “안”이 아니라 루프 “위”로 옮겨간다

하네스 엔지니어링이 중요한 이유는 인간과 자동화 사이의 위치를 다시 정하기 때문이다. Kief Morris는 인간의 자리를 세 단계로 구분한다:

• In the loop — 인간이 코드 생성 루프 안에 게이트키퍼로 들어가 한 줄씩 검사한다. 품질은 지키지만 인간이 병목이 된다.
• On the loop — 인간이 산출물을 직접 고치는 대신, 그 산출물을 만들어낸 하네스를 고친다. 결과가 불만이면 결과물이 아니라 그것을 생성한 환경을 바꾼다. 이게 하네스 엔지니어링이 인간을 놓는 자리다.
• Flywheel — 하네스를 개선하는 일 자체를 에이전트에게 맡긴다. 에이전트가 루프의 성능을 평가하고 자기 하네스의 개선안을 만들어낸다.

즉 “in the loop”의 교정 방식이 산출물을 고치기라면, “on the loop”의 교정 방식은 그것을 생성한 하네스를 고치기다. 같은 실수가 반복될 때 무엇을 손대는가 — 그 차이가 하네스 엔지니어링의 정체성이다.

한 번의 설정이 아니라 지속적 실천이다

하네스 엔지니어링은 일회성 구성(configuration)이 아니라 성숙 단계이자 계속 도는 루프다. Hashimoto의 AI 도입 여정에서 이 단계는 6단계 중 5번째 — 챗봇을 버리고, 에이전트가 잘하는 일과 못하는 일의 경계를 충분히 익힌 뒤에야 도달하는 지점이다. 즉 하네스 엔지니어링은 도구를 처음 켜자마자 하는 일이 아니라, 에이전트의 실패 패턴이 쌓인 다음에 그 패턴을 하나씩 환경으로 봉인하는 작업이다.

Böckeler도 같은 결론에 닿는다 — 바깥 하네스를 짓는 일은 “일회성 구성이 아니라 계속되는 엔지니어링 실천”이다. 같은 이슈가 반복될 때마다 guide와 sensor를 개선해 재발 확률을 낮추는 steering loop가 핵심이고, 이 루프 자체를 에이전트에게 맡기기 시작하면 하네스가 스스로를 개선하는 flywheel로 넘어간다.

결국 Agent = Model + Harness

하네스 엔지니어링은 결국 한 등식으로 압축된다 — Agent = Model + Harness. 모델은 우리가 직접 바꿀 수 없는 고정 변수이고, 에이전트의 신뢰성을 끌어올리는 레버는 거의 전부 등호 오른쪽의 하네스에 있다. prompt engineering과 context engineering이 모델에게 무엇을 어떻게 보여줄지를 다룬다면, 하네스 엔지니어링은 그 바깥에서 모델이 일하고 검증받고 교정되는 실행 환경 전체를 설계하는 한 단계 위의 작업이다.

---

Connections

• [[컨텍스트 엔지니어링은 모델의 작업 기억을 설계하는 일이다]] — 하네스 안쪽, 모델의 작업 기억을 다루는 인접 실천
• [[에이전트 실패는 하네스 갭의 신호일 수 있다]] — “실수를 환경으로 막는다”는 명제의 운영 버전
• [[장기 실행 에이전트에는 외부화된 작업 상태가 필요하다]] — 하네스의 상태 관리 구성요소
• Agent Skills - AI 에이전트에게 전문성을 부여하는 방법 — 피드포워드 guide의 한 구현 형태

Open Questions

• “harness”라는 단어의 의미: 본래 말의 마구(tack) 또는 등반 안전벨트를 뜻하며, 소프트웨어에서는 무언가를 실제로 돌리는 외부 골격(예: test harness)을 가리키는 비유로 쓰인다. 다만 AI 에이전트 맥락에서 이 단어가 test harness 계보에서 왔다고 명시적으로 밝힌 1차 출처는 아직 확인되지 않았다 — 합리적 추론일 뿐 인용 가능한 사실은 아니다.

Related MOCs

• [[MOCs - Harness Engineering]]