정의
Loop engineering은 코딩 에이전트에게 매번 사람이 직접 프롬프트를 넣는 대신, 에이전트에게 프롬프트를 공급하고 결과를 검증하며 다음 행동을 결정하는 반복 시스템 자체를 설계하는 일이다. 2026-06-14-loop-engineering의 표현으로는, 사람은 더 이상 단일 프롬프트 작성자가 아니라 “일을 찾아내고, 분배하고, 검토하고, 끝났는지 기록하고, 다음 일을 정하는 작은 시스템”의 설계자가 된다.
이 관점은 2026-05-25-agent-harness-engineering-blog가 정리한 Agent Harness Engineering과 이어진다. 하네스 엔지니어링이 단일 에이전트가 안전하게 실행되는 환경·도구·컨텍스트·검증·거버넌스 계층을 설계한다면, 루프 엔지니어링은 그 하네스를 일정, 상태, 위임, 리뷰, 재시도, 핸드오프와 묶어 계속 돌아가는 운영 루프로 만든다.
핵심 구조
| 구성 요소 | 루프에서의 역할 | 실패하면 생기는 문제 |
|---|---|---|
| 자동화 | 주기적으로 발견·분류·실행을 시작한다 | 루프가 한 번짜리 프롬프트로 되돌아간다 |
| 워크트리 | 병렬 에이전트 작업을 파일 시스템 차원에서 격리한다 | 서로의 변경을 덮어쓰고 리뷰 가능한 diff가 사라진다 |
| 스킬 | 프로젝트 규칙·빌드 절차·과거 사고를 지속 지식으로 제공한다 | 매 실행마다 맥락을 재추론하고 의도 부채가 누적된다 |
| 플러그인/커넥터 | GitHub, Linear, Slack, DB, 배포 환경 같은 실제 도구에 연결한다 | “제안”은 하지만 실제 워크플로우를 끝내지 못한다 |
| 서브에이전트 | 작성자와 검증자를 분리한다 | 만든 모델이 자기 작업을 과하게 낙관적으로 판정한다 |
| 상태/메모리 | 이전 실행의 결정, 블로커, 완료 기준을 보존한다 | 다음 실행이 항상 처음부터 시작한다 |
하네스와의 차이
- 하네스: 에이전트 한 번의 실행을 감싸는 런타임 경계다. 예: 샌드박스, MCP 도구, 컨텍스트 압축, trace, eval, permission gate.
- 루프: 여러 실행을 시간 위에 배치하는 운영 구조다. 예: 매일 triage → 워크트리별 수정안 → 독립 리뷰 → CI/eval → PR/핸드오프 → 상태 파일 갱신.
- 따라서 루프는 하네스를 대체하지 않는다. 루프는 하네스 위에서 반복, 상태, 위임, 정지 조건을 엔지니어링한다.
설계 원칙
- 정지 조건을 먼저 쓴다. “완료될 때까지”는 위험하다. 테스트, 린트, 재현 단계, 승인자, 비용 한도, 핸드오프 조건을 명시해야 한다.
- 작성자와 검사자를 분리한다. 루프가 사람 없이 잠시 돌아가려면, 최소한 구현 에이전트와 검증 에이전트의 역할이 달라야 한다.
- 상태를 대화 밖에 둔다. 마크다운 ledger, 이슈 보드, Linear, SQLite 등 무엇이든 단일 세션을 넘어 살아남아야 한다.
- 병렬성보다 리뷰 대역폭을 먼저 본다. 워크트리는 충돌을 줄이지만, 사람이 읽고 승인할 수 있는 양을 늘려주지는 않는다.
- 비용과 권한을 루프의 일부로 다룬다. 서브에이전트·장기 실행·커넥터는 토큰 비용과 blast radius를 동시에 키운다.
- 핸드오프를 실패 경로로 설계한다. 루프가 못 푸는 것은 조용히 계속 돌리지 말고, 증거와 선택지를 갖춘 decision-ready 상태로 사람에게 넘겨야 한다.
좋은 사용처
- 반복적인 이슈/PR/CI triage
- 의존성 업데이트, 린트 수정, 테스트 실패 재현 같은 좁은 유지보수 작업
- 문서/위키 ingest처럼 입력·검증·파일링 규칙이 명확한 작업
- 여러 후보안을 만들고 별도 리뷰어가 비교할 수 있는 UI/코드 개선
- 2026-06-14-steipete-maintainer-orchestrator-loop처럼 maintainer가 큐를 관리하고 워커 스레드에 일을 분배하는 레포 운영
위험 신호
- “계속 돌리면 언젠가 좋아질 것”이라는 열린 목표
- CI/eval 없이 “완료”라고 주장하는 루프
- 프로덕션 권한을 가진 커넥터가 승인 게이트 없이 붙어 있음
- 상태 파일이 없거나, 상태 파일은 있지만 사람이 읽지 않음
- 루프가 만든 코드를 이해하지 못한 채 병합하는 습관
- 토큰·시간·API 사용량 상한이 없는 야간 실행
실전 템플릿
목표: <검증 가능한 완료 상태>
입력: <읽을 이슈/로그/파일/보드>
반복 주기: <수동 / 매일 / 5분마다 / CI 실패 시>
작업자: <구현 에이전트, 리서치 에이전트, 리뷰 에이전트>
격리: <워크트리/브랜치/샌드박스>
도구 권한: <읽기 전용 / PR 생성 / 배포 금지 / 승인 필요>
검증: <테스트, 린트, 재현 스크립트, 리뷰 체크리스트>
상태 저장: <ledger 파일 또는 이슈 보드>
정지 조건: <통과/실패/비용 초과/사람에게 질문>
핸드오프: <결정 필요 시 남길 증거와 질문 형식>관련 노트
- 2026-07-18-react-reasoning-acting · 2026-07-18-reflexion · 2026-07-18-self-refine · 2026-07-18-toolformer · 2026-07-18-tree-of-thoughts · 2026-07-18-voyager · 2026-07-18-swe-agent-agent-computer-interfaces · 2026-07-18-swe-bench · 2026-07-18-copilot-productivity-rct — 오늘날 에이전트 루프 설계 원칙(되먹임, 상태/메모리, 검증, 비용 상한)의 학술적 뿌리가 된 2022~2024년 기초 논문 9편
- 2026-06-14-loop-engineering — Addy Osmani 글의 원문 요약
- 2026-07-14-loop-engineering-with-claude-code — 헤드리스 모드(
-p)·구조화 출력·배치/멀티턴/파이프라인 3패턴·--allowedTools/--max-turns/--bare가드레일까지 Claude Code CLI 플래그 수준으로 구체화한 실전편 - 2026-06-14-steipete-maintainer-orchestrator-loop — 5분 폴링 maintainer-orchestrator 사례
- 2026-06-20-karpathy-vibe-coding-to-agentic-engineering — agentic engineering은 품질 바를 보존하는 상위 역량이라는 관점
- 2026-05-24-agent-harness-engineering-survey — 루프를 떠받치는 하네스 계층 분류
- 2026-07-19-loop-engineering-to-graph-engineering — 단일 루프 → 루프들의 그래프, 그리고 위상 구조가 아니라 현실에 닿는 앵커(grounded)가 핵심이라는 후속 논의
- moc-ai-coding · moc-ai-agents-harness