Loop Engineering vs Harness Engineering:
AI 코딩 에이전트의 새로운 패러다임
2026년, AI 코딩 에이전트 업계에 새로운 키워드가 등장했습니다. Loop Engineering입니다. Google 엔지니어 Addy Osmani가 자신의 블로그에서 개념화한 이 용어는, 불과 며칠 만에 개발자 커뮤니티에서 뜨거운 논쟁을 불러일으켰습니다.
그런데 잠깐. 몇 달 전만 해도 Harness Engineering이라는 개념이 같은 커뮤니티를 뜨겁게 달궜었죠. 둘의 차이는 무엇일까요? 새로운 buzzword일 뿐일까요, 아니면 진짜 패러다임 전환일까요?
이 글에서는 두 개념을 깊이 파헤치고, 실제 코드 예제와 함께 그 차이를 명확히 정리해보겠습니다.
1. 🏗️ Harness Engineering — 에이전트의 엔진룸을 설계하라
Harness Engineering의 핵심 전제는 간단합니다. "좋은 harness를 가진 평범한 모델이, 나쁜 harness를 가진 좋은 모델을 이긴다." 실제로 Terminal Bench 2.0에서 같은 Claude Opus 4.6 모델이 harness에 따라 Top 30 → Top 5로 성능이 극적으로 변화한 사례가 이를 증명합니다.
Harness가 포함하는 것
- 시스템 프롬프트 — AGENTS.md, CLAUDE.md, SKILL.md 등 프로젝트 컨텍스트
- Tools — filesystem 접근, bash 실행, 브라우저, 샌드박스
- Connectors — MCP 서버 설정 (이슈 트래커, DB, Slack 연동)
- Hooks — compaction, lint 검사, 연속성 관리, 사전/사후 처리
- Observability — 로깅, 비용/지연 시간 측정, 추적
- Memory — 검색 기능, 컨텍스트 로트(Rot) 방지
Ratchet 원칙
에이전트가 실수할 때마다 그 실수를 영구적인 시스템 신호로 전환하라:
- 에이전트가 주석 처리된 테스트를 PR에 포함 → AGENTS.md에 "절대 테스트를 주석처리 하지 말고, 지우거나 수정하라" 추가
- pre-commit hook에서
.skip(이나xit(패턴 차단 - 리뷰어 sub-agent가 주석 처리된 테스트를 blocker로 플래그
규칙: 실제 실패를 본 후에만 제약을 추가하고, 모델이 불필요하게 만든 후에만 제거한다.
2. 🔁 Loop Engineering — 당신을 프롬프터 자리에서 해방시켜라
Loop Engineering은 한 차원 위의 개념입니다. Harness가 "에이전트가 실행되는 환경"이라면, Loop는 "그 환경을 언제, 왜, 어떤 목표로 실행할지 결정하는 외부 오케스트레이터"입니다.
쉽게 말해: 당신은 더 이상 직접 프롬프트를 입력하지 않습니다. 대신, 당신을 대신해 프롬프트를 생성하고 실행하고 검증하는 시스템(루프)을 설계합니다.
세 가지 레이어의 진화
| 레이어 | 최적화 대상 | 작업 단위 |
|---|---|---|
| Prompt Engineering (과거) |
하나의 지시를 어떻게 잘 적을까 | 사람이 직접 타이핑하는 하나의 턴 |
| Context Engineering (현재) |
윈도우에 무엇을 넣을까: 문서, 히스토리, 도구 정의 | 하나의 답변을 위한 조건 설계 |
| 🔁 Loop Engineering (미래) |
무엇을, 언제 프롬프팅할지, 결과가 acceptable한지 판단하는 시스템 | 수많은 턴에 걸친 자가 실행 사이클 |
Prompt Engineering이 사라지는 것이 아니다. Loop Engineering은 그 위에 자율 제어 구조를 추가하는 것이다. 프롬프트 품질은 여전히 중요하지만, 레버리지의 중심이 "좋은 프롬프트 한 줄"에서 "프롬프트를 생성하고 검증하는 시스템의 설계"로 이동했다.
3. 🧱 Loop의 6가지 구성 요소
Addy Osmani가 정의한 Loop는 다음 6가지 요소로 구성됩니다. Claude Code와 OpenAI Codex 모두 동일한 구조를 (이름만 다르게) 지원합니다.
① Automations — 심장박동 (Heartbeat)
스케줄 기반으로 작업을 발견하고 분류(triage)하는 트리거입니다. 사람이 "이제 시작해"라고 말할 필요가 없습니다.
| 도구 | 구현 |
|---|---|
| Claude Code | /loop (주기적 실행), /goal (조건 충족까지 실행), cron, hooks, GitHub Actions |
| OpenAI Codex | Automations 탭 (프로젝트/프롬프트/주기 설정), /goal 명령어 |
② Worktrees — 병렬 충돌 방지
여러 에이전트가 동시에 작업할 때 파일 충돌을 방지합니다. 각자 독립 브랜치 + 별도 워킹 디렉토리에서 작업합니다.
당신의 리뷰 대역폭이 여전히 병목이다. Worktree가 기계적 충돌은 막아주지만, 당신이 하루에 검토할 수 있는 PR의 양이 곧 한계다. 병렬 에이전트 수를 늘리기 전에 먼저 리뷰 프로세스를 최적화하라.
③ Skills — 프로젝트 지식의 코드화
매 세션마다 프로젝트 컨텍스트를 다시 설명하지 않도록, 영속적인 지식을 SKILL.md 파일로 저장합니다.
| 매커니즘 | 저장 대상 | 저장 위치 |
|---|---|---|
| Skill | 영속적 프로젝트 지식 (컨벤션, 빌드 방법, 의사결정 내역) | SKILL.md (프로젝트 레포) |
| Memory | 변경 가능한 상태 (무엇이 끝났는지, 무엇이 다음인지) | TODO.md, 이슈 보드 |
| Connector | 외부 도구 접근 권한 | MCP 서버 설정 |
④ Plugins & Connectors — 실제 도구와의 연결
MCP (Model Context Protocol) 기반으로 에이전트가 실제 개발 도구와 상호작용합니다. 이슈 트래커 조회, DB 쿼리, Slack 메시지 전송 등이 가능해집니다. 이것이 "이론적 제안"과 "실제로 PR을 생성하고 Slack에 알리는 루프"의 차이를 만듭니다.
⑤ Sub-Agents — Maker와 Checker의 분리
가장 중요한 구조적 결정입니다. "코드를 작성한 모델이 자기 숙제를 채점하면 너무 관대하다." 따라서 작성자(Implementer)와 검증자(Verifier)를 분리합니다.
전형적인 3분할: Explorer(탐색) → Implementer(구현) → Verifier(검증)
⑥ Memory (State) — 여섯 번째 요소
루프의 실행 간에 지속되는 상태입니다. 모델은 매 실행 사이에 모든 컨텍스트를 잊으므로, 진행 상태, TODO, 결정 내역은 반드시 디스크 위의 파일로 관리해야 합니다.
4. 🆚 결정적 차이: Harness vs Loop
이제 두 개념의 가장 중요한 차이를 표로 정리해보겠습니다.
| 기준 | 🏗️ Harness Engineering | 🔁 Loop Engineering |
|---|---|---|
| 핵심 질문 | "에이전트가 실행될 최적의 환경은?" | "에이전트를 언제, 무엇을 위해, 어떻게 검증하며 실행할까?" |
| 범위 | 단일 에이전트 인스턴스 내부 | 여러 실행에 걸친 외부 오케스트레이션 |
| 시간 스케일 | 하나의 세션 / 하나의 턴 | 여러 세션, 날짜, 스케줄 (cron, /loop) |
| 프롬프팅 주체 | 사람이 프롬프트 작성 → Harness가 실행 | Loop가 프롬프트를 생성 — 사람은 시스템만 설계 |
| 작업 단위 | 하나의 ReAct 사이클 | 수많은 ReAct 사이클을 조율 |
| 사람의 역할 | 프롬프트 엔지니어 + Harness 설계자 | Loop 설계자 — 프롬프팅에서 손을 뗌 |
| 메모리/상태 | 컨텍스트 윈도우 내 (AGENTS.md 등) | 디스크 위 (TODO.md, 진행 상태 파일) |
| 대표 요소 | MCP 서버, sandbox, hooks, compaction, observability | cron, /goal, sub-agents, worktrees, 종료 조건 |
| 실패 모드 | 에이전트가 멍청한 행동을 함 | 루프가 무한 반복, 비용 폭발, 가짜 진전 |
레이어 스택으로 보는 관계
Model + Harness = Agent.
Agent + Loop = Autonomous System.
5. 🎬 실제 워크플로우 비교 — CI 실패 분석
가장 이해하기 쉬운 예시로, 매일 아침 CI 실패를 분석하는 시나리오를 비교해보겠습니다.
❌ Old Way: 사람이 직접 프롬프팅 (Harness만 있음)
당신은 매일 아침 같은 프롬프트를 직접 타이핑하는 수동 프롬프터입니다. Harness(환경)는 잘 갖춰져 있지만, "언제 실행할지"와 "무엇을 할지"는 여전히 당신이 직접 결정합니다.
✅ New Way: Loop가 대신 프롬프팅
당신은 직접 프롬프트를 단 한 줄도 입력하지 않았습니다. 시스템(루프)이 상황을 판단하고, 적절한 프롬프트를 생성하고, 결과를 검증하고, 필요한 경우에만 당신을 호출합니다.
6. ⚠️ Loop Engineering의 5가지 실패 모드
루프가 강력한 만큼, 잘못 설계되면 그 피해도 증폭됩니다. Addy Osmani가 지적한 주요 실패 모드입니다.
| 실패 모드 | 증상 | 해결책 |
|---|---|---|
| ① 무한 루프 | 에이전트가 계속 돌지만 목표에 도달하지 못함 | 명확한 종료 조건 + 최대 반복 횟수 + 예산 제한 |
| ② 컨텍스트 오염 | 히스토리가 쌓여 토큰 한도 초과, 추론 저하 | 요약 + 오래된 이터레이션 폐기 + compaction |
| ③ 가짜 진전 | 생산적으로 보이지만 목표에 도움이 안 되는 행동 | Verifier sub-agent + 목표 정렬 검사 |
| ④ 비용 폭발 | 수백 번의 iteration, 불필요한 도구 호출 | 느린 cadence로 시작, 엄격한 예산, 모니터링 |
| ⑤ 과도한 컨텍스트 의존 | 모든 히스토리를 동등하게 중요시 → 추론 품질 저하 | Token-poor loop 설계, 검색 기반 컨텍스트 조립 |
Token-Rich Loop: 매 iteration마다 전체 컨텍스트 포함 — 실수 적지만 고비용, 느림
Token-Poor Loop: 최소 컨텍스트만 — 저비용, 빠르지만 환각/재작업 위험
Loop Engineering의 예술은 latency, cost, quality, safety 사이의 균형을 찾는 것입니다.
7. 🔗 Hermes Agent로 Loop Engineering 실현하기
흥미롭게도, 우리가 사용하는 Hermes Agent는 Loop Engineering의 많은 요소를 이미 내장하고 있습니다.
| Loop 구성 요소 | Hermes Agent 구현 |
|---|---|
| Automations (심장박동) | cronjob 도구 — 스케줄 기반 자동 실행 |
| Skills (지식 축적) | skill_manage / skill_view — SKILL.md 기반 영속 지식 |
| Sub-agents (분업) | delegate_task — 병렬/격리 서브에이전트 실행 |
| Connectors (도구 연결) | Native MCP 클라이언트 (MCP 서버 자동 등록) |
| Memory (영속 상태) | memory 도구 + session_search — 크로스세션 저장/검색 |
| Goal 기반 실행 | cronjob + skills + 조건부 deliver로 구현 가능 |
이 블로그를 읽고 계신 분의 Hermes Agent 환경에는 다음과 같은 cronjob이 이미 설정되어 있습니다:
여기서 당신은 cronjob을 한 번 설정했을 뿐입니다. 이후 매일 아침 9시, Hermes 시스템이 자동으로 프롬프트를 생성하고, 뉴스를 수집하고, 요약하고, Slack으로 전송합니다. 이것이 바로 Loop Engineering의 실제 구현입니다.
8. 🤔 커뮤니티 반응: Buzzword인가, 패러다임 전환인가?
Reddit r/myclaw 커뮤니티에서는 이 개념이 진짜인지, 아니면 "vibe coding"이나 "harness engineering"의 뒤를 잇는 또 다른 hype인지에 대한 논쟁이 있었습니다.
한 Reddit 사용자의 현실적인 평가:
또한 실제 엔드투엔드 사례가 아직 부족하다는 비판도 있습니다. 많은 업계 리더들이 개념은 이야기하지만, 구체적인 "이렇게 구현하라"는 예제는 드물다는 지적입니다.
필자의 견해: Loop Engineering은 단순한 buzzword를 넘어, AI 에이전트 개발 패러다임의 자연스러운 진화입니다. Prompt Engineering(단일 지시 최적화) → Context Engineering(컨텍스트 설계) → Loop Engineering(자율 루프 시스템 설계)으로 이어지는 흐름은, 소프트웨어 공학이 수동 작업에서 자동화로 진화해온 역사와 일치합니다.
다만 현실적으로는 모든 작업을 루프로 만들 필요는 없습니다. 창의적인 작업, 모호한 요구사항, 높은 비용의 의사결정은 여전히 사람의 개입이 필요합니다. Loop Engineering의 핵심 통찰은 "무엇을 루프에 맡기고, 무엇은 사람이 직접 할지"를 설계하는 안목에 있습니다.
9. 🎯 결론: 한 문장으로 정리
🏗️ Harness Engineering
에이전트가 똑똑하게 행동할 환경을 만드는 것
🔁 Loop Engineering
당신이 직접 프롬프팅하지 않아도
에이전트가 계속 유용한 일을 하게 만드는 시스템을 설계하는 것
즉, Harness = 에이전트 한 대의 '엔진룸'을 설계하는 것이고, Loop = 그 엔진을 '언제, 왜, 얼마나' 돌릴지 결정하는 자율 주행 시스템을 설계하는 것입니다.
두 개념은 대체 관계가 아니라 계층 관계입니다. 좋은 Loop는 좋은 Harness 위에서만 동작합니다. 그리고 좋은 Harness는 좋은 Loop가 있어야 비로소 그 잠재력을 최대한 발휘합니다.
'프로그래밍' 카테고리의 다른 글
| 파이썬 개발자 필수! VS Code 가상 환경 및 인터프리터 설정 완벽 가이드 (0) | 2026.03.06 |
|---|---|
| AI Town 완벽 가이드: 나만의 인공지능 심즈 만들기 (0) | 2026.02.13 |
| Cursor Composer 1.5 공개: 스스로 생각하는 AI 코딩의 시작 (0) | 2026.02.13 |
| 구글 WebMCP 공식 발표: 에이전트 웹(Agentic Web) 시대의 개막 (0) | 2026.02.13 |
| Antigravity IDE에서 Claude Opus 4.6 무료로 사용하는 방법 (0) | 2026.02.10 |