사용 사례와 가이드
지금 작업에 맞는 OMX 워크플로우를 고르는 방법
사용 사례 살펴보기
해야 할 일의 종류는 대략 알지만 어떤 OMX 워크플로우에 맡겨야 할지 헷갈릴 때 이 페이지를 참고하세요.
기준은 간단합니다. 작업이 흐릿하면 먼저 요구사항을 명확히 하고, 틀렸을 때 비용이 크면 구현 전에 계획합니다. 승인된 계획은 오래 유지되어야 하면 $ultragoal로 넘기고, 실제로 독립해서 진행할 수 있는 부분이 있을 때만 팀으로 나눕니다.
결정표
| 상황 | 첫 선택 | 이유 |
|---|---|---|
| 요구사항이 모호함 | $deep-interview | 구현 전에 범위를 먼저 정해야 함 |
| 방향은 알지만 계획이 없음 | $ralplan | 절충안과 테스트 기준을 먼저 고정해야 함 |
| UI/UX, 프런트엔드, 디자인 시스템 방향이 필요함 | $design | 구현 전에 repo-local DESIGN.md로 기준을 고정함 |
| 결합도가 높아 한 컨텍스트가 필요함 | $ralph | 단일 소유자가 하나의 검증 루프를 유지함 |
| 큰 계획이 여러 마일스톤으로 이어짐 | $ultragoal | 목표, 진행 장부, 인계 근거를 지속적으로 저장함 |
| 일을 독립적인 작업 축으로 나눌 수 있음 | $team | 병렬화의 이득이 실제로 있음 |
| 빠르게 프로토타입을 보고 싶음 | $autopilot | 일부 제어를 내려놓고 속도를 얻음 |
| 검증과 수정이 핵심임 | $ultraqa | 테스트, 진단, 수정을 반복함 |
기본 안내 흐름
OMX가 처음이라면 단축 경로부터 쓰기보다 아래 세 단계를 한 번 거쳐 보세요.
$deep-interview "clarify the authentication change"
$ralplan "approve the safest implementation path"
$ultragoal "turn the approved plan into durable goals and complete them"| 단계 | 역할 |
|---|---|
$deep-interview | 요구사항이 흐릿할 때 작업을 명확히 정리함 |
$ralplan | 구현 전에 계획과 절충안을 합의함 |
$ultragoal | 승인된 계획을 durable goal, ledger evidence, completion checkpoint로 전환함 |
나중에는 $autopilot에 전체 실행 흐름을 빠르게 맡길 수 있습니다. 다만 이 기본 흐름을 먼저 거치면 각 단계가 어디에서 가치를 내는지 더 잘 보입니다.
$autopilot으로 빠르게 프로토타입 만들기
$autopilot "build me a todo app in next.js"잘 맞는 경우:
- 작은 기능이나 버려도 되는 프로토타입
- 운영 위험이 낮은 작업
- 전체 실행 흐름을 빠르게 확인하고 싶은 경우
요구사항이 불명확하거나, 아키텍처 위험이 크거나, 명시적인 계획 승인이 중요하다면 다른 워크플로우를 고르세요.
구현 전에 계획하기
$deep-interview "clarify what we need to build"
$ralplan "produce the safest implementation plan"
$ultragoal "turn that plan into durable goals and complete them"아키텍처, 테스트, 데이터 마이그레이션, 보안, 운영 영향이 중요한 작업에는 이 경로가 더 안전합니다. 승인된 계획이 한 번의 실행 루프 안에만 남지 않고 durable goal로 보존되기 때문입니다.
$design로 UI 작업 전에 설계 기준 세우기
제품, UI/UX, 프런트엔드, 디자인 시스템 결정이 구현 전에 repo의 durable source of truth로 남아야 한다면 $design을 사용합니다. 기존 UI 근거를 확인하고, 디자인에 꼭 필요한 누락 맥락만 질문한 뒤, repo root의 DESIGN.md를 만들거나 갱신합니다.
$design "create a design contract for the dashboard refresh"좋은 후속 흐름:
- frontend, backend, test를 깔끔하게 나눌 수 있으면 승인된 design contract를
$team으로 넘김 - design plan이 여러 milestone으로 이어지면
$ultragoal로 넘김 - 승인된 screenshot, mockup, image, live URL을 시각적으로 맞춰야 할 때만
$visual-ralph를 사용
$ultragoal로 지속 가능한 마일스톤 추적하기
$ultragoal은 넓은 작업 개요나 승인된 계획을 오래 유지되는 Codex/OMX 목표로 바꿉니다. 장기 계획을 .omx/ultragoal/ 아래에 기록하고, 진행 장부로 상태를 추적하며, 현재 스레드를 Codex goal mode로 명시적으로 인계합니다.
$ultragoal "split this launch plan into durable goals and complete them"컨텍스트 압축이나 작업 인계를 견뎌야 하는 다중 마일스톤 출시, 릴리스 트레인, 큰 리팩터링에 사용합니다.
$team으로 병렬 작업 나누기
$team 3:executor "execute the approved plan in parallel"
잘 맞는 경우:
- 프런트엔드, 백엔드, 테스트가 독립적으로 진행될 수 있음
- 파일 소유 범위를 명확히 나눌 수 있음
- 계획이 이미 승인됨
요구사항이 모호하거나, 하나의 컨텍스트를 계속 유지해야 하거나, 병렬 작업 흐름이 대부분 병합 충돌을 만들 것 같다면 team mode는 피하세요.
$ultraqa로 검증과 수리 반복하기
초록색 build만으로는 충분하지 않고 hostile/edge condition에서의 실제 동작까지 확인해야 한다면 $ultraqa를 사용합니다. baseline check와 adversarial dynamic e2e scenario를 함께 돌리고, 실패를 진단해 고친 뒤, temporary harness cleanup과 evidence report까지 남깁니다.
$ultraqa --tests
$ultraqa --custom "the report export rejects stale state"잘 맞는 경우:
- prompt injection, cancel/resume, stale state, misleading success output이 중요한 CLI 또는 workflow 변경
- failure evidence와 cleanup proof가 필요한 release-readiness 확인
- unit test는 통과했지만 dynamic behavior probe가 더 필요한 기능