주요 개념

OMX를 구성하는 에이전트, 스킬, 훅, 상태 관리 시스템의 관계

OMX의 구성 요소

OMX는 네 가지 시스템이 맞물리면서 동작합니다.

각 개념 요약

에이전트 (Agents)

OMX는 33개의 role-specific 에이전트를 제공합니다. 각 에이전트는 하나의 책임에 집중합니다.

예: explore(탐색), planner(계획), architect(설계), executor(구현), verifier(검증)

스킬 (Skills)

스킬은 에이전트의 행동을 조합하고 확장하는 워크플로우 진입점입니다. $autopilot, $ralph, $team 같은 이름으로 호출됩니다.

예: $deep-interview(요구사항 명확화), $ralplan(합의 기반 계획), $ralph(완료까지 지속 실행)

훅 (Hooks)

훅은 Codex CLI의 라이프사이클 이벤트에 반응해서 스킬과 런타임 동작을 활성화합니다. 세션 시작, 사용자 입력, 도구 실행, 정지 시점마다 개입할 수 있습니다.

상태 관리 (State)

작업 진행 상황과 세션 간 지식은 .omx/ 디렉터리 아래에 저장됩니다. 그래서 context compaction 이후에도 중요한 정보가 유지됩니다.

에이전트란?

에이전트는 특정 역할에 특화된 작업 surface입니다. OMX는 이 에이전트들을 4개 레인으로 분류합니다.

Build / Analysis 레인

요구사항 이해부터 구현, 검증까지 개발의 중심 흐름을 담당합니다.

에이전트	역할
`explore`	코드베이스 탐색, 파일/패턴/관계 파악
`analyst`	요구사항 분석, 숨겨진 제약 조건 발견
`planner`	작업 순서와 계획 수립
`architect`	시스템 설계, 인터페이스, 트레이드오프 분석
`debugger`	근본 원인 분석
`executor`	코드 구현, 리팩토링
`verifier`	완료 검증, 테스트 적절성 확인

Review 레인

구현 결과를 넘기기 전에 품질과 위험을 점검합니다.

에이전트	역할
`quality-reviewer`	논리 결함, 유지보수성, 안티패턴 검토
`security-reviewer`	보안 취약점, 신뢰 경계, auth 검토
`code-reviewer`	종합 코드 리뷰
`style-reviewer`	스타일, 네이밍, 포맷 검토
`api-reviewer`	API 계약과 하위 호환성 점검
`performance-reviewer`	성능 병목과 비용 점검

Domain 레인

특정 분야에 강한 specialist들입니다. 필요할 때 호출됩니다.

예:

test-engineer — 테스트 전략
designer — UI/UX 설계
writer — 문서와 사용자 안내
researcher — 외부 문서와 레퍼런스 조사
build-fixer — 빌드/툴체인 오류 수정
git-master — Git 작업과 히스토리 관리

Coordination 레인

다른 에이전트가 만든 계획과 결과를 검토하고 조정합니다.

예:

critic — 계획/설계의 빈틈 검토
team-executor — 팀 실행 레인 보조
quality-strategist — 품질 전략 판단

에이전트 선택 감각

간단히 말하면 이렇게 생각하면 됩니다.

작업 유형	먼저 떠올릴 에이전트
코드베이스를 빠르게 읽고 싶다	`explore`
요구사항이 헷갈린다	`analyst`
계획부터 세워야 한다	`planner`, `architect`, `critic`
실제 구현을 해야 한다	`executor`
완료 여부를 확인해야 한다	`verifier`
보안/품질/성능이 걱정된다	review 레인

전체 목록은 에이전트 카탈로그에서 확인할 수 있습니다.

스킬이란?

스킬은 에이전트의 행동을 조합하는 워크플로우 시스템입니다. 에이전트를 대체하는 것이 아니라, 어떤 순서로 어떤 역할을 호출할지를 정리해 줍니다.

스킬을 어떻게 호출하나?

OMX에서는 보통 $ 접두사로 호출합니다.

$deep-interview "인증 요구사항을 정리해줘"
$ralplan "가장 안전한 구현 계획을 세워줘"
$ralph "승인된 계획을 끝까지 완료해줘"

또는 매직 키워드가 감지되면 대응하는 스킬이 자동으로 활성화되기도 합니다.

주요 워크플로우 스킬

스킬	역할
`$deep-interview`	요구사항이 모호할 때 질문으로 명확화
`$ralplan`	planner/architect/critic 합의 기반 계획 수립
`$ralph`	완료가 검증될 때까지 계속 실행
`$team`	병렬 실행이 필요한 작업을 조율
`$autopilot`	아이디어에서 구현/QA/검증까지 일괄 실행
`$ultraqa`	테스트, 검증, 수정 반복

스킬을 언제 쓰면 되나?

무엇을 만들지 모호하다 → $deep-interview
구현 전에 계획을 세우고 싶다 → $ralplan
한 명의 소유자가 끝까지 밀고 가야 한다 → $ralph
병렬 작업이 필요하다 → $team
한 번에 전 과정을 맡기고 싶다 → $autopilot

전체 목록은 스킬 카탈로그에서 확인할 수 있습니다.

훅이란?

훅(Hook)은 Codex CLI의 라이프사이클 이벤트에 반응하는 런타임 코드입니다. 사용자가 프롬프트를 입력하거나, 도구를 실행하거나, 세션이 시작/종료될 때 자동으로 개입합니다.

OMX는 훅을 통해 키워드 감지, 스킬 활성화, 상태 복원, 종료 차단 같은 동작을 구현합니다.

주요 이벤트와 역할

이벤트	OMX가 하는 일
`SessionStart`	상태 복원, 개발자 컨텍스트 주입, `.omx/` 초기 점검
`UserPromptSubmit`	매직 키워드 감지, 대응 스킬 활성화
`PreToolUse`	위험 명령 경고, 실행 전 가드
`PostToolUse`	실패 힌트 표면화, 후처리
`Stop`	아직 끝나지 않은 지속 실행 모드 차단/계속

즉, 훅은 사용자가 직접 호출하는 기능이 아니라, OMX가 뒤에서 자연스럽게 동작하도록 연결하는 이벤트 레이어라고 보면 됩니다.

자세한 내용은 Hooks 섹션에서 볼 수 있습니다.

상태 관리 개요

OMX는 실행 중 상태와 세션 간 기억을 .omx/ 아래에 저장합니다.

경로	역할
`.omx/state/`	활성 모드 상태
`.omx/plans/`	`$ralplan` 같은 계획 결과
`.omx/logs/`	세션 및 실행 로그
`.omx/notepad.md`	자유 형식 메모
`.omx/project-memory.json`	오래 유지되는 프로젝트 지시문/노트
`.omx/wiki/`	누적되는 wiki 지식

왜 중요한가?

상태 관리가 있기 때문에 OMX는:

context compaction 이후에도 진행 상황을 잃지 않고
장기 실행 워크플로우를 재개할 수 있고
세션이 바뀌어도 프로젝트 지식을 이어받을 수 있습니다.

즉, 훅과 스킬이 “행동”을 담당한다면, 상태 관리는 그 행동이 끊기지 않게 만드는 기반입니다.

자세한 내용은 .omx/ 디렉터리 참조와 State 도구를 참고하면 됩니다.

목차