oh-my-claudecode(OMC)는 Claude Code 위에서 기획, 구현, 검토 역할과 hook, state를 조합하는 multi-agent 구성입니다. 32개 역할을 둔다는 사실만으로 비용이 줄거나 속도가 3~5배 빨라지지는 않으며, 독립 작업의 병렬성, 검증 기여, 복구 가능성을 같은 task에서 측정해야 합니다. 작은 격리 branch에서 단일 Agent보다 실제 review 시간을 줄이는 역할만 남기는 편이 좋습니다.
OMC 저장소는 single session의 context와 자기검증 한계를 역할 분리로 다루려 합니다. 사람 조직과 같은 “개발팀”이 생겼다고 보기보다 task graph, prompt와 tool 권한을 나눈 workflow로 이해해야 과장을 피할 수 있습니다.
원문은 OMC를 Hooks, Skills, Agents, State 네 layer로 설명합니다. 실제 지원 interface와 구성은 선택한 repository commit에서 확인해야 하며, 역할 수와 “완벽한 조율”은 구현 증거가 아닙니다. 각 layer가 없을 때 어떤 오류가 늘어나는지 분리해 보는 것이 중요합니다.
원문은 model routing과 Team Mode에서 Plan→PRD→Execute→Verify 단계를 나누는 흐름을 설명합니다. 조사처럼 독립적인 하위 작업은 병렬로 실행할 수 있지만 PRD가 필요한 구현이나 같은 file을 바꾸는 작업은 순서를 지켜야 합니다. dependency를 무시한 worker 수 증가는 merge 충돌과 재작업을 만듭니다.
| 비교 항목 | Native Claude Code | oh-my-claudecode (OMC) |
|---|---|---|
| 작업 방식 | 단일 모델이 처음부터 끝까지 순차적으로 처리 | 32개 전문 에이전트(아키텍트, 코더, QA 등)가 병렬 처리 |
| model 활용 | 한 model, 설정으로 처리 | 역할별 routing을 구성할 수 있으며 실제 mapping은 version별 확인 |
| 검증 방식 | 같은 context의 자기검토 위험 | 다른 역할, model review와 결정적 test를 함께 구성 |
| 상태 관리 | 세션이 길어지면 토큰 오염 및 할루시네이션 급증 | 영속성(Persistence) 레이어로 각 에이전트 컨텍스트 독립적 초기화 |
아래 JSON은 pipeline state의 개념을 설명하는 예시입니다. 실제 OMC schema, 지원 model 이름이나 tokens_saved 계산으로 단정하지 말고 선택한 version의 source와 생성 state file을 확인해야 합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{
"orchestration_mode": "team-mode",
"task_id": "migrate-auth-middleware-v2",
"pipeline_stage": "verification",
"agents_in_action": {
"architect": {
"model": "claude-3-opus",
"role": "시스템 설계 및 PRD 작성",
"status": "completed"
},
"coder": {
"model": "claude-3-5-sonnet",
"parallel_workers": 3,
"status": "completed"
},
"reviewer": {
"model": "codex-validator",
"role": "Adversarial Stress Testing (적대적 검증)",
"status": "running"
}
},
"hooks_active": ["pre-commit-lint", "blind-tdd-check"],
"cost_optimization": {
"tokens_saved": 45000,
"strategy": "haiku_fallback_for_chores"
}
}
다른 역할이나 model이 review하면 표현 편향을 줄일 가능성은 있지만 오류를 원천 차단하지 않습니다. reviewer가 같은 잘못된 PRD와 source를 읽으면 같은 결론을 낼 수 있습니다. compiler, 기존, 새 test와 specification처럼 model과 독립된 기준을 최종 gate로 둡니다.
병렬 coder가 같은 file이나 API contract를 바꾸지 않게 작업별 write path와 branch를 분리합니다. 결과 merge에는 ownership, conflict와 dependency test가 필요합니다. worker가 많아도 최종 통합이 직렬 병목이면 wall time은 줄지 않을 수 있습니다.
상태 persistence가 있다면 terminal 종료 뒤 stage, artifact를 복구할 수 있는지 실제로 강제 종료해 시험합니다. model의 긴 context를 완벽히 복원한다는 표현보다 task ID, 기준 commit, 완료 artifact, 실패와 budget을 구조화해 저장하는지가 중요합니다. state file과 Git이 충돌하면 Git diff와 test를 진실의 원천으로 삼습니다.
pre-commit-lint 같은 hook도 이름이 아니라 집행을 확인합니다. 실패 exit code가 commit을 차단하는지, Agent가 hook을 끄거나 lint 설정을 약화할 수 있는지, timeout 때 fail closed하는지 봅니다. lint 통과는 의미, 보안 검증을 대신하지 않습니다.
수백 file의 monolith를 한 번에 MSA로 바꾸는 것은 OMC 여부와 무관하게 위험합니다. 먼저 read-only dependency map과 한 module의 contract test를 만들고, 작은 경계 하나만 격리 branch에서 분리합니다. Ralph Mode 같은 이름과 실제 동작, 종료 조건은 repository version에서 확인합니다.
Tmux와 HUD가 있더라도 사람이 상태 표시만 보면 되는 것은 아닙니다. 각 stage의 기준 commit, artifact, test, budget과 blocker를 열 수 있어야 하고 transaction 경계 변경은 승인 전에 merge하지 않습니다.
OMC에 Datadog, CloudWatch 접근이 실제로 제공되는지는 별도 connector와 권한을 확인해야 합니다. 장애 조사 역할에는 incident 시간 범위의 read-only log만 주고 근거 source가 붙은 RCA 초안을 만들게 할 수 있습니다. DB pool 변경이나 cache hotfix는 동시에 자동 실행하지 않고 별도 branch와 사람 승인으로 분리합니다.
Agent가 많은 환경에서는 한 잘못된 alert 해석이 조사, code, review로 빠르게 전파될 수 있습니다. 과거 incident fixture에서 red herring, PII masking, tool budget과 근거 적중률을 평가하기 전에는 live incident에 연결하지 않습니다.
대표적인 작은 task 20개를 단일 Claude Code, OMC의 최소 세 역할, 더 큰 Team Mode로 실행합니다. 정답 test, 무관 diff, wall time, 총 호출, 사람 review 수정과 복구 실패를 같은 표에 놓습니다. 각 역할을 하나씩 빼도 결과가 같다면 그 역할은 운영 graph에서 제거합니다.
첫 파일럿은 운영 자격 증명이 없는 worktree와 보호 branch에서 수행합니다. state persistence, hook fail-closed, worker 충돌과 budget 중단을 의도적으로 재현합니다. 성능 수치와 model routing은 기사나 JSON 예시가 아니라 실제 usage, trace에서 확인합니다.
OMC의 유용한 질문은 “Agent가 32명인가”가 아니라 어떤 작업을 독립시키고 어떤 근거로 다시 합칠 것인가입니다. multi-agent가 single-agent보다 오류와 review를 줄이는 작업만 남기고, 최종 품질과 merge 책임은 사람과 결정적 gate가 소유해야 합니다.
보장되지 않습니다. 의존 작업은 병렬화할 수 없고 handoff, review 비용이 생기므로 같은 task에서 wall time, 호출, 정답을 직접 비교해야 합니다.
아닙니다. 같은 요구, 근거를 공유하면 같은 오류를 반복할 수 있어 compiler, test, 원문 specification 같은 독립 검증기가 필요합니다.
운영 권한이 없는 격리 branch에서 완료 조건이 분명한 작은 변경을 단일 Agent baseline과 비교하는 범위가 적합합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.