한 줄 요약
Addy Osmani의 Loop Engineering은 코딩 에이전트에게 사람이 매번 직접 프롬프트를 입력하는 단계에서, 자동화·워크트리·스킬·커넥터·서브에이전트·상태 저장소가 서로 이어진 자기 반복형 작업 시스템을 설계하는 단계로 이동하고 있다는 주장이다.
핵심 주장
- 루프 엔지니어링은 “더 긴 프롬프트”가 아니라 프롬프트를 대신 넣고, 결과를 검사하고, 다음 행동을 결정하는 시스템을 설계하는 일이다.
- 하네스 엔지니어링이 단일 에이전트의 실행 환경을 감싸는 계층이라면, 루프 엔지니어링은 그 하네스를 타이머·상태·위임·검증과 결합해 계속 돌아가게 만드는 한 층 위의 운영 패턴이다.
- Codex와 Claude Code는 이름은 달라도 자동화, 워크트리, 스킬, 플러그인/커넥터, 서브에이전트, 상태 저장이라는 비슷한 기본 부품을 갖추는 방향으로 수렴하고 있다.
- 그러나 루프는 사람을 제거하지 않는다. 오히려 검증, 이해, 판단을 소홀히 하면 agentic engineering이 아니라 이해 부채와 인지적 항복을 가속한다.
루프의 여섯 부품
| 부품 | 의미 |
|---|---|
| 자동화 | 일정 또는 이벤트에 따라 발견·분류·실행을 시작하는 심장박동 |
| 워크트리 | 여러 에이전트가 동시에 작업해도 충돌하지 않게 하는 격리 단위 |
| 스킬 | 프로젝트 규칙과 반복 절차를 세션 밖 지식으로 저장하는 방법 |
| 플러그인/커넥터 | GitHub, Linear, Slack, DB, 배포 환경 같은 실제 업무 표면에 연결하는 통로 |
| 서브에이전트 | 작성자와 검증자, 탐색자와 구현자를 분리하는 구조 |
| 상태/메모리 | 무엇을 시도했고 무엇이 끝났으며 무엇이 막혔는지 다음 실행으로 넘기는 ledger |
예시 루프
- 매일 아침 자동화가 저장소의 CI 실패, 열린 이슈, 최근 커밋을 읽는다.
- triage 스킬이 작업을 “자율 처리 가능 / 오너 결정 필요 / 보류”로 나눈다.
- 자율 처리 가능한 항목마다 격리된 워크트리를 만들고 구현 에이전트를 보낸다.
- 별도 리뷰 에이전트가 diff, 테스트, 프로젝트 규칙에 비추어 수정안을 검사한다.
- 커넥터가 PR을 열거나 이슈 보드를 갱신한다.
- 상태 파일이 시도, 실패, 남은 질문, 다음 실행의 시작점을 기록한다.
이 패턴은 2026-06-14-steipete-maintainer-orchestrator-loop의 maintainer-orchestrator 사례와 거의 같은 구조다. 루트 오케스트레이터는 직접 구현하기보다 큐를 보고, 워커를 배정하고, 블로커와 게이트만 관리한다.
실무적 함의
- 루프의 단위는 프롬프트가 아니라 완료 기준이다. 테스트·린트·재현·비용·승인 조건을 명확히 써야 한다.
- 루프에는 권한 설계가 포함된다. 커넥터가 많을수록 생산성과 blast radius가 함께 커진다.
- 상태는 컨텍스트가 아니라 디스크에 있어야 한다. 모델은 실행 사이를 잊지만, repo/ledger/이슈 보드는 잊지 않는다.
- 서브에이전트는 품질 게이트이지 장식이 아니다. 루프가 unattended로 돌아갈수록 작성자와 검사자의 분리가 중요해진다.
- 리뷰 대역폭이 병목이다. 워크트리는 병렬성을 주지만, 사람이 이해하고 승인할 수 있는 변경량은 별도의 제약이다.
비판적 관찰
루프 엔지니어링은 강력한 레버지만, 과장하면 “밤새 알아서 다 고치는 마법”으로 오해된다. 실제로는 비용 상한, 권한 경계, 검증자 독립성, 상태 파일 품질, 사람의 리뷰 습관이 빠지면 단순 자동화보다 더 위험하다. 좋은 루프는 사람을 대체하기보다, 사람이 더 적은 프롬프트로 더 많은 검증 가능한 선택지를 받게 만든다.
관련 노트
- loop-engineering — 개념 정리와 실전 템플릿
- 2026-06-14-steipete-maintainer-orchestrator-loop — Codex maintainer-orchestrator 루프 사례
- 2026-05-24-agent-harness-engineering-survey — 하네스 엔지니어링 서베이
- moc-ai-coding · moc-ai-agents-harness