1. 서론: 같은 문제, 다른 추상화 계층
2026년 Claude Code 생태계에서 멀티 에이전트 오케스트레이션을 다루는 대표적 오픈소스 시도로 Oh My Claude(이하 OMC, oh-my-claudecode)와 Oh My Agent(이하 OMA, first-fluke/oh-my-agent)를 들 수 있습니다. 두 프로젝트는 “단일 AI에 모든 일을 맡기면 역할이 섞이고 완료 품질이 불안정해진다”는 문제 인식에서 출발합니다. 그러나 해법의 추상화 계층이 다릅니다.
OMC는 Claude Code 전용 멀티 에이전트 오케스트레이션 플러그인·CLI입니다. Claude Code UX를 유지한 채 전문 에이전트 위임, 실행 모드(Autopilot, Ultrawork, Ralph, Team 등), 스마트 모델 라우팅을 자동화합니다. OMA는 벤더 비종속 포터블 멀티 에이전트 하네스입니다. `.agents/`를 단일 소스(SSOT)로 두고 Claude Code, Codex, Cursor, Antigravity, Grok Build 등 여러 런타임에 동일한 스킬·워크플로우·역할을 투영합니다.
본고는 두 시스템의 철학, 아키텍처, 설치·명령어, 워크플로우, 모델 전략, 실무 선택 기준, 학문적 함의를 비교합니다. 목표는 우열 선언이 아니라, 어떤 조직·작업에 어떤 계층이 적합한지를 밝히는 데 있습니다.
2. 제품 정의 비교
2.1 Oh My Claude (OMC)
OMC는 Yeachan-Heo가 주도하는 MIT 라이선스 프로젝트로, Claude Code 플러그인과 npm CLI(`omc` / `oh-my-claude-sisyphus`)로 배포됩니다. 슬로건은 “Claude Code를 배우지 말고, 그냥 OMC를 쓰십시오”입니다. 30개 전후의 전문 에이전트, 다수의 스킬·훅, Tier-0 워크플로우를 제공하며, 자연어 키워드만으로도 모드가 선택되도록 설계되어 있습니다.
2.2 Oh My Agent (OMA)
OMA는 first-fluke가 주도하는 포터블 하네스입니다. 공식 수사는 “AI 어시스턴트에게 동료를 부여한다”입니다. frontend·backend·architecture·QA·PM·DB·mobile·infra·debug·design·explore 등 역할 에이전트를 `.agents/`에 정의하고, 설치기가 각 런타임 네이티브 레이아웃으로 생성·동기화합니다. Node.js 26+ 환경과 bun 기반 CLI가 중심입니다.
3. 설계 철학의 차이
OMC의 철학은 Claude Code 안에서의 팀형 실행 가속입니다. 학습 곡선을 최소화하고, 위임·병렬화·지속 실행(Ralph)을 자동으로 수행합니다. “완료될 때까지 포기하지 않는” 실행 모드가 제품 정체성의 일부입니다.
OMA의 철학은 역할 분리 + 이식성(portability)입니다. 특정 IDE에 지식이 갇히지 않도록 SSOT를 프로젝트와 함께 이동시키고, 벤더별 파일은 생성물로 취급합니다. 소프트웨어 공학의 역할 분리를 에이전트 팀 설계에 직접 투영합니다.
요약하면, OMC는 “Claude Code를 더 잘 쓰게 만드는 오케스트레이터”, OMA는 “여러 런타임이 공유하는 에이전트 팀의 규약과 하네스”에 가깝습니다.
4. 아키텍처 비교
4.1 OMC
Claude Code의 agentic loop 위에서 동작합니다. 사용자 입력이 키워드·의도 분석을 거쳐 autopilot, ultrawork, ralph, team, ralplan 등 Tier-0 워크플로우 또는 개별 스킬로 라우팅됩니다. 전문 서브에이전트(executor, critic, architect, document-specialist 등)에 위임하고, 검증 후 종합합니다. 모델 라우팅은 단순 작업 Haiku, 표준 Sonnet, 심층 Opus 경향을 따릅니다.
4.2 OMA
SSOT는 `.agents/`입니다. skills, workflows, agents, oma-config.yaml, rules가 핵심입니다. 각 에이전트의 target vendor를 설정에서 해석한 뒤, 현재 런타임과 같으면 네이티브 서브에이전트 경로를 사용하고, 아니면 `oma agent:spawn`으로 폴백합니다. Claude Code용으로는 `.claude/agents/*.md`, CLAUDE.md, 라우터 스킬 등이 생성됩니다.
4.3 구조적 함의
OMC는 Claude Code surface에 깊숙이 최적화되어 즉각적인 생산성이 높습니다. OMA는 추상화 비용이 있지만, 멀티 IDE 팀과 장기 프로젝트에서 지식·프로세스의 이동 비용이 낮습니다.
5. 실행 모드·워크플로우 비교
OMC의 대표 모드는 Autopilot(완전 자율), Ultrawork/Ultrapilot(최대 병렬), Ralph(검증 통과까지 지속), Team(다중 에이전트 조율), Ecomode(비용 효율)입니다. 키워드 트리거(`autopilot:`, `ralph:`, `ulw` 등)가 강조됩니다.
OMA의 대표 워크플로우는 orchestrate, work, ultrawork, ralph, plan, brainstorm, architecture, design, review입니다. 특히 ralph는 ultrawork를 감싸고 독립 judge가 완료를 인정할 때까지 종료를 막는 지속 루프로 설명됩니다. 키워드 훅과 명시적 워크플로우 이름이 함께 사용됩니다.
명칭상 ralph·ultrawork가 겹치지만, 구현 맥락이 다릅니다. OMC의 모드는 Claude Code 플러그인 오케스트레이션에 밀착되어 있고, OMA의 워크플로우는 SSOT 워크플로우 정의와 멀티 런타임 디스패치 위에 있습니다.
6. 모델·비용 전략
OMC는 Claude 모델 계층(Haiku/Sonnet/Opus) 안에서 스마트 라우팅으로 토큰 절감을 주장합니다. Claude 구독·API 비용 구조 안에서 최적화하는 접근입니다.
OMA는 `model_preset`(claude, codex, cursor, antigravity, mixed, qwen 등)과 역할별 오버라이드로 벤더 자체를 섞을 수 있습니다. 예: 오케스트레이션은 Claude, 구현은 Codex, 탐색은 저비용 모델. 팀의 구독 포트폴리오를 활용하는 전략에 유리합니다.
7. 설치 방법 (필수)
7.1 OMC 설치
전제: Claude Code CLI와 Claude 구독 또는 API 키.
# Claude Code 세션에서 한 줄씩 /plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode /plugin install oh-my-claudecode # 설정 /omc-setup # 또는 /oh-my-claudecode:omc-setup # npm CLI 경로 npm i -g oh-my-claude-sisyphus@latest omc setup
7.2 OMA 설치
전제: Node.js 26+ 권장. 스크립트가 bun·uv·serena를 자동 설치할 수 있습니다.
# macOS / Linux curl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash # Windows PowerShell irm https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.ps1 | iex # 수동 bunx oh-my-agent@latest # Homebrew brew install oh-my-agent
스킬만 배포할 경우 Agent Package Manager(`apm install first-fluke/oh-my-agent`)도 가능하나, 워크플로우·설정·spawn CLI까지 쓰려면 본 설치가 필요합니다.
8. 필수 명령어 비교
8.1 OMC 핵심 명령
/omc-setup— 최초·재설정 (사실상 필수)omc setup— 터미널 설정- 자연어 트리거:
autopilot: ...,ralph: ...,ulw ... - 슬래시 워크플로우:
/autopilot,/ultrawork,/ralph,/team,/ralplan - 취소·검증 관련 스킬 명령
8.2 OMA 핵심 명령
oma install/oma install --globaloma update,oma uninstall [--dry-run]oma doctor --profile— 역할별 모델 매트릭스oma emit— 개방형 산출물 생성oma agent:spawn— 크로스 벤더 디스패치oma verify triggers— 트리거 감지기 평가- 워크플로우 키워드:
ralph:,ultrawork,plan,orchestrate등
8.3 사용 감각의 차이
OMC는 Claude Code 세션 안에서 “말하기만 하면” 모드가 선택되는 경험이 강합니다. OMA는 프로젝트 SSOT를 먼저 설치·동기화한 뒤, 런타임에서 워크플로우를 호출하는 프로젝트 엔지니어링 성격이 강합니다.
9. 설정 단위와 이식성
OMC의 설정은 로컬/글로벌 CLAUDE.md 선택, 플러그인·훅·HUD 설치에 무게가 있습니다. Claude Code 생태계 안에서의 일관성이 목표입니다.
OMA의 설정 중심은 `.agents/oma-config.yaml`입니다. 언어, model_preset, 역할별 모델, 규칙, 브랜칭 정책 등을 프로젝트와 함께 버전 관리할 수 있습니다. `oma emit`과 CI drift 검사로 생성물의 정합성을 유지하려는 점이 특징입니다.
10. 실무 시나리오별 적합성
Claude Code만 쓰는 개인·소규모 팀이 빠르게 병렬 구현·완료 보장 루프를 원하면 OMC가 유리합니다. 설치 후 즉시 autopilot/ralph를 사용할 수 있습니다.
Claude Code + Cursor + Codex를 혼용하는 팀이 동일한 역할 정의와 워크플로우를 공유하려면 OMA가 유리합니다. SSOT가 프로젝트와 함께 이동합니다.
비용 최적화에서 OMC는 Claude 내부 티어 라우팅, OMA는 벤더 혼합 프리셋으로 접근합니다. 구독 구성에 따라 선택이 달라집니다.
완료 정의가 엄격한 작업에서는 둘 다 ralph형 지속 루프를 제공합니다. OMC는 Claude Code 검증 루프에, OMA는 독립 judge를 포함한 워크플로우 정의에 무게가 있습니다.
11. 강점·약점 요약
OMC 강점: Claude Code 밀착, 제로에 가까운 학습 곡선, 강력한 실행 모드, 즉각적 생산성. 약점: Claude Code 종속, 멀티 IDE 이식성 제한, 자율 루프의 토큰 비용 증가 가능성.
OMA 강점: 벤더 비종속 SSOT, 역할·워크플로우의 프로젝트 이동성, 모델 프리셋 유연성, 멀티 런타임 팀 지원. 약점: 초기 개념 학습 비용, 설정 복잡도, 런타임별 네이티브 기능 차이, 생성물 drift 관리 필요.
12. 조합 가능성과 계층적 사용
두 도구는 상호 배타적이지 않습니다. 예를 들어 OMA로 프로젝트 SSOT와 역할 정의를 관리하고, 실제 Claude Code 세션에서는 OMC의 실행 모드를 활용하는 식의 계층적 조합을 고려할 수 있습니다. 다만 오케스트레이션 계층이 이중화되면 책임 경계가 모호해질 수 있으므로, 팀 내 “SSOT는 OMA, 세션 실행 가속은 OMC”처럼 역할을 문서화하는 것이 좋습니다.
13. 학문적 함의
OMC는 “단일 에이전트 한계를 팀형 위임으로 보완하는 런타임 오케스트레이션”의 제품 사례입니다. OMA는 “에이전트 조직의 인터페이스·프로세스·배치를 프로젝트 자산으로 승격시키는 규약”의 사례입니다. 전자가 실행 시 제어에 가깝다면, 후자는 개발 조직의 지식 인프라에 가깝습니다.
공통 연구 과제는 완료 조건의 검증 가능성, 병렬 실행 시 일관성, 의도 라우팅의 측정, 비용·품질 트레이드오프입니다. OMA가 트리거 감지기를 코퍼스와 CI로 점수화하는 점, OMC가 모드별 병렬성·지속성을 제품 언어로 고정한 점은 각각 평가 가능한 설계 선택으로 볼 수 있습니다.
14. 한계와 위험
둘 다 자율 루프를 제공하므로 토큰·시간 비용이 커질 수 있습니다. 권한 승인 없는 과도한 자율 실행은 위험합니다. OMC는 Claude 종속 리스크, OMA는 설정 파일의 코드 동등성(임의 바이너리 실행 가능) 리스크를 인식해야 합니다. 신뢰할 수 없는 프로젝트의 설정을 검토 없이 실행하면 안 됩니다.
15. 결론: 선택 기준
Claude Code를 주력으로 쓰며 “지금 당장 팀처럼 일하게” 만들고 싶다면 OMC가 적합합니다. 설치는 플러그인 추가와 `/omc-setup`으로 충분하고, `autopilot`·`ralph`·`ulw`만으로도 실무 가치가 큽니다.
여러 AI IDE를 넘나들며 역할·워크플로우·규칙을 프로젝트 자산으로 관리하려면 OMA가 적합합니다. `oma install`, `oma doctor –profile`, `oma agent:spawn`, `.agents/oma-config.yaml`이 중심 축입니다.
결국 OMC는 Claude Code 세션의 오케스트레이션 증폭기이고, OMA는 멀티 런타임 에이전트 팀의 포터블 하네스입니다. 팀의 도구 다양성, 이식성 요구, 구독 구성, 완료 보장 수준에 따라 선택하거나 계층적으로 조합하는 것이 타당합니다.
주요 근거
OMC: github.com/Yeachan-Heo/oh-my-claudecode , 공식 README·CLAUDE.md·실행 모드 문서
OMA: github.com/first-fluke/oh-my-agent , SUPPORTED_AGENTS.md , oma-config 가이드 , install 스크립트
2026년 릴리스 및 커뮤니티 기술 자료
추상화 층으로 고르기
| 허용하는 종속 | 선택 | 이유 |
|---|---|---|
| Claude에 밀착해도 됨 | OMC | 세션 위 역할 분담이 짧음 |
| 공급자를 바꿔야 함 | OMA | 설정과 역할을 들고 옮김 |
| 둘 다 필요 없음 | 단독 CLI | 단일 과제에는 오버레이가 낭비 |
문제 정의: 기능 체크리스트로 고르면 둘 다 설치하게 된다
OMC는 Claude 밀착, OMA는 공급자 분리입니다. 종속 허용 범위로 고르고, 한 팀에 두 표준을 동시에 두지 않습니다. 단일 과제에는 어느 쪽도 필요 없습니다.
Takeaway
- OMC는 Claude 밀착, OMA는 공급자 분리입니다. 기능 체크리스트로 고르지 말고 종속 허용 범위로 고르십시오.
- 둘 다 멀티 에이전트이므로 단일 과제 클론 코딩에는 필요하지 않습니다.
- 평가 주에는 같은 버그를 두 하네스에 넣어 재현 시간과 토큰을 재십시오.
- 승자 없는 비교가 정상입니다. 팀의 제약(보안, 벤더, 인원)이 승자를 정합니다.
도입 전 점검: 실측 없이 고르지 않는 법
카탈로그 비교만으로 도구를 고르면 팀의 실제 병목과 무관한 기준으로 결정하게 된다. 아래는 두 도구 중 하나를 실제로 채택하기 전, 1~2주 파일럿에서 측정해야 할 최소 지표다.
- 완료 판정 정확도: 같은 버그 티켓 10개를 각 도구의 지속 실행 모드(OMC의 ralph, OMA의 ralph 워크플로우)에 넣고, “완료”로 판정된 결과물 중 실제 리뷰를 통과하는 비율을 센다. 완료 선언과 실제 완성도 사이의 괴리가 클수록 사람 검수 비용이 숨어 있다.
- 토큰·비용 곡선: 동일 작업을 3회 반복 실행해 토큰 사용량의 분산을 확인한다. 자율 루프는 작업 난이도에 따라 비용이 비선형으로 증가하는 경우가 많아, 평균값만으로는 예산을 잘못 잡기 쉽다.
- 런타임 전환 비용(OMA에만 해당): 동일 역할 정의를 Claude Code에서 Cursor로 전환했을 때, 실제로 몇 개 파일을 수동 수정해야 하는지 계산한다. “포터블”이라는 설계 목표와 실제 이식 비용은 다를 수 있다.
- 권한 경계: 두 도구 모두 자율 실행 중 승인 없이 실행 가능한 명령의 범위를 반드시 확인한다. 기본 설정을 그대로 쓰지 말고, 프로덕션 자격 증명이 있는 환경에서는 화이트리스트 방식으로 좁혀야 한다.
이 네 지표를 측정한 뒤에도 우열이 나지 않는다면, 그것이 정상이다. 도구 선택은 팀의 벤더 제약과 완료 기준의 엄격도가 정하지, 기능 목록이 정하지 않는다.