루프 엔지니어링 완벽 가이드

하네스 엔지니어링 시리즈 · 2편  |  AI Agent Engineering · 2026

루프 엔지니어링 완벽 가이드
프롬프트 치는 사람에서, 루프를 설계하는 사람으로

하네스가 에이전트의 '환경'을 설계하는 일이었다면, 루프 엔지니어링은 그 환경 위에서 에이전트가 사람 없이 스스로 도는 '순환'을 설계하는 일입니다. 2026년 6월 업계를 뒤흔든 이 개념을 정의부터 실전 예제, 실패 모드까지 정리합니다.

"나는 더 이상 Claude에 직접 프롬프트하지 않는다. 내 일은 루프를 작성하는 것이다." — Boris Cherny, Anthropic Claude Code 리드

1. 루프 엔지니어링이란? 2. 자동화와 뭐가 다른가 3. 4단계 진화: 프롬프트→루프 4. 루프를 이루는 6가지 부품 5. 실전 예제 4가지 6. 실패 모드와 가드레일 7. 하네스와의 관계, 시작하는 법

01 · DEFINITION

1. 루프 엔지니어링이란?

루프 엔지니어링(Loop Engineering)이란, AI 에이전트가 사람의 지속적인 개입 없이 목표에 도달할 때까지 발견 → 계획 → 실행 → 검증 → 반복의 피드백 사이클을 스스로 돌도록, 그 순환 구조를 설계·운영·개선하는 방법론이다.

기존 방식에서는 사람이 지시하고, 결과를 보고, 잘못된 부분을 지적하고, 다시 지시했습니다. 이 "수동 핑퐁"의 구조적 한계는 명확합니다. 병목이 사람이라는 것. 에이전트는 분당 수천 토큰을 생성하는데, 사람의 확인과 재지시는 분 단위로 걸립니다. 사람이 사실상 피드백 루프 그 자체였던 거죠.

루프 엔지니어링은 이 역할을 시스템에 넘깁니다. 사람은 목표와 종료 조건을 정의하고, 루프가 에이전트에게 일을 시키고, 결과를 채점하고, 다음 바퀴를 돌립니다. 개발자의 역할이 "코드를 쓰는 사람"에서 "에이전트가 도는 루프를 설계하는 사람"으로 이동하는 것입니다.

용어의 등장 — 2026년 6월의 일주일

• 6월 2일 — Claude Code를 만든 Anthropic의 Boris Cherny가 한 행사에서 "나는 더 이상 Claude에 직접 프롬프트하지 않는다. 루프가 Claude를 프롬프트한다. 내 일은 루프를 작성하는 것"이라고 발언
• 6월 7일 — Peter Steinberger가 X에 "이제 코딩 에이전트에 프롬프트하지 말라. 에이전트를 프롬프트하는 루프를 설계하라"는 취지의 글을 올려 수백만 뷰를 기록하며 담론의 도화선이 됨
• 같은 시기 — Google의 Addy Osmani가 블로그 "Loop Engineering"에서 이 흐름에 이름을 붙이고 구성 요소를 구조화

다만 발상 자체는 새것이 아닙니다. 학술적 출발점은 2022년의 ReAct 논문(Reason → Act → Observe → Repeat)으로, 루프 엔지니어링은 오래된 패턴에 2026년에 붙은 새 이름에 가깝습니다. 아직 권위 있는 단일 정의가 없는, 그만큼 따끈따끈한 신생 용어이기도 하고요.

02 · VS. AUTOMATION

2. "그거 그냥 자동화 아닌가요?"

처음 접하면 누구나 드는 의문입니다. 비슷해 보이지만 본질이 다릅니다.

자동화는 정해진 조건에서 정해진 행동을 실행합니다. 매일 오전 9시에 리포트를 발송하고, 폼이 제출되면 이메일을 보냅니다. 규칙이 고정되어 있어서, 예상 밖의 상황이 생기면 멈추거나 틀린 결과를 냅니다. 판단하지 않기 때문입니다.

루프는 다릅니다. 목적과 종료 조건을 정해두면, 에이전트가 스스로 판단하고, 실행하고, 결과를 평가하고, 방향을 수정하며 반복합니다. 자동화가 "레일 위를 달리는 기차"라면, 루프는 "목적지만 알려주면 길을 찾아가는 운전자"에 가깝습니다.

발견→ 계획→ 실행→ 검증→ 반복↺

사람은 루프가 완료되거나 중요한 결정이 필요할 때만 개입합니다.

03 · EVOLUTION

3. 4단계 진화 — 프롬프트에서 루프까지

단계	핵심 질문	사람의 역할
프롬프트 엔지니어링	"무엇을 물어볼까?"	좋은 질문을 쓰는 사람
컨텍스트 엔지니어링	"무엇을 보여줄까?"	맥락을 큐레이션하는 사람
하네스 엔지니어링	"환경을 어떻게 설계할까?"	작업 환경을 설계하는 사람
루프 엔지니어링	"스스로 도는 순환을 어떻게 설계할까?"	목표를 설정하고 게이트를 거는 사람

중요한 것은, 루프 엔지니어링이 아래 단계를 대체하지 않고 감싼다(wraps)는 점입니다. 루프 안에서도 결국 좋은 프롬프트와 잘 큐레이션된 컨텍스트, 잘 설계된 하네스가 필요합니다. 바깥에 자동화 루프가 한 겹 더 생겼을 뿐, 안쪽 기술이 사라진 게 아닙니다. 네 가지는 경쟁 관계가 아니라 층층이 쌓인 누적 관계입니다.

04 · SIX PARTS

4. 루프를 이루는 6가지 부품

Addy Osmani가 정리한 구성 요소입니다. Claude Code와 Codex 모두 이 부품들을 기본으로 제공합니다.

PART 01

Automations — 심장박동

루프가 언제 시작될지 정의합니다. 스케줄에 따라 어제의 CI 실패를 훑거나 열린 이슈를 점검하는 일을 사람 없이 주기적으로 수행합니다.

PART 02

Git Worktree — 충돌 격리

여러 에이전트를 동시에 돌리면 같은 파일을 건드려 충돌이 납니다. 워크트리는 각 에이전트에 별도 작업 디렉터리를 줘서 서로의 수정이 닿지 않게 격리합니다.

PART 03

Skills — 프로젝트 지식

컨벤션, 빌드 단계, "이 사건 때문에 이렇게 하지 않는다" 같은 의도를 문서로 정리해두면 루프가 매 실행마다 읽습니다. 없으면 매 사이클마다 프로젝트를 처음부터 재파악합니다.

PART 04

Connectors — 실제 도구 연결

파일시스템만 보는 루프는 좁은 루프입니다. MCP 커넥터로 이슈 트래커, DB, Slack에 연결하면 직접 PR을 열고, 티켓을 갱신하고, CI 통과 후 알림까지 보냅니다.

PART 05

Sub-agents — 만들기와 검증의 분리

코드를 쓴 에이전트가 자기 결과를 채점하면 너무 후합니다. 만드는 에이전트와 검증하는 에이전트를 나누는 것이 신뢰의 출발점입니다.

PART 06

Memory — 외부 기억

모델은 실행이 끝나면 잊습니다. 마크다운 파일이나 협업 보드에 "무엇이 끝났고 무엇이 남았는지"를 기록해, 다음 실행이 멈춘 자리에서 이어가게 합니다.

가장 자주 빠뜨리는 부품이 5번 서브에이전트입니다. 작업을 만든 모델이 "다 됐다"고 자평하면 거의 항상 성공을 과대 보고하기 때문에, '만든 쪽'과 '판정하는 쪽'을 분리하는 것이 루프 설계의 핵심 원리입니다.

05 · EXAMPLES

5. 실전 예제 4가지

예제 1 · 가장 원시적인 루프 — Ralph Loop

Geoffrey Huntley가 이름 붙인, 코딩 에이전트를 셸 루프로 돌리는 가장 단순한 결정론적 패턴입니다.

terminal

while :; do cat PROMPT.md | claude-code ; done

PROMPT.md에 목표와 검증 방법을 적어두면, 에이전트가 끝없이 같은 목표를 향해 재시도합니다. 조악해 보이지만 루프의 본질 — "프롬프트를 사람이 아니라 시스템이 넣는다" — 을 가장 적나라하게 보여줍니다.

예제 2 · Claude Code의 /loop와 /goal

이제는 셸 스크립트 없이도 에이전트 도구가 루프를 기본 제공합니다.

claude code

# 주기적 재실행 — 조건을 걸고 계속 돌린다
/loop babysit all my PRs. Auto-fix build issues,
and when comments come in, use a worktree agent to fix them

# 조건 충족 시 중단 — 완료 판정은 별도 모델이 수행
/goal 모든 테스트가 통과하고 ruff 경고가 0이 될 때까지
      실패 원인을 분석하고 수정을 반복하라

특히 /goal은 완료 조건을 검증할 때 코드를 생성한 모델과 다른 모델을 별도로 씁니다. 도구 차원에서 '만들기'와 '판정'을 분리해 둔 것이죠.

예제 3 · 서브에이전트 파이프라인 정의

Claude Code에서는 .claude/agents/ 디렉터리에 역할별 에이전트를 정의해 팀을 구성합니다. 탐색 → 구현 → 검증으로 이어지는 파이프라인이 대표적인 패턴입니다.

.claude/agents/verifier.md

---
name: verifier
description: 구현 결과를 명세와 대조해 검증하는 전용 에이전트
tools: Read, Bash(pytest:*), Bash(ruff check:*)
---
당신은 검증 전담 에이전트다. 코드를 수정하지 않는다.
1. 구현 에이전트의 변경 사항을 읽는다
2. pytest 와 ruff 를 실행한다
3. CLAUDE.md 의 컨벤션 위반 여부를 대조한다
4. 통과/실패와 그 근거를 보고서로만 출력한다

검증자에게 수정 권한을 주지 않는 것이 포인트입니다. 심판이 선수를 겸하면 판정이 무너집니다.

예제 4 · GitHub Actions 나이틀리 루프

매일 밤 저장소를 훑어 스스로 일감을 찾고, 고치고, PR을 여는 무인 루프의 골격입니다.

.github/workflows/nightly-loop.yml

name: Nightly Agent Loop
on:
  schedule:
    - cron: "0 18 * * *"   # 매일 03:00 KST
jobs:
  loop:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 어제의 CI 실패와 오픈 이슈를 수집해 TODO.md 갱신
        run: claude -p "CI 로그와 이슈를 읽고 TODO.md를 갱신하라"
      - name: 항목별 worktree에서 수정안 작성 후 PR 오픈
        run: claude -p "TODO.md 상위 1건을 worktree에서 수정하고
                          verifier 에이전트 통과 시에만 PR을 열어라"

자동화(Automations)가 일감을 발견하고, 워크트리가 격리하고, 서브에이전트가 검증하고, TODO.md가 메모리 역할을 합니다. 6가지 부품이 한 루프 안에서 맞물리는 구조입니다. 에이전트는 잊지만, 레포지토리는 잊지 않습니다.

06 · GUARDRAILS

6. 실패 모드와 가드레일

루프는 강력한 만큼 위험합니다. 무인으로 도는 루프는 실수도 무인으로 합니다.

1. 루프 폭주 — 잘못 설계된 루프는 토큰을 태우거나 무한히 돕니다. 최대 반복 횟수와 종료 조건은 선택이 아니라 필수입니다.
2. 보상 해킹 — 에이전트가 "테스트를 통과시키기 위해 테스트를 지우는" 식으로 목표를 편법으로 달성할 수 있습니다. 검증 스크립트와 테스트 파일은 에이전트의 쓰기 권한 밖에 두세요.
3. 수렴 실패의 신호 — 8회씩 반복해야 끝나는 루프가 매번 돈다면, 애초에 작업 정의가 잘못되었거나 가이드 파일이 부실하다는 신호입니다. "루프가 돌았다"가 아니라 "몇 번 만에 수렴했나"를 봐야 합니다.
4. 비용 구조의 변화 — 루프는 사람의 시간을 토큰 비용으로 치환합니다. 두 번째 의견(서브에이전트)은 그 비용을 치를 만한 곳에만 쓰라는 것이 Osmani의 조언입니다.

루프를 짠다고 사람이 사라지는 것은 아니다. 에이전트가 도는 동안 과정을 지켜보고 게이트를 거는 일은 여전히 사람의 몫이다.

07 · HARNESS & LOOP

7. 하네스와의 관계, 그리고 시작하는 법

1편에서 다룬 하네스 엔지니어링과의 관계는 대체가 아니라 포함입니다. 하네스가 에이전트 실행 환경 전체(규칙·도구·권한·피드백 장치)를 설계하는 넓은 개념이라면, 루프 엔지니어링은 그 안의 가이드와 센서를 조합해 자율 순환을 설계하는 특화 실천 — 하네스 엔지니어링의 가장 전위적인 형태입니다.

하네스가 마구(馬具)라면, 루프는 기수 없이도 정해진 코스를 완주하게 하는 조련이다. 마구 없는 조련은 불가능하다.

흥미로운 점은, 좋은 루프의 부품이 화려한 프롬프트가 아니라는 사실입니다. 잘 만든 검증 스크립트, 간결한 CLAUDE.md, 적절한 체크포인트, 보상 해킹을 막는 가드레일 — 모두 AI 이전부터 좋은 엔지니어링 조직이 해오던 일(빠른 CI, 명확한 컨벤션 문서, 작은 PR, 독립적 리뷰)의 연장선입니다.

오늘 시작하는 법

1. 검증부터 쓰기 — 루프의 품질은 검증의 품질입니다. verify.sh 하나(린트 + 테스트 + 빌드)를 먼저 만드세요.
2. 가장 작은 루프 하나 돌리기 — "테스트가 전부 통과할 때까지 수정을 반복하라"는 /goal 한 줄부터 시작
3. 만들기와 판정 분리하기 — 검증 전용 서브에이전트를 정의하고, 수정 권한은 주지 않기
4. 메모리 파일 두기 — TODO.md 하나면 충분합니다. 무엇이 끝났고 무엇이 남았는지만 남기세요.
5. 게이트 정하기 — 사람 승인 없이는 절대 넘지 못하는 지점(머지, 배포, 삭제)을 명시

한 가지 현실적인 조언도 있습니다. 한국 팀에 적용할 때 진짜 병목은 도구가 아니라 Skills 문서화 단계일 가능성이 높다는 것. 사내 규칙, 코드 컨벤션, 도메인 맥락이 문서로 정리돼 있지 않으면 아무리 좋은 루프를 깔아도 에이전트가 매번 맥락을 헛짚습니다. 의도 빚을 먼저 갚는 것 — 즉 Skills부터 채우는 것이 현실적인 출발점입니다.

REFERENCES

• Addy Osmani — Loop Engineering (2026.6) · 루프의 6가지 구성 요소 정리
• Peter Steinberger — X 게시글 (2026.6.7) · "루프를 설계하라" 담론의 도화선
• Boris Cherny — Acquired Unplugged 발언 (2026.6.2) · "내 일은 루프를 작성하는 것"
• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629, 2022)
• 국내 정리 글 — elancer.co.kr · birdspring.com · aisparkup.com · youngju.dev · discuss.pytorch.kr

SERIES
1편 — 하네스 엔지니어링 완벽 가이드 · 2편 — 루프 엔지니어링 완벽 가이드 (본편)