워크플로우
이 가이드는 Rasen의 일반적인 워크플로우 패턴과 각 패턴을 언제 사용하는지에 대해 다룹니다. 기본 설정은 Getting Started를 참고하세요. 명령 참조는 Commands를 참고하세요.
철학: 단계가 아닌 동작
전통적인 워크플로우는 단계별로 강제합니다: 계획, 그 다음 구현, 그 다음 완료. 하지만 실제 작업은 깔끔하게 상자에 맞지 않습니다.
OPSX는 다른 접근 방식을 취합니다:
Traditional (phase-locked):
PLANNING ────────► IMPLEMENTING ────────► DONE
│ │
│ "Can't go back" │
└────────────────────┘
OPSX (fluid actions):
proposal ──► specs ──► design ──► tasks ──► implement
핵심 원칙:
- 단계가 아닌 동작 - 명령은 수행할 수 있는 것이지, 갇혀 있는 단계가 아닙니다
- 의존성은 활성화기 - 그들은 가능한 것을 보여주고, 다음에 필요한 것이 무엇인지를 나타내지 않습니다
사용자 정의: OPSX 워크플로우는 산출물 시퀀스를 정의하는 스키마로 작동합니다. 사용자 정의 스키마 생성에 대한 세부 사항은 Customization을 참고하세요.
두 가지 모드
빠른 경로 (core 프로파일)
새 설치는 기본적으로 full 프로파일(모든 워크플로우)로 설정됩니다. core는 일상 리듬을 위해 축소한 프로파일입니다:
/rasen:explore/rasen:propose/rasen:apply/rasen:sync/rasen:archive
일반적인 흐름:
/rasen:explore ──► /rasen:propose ──► /rasen:apply ──► /rasen:sync ──► /rasen:archive
(optional)
탐색으로 시작합니다(형성할 가치 있는 습관)
/rasen:explore는 기본 프로파일의 일부이지 고급 추가 기능이 아닙니다. 문제가 있지만 아직 계획이 없을 때마다 취할 동작입니다. AI 어시스턴트를 사용하면 대부분의 경우입니다.
You: /rasen:explore
AI: What would you like to explore?
You: Our search results feel stale. I'm not sure if it's caching,
indexing, or the query itself.
AI: Let me look... [reads the search service and cache layer]
It's the index: it only rebuilds nightly, so edits don't show
up until the next day. Two options: rebuild on write (simple,
more load) or a short-TTL cache invalidation (more moving parts,
less load). Given your write volume is low, rebuild-on-write is
the cleaner fix. Want to scope it?
You: Yes.
You: /rasen:propose rebuild-search-index-on-write
탐색은 산출물을 생성하지 않으며 코드를 작성하지 않습니다. 모호한 걱정을 정확한 변경으로 변환하는 무료이고 위험이 없는 대화이므로 따라오는 제안이 선명합니다. 이미 정확히 원하는 것을 알고 있습니까? 건너뜁니다 그리고 /rasen:propose로 직접 이동합니다. 전체 가이드: Explore First.
확장/전체 워크플로우(사용자 정의 선택)
명시적 스캐폴드 및 빌드 명령(/rasen:new, /rasen:continue, /rasen:ff, /rasen:verify, /rasen:bulk-archive, /rasen:onboard)은 새 설치가 기본적으로 full 프로파일로 설정되므로 이미 기본적으로 설치됩니다. core 집합만 선호하는 경우 다음을 사용하여 전환합니다:
rasen config profile core
rasen update
워크플로우 패턴(확장 모드)
빠른 기능
빌드할 내용을 알고 있고 단순히 실행하기만 하면 됩니다:
/rasen:new ──► /rasen:ff ──► /rasen:apply ──► /rasen:verify ──► /rasen:archive
예제 대화:
You: /rasen:new add-logout-button
AI: Created rasen/changes/add-logout-button/
Ready to create: proposal
You: /rasen:ff
AI: Creating all planning artifacts...
✓ proposal.md
✓ specs/
✓ design.md
✓ tasks.md
Ready for implementation!
You: /rasen:apply
AI: Working through tasks...
✓ Added logout button to header
✓ Implemented session clearing
✓ Added confirmation dialog
All tasks complete!
You: /rasen:archive
AI: ✓ Merged specs
✓ Archived change
최고 대상: 작은 에서 중간 크기 기능, 버그 수정, 직선적인 변경.
탐색
요구사항이 명확하지 않거나 먼저 조사해야 할 때:
/rasen:explore ──► /rasen:new ──► /rasen:continue ──► ... ──► /rasen:apply
예제 대화:
You: /rasen:explore
AI: What would you like to explore?
You: I want to improve page load performance but I'm not sure
where the bottlenecks are.
AI: Let me help investigate...
[Analyzes bundle sizes, identifies slow queries, reviews
component render patterns]
I found three main bottlenecks:
1. Large unoptimized images
2. Synchronous data fetching in ProductList
3. Re-renders from context changes
Which would you like to address first?
You: Let's tackle the data fetching issue.
You: /rasen:new optimize-product-list-fetching
AI: Created change. Ready to create: proposal
You: /rasen:continue
AI: Creating proposal based on our exploration...
[Writes proposal incorporating investigation insights]
Ready to create: specs, design
Which would you like next?
You: /rasen:continue
AI: Creating specs...
최고 대상: 성능 최적화, 디버깅, 아키텍처 결정, 명확하지 않은 요구사항.
병렬 변경
동시에 여러 변경에 대해 작업합니다:
Change A: /rasen:new ──► /rasen:ff ──► /rasen:apply (in progress)
│
context switch
│
Change B: /rasen:new ──► /rasen:ff ──────► /rasen:apply
예제 대화:
You: I'm working on add-dark-mode but got pulled into a bug fix
You: /rasen:new fix-login-redirect
AI: Created rasen/changes/fix-login-redirect/
You: /rasen:ff
AI: ✓ Created planning artifacts
You: /rasen:apply
AI: Working on fix-login-redirect...
[Implements the fix]
All tasks complete!
You: /rasen:archive
AI: ✓ Archived fix-login-redirect
You: Let's get back to dark mode
You: /rasen:apply add-dark-mode
AI: Resuming add-dark-mode...
Picking up at task 2.3: Update Header...
최고 대상: 병렬 작업 흐름, 긴급 중단, 팀 협업.
여러 완료된 변경이 있는 경우 /rasen:bulk-archive를 사용합니다:
You: /rasen:bulk-archive
AI: Found 3 completed changes:
- add-dark-mode (all tasks done)
- fix-login-redirect (all tasks done)
- update-footer (all tasks done)
Checking for spec conflicts...
⚠ add-dark-mode and update-footer both touch specs/ui/
Inspecting codebase to resolve...
Both changes are implemented. Will apply in chronological order.
Archive all 3 changes?
You: Yes
AI: ✓ Archived add-dark-mode
✓ Archived fix-login-redirect
✓ Archived update-footer
Specs merged in order: add-dark-mode → update-footer
벌크 보관은 여러 변경이 동일한 스펙을 터치하고 실제로 구현된 것을 확인하여 충돌을 해결하는 경우를 감지합니다.
변경 완료
권장 완료 흐름:
/rasen:apply ──► /rasen:verify ──► /rasen:archive
│ │
validates prompts to sync
implementation if needed
검증: 작업 확인
/rasen:verify는 세 가지 차원에서 산출물에 대한 구현을 검증합니다:
You: /rasen:verify
AI: Verifying add-auth...
COMPLETENESS
✓ All 12 tasks in tasks.md are checked
✓ All requirements in specs have corresponding code
⚠ Scenario "Session timeout after inactivity" not tested
CORRECTNESS
✓ Implementation matches spec intent
✓ Edge cases from scenarios are handled
✓ Error states match spec definitions
COHERENCE
✓ Design decisions reflected in code structure
✓ Naming conventions consistent with design.md
⚠ Design mentions "event-driven" but implementation uses polling
SUMMARY
─────────────────────────────
Critical issues: 0
Warnings: 2
Ready to archive: Yes (with warnings)
Recommendations:
1. Add test for session timeout scenario
2. Consider refactoring to event-driven as designed, or update design.md
검증이 확인하는 사항:
| 차원 | 검증하는 항목 |
|---|---|
| 완성도 | 모든 작업 완료, 모든 요구사항 구현, 시나리오 적용 |
| 정확성 | 구현이 스펙 의도와 일치, 엣지 케이스 처리 |
| 일관성 | 설계 결정이 코드에 반영, 패턴 일관성 |
검증은 보관을 차단하지 않지만 먼저 처리하고 싶을 수 있는 문제를 표시합니다.
리뷰 사이클: 깨끗할 때까지 루프(옵트인)
/rasen:verify는 단일 통과입니다. /rasen:review-cycle은 검토자를 래핑하고 변경이 실제로 깨끗해질 때까지 계속하는 루프입니다:
review ──► triage ──► fix ──► re-review(Δ) ──► { pass | loop | escalate }
각 리뷰 통과는 항상 설치된 rasen-review 엔진에 위임됩니다 — 루프는 리뷰 휴리스틱을 재구현하지 않습니다. 맨 위에 네 가지를 추가합니다:
- 수정 크기 분류. 각 발견은 수정 크기로 라우팅됩니다: trivial → 오케스트레이터 인라인; non-trivial → 코드를 작성한 구현 에이전트; design-level → 별도의 수정 에이전트(원래 저자 아님).
- 저자 ≠ 검증자. 발견은 수정을 작성하지 않은 검토자가 원래 발견에 대해 확인할 때만 해결됩니다. 사소한 인라인 수정의 경우 독립적인 게이트 실행(테스트/린트/빌드) 및 정확한 변경의 diff 읽기가 동등한 저자 아닌 확인입니다 — 그리고 사이클 보고서에 기록되어야 합니다.
- 델타만 재검토합니다. Claude Code with agent-teams(
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1)에서 리드는SendMessage를 통해 원래 검토자를 재개하여 델타만 재검토할 수 있습니다(리드만SendMessage를 시작할 수 있음). 그렇지 않으면 신규 델타 리뷰로 폴백하여 사전 발견 및 수정 diff를 공유 파일을 통해 전달합니다 — 동등한 결과, 비용만 많습니다. - 경계 종료. 루프는 최대 라운드(기본값 3)로 제한됩니다. 상한에서 미해결 Blocker/Major 발견이 있는 경우 미해결 발견 및 라운드 기록과 함께 인간에게 상위 단계로 올립니다 — 절대 자동으로 깨끗한 통과를 보고합니다.
라이브 diff에 대해 구현 후에 사용합니다. 선택 사항입니다: 사용자 정의 프로파일을 통해 활성화합니다(이것은 core에 없음). 라운드 기록과 각 저자 아닌 확인은 변경 디렉토리의 review-cycle-report.md에 기록됩니다.
보관: 변경 최종화
/rasen:archive는 변경을 완료하고 보관으로 이동합니다:
You: /rasen:archive
AI: Archiving add-auth...
Artifact status:
✓ proposal.md exists
✓ specs/ exists
✓ design.md exists
✓ tasks.md exists (12/12 tasks complete)
Delta specs: Not yet synced to main
→ Would you like to sync now?
You: Yes
AI: ✓ Synced specs to rasen/specs/auth/spec.md
✓ Moved to rasen/changes/archive/2025-01-24-add-auth/
Change archived successfully.
스펙이 동기화되지 않은 경우 보관이 메시지를 표시합니다. 완료되지 않은 작업에서 차단하지 않지만 경고합니다.
무엇을 언제 사용하는지
/rasen:ff vs /rasen:continue
| 상황 | 사용 |
|---|---|
| 명확한 요구사항, 빌드 준비 완료 | /rasen:ff |
| 탐색, 각 단계를 검토하고 싶음 | /rasen:continue |
| 스펙 전에 제안서를 반복하고 싶음 | /rasen:continue |
| 시간 압박, 빠르게 이동해야 함 | /rasen:ff |
| 복잡한 변경, 제어를 원함 | /rasen:continue |
경험칙: 전체 범위를 미리 설명할 수 있으면 /rasen:ff를 사용합니다. 진행하면서 알아내면 /rasen:continue를 사용합니다.
업데이트 vs 새로 시작할 때
일반적인 질문: 기존 변경을 업데이트하는 것이 좋을 때와 새로 시작해야 할 때는 언제입니까?
기존 변경을 업데이트할 때:
- 같은 의도, 정제된 실행
- 범위 축소(먼저 MVP, 나머지는 나중에)
- 학습 기반 수정(코드베이스가 예상과 다름)
- 구현 발견에 따른 설계 조정
새 변경을 시작할 때:
- 의도가 근본적으로 변경됨
- 범위가 완전히 다른 작업으로 폭증
- 원래 변경을 별도로 "완료"로 표시할 수 있음
- 패치가 명확히 하는 것보다 혼란스러울 것
┌─────────────────────────────────────┐
│ Is this the same work? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Same intent? >50% overlap? Can original
Same problem? Same scope? be "done" without
│ │ these changes?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
UPDATE NEW UPDATE NEW UPDATE NEW
예제: "어두운 모드 추가"
- "사용자 정의 테마도 지원해야 함" → 새 변경(범위 폭증)
- "시스템 환경 설정 감지가 예상보다 어려움" → 업데이트(같은 의도)
- "먼저 토글을 배포하고 나중에 환경 설정 추가" → 업데이트 그 다음 보관, 그 다음 새 변경
모범 사례
변경을 집중하게 유지합니다
변경당 하나의 논리적 작업 단위. "기능 X를 추가하고 Y를 리팩토링"을 하면 두 개의 별도 변경을 고려합니다.
중요한 이유:
- 검토 및 이해가 더 쉬움
- 보관 기록이 더 깔끔함
- 독립적으로 배포할 수 있음
- 필요한 경우 더 간단한 롤백
명확하지 않은 요구사항에 /rasen:explore 사용합니다
변경을 확정하기 전에 문제 공간을 탐색합니다:
You: /rasen:explore
AI: What would you like to explore?
You: How should we handle rate limiting for our API?
AI: Let me investigate your current setup and options...
[Researches codebase, considers patterns]
I see three approaches we could take:
1. Middleware-based (simple, per-endpoint)
2. Redis-backed (scalable, shared state)
3. Token bucket per user (fair, complex)
Your current stack suggests #1 or #2. What's your scale?
탐색은 산출물을 생성하기 전에 생각을 명확히 합니다.
보관하기 전에 검증합니다
/rasen:verify를 사용하여 구현이 산출물과 일치하는지 확인합니다:
You: /rasen:verify
AI: Verifying add-dark-mode...
✓ All tasks in tasks.md are checked
✓ Requirements in specs have corresponding code
✓ Design decisions are reflected in implementation
Ready to archive!
변경을 마감하기 전에 불일치를 포착합니다.
변경의 이름을 명확히 지정합니다
좋은 이름은 rasen list를 유용하게 만듭니다:
Good: Avoid:
add-dark-mode feature-1
fix-login-redirect update
optimize-product-query changes
implement-2fa wip
명령 빠른 참조
전체 명령 세부 사항 및 옵션은 Commands를 참고하세요.
| 명령 | 용도 | 사용 시기 |
|---|---|---|
/rasen:propose |
변경 + 계획 산출물 생성 | 빠른 기본 경로(core 프로파일) |
/rasen:explore |
AI와 함께 아이디어를 생각해봅니다 | 명확하지 않을 때 여기서 시작: 명확하지 않은 요구사항, 조사, 옵션 비교 |
/rasen:new |
변경 스캐폴드 시작 | 확장 모드, 명시적 산출물 제어 |
/rasen:continue |
다음 산출물 생성 | 확장 모드, 단계별 산출물 생성 |
/rasen:ff |
모든 계획 산출물 생성 | 확장 모드, 명확한 범위 |
/rasen:apply |
작업 구현 | 코드를 작성할 준비 완료 |
/rasen:verify |
구현 검증 | 확장 모드, 보관 전 |
/rasen:sync |
델타 스펙 병합 | 확장 모드, 선택 사항 |
/rasen:archive |
변경 완료 | 모든 작업 완료 |
/rasen:bulk-archive |
여러 변경 보관 | 확장 모드, 병렬 작업 |
다음 단계
- Writing Good Specs - 강한 요구사항과 시나리오가 어떤 모습인지, 그리고 변경을 올바르게 크기 조정하는 방법
- Reviewing a Change - 코드 전에 작성된 계획의 2분 통과
- Rasen on a Team - 변경이 브랜치 및 풀 리퀘스트에 어떻게 맞는지
- Commands - 옵션이 있는 전체 명령 참조
- Concepts - 스펙, 산출물, 스키마에 깊이 빠져들기
- Customization - 사용자 정의 워크플로우 생성