Loop Engineering: 프롬프터에서 루프 설계자로 (Addy Osmani의 새 개념 정리)
루프 엔지니어링(Loop Engineering): 프롬프터에서 루프 설계자로 가는 길 (Addy Osmani)
2026년 6월 8일, 구글 크롬 엔지니어링 리더 Addy Osmani가 블로그와 X에 짧은 글 하나를 올렸습니다. 제목은 Loop Engineering(루프 엔지니어링). 한 줄로 요약하면 이래요. "에이전트에게 프롬프트를 입력하는 나 자신을 시스템으로 대체하라." 지난 2년간 우리가 코딩 에이전트를 쓰던 방식이 끝나간다는 선언인데요. 이게 왜 중요한지, 그리고 1인 기업이나 실무 개발자가 어떻게 받아들여야 할지 차근차근 풀어 드릴게요.
루프 엔지니어링이란?: 에이전트에게 프롬프트를 입력하는 사람 자신을, 작업을 찾고 분배하고 검증하고 기록하는 시스템으로 대체하는 설계 방식입니다.
목차
- Loop Engineering이란 무엇인가
- prompt → context → loop, 추상화의 이동
- 루프를 굴리는 5(+1)개 부품
- maker ≠ checker: 루프의 안전장치와 /goal
- Claude Code와 Codex, 같은 루프가 돈다
- 1인 기업이 루프로 인력을 레버리지하는 법
- Osmani가 던진 4가지 경고
- 자주 묻는 질문(FAQ)
Loop Engineering이란 무엇인가
지난 2년간 코딩 에이전트를 쓰는 방식은 모두 비슷했습니다. 프롬프트를 한 번 입력하고, 결과를 읽고, 다시 다음 프롬프트를 입력하죠. 매 턴마다 사람이 도구를 손에 쥐고 있었어요.
Loop Engineering은 이 흐름을 뒤집습니다. 작업을 찾고(find) → 분배하고(hand out) → 검사하고(check) → 기록하고(write down) → 다음 작업을 결정하는(decide) 작은 시스템을 한 번 만들어 두고, 사람 대신 그 시스템이 에이전트를 찌르게(poke) 하는 거예요. Osmani는 루프를 "목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표(recursive goal)"라고 정의합니다.
중요한 건 이게 Osmani 단독 발명이 아니라는 점이에요. 2026년 6월 초 업계에서 동시다발로 부상한 흐름을 정리·명명한 것입니다. OpenClaw 프로젝트의 Peter Steinberger는 "이제 코딩 에이전트에게 프롬프트하지 말고, 당신의 에이전트를 프롬프트하는 루프를 설계하라"고 했고, Anthropic Claude Code 책임자 Boris Cherny는 "나는 더 이상 Claude에게 프롬프트하지 않는다. Claude를 프롬프트하고 무엇을 할지 판단하는 루프를 돌린다. 내 일은 루프를 작성하는 것이다"라고 말했죠.
prompt → context → loop, 추상화의 이동
Loop Engineering은 갑자기 튀어나온 게 아니라 자연스러운 추상화 상승의 한 단계입니다.
- 프롬프트 엔지니어링: 뭐라고 말할까 (what to say)
- 컨텍스트 엔지니어링: 뭘 보여줄까 (what to show)
- 루프 엔지니어링: 누가 반복을 돌릴까 (who runs the loop)
Osmani 본인의 선행 개념인 agent harness engineering(단일 에이전트가 작동하는 환경 설계)과 factory model(소프트웨어를 만드는 시스템) 위에 한 층을 더 얹은 셈이에요. 그의 표현을 빌리면 "harness가 타이머로 돌고, 작은 도우미들을 spawn하고, 스스로를 먹여 살리는 것"이 루프입니다.
루프를 굴리는 5(+1)개 부품
다섯 개의 핵심 부품과 +1 상태
Osmani는 루프를 검증 가능한 5(+1)개 구성 요소로 분해합니다.
- Automations(자동화) — 스케줄 기반으로 알아서 일감을 발견하고 분류해요. 루프의 심장박동이죠. 한 번 실행한 run을 진짜 루프로 만드는 핵심 요소입니다.
- Worktrees(워크트리) — 에이전트가 둘 이상이면 파일 충돌이 곧 실패 지점이에요. git worktree는 같은 repo history를 공유하되 별도 작업 디렉토리와 브랜치를 줘서 충돌을 막습니다.
- Skills(스킬) — 매 세션 프로젝트 컨텍스트를 금붕어처럼 다시 설명하는 걸 멈추는 장치예요. 프로젝트 지식을 코드(
SKILL.md)로 한 번 박아둡니다. - Plugins/Connectors(MCP) — "파일시스템만 보는 루프는 작은 루프"입니다. MCP 기반 커넥터가 이슈 트래커 읽기, DB 쿼리, staging API 호출, Slack 메시지를 가능하게 해요.
- Sub-agents(서브에이전트) — 아이디어를 만드는 에이전트와 검증하는 에이전트를 분리합니다. 루프 구조에서 가장 유용한 부품이에요.
그리고 +1, State/Memory(상태). Markdown 파일이든 Linear 보드든, 단일 대화 밖 디스크에 "완료/대기"를 기록합니다. "모델은 run 사이에 모든 걸 잊으므로 메모리는 컨텍스트가 아니라 디스크에 있어야 한다. 에이전트는 잊지만 repo는 안 잊는다"는 게 핵심이에요.
maker ≠ checker: 루프의 안전장치와 /goal
루프에서 가장 중요한 원칙은 만드는 모델과 검사하는 모델을 분리하는 것입니다. 코드를 작성한 모델은 자기 채점에 너무 관대하거든요. 그래서 다른 지시·다른 모델의 검증 sub-agent를 분리해야 합니다. Osmani의 표현으로는 "루프는 당신이 보지 않을 때 돌기 때문에, 신뢰할 수 있는 verifier만이 자리를 비울 수 있는 유일한 이유"예요.
Claude Code와 Codex 양쪽 모두 이걸 /goal 커맨드로 구현했습니다. "test/auth의 모든 테스트 통과 + lint clean" 같은 검증 가능한 종료 조건을 주면, 매 턴 후 별도의 작은 모델이 조건이 참이 됐는지 채점합니다. 기본 평가자 모델은 Claude Haiku라 메인 턴 대비 비용이 거의 무시할 수준이에요.
여기서 /loop과 /goal의 구분이 중요합니다. /loop은 정해진 주기(cadence)로 재실행하고, /goal은 "내가 작성한 조건이 실제로 참이 될 때까지" 계속 진행합니다. "좋은 앱 만들기"는 측정 불가능하지만 "product-roadmap.md의 62개 작업 전부 체크 + 테스트 통과"는 측정 가능하죠.
Claude Code와 Codex, 같은 루프가 돈다
Osmani 글의 또 다른 강점은 5요소를 Claude Code와 OpenAI Codex에 1:1로 매핑했다는 점입니다.
| 구성 요소 | Claude Code | OpenAI Codex |
|---|---|---|
| Automations | /loop, cron, hooks, GitHub Actions | Automations 탭, Triage 인박스, /goal |
| Worktrees | git worktree, sub-agent isolation: worktree | thread별 내장 worktree |
| Skills | Agent Skills (SKILL.md) | Agent Skills (SKILL.md) |
| Plugins/Connectors | MCP 서버 + 플러그인 | Connectors(MCP) + 플러그인 |
| Sub-agents | .claude/agents/ Task subagent + agent teams | .codex/agents/ TOML subagent |
| State | Markdown 또는 MCP 경유 Linear | Markdown 또는 connector 경유 Linear |
"이름은 조금씩 다르지만 capability는 동일하다. 한 번 설계하면 Codex든 Claude Code든 같은 루프가 돈다"는 게 결론이에요. 도구 논쟁을 멈추고 어느 제품에 앉아 있든 동작하는 루프를 설계하라는 거죠.
1인 기업이 루프로 인력을 레버리지하는 법
이 개념이 가장 강력하게 와닿는 건 1인 기업입니다. 직원을 늘리는 대신 루프를 늘리는 거예요. Osmani가 든 예시를 보면 이렇습니다.
매일 아침 automation이 repo에서 실행됩니다. 트리아지 skill이 어제 CI 실패, 열린 이슈, 최근 커밋을 읽고 Markdown이나 Linear에 기록해요. 할 가치가 있는 항목마다 격리된 worktree를 열고 sub-agent가 수정 초안을 작성하고, 두 번째 sub-agent가 프로젝트 skill과 기존 테스트 대비 검토합니다. connector가 PR을 열고 티켓을 업데이트하고요. 루프가 못 다룬 건 triage 인박스로 보냅니다. state 파일이 척추(spine)가 되어 내일 아침 run이 오늘 멈춘 지점부터 이어받죠.
"당신은 이걸 한 번 설계했고, 어떤 단계도 프롬프트하지 않았다." 1인이 모든 소프트웨어를 AI로 개발하는 환경에 정확히 들어맞는 그림입니다.
Osmani가 던진 4가지 경고
여기서 멈추지 않고, Osmani 본인이 강한 회의(skeptic)를 함께 제시한 게 이 글의 신뢰도를 높입니다.
- 토큰 비용 폭주 — 무인 루프는 비용 변동성이 큽니다.
- 검증 책임은 여전히 사람에게 — 무인(unattended) 루프는 곧 무인 실수예요.
- Comprehension debt(이해 부채) — 이해를 건너뛰면 부채가 쌓입니다.
- Cognitive surrender(인지적 항복) — 사고 자체를 외주화하는 위험.
그의 명언이 핵심을 찌릅니다. "같은 루프를 두 사람이 만들어도 정반대 결과가 나온다. 한 명은 깊이 이해하는 일을 더 빨리 하려고, 다른 한 명은 이해 자체를 회피하려고 쓴다. 루프는 그 차이를 모르지만 당신은 안다." 결론도 균형 잡혀 있어요. "루프 설계가 프롬프트 엔지니어링보다 쉬운 게 아니라 더 어렵다 — 레버리지 지점이 이동했을 뿐이다."
자주 묻는 질문(FAQ)
Q. Loop Engineering은 누가 처음 제시했나요? A. 구글 크롬 엔지니어링 리더 Addy Osmani가 2026년 6월 8일 자신의 블로그와 X에 정리·명명했습니다. 다만 Peter Steinberger, Boris Cherny 등의 선행 발언을 5요소 구조로 정식화한 것에 가깝습니다.
Q. /loop과 /goal의 차이는 뭔가요?
A. /loop은 정해진 주기로 재실행하는 커맨드이고, /goal은 "검증 가능한 종료 조건"이 참이 될 때까지 매 턴 별도 모델이 채점하며 진행하는 커맨드입니다. 둘 다 Claude Code와 Codex 모두에 있습니다.
Q. maker ≠ checker 원칙이 왜 중요한가요? A. 코드를 작성한 모델은 자기 채점에 관대해서, 다른 모델이 검증해야 무인 루프를 믿고 자리를 비울 수 있기 때문입니다.
Q. 지금 바로 시작하려면 무엇이 필요한가요? A. 거창한 도구가 필요 없습니다. Automations(스케줄), Worktrees(격리), Skills(지식), MCP(도구 연결), Sub-agents(검증) — 이 5가지는 이미 Claude Code와 Codex에 모두 들어 있습니다.
마무리
루프 엔지니어링은 "AI가 다 해준다"는 과장이 아니라, 사람의 레버리지 지점이 프롬프트에서 시스템 설계로 이동했다는 진단입니다. 핵심 부품은 이미 Claude Code와 Codex에 다 들어 있어요. Automations, Worktrees, Skills, MCP, Sub-agents, 그리고 상태 파일. 여기에 maker ≠ checker 원칙만 더하면, 1인 기업도 직원 대신 루프로 일을 확장할 수 있습니다. 다만 무인 루프는 곧 무인 실수라는 경고도 함께 기억해야 해요. 루프는 깊이 이해하는 사람을 더 빠르게, 이해를 피하는 사람을 더 깊은 구렁으로 데려가니까요. 작게 한 개의 루프부터 설계해 보시길 권합니다.
