القائمة
단순한 순차적 파이프라인에서 RFC 기반 다중 에이전트 DAG 시스템에 이르기까지 자율적인 Claude Code 루프를 위한 패턴과 아키텍처.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/SAM42-Lab/everything-claude-code-kr --skill autonomous-loopsيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | autonomous-loops |
| description | 단순한 순차적 파이프라인에서 RFC 기반 다중 에이전트 DAG 시스템에 이르기까지 자율적인 Claude Code 루프를 위한 패턴과 아키텍처. |
| origin | ECC |
호환성 참고 (v1.8.0):
autonomous-loops는 한 번의 릴리스 동안 유지됩니다. 표준 스킬 이름은 이제continuous-agent-loop입니다. 새로운 루프 가이드는 그곳에서 작성되어야 하며, 이 스킬은 기존 워크플로가 깨지는 것을 방지하기 위해 계속 사용 가능합니다.
자율 루프에서 Claude Code를 실행하기 위한 패턴, 아키텍처 및 참조 구현입니다. 단순한 claude -p 파이프라인부터 완전한 RFC 기반 다중 에이전트 DAG 오케스트레이션에 이르기까지 모든 것을 다룹니다.
가장 단순한 것부터 가장 정교한 것까지:
| 패턴 | 복잡도 | 최적의 용도 |
|---|---|---|
| 순차적 파이프라인 | 낮음 | 일상적 개발 단계, 스크립트 기반 워크플로 |
| NanoClaw REPL | 낮음 | 대화형 영구 세션 |
| 무한 에이전트 루프 | 중간 | 병렬 콘텐츠 생성, 사양 중심 작업 |
| 지속적 Claude PR 루프 | 중간 | CI 게이트가 있는 다일간의 반복 프로젝트 |
| De-Sloppify 패턴 | 추가 기능 | 구현 단계 이후의 품질 정리 |
| Ralphinho / RFC 기반 DAG | 높음 | 대규모 기능, 머지 큐가 있는 다중 단위 병렬 작업 |
claude -p)가장 단순한 루프. 일상적인 개발을 비대화형 claude -p 호출 시퀀스로 나눕니다. 각 호출은 명확한 프롬프트가 있는 집중된 단계입니다.
이런 루프를 구성할 수 없다면, 대화형 모드에서조차 LLM이 코드를 수정하도록 유도할 수 없다는 뜻입니다.
claude -p 플래그는 프롬프트와 함께 Claude Code를 비대화형으로 실행하고 완료되면 종료됩니다. 호출을 체이닝하여 파이프라인을 구축합니다.
#!/bin/bash
# daily-dev.sh — 기능 브랜치를 위한 순차적 파이프라인
set -e
# 1단계: 기능 구현
claude -p "docs/auth-spec.md의 사양을 읽고 src/auth/에 OAuth2 로그인을 구현해. 테스트를 먼저 작성해(TDD). 새로운 문서 파일은 생성하지 마."
# 2단계: De-sloppify (정리 단계)
claude -p "이전 커밋에서 변경된 모든 파일을 리뷰해. 불필요한 타입 테스트, 과도하게 방어적인 체크, 또는 언어 기능 테스트(예: TypeScript 제네릭 작동 확인)를 제거해. 실제 비즈니스 로직 테스트는 유지해. 정리 후 테스트 스위트를 실행해."
# 3단계: 검증
claude -p "전체 빌드, 린트, 타입 체크 및 테스트 스위트를 실행해. 실패한 부분을 수정해. 새로운 기능은 추가하지 마."
# 4단계: 커밋
claude -p "스테이징된 모든 변경 사항에 대해 컨벤션 커밋을 생성해. 메시지는 'feat: add OAuth2 login flow'로 해."
claude -p 호출마다 신선한 컨텍스트 창이 사용되므로 단계 간의 컨텍스트 오염이 없습니다.set -e는 실패 시 파이프라인을 중단합니다.모델 라우팅 활용:
# Opus로 리서치 (심층 추론)
claude -p --model opus "코드베이스 아키텍처를 분석하고 캐싱 추가를 위한 계획을 작성해..."
# Sonnet으로 구현 (빠르고 유능함)
claude -p "docs/caching-plan.md의 계획에 따라 캐싱 레이어를 구현해..."
# Opus로 리뷰 (철저함)
claude -p --model opus "보안 이슈, 레이스 컨디션 및 엣지 케이스에 대해 모든 변경 사항을 리뷰해..."
환경 컨텍스트 전달:
# 프롬프트 길이 대신 파일을 통해 컨텍스트 전달
echo "중점 분야: auth 모듈, API 속도 제한" > .claude-context.md
claude -p ".claude-context.md를 읽고 우선순위를 파악해. 순서대로 작업해."
rm .claude-context.md
--allowedTools 제한 활용:
# 읽기 전용 분석 단계
claude -p --allowedTools "Read,Grep,Glob" "이 코드베이스의 보안 취약점을 감사해..."
# 쓰기 전용 구현 단계
claude -p --allowedTools "Read,Write,Edit,Bash" "security-audit.md의 수정 사항을 구현해..."
ECC의 내장 영구 루프. 전체 대화 기록과 함께 claude -p를 동기적으로 호출하는 세션 인식 REPL입니다.
# 기본 세션 시작
node scripts/claw.js
# 스킬 컨텍스트가 포함된 명명된 세션
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js
~/.claude/claw/{session}.md에서 대화 기록을 로드합니다.claude -p에 전송됩니다.| 사용 사례 | NanoClaw | 순차적 파이프라인 |
|---|---|---|
| 대화형 탐색 | 예 | 아니요 |
| 스크립트 기반 자동화 | 아니요 | 예 |
| 세션 지속성 | 내장됨 | 수동 |
| 컨텍스트 축적 | 턴마다 증가 | 각 단계마다 새로 시작 |
| CI/CD 통합 | 부족함 | 우수함 |
자세한 내용은 /claw 명령어 문서를 참조하세요.
사양 중심 생성을 위해 병렬 하위 에이전트를 오케스트레이션하는 투-프롬프트(Two-Prompt) 시스템입니다. disler가 개발했습니다(출처: @disler).
프롬프트 1 (오케스트레이터) 프롬프트 2 (하위 에이전트)
┌─────────────────────┐ ┌──────────────────────┐
│ 사양 파일 파싱 │ │ 전체 컨텍스트 수신 │
│ 출력 디렉터리 스캔 │ 배포 │ 할당된 번호 확인 │
│ 반복 계획 수립 │────────────│ 사양을 정확히 준수 │
│ 창의적 방향 할당 │ N개 에이전트│ 고유한 출력 생성 │
│ 웨이브(Wave) 관리 │ │ 출력 디렉터리에 저장 │
└─────────────────────┘ └──────────────────────┘
.claude/commands/infinite.md 생성:
$ARGUMENTS에서 다음 인자를 파싱해:
1. spec_file — 사양 마크다운 경로
2. output_dir — 반복 결과가 저장될 위치
3. count — 정수 1-N 또는 "infinite"
1단계: 사양을 읽고 깊이 이해한다.
2단계: output_dir을 리스팅하고 가장 높은 반복 번호를 찾는다. N+1에서 시작한다.
3단계: 창의적 방향을 계획한다 - 각 에이전트는 서로 다른 테마/접근 방식을 받는다.
4단계: 하위 에이전트를 병렬로 배포한다(Task 도구). 각 에이전트는 다음을 받는다:
- 전체 사양 텍스트
- 현재 디렉터리 스냅샷
- 할당된 반복 번호
- 고유한 창의적 방향
5단계 (무한 모드): 컨텍스트가 낮아질 때까지 3-5개 단위의 웨이브로 루프를 돌린다.
호출:
/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite
| 개수 | 전략 |
|---|---|
| 1-5 | 모든 에이전트 동시 실행 |
| 6-20 | 5개 단위 배치 |
| 무한 | 3-5개 단위 웨이브, 점진적 고도화 |
에이전트가 스스로 차별화하기를 기대하지 마세요. 오케스트레이터가 각 에이전트에게 특정 창의적 방향과 반복 번호를 할당해야 합니다. 이를 통해 병렬 에이전트 간의 개념 중복을 방지합니다.
Claude Code를 지속적인 루프로 실행하여 PR을 생성하고, CI를 기다리고, 자동으로 머지하는 프로덕션 급 셸 스크립트입니다. AnandChowdhary가 제작했습니다(출처: @AnandChowdhary).
┌─────────────────────────────────────────────────────┐
│ 지속적 CLAUDE 반복 │
│ │
│ 1. 브랜치 생성 (continuous-claude/iteration-N) │
│ 2. 강화된 프롬프트로 claude -p 실행 │
│ 3. (선택 사항) 리뷰어 단계 — 별도의 claude -p │
│ 4. 변경 사항 커밋 (Claude가 메시지 생성) │
│ 5. 푸시 및 PR 생성 (gh pr create) │
│ 6. CI 체크 대기 (gh pr checks 폴링) │
│ 7. CI 실패? → 자동 수정 단계 (claude -p) │
│ 8. PR 머지 (squash/merge/rebase) │
│ 9. main으로 복귀 → 반복 │
│ │
│ 제한: --max-runs N | --max-cost $X │
│ --max-duration 2h | 완료 신호 │
└─────────────────────────────────────────────────────┘
주의: continuous-claude는 코드를 검토한 후 해당 저장소에서 설치하세요. 외부 스크립트를 파이프로 직접 bash에 연결하지 마세요.
# 기본: 10회 반복
continuous-claude --prompt "테스트되지 않은 모든 함수에 단위 테스트 추가" --max-runs 10
# 비용 제한
continuous-claude --prompt "모든 린트 에러 수정" --max-cost 5.00
# 시간 제한
continuous-claude --prompt "테스트 커버리지 향상" --max-duration 8h
# 코드 리뷰 단계 포함
continuous-claude \
--prompt "인증 기능 추가" \
--max-runs 10 \
--review-prompt "npm test && npm run lint 실행 후 실패 지점 수정"
# 워크트리를 통한 병렬 실행
continuous-claude --prompt "테스트 추가" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "코드 리팩터링" --max-runs 5 --worktree refactor-worker &
wait
중요한 혁신: SHARED_TASK_NOTES.md 파일이 반복 간에 컨텍스트를 유지합니다.
## 진행 상황
- [x] 인증 모듈 테스트 추가 (반복 1)
- [x] 토큰 갱신 엣지 케이스 수정 (반복 2)
- [ ] 남은 작업: 속도 제한 테스트, 에러 바운더리 테스트
## 다음 단계
- 다음에는 속도 제한 모듈에 집중할 것
- tests/helpers.ts의 모크 설정을 재사용할 수 있음
Claude는 반복 시작 시 이 파일을 읽고 종료 시 업데이트합니다. 이는 독립적인 claude -p 호출 간의 컨텍스트 격차를 메워줍니다.
PR 체크가 실패하면 Continuous Claude는 자동으로 다음을 수행합니다:
gh run list를 통해 실패한 실행 ID를 가져옵니다.claude -p를 실행합니다.gh run view를 통해 로그를 검사하고, 코드를 수정하고, 커밋하고 푸시합니다.--ci-retry-max 횟수만큼).Claude는 매직 구문을 출력하여 "작업 완료" 신호를 보낼 수 있습니다.
continuous-claude \
--prompt "이슈 트래커의 모든 버그 수정" \
--completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
--completion-threshold 3 # 3회 연속 신호 발생 시 중단
3회 연속으로 완료 신호가 발생하면 루프가 중단되어 이미 완료된 작업에 낭비되는 실행을 방지합니다.
| 플래그 | 목적 |
|---|---|
--max-runs N | N회 성공적인 반복 후 중단 |
--max-cost $X | $X 달러 소모 후 중단 |
--max-duration 2h | 경과 시간 도달 후 중단 |
--merge-strategy squash | squash, merge, 또는 rebase |
--worktree <name> | git 워크트리를 통한 병렬 실행 |
--disable-commits | 드라이 런(dry-run) 모드 (git 작업 안 함) |
--review-prompt "..." | 반복당 리뷰어 단계 추가 |
--ci-retry-max N | CI 실패 자동 수정 (기본값: 1) |
모든 루프를 위한 추가 패턴. 각 구현 단계 후에 전용 정리/리팩터링 단계를 추가합니다.
LLM에게 TDD로 구현하라고 요청하면 "테스트 작성"을 너무 문자 그대로 받아들일 때가 있습니다:
typeof x === 'string' 테스트 등)구현 프롬프트에 "타입 시스템을 테스트하지 마" 또는 "불필요한 체크를 추가하지 마"라고 추가하면 다운스트림 효과가 발생합니다:
구현 에이전트를 제약하는 대신 철저하게 작업하도록 둡니다. 그 다음 집중된 정리 에이전트를 추가합니다.
# 1단계: 구현 (철저하게 작업하도록 둠)
claude -p "TDD로 기능을 구현해. 테스트를 철저하게 작성해."
# 2단계: De-sloppify (별도의 컨텍스트, 집중된 정리)
claude -p "작업 트리의 모든 변경 사항을 리뷰해. 다음을 제거해:
- 비즈니스 로직이 아닌 언어/프레임워크 동작을 검증하는 테스트
- 타입 시스템이 이미 강제하는 중복된 타입 체크
- 불가능한 상태에 대한 과도하게 방어적인 에러 처리
- Console.log 문
- 주석 처리된 코드
모든 비즈니스 로직 테스트는 유지해. 정리 후 테스트 스위트를 실행하여 깨지는 부분이 없는지 확인해."
for feature in "${features[@]}"; do
# 구현
claude -p "$feature를 TDD로 구현해."
# De-sloppify
claude -p "정리 단계: 변경 사항 리뷰, 테스트/코드 슬롭 제거, 테스트 실행."
# 검증
claude -p "빌드 + 린트 + 테스트 실행. 실패 시 수정."
# 커밋
claude -p "커밋 메시지: feat: add $feature"
done
품질에 다운스트림 효과를 주는 부정적 지시를 추가하는 대신, 별도의 de-sloppify 단계를 추가하세요. 집중된 두 에이전트가 제약된 하나의 에이전트보다 성능이 뛰어납니다.
가장 정교한 패턴. 사양을 종속성 DAG로 분해하고, 각 단위를 계층화된 품질 파이프라인을 통해 실행하며, 에이전트 기반 머지 큐를 통해 반영하는 RFC 기반 다중 에이전트 파이프라인입니다. enitrat가 제작했습니다(출처: @enitrat).
RFC/PRD 문서
│
▼
분해 (AI)
RFC를 종속성 DAG가 있는 작업 단위로 분해
│
▼
┌──────────────────────────────────────────────────────┐
│ RALPH 루프 (최대 3회 패스) │
│ │
│ 각 DAG 레이어에 대해 (종속성에 따라 순차 실행): │
│ │
│ ┌── 품질 파이프라인 (단위별 병렬 실행) ────────────┐ │
│ │ 각 단위는 고유한 워크트리에서 실행: │ │
│ │ 리서치 → 계획 → 구현 → 테스트 → 리뷰 │ │
│ │ (깊이는 복잡도 티어에 따라 다름) │ │
│ └────────────────────────────────────────────────┘ │
│ │
│ ┌── 머지 큐 (Merge Queue) ───────────────────────┐ │
│ │ main으로 리베이스 → 테스트 실행 → 반영 또는 퇴출 │ │
│ │ 퇴출된 단위는 충돌 컨텍스트와 함께 재진입 │ │
│ └────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────┘
AI가 RFC를 읽고 작업 단위를 생성합니다:
interface WorkUnit {
id: string; // kebab-case 식별자
name: string; // 가독성 있는 이름
rfcSections: string[]; // 이 단위가 다루는 RFC 섹션
description: string; // 상세 설명
deps: string[]; // 종속성 (다른 단위 ID)
acceptance: string[]; // 구체적인 수락 기준
tier: "trivial" | "small" | "medium" | "large";
}
분해 규칙:
종속성 DAG가 실행 순서를 결정합니다:
레이어 0: [unit-a, unit-b] ← 종속성 없음, 병렬 실행
레이어 1: [unit-c] ← unit-a에 종속
레이어 2: [unit-d, unit-e] ← unit-c에 종속
티어마다 파이프라인 깊이가 다릅니다:
| 티어 | 파이프라인 단계 |
|---|---|
| trivial | 구현 → 테스트 |
| small | 구현 → 테스트 → 코드 리뷰 |
| medium | 리서치 → 계획 → 구현 → 테스트 → PRD 리뷰 + 코드 리뷰 → 리뷰 수정 |
| large | 리서치 → 계획 → 구현 → 테스트 → PRD 리뷰 + 코드 리뷰 → 리뷰 수정 → 최종 리뷰 |
이는 간단한 변경 사항에 대한 과도한 비용을 방지하면서도 아키텍처 변경에는 철저한 검증을 보장합니다.
각 단계는 자체 컨텍스트 창과 자체 에이전트 프로세스에서 실행됩니다:
| 단계 | 모델 | 목적 |
|---|---|---|
| 리서치 | Sonnet | 코드베이스 + RFC 읽기, 컨텍스트 문서 생성 |
| 계획 | Opus | 구현 단계 설계 |
| 구현 | Codex | 계획을 따라 코드 작성 |
| 테스트 | Sonnet | 빌드 + 테스트 스위트 실행 |
| PRD 리뷰 | Sonnet | 사양 준수 확인 |
| 코드 리뷰 | Opus | 품질 + 보안 체크 |
| 리뷰 수정 | Codex | 리뷰 이슈 해결 |
| 최종 리뷰 | Opus | 품질 게이트 (large 티어 전용) |
핵심 설계: 리뷰어는 자신이 리뷰하는 코드를 직접 작성하지 않았습니다. 이는 저자 편향(author bias)을 제거합니다. 이는 자기 리뷰에서 이슈를 놓치는 가장 흔한 원인입니다.
품질 파이프라인이 완료되면 단위가 머지 큐에 들어갑니다:
단위 브랜치
│
├─ main으로 리베이스
│ └─ 충돌? → 퇴출 (충돌 컨텍스트 캡처)
│
├─ 빌드 + 테스트 실행
│ └─ 실패? → 퇴출 (테스트 출력 캡처)
│
└─ 통과 → main 패스트 포워드, 푸시, 브랜치 삭제
파일 중복 인텔리전스:
퇴출 복구: 퇴출 시 전체 컨텍스트(충돌 파일, diff, 테스트 출력)가 캡처되어 다음 Ralph 패스에서 구현자에게 제공됩니다:
## 머지 충돌 — 다음 반영 전에 해결 필요
이전 구현이 먼저 반영된 다른 단위와 충돌했습니다.
아래의 충돌 파일/라인을 피하도록 변경 사항을 재구성하세요.
{전체 퇴출 컨텍스트와 diff}
리서치.컨텍스트파일경로 ──────────────────→ 계획
계획.구현단계 ────────────────────────────→ 구현
구현.{생성된파일, 작업내용} ─────────────→ 테스트, 리뷰
테스트.실패요약 ──────────────────────────→ 리뷰, 구현 (다음 패스)
리뷰.{피드백, 이슈} ───────────────────→ 리뷰 수정 → 구현 (다음 패스)
최종리뷰.추론 ────────────────────────────→ 구현 (다음 패스)
퇴출컨텍스트 ─────────────────────────────→ 구현 (머지 충돌 후)
모든 단위는 격리된 워크트리에서 실행됩니다(git 대신 jj/Jujutsu 사용):
/tmp/workflow-wt-{unit-id}/
동일 단위의 파이프라인 단계는 워크트리를 공유하여 리서치 → 계획 → 구현 → 테스트 → 리뷰 과정 동안 상태(컨텍스트 파일, 계획 파일, 코드 변경 사항)를 보존합니다.
| 시그널 | Ralphinho 사용 | 단순 패턴 사용 |
|---|---|---|
| 상호 의존적인 여러 작업 단위 | 예 | 아니요 |
| 병렬 구현 필요 | 예 | 아니요 |
| 머지 충돌 발생 가능성 높음 | 예 | 아니요 (순차 실행으로 충분) |
| 단일 파일 변경 | 아니요 | 예 (순차 파이프라인) |
| 다일간의 프로젝트 | 예 | 아마도 (continuous-claude) |
| 사양/RFC가 이미 작성됨 | 예 | 아마도 |
| 하나에 대해 빠른 반복 작업 | 아니요 | 예 (NanoClaw 또는 파이프라인) |
작업이 하나의 집중된 변경인가?
├─ 예 → 순차적 파이프라인 또는 NanoClaw
└─ 아니요 → 작성된 사양/RFC가 있는가?
├─ 예 → 병렬 구현이 필요한가?
│ ├─ 예 → Ralphinho (DAG 오케스트레이션)
│ └─ 아니요 → 지속적 Claude (반복적 PR 루프)
└─ 아니요 → 동일한 내용의 여러 변형이 필요한가?
├─ 예 → 무한 에이전트 루프 (사양 중심 생성)
└─ 아니요 → De-sloppify를 포함한 순차적 파이프라인
이 패턴들은 서로 잘 조합됩니다:
순차적 파이프라인 + De-Sloppify — 가장 흔한 조합. 모든 구현 단계에 정리 패스를 추가합니다.
지속적 Claude + De-Sloppify — 각 반복에 de-sloppify 지시어가 포함된 --review-prompt를 추가합니다.
모든 루프 + 검증 — 커밋 전 게이트로 ECC의 /verify 명령어 또는 verification-loop 스킬을 사용합니다.
단순 루프에서의 Ralphinho식 계층화 접근 — 순차적 파이프라인에서도 간단한 작업은 Haiku로, 복잡한 작업은 Opus로 라우팅할 수 있습니다:
# 간단한 포맷팅 수정
claude -p --model haiku "src/utils.ts의 임포트 순서 수정해"
# 복잡한 아키텍처 변경
claude -p --model opus "인증 모듈을 전략 패턴을 사용하도록 리팩터링해"
종료 조건 없는 무한 루프 — 항상 max-runs, max-cost, max-duration 또는 완료 신호를 설정하세요.
반복 간 컨텍스트 브리지 없음 — 각 claude -p 호출은 새로 시작됩니다. 반복 간 컨텍스트를 잇기 위해 SHARED_TASK_NOTES.md나 파일 시스템 상태를 활용하세요.
동일한 실패 재시도 — 반복이 실패하면 그냥 다시 시도하지 마세요. 에러 컨텍스트를 캡처하여 다음 시도에 제공하세요.
정리 단계 대신 부정적 지시 사용 — "X를 하지 마"라고 말하지 마세요. X를 제거하는 별도의 패스를 추가하세요.
모든 에이전트를 하나의 컨텍스트 창에 배치 — 복잡한 워크플로의 경우 관심사를 서로 다른 에이전트 프로세스로 분리하세요. 리뷰어는 절대로 작성자가 되어서는 안 됩니다.
병렬 작업에서의 파일 중복 무시 — 두 병렬 에이전트가 동일한 파일을 수정할 수 있는 경우, 머지 전략(순차 반영, 리베이스 또는 충돌 해결)이 필요합니다.
| 프로젝트 | 저자 | 링크 |
|---|---|---|
| Ralphinho | enitrat | 출처: @enitrat |
| 무한 에이전트 루프 | disler | 출처: @disler |
| 지속적 Claude | AnandChowdhary | 출처: @AnandChowdhary |
| NanoClaw | ECC | 이 저장소의 /claw 명령어 |
| 검증 루프 (Verification Loop) | ECC | 이 저장소의 skills/verification-loop/ |