ECC — Claude Code의 기본값을 다시 디자인하는 메타프레임

TL;DR

• ECC(affaan-m/everything-claude-code)는 Anthropic × Cerebral Valley 해커톤(2026-02) 우승자 Affaan Mustafa가 만든 메타프레임워크다. 2026-01-22 v1.0 출시 후 약 4개월 만에 181.6k★·28k fork·1,900+ 머지 PR·150+ contributor. 같은 카테고리 다른 셋과 결정적으로 다른 점: commercial 플랫폼 평면을 가진다 — 호스티드 SaaS(ECC Tools Pro), GitHub App(150+ install), 별도 npm 패키지 2개(ecc-universal · ecc-agentshield), 무료/Pro/Enterprise 마켓플레이스 티어.
• 메커니즘 한 줄: 하네스 자체를 어떻게 굴릴지에 의견을 가진다. 토큰 최적화(model 디폴트 sonnet, MAX_THINKING_TOKENS=10000, CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=50), 메모리 영속(SessionStart/Stop 훅으로 컨텍스트 자동 저장·복원), instinct 기반 지속 학습(continuous-learning-v2의 신뢰도 점수), 보안 스캐닝(AgentShield 1,282 테스트·102 룰), 병렬 처리(git worktree·캐스케이드). 5개 축이 Claude Code의 실행 환경 자체를 갈아엎는다.
• 카테고리 진화: v1.5(2026-02-11) "Universal Edition"으로 10+ 하네스(Claude Code·Codex·Cursor·OpenCode·Gemini·Kiro·Qwen·Trae·CodeBuddy)에 분기 설치. v1.8(2026-03-05) "Harness Performance" 태그라인 도입 — 그 전까지의 "language rule pack" 정체성이 retroactively 재포지셔닝된 시점. v1.10(2026-04-05) "ECC 2.0 Alpha"와 운영자 워크플로 라이브러리 합류로 엔터프라이즈 vertical에 진입.
• 실제 규모는 README가 광고하는 "16 agents, 65 skills, 40 commands" 보다 큰 지점에 와 있다. 2026-05-14 main 브랜치 기준 60+ agents · 220+ skills · 75+ commands. README 숫자는 v1.6 시점에 고정돼 있고, 이후 매주 fix-wave PR로 카탈로그가 확장 중.
• 단독으로 쓰면 Claude Code의 실행 환경을 정직하게 다듬어주는 작업에 강하다. Superpowers·GSD·gstack과 섞으면 §6의 5가지 충돌 표면 — 특히 SessionStart 훅 4중 주입과 vertical skill의 description 매칭이 다른 프레임의 process 게이트를 우회하는 지점 — 에서 부딪친다.

1. ECC 소개

1.1. 무엇인가

affaan-m/everything-claude-code — Affaan Mustafa가 만든 AI 에이전트 하네스를 위한 성능 최적화 시스템. v1.10 README 자체의 self-positioning:

"단순한 설정 파일 모음이 아닙니다. 스킬, 직관(Instinct), 메모리 최적화, 지속적 학습, 보안 스캐닝, 리서치 우선 개발을 아우르는 완전한 시스템입니다. 10개월 이상 실제 프로덕트를 만들며 매일 집중적으로 사용해 발전시킨 프로덕션 레벨의 에이전트, 훅, 커맨드, 룰, MCP 설정이 포함되어 있습니다." — README (ko-KR)

핵심은 "단순한 설정 파일 모음이 아니다"라는 부정형 self-description이다. 그 부정이 진실에 가까운 이유는 carbon copy로 깔아 쓰는 dotfiles가 아니라 5개의 directional 축(토큰 최적화·메모리 영속·지속 학습·보안·병렬 처리)에 의견을 가진 환경 프레임워크이기 때문. Superpowers가 프로세스 게이트, GSD가 컨텍스트 분리, gstack이 역할 페르소나에 의견을 가진다면, ECC는 하네스 자체를 어떻게 운영할지에 의견을 가진다.

1.2. 창시자 — Affaan Mustafa와 Zenith.chat

Affaan Mustafa는 zenith.chat(AI 채팅 인터페이스 스타트업)의 창업자다. ECC의 등장 timeline은 그의 다른 작업과 묶여있다:

• 2026-01-22 — ECC v1.0 출시 ("Official Plugin Release"). Claude Code 플러그인 마켓플레이스 정식 등록.
• 2026-02 — Cerebral Valley × Anthropic 해커톤 우승. 수상작은 AgentShield — Claude Code 설정의 보안 취약점·misconfiguration·인젝션 위험을 스캔하는 도구. 1,282 테스트, 98% 커버리지, 102개 정적 분석 룰.
• 2026-02-24 — ECC v1.6 "Codex Edition + GitHub App". AgentShield를 npm ecc-agentshield로 분리 publish + GitHub App(github.com/marketplace/ecc-tools)으로 마켓플레이스 진입. 무료/Pro/Enterprise 3 티어.
• 2026-03-05 — ECC v1.8 "Harness Performance & Cross-Platform Reliability". 태그라인 자체가 "하네스 성능"으로 명시화된 시점.
• 2026-03-21 — ECC v1.9 "Selective Install, ECC Tools Pro, 12 Language Ecosystems". 호스티드 SaaS(ECC Tools Pro) 런칭. 12개 언어 ecosystem 패턴(Python·TypeScript·Go·Java·C++·Rust·Swift·Kotlin·Dart·PHP·Perl·C#).
• 2026-04-05 — ECC v1.10 "Surface Refresh, Operator Workflows, and ECC 2.0 Alpha". 운영자 워크플로 라이브러리가 합류 — 엔터프라이즈 vertical(healthcare·logistics·finance·customs) 스킬군. ecc2/ 디렉토리에 ECC 2.0 alpha가 들어옴.

ECC를 다른 셋과 같은 평면에 두고 볼 때 핵심 은 Affaan의 인센티브다. Superpowers의 Jesse Vincent는 솔로 메인테이너, GSD의 TÂCHES도 작은 팀, gstack의 Garry Tan은 YC 채용 lure가 있지만 도구 자체는 비상업. ECC는 처음부터 commercial 플랫폼을 가진 카테고리 진입자다. 호스티드 SaaS·GitHub App·티어 분리는 마케팅 부산물이 아니라 디자인 의도. 이 점이 §7.5의 비판적 독해 대목.

1.3. 장점

• 토큰 비용을 디폴트로 깎아준다. README가 권장하는 ~/.claude/settings.json 한 블록:
  • model: sonnet (디폴트 Opus → Sonnet, ~60% 비용 절감, 80%+ 코딩 작업 처리 가능)
  • MAX_THINKING_TOKENS: 10000 (디폴트 31,999 → 10,000, 숨겨진 사고 비용 ~70% 절감)
  • CLAUDE_AUTOCOMPACT_PCT_OVERRIDE: 50 (디폴트 95 → 50, 더 일찍 압축해 긴 세션 품질 유지) 이 세 설정만으로 대부분의 사용자가 의식 없이 지불하던 비용 표면이 줄어든다. 같은 카테고리 다른 셋은 모델 선택·thinking budget·autocompact 시점에 의견을 갖지 않는다 — Max plan 전제로 운영. ECC는 예산 의식이 첫 시민.
• 메모리가 세션 사이를 건너온다. hooks/memory-persistence/가 SessionStart 진입 시 이전 세션 요약·결정·차지를 자동 복원하고, Stop 단계에 세션 요약을 디스크에 적는다. GSD의 .planning/ 디스크 state와 비슷한 의도지만 훅 레벨에서 모든 워크플로에 디폴트 적용. Superpowers·gstack은 세션 안의 게이트와 페르소나에 의견을 갖고, 세션 간 연속성은 사용자 책임으로 남긴다.
• continuous-learning v2 — 신뢰도 점수가 있는 직관 기반 학습. 세션에서 반복되는 패턴을 자동 추출해 Instinct(직관)로 저장. 각 직관에는 신뢰도 점수가 붙고, /instinct-status로 확인·/instinct-import <file>로 다른 사람의 직관 가져오기·/instinct-export로 내 직관 내보내기·/evolve로 관련 직관을 재사용 가능한 스킬로 클러스터링. gstack의 /learn이 프로젝트별 누적 markdown이라면, ECC의 instinct는 세션 간 자동 추출 + 신뢰도 가중 + 스킬 승격 파이프라인. 카테고리 내 학습 메커니즘이 가장 자동화된 영역.
• AgentShield — 셋 중 유일한 통합 보안 스택. 별도 npm 패키지(ecc-agentshield)로 분리되어 있지만 ECC 본체와 통합. /security-scan이 CLAUDE.md·settings.json·MCP 설정·훅·에이전트 정의·스킬 6개 surface를 시크릿 감지(14 패턴)·권한 감사·훅 인젝션 분석·MCP 서버 위험 프로파일링·에이전트 설정 검토 5 카테고리로 스캔. --opus 플래그로 Claude Opus 4.6 에이전트 3개(redteam·blueteam·auditor)를 파이프라인으로 실행하는 디자인이 카테고리에서 보지 못한 정밀도.
• 10+ 하네스 분기 설치. Claude Code · Codex CLI · Cursor · OpenCode · Gemini · Kiro · Qwen · Trae · CodeBuddy · Antigravity. ./install.sh typescript처럼 언어 선택 + 하네스 선택이 한 커맨드. 모든 훅·스크립트가 크로스 플랫폼 Node.js로 작성 — Windows/macOS/Linux 모두.
• 운영자 워크플로 라이브러리. v1.10의 Operator Workflows. healthcare-cdss-patterns·hipaa-compliance·customs-trade-compliance·inventory-demand-planning·logistics-exception-management·returns-reverse-logistics·production-scheduling·email-ops·finance-billing-ops 등. 같은 카테고리 다른 셋은 개발자 워크플로만 다루고, 비개발 도메인의 운영자 작업에는 발도 안 들였다. ECC가 vertical에 진입한 첫 프레임.

1.4. 설치

2분 안에 셋업 완료(README 클레임):

1단계 — 플러그인 설치 (마켓플레이스 경로):

# Claude Code 안에서
/plugin marketplace add https://github.com/affaan-m/everything-claude-code
/plugin install ecc@ecc

2단계 — 룰 수동 설치 (필수):

# 플러그인 시스템이 rules 자동 배포를 지원하지 않으므로 수동
git clone https://github.com/affaan-m/everything-claude-code.git
cd everything-claude-code
./install.sh typescript    # 또는 python · golang · 여러 개 한꺼번에
# Cursor 타겟: ./install.sh --target cursor typescript

3단계 — 사용:

/ecc:plan "사용자 인증 추가"    # 마켓플레이스 모드
/plan "사용자 인증 추가"        # 수동 설치 시 짧은 형태
/plugin list ecc@ecc           # 설치 확인

Claude Code 최소 버전 v2.1.0 필요(훅 시스템 변경 의존). 주의: .claude-plugin/plugin.json에 "hooks" 필드를 추가하지 말 것 — Claude Code v2.1+는 설치된 플러그인의 hooks/hooks.json을 자동 로드하므로, 명시 선언 시 중복 감지 오류 발생.

선택적 컴포넌트 설치 — 플러그인 통째가 아니라 부분 설치가 가능하다는 점이 다른 셋과 결정적 차이:

cp everything-claude-code/agents/*.md ~/.claude/agents/    # 에이전트만
cp -r everything-claude-code/rules/common/* ~/.claude/rules/    # 룰만

각 컴포넌트가 완전히 독립적. Superpowers의 부트스트랩 훅이나 gstack의 CLAUDE.md 침투 같은 all-or-nothing 디자인이 아니다.

2. 작동 구조 — 하네스 성능의 5개 축

2.1. 토큰 최적화 축 — 모델·thinking·autocompact 디폴트

ECC의 settings.json 권장 블록이 첫 축. 같은 작업을 같은 품질로 60-70% 싸게 처리하도록 Claude Code의 디폴트 행동 자체를 갈아엎는다.

깊은 아키텍처 추론·디버깅·복잡한 디자인에만 /model opus로 임시 전환. 일상 워크플로는 Sonnet + 줄어든 thinking budget + 빠른 autocompact가 디폴트.

이 디자인이 카테고리 다른 셋과 결정적으로 다른 지점이다. GSD는 fresh 200k 컨텍스트 per phase를 본체 디자인으로 두므로 토큰 비용 표면이 무겁다(Issue #1553의 "Max plan 40분 소진"). gstack은 real browser·design-html·shotgun 등 자체 시스템 코드 부하가 추가됨. ECC만 Claude Code의 baseline cost를 디폴트로 낮춰주는 의견을 갖는다.

2.2. 메모리 영속 축 — SessionStart/Stop 훅

hooks/memory-persistence/가 두 trigger를 잡는다:

• SessionStart — 이전 세션의 요약·진행 중 결정·미완 작업을 자동으로 컨텍스트에 주입. /clear 또는 /compact 후에도 작동.
• Stop — 세션 종료 시 현재 상태를 markdown으로 디스크에 적는다. 명시적인 /save-session 슬래시도 별도 제공(commands/save-session.md, commands/resume-session.md).

이 디자인의 의미: 컨텍스트 윈도우는 휘발성이지만 워크 메모리는 영속적이라는 디자인 가정이 카테고리 다른 셋과 다른 지점. Superpowers는 세션 안의 게이트와 디시플린에 집중. gstack은 /learn으로 프로젝트별 markdown 학습을 누적하지만 세션 시작 시 자동 주입은 아니고 사용자 호출 기반. GSD는 .planning/ markdown state가 phase boundary에 흐른다 — 같은 디스크 기반 영속이지만 phase 단위이지 세션 라이프사이클 단위가 아니다.

ECC만 Claude Code의 session lifecycle 자체에 영속 메모리를 박는다. 이 대목에서 카테고리 내 ECC의 위치가 분명해진다.

2.3. 지속 학습 축 — Instinct v2

skills/continuous-learning-v2/. 디자인 한 줄: 반복되는 패턴을 자동 추출 → 신뢰도 점수 부여 → 스킬로 승격.

/instinct-status        # 학습된 직관과 신뢰도 확인
/instinct-import <file> # 다른 사람의 직관 가져오기
/instinct-export        # 내 직관 내보내기
/evolve                 # 관련 직관을 스킬로 클러스터링

Instinct가 다른 메커니즘과 다른 점:

• gstack /learn: 사용자가 명시적으로 패턴을 저장. markdown 누적, 신뢰도 점수 없음.
• GSD .planning/SUMMARY.md: phase boundary에 해당 phase의 요약을 자동 작성. 횡단 패턴 추출 없음.
• Superpowers: 학습 메커니즘 없음. 부트스트랩과 자가 호출 디시플린이 본체.
• ECC instinct: 세션 자체에서 자동 추출 + 신뢰도 점수 가중 + 직관 → 스킬 자동 승격 파이프라인 + import/export로 공유 가능.

/instinct-import로 다른 사용자의 직관을 가져온다는 디자인이 같은 카테고리에서 보지 못한 지점. 카탈로그·marketplace 정신과 결합되면 지식 자체가 자산이 되는 layer. 단 공유된 instinct의 quality control은 v2 시점 도구가 거의 없다 — 신뢰도 점수가 내 세션의 반복 패턴에서 나오는 것이라 다른 사람의 환경에 그대로 옮기면 신뢰도가 의미를 잃는다는 점은 의식해야 함.

2.4. 보안 축 — AgentShield 통합

§5에서 deep dive. 짧게: Claude Code 설정 자체의 보안 취약점을 스캔하는 것은 카테고리 내 ECC만 가지는 축. 1,282 테스트·102 룰·5 카테고리(시크릿 감지·권한 감사·훅 인젝션·MCP 위험·에이전트 설정)·--opus 3-agent redteam/blueteam/auditor 파이프라인.

2.5. 병렬 처리 축 — worktree·캐스케이드·인스턴스 확장

README가 별도 항목으로 명시: Git worktree, 캐스케이드 방식, 인스턴스 확장 시점. gstack의 parallel sprint via Conductor와 비슷한 대목이지만 ECC는 워크트리 자체에 의견을 갖는다(어떤 작업에 worktree를 띄울지·언제 캐스케이드할지·언제 인스턴스를 늘릴지 등의 판단 표). The Longform Guide의 한 챕터가 이 대목 통째로.

2.6. 5개 축의 상호작용

이 5개가 상호 의존한다는 점이 ECC의 디자인 가정 중 가장 미묘한 부분. 예:

• 토큰 최적화가 MAX_THINKING_TOKENS=10000을 권장 → autocompact=50과 결합하면 긴 세션에서 50% 압축 후 1만 토큰 사고로 재진입 → 메모리 영속 훅이 이전 세션 요약을 SessionStart에 주입 → Instinct가 그 요약에서 패턴 추출 → 다음 parallel worktree에 instinct가 전파됨.

즉 5개 축은 각자 독립적으로도 의미가 있지만, 함께 켜졌을 때만 ECC의 본체 디자인. 부분만 깔면 cherry-pick의 이점은 있지만 5축 사이 시너지는 사라진다. 같은 카테고리 다른 셋과는 다른 시스템적 결합도가 ECC의 특징.

3. 도드라지는 디자인

3.1. 실제 카탈로그 크기 — README와 main 브랜치의 격차

2026-05-14 main 브랜치 직접 확인:

README의 숫자는 v1.6(2026-02) 시점에 고정되어 있고, 그 이후 fix-wave 단위로 카탈로그가 확장 중이다. 1,900+ 머지 PR이 대부분 community contribution을 batch 머지한 흐름. 즉 ECC의 현재 표면적은 광고된 표면적의 ~3배. 사용자 입장에서 모든 스킬을 메모리에 둔 채 운영하기 어려운 규모에 이미 도달.

이 규모가 카테고리 내 ECC의 위치를 결정한다. Superpowers의 14 스킬, GSD의 86 명령(v1.41 기준), gstack의 30+ 명령과 비교하면 ECC의 표면적이 압도적으로 크다. 같은 카테고리에서 ECC는 가장 무거운 프레임이다.

3.2. 운영자 워크플로 라이브러리 — vertical 진입

v1.10 "Operator Workflows"로 합류한 스킬군. 개발자 워크플로가 아닌 비개발 도메인의 운영자 작업에 의견을 가진다:

• healthcare: healthcare-cdss-patterns·healthcare-emr-patterns·healthcare-eval-harness·healthcare-phi-compliance·hipaa-compliance·healthcare-reviewer
• logistics·trade: customs-trade-compliance·inventory-demand-planning·logistics-exception-management·production-scheduling·returns-reverse-logistics·quality-nonconformance
• finance·billing: finance-billing-ops·customer-billing-ops·carrier-relationship-management·energy-procurement
• operations ops: email-ops·messages-ops·automation-audit-ops·enterprise-agent-ops·google-workspace-ops·knowledge-ops·research-ops·terminal-ops·project-flow-ops·unified-notifications-ops
• homelab: homelab-network-readiness·homelab-pihole-dns·homelab-vlan-segmentation·homelab-wireguard-vpn·homelab-network-setup
• scientific: scientific-db-pubmed-database·scientific-db-uspto-database·scientific-pkg-gget·scientific-thinking-literature-review·scientific-thinking-scholar-evaluation

이 군집이 카테고리 다른 셋과의 결정적 차이. Superpowers/GSD/gstack은 코드 작업의 메타프레임. ECC는 non-coding 운영 작업에도 동등한 깊이로 들어간다 — 이는 Affaan의 인센티브가 enterprise vertical 마켓플레이스에 있다는 점과 일치한다. ECC Tools Pro/Enterprise 티어가 이 vertical 스킬군의 hosted 버전을 판다.

3.3. ECC Tools Pro와 호스티드 평면

ecc.tools는 ECC의 SaaS 친구. README 클레임:

"이 저장소는 코드만 포함하고 있습니다. 가이드에서 모든 것을 설명합니다."

핵심 동작이 오픈소스 본체와 호스티드 SaaS로 분리되어 있다는 신호. GitHub App 150+ install은 조직 도입의 신호 — 개인이 git clone하는 방식이 아니라 조직이 GitHub App을 install하는 모드. 무료/Pro/Enterprise 티어가 호스티드 기능(10k+ 커밋 분석·자동 PR·팀 공유)을 게이트한다.

오픈소스로 보면 ECC는 완전히 무료 MIT. 그러나 카탈로그 발견·자동 분석·팀 공유 기능은 호스티드 평면이 본체. 이 이중 평면이 카테고리 내 ECC의 상업적 정체성. Superpowers·GSD·gstack은 오픈소스 본체가 100% 본체다.

3.4. 8개 fix-wave 패턴 — 매일 머지 사이클

2026-05-13~14 commit log를 보면 하루에 10+개 commit가 머지된다. 패턴이 일정:

• Sync ECC Tools hosted ... — 호스티드 SaaS와의 sync
• docs: sync roadmap after AgentShield ... — AgentShield 작업 후 ECC repo로 reflect
• docs: sync roadmap after ECC-Tools ... — ECC Tools Pro와의 sync

즉 ECC main repo는 호스티드 SaaS·AgentShield·ECC Tools가 일으킨 변경의 reflection layer가 되어가고 있다. 본체 개발이 오픈소스 repo가 아닌 곳에서 일어나고 있다는 신호. 이는 long-term 안정성 위험인 동시에 호스티드 평면의 깊이를 보여주는 대목.

3.5. ECC 2.0 alpha — ecc2/ 디렉토리

v1.10에 같이 들어온 ecc2/가 다음 버전 본체. 코어 디자인이 변경 중. 현재 시점에서는 alpha라 운영 보장 없음. v1.10 release notes에 "Surface Refresh"라는 표현이 기존 표면을 재정의하는 작업이 진행 중임을 명시.

ECC 사용자라면 v1.x → v2 마이그레이션이 다음 1~2 분기 내 일어남을 의식해야 한다. 같은 카테고리에서 v2 alpha를 동시 운영하는 프레임은 ECC와 GSD(gsd-2 별도 repo) 둘.

4. 카탈로그 — agents · skills · commands

§3.1의 실측 숫자(60+ · 220+ · 75+)를 토대로, 카테고리 분류로 정리한다. (전체 나열은 생략 — 핵심 군집만.)

4.1. Agents 분류 (60+ 중 주요)

4.2. Skills 분류 (220+ 중 주요 군집)

4.3. Commands 분류 (75+ 중 주요)

/hookify 명령군은 훅 자체를 생성하는 메타 명령이다 — 사용자가 자기 워크플로에 맞는 훅을 ECC가 생성해주는 지점. 카테고리에서 보지 못한 디자인.

5. AgentShield deep dive

5.1. 카테고리 내 ECC만 가지는 자리

같은 카테고리 다른 셋이 코드 작업의 메타프레임에 머무를 때, ECC는 Claude Code 설정 자체의 보안 surface에 들어간다. AgentShield는 별도 npm ecc-agentshield로 publish되지만 ECC 본체와 통합. 카테고리 내 ECC만 가지는 디자인 영역.

5.2. 무엇을 스캔하나

5 카테고리·6 surface:

102 정적 분석 룰·1,282 테스트·98% 커버리지 — 카테고리 다른 셋의 어떤 도구도 이 정밀도에 도달하지 않았다.

5.3. --opus 플래그 — 3 에이전트 redteam/blueteam/auditor

"--opus 플래그는 레드팀/블루팀/감사관 파이프라인으로 3개의 Claude Opus 4.6 에이전트를 실행합니다. 공격자가 익스플로잇 체인을 찾고, 방어자가 보호 조치를 평가하며, 감사관이 양쪽의 결과를 종합하여 우선순위가 매겨진 위험 평가를 작성합니다." — README

이 디자인이 카테고리에서 보지 못한 지점. 세 페르소나가 동시에 같은 코드를 본다. 비용은 정직히 노출됨 — Opus 4.6 × 3 에이전트가 streaming으로 흐른다. README가 npx ecc-agentshield scan --opus --stream을 "3개의 Opus 4.6 에이전트로 정밀 분석"이라고 부른 대목.

5.4. GitHub Action 통합 — CI에 박는 게이트

- uses: affaan-m/agentshield@v1

GitHub Action으로 CI 파이프라인에 박을 수 있다. 카테고리 다른 셋은 로컬 개발자 도구 중심. ECC는 CI 자동화 surface에 진입한 첫 프레임. 조직 도입 시점에 이 surface가 governance와 가장 가까운 지점.

5.5. AgentShield ↔ 기존 보안 도구의 위치

AgentShield는 애플리케이션 코드의 취약점을 스캔하지 않는다 — SAST/DAST 도구(Snyk·Semgrep·Checkmarx)의 영역은 그대로. AgentShield의 자리는 Claude Code의 에이전트 설정 표면. 즉:

• SAST/DAST: 애플리케이션 코드의 OWASP·CVE 패턴
• AgentShield: 에이전트가 그 코드를 어떻게 다루는지의 설정

이 둘은 상호 보완이지 경쟁이 아니다. 조직이 AI 에이전트를 도입하면서 기존 보안 스택이 커버하지 못하는 새 surface에 ECC가 답을 만든 대목. 이 점이 Agent Governance 카테고리의 AWS Agent Registry와 같은 운동 — MCP 표준화 직후 등장한 거버넌스 레이어 — 의 일부로 ECC를 위치 짓는 이유.

6. Superpowers·GSD·gstack과 같이 쓸 때 어디서 깨지는지

아래는 셋을 동시에 깔아 직접 겪은 관찰이 아니라, 각자의 SessionStart 훅·README·정의 파일·공식 이슈를 읽고 충돌이 구조적으로 필연인 지점만 짚은 것이다.

6.1. SessionStart 훅 4중 주입

ECC·Superpowers·GSD·gstack 모두 SessionStart 훅을 박는다. 셋 동시 설치도 §6.1(GSD 글)에서 3중 비결정이라고 정리됐고, ECC를 추가하면 4중 비결정:

• Superpowers <EXTREMELY_IMPORTANT> 부트스트랩
• GSD gsd-update-banner.js
• gstack team-mode auto-update banner
• ECC hooks/memory-persistence/ SessionStart + hooks.json의 다른 매처들

Claude Code 매뉴얼은 identical handler만 dedup된다고 명시 — 네 프레임이 각자 다른 명령으로 등록되므로 모두 컨텍스트에 주입된다. 대응: 메인 프레임 하나만 글로벌, 나머지는 프로젝트 단위 .claude/settings.local.json opt-in.

6.2. ECC의 광대한 description 매칭 vs 다른 셋의 process 게이트

ECC는 220+ skills + 60+ agents + 75+ commands. 각각이 description 매칭으로 자동 호출될 수 있다. 사용자 발화에 복수의 ECC 스킬이 매칭되면 모델이 어떤 걸 부를지 ECC 내부에서 정해야 한다.

Superpowers는 brainstorming HARD-GATE가 코드 변경 발화에 먼저 트리거. gstack은 명시적 슬래시 호출 위주. GSD는 phase 시작 명령이 명시적.

ECC + Superpowers 동시 설치 시: Superpowers의 brainstorming description("You MUST use this before any creative work")이 발동하기 전에 ECC의 vertical skill(예: feature-dev 스킬)이 매칭될 수 있다. 즉 ECC의 description-rich 카탈로그가 Superpowers의 process 게이트를 우회할 수 있는 지점.

대응: Superpowers와 ECC를 같이 쓸 때, ECC의 작업-단계 스킬(plan·feature-dev·tdd 등)은 Superpowers의 등가 스킬(writing-plans·brainstorming·test-driven-development)이 우선 호출되도록 AGENTS.md에 명시. ECC의 vertical 스킬(healthcare·logistics 등)은 Superpowers가 못 다루는 영역이므로 충돌 없음.

6.3. 메모리 영속 vs GSD의 fresh-context

ECC의 SessionStart 메모리 주입과 GSD의 fresh 200k subagent context는 디자인 가정이 직교한다:

• ECC: 컨텍스트는 비싸므로 이전 세션의 압축 요약을 새 세션에 주입해 연속성을 확보
• GSD: 컨텍스트가 차오를수록 품질이 저하되므로 매 phase 새 fresh 200k를 띄워 오염 차단

두 가정이 한 환경에 있으면: GSD subagent는 fresh context로 시작하므로 ECC의 memory-persistence 훅이 주입한 메시지를 못 본다. 반대로 메인 세션에 ECC가 주입한 이전 세션 요약이 있을 때 GSD /gsd-execute-phase가 dispatch한 executor는 그 요약을 무시한다 — 디자인 의도대로.

대응: 둘을 같이 쓰면 layer 분리 — ECC의 memory-persistence는 메인 세션의 연속성에만 적용된다고 명시. GSD subagent에는 기대하지 않는다. 또는 어느 한쪽만.

6.4. AgentShield와 다른 프레임의 설정 충돌

AgentShield가 Claude Code 설정의 보안 취약점을 스캔하는데, 다른 메타프레임이 만든 설정도 같이 스캔 대상. 예:

• gstack이 ~/.claude/CLAUDE.md에 gstack 섹션을 박아넣으면 AgentShield가 그 섹션의 권한 패턴을 스캔. 충돌 가능.
• Superpowers의 SessionStart 훅이 부트스트랩 메시지를 컨텍스트에 주입하면 AgentShield가 훅 인젝션 분석 카테고리에서 평가.
• GSD의 --dangerously-skip-permissions 권고를 ECC가 적용해 settings.json에 박았다면, AgentShield가 과도 권한 경고를 띄울 수 있다.

대응: 다중 프레임 환경에서 AgentShield 실행 시 false positive를 의식. v1.10 시점 AgentShield는 셀프 검사 모드만 있고 다른 프레임의 의도된 설정을 whitelist하는 메커니즘은 미완성. 운영 시 의식적 검토 필요.

6.5. ECC의 description 풍부도 vs gstack의 top-level 슬래시 점유

gstack은 /review·/ship·/qa 같은 top-level 슬래시를 점유. ECC도 /code-review·/pr·/tdd 같은 top-level 슬래시를 다수 가진다. 둘이 같이 깔리면 슬래시 이름 충돌은 적지만(접두사가 달라서), description 매칭은 겹친다. 예:

• gstack /review description: "Find the bugs that pass CI but blow up in production."
• ECC /code-review description: "코드 품질·보안·유지보수성을 리뷰합니다."

사용자가 "리뷰 돌려줘"라고 하면 둘 다 매칭 가능. 어느 게 호출될지 비결정.

대응: 글로벌 AGENTS.md에 우선순위를 명시("코드 리뷰는 gstack /review 우선, ECC /code-review는 보조"). 또는 역할 명확화로 운영(gstack 슬래시는 production bug, ECC 슬래시는 vertical 작업).

6.6. 충돌 표면 요약

네 프레임이 카테고리 안에서 각자 다른 표면을 점유한다는 점이 명확해진다. ECC의 자리는 Claude Code의 실행 환경 자체 + 비개발 도메인 + 상업 평면이라는 3중 확장. 같은 카테고리 다른 셋과 결합 가능성보다 동시 운영 시 충돌 표면이 더 많은 자리.

7. 한계와 trade-off

7.1. 카탈로그가 광고된 표면적의 ~3배 — 학습 부담

§3.1의 격차 — 16/65/40 광고 vs 60+/220+/75+ 실측. ECC를 통째로 install하면 Claude Code의 시스템 프롬프트 표면이 카테고리에서 가장 무거워진다. 선택적 install(rules만·agents만·특정 스킬만)이 사실상 권장 경로. 하지만 선택적 install이 5축 시너지를 깎는다는 §2.6의 trade-off가 그대로 따라온다.

7.2. README 숫자의 retroactive 불일치

ECC v1.6 시점에 박힌 "16 agents, 65 skills, 40 commands" 가 v1.10 + 2026 Q2 fix-wave 후에도 README에 그대로 남아있다. 마케팅 일관성과 실제 표면의 갭이 카테고리에서 가장 큰 자리. 사용자 입장에서는 공식 문서의 숫자를 의심해야 한다 — 직접 ls가 정답.

7.3. ECC 2.0 alpha — 마이그레이션 리스크

§3.5에서 다룬 ecc2/. v1.x → v2 마이그레이션 path가 명시되지 않은 시점. production 도입 시 v1.x로 frozen 권장. v2 메이저 디자인 변경이 기존 5축과 어디서 충돌할지 불명확. 카테고리 내 GSD도 gsd-2 별도 repo가 있지만 명시적 v1/v2 분리인 반면 ECC는 같은 repo 안의 ecc2/라 경계가 모호하다.

7.4. 상업 평면의 인센티브 — 호스티드 평면 깊이

§3.3에서 다룬 ECC Tools Pro/Enterprise. 오픈소스 본체는 완전히 무료 MIT이지만 호스티드 평면이 본체로 성장 중. 다음 1~2 분기에 오픈소스 본체에서 일부 기능이 호스티드로만 이동할 가능성을 의식해야 함. 같은 카테고리 다른 셋은 commercial 평면이 없으므로 이런 리스크가 없다.

7.5. fix-wave dependency — sync commit 비중

§3.4에서 본 매일 10+ commit이 호스티드 SaaS와의 sync. ECC repo가 호스티드 SaaS의 reflection layer에 가까워지면, 오픈소스 본체의 stand-alone usability가 약해질 위험. 사용자가 호스티드 평면 없이 ECC 본체만으로 어디까지 갈 수 있는지가 시간이 지날수록 불분명해질 수 있다.

7.6. Vertical 스킬의 quality control

§3.2의 운영자 워크플로 라이브러리. healthcare·logistics·finance 같은 규제 도메인의 스킬을 ECC가 ship한다는 점은 주의 깊게 봐야 한다. hipaa-compliance·customs-trade-compliance 같은 스킬이 실제 규제 요구를 정확히 반영하는지의 quality control은 Affaan 1인 + 커뮤니티 PR 모드. 프로덕션 도입 시 도메인 전문가 검토 필수 — ECC 자체의 클레임을 그대로 받아들이면 안 된다.

7.7. instinct 공유의 quality 문제

§2.3에서 다룬 /instinct-import. 다른 사용자의 직관을 가져올 수 있다는 디자인이 quality 검증 메커니즘 없이 운영되는 시점. 내 환경의 신뢰도 점수는 나의 반복 패턴에서 나온 것인데, 다른 사람의 instinct는 그 사람의 반복에서 나온 것 — 내 환경에서 같은 신뢰도가 정당화되지 않는다. 카테고리에서 지식 공유 메커니즘이 가장 야심차지만 quality control은 가장 얇은 자리.

8. 종합 — ECC는 "하네스 성능"의 프레임워크다 (그리고 그 이상)

세 줄로 줄이면:

1. process 의견도, environment 의견도, role 의견도 아닌 harness 의견. Superpowers는 어떻게 일할지, GSD는 어디서 일할지, gstack은 누가 일할지를 강제. ECC는 Claude Code 자체를 어떻게 굴릴지에 의견을 가진다 — 토큰 디폴트·메모리 영속·instinct 학습·보안 스캔·병렬 처리의 5축이 하네스 baseline을 갈아엎는다. 같은 카테고리 셋과의 결정적 차이.
2. 셋 중 유일하게 상업 플랫폼 평면을 가진다. 호스티드 SaaS(ECC Tools Pro), GitHub App(150+ install), npm 2개, 무료/Pro/Enterprise 마켓플레이스 티어, 비개발 vertical 스킬군까지. 같은 카테고리 다른 셋의 비상업 정체성과 ECC의 commercial 정체성은 디자인 의도 자체의 차이. Affaan의 인센티브가 enterprise vertical과 호스티드 평면 성장에 있다는 점은 마케팅 부산물이 아니라 디자인 의도다.
3. 표면적이 카테고리에서 가장 크다 — 광고된 숫자의 ~3배. 60+ agents · 220+ skills · 75+ commands. README의 v1.6 시점 숫자(16/65/40)가 retroactively 일관되게 유지되지 않는다는 점이 상업 마케팅과 오픈소스 본체의 갭을 보여준다. 사용자는 선택적 install이 사실상 권장이고, 통째 install은 카테고리에서 가장 무거운 자리.

운영 결론: 하네스 baseline을 다듬고 vertical 스킬군이 필요한 환경(엔터프라이즈 도입·다언어 ecosystem 동시 운영·CI 자동화 surface까지 박는 조직)에서 ECC는 셋 중 가장 적합. 개인 사용자가 단일 워크플로 디시플린만 원하는 경우에는 Superpowers·gstack 단독이 더 가볍다. Superpowers·GSD·gstack과 같이 쓸 때: §6의 5가지 충돌 표면 — 특히 SessionStart 4중 주입과 ECC의 description-rich 카탈로그가 다른 프레임의 process 게이트를 우회하는 자리, 메모리 모델 직교, AgentShield의 false positive — 에서 부딪친다. 외부 결합 가이드들이 layer 시퀀스 분리를 권하는 이유.

한 줄 추천 — Claude Code의 baseline을 의식하기 시작했다면 ECC를 켜라. 토큰 비용에 의식 없이 지불하던 사용자, 세션 간 연속성이 끊겨 매번 컨텍스트를 재구축하던 사용자, AI 에이전트가 자기 설정 자체의 보안 취약점을 가지는지 의식하기 시작한 조직에게 ECC는 카테고리에서 가장 직접적인 답이다. 5축 통째가 부담이라면 cp -r everything-claude-code/rules/common/* ~/.claude/rules/ 한 줄로 공통 룰만 깔고 시작할 수 있다. vertical은 필요한 도메인만 cherry-pick. 호스티드 평면은 조직 도입 시점에 고려. AgentShield는 카테고리 다른 셋을 깔든 안 깔든 npx ecc-agentshield scan 한 번은 가치 있는 자리 — 카테고리 내 ECC만 가지는 자리이므로.

참고

공식 1차

• affaan-m/everything-claude-code — v1.10 stable, 181.6k★(2026-05-14 기준)
• README.md (en) · README.md (ko-KR)
• The Longform Guide — 토큰 최적화·메모리 영속·평가·병렬 처리 deep dive
• The Shortform Guide — 설정·기초·철학 입문
• The Security Guide — AgentShield 운영 가이드
• CHANGELOG.md — v1.0 → v1.10 timeline
• Release notes — v1.5 Universal, v1.8 Harness Performance, v1.10 ECC 2.0 Alpha

분리된 commercial 평면

• ECC Tools (ecc.tools) — 호스티드 SaaS
• GitHub Marketplace — ecc-tools — GitHub App (150+ install)
• npm — ecc-universal
• npm — ecc-agentshield
• affaan-m/agentshield — AgentShield 별도 repo (GitHub Action 포함)

창시자

• Affaan Mustafa / @affaanmustafa
• zenith.chat — AI 채팅 인터페이스 스타트업
• Cerebral Valley × Anthropic Hackathon, 2026-02 — AgentShield 우승작

시리즈 내 다른 글

• Agent Framework 카테고리 개요 — Superpowers · GSD · gstack · ECC 네 프레임의 위치
• Superpowers — 프로세스 게이트 축
• GSD — 맥락 분리 축
• gstack — 역할 분담 축
• Agent Governance — AWS Agent Registry — MCP 표준화 직후 등장한 거버넌스 레이어(AgentShield와 같은 운동)