ECC vs OMC
Claude Code 에이전트 하네스 비교 리포트
2026-07-30 기준
ECC(Everything Claude Code)와 OMC(oh-my-claudecode)는 둘 다 2026년 1월에 태어난
1인 메인테이너 오픈소스 Claude Code 하네스지만 철학이 정반대다. ECC는 context-lean 플러그인 구조로
281개 스킬을 필요할 때만 불러오고, 언어별 리뷰어와 품질 게이트로 안정성을 강조한다. OMC는 멀티에이전트
오케스트레이션을 상시 가동하며 매직 키워드 한 마디로 자율 실행을 트리거하고, 3단 모델 라우팅으로 비용
절감을 노린다. 아래에서 규모·강점·약점·핵심 차이를 데이터 기준으로 비교한다.
01 · Overview
한눈에 보기
GitHub API 및 저장소 실측 기준 핵심 지표 비교.
02 · Philosophy
철학과 아키텍처
두 하네스가 컨텍스트와 실행을 다루는 근본적으로 다른 접근.
ECC
철학
"Optimize the context window. Persist everything else." 자칭 "harness-native operator layer" — plan→test→implement→review→verify→remember→improve 파이프라인을 내장한다.
아키텍처
Agents 67개 + Skills 281개 + legacy 커맨드 shim 94개 + 언어팩 Rules 22종. 언어별 reviewer / build-resolver 페어, orch-* 오케스트레이션 스킬, GAN 대립 루프(planner/generator/evaluator), Epic/PM 스킬, Instinct 연속학습 시스템으로 구성.
컨텍스트 전략
On-demand skill loading — 281개 스킬은 태스크 매칭 시에만 로드되어 상시 컨텍스트 부담이 낮다. 단, Rules(common+언어팩)는 설치 시 상시 로드되어 세션마다 수천 토큰을 고정 소모한다.
OMC
철학
"Teams-first Multi-agent orchestration for Claude Code" / "Zero learning curve. Maximum power." 매직 키워드 한 마디로 완전 자율 실행을 트리거하는 것을 지향.
아키텍처
인세션 파이프라인(plan→PRD→execute→verify→fix, 실험 플래그 의존) + CLI omc(tmux 워커로 Claude·Codex·Gemini·Grok 등 외부 모델 병렬 스폰). Agents 29개를 Haiku(LOW)/Sonnet(MEDIUM)/Opus(HIGH) 3단 모델 티어로 라우팅.
컨텍스트 전략
메인 에이전트 컨텍스트를 태스크 컨텍스트에서 격리해 조기 컴팩션을 방지. Team/Autopilot/Ralph/Ultrawork/Pipeline/Ecomode 등 실행 모드로 병렬성과 지속성을 상시 오케스트레이션한다.
03 · Strengths
장점
각 하네스가 리서치·실사용 후기에서 인정받은 강점.
ECC 강점
- On-demand skill loading — 281개 스킬이 태스크 매칭 시에만 로드되어 컨텍스트 절약(context-lean)
- Clean uninstall — ECC가 설치한 파일만 추적해 삭제(
--dry-run 지원)
- 언어별 전문 reviewer — 신뢰도 80% 이상 필터링, 보안 우선순위화 (외부 리뷰 긍정 평가)
- TDD를 hook/agent로 게이팅해 강제
- Plan이 채팅에서 사라지지 않고 편집 가능한 아티팩트로 유지됨
- 비판적 Medium 기사조차 "Claude Code agents/skills/hooks 구조의 최고 레퍼런스 아키텍처"로 인정
OMC 강점
- 메인 에이전트 컨텍스트를 태스크 컨텍스트에서 격리 → 조기 컴팩션 방지 (실사용 후기)
- 병렬 서브에이전트로 체감 속도 향상
- 공식 hooks 기반이라 TOS 리스크 낮음
- 스마트 모델 라우팅으로 "30~50% 토큰/비용 절감" 주장 (벤더 자체 주장, 미검증)
- Ralph 모드의 "포기하지 않는" 지속성(until done 반복 루프)
- 커뮤니티 제안을 몇 주 내 흡수하는 빠른 개발 속도
04 · Weaknesses
단점
실제 GitHub 이슈와 커뮤니티 비판 기준.
ECC 단점
- GateGuard 차단 이슈 (
#1422·#1427) — auto 모드에서 git status까지 전부 차단, 훅을 끄려는 settings.json 편집조차 재차 차단하는 self-locking 무한루프 사례
- 병렬 툴콜 중 하나가 GateGuard에 걸리면 나머지 전부 취소되는 연쇄 실패
- Rules 상시 컨텍스트 부담 — 언어팩 다수 설치 시 세션마다 수천 토큰 고정 소모
- 281개 스킬 학습 곡선 — "잘 만든 60~200줄 CLAUDE.md 하나가 필요의 80%를 커버하는데 과잉설계"라는 Medium 비판
- 네이밍 혼란 — 저장소(affaan-m/ECC) vs 마켓플레이스(ecc@ecc) vs npm(ecc-universal),
/ecc:plan vs /plan 공존
- Rules가 플러그인으로 배포되지 않아 "설치 한 번에 전부" 약속이 불완전 (
#29, #52, #103)
- 문서-실물 불일치 — SOUL.md는 "30 agents, 135 skills"로 기술하나 실제는 67/281 (문서가 배포 속도를 못 따라감)
OMC 단점
- README가 과장·분노 표출 중심이고 기능 설명이 부실 (HN 비판 다수)
- "기본 설정이 브리틀, 높은 토큰 소모 대비 결과물은 그저 그럼"이라는 실사용 후기
- 멀티에이전트 오케스트레이션 실효성에 근본적 회의론 — 병렬 실행이 비용을 배가시킬 수 있음
- 1인 메인테이너 (bus factor)
- 잦은 breaking change — v4.1.7에서 Swarm 모드 제거, v4.4.0에서 MCP 서버 지원 제거
- 실험적 플래그(
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS) 의존 → Anthropic 네이티브 기능 출시 시 무력화 위험
- Claude Code 업데이트 후 호환성 문제 다수 —
#3576 HUD 파싱 깨짐, #3574 컨텍스트 경고 silent failure, #3571 매 세션 재로그인 강제, #3601·#3600·#3584 Windows 지원 취약
05 · Key Differences
핵심 차이 5가지
의사결정에 가장 크게 영향을 주는 다섯 가지 축.
1
컨텍스트 전략
ECCOn-demand skills — 필요할 때만 로드해 컨텍스트 절약
OMC상시 오케스트레이션 — 메인 컨텍스트를 태스크와 격리해 조기 컴팩션을 방지
2
비용 접근
ECC품질 게이트 우선 — 리뷰·TDD 강제로 재작업 비용을 줄이는 전략
OMC모델 라우팅으로 "30~50% 절감" 주장 (벤더 자체 주장, 미검증)
3
안정성
ECC잦은 릴리스 + breaking change, 문서-실물 불일치 이력
OMC잦은 릴리스 + breaking change, 여기에 실험 플래그 의존까지 더해져 안정성 리스크 가중
4
플랫폼
ECCRules 언어팩이 플러그인 배포에서 제외되어 수동 git clone 후 복사 필요
OMCTeam 모드는 tmux 필요(Windows는 psmux), 일부 기능 Linux flock 필요 — Windows 취약 이슈 다수(#3601·#3600·#3584)
5
학습 곡선
ECC281개 스킬 체계를 학습해야 전체 역량을 활용 가능
OMC"Zero learning curve" — 매직 키워드(ultrawork, ralph, autopilot 등) 한 마디로 즉시 실행
06 · Verdict
어느 쪽을 써야 할까
사용 목적에 따른 권장안.
ECC를 선택하면 좋은 경우
품질 게이트, 언어별 전문 리뷰어, TDD 강제, 컨텍스트 절약(on-demand skill loading)을 원한다면 ECC가 적합하다. 안정적인 코드 품질 파이프라인과 clean uninstall이 중요한 팀에 유리하다.
OMC를 선택하면 좋은 경우
매직 키워드로 즉시 자율 실행을 트리거하고, 멀티모델 병렬 처리와 비용 라우팅을 원한다면 OMC가 적합하다. 학습 곡선을 최소화하고 빠른 속도감을 우선하는 사용자에게 유리하다.
ℹ️
이 환경은 2026-07-30 OMC에서 ECC로 전환 완료되었습니다.
07 · Shared Risk
공통 리스크
- 둘 다 1인 메인테이너 체제 — bus factor(핵심 인력 이탈 시 지속 불가) 리스크가 있음
- 둘 다 잦은 breaking change를 동반하는 빠른 릴리스 케이던스
- 둘 다 Claude Code 자체 업데이트에 취약 — 내부 API/데이터 구조 변경 시 파싱·훅이 깨질 수 있음
- 벤더가 자체 주장하는 성능·비용 절감 수치(예: OMC의 "30~50% 절감", ECC GateGuard의 "+2.25점" 표본 n=2)는 모두 미검증 상태