루프 엔지니어링이란? AI 코딩의 새로운 패러다임

루프 엔지니어링이란?

2026년 6월, 개발자 트위터(X)를 뜨겁게 달군 키워드가 있습니다. 루프 엔지니어링(Loop Engineering).

한 문장으로 정의하면 이렇습니다:

에이전트에게 프롬프트를 직접 주는 대신, 에이전트를 프롬프트하는 루프를 설계하는 것

기존의 프롬프트 엔지니어링이 "어떤 말을 해야 AI가 잘 답하는가?"에 집중했다면, 루프 엔지니어링은 AI가 스스로 작업을 찾고, 실행하고, 검증하고, 반복하는 시스템을 어떻게 설계하는가에 집중합니다.

누가 시작했나?

Peter Steinberger의 트윗

2026년 6월 8일, OpenAI에서 일하는 Peter Steinberger(@steipete)가 X에 두 문장을 올렸습니다:

"Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

"더 이상 코딩 에이전트에게 프롬프트를 치지 마세요. 에이전트에게 프롬프트를 주는 루프를 설계하세요."

이 트윗은 650만 뷰를 기록하며 개발자 커뮤니티에 격렬한 논쟁을 촉발했습니다. 39%는 "진정한 패러다임 전환"이라고 했고, 61%는 "시기상조" 또는 "과장"이라고 반박했습니다.

Boris Cherny의 선언

논쟁에 결정적 무게를 실어준 사람은 Anthropic에서 Claude Code를 만든 Boris Cherny였습니다. 그는 이렇게 말했습니다:

"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."

"나는 더 이상 Claude에게 프롬프트를 치지 않는다. 루프가 돌아가고 있고, 그것들이 Claude에게 프롬프트를 주고 뭘 할지 결정한다. 내 일은 루프를 작성하는 것이다."

Claude Code를 만든 사람이 "프롬프트를 더 이상 안 친다"고 선언한 것입니다. 이 발언 이후 루프 엔지니어링은 단순한 유행어가 아닌, 실질적인 워크플로우 변화로 자리잡기 시작했습니다.

프롬프트 엔지니어링 vs 루프 엔지니어링

구분	프롬프트 엔지니어링	루프 엔지니어링
방식	사람이 매번 지시	시스템이 자동 반복
초점	"어떤 말을 할까?"	"어떤 시스템을 만들까?"
검증	결과를 사람이 확인	결과를 에이전트가 자동 검증
확장성	1:1 (사람:에이전트)	1:N (사람이 여러 루프 관리)
종료 조건	사람이 판단	목표 달성 시 자동 종료

핵심 차이를 비유하면: 프롬프트 엔지니어링이 요리사에게 재료를 하나씩 건네주는 것이라면, 루프 엔지니어링은 레시피와 재료를 모두 세팅해두고 요리사가 스스로 완성할 때까지 맡기는 것입니다.

루프의 핵심 사이클

모든 루프는 4단계를 반복합니다:

행동(Act) → 관찰(Observe) → 추론(Reason) → 반복(Repeat)

행동: 에이전트가 코드를 수정하거나 파일을 생성
관찰: 테스트를 실행하고 결과를 확인
추론: 성공인지 실패인지 판단하고 다음 행동을 결정
반복: 목표 달성 시 멈추고, 미달이면 다시 1번으로

루프 엔지니어링의 5가지 구성요소

Google의 Addy Osmani가 정리한 실전 루프의 5가지 필수 요소입니다.

1. 자동화 (Automations)

루프의 시작점입니다. 사람이 "시작"을 누르지 않아도 특정 조건이나 일정에 따라 에이전트가 자동으로 작업을 시작합니다.

일정 기반: "매일 오전 9시에 CI 실패 건을 분류하라"
이벤트 기반: "새 이슈가 등록되면 우선순위를 판단하라"

2. 워크트리 (Worktrees)

여러 에이전트가 동시에 같은 코드베이스에서 작업하면 충돌이 납니다. Git worktree로 각 에이전트에게 독립된 작업 공간을 부여합니다.

# 에이전트 A는 bugfix 브랜치에서
git worktree add ../agent-a-bugfix fix/auth-bug

# 에이전트 B는 feature 브랜치에서
git worktree add ../agent-b-feature feat/new-api

3. 스킬 (Skills)

에이전트가 매번 같은 설명을 듣지 않아도 되도록, 프로젝트의 규칙과 컨벤션을 문서화합니다. CLAUDE.md가 대표적인 예입니다.

4. 커넥터 (Connectors)

에이전트가 외부 세계와 소통하는 통로입니다. MCP(Model Context Protocol)를 통해 GitHub, Linear, Slack, 데이터베이스 등에 접근합니다.

5. 서브 에이전트 (Sub-agents)

코드를 쓴 사람이 코드를 리뷰하면 안 된다 — 이 원칙을 에이전트에도 적용합니다.

작성자 에이전트: 코드 수정
검증자 에이전트: 테스트 실행 + 코드 리뷰
두 에이전트는 서로 독립적으로 동작

Claude Code에서 루프 실행하기

Claude Code는 루프 엔지니어링을 가장 직접적으로 지원하는 도구입니다. 핵심 명령어 두 가지를 알아봅시다.

/goal — "이 조건이 될 때까지 반복"

/goal 모든 테스트가 통과하고 린트 에러가 0일 것

이 한 줄이면 Claude Code는:

테스트를 실행하고
실패하면 원인을 분석하고
코드를 수정하고
다시 테스트를 실행하고
모든 테스트가 통과할 때까지 반복합니다

매 턴이 끝날 때마다 별도의 소형 모델이 "목표가 달성되었는가?"를 판단합니다. 작성자와 검증자가 자동으로 분리되는 것입니다.

좋은 goal 작성법:

# 나쁜 예 — 모호함
/goal 코드를 개선해줘

# 좋은 예 — 검증 가능한 종료 조건
/goal src/lib/auth.ts의 모든 함수에 단위 테스트를 추가하고, npm test가 통과할 것

# 더 좋은 예 — 안전장치 포함
/goal 타입 에러 0개, 테스트 100% 통과. 기존 파일 삭제 금지. 30턴 이내.

핵심: 완료가 어떤 상태인지 말할 수 없으면, 그건 루프가 아니라 소망입니다.

/loop — "주기적으로 반복"

/loop 매시간 CI 실패 건을 확인하고 자동 수정 시도

/goal이 "조건 달성까지"라면, /loop은 "정해진 주기마다" 실행됩니다.

명령어	다음 턴 시작 조건	종료 조건
`/goal`	이전 턴 즉시 완료 후	목표 달성 시 자동 종료
`/loop`	설정된 시간 경과 후	사용자가 중단할 때

CLAUDE.md — 루프의 두뇌

루프 엔지니어링에서 CLAUDE.md 파일은 단순한 프로젝트 설명을 넘어 에이전트의 두뇌 역할을 합니다. 매 세션 시작 시 자동으로 로드되어, 에이전트가 프로젝트의 맥락을 즉시 파악합니다.

효과적인 CLAUDE.md 구성:

# 프로젝트명

## 기술 스택
- Next.js 14, TypeScript, Supabase

## 절대 규칙
- UI 텍스트는 한국어만
- 이모지 금지, lucide-react SVG만
- financial-constants.ts 수정 시 반드시 확인

## 명령어
npm run dev       # 개발 서버
npm test          # vitest 단위 테스트
npm run build     # 프로덕션 빌드

## 주의 사항
- OG 이미지 TOOL_COUNT 하드코딩 — 도구 추가 시 수동 갱신
- posts는 Supabase DB가 단일 소스

이렇게 하면 /goal 모든 테스트 통과라는 한 줄만으로도 에이전트가 어떤 테스트 명령어를 쓰고, 어떤 규칙을 지켜야 하는지 알 수 있습니다.

실전 시나리오: 매일 아침 자동화 루프

루프 엔지니어링의 꿈은 "잠자는 동안 코드가 개선되는 것"입니다. 현실적인 일일 루프 구조를 살펴봅시다:

[매일 오전 9시 트리거]
    │
    ├─ 1. 어제 CI 실패 건 수집
    ├─ 2. 미해결 GitHub 이슈 분류
    ├─ 3. 최근 커밋에서 TODO 추출
    │
    ├─ 4. 각 항목별 워크트리 생성
    │     ├── 에이전트 A: bugfix 브랜치에서 수정
    │     └── 에이전트 B: 독립적으로 코드 리뷰
    │
    ├─ 5. 테스트 통과 → PR 자동 생성
    │     실패 → 피드백 반영 후 재시도
    │
    └─ 6. 해결 불가 건 → 개발자 인박스로 알림

개발자는 출근해서 이미 만들어진 PR을 리뷰하는 것부터 시작합니다. 루프가 밤새 일한 결과물이 아침에 대기하고 있는 것입니다.

주의해야 할 것들

루프 엔지니어링은 강력하지만, 맹목적으로 따르면 안 됩니다.

1. 비용 관리

에이전트가 스스로 프롬프트하고 검증하면 토큰 소비가 급증합니다. 반드시 턴 제한과 예산 상한을 설정하세요.

2. 이해도 부채 (Comprehension Debt)

자동으로 생성된 PR을 제대로 읽지 않고 머지하면, 본인이 모르는 코드가 쌓입니다. 루프가 빠를수록 코드 리뷰의 중요성은 커집니다.

3. 명확한 종료 조건

"코드를 개선해줘"는 루프가 아닙니다. 테스트 100% 통과 + 린트 에러 0처럼 검증 가능한 종료 조건이 없으면 에이전트는 무한히 반복합니다.

4. 엔지니어로 남아있기

Addy Osmani의 핵심 경고:

"루프를 설계하되, 엔지니어로 남아있어야 합니다. 단순히 '실행' 버튼을 누르는 사람이 아니라."

루프 엔지니어링은 생각을 피하기 위해 쓰는 것이 아니라, 깊은 이해 위에서 반복 작업을 자동화하는 것입니다.

정리

핵심 포인트	내용
정의	에이전트를 프롬프트하는 시스템을 설계하는 것
기원	Peter Steinberger 트윗(6.5M뷰) + Boris Cherny 선언
핵심 사이클	행동 → 관찰 → 추론 → 반복
5요소	자동화, 워크트리, 스킬, 커넥터, 서브에이전트
Claude Code	`/goal`(조건 달성까지) + `/loop`(주기적 반복)
필수 조건	검증 가능한 종료 조건
주의	비용 관리, 이해도 부채, 엔지니어로 남기

프롬프트 엔지니어링이 "AI에게 말하는 기술"이었다면, 루프 엔지니어링은 AI가 스스로 일하는 시스템을 설계하는 기술입니다. 2026년, 개발자의 역할은 "코드를 짜는 사람"에서 코드를 짜는 시스템을 설계하는 사람으로 진화하고 있습니다.

이 글에서 소개한 루프 엔지니어링 개념은 Peter Steinberger(@steipete), Boris Cherny(Anthropic), Addy Osmani(Google)의 공개 발언과 글을 기반으로 정리했습니다.