Harness, Loop, and Graph Engin
AI & HCI프롬프트 엔지니어링 다음에 나온 세 용어, 결국 같은 질문을 다른 해상도에서 묻고 있다.
Posted on Aug. 2, 2026, 7:09 a.m. by
SANGJIN
A short explainer piece on three terms that emerged in rapid succession in 2026 — harness engineering, loop engineering, and graph engineering — and how they relate to each other.
The core claim: all three are attempts to achieve predictable, consistently high-quality output for repetitive agentic tasks through control — the difference is only in what gets controlled and at what unit of granularity.
| Term | Controls | Unit |
|---|---|---|
| Harness Engineering | The execution environment around an agent | Tools, memory, sandbox, verification logic (conceptual) / Specs, skills, subagents, workflows, hooks, checklists (practical) |
| Loop Engineering | One agent's behavioral cycle | Observe → reason → act → evaluate |
| Graph Engineering | Relationships between multiple agents/loops | Nodes and edges, state handoff |
Key points covered
- Harness engineering — coined by Mitchell Hashimoto (HashiCorp/Terraform) in Feb 2026, popularized further by OpenAI and Anthropic engineering posts. Core idea: "leave the model alone, change what surrounds it." In practice (e.g. Claude Code), a harness is built from concrete pieces — specs (AGENTS.md/CLAUDE.md), skills, subagents, workflows, hooks, and checklists — which map onto the more abstract five-component framing (filesystem, code execution, sandbox, memory, context management).
- Loop engineering — designing the repeating observe-reason-act-evaluate cycle a single agent runs autonomously. Distinguished from a fixed "chain" (A→B→C) by its ability to retry and adapt. Well-designed loops need clear termination conditions, tool access, context management, explicit failure exits, and genuine error adaptation (not blind retries).
- Graph engineering — the newest and least settled term. Wires multiple agents/loops into an explicit node-and-edge structure so failures can be localized to a specific node. Not a replacement for loops — a graph node can still run its own internal loop.
- The three layers stack, not replace each other. Building a graph doesn't remove the loops inside its nodes, and loops still run inside a harness.
2026년 몇 달 간격으로 연달아 등장한 세 용어 — 하네스 엔지니어링, 루프 엔지니어링, 그래프 엔지니어링 — 이 서로 어떻게 연결되는지 정리한 짧은 개념 글이다.
핵심 주장: 세 용어 모두 반복적인 작업에 대해 예측 가능하고 일정한 품질의 결과물을, 적절한 통제를 통해 달성하려는 시도다. 차이는 무엇을 통제 대상으로 삼고, 어느 단위에서 개입하느냐뿐이다.
| 용어 | 통제 대상 | 통제 단위 |
|---|---|---|
| 하네스 엔지니어링 | 에이전트를 둘러싼 실행 환경 | (개념) 도구·메모리·샌드박스·검증 로직 / (실무) 스펙·스킬·서브에이전트·워크플로우·훅·체크리스트 |
| 루프 엔지니어링 | 한 에이전트의 행동 사이클 | 관찰 → 추론 → 행동 → 평가 |
| 그래프 엔지니어링 | 여러 에이전트/루프 간의 관계 | 노드와 엣지, 상태 전달 |
핵심 내용
- 하네스 엔지니어링 — 2026년 2월 미첼 해시모토(HashiCorp/Terraform)가 처음 알렸고, 이후 OpenAI·Anthropic 엔지니어링 블로그로 확산됐다. 핵심은 "모델은 그대로 두고, 모델을 둘러싼 것을 바꾼다"는 관점. 실무(예: Claude Code)에서는 스펙 (AGENTS.md/CLAUDE.md), 스킬, 서브에이전트, 워크플로우, 훅, 체크리스트 같은 구체적 요소로 구현되며, 이는 좀 더 추상적인 다섯 가지 구성 요소(파일시스템·코드 실행· 샌드박스·메모리·컨텍스트 관리)와 같은 대상을 다른 해상도로 본 것이다.
- 루프 엔지니어링 — 하나의 에이전트가 자율적으로 도는 관찰-추론-행동-평가 사이클을 설계하는 일. 정해진 순서로만 도는 "체인"과 달리 재시도·적응이 가능하다는 게 차이. 잘 설계된 루프는 명확한 종료 조건, 도구 접근, 컨텍스트 관리, 명시적 실패 탈출 조건, 같은 실패를 반복하지 않는 진짜 오류 적응을 갖춘다.
- 그래프 엔지니어링 — 세 용어 중 가장 최근에, 가장 합의가 덜 된 상태로 등장했다. 여러 에이전트/루프를 노드-엣지 구조로 명시적으로 연결해서 실패를 특정 노드로 국소화할 수 있게 한다. 루프를 대체하는 게 아니라, 그래프의 한 노드 안에서도 여전히 자체 루프가 돌 수 있다.
- 세 층위는 대체가 아니라 누적된다. 그래프를 설계해도 그 안의 루프는 사라지지 않고, 루프는 여전히 하네스 위에서 돈다.
Leave a Comment: