| name | autonomous-loops |
| description | 단순한 순차적 파이프라인에서 RFC 기반 다중 에이전트 DAG 시스템에 이르기까지 자율적인 Claude Code 루프를 위한 패턴과 아키텍처. |
| origin | ECC |
자율 루프 스킬 (Autonomous Loops Skill)
호환성 참고 (v1.8.0): autonomous-loops는 한 번의 릴리스 동안 유지됩니다.
표준 스킬 이름은 이제 continuous-agent-loop입니다. 새로운 루프 가이드는
그곳에서 작성되어야 하며, 이 스킬은 기존 워크플로가 깨지는 것을 방지하기 위해
계속 사용 가능합니다.
자율 루프에서 Claude Code를 실행하기 위한 패턴, 아키텍처 및 참조 구현입니다. 단순한 claude -p 파이프라인부터 완전한 RFC 기반 다중 에이전트 DAG 오케스트레이션에 이르기까지 모든 것을 다룹니다.
사용 시점
- 인간의 개입 없이 실행되는 자율 개발 워크플로를 설정할 때
- 문제에 적합한 루프 아키텍처(단순 vs 복잡)를 선택할 때
- CI/CD 스타일의 지속적 개발 파이프라인을 구축할 때
- 병렬 에이전트를 실행하고 머지(merge) 조정을 수행할 때
- 루프 반복 간에 컨텍스트 지속성을 구현할 때
- 자율 워크플로에 품질 게이트(quality gate) 및 정리 단계를 추가할 때
루프 패턴 스펙트럼
가장 단순한 것부터 가장 정교한 것까지:
1. 순차적 파이프라인 (claude -p)
가장 단순한 루프. 일상적인 개발을 비대화형 claude -p 호출 시퀀스로 나눕니다. 각 호출은 명확한 프롬프트가 있는 집중된 단계입니다.
핵심 통찰
이런 루프를 구성할 수 없다면, 대화형 모드에서조차 LLM이 코드를 수정하도록 유도할 수 없다는 뜻입니다.
claude -p 플래그는 프롬프트와 함께 Claude Code를 비대화형으로 실행하고 완료되면 종료됩니다. 호출을 체이닝하여 파이프라인을 구축합니다.
#!/bin/bash
set -e
claude -p "docs/auth-spec.md의 사양을 읽고 src/auth/에 OAuth2 로그인을 구현해. 테스트를 먼저 작성해(TDD). 새로운 문서 파일은 생성하지 마."
claude -p "이전 커밋에서 변경된 모든 파일을 리뷰해. 불필요한 타입 테스트, 과도하게 방어적인 체크, 또는 언어 기능 테스트(예: TypeScript 제네릭 작동 확인)를 제거해. 실제 비즈니스 로직 테스트는 유지해. 정리 후 테스트 스위트를 실행해."
claude -p "전체 빌드, 린트, 타입 체크 및 테스트 스위트를 실행해. 실패한 부분을 수정해. 새로운 기능은 추가하지 마."
claude -p "스테이징된 모든 변경 사항에 대해 컨벤션 커밋을 생성해. 메시지는 'feat: add OAuth2 login flow'로 해."
주요 설계 원칙
- 각 단계의 격리 — 각
claude -p 호출마다 신선한 컨텍스트 창이 사용되므로 단계 간의 컨텍스트 오염이 없습니다.
- 순서가 중요함 — 단계는 순차적으로 실행됩니다. 각 단계는 이전 단계가 남긴 파일 시스템 상태를 바탕으로 작동합니다.
- 부정적 지시는 위험함 — "타입 시스템을 테스트하지 마"라고 말하지 마세요. 대신 별도의 정리 단계를 추가하세요(De-Sloppify 패턴 참조).
- 종료 코드 전파 —
set -e는 실패 시 파이프라인을 중단합니다.
변형
모델 라우팅 활용:
claude -p --model opus "코드베이스 아키텍처를 분석하고 캐싱 추가를 위한 계획을 작성해..."
claude -p "docs/caching-plan.md의 계획에 따라 캐싱 레이어를 구현해..."
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의 수정 사항을 구현해..."
2. NanoClaw REPL
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에 전송됩니다.
- 응답은 세션 파일에 추가됩니다(Markdown-as-database).
- 세션은 재시작 후에도 유지됩니다.
NanoClaw vs 순차적 파이프라인
| 사용 사례 | NanoClaw | 순차적 파이프라인 |
|---|
| 대화형 탐색 | 예 | 아니요 |
| 스크립트 기반 자동화 | 아니요 | 예 |
| 세션 지속성 | 내장됨 | 수동 |
| 컨텍스트 축적 | 턴마다 증가 | 각 단계마다 새로 시작 |
| CI/CD 통합 | 부족함 | 우수함 |
자세한 내용은 /claw 명령어 문서를 참조하세요.
3. 무한 에이전트 루프 (Infinite Agentic Loop)
사양 중심 생성을 위해 병렬 하위 에이전트를 오케스트레이션하는 투-프롬프트(Two-Prompt) 시스템입니다. disler가 개발했습니다(출처: @disler).
아키텍처: 투-프롬프트 시스템
프롬프트 1 (오케스트레이터) 프롬프트 2 (하위 에이전트)
┌─────────────────────┐ ┌──────────────────────┐
│ 사양 파일 파싱 │ │ 전체 컨텍스트 수신 │
│ 출력 디렉터리 스캔 │ 배포 │ 할당된 번호 확인 │
│ 반복 계획 수립 │────────────│ 사양을 정확히 준수 │
│ 창의적 방향 할당 │ N개 에이전트│ 고유한 출력 생성 │
│ 웨이브(Wave) 관리 │ │ 출력 디렉터리에 저장 │
└─────────────────────┘ └──────────────────────┘
패턴
- 사양 분석 — 오케스트레이터가 생성할 내용을 정의한 사양 파일(Markdown)을 읽습니다.
- 디렉터리 정찰 — 기존 출력을 스캔하여 가장 높은 반복 번호를 찾습니다.
- 병렬 배포 — 다음을 포함하여 N개의 하위 에이전트를 시작합니다:
- 전체 사양 텍스트
- 고유한 창의적 방향
- 특정 반복 번호 (충돌 없음)
- 기존 반복 내용의 스냅샷 (고유성 보장)
- 웨이브 관리 — 무한 모드의 경우, 컨텍스트가 소진될 때까지 3-5개 에이전트로 구성된 웨이브를 배포합니다.
Claude Code 명령어를 통한 구현
.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개 단위 웨이브, 점진적 고도화 |
핵심 통찰: 할당을 통한 고유성 보장
에이전트가 스스로 차별화하기를 기대하지 마세요. 오케스트레이터가 각 에이전트에게 특정 창의적 방향과 반복 번호를 할당해야 합니다. 이를 통해 병렬 에이전트 간의 개념 중복을 방지합니다.
4. 지속적 Claude PR 루프 (Continuous Claude PR Loop)
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에 연결하지 마세요.
사용법
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
중요한 혁신: SHARED_TASK_NOTES.md 파일이 반복 간에 컨텍스트를 유지합니다.
## 진행 상황
- [x] 인증 모듈 테스트 추가 (반복 1)
- [x] 토큰 갱신 엣지 케이스 수정 (반복 2)
- [ ] 남은 작업: 속도 제한 테스트, 에러 바운더리 테스트
## 다음 단계
- 다음에는 속도 제한 모듈에 집중할 것
- tests/helpers.ts의 모크 설정을 재사용할 수 있음
Claude는 반복 시작 시 이 파일을 읽고 종료 시 업데이트합니다. 이는 독립적인 claude -p 호출 간의 컨텍스트 격차를 메워줍니다.
CI 실패 복구
PR 체크가 실패하면 Continuous Claude는 자동으로 다음을 수행합니다:
gh run list를 통해 실패한 실행 ID를 가져옵니다.- CI 수정 컨텍스트와 함께 새로운
claude -p를 실행합니다.
- Claude는
gh run view를 통해 로그를 검사하고, 코드를 수정하고, 커밋하고 푸시합니다.
- 다시 체크를 기다립니다(최대
--ci-retry-max 횟수만큼).
완료 신호
Claude는 매직 구문을 출력하여 "작업 완료" 신호를 보낼 수 있습니다.
continuous-claude \
--prompt "이슈 트래커의 모든 버그 수정" \
--completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
--completion-threshold 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) |
5. De-Sloppify 패턴
모든 루프를 위한 추가 패턴. 각 구현 단계 후에 전용 정리/리팩터링 단계를 추가합니다.
문제점
LLM에게 TDD로 구현하라고 요청하면 "테스트 작성"을 너무 문자 그대로 받아들일 때가 있습니다:
- TypeScript의 타입 시스템이 작동하는지 확인하는 테스트(
typeof x === 'string' 테스트 등)
- 타입 시스템이 이미 보장하는 내용에 대한 과도한 방어적 런타임 체크
- 비즈니스 로직보다는 프레임워크 동작에 대한 테스트
- 실제 코드를 가리는 과도한 에러 처리
왜 부정적 지시를 쓰지 않는가?
구현 프롬프트에 "타입 시스템을 테스트하지 마" 또는 "불필요한 체크를 추가하지 마"라고 추가하면 다운스트림 효과가 발생합니다:
- 모델이 모든 테스트에 대해 주저하게 됨
- 정당한 엣지 케이스 테스트까지 건너뛰게 됨
- 품질이 예측 불가능하게 저하됨
해결책: 별도의 단계
구현 에이전트를 제약하는 대신 철저하게 작업하도록 둡니다. 그 다음 집중된 정리 에이전트를 추가합니다.
claude -p "TDD로 기능을 구현해. 테스트를 철저하게 작성해."
claude -p "작업 트리의 모든 변경 사항을 리뷰해. 다음을 제거해:
- 비즈니스 로직이 아닌 언어/프레임워크 동작을 검증하는 테스트
- 타입 시스템이 이미 강제하는 중복된 타입 체크
- 불가능한 상태에 대한 과도하게 방어적인 에러 처리
- Console.log 문
- 주석 처리된 코드
모든 비즈니스 로직 테스트는 유지해. 정리 후 테스트 스위트를 실행하여 깨지는 부분이 없는지 확인해."
루프 컨텍스트에서의 활용
for feature in "${features[@]}"; do
claude -p "$feature를 TDD로 구현해."
claude -p "정리 단계: 변경 사항 리뷰, 테스트/코드 슬롭 제거, 테스트 실행."
claude -p "빌드 + 린트 + 테스트 실행. 실패 시 수정."
claude -p "커밋 메시지: feat: add $feature"
done
핵심 통찰
품질에 다운스트림 효과를 주는 부정적 지시를 추가하는 대신, 별도의 de-sloppify 단계를 추가하세요. 집중된 두 에이전트가 제약된 하나의 에이전트보다 성능이 뛰어납니다.
6. Ralphinho / RFC 기반 DAG 오케스트레이션
가장 정교한 패턴. 사양을 종속성 DAG로 분해하고, 각 단위를 계층화된 품질 파이프라인을 통해 실행하며, 에이전트 기반 머지 큐를 통해 반영하는 RFC 기반 다중 에이전트 파이프라인입니다. enitrat가 제작했습니다(출처: @enitrat).
아키텍처 개요
RFC/PRD 문서
│
▼
분해 (AI)
RFC를 종속성 DAG가 있는 작업 단위로 분해
│
▼
┌──────────────────────────────────────────────────────┐
│ RALPH 루프 (최대 3회 패스) │
│ │
│ 각 DAG 레이어에 대해 (종속성에 따라 순차 실행): │
│ │
│ ┌── 품질 파이프라인 (단위별 병렬 실행) ────────────┐ │
│ │ 각 단위는 고유한 워크트리에서 실행: │ │
│ │ 리서치 → 계획 → 구현 → 테스트 → 리뷰 │ │
│ │ (깊이는 복잡도 티어에 따라 다름) │ │
│ └────────────────────────────────────────────────┘ │
│ │
│ ┌── 머지 큐 (Merge Queue) ───────────────────────┐ │
│ │ main으로 리베이스 → 테스트 실행 → 반영 또는 퇴출 │ │
│ │ 퇴출된 단위는 충돌 컨텍스트와 함께 재진입 │ │
│ └────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────┘
RFC 분해
AI가 RFC를 읽고 작업 단위를 생성합니다:
interface WorkUnit {
id: string;
name: string;
rfcSections: string[];
description: string;
deps: string[];
acceptance: string[];
tier: "trivial" | "small" | "medium" | "large";
}
분해 규칙:
- 더 적고 응집력 있는 단위를 선호 (머지 리스크 최소화)
- 단위 간 파일 중복 최소화 (충돌 방지)
- 테스트는 구현과 함께 유지 (절대 "X 구현" + "X 테스트"로 나누지 않음)
- 실제 코드 종속성이 있는 경우에만 종속성 설정
종속성 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}/
동일 단위의 파이프라인 단계는 워크트리를 공유하여 리서치 → 계획 → 구현 → 테스트 → 리뷰 과정 동안 상태(컨텍스트 파일, 계획 파일, 코드 변경 사항)를 보존합니다.
주요 설계 원칙
- 결정론적 실행 — 사전 분해를 통해 병렬성 및 순서 고정
- 레버리지 포인트에서의 인간 리뷰 — 작업 계획은 가장 큰 레버리지를 가진 개입 지점임
- 관심사 분리 — 각 단계를 별도의 에이전트 프로세스와 컨텍스트 창에서 실행
- 컨텍스트 기반 충돌 복구 — 퇴출 컨텍스트를 통해 맹목적인 재시도가 아닌 지능적인 재실행 가능
- 티어 기반 깊이 — 사소한 변경은 리서치/리뷰 건너뜀, 대규모 변경은 최대 검증
- 재개 가능한 워크플로 — 전체 상태가 SQLite에 저장되어 어느 지점에서든 재개 가능
Ralphinho vs 단순 패턴 선택
| 시그널 | 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/ |
