TL;DR

하네스 엔지니어링 (Harness Engineering)에는 「에이전트의 행동 범위를 넓히는」 방향과 「불완전성을 메우는」 방향의 두 가지가 있다고 느껴왔습니다. 하지만 이 이분법은 거칠며, 더 넓은 좌표 공간의 한 단면에 불과하다는 것을 알게 되었습니다. Böckeler의 guides ↔ sensors 축과 당초의 이분법을 직교시켜 4사분면을 만들면, 왼쪽 하단의 「Agency × Sensors」만이 구조적으로 희박하다는 것을 볼 수 있습니다. 실행 시의 피드백으로 행동 표면 그 자체를 다시 쓰는 영역으로, 추상이 미성숙한 채 방치되어 있는 곳입니다. 하네스를 학습계로 만들고 싶다면, 이곳을 경유할 수밖에 없을 것 같다는 이야기를 쓰겠습니다.

두 가지 방향성이 보였다

최근 하네스 엔지니어링 (Harness Engineering)이라는 말을 자주 접합니다. 제창된 것은 2026년 초로, Mitchell Hashimoto와 OpenAI의 Ryan Lopopolo가 거의 비슷한 시기에 독립적으로 던진 용어라고 정리되어 있습니다. 어휘로서는 결정화되는 과정 중에 있으며, 사람에 따라 함의가 미묘하게 어긋나 있는 점도 흥미로운 부분입니다.

한동안 관찰해 오면서, 제 안에서는 이것이 두 가지 방향으로 나뉘어 있었습니다.

하나는 에이전트의 행동 표면을 넓히는 하네스. Claude Code, Codex, OpenCode 계보로, 브라우저 조작, Skills, 서브 에이전트 (sub-agent), MCP 서버 접속, Bash 액세스. 요컨대 에이전트가 접하는 세계를 넓히는 방향입니다. 화려하고 경쟁이 치열하며, 신기능이 나올 때마다 화제가 됩니다.

다른 하나는 에이전트의 불완전성을 보완하는 하네스. rubric에 기반한 평가, 리뷰 관점과 소스의 엄격화, CI 게이트 (CI gate), 가관측성 (Observability), 재현성. 이쪽은 은탄환 (Silver bullet)이 없고, 개별 최적화 요소가 강해서 지루하고 다루기 어렵습니다. LLMOps도 결과적으로 이쪽을 파고들지 못하고 있다고 생각합니다.

이분법으로서는 우선 이것으로 움직일 수 있었습니다.

하지만 이분법은 거칠었다

제대로 문헌을 다시 읽어보니, 저의 정리가 거칠다는 것을 깨달았습니다.

Böckeler가 Thoughtworks를 통해 쓴 harness engineering 기사에서는, Guides (실행 전의 스티어링)와 Sensors (실행 후의 탐지)를 직교축으로 한 2×2가 제시되어 있습니다. 나아가 각각을 Computational (결정론적)과 Inferential (LLM 구동)로 세분화합니다. 규제 대상으로서는 Maintainability harness, Architecture fitness harness, Behavior harness의 세 가지를 별도 축으로 나타내고 있습니다. Behavior harness가 「the elephant in the room」이라고 불리며, 이곳이 가장 미성숙하다고 정리되어 있습니다.

다른 논문에서는 CAR (Control / Agency / Runtime)라는 분해가 제안되어 있습니다. 하네스 층을 Control (제어), Agency (행동 가능 공간), Runtime (상태와 재시도와 회복)의 세 부분으로 나누고, HarnessCard라는 구조화된 보고 아티팩트 (artifact)를 함께 제안하는 입장입니다.

이것을 저의 이분법과 나란히 놓고 보면, 당초의 「확장성 vs 불완전성 보완」은 요컨대 「Agency vs (Control + Sensors + Runtime)」의 축약이었습니다. 틀린 것은 아니지만 해상도가 낮습니다. 예를 들어 Skills를 「확장성 측」에 두었지만, Böckeler의 프레임워크에서는 Skills는 Guides (지식의 사전 주입)입니다. 서브 에이전트도 Agency 확장으로 보이지만, 실체는 단일 컨텍스트가 파탄 나는 것을 피하기 위한 불완전성 회피책이기도 합니다. Agency 확장과 제어 강화는 동일한 프리미티브 (primitive)로 구현 가능하며, 이분법은 구조적으로 중첩을 가지고 있었다는 뜻이 됩니다.

축을 두 개로 만든다

다시 정리하면, 가로축에 「Agency 확장 ↔ Control·검증」, 세로축에 「사전 (Guides) ↔ 사후 (Sensors)」를 취하면 딱 적당해집니다. 양쪽 모두 실용상 의미 있는 구분이며, 4사분면 모두에 구체적인 구성 요소를 배치할 수 있습니다.

왼쪽 상단, Agency × Guides. 능력의 사전 부여. MCP 서버나 도구 정의, 서브 에이전트 정의, Skills, 브라우저나 Bash 접속, Agent SDK의 tool layer.

오른쪽 상단, Control × Guides. 방침이나 규약의 사전 부여. CLAUDE.md나 AGENTS.md, 코딩 규약, rubric이나 평가 기준의 사양, 타입 스키마 (type schema), 아키텍처 문서.

우측 하단, Control × Sensors. 결과의 검증과 관측. Linter, type checker, 테스트와 CI 게이트, LLM-as-judge, LangSmith나 Langfuse, 차분 eval (diff eval).

그리고 좌측 하단, Agency × Sensors. 스크린샷의 순환, Shell이나 REPL 출력의 관찰, 자기 수정 루프 (self-correction loop), 재시도(retry)나 에스컬레이션 (escalation). 이렇게 써 내려가 보니 항목 수도 적고 추상화도 제대로 이루어지지 않았음을 알 수 있습니다. 이 부분만 유독 빈약합니다.

왜 좌측 하단이 빈약한가

설계자가 실수로 잊어버린 것이 아니라, 구조적으로 빈약한 것이라고 생각합니다. 그 이유는 적어도 다섯 가지가 겹쳐 있습니다.

첫 번째는 시간축의 비대칭성입니다. Agency는 본질적으로 설계 시의 개념(도구, Skills, 서브 에이전트를 사전에 결정)이며, Sensors는 본질적으로 실행 시의 개념입니다. 양자의 교점은 '실행 중에 행동 표면(action surface)이 변동하는' 설계를 요구합니다. 이는 '하네스(Harness) = 고정된 발판'이라는 지배적인 멘탈 모델 (mental model)을 깨뜨립니다. 많은 엔지니어의 인지 지도에 이 조합이 애초에 포함되어 있지 않은 것 같습니다.

두 번째는 재현성과 감사성 (auditability) 사이의 충돌입니다. Agency를 동적으로 다시 쓰면 비정상성 (non-stationarity)이 나타납니다. 동일한 태스크, 동일한 모델이라도 시점에 따라 이용 가능한 도구 집합이 달라집니다. 트레이스 (trace)가 안정되지 않아 디버깅과 감사가 어려워집니다. 이는 엔터프라이즈의 보수적인 요구사항과 정면으로 충돌합니다.

세 번째는 '에이전트가 이미 하고 있는 것처럼 보이는' 착각입니다. ReAct 루프에서 에이전트는 도구 결과를 관찰하여 다음 수를 결정합니다. Agency × Sensors의 위치는 '모델의 일'로 간주되기 쉽습니다. 하지만 모델 내부의 perception-to-action과 하네스 외부에서의 capability-modulation은 별개의 것이라고 생각합니다. 전자는 단일 에이전트의 인지 루프이고, 후자는 환경 측에서 능력의 경계 그 자체를 다시 쓰는 층입니다. 외형이 비슷하기 때문에 설계자의 시야에서 누락됩니다.

네 번째는 Hashimoto 처방전의 관성입니다. '실수를 발견하면 다시는 일어나지 않도록 하네스를 고친다'는 지배적인 처방은 guide 추가나 sensor 추가로 귀결됩니다. Agency를 동적으로 다시 쓰는 방향으로는 향하지 않습니다. 개선의 에너지가 guide / sensor 사분면으로 흐르고, Agency 측은 정적인 상태로 방치됩니다.

다섯 번째는 추상의 미성숙입니다. LangGraph, Claude Agent SDK, Codex와 같은 기존 프레임워크는 도구 레지스트리 (tool registry)를 정적인 config로 취급합니다. 'sensor 발화 → 도구 레지스트리 재작성 → 다음 태스크에 반영'을 위한 표준 훅 (hook)이 없습니다. 이를 시도하려면 매번 스크래치(scratch)부터 시작해야 하므로 진입 장벽이 높습니다.

채우면 무엇이 일어나는가

이 부분을 채우면 할 수 있는 일이 달라집니다.

첫 번째는 Just-in-time capability provisioning입니다. 도구를 전부 사전에 공개하면 context bloat와 의사결정 혼란이 발생합니다. MCP를 대량으로 연결했을 때 성능이 저하되는 현상은 경험적으로도 보고되어 있습니다. 상황에 따라 도구 집합을 넣고 빼는, sensor 구동의 선택적 공개가 이를 구조적으로 해결합니다. '도구가 많을수록 좋다'에서 '지금 필요한 도구만 보인다'로 나아가는 방향입니다.

두 번째는 failure-aware action surface입니다. 동일한 도구로 N번 실패하면, 하네스가 다른 도구나 상위 서브 에이전트, 혹은 degraded mode로 전환합니다. 에이전트 버전의 circuit breaker입니다. 무한 retry 지옥이 사라집니다.

세 번째는 telemetry 구동의 tool / skill 진화입니다. sensor가 도구 사용의 실패 패턴과 성공 패턴을 관측하고, 하네스가 도구 기술, Skills의 내용, 서브 에이전트 정의 그 자체를 업데이트합니다. 이는 '개인 역량에 의존하지 않는 지속적 개선'의 구현 그 자체라고 생각합니다. 하네스가 자기 자신을 관측 데이터로 업데이트하는 폐루프 (closed loop)입니다.

네 번째는 Behavior harness의 자동화로 가는 길입니다. Böckeler가 'elephant in the room'이라고 부른 가장 어려운 영역은 도메인 특화적 (domain-specific)이기 때문에 수작업에 의존하게 됩니다. Agency × Sensors 패턴은 실제 태스크에서 관측하여 capability gap을 추출하고 action surface를 개수하는 순환을 기계화하는 길을 열어줍니다. 장인 정신에서 계통적 공학 (systematic engineering)으로 넘어가는 가교가 될 수 있다는 기대가 있습니다.

다섯 번째는 orientation tax (방향성 비용)의 절감입니다. 에이전트가 환경을 맹목적으로 grep(검색)하는 현상이 자주 발생합니다. 이에 대해, 방황을 감지하는 sensor (센서)가 RepoMapper와 같은 환경 매핑 (environment mapping) 서브 에이전트를 동적으로 주입합니다. 사전에 전부 준비하는 대신, 필요할 때 주입하는 설계입니다.

그리고 업계 전체적으로 이 사분면의 구현 패턴이 미성숙하다는 사실 자체가, 이 영역에 뛰어들 가치가 있다는 근거가 됩니다.

이곳을 열지 않으면 닫히게 되는 것들

Agency × Sensors를 공백으로 남겨두면, 하네스 (harness)의 개선 루프는 반드시 "인간이 관측 → 인간이 guide / sensor를 수동으로 업데이트"하는 방식으로 귀결됩니다. 개인의 역량에 의존하는 속인화 (individualization)에서 벗어날 경로가 없습니다. 하네스 자체가 학습 계열이 되는 길은 이 사분면을 경유할 수밖에 없다고 생각합니다. 이곳을 열지 않으면, 최종적으로는 "인간의 수작업을 자동화하는 도구"에 그치게 되며, 하네스를 학습 계열로 만드는 도달점은 닫힌 채로 남게 됩니다.

이는 지난번에 썼던 "엔지니어의 일은 목적의 번역업이다"라는 이야기와도 연결됩니다. Agency × Sensors가 기능하는 하네스에서, 엔지니어의 업무는 "개별적인 guide나 sensor를 작성하는 것"에서 "하네스의 자기 업데이트 규칙을 설계하는 것"이라는 메타 레이어 (meta-layer)로 옮겨갑니다. 번역 장치 그 자체를 설계하는 일이라고 말해도 좋을 것입니다.

구현상의 유보 사항

비정상성 (non-stationarity) 문제는 Agency의 업데이트를 에피소드 경계 (episode boundary, 태스크 완료 시)에만 허용하는 설계로 상당히 완화할 수 있다고 생각합니다. 감사성 (auditability)은 각 Agency 변경을 versioned event (버전 관리된 이벤트)로 기록하고, 트레이스 (trace)에 active surface의 해시 (hash)를 태깅하는 운용으로 확보할 수 있습니다. 안전성 (safety)은 "확장은 allowlist (허용 목록) 내에서만, 축소는 자유롭게"라는 비대칭 정책으로 담보합니다. 이 세 가지를 처음부터組み込んで(組み込んで, 포함시켜) 두면, 위에서 언급한 "재현성·감사성과의 충돌"은 실용적으로 해결할 수 있을 것입니다.

마치며

이분법은 이분법대로 일단 작동했지만, 좌표를 한 단계 늘리니 보이는 것이 달라졌습니다. 특히 왼쪽 하단의 희박함이 저의 부주의가 아니라 구조적인 것이라고 정리할 수 있었던 것이 수확이었습니다.

앞으로 Agency × Sensors를 채우기 위한 구체적인 프리미티브 (primitive)가 무엇이 될지는 저 자신도 아직 명확하지 않습니다. 동적인 툴 레지스트리 (tool registry) API일지, sensor → registry 업데이트를 위한 선언적 언어일지, 혹은 HarnessCard와 같은 감사 아티팩트 (audit artifact)와 결합한 운용 패턴일지. 이 부분은 직접 손을 움직이며 생각할 수밖에 없을 것 같습니다.

참고:

• Birgitta Böckeler, "Harness engineering for coding agent users" (martinfowler.com, 2026)
• Ryan Lopopolo (OpenAI), "Harness engineering: leveraging Codex in an agent-first world" (2026)
• "Harness Engineering for Language Agents: The Harness Layer as Control, Agency, and Runtime" (Preprints, 2026년 3월)

유보: Mitchell Hashimoto의 harness engineering 제창 시기에 대해, 소스 간에 2025년 2월과 2026년 2월이 혼재되어 있습니다. 본고의 논의에는 영향을 미치지 않습니다.