이 글은 3부작의 1편입니다. ① 하네스 엔지니어링이란 무엇인가(이 글) → ② 루프 엔지니어링이란 무엇인가 → ③ 그래서 어떻게 쓰이고 있는가
들어가며: 같은 모델인데 왜 결과가 다른가
Claude Code나 Cursor, Codex를 팀에서 함께 쓰다 보면 이상한 일을 겪습니다. 같은 모델을 쓰는데 어떤 사람은 에이전트에게 큰 작업을 통째로 맡겨 두고 커피를 마시러 가고, 어떤 사람은 매 단계 손으로 붙잡고 있어도 자꾸 엉뚱한 결과가 나옵니다. 모델은 같습니다. 그렇다면 차이는 어디서 오는 걸까요.
차이는 모델이 아니라 모델을 둘러싼 것에서 옵니다. 어떤 도구를 쥐여 줬는지, 프로젝트 규칙을 어디에 적어 뒀는지, 테스트가 얼마나 빨리 에이전트에게 "틀렸다"고 알려 주는지, 컨텍스트가 꽉 찼을 때 무엇을 버리고 무엇을 남기는지. 이 "둘러싼 것" 전체를 부르는 이름이 최근 생겼습니다. 하네스(harness), 그리고 그것을 설계하는 일을 하네스 엔지니어링(harness engineering)이라고 부릅니다.
이 글은 그 개념을 처음부터 풀어냅니다. 하네스가 무엇인지, 왜 필요한지, 실제로 무엇이 그 안에 들어가는지, 그리고 흩어진 부품들을 어떻게 하나의 그림으로 정리해서 생각할지를 봅니다. 마지막에는 한국어 소개 글에서 거의 예외 없이 반복되는 한 문장 — "모델이 아니라 하네스가 성능을 정한다" — 이 실제 측정과 얼마나 맞는지도 따져 봅니다.
이 글은 2편으로 이어집니다. 하네스가 에이전트 하나가 돌아가는 환경이라면, 그 환경을 타이머 위에 올려 스스로 돌게 만든 것이 루프입니다. 하지만 그건 다음 글의 이야기이고, 먼저 환경 자체를 이해해야 합니다.
하네스란 무엇인가
가장 간결한 정의는 LangChain의 Vivek Trivedy가 내놓은 등식입니다.
Agent = Model + Harness. If you're not the model, you're the harness.
에이전트는 모델과 하네스의 합이고, 모델이 아닌 것은 전부 하네스라는 것입니다. 그는 하네스를 이렇게 풀어 씁니다.
The model contains the intelligence and the harness is the system that makes that intelligence useful.
모델은 지능을 담고 있고, 하네스는 그 지능을 쓸모 있게 만드는 시스템이라는 것입니다. 조금 더 기술적으로 옮기면 하네스는 "모델 자체가 아닌 모든 코드, 설정, 실행 로직(every piece of code, configuration, and execution logic that isn't the model itself)"입니다.
여기서 핵심 통찰은 하네스가 모델을 똑똑하게 만드는 게 아니라는 점입니다. Trivedy의 표현을 빌리면 하네스의 목표는 다른 데 있습니다.
The goal of a harness is to mold the inherently spiky intelligence of a model for tasks we care about.
모델의 지능은 본래 들쭉날쭉(spiky)합니다. 어떤 문제는 놀랍도록 잘 풀고 어떤 문제는 어이없게 틀립니다. 하네스가 하는 일은 그 뾰족뾰족한 지능을 우리가 원하는 과제의 모양으로 성형(mold)하는 것입니다. 그는 하네스 엔지니어링이 무엇에 관한 것인지도 한 문장에 담습니다. "시스템에 관한 것이고, 과제 성능·토큰 효율·지연시간 같은 목표를 최적화하도록 모델 주위에 도구를 짓는 일(you're building tooling around the model to optimize goals like task performance, token efficiency, latency)"이며, 그 설계 결정에는 "시스템 프롬프트, 도구 선택, 실행 흐름"이 포함됩니다.
이 정의를 붙잡고 나면 앞의 질문이 다시 보입니다. 같은 모델을 쓰는데 결과가 다른 이유는, 두 사람이 서로 다른 하네스 안에서 그 모델을 돌리고 있기 때문입니다. 모델은 공유 자원이고, 하네스는 각자가 만드는 것입니다.
왜 필요한가: 하나의 희소성 문제
하네스가 왜 필요한지는 컴포넌트를 나열하기 전에 먼저 이해해야 합니다. 그렇지 않으면 하네스는 그냥 기능들의 잡동사니처럼 보이기 때문입니다. 실제로는 그렇지 않습니다. 하네스의 거의 모든 부품은 하나의 희소성 문제에 대한 답입니다.
그 문제는 컨텍스트입니다. Claude Code의 공식 문서는 자신의 권장 사항 대부분이 단 하나의 제약에서 나온다고 말합니다.
Most best practices are based on one constraint: Claude's context window fills up fast, and performance degrades as it fills.
컨텍스트 윈도가 빠르게 차고, 차오를수록 성능이 떨어진다는 것입니다. 문서는 컨텍스트 윈도를 "가장 중요하게 관리해야 할 자원", "근본 제약(fundamental constraint)"이라고 부릅니다.
이 제약이 특히 아프게 드러나는 곳이 오래 도는 에이전트입니다. Anthropic은 이 문제를 교대 근무에 비유합니다.
The core challenge of long-running agents is that they must work in discrete sessions, and each new session begins with no memory of what came before. Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.
긴 작업은 여러 세션에 걸쳐 진행되는데, 각 세션은 이전 세션의 기억 없이 시작합니다. 마치 교대 근무로 돌아가는 프로젝트에서, 새로 출근한 엔지니어가 앞 교대조가 무엇을 했는지 전혀 모르는 채로 도착하는 것과 같습니다. 이 비유가 하네스가 존재하는 이유를 가장 정확하게 보여 줍니다. 하네스는 그 교대 조들 사이에 남겨 두는 인수인계 노트이자, 각자에게 쥐여 주는 매뉴얼이자, 잘못을 짚어 주는 검사 장치입니다.
Anthropic이 특히 정직한 대목은 자기 제품의 기능만으로는 부족하다고 인정하는 부분입니다.
However, compaction isn't sufficient.
컨텍스트가 차면 요약해서 넘기는 기능(compaction)을 자사 SDK가 제공하지만, 그것만으로는 부족하다는 것입니다. 고수준 프롬프트 하나("claude.ai 클론을 만들어 줘")만 주면, 프론티어 모델조차 프로덕션 품질의 웹앱을 완성하지 못하고 중간에 무너진다고 그들은 관찰합니다. 그 관찰에서 나온 것이 하네스 엔지니어링입니다.
무엇이 들어가나
이제 하네스에 실제로 무엇이 들어가는지 봅니다. 위의 희소성 문제를 기억하면서 읽으면, 각 부품이 그 문제의 어느 측면에 답하는지가 보입니다.
컨텍스트 관리
첫 번째 묶음은 컨텍스트를 아껴 쓰는 기술입니다.
Compaction(압축). 대화가 컨텍스트 한계에 가까워지면 지금까지의 내용을 요약해서 새 윈도를 그 요약으로 다시 시작합니다. Anthropic은 여기서 어려운 부분이 요약 자체가 아니라 선택이라고 짚습니다.
The art of compaction lies in the selection of what to keep versus what to discard, as overly aggressive compaction can result in the loss of subtle but critical context whose importance only becomes apparent later.
무엇을 남기고 무엇을 버릴지가 기술의 핵심이며, 지나치게 공격적으로 압축하면 당장은 사소해 보이지만 나중에야 중요성이 드러나는 맥락을 잃는다는 것입니다. 압축은 공짜가 아니라 손실적이고, 그 손실은 뒤늦게 발견됩니다. 대부분의 소개 글이 빼먹는 정직한 부분입니다.
Context rot(컨텍스트 부패). 컨텍스트는 무한정 채운다고 좋아지지 않습니다. Anthropic은 이를 "감소하는 한계 수익을 가진 유한 자원"으로 다뤄야 한다고 말하며, 토큰 수가 늘어날수록 모델이 그 안의 정보를 정확히 회상하는 능력이 떨어지는 현상을 context rot이라 부릅니다. 컨텍스트를 예산처럼 관리해야 하는 이유입니다.
Just-in-time(적시 로딩). 그래서 좋은 하네스는 모든 것을 미리 밀어 넣지 않습니다. 대신 가벼운 식별자(파일 경로, 저장된 쿼리, 링크)만 들고 있다가 필요할 때 도구로 데이터를 불러옵니다. 페이로드보다 포인터를 선호하는 것입니다. 한국 개발자에게는 lazy loading의 발상과 정확히 같습니다.
서브에이전트(sub-agent). 여기서 서브에이전트가 왜 병렬화 도구이기 전에 컨텍스트 도구인지가 드러납니다.
Each subagent might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens).
서브에이전트는 수만 토큰을 써 가며 탐색하지만, 돌아올 때는 1,000~2,000 토큰짜리 압축된 요약만 가져옵니다. 대략 10:1 이상의 압축입니다. 무거운 탐색 비용을 메인 윈도 바깥에 격리해 두는 장치인 셈입니다.
도구 설계
두 번째 묶음은 도구입니다. 여기서 흔한 오해 하나가 깨집니다. 도구 설명은 단순한 문서가 아니라 컨텍스트에 로딩되는 프롬프트입니다.
Because these are loaded into your agents' context, they can collectively steer agents toward effective tool-calling behaviors. Even small refinements to tool descriptions can yield dramatic improvements.
도구 설명이 에이전트의 컨텍스트에 들어가기 때문에, 그것들이 모여서 에이전트의 도구 사용 행동을 유도하며, 설명을 조금만 다듬어도 극적인 개선이 나온다는 것입니다. Anthropic은 도구를 설명할 때 "팀에 새로 온 동료에게 이 도구를 어떻게 설명할지 생각하라"고 조언합니다. 도구를 만드는 일은 API를 노출하는 일이 아니라 프롬프트를 쓰는 일에 가깝습니다.
세션 간 상태
세 번째 묶음은 교대 조들 사이에 남기는 기록입니다. Anthropic이 오래 도는 에이전트에서 관찰한 두 가지 실패 패턴이 이 부품의 필요성을 정확히 보여 줍니다. 첫째는 한 번에 너무 많이 하려다(one-shot 시도) 구현 중간에 컨텍스트가 소진되어, 다음 세션이 반쯤 만들다 만 문서 없는 기능을 물려받는 경우입니다. 둘째는 나중 세션이 둘러보고 진척이 있으니 다 됐다고 선언해 버리는 경우입니다.
그들의 해법은 두 부분입니다. 첫 세션은 초기화 에이전트로서 환경을 세팅합니다. init.sh 스크립트, 에이전트들이 무엇을 했는지 기록하는 claude-progress.txt, 그리고 어떤 파일이 추가됐는지 보여 주는 최초 git 커밋을 만듭니다. 이후 모든 세션은 코딩 에이전트로서 점진적으로 진척을 내고 구조화된 갱신을 남깁니다. 이 작고 구체적인 산출물 목록 — init.sh, claude-progress.txt, git 커밋 — 이 "하네스에 실제로 무엇이 들어가는가"의 가장 손에 잡히는 답입니다.
정리하는 격자: 가이드와 센서
여기까지 오면 부품이 꽤 쌓입니다. 컨텍스트 관리, 도구 설계, 상태 기록. 이것들을 어떻게 하나의 그림으로 정리할 수 있을까요. 이 문헌에서 가장 유용한 개념 어휘를 내놓은 사람은 Thoughtworks의 Birgitta Böckeler입니다. (그의 글이 martinfowler.com에 실려 있어 종종 "마틴 파울러가 말하길"로 잘못 인용되는데, 파울러의 글이 아니라 그의 사이트에 실린 Böckeler의 글입니다.)
Böckeler는 하네스의 구성 요소를 두 가지 독립된 기준으로 나눕니다. 첫 번째 기준은 언제 작동하는가입니다.
Guides (feedforward controls) - anticipate the agent's behaviour and aim to steer it before it acts. Sensors (feedback controls) - observe after the agent acts and help it self-correct.
가이드(guide)는 피드포워드 제어입니다. 에이전트가 행동하기 전에 미리 방향을 잡아 줍니다. 첫 시도에서 좋은 결과가 나올 확률을 높이는 것입니다. AGENTS.md에 적힌 코딩 규칙, 스킬에 담긴 절차가 여기 속합니다. 센서(sensor)는 피드백 제어입니다. 에이전트가 행동한 후에 관찰해서 스스로 고치도록 돕습니다. 테스트, 린터, CI가 여기 속합니다.
이 어휘가 좋은 이유는 그것이 소프트웨어 은어가 아니라 제어이론에서 왔기 때문입니다. 피드포워드와 피드백은 온도 조절기든 자동차든 어디에나 있는 개념이라 잘 옮겨집니다.
두 번째 기준은 무엇이 그것을 실행하는가입니다.
Computational - deterministic and fast, run by the CPU. Tests, linters, type checkers, structural analysis. Inferential - Semantic analysis, AI code review, 'LLM as judge'. Typically run by a GPU or NPU.
계산형(computational)은 결정론적이고 빠르며 CPU가 돌립니다. 테스트, 린터, 타입 체커, 구조 분석입니다. Böckeler는 이들이 "밀리초에서 초 단위로 돌고 결과가 신뢰할 만하다"고 말합니다. 추론형(inferential)은 의미 분석, AI 코드 리뷰, LLM을 심판으로 쓰는 것으로, 보통 GPU나 NPU가 돌립니다. 이쪽은 "더 느리고 더 비쌉니다."
이 두 번째 기준이 이 문헌 전체에서 가장 날카로운 절단입니다. CPU 대 GPU라는 하드웨어 프레이밍이 트레이드오프를 철학이 아니라 물리로 만들기 때문입니다. 결정론적·빠름·신뢰할 만함 대 의미론적·느림·비쌈. 어떤 검사를 계산형으로 만들 수 있다면 그렇게 하는 게 대체로 낫고, 계산형으로 표현할 수 없는 것만 추론형에 맡깁니다.
두 기준을 교차하면 앞서 나온 부품들이 자리를 찾습니다. AGENTS.md와 스킬은 가이드이면서 대개 추론형입니다. 테스트·린터·타입 체커는 센서이면서 계산형입니다. AI 코드 리뷰나 검증용 서브에이전트는 센서이면서 추론형입니다. 흥미로운 점은 같은 산출물이 쓰임에 따라 다른 칸에 들어간다는 것입니다. 예컨대 스킬은 코딩 규칙을 담으면 가이드가 되고, 리뷰 방법을 담으면 센서가 됩니다. 부품의 정체는 그것이 무엇이냐가 아니라 어떻게 쓰이느냐로 정해집니다.
그리고 이 격자는 사람의 자리도 알려 줍니다. Böckeler의 한 문장이 그것을 요약합니다.
A good harness should not necessarily aim to fully eliminate human input, but to direct it to where our input is most important.
좋은 하네스는 사람의 개입을 완전히 없애는 걸 목표로 하지 않고, 우리의 개입을 가장 중요한 곳으로 몰아주는 것을 목표로 한다는 것입니다.
실천인가 산출물인가: 589바이트짜리 파일
지금까지 하네스를 산출물처럼 다뤘습니다. 코드, 설정, 도구, 기록. 그런데 하네스 엔지니어링을 가장 먼저 정의한 사람은 그것을 산출물이 아니라 실천으로 봤습니다. Ghostty와 HashiCorp를 만든 Mitchell Hashimoto입니다.
그의 정의는 이렇습니다.
It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.
에이전트가 실수하는 것을 발견할 때마다, 그 에이전트가 다시는 같은 실수를 하지 않도록 해결책을 공들여 만들어 두는 일. 이것은 명사가 아니라 동사이고, 물건이 아니라 습관입니다. 그가 앞 문단에서 밝힌 목표를 보면 방향이 더 분명해집니다. "에이전트는 첫 번에 맞는 결과를 낼 때 훨씬 효율적이며, 그렇게 만드는 가장 확실한 방법은 에이전트가 틀렸을 때 자동으로 알려 주는 빠르고 질 좋은 도구를 쥐여 주는 것"입니다. 수리는 방법이고, 목적은 빠른 오류 신호입니다.
그는 이 실천이 두 가지 형태를 띤다고 말합니다. 하나는 AGENTS.md 같은 파일을 통한 암묵적 프롬프팅이고, 다른 하나는 실제로 프로그래밍된 도구(스크린샷 스크립트, 필터링된 테스트 실행 등)입니다. 그리고 도구를 만들면 반드시 AGENTS.md에 그 존재를 알려야 한다고 덧붙입니다. 에이전트가 모르는 도구는 하네스가 아니기 때문입니다.
여기서 이 글에서 가장 인상적인 한 문장이 나옵니다. 그는 자기 프로젝트 Ghostty의 AGENTS.md를 예로 들며 이렇게 씁니다.
Each line in that file is based on a bad agent behavior, and it almost completely resolved them all.
그 파일의 모든 줄이 에이전트의 나쁜 행동 하나하나에 기반한다는 것입니다. 이 문장이 실천과 산출물의 관계를 정확히 보여 줍니다. AGENTS.md는 처음부터 완성해서 내려놓는 스타일 가이드가 아니라, 에이전트가 실수할 때마다 한 줄씩 쌓인 사고 기록부입니다. 산출물은 실천의 퇴적물입니다.
이 점이 얼마나 구체적인지는 그가 링크한 실제 파일을 보면 알 수 있습니다. Ghostty의 src/inspector/AGENTS.md는 그 시점에 589바이트, 네 줄짜리 파일이었고, 레포 루트가 아니라 인스펙터 서브시스템에만 적용되는 파일이었습니다.
# Inspector Subsystem
The inspector is a feature of Ghostty that works similar to a browser's developer tools.
It allows the user to inspect and modify the terminal state.
- See the full C API by finding `dcimgui.h` in the `.zig-cache` folder in the root
- See full examples of how to use every widget by loading the imgui demo file
- On macOS, run builds with `-Demit-macos-app=false`이 작은 파일이 "AGENTS.md는 거대한 스타일 가이드여야 한다"는 오해를 혼자서 무너뜨립니다. 좋은 하네스 아티팩트는 크지 않습니다. 작고, 구체적이고, 각 줄에 사연이 있습니다.
그렇다면 하네스는 실천인가 산출물인가. 답은 둘 다이며, 두 정의는 모순이 아니라 서로 다른 질문에 답합니다. Trivedy의 "모델이 아닌 모든 것"은 하네스가 무엇이냐에 답하고, Hashimoto의 "실수를 발견할 때마다 고쳐 넣는 규율"은 하네스 엔지니어링이 무엇이냐에 답합니다. 589바이트짜리 파일은 산출물이고, 그 네 줄이 각각 어떤 실수에서 나왔는지가 실천입니다. 이 둘을 뭉개면 하네스 엔지니어링은 "AGENTS.md 잘 쓰는 법" 정도로 쪼그라듭니다. 실천이 산출물을 만들지, 산출물이 실천을 대신하지 않습니다.
Hashimoto가 이 절을 닫는 문장에도 짚어 둘 대목이 있습니다. 그는 자기 작업을 이렇게 요약합니다. "나쁜 짓을 볼 때마다 다시는 못 하게 막으려 애쓰고, 거꾸로(conversely) 좋은 일을 하고 있음을 에이전트가 스스로 검증할 수 있게 만들려 애쓴다." 하네스 엔지니어링은 사후 수리만이 아니라 사전 검증 장치를 심는 일이기도 합니다. 이 "스스로 검증한다"는 대목은 3편의 핵심 주제로 다시 등장합니다.
그래서 모델보다 중요한가
이제 이 글을 쓴 이유에 도착했습니다. 하네스를 다루는 한국어 소개 글은 거의 예외 없이 한 문장을 담습니다. "모델이 아니라 하네스가 성능을 정한다." 그럴듯하게 들리고, 실제로 이 담론을 퍼뜨린 동력이기도 합니다. 그런데 이 문장은 얼마나 사실일까요.
이 주장을 지지하는 가장 강한 실측은 앞서 나온 Trivedy의 것입니다.
We used a simple recipe to iteratively improve deepagents-cli (our coding agent) 13.7 points from 52.8 to 66.5 on Terminal Bench 2.0. We only tweaked the harness and kept the model fixed, gpt-5.2-codex.
모델을 gpt-5.2-codex로 고정하고 하네스만 바꿔서, Terminal Bench 2.0 점수를 52.8에서 66.5로 13.7점 끌어올렸다는 것입니다. 당시 리더보드 기준으로 Top 30 밖에서 Top 5로 올라간 폭입니다. 인상적인 숫자입니다. 다만 곧바로 조건을 붙여야 합니다. 이것은 자기 제품을 개선한 자가 보고이고, 단일 벤더의 결과이며, 독립적으로 재현된 적이 없습니다. 그리고 순위는 글 작성 시점의 리더보드에 대한 것이라 지금도 같다는 뜻이 아닙니다.
그런데 이 문제를 더 넓게 측정한 소스들은 오히려 반대 방향을 가리킵니다. Terminal-Bench를 만든 연구진은 논문 본문에서 이렇게 말합니다.
model selection is usually more important than agent scaffold.
모델 선택이 대체로 에이전트 스캐폴드보다 더 중요하다는 것입니다. Anthropic도 자사의 연구 에이전트 분석에서 비슷한 결론을 냅니다. Claude Sonnet 3.7의 토큰 예산을 두 배로 늘리는 것보다 Sonnet 4로 모델을 업그레이드하는 편이 성능 이득이 더 컸다고요.
한편 같은 Terminal-Bench 데이터는 하네스가 큰 차이를 만든다는 것도 보여 줍니다. 동일한 Gemini 2.5 Pro 모델을 OpenHands 스캐폴드에서 돌리면 15.7%, Terminus 2 스캐폴드에서 돌리면 32.6%가 나옵니다. 16.9%포인트 차이입니다. 스캐폴드만 바꿨는데 점수가 두 배가 됩니다.
두 그림이 충돌하는 것처럼 보입니다. 하나는 "모델이 더 중요하다"고 하고, 다른 하나는 "하네스만 바꿔도 두 배가 된다"고 합니다. 그리고 여기서 정직하게 인정할 것이 하나 더 있습니다. 하네스의 기여도를 다른 모든 조건을 고정한 채 분리해 낸 통제된 독립 실험은 존재하지 않습니다. 리더보드의 각 행은 스캐폴드만 다른 게 아니라 시도 횟수, 노력의 정도, 비용, 프롬프팅이 함께 다릅니다. "하네스가 모델보다 중요하다"는 명제는 끊임없이 주장되지만 느슨하게만 측정됩니다.
그렇다면 어떻게 정리해야 할까요. 필자가 보기에 두 그림은 사실 모순이 아닙니다. 모델은 천장을 정하고, 하네스는 그 천장 아래에서 지금 손에 있는 모델로부터 실제로 얼마나 뽑아낼지를 정합니다. Gemini 2.5 Pro의 천장은 정해져 있지만, 그 천장의 절반을 쓸지 전부를 쓸지는 하네스가 가릅니다. 더 나은 모델이 나오면 천장이 올라가고, 그건 하네스가 할 수 있는 어떤 일보다 큰 도약일 수 있습니다.
하네스 엔지니어링이 중요한 진짜 이유는 그것이 모델보다 커서가 아닙니다. 그것이 당신이 바꿀 수 있는 쪽이기 때문입니다. 다음 모델이 언제 나올지는 당신이 정하지 못하지만, 오늘의 모델을 감싼 환경은 오늘 바꿀 수 있습니다. "모델보다 중요하다"는 슬로건은 과장이지만, "당신이 손댈 수 있는 유일한 레버"라는 관찰은 정확합니다.
누가 이 이름을 붙였나
마지막으로 이 용어가 어디서 왔는지를 짧게 짚고 넘어가겠습니다. 흥미로운 점은 여기에 깔끔한 답이 없다는 것, 그리고 그 없음 자체가 이 분야의 성격을 말해 준다는 것입니다.
이 개념을 정리한 유명한 글들은 2026년 봄에 몰려 있습니다. Hashimoto가 2월 초에 정의를 내놓았고, OpenAI와 LangChain의 Trivedy, Thoughtworks의 Böckeler가 그 뒤 몇 주 안에 각자 이 주제를 다뤘으며, Addy Osmani가 4월에 가장 널리 읽히는 정리를 썼습니다. 그런데 이들은 서로를 거의 인용하지 않습니다. 각자 자기 자리에서 같은 것에 이름을 붙였을 뿐입니다.
더 흥미로운 건 그 이름이 에세이보다 먼저 태어났다는 점입니다. agent harness라는 명사는 이미 2024년 12월의 어느 벤치마크 유틸리티 저장소에서 커밋 메시지("make agent harness async")와 디렉터리 이름으로 쓰이고 있었습니다. harness engineering이라는 분야명은 2025년 12월 말 어느 개인 연구 노트의 커밋에 "Harness engineering = how you integrate with tools"라는 형태로 이미 등장했습니다. 에세이가 아니라 git 로그입니다.
그래서 Hashimoto가 2월에 "이걸 가리키는 업계 통용어가 있는지 모르겠지만 나는 이렇게 부르게 됐다"고 쓴 대목이 각별합니다.
I don't know if there is a broad industry-accepted term for this yet, but I've grown to calling this "harness engineering." … I don't need to invent any new terms here; if another one exists, I'll jump on the bandwagon.
그가 이렇게 썼을 때, 그 말은 이미 최소 몇 주 전부터 여기저기서 쓰이고 있었습니다. 그는 몰랐고, 그래서 "새 용어를 발명할 필요는 없다, 다른 게 있으면 갈아타겠다"는 그의 태도는 겸양이 아니라 정확히 옳은 것이었습니다.
용어는 누군가 선포해서 생기지 않았습니다. 커밋 메시지와 디렉터리 이름에서 먼저 굳어지고, 여러 사람이 비슷한 시기에 같은 필요를 느껴 각자 이름을 붙이면서 침전됐습니다. "누가 하네스 엔지니어링을 만들었나"라는 질문은 이 용어가 생겨난 방식과 애초에 맞지 않습니다. 그리고 이것은 기술 용어가 실무의 압력에서 자라날 때 흔히 일어나는 일이기도 합니다.
정리
이 글의 요지를 추리면 이렇습니다.
하네스는 에이전트에서 모델이 아닌 모든 것입니다. 코드, 설정, 도구, 규칙, 검사 장치. 그것이 하는 일은 모델을 똑똑하게 만드는 게 아니라, 본래 들쭉날쭉한 지능을 우리가 원하는 과제의 모양으로 성형하는 것입니다.
하네스가 필요한 이유는 하나의 희소성 문제로 수렴합니다. 컨텍스트는 유한하고 차오를수록 성능이 떨어지며, 오래 도는 작업은 기억 없이 교대하는 조들의 연속입니다. 하네스의 부품 대부분 — 압축, 적시 로딩, 서브에이전트 격리, 상태 파일 — 은 이 문제에 대한 답입니다.
흩어진 부품은 Böckeler의 두 기준으로 정리됩니다. 행동 전에 잡아 주는 가이드와 행동 후에 관찰하는 센서, 그리고 결정론적이고 빠른 계산형과 의미론적이고 비싼 추론형. 이 격자가 무엇을 어디에 둘지를 알려 줍니다.
하네스는 산출물이면서 실천입니다. Hashimoto의 589바이트짜리 파일이 보여 주듯, 좋은 아티팩트는 실수 하나하나가 쌓인 사고 기록부이지 처음부터 완성해 내려놓는 문서가 아닙니다.
그리고 "모델보다 하네스가 중요하다"는 슬로건은 절반만 맞습니다. 모델이 천장을 정하고 하네스가 그 아래를 정합니다. 하네스가 중요한 이유는 모델보다 커서가 아니라, 오늘 당신이 바꿀 수 있는 유일한 쪽이기 때문입니다.
이제 질문 하나가 남습니다. 지금까지의 하네스는 에이전트 하나가 한 번 도는 환경이었습니다. 이 환경을 타이머 위에 올려 스스로 돌게 하고, 작은 조수들을 낳게 하고, 스스로 먹이를 주게 하면 어떻게 될까요. 그것이 다음 글의 주제, 루프 엔지니어링입니다.
이 글에서 다루지 못한 주제
이 글은 하네스의 정의, 필요, 구성, 정리 틀, 그리고 "모델 대 하네스" 논쟁을 다뤘습니다. 다음 주제들은 분량과 초점 때문에 이어지는 글로 넘겼습니다.
- 하네스를 반복 실행하는 시스템(automation, worktree, 스케줄)의 설계 — 2편 루프 엔지니어링.
- 검증 장치가 실제로 얼마나 믿을 만한가, 자기 코드를 검증하는 에이전트가 왜 실패하는가 — 3편. 이 글의 "센서", 특히 추론형 센서의 신뢰성 문제가 그 글의 핵심입니다.
- Trivedy가 하네스를 개선하기 위해 쓴 자동 분석 루프(트레이스를 모아 병렬로 오류를 분석하고 하네스에 반영하는 방법)의 상세 — 2편·3편에서 실전 맥락으로 다룹니다.