Oh My Claude - Ralplan 핵심 정리
- Ralplan은 Planner, Architect, Critic, Analyst 4개 에이전트가 협력하는 계획 수립 시스템입니다
- 최대 5번의 반복 루프를 통해 계획의 완성도를 높입니다
- 각 에이전트는 명확한 역할 분리로 자신의 전문 분야에만 집중합니다
- Critic의 평가를 통해 계획의 품질을 객관적으로 검증합니다
서론
지난번에 소개한 Oh My Claude에서 가장 유용하게 쓰는 기능이 있습니다. 바로 Ralplan입니다. 이 기능은 Ralph Loop의 반복 실행 개념을 계획 수립에 적용한 유틸 커맨드입니다. 단순히 "계획 짜줘"가 아니라, Planner-Architect-Critic 세 에이전트가 최대 5번의 루프를 돌면서 계획을 다듬는 방식이죠. 여기에 Analyst까지 더해 총 네 개의 에이전트가 협력합니다.
Ralplan이란
핵심 개념
Planner, Architect, Critic 세 에이전트가 협력해서 작업 계획을 완성합니다.
| 에이전트 | 역할 | 코드네임 |
|---|---|---|
| Planner | 계획 수립 | Prometheus |
| Architect | 아키텍처 자문 | Oracle |
| Critic | 무자비한 리뷰 | - |
| Analyst | 요구사항 갭 분석 | Metis |
재밌는 건 에이전트에 붙은 코드네임입니다. Prometheus는 인류에게 불을 가져다준 선견지명의 티탄, Oracle은 델포이 신전의 예언 기관, Metis는 제우스보다 지혜로웠던 티탄 여신이죠. 네이밍 센스가 보이더군요.
동작 흐름
Planner (계획 작성)
├── Analyst(Metis) 필수 상담
↓
질문 있음? → Architect (자문)
↓
Critic (리뷰)
↓
REJECT → Planner로 피드백 (반복)
OKAY → 계획 완료Planner는 계획 수립 시 Analyst(Metis)와 필수로 상담합니다. 갭 분석을 먼저 받는 거죠. 최대 5번 반복하며, 중간에 Critic이 OKAY를 주면 바로 종료됩니다.
에이전트별 역할 분석
Planner (Prometheus) - 계획만 세우는 전략가
Planner의 정체성은 명확합니다.
YOU ARE A PLANNER. YOU ARE NOT AN IMPLEMENTER. YOU DO NOT WRITE CODE.
사용자가 "로그인 버그 고쳐줘"라고 하면, 코드를 고치는 게 아니라 "로그인 버그를 고치는 계획"을 세웁니다. 코드 작성, 파일 수정은 금지된 행동이죠.
핵심 기능
| 단계 | 설명 |
|---|---|
| Phase 1: Interview | 요구사항 파악을 위한 인터뷰 |
| Phase 2: Plan Generation | 계획 문서 생성 |
| Phase 3: Confirmation | 사용자 확인 후 Critic에게 넘김 |
알아두면 좋은 것
질문 분류 체계가 있습니다. 질문을 던지기 전에 먼저 분류하죠.
| 유형 | 예시 | 행동 |
|---|---|---|
| Codebase Fact | "어떤 패턴 쓰고 있어?" | 직접 코드베이스 탐색 |
| User Preference | "우선순위는?", "일정은?" | 사용자에게 질문 |
| Scope Decision | "Y 기능도 포함할까?" | 사용자에게 질문 |
코드베이스에서 알 수 있는 건 물어보지 않고 직접 찾습니다. 그리고 한 번에 하나의 질문만 던지는 규칙이 있습니다.
계획 문서 구조도 정해져 있습니다: Context → Work Objectives → Guardrails (Must Have / Must NOT Have) → Tasks → Risks → Verification
Architect (Oracle) - 읽기만 하는 자문가
Architect도 마찬가지로 코드를 수정하지 않습니다.
IDENTITY: Consulting architect. You analyze, advise, recommend. You do NOT implement.
핵심 기능
| 단계 | 설명 |
|---|---|
| Phase 1: Context Gathering | 관련 파일, 의존성, 테스트 커버리지 파악 |
| Phase 2: Deep Analysis | 아키텍처, 디버깅, 성능, 보안 분석 |
| Phase 3: Recommendation | 요약 → 진단 → 근본 원인 → 추천 → 트레이드오프 → 참조 |
알아두면 좋은 것
디버깅 프로토콜이 체계적입니다. 먼저 Quick Assessment로 명백한 버그(오타, import 누락)인지 확인하고, 아니면 Full Protocol로 들어갑니다.
3-Failure Circuit Breaker 규칙이 흥미롭습니다. 같은 수정을 3번 시도하도 안 되면:
STOP recommending fixes → Question the architecture → "Is the approach fundamentally wrong?"
증상만 고치려다 본질을 놓치는 함정을 막아주는 규칙이죠.
| 증상 | 잘못된 수정 | 물어야 할 질문 |
|---|---|---|
| TypeError: undefined | null check 추가 | 왜 undefined인가? |
| 테스트 flaky | 재실행 | 어떤 상태가 공유되고 있나? |
| 로컬에서만 됨 | "CI 문제야" | 환경 차이가 뭔가? |
출력 포맷도 정해져 있습니다: Summary → Analysis → Root Cause → Recommendations (우선순위/노력/임팩트) → Trade-offs → References (file:line)
Critic - 평균 7번 거절하는 리뷰어
Critic 룰에 이런 문장이 있습니다.
Historical Data: Plans from authors average 7 rejections before receiving OKAY.
평균 7번 거절한다는 통계가 실제로 적혀 있더군요. "무자비한 비평가(ruthless critic)"라는 표현이 괜히 있는 게 아닙니다.
핵심 기능: 4가지 평가 기준
| 기준 | 검증 내용 |
|---|---|
| Clarity | 각 태스크가 추측 없이 실행 가능한가? |
| Verification | 모든 태스크에 객관적 성공 기준이 있는가? |
| Context Completeness | 뭘 해야 하는지 90% 이상 확신할 수 있는가? |
| Big Picture | 왜, 무엇을, 어떻게가 연결되어 이해되는가? |
알아두면 좋은 것
리뷰 프로세스가 5단계입니다:
- Read: 계획 파싱, 파일 참조 추출
- Deep Verification: 모든 파일 참조가 실제로 유효한지 검증
- Apply Criteria: 4가지 기준 체크
- Implementation Simulation: 2~3개 태스크를 머릿속으로 실행해봄
- Write Report: 평가 리포트 작성
4번이 핵심입니다. 실제로 이 계획대로 일하면 어디서 막히는지 시뮬레이션합니다.
Auto-REJECT 조건 (하나라도 해당되면 자동 거절):
- 측정 기준 없는 모호한 표현 ("성능 개선")
- 코드 변경에 파일 참조 없음
- 태스크에 수락 기준 없음
- 태스크 간 순환 의존성
- 에러 핸들링 고려 없음
- 검증 단계 없음
Analyst (Metis) - 계획 전 갭 분석
Analyst는 계획 수립 전에 투입되는 사전 컨설턴트입니다. "물어봤어야 하는데 안 물어본 질문"을 찾아내고, 범위 확장 위험을 잡아냅니다.
핵심 기능: 6가지 분석 영역
| 영역 | 찾아내는 것 |
|---|---|
| Missing Questions | 물어봤어야 하는데 안 물어본 질문 |
| Undefined Guardrails | 명시적 경계가 필요한 부분 |
| Scope Risks | 범위 확장 위험 지점 |
| Unvalidated Assumptions | 검증 없이 가정하고 있는 것 |
| Missing Acceptance Criteria | 빠진 성공 기준 |
| Edge Cases | 다루지 않은 예외 상황 |
알아두면좋은 것
질문 카테고리가 세 가지로 나뉩니다:
- Functional: X가 일어나면 정확히 어떻게 되어야 하나?
- Technical: 어떤 패턴을 따라야 하나? 에러 핸들링 전략은?
- Scope: 이 작업에 포함되지 않는 건 뭔가? 최소 버전은?
워크플로우 상 위치:
User Request
↓
Analyst (Metis) ← "빠진 요구사항이 뭐지?"
↓
Planner (Prometheus) ← "계획 수립"
↓
Critic ← "이 계획 완전한가?"Analyst 분석이 끝나면 @planner에게 핸드오프합니다.
왜 이 방식이 효과적인가
역할 분리의 힘
각 에이전트는 자기 역할만 수행합니다.
| 에이전트 | 할 수 있는 것 | 금지된 것 |
|---|---|---|
| Planner | 질문, 계획 작성 | 코드 작성 |
| Architect | 파일 읽기, 분석, 추천 | 파일 수정 |
| Critic | 계획 리뷰, 거절/승인 | 계획 작성 |
이렇게 역할을 분리하면 각 단계가 자기 일에만 집중하게 됩니다. Planner가 코드까지 건드리려고 하면 계획의 질이 떨어지죠.
반복의 가치
5번까지 반복할 수 있다는 건 단순히 "다시 해봐"가 아닙니다. Critic의 구체적인 피드백이 Planner에게 전달되고, 필요하면 Architect의 자문을 받아서 계획을 다듬는 구조입니다.
기존에 플랜 한 번 돌리면 "이 정도면 됐나?" 하고 넘어갔다면, Ralplan은 Critic이 OKAY를 줄 때까지 자동으로 다듬어줍니다.
상태 관리
.omc/ralplan-state.json에 진행 상태가 저장됩니다. 세션이 끊겨도 어디까지 진행됐는지 알 수 있죠.
{
"iteration": 1,
"max_iterations": 5,
"current_phase": "critic_review"
}실제 사용 소감
Ralplan으로 짜여진 계획은 기존 방식보다 씬 간결합니다. 그리고 "왜 이 방식을 선택했는지"까지 담겨 있어서 리뷰하기 좋습니다.
기존에는 계획을 받고 나서 "이거 맞나?", "빠진 거 없나?" 고민하는 시간이 꽤 들었는데, Critic이 이미 그 고민을 대신 해준 셈이죠. 사용자는 최종 리뷰에만 시간을 쓰면 됩니다.
너무 만족스러워서 이 커맨드와 룰들을 추출해서 Cursor에서도 사용 중입니다.
마치며
얼마 전까지는 LLM 사용 시 프롬프트를 누가 더 잘 쓰느냐가 중요했다면, 이제는 거기에 더해 에이전트/룰/자동화를 얼마나 잘 설계해놨느냐가 중요한 것 같습니다.
Ralplan처럼 역할을 분리하고, 반복을 통해 품질을 높이는 패턴은 다른 곳에도 응용할 수 있을 것 같습니다.
요즘은 새로운 게 계속 나오고, 써보면서 새로운 지식이 늘어나는 느낌이라 재밌네요.
Refs
- Oh My Claude GitHub Repository
- Ralplan Skill Definition (
ralplan.md) - Agent Rules: planner.mdc, architect.mdc, critic.mdc, analyst.mdc
