Claude Code 자율 코딩 스킬 생태계 — autopilot부터 team까지 실무 정리
oh-my-claudecode·superpowers·octo 스킬로 요구사항 분석부터 배포까지 인간 개입 없이 처리하는 자율 코딩 파이프라인과 스킬별 실행 명령을 정리한다
2026-08-12 · 최초 발행 2026-04-17
Claude Code에 설치된 스킬(oh-my-claudecode, superpowers, octo)을 조합하면, 초기 프롬프트나 계획 승인만 던져주고 나머지는 에이전트에게 맡기는 자율 코딩이 가능해진다. 요구사항 분석 → 기술 설계 → 계획 수립 → 구현 → 테스트 → 검증 → 정제로 이어지는 사이클 전체를 에이전트가 스스로 돌리고, 실패하면 자동으로 되돌아가 수정한다.
요구사항 분석 → 기술 설계 → 계획 수립 → 코드 구현 → 테스트 → 검증 → 정제 → 완성
↑ ↓
└──────────────────── 실패 시 자동 수정 ─────────────────────┘
이 자율화가 굴러가는 배경에는 다섯 가지 원칙이 있다.
| 원칙 | 설명 |
|---|---|
| 증거 우선 | 가정이 아닌 테스트 결과로 완료를 판단 |
| 병렬 실행 | 독립 작업은 동시에 실행하여 시간 단축 |
| 전문 위임 | 각 작업을 최적의 전문 에이전트에게 위임 |
| 반복 수정 | 실패 시 자동 분석 및 재시도 (포기하지 않음) |
| 분리 검증 | 작성자와 검증자를 분리하여 객관적 평가 |
스킬 생태계 전체 지도
설치된 스킬을 역할별로 나누면 사전 준비, 핵심 실행, 사후 검증, 보조 도구 네 층으로 정리된다.
┌─────────────────────────────────────────────────────────────────────┐
│ VIBE AUTO CODING 스킬 생태계 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─ 사전 준비 (Pre-Execution) ──────────────────────────────────┐ │
│ │ deep-interview 요구사항 정제 (모호도 20% 이하까지) │ │
│ │ brainstorming 창의적 탐색 및 아이디어 확장 │ │
│ │ octo:prd AI 최적화 PRD 문서 생성 │ │
│ │ ralplan Planner+Architect+Critic 합의 계획 │ │
│ │ writing-plans 구현 계획 작성 │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─ 핵심 실행 (Execution) ──────────────────────────────────────┐ │
│ │ autopilot 완전 자율 (6단계 파이프라인) Level 4 │ │
│ │ ralph PRD 기반 검증 루프 Level 4 │ │
│ │ team N개 에이전트 협업 파이프라인 Level 4 │ │
│ │ ultrawork 병렬 실행 컴포넌트 Level 3 │ │
│ │ octo:factory Dark Factory (spec-in, software-out) Level 5 │ │
│ │ octo:embrace Double Diamond 전체 워크플로우 Level 5 │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─ 사후 검증 (Post-Execution) ─────────────────────────────────┐ │
│ │ ultraqa QA 사이클링 (최대 5회) │ │
│ │ verify 증거 기반 최종 검증 │ │
│ │ ai-slop-cleaner AI 코드 슬롭 제거 │ │
│ │ verification 완료 전 필수 검증 │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─ 보조 도구 (Support) ────────────────────────────────────────┐ │
│ │ ccg Claude+Codex+Gemini 3모델 합성 │ │
│ │ sciomc 병렬 연구 오케스트레이션 │ │
│ │ external-context 외부 문서 병렬 수집 │ │
│ │ deepinit 코드베이스 AGENTS.md 초기화 │ │
│ │ self-improve 자율 진화 코드 개선 │ │
│ └───────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
3-Stage 파이프라인 — 가장 품질이 높은 실행 경로
oh-my-claudecode는 3단계 파이프라인으로 최고 품질의 자율 실행을 지원한다. 각 단계의 결과는 다음 단계로 자동 전달되고, 이미 끝난 단계는 건너뛴다.
Stage 1 Stage 2 Stage 3
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│deep-interview│ ───────→ │ ralplan │ ───────→ │ autopilot │
│ │ │ │ │ │
│ 모호도 측정 │ │ 3자 합의 계획 │ │ 자율 구현 │
│ 소크라테스 질문 │ │ Planner │ │ Phase 0 생략 │
│ 명세서 출력 │ │ Architect │ │ Phase 1 생략 │
│ │ │ Critic │ │ Phase 2~5 │
└──────────────┘ └──────────────┘ └──────────────┘
개입: 질문 응답 개입: 계획 승인 개입: 없음
요구사항이 얼마나 명확한지에 따라 1~3 스테이지 중 어디서 시작할지가 갈린다.
# 전체 3-Stage 파이프라인 (가장 높은 품질)
/deep-interview FastAPI 기반 이커머스 API를 만들고 싶어
# → 질문에 답하면 명세서 생성 → ralplan 자동 연결 → autopilot 자동 실행
# 2-Stage: 계획부터 시작 (요구사항이 명확할 때)
/ralplan FastAPI 이커머스 API. 상품/주문/결제 CRUD, JWT 인증, pytest 테스트
# → 계획 승인 후 자동 실행
# 1-Stage: 바로 실행 (프롬프트가 충분히 구체적일 때)
/autopilot FastAPI 이커머스 API 구현. 상품 CRUD, 주문 처리, JWT 인증. pytest 포함.핵심 실행 스킬
autopilot — 완전 자율 실행 엔진
아이디어 한 줄로 완성된 프로그램을 만드는 Level 4 스킬이다. 6개 Phase를 순차 실행하며, 각 Phase 내부에서는 병렬 실행을 최대화한다.
명령어: /autopilot <프롬프트>
트리거 키워드: autopilot, auto pilot, autonomous, build me, create me, make me, full auto, handle it all
Phase 0: Expansion ──→ Phase 1: Planning ──→ Phase 2: Execution
(아이디어→명세) (명세→계획) (계획→코드)
[ralplan 있으면 생략] [ralplan 있으면 생략] [Ralph + Ultrawork]
│ │ │
↓ ↓ ↓
Phase 5: Cleanup ←── Phase 4: Validation ←── Phase 3: QA
(상태 파일 삭제) (다중 관점 검증) (테스트 사이클링)
[성공 시에만] [전원 승인 필수] [최대 5회 반복]
| Phase | 역할 | 상세 |
|---|---|---|
| Phase 0 | Expansion | 2~3줄 아이디어를 상세 명세서로 확장 |
| Phase 1 | Planning | 명세서에서 구현 계획 생성 |
| Phase 2 | Execution | Ralph + Ultrawork로 병렬 구현 |
| Phase 3 | QA | 테스트 실행 → 실패 시 수정 (최대 5사이클, 동일 오류 3회 시 중단) |
| Phase 4 | Validation | Architect + Security-reviewer + Code-reviewer 3자 검증 (전원 승인 필수) |
| Phase 5 | Cleanup | 성공 시 모든 상태 파일 삭제 |
반복 횟수나 Phase 생략 여부는 설정 파일에서 조정할 수 있다.
{
"autopilot": {
"maxIterations": 10, // 전체 최대 반복
"maxQaCycles": 5, // Phase 3 QA 최대 사이클
"maxValidationRounds": 3, // Phase 4 검증 최대 라운드
"skipExpansion": false, // Phase 0 생략 여부
"skipPlanning": false, // Phase 1 생략 여부
},
}# 기본 사용
/autopilot FastAPI로 TODO 앱 API 만들어줘. CRUD + JWT 인증 + pytest
# 상세 프롬프트
/autopilot Python FastAPI로 블로그 REST API를 구현해줘.
- 기술 스택: FastAPI, SQLAlchemy, SQLite, Pydantic v2
- API: POST/GET/PUT/DELETE /posts, POST/GET /posts/{id}/comments
- pytest 테스트 전체 커버리지
- 라우터/모델/스키마 분리 구조
# ralplan 결과 이후 자동 연결 (Phase 0, 1 생략)
/ralplan 블로그 API 구현 → 승인 → autopilot 자동 시작중소규모 프로젝트, 단일 서비스, API 서버, CLI 도구에 적합하다. 탐색·브레인스토밍만 필요할 때, 단일 파일 수정, 코드 리뷰에는 맞지 않는다.
ralph — PRD 기반 검증 루프
PRD(Product Requirements Document)의 사용자 스토리를 하나씩 구현하고, 각 스토리의 수락 기준을 검증한 후 다음 스토리로 진행하는 Level 4 스킬이다.
명령어: /ralph <프롬프트>
트리거 키워드: ralph
┌─────────────────────────────────────────────────────────────┐
│ Ralph 실행 루프 │
│ │
│ 1. PRD 설정 (prd.json 생성/로드) │
│ ↓ │
│ 2. 다음 미완료 스토리 선택 │
│ ↓ │
│ 3. 전문 에이전트로 구현 (executor, designer, debugger 등) │
│ ↓ │
│ 4. 수락 기준 검증 (fresh evidence 수집) │
│ ↓ │
│ 5. 통과? ──No──→ 원인 분석 → 수정 → 4번으로 │
│ │ │
│ Yes │
│ ↓ │
│ 6. 스토리 완료 표시 (passes: true) │
│ ↓ │
│ 7. 모든 스토리 완료? ──No──→ 2번으로 │
│ │ │
│ Yes │
│ ↓ │
│ 8. 리뷰어 검증 (architect/critic/codex 중 선택) │
│ ↓ │
│ 8.5. Deslop Pass (ai-slop-cleaner 자동 실행) │
│ ↓ │
│ 8.6. 회귀 재검증 (deslop 후 기존 기능 확인) │
│ ↓ │
│ 9. 승인? ──No──→ 피드백 반영 → 수정 → 8번으로 │
│ │ │
│ Yes │
│ ↓ │
│ 10. 완료 + /cancel로 깔끔한 종료 │
│ │
└─────────────────────────────────────────────────────────────┘
시작하면 자동으로 prd.json 스캐폴드를 만든다.
{
"title": "프로젝트 제목",
"stories": [
{
"id": "S1",
"title": "사용자 회원가입",
"acceptance": [
"POST /auth/register 201 응답",
"비밀번호 해시 저장",
"중복 이메일 거부"
],
"passes": false
},
{
"id": "S2",
"title": "로그인 및 JWT 발급",
"acceptance": [
"POST /auth/login 200 + JWT 토큰",
"잘못된 비밀번호 시 401"
],
"passes": false
}
]
}ralph와 autopilot은 겹치는 듯 보이지만 구조가 다르다.
| 특성 | Ralph | Autopilot |
|---|---|---|
| 구조 | 스토리 단위 반복 | 6-Phase 순차 실행 |
| 추적 | prd.json으로 진행 상황 추적 | 내부 상태 관리 |
| 재개 | 중단 후 재개 가능 (미완료 스토리부터) | 재개 가능 (마지막 Phase부터) |
| 코드 정제 | Deslop Pass 자동 포함 | 미포함 |
| 검증 강도 | 스토리별 + 전체 리뷰어 | Phase 4에서 3자 검증 |
| 적합한 크기 | 중~대규모 | 소~중규모 |
# 기본 사용
/ralph 사용자 인증 시스템 구현. 회원가입, 로그인, 프로필 조회 API.
# 리뷰어 지정
/ralph --reviewer architect "결제 시스템 구현"
# Deslop 생략 (속도 우선)
/ralph --no-deslop "프로토타입 빠르게 만들어줘"team — 다중 에이전트 협업 파이프라인
N개의 에이전트가 역할을 나눠 병렬로 작업하는 Level 4 스킬이다. 5단계 파이프라인을 지원하며, 단계별로 전문 에이전트가 자동 배정된다.
명령어: /team N:agent-type "작업 설명"
team-plan → team-prd → team-exec → team-verify → team-fix (루프)
| Stage | 역할 | 배정 에이전트 |
|---|---|---|
| team-plan | 탐색 및 계획 | explore, planner, analyst, architect |
| team-prd | PRD 작성 | analyst, planner |
| team-exec | 구현 | executor, debugger, designer |
| team-verify | 검증 | verifier, code-reviewer |
| team-fix | 수정 (검증 실패 시) | executor, debugger |
에이전트끼리는 메시지와 공유 태스크 리스트로 조율한다.
┌────────────┐ SendMessage ┌────────────┐
│ Agent 1 │ ←───────────────→ │ Agent 2 │
│ (executor) │ (DM/Broadcast) │ (executor) │
└─────┬──────┘ └─────┬──────┘
│ 공유 태스크 리스트 │
└──────────→ TaskList ←────────────┘
TaskCreate
TaskUpdate
각 단계가 끝나면 .omc/handoffs/<stage-name>.md에 핸드오프 문서를 남겨 다음 단계에 컨텍스트를 전달한다.
# 기본: 3개 executor가 모듈별 병렬 구현
/team 3:executor "이커머스: 1) 상품 서비스 2) 주문 서비스 3) 결제 서비스"
# 혼합 에이전트 타입
/team 2:executor,1:designer "대시보드 앱: API + 프론트엔드 + UI 디자인"
# Ralph 통합 (검증 루프 래핑)
/team ralph 3:executor "마이크로서비스 구현 후 통합 테스트까지"
# CLI 워커 혼합 (Codex/Gemini 활용)
/team 2:executor,1:codex "다중 모델로 API 구현 및 리뷰"OMC_TEAM_SCALING_ENABLED=1을 설정하면 실행 중에 에이전트 수를 동적으로 조정할 수 있다.
ultrawork — 병렬 실행 컴포넌트
독립적인 여러 작업을 동시에 실행하는 Level 3 컴포넌트다. Ralph와 Autopilot의 내부 실행 엔진으로 쓰이며, 단독으로도 쓸 수 있다.
명령어: /ultrawork <작업 설명>
트리거 키워드: ulw, ultrawork
ultrawork는 독립형 스킬이라기보다 다른 스킬에 조합되는 컴포넌트에 가깝다.
┌──────────────────────────────────────────────────┐
│ autopilot = Expansion + Planning + Ultrawork │
│ + QA + Validation │
│ │
│ ralph = PRD + Ultrawork + Verification │
│ + Deslop │
│ │
│ ultrawork = 순수 병렬 실행 (검증은 경량) │
└──────────────────────────────────────────────────┘
작업 복잡도에 따라 에이전트 티어가 자동 선택된다.
| 작업 복잡도 | 모델 | 예시 |
|---|---|---|
| 간단한 조회 | Haiku | 파일 탐색, 설정 확인 |
| 표준 구현 | Sonnet | 기능 구현, 테스트 작성 |
| 복잡한 분석 | Opus | 아키텍처 설계, 보안 감사 |
# 3개 독립 모듈 동시 구현
/ultrawork 동시에 구현: 1) 사용자 모델 2) 인증 미들웨어 3) API 라우터
# 여러 파일 동시 리팩토링
/ultrawork 모든 서비스 파일에서 동기 DB 호출을 async/await로 변환독립적인 여러 작업이 있을 때, Ralph나 Autopilot 없이 빠르게 병렬 실행하고 싶을 때 적합하다. 다만 검증이 경량이므로 높은 정확도가 필요하면 Ralph나 Autopilot을 쓰는 편이 낫다.
실행 전 품질 게이트 — 사전 준비 스킬
deep-interview — 소크라테스식 요구사항 정제
모호한 아이디어를 수학적 모호도 측정으로 정제해 명확한 명세서로 바꾼다.
명령어: /deep-interview <아이디어>
4개 차원에서 가중치 기반으로 모호도를 측정하며, 20% 이하가 되어야 다음 단계로 진행한다.
| 차원 | 가중치 | 측정 내용 |
|---|---|---|
| Goal (목표) | 높음 | 무엇을 달성하려는가? |
| Constraints (제약) | 중간 | 기술 스택, 성능, 보안 요구사항 |
| Success Criteria (성공 기준) | 높음 | 어떻게 완료를 판단하는가? |
| Context (맥락) | 낮음 | 기존 시스템, 팀, 환경 |
3가지 모드의 챌린지 에이전트가 요구사항의 약점을 공격한다.
| 모드 | 역할 |
|---|---|
| Contrarian | 반대 관점에서 약점 찾기 |
| Simplifier | 불필요한 복잡성 제거 |
| Ontologist | 용어와 개념의 모호성 해소 |
새 프로젝트인지 기존 코드에 얹는 작업인지도 자동으로 갈린다. Greenfield(새 프로젝트)는 전체 아키텍처 설계부터 시작하고, Brownfield(기존 코드)는 기존 코드베이스 분석 후 변경 범위를 제한한다.
# 모호한 아이디어로 시작 가능
/deep-interview 실시간 채팅 앱을 만들고 싶어
# → "어떤 플랫폼? 사용자 규모? 인증 방식? 메시지 저장?"
# → 질문에 답하면 모호도 점수가 점점 낮아짐
# → 20% 이하 도달 → 명세서 생성 → ralplan 자동 연결ralplan — 합의 기반 계획 수립
3명의 전문 에이전트(Planner, Architect, Critic)가 합의에 도달할 때까지 계획을 반복 검토한다.
명령어: /ralplan <요구사항>
1. Planner ──→ 초기 계획 + RALPLAN-DR 문서 작성
(Principles, Decision Drivers, Options, Pre-mortem, Test Plan)
↓
2. User Feedback (--interactive 모드에서만)
↓
3. Architect ──→ 기술적 타당성 검토 (순차 실행, 완료 대기)
↓
4. Critic ────→ 품질 기준 평가 (Architect 완료 후 실행)
↓
5. 전원 APPROVE? ──No──→ 피드백 반영 → 1번으로 (최대 5회)
│
Yes
↓
6. User 최종 승인 (--interactive 모드에서만)
↓
7. 실행 모드 선택 → team / ralph / autopilot
# 인터랙티브 모드 (핵심 결정 시점에 사용자 확인)
/ralplan --interactive 결제 시스템 구현
# 신중 모드 (고위험 작업: Pre-mortem + 확장 테스트 계획 추가)
/ralplan --deliberate 기존 인증 시스템 마이그레이션
# 외부 모델 활용
/ralplan --architect codex --critic codex 마이크로서비스 설계모호한 실행 요청은 자동으로 계획 단계로 리디렉션된다.
| 요청 | 판정 | 이유 |
|---|---|---|
ralph improve performance |
차단 → ralplan | "performance"가 모호 |
autopilot build the app |
차단 → ralplan | "the app"이 불명확 |
ralph fix src/auth.py:42 NPE |
통과 | 구체적 파일, 라인, 오류 |
force: ralph do something vague |
강제 통과 | force: 접두사 |
그 밖의 사전 준비 스킬
octo:prd는 AI 코딩 에이전트에 최적화된 PRD를 100점 스코어링 프레임워크로 작성한다.
# PRD 작성
/octo:prd 실시간 협업 문서 편집기
# 기존 PRD 점수 평가
/octo:prd-score ./docs/PRD.mdsuperpowers:brainstorming은 기능 추가, 컴포넌트 생성, 동작 변경 같은 창의적 작업 전에 자동으로 실행되어 의도와 요구사항을 탐색한다. superpowers:writing-plans는 명세나 요구사항이 있을 때 코드 작성 전 다단계 구현 계획을 생성하며, 역시 다단계 작업의 코드 작성 전에 자동 트리거된다.
완성도를 보장하는 사후 검증 스킬
ultraqa — QA 사이클링
테스트 → 진단 → 수정 → 재테스트 사이클을 자율적으로 반복한다.
명령어: /ultraqa <옵션>
/ultraqa --tests # 테스트 전체 통과까지
/ultraqa --build # 빌드 성공까지
/ultraqa --lint # 린트 오류 제로까지
/ultraqa --typecheck # 타입 체크 통과까지
/ultraqa --custom "패턴" # 커스텀 검증 패턴
/ultraqa --interactive # 대화형 QACycle 1 → 테스트 실행 → 실패 발견
↓
Architect 진단 (원인 분석)
↓
Executor 수정 (코드 변경)
↓
Cycle 2 → 재테스트 → 일부 통과
↓
... 반복 (최대 5 사이클)
↓
종료 조건: 목표 달성 / 최대 사이클 / 동일 실패 3회 / 환경 오류
verify — 증거 기반 검증
"잘 동작합니다"라는 말을 구체적 증거로 뒷받침한다.
명령어: /verify
검증은 네 단계 순서로 진행된다. 1) 기존 테스트 실행, 2) 타입체크·빌드, 3) 특정 기능의 직접 명령 확인, 4) 자동화 불가능한 항목의 수동 검증 목록화.
[VERIFIED] pytest 전체 통과 (42/42)
[VERIFIED] mypy 타입체크 통과
[VERIFIED] POST /api/users 201 응답 확인
[UNVERIFIED] UI 렌더링 (브라우저 확인 필요)
ai-slop-cleaner — AI 생성 코드 정제
AI가 생성한 코드의 **슬롭(slop)**을 제거한다. 동작은 바꾸지 않고 품질만 개선한다.
명령어: /ai-slop-cleaner 또는 키워드 deslop, anti-slop
| 카테고리 | 설명 | 예시 |
|---|---|---|
| Duplication | 중복 코드 | 같은 로직 복사-붙여넣기 |
| Dead code | 미사용 코드 | 호출되지 않는 함수 |
| Needless abstraction | 불필요한 추상화 | 1회만 사용되는 유틸리티 클래스 |
| Boundary violations | 경계 위반 | 계층 간 부적절한 의존성 |
| Missing tests | 누락 테스트 | 구현은 있지만 테스트 없음 |
회귀를 막기 위해 실행 순서가 정해져 있다.
1. Dead code 제거 → 테스트 통과 확인
2. Duplication 제거 → 테스트 통과 확인
3. Naming 개선 → 테스트 통과 확인
4. Test 보강 → 전체 통과 확인
Ralph 실행이 끝나면 자동으로 Deslop Pass가 돌고, 이어서 회귀 재검증까지 수행된다.
superpowers:verification-before-completion은 작업 완료를 선언하기 전, 커밋 전, PR 생성 전에 반드시 검증 명령을 실행하고 출력을 확인하도록 자동 트리거된다.
고급 확장 스킬
ccg는 Claude, Codex, Gemini 3개 모델의 응답을 병렬로 수집한 뒤 Claude가 최적 답변을 합성한다.
┌──→ Codex ──→ 응답 A ──┐
User Prompt ──────┤ ├──→ Claude 합성 → 최종 답변
└──→ Gemini ──→ 응답 B ──┘
다양한 관점이 필요한 설계 결정, 코드 리뷰, 복잡한 문제 해결에 적합하다.
# 아키텍처 설계에 다중 모델 관점
/ccg 이벤트 소싱 vs CQRS 중 이 프로젝트에 적합한 패턴은?
# 다중 모델 코드 리뷰
/ccg 이 인증 모듈의 보안 취약점을 분석해줘sciomc는 복잡한 연구 목표를 3~7개 독립 단계로 분해하고 병렬 과학자 에이전트로 분석한다.
# 기술 리서치
/sciomc WebSocket vs SSE vs gRPC 실시간 통신 프로토콜 비교 분석
# AUTO 모드 (완전 자율, 최대 10회 반복)
/sciomc --auto "최신 인증 프로토콜 동향 조사 및 권장사항 도출"self-improve는 코드베이스를 자율적으로 반복 개선하는 진화 엔진으로, Tournament Selection으로 최적 개선안을 고른다. Plateau 감지·Circuit Breaker·Git Worktree 격리 같은 안전장치가 있고 세션 간 재개도 가능하다.
Research → Plan (N개 병렬) → Review (Architect+Critic)
↑ → Execute (병렬) → Tournament Selection │
│ → Record & Visualize │
└──────────────── 정지 조건 미달 시 반복 ────────────────┘
deepinit은 코드베이스 전체에 계층적 AGENTS.md 문서를 자동 생성한다. 각 AGENTS.md는 부모 참조를 포함해 탐색 가능한 계층 구조를 이룬다.
# 전체 코드베이스 문서화
/deepinit
# 결과 예시:
# ./AGENTS.md (루트)
# ./src/AGENTS.md
# ./src/auth/AGENTS.md
# ./src/api/AGENTS.md
# ./tests/AGENTS.mdexternal-context는 쿼리를 2~5개 검색 패싯으로 분해하고 병렬 document-specialist 에이전트로 외부 문서를 수집한다.
# SDK 문서 수집
/external-context FastAPI 0.115 마이그레이션 가이드 및 Pydantic v2 호환성octo:factory는 Spec-in, Software-out 완전 자율 파이프라인이다(/octo:factory). octo:embrace는 Research → Define → Develop → Deliver의 4단계 Double Diamond 워크플로우 전체를 수행한다.
# 전체 4단계 워크플로우
/octo:embrace 고객 피드백 관리 시스템 구축
# 개별 단계 실행도 가능
/octo:discover 시장 조사
/octo:define 문제 정의
/octo:develop 솔루션 구현
/octo:deliver 검증 및 배포실전 워크플로우 레시피
프로젝트 규모와 품질 요구 수준별로 조합을 미리 정해두면 매번 고민할 필요가 없다.
소규모 프로젝트(CLI 도구, 단일 API) — 한 줄로 끝난다.
/autopilot Python CLI 도구 만들어줘. JSON/YAML 변환기. click 프레임워크, 파이프 지원.중규모 프로젝트(웹 API + DB) — 계획부터 세우고 자율 실행으로 넘긴다.
/ralplan FastAPI 블로그 API. 게시글 CRUD, 댓글, 태그, JWT 인증, SQLAlchemy+SQLite, pytest.
# → 계획 승인 후 자동 실행대규모 프로젝트(마이크로서비스) — 인터뷰부터 시작해 팀 기반 병렬 구현까지 간다.
/deep-interview 이커머스 플랫폼을 구축하고 싶어
# → 질문 응답 → 명세서 생성
# → ralplan 자동 연결 → 계획 승인
# → team 기반 병렬 구현 자동 실행미션 크리티컬 — PRD 작성부터 다중 모델 리뷰까지 겹겹이 쌓는다.
/octo:prd 금융 거래 처리 시스템
# → PRD 검토
/ralplan --deliberate # Pre-mortem + 확장 테스트 계획
# → 계획 승인
# → autopilot 실행 (Phase 4에서 3자 검증)
/ccg 최종 보안 리뷰 # 3개 모델로 추가 리뷰기존 코드 개선 — 자율 진화나 슬롭 제거 중 하나를 고른다.
/self-improve
# 또는
/ai-slop-cleaner연구 후 구현 — 기술 리서치 결과를 그대로 구현에 넘긴다.
/sciomc WebSocket 라이브러리 비교 (ws, socket.io, uWebSockets)
# → 리서치 결과 확인
/autopilot 리서치 결과 기반으로 실시간 채팅 서버 구현프롬프트를 어떻게 써야 하는가
자율 실행 프롬프트는 기술 스택·기능 목록·기술 요구사항·테스트 범위·구조를 명시할수록 결과가 좋아진다.
/autopilot [기술 스택]으로 [무엇을] 구현해줘.
- 기능 목록: [구체적 엔드포인트/기능 나열]
- 기술 요구사항: [DB, 인증, 캐싱 등]
- 테스트: [테스트 프레임워크 및 범위]
- 구조: [프로젝트 구조 가이드]
모호한 프롬프트와 구체적인 프롬프트의 차이는 결과물의 차이로 그대로 이어진다.
| 나쁜 프롬프트 | 좋은 프롬프트 |
|---|---|
앱 만들어줘 |
FastAPI로 TODO 앱 REST API 만들어줘. CRUD + JWT + pytest |
성능 개선해줘 |
GET /api/users의 응답 시간을 500ms에서 100ms로 줄여줘. N+1 쿼리 의심 |
테스트 추가해줘 |
src/auth/ 모듈에 pytest 단위 테스트 추가. 경계값과 에러 케이스 포함 |
리팩토링해줘 |
src/services/의 동기 DB 호출을 async/await로 변환. 기존 테스트 통과 유지 |
프롬프트가 충분히 구체적이면 ralplan 게이팅을 자동으로 통과한다.
# 자동 통과 (구체적)
/ralph src/auth.py:42의 NullPointerException 수정. User.email이 None일 때 발생.
# 게이팅됨 (모호함) → ralplan으로 리디렉션
/ralph 인증 시스템 개선해줘
# 강제 통과 (게이팅 우회)
/ralph force: 인증 시스템 개선해줘어떤 조합을 선택할까
목적별로 추천 조합과 필요한 인간 개입 횟수를 정리하면 다음과 같다.
| 목적 | 추천 조합 | 인간 개입 |
|---|---|---|
| 빠른 프로토타입 | /autopilot |
0회 |
| 안정적 구현 | /ralplan → 자동 실행 |
1회 (계획 승인) |
| 최고 품질 | /deep-interview → /ralplan → 자동 실행 |
2회 (인터뷰 + 계획) |
| 대규모 병렬 | /ralplan → /team N:executor |
1회 |
| 미션 크리티컬 | /octo:prd → /ralplan --deliberate → 자동 실행 → /ccg 리뷰 |
3회 |
| 코드 개선 | /self-improve 또는 /ai-slop-cleaner |
0회 |
| 연구 기반 구현 | /sciomc → /autopilot |
0~1회 |
판단 기준을 세 갈래로 나누면 다음과 같이 정리된다.
프로젝트 크기?
├── 소규모 (1~3 파일) ──→ /autopilot
├── 중규모 (4~15 파일) ──→ /ralplan → /ralph
├── 대규모 (15+ 파일) ──→ /ralplan → /team
└── 초대규모 ──→ /deep-interview → /ralplan → /team
요구사항 명확도?
├── 명확함 ──→ 바로 실행 스킬
├── 대략적 ──→ /ralplan 거쳐서 실행
└── 모호함 ──→ /deep-interview부터 시작
품질 요구 수준?
├── 프로토타입 ──→ /autopilot 또는 /ultrawork
├── 프로덕션 ──→ /ralph (Deslop + 검증 포함)
└── 미션 크리티컬 ──→ /ralph + /ccg 리뷰 + /ultraqa
설정 파일과 환경 변수
| 파일 | 용도 |
|---|---|
.claude/settings.json |
autopilot 반복 횟수, QA 사이클 등 |
.claude/omc.jsonc |
에이전트별 모델/프로바이더 라우팅 |
CLAUDE.md |
프로젝트별 지침 (코딩 스타일, 제약사항) |
AGENTS.md |
디렉토리별 에이전트 지침 |
OMC_TEAM_SCALING_ENABLED=1 # 동적 팀 스케일링 활성화
DISABLE_OMC=1 # OMC 전체 비활성화
OMC_SKIP_HOOKS=hook1,hook2 # 특정 훅 건너뛰기막혔을 때
실행을 멈추고 싶으면 /oh-my-claudecode:cancel을 쓰거나, .omc/state/에 저장된 상태 파일을 확인한다.
# 현재 실행 모드 취소
/oh-my-claudecode:cancel
# 상태 확인
# OMC 상태 파일은 .omc/state/에 저장됨Ralph가 같은 오류로 무한 루프를 돈다면 걱정할 필요는 적다 — 동일 오류가 3회 반복되면 자동으로 중단된다. 그래도 멈추지 않으면 /oh-my-claudecode:cancel로 수동 취소하고, 프롬프트를 더 구체적으로 바꿔 재실행한다.
Autopilot Phase 4 검증에서 Architect, Security-reviewer, Code-reviewer 중 하나라도 거부하면 수정 후 재검증에 들어가며, 최대 maxValidationRounds(기본 3)회까지 반복한다.
팀 에이전트끼리 같은 파일을 건드려 충돌이 나면, 애초에 겹치지 않게 작업을 분배하고 Git Worktree 격리를 활용하는 게 우선이다. .omc/handoffs/의 핸드오프 문서로 컨텍스트를 공유하는 것도 도움이 된다.
환경 전체가 의심스러우면 진단 명령을 돌린다.
# 환경 전체 진단
/oh-my-claudecode:omc-doctor요약
| 한 줄 실행 | 명령어 |
|---|---|
| 바로 만들어줘 | /autopilot <구체적 프롬프트> |
| 계획 세우고 만들어줘 | /ralplan <요구사항> |
| 여러 모듈 동시에 | /team N:executor <작업들> |
| 테스트 통과할 때까지 | /ralph <구현 요청> |
| 아이디어부터 시작 | /deep-interview <아이디어> |
| 코드 품질 개선 | /ai-slop-cleaner |
| 전체 진화 개선 | /self-improve |