정의

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/핸드오프 → 상태 파일 갱신.
  • 따라서 루프는 하네스를 대체하지 않는다. 루프는 하네스 위에서 반복, 상태, 위임, 정지 조건을 엔지니어링한다.

설계 원칙

  1. 정지 조건을 먼저 쓴다. “완료될 때까지”는 위험하다. 테스트, 린트, 재현 단계, 승인자, 비용 한도, 핸드오프 조건을 명시해야 한다.
  2. 작성자와 검사자를 분리한다. 루프가 사람 없이 잠시 돌아가려면, 최소한 구현 에이전트와 검증 에이전트의 역할이 달라야 한다.
  3. 상태를 대화 밖에 둔다. 마크다운 ledger, 이슈 보드, Linear, SQLite 등 무엇이든 단일 세션을 넘어 살아남아야 한다.
  4. 병렬성보다 리뷰 대역폭을 먼저 본다. 워크트리는 충돌을 줄이지만, 사람이 읽고 승인할 수 있는 양을 늘려주지는 않는다.
  5. 비용과 권한을 루프의 일부로 다룬다. 서브에이전트·장기 실행·커넥터는 토큰 비용과 blast radius를 동시에 키운다.
  6. 핸드오프를 실패 경로로 설계한다. 루프가 못 푸는 것은 조용히 계속 돌리지 말고, 증거와 선택지를 갖춘 decision-ready 상태로 사람에게 넘겨야 한다.

좋은 사용처

  • 반복적인 이슈/PR/CI triage
  • 의존성 업데이트, 린트 수정, 테스트 실패 재현 같은 좁은 유지보수 작업
  • 문서/위키 ingest처럼 입력·검증·파일링 규칙이 명확한 작업
  • 여러 후보안을 만들고 별도 리뷰어가 비교할 수 있는 UI/코드 개선
  • 2026-06-14-steipete-maintainer-orchestrator-loop처럼 maintainer가 큐를 관리하고 워커 스레드에 일을 분배하는 레포 운영

위험 신호

  • “계속 돌리면 언젠가 좋아질 것”이라는 열린 목표
  • CI/eval 없이 “완료”라고 주장하는 루프
  • 프로덕션 권한을 가진 커넥터가 승인 게이트 없이 붙어 있음
  • 상태 파일이 없거나, 상태 파일은 있지만 사람이 읽지 않음
  • 루프가 만든 코드를 이해하지 못한 채 병합하는 습관
  • 토큰·시간·API 사용량 상한이 없는 야간 실행

실전 템플릿

목표: <검증 가능한 완료 상태>
입력: <읽을 이슈/로그/파일/보드>
반복 주기: <수동 / 매일 / 5분마다 / CI 실패 시>
작업자: <구현 에이전트, 리서치 에이전트, 리뷰 에이전트>
격리: <워크트리/브랜치/샌드박스>
도구 권한: <읽기 전용 / PR 생성 / 배포 금지 / 승인 필요>
검증: <테스트, 린트, 재현 스크립트, 리뷰 체크리스트>
상태 저장: <ledger 파일 또는 이슈 보드>
정지 조건: <통과/실패/비용 초과/사람에게 질문>
핸드오프: <결정 필요 시 남길 증거와 질문 형식>

관련 노트