Loop Engineering
“에이전트를 프롬프트하지 말고, 에이전트를 프롬프트하는 루프를 설계하라”
핵심 개념
Loop engineering은 자기 자신을 “에이전트를 프롬프트하는 사람” 자리에서 치우고 그 일을 하는 시스템을 설계하는 것이다. 루프는 재귀적 목표 — 목적을 정의하면 AI가 완료될 때까지 반복한다.
지난 2년의 방식은 좋은 프롬프트를 쓰고, 돌아온 걸 읽고, 다음을 타이핑하는 것이었다. 에이전트는 도구였고 사람이 내내 손에 쥐고 있었다. 대신 이제는 일을 찾아내고, 나눠주고, 검증하고, 무엇이 끝났는지 기록하고, 다음을 결정하는 작은 시스템을 만들고 그 시스템이 에이전트를 찌르게 한다.
계층으로 보면: agent harness(에이전트 하나가 사는 환경) < loop(타이머로 돌고, 헬퍼를 스폰하고, 스스로에게 먹이를 주는 harness) < factory model(소프트웨어를 짓는 시스템).
다섯 조각 + 메모리
1년 전엔 bash 더미를 직접 유지해야 했지만 이제 조각들이 제품에 들어 있고, Codex와 Claude Code에서 이름만 다르고 형태는 같다. 그래서 도구를 고르는 논쟁 대신 어느 쪽에서든 도는 루프를 설계하면 된다.
| 프리미티브 | 루프에서의 역할 |
|---|---|
| Automations | 스케줄로 발화해 discovery·triage를 스스로. 뭔가 찾으면 triage inbox, 없으면 자동 아카이브. 루프를 “한 번 돌린 실행”이 아니라 실제 루프로 만드는 심장박동 |
| Worktrees | 병렬 에이전트 격리. 두 에이전트가 같은 파일을 쓰는 건 두 엔지니어가 상의 없이 같은 줄을 커밋하는 것과 같은 문제 |
Skills (SKILL.md) | 프로젝트 지식을 밖에 적어둠. 없으면 루프가 매 사이클 프로젝트 전체를 처음부터 재유도한다 |
| Plugins / Connectors (MCP) | 이슈 트래커·DB·스테이징 API·Slack 접근. 파일시스템만 보는 루프는 작은 루프 |
| Sub-agents | 만드는 자와 검사하는 자를 분리 |
| State (여섯 번째) | 대화 밖에 사는 마크다운/보드. 모델은 실행 사이에 다 잊지만 repo는 안 잊는다 |
메모리가 너무 시시해 보이지만, 장기 실행 에이전트가 의존하는 바로 그 트릭이다. 컨텍스트가 아니라 디스크에 있어야 한다.
maker/checker 분리가 핵심인 이유
루프에서 구조적으로 가장 유용한 것은 쓴 자와 검사하는 자를 나누는 것이다. 코드를 쓴 모델은 자기 숙제를 너무 후하게 채점한다. 다른 지시(때로는 다른 모델)를 가진 두 번째 에이전트가 첫 번째가 스스로를 설득해버린 부분을 잡는다.
루프 안에서 이게 특히 중요한 이유: 루프는 내가 안 보는 동안 돈다. 신뢰할 수 있는 verifier가 자리를 뜰 수 있는 유일한 근거다.
/loop과 /goal의 차이도 같은 원리다.
/loop— 정해진 주기로 재실행/goal— 검증 가능한 정지 조건이 참이 될 때까지 계속하고, 매 턴 별도의 작은 모델이 완료 여부를 판정한다. 코드를 쓴 에이전트가 자기 채점을 하지 않는다. maker/checker 분리를 정지 조건 자체에 적용한 것
루프 한 개의 실제 모양
매일 아침 automation 발화
→ triage skill이 어제 CI 실패 · 오픈 이슈 · 최근 커밋을 읽어
마크다운 파일 / Linear 보드에 findings 기록
→ 할 만한 항목마다 격리된 worktree 개설
→ sub-agent A: 수정 초안
→ sub-agent B: 프로젝트 skill과 기존 테스트 대비 리뷰
→ connector가 PR 개설 · 티켓 갱신
→ 루프가 처리 못한 건 triage inbox로 (사람에게)
상태 파일이 척추: 무엇을 시도했고 무엇이 통과했고 무엇이 열려 있는지
→ 내일 아침 실행이 오늘 멈춘 곳에서 이어짐
한 번 설계했고, 저 단계들 중 어느 것도 직접 프롬프트하지 않았다.
루프가 대신 해주지 않는 것 — 오히려 날카로워지는 3가지
- 검증은 여전히 내 몫. 무인으로 도는 루프는 무인으로 실수하는 루프다. verifier subagent를 분리하는 이유가 루프의 “done”에 의미를 주기 위함인데, 그래도 “done”은 주장이지 증명이 아니다
- comprehension debt. 내가 쓰지 않은 코드를 루프가 빨리 낼수록 존재하는 것과 내가 실제로 이해하는 것의 간극이 커진다. 매끄러운 루프는 그 간극을 더 빨리 키운다
- cognitive surrender. 루프가 알아서 돌면 의견 갖기를 그만두고 나오는 대로 받는 게 아주 편해진다. 루프를 설계하는 것은 판단력을 가지고 할 때는 치료제이고, 생각을 피하려고 할 때는 촉진제다. 같은 행동, 정반대 결과
비용과 한계
- subagent는 각자 모델·툴 작업을 하므로 토큰을 더 태운다. 두 번째 의견이 값어치 있는 곳에만 지출
- 토큰 부자냐 빈자냐에 따라 사용 패턴이 크게 달라진다
- worktree가 기계적 충돌은 없애주지만 병목은 여전히 사람의 리뷰 대역폭(orchestration tax)이다. 몇 개를 실제로 돌릴 수 있는지는 도구가 아니라 내가 정한다
- 직접 프롬프트하는 것도 여전히 효과적이다. 균형의 문제
경계 — loop와 skill은 다른 축이다
위 프리미티브 표에 Skill이 한 줄로 들어 있어 혼동하기 쉬운데, 둘은 직교하는 축이다.
| Loop Engineering | Agent Skills and Paved Paths | |
|---|---|---|
| 다루는 축 | 시간 — 언제 발화하고, 다음에 뭘 하고, 언제 멈추는가 | 지식 — 이 작업 하나를 어떻게 올바르게 하는가 |
| 전제 | 내가 안 보는 동안 돈다 | 사람이 부르든 루프가 부르든 동일하게 동작 |
| 핵심 설계 결정 | maker/checker 분리, 정지 조건, 상태를 디스크에 | 에이전트(모호) ↔ 스크립트(결정론) 경계 |
| 대표 실패 | comprehension debt, cognitive surrender | 아무도 안 씀 (discoverability) |
| 없으면 | 매번 사람이 다음 프롬프트를 타이핑 | 루프가 매 사이클 프로젝트를 처음부터 재유도 |
서로를 필요로 하지 않는다. Skill은 루프 없이 사람이 직접 불러도 값을 하고(Etsy 사례가 그렇다), 루프는 skill 없이도 돌긴 한다 — 다만 비싸게.
합쳐질 때 생기는 것: skill이 루프의 진입점이 되면, 개발자가 평소 어휘로 요청한 것이 paved path로 흘러 들어가 루프가 그 뒤를 이어받는다. 이때 skill의 discoverability 문제가 루프의 커버리지 문제로 바뀐다 — 루프가 집어 갈 수 있는 일의 범위가 곧 진입점의 범위다.
연관 개념
- Agent Skills and Paved Paths — 루프가 쓰는 지식 단위, 그리고 그것을 사람이 찾게 만드는 문제
- AI Agent
- Context Engineering
- MCP (Model Context Protocol)
- LLM Evaluation
- LLM Platform Engineering
- AI Agent Identity and Security
- Multiagent Coordination — maker/checker를 넘어선 다중 에이전트 조율
- Agentic ML Modeling — 루프를 모델링 실험에 적용했을 때의 실패 모드
Source: Loop Engineering - Designing Systems That Prompt Agents