Everything Claude Code 해부: 설정 모음이 아니라 에이전트 하니스 시스템인 이유

everything-claude-code를 처음 보면 거대한 설정 저장소처럼 보입니다. 하지만 README가 이 저장소를 설명하는 방식은 다릅니다. 이 프로젝트는 “AI agent harnesses를 위한 performance optimization system"이며, 단순한 설정 묶음이 아니라 스킬, 훅, 메모리 최적화, 연속 학습, 보안 스캐닝, 리서치 우선 개발 방식을 함께 담은 운영 체계에 가깝습니다.

조금 더 정확히 말하면, 이 저장소의 핵심 가치는 좋은 프롬프트 몇 개가 아니라 명령 -> 스킬 -> 전문 에이전트 -> 훅 -> 검증 -> 세션 메모리로 이어지는 실행 루프를 한 덩어리로 제공한다는 데 있습니다. Claude Code뿐 아니라 Codex, Cursor, OpenCode 같은 다른 하니스까지 염두에 두고 구조를 맞춘 점도 이 저장소를 흥미롭게 만듭니다.

Sources

https://github.com/affaan-m/everything-claude-code

왜 이 저장소를 “설정 팩"으로 보면 놓치는가

README는 이 프로젝트를 “raw code only"라고 부르면서, 실제 사용법은 shorthand guide와 longform guide에서 설명한다고 못 박습니다. 즉 이 저장소의 본체는 파일 수가 많은 리포지토리 자체가 아니라, 그 파일들이 어떤 실행 모델로 연결되는지에 대한 설계입니다.

여기서 중요한 변화가 v1.9.0의 selective install architecture입니다. README에 따르면 이 버전은 install-plan.js와 install-apply.js를 중심으로 한 manifest-driven 설치 파이프라인을 도입했고, state store를 통해 무엇이 설치되었는지 추적하면서 점진적으로 업데이트할 수 있게 바꿨습니다. 이 말은 “전부 다 복사해 넣는 설정 팩"이 아니라 “필요한 구성요소만 선택적으로 조립하는 하니스"로 방향을 명확히 잡았다는 뜻입니다.

또한 package.json은 이 패키지를 ecc-universal로 정의하고, ecc와 ecc-install이라는 실행 진입점을 제공합니다. 같은 파일과 README의 디렉터리 구조를 보면 이 저장소에는 .claude, .codex, .cursor, .opencode용 자산이 함께 들어 있고, 그 아래에 agents, skills, commands, rules, hooks, scripts, contexts, mcp-configs가 레이어처럼 배치되어 있습니다. 저장소를 읽을 때 파일 하나하나를 보는 것보다 이 레이어 구조를 먼저 보는 편이 훨씬 이해가 빠릅니다.

flowchart TD
    deploy["배포 레이어
plugin + installer + manifests"] --> execution["실행 레이어
commands + skills + agents"]
    execution --> guardrails["가드레일 레이어
rules + hooks"]
    guardrails --> integration["통합 레이어
CLI + MCP + Node.js scripts"]
    integration --> memory["지속성 레이어
state store + session files + learning"]

    classDef layerDeploy fill:#c5dcef,color:#333,stroke:#6f9fbe,stroke-width:1px;
    classDef layerRun fill:#c0ecd3,color:#333,stroke:#75b48e,stroke-width:1px;
    classDef layerGuard fill:#fde8c0,color:#333,stroke:#d0b070,stroke-width:1px;
    classDef layerIntegration fill:#e0c8ef,color:#333,stroke:#a58cbb,stroke-width:1px;
    classDef layerMemory fill:#ffc8c4,color:#333,stroke:#cf8f8a,stroke-width:1px;

    class deploy layerDeploy;
    class execution layerRun;
    class guardrails layerGuard;
    class integration layerIntegration;
    class memory layerMemory;

이 관점에서 보면 “28 agents, 116 skills, 59 commands"라는 숫자도 단순한 규모 자랑이 아닙니다. 저장소가 지향하는 것은 거대한 범용 프롬프트 한 장이 아니라, 역할이 나뉜 작은 실행 단위를 조합해 하니스를 운영하는 방식입니다.

실행 레이어: Skills, Commands, Rules, Hooks, Agents

shortform guide는 skills를 “특정 범위와 워크플로우에 묶인 shorthand prompts"로 설명하고, commands는 그 skills를 slash command로 빠르게 실행하는 형태라고 구분합니다. 즉 명령은 진입점이고, skill은 작업 절차이며, agent는 그 절차를 수행할 역할 분리 단위입니다.

여기에 rules와 hooks가 붙으면서 구조가 훨씬 강해집니다. rules는 항상 따라야 하는 원칙을 모듈화한 계층입니다. 예를 들어 coding style, testing, git workflow, security, performance, agents 같은 규칙이 언어 공통 영역에 있고, 언어별 세부 규칙은 별도 디렉터리로 분리됩니다. AGENTS.md도 같은 방향을 보여 주는데, Agent-First, Test-Driven, Security-First, Plan Before Execute 같은 원칙을 맨 위에 두고 어떤 상황에서 어떤 전문 에이전트를 써야 하는지 명시합니다.

hooks는 여기서 자동화를 담당합니다. shortform guide가 설명하듯 PreToolUse, PostToolUse, UserPromptSubmit, Stop, PreCompact, Notification 같은 라이프사이클 이벤트에 맞춰 자동 동작을 걸 수 있습니다. README는 최근 버전에서 이 훅들을 Node.js 스크립트 기반으로 다시 정리했고, ECC_HOOK_PROFILE이나 ECC_DISABLED_HOOKS 같은 런타임 제어 플래그도 제공한다고 설명합니다. 즉 이 저장소는 프롬프트 레이어만 설계한 것이 아니라, 실행 전후의 검증과 피드백까지 코드화한 것입니다.

flowchart TD
    request["사용자 요청"] --> entry["명령 또는 스킬 선택"]
    entry --> specialist["전문 서브에이전트 위임"]
    entry --> rules["항상 적용 규칙"]
    specialist --> tools["CLI / 파일 편집 / MCP 호출"]
    rules --> tools
    tools --> post["PostToolUse / 검증 훅"]
    post --> result["결과 반환 또는 수정 루프"]

    classDef inputNode fill:#c5dcef,color:#333,stroke:#6f9fbe,stroke-width:1px;
    classDef processNode fill:#c0ecd3,color:#333,stroke:#75b48e,stroke-width:1px;
    classDef ruleNode fill:#fde8c0,color:#333,stroke:#d0b070,stroke-width:1px;
    classDef outputNode fill:#ffc8c4,color:#333,stroke:#cf8f8a,stroke-width:1px;

    class request inputNode;
    class entry,specialist,tools,post processNode;
    class rules ruleNode;
    class result outputNode;

이 구조를 이해하면 왜 저장소 안에 planner, architect, tdd-guide, code-reviewer, security-reviewer, build-error-resolver 같은 역할별 에이전트가 많은지도 자연스럽게 보입니다. 저자는 하나의 메인 에이전트가 모든 문맥을 다 짊어지는 구조보다, 목적이 좁은 전문 에이전트에게 필요한 범위만 위임하는 방식을 기본값으로 둡니다.

메모리 지속성과 연속 학습이 진짜 차별점이다

longform guide에서 가장 인상적인 부분은 메모리를 “대화 기록"이 아니라 “재주입 가능한 작업 상태"로 취급한다는 점입니다. 저자는 세션이 끝날 때 현재 상태를 요약한 파일을 남기고, 다음 세션에서 그 파일 경로를 다시 주어 이어서 일하는 방식을 설명합니다. 그 파일에는 무엇이 검증되었는지, 무엇을 시도했지만 실패했는지, 무엇이 아직 남았는지가 들어가야 한다고 합니다.

더 나아가 longform guide는 잘 알려지지 않은 훅 조합으로 이를 자동화합니다. PreCompact 훅은 컨텍스트 압축 전에 중요한 상태를 저장하고, Stop 훅은 세션 종료 시 학습 내용을 남기며, SessionStart 훅은 다음 세션에서 이전 상태를 불러옵니다. README가 hooks/memory-persistence를 별도 구성요소로 갖고 있는 이유도 여기에 있습니다.

연속 학습 방식도 비슷한 철학을 가집니다. 반복해서 마주치는 비사소한 패턴이 있으면 그걸 새 스킬로 승격하라는 것입니다. longform guide는 continuous-learning 스킬이 이런 발견을 세션 종료 시점에 정리해 다음 번에는 자동으로 불러올 수 있게 만든다고 설명합니다. 특히 Stop 훅을 쓰는 이유를 별도로 강조하는데, UserPromptSubmit은 모든 메시지마다 실행되어 지연을 늘리지만 Stop은 세션 끝에 한 번만 돌기 때문에 훨씬 가볍다는 판단입니다.

flowchart TD
    session["현재 세션"] --> compact["PreCompact
중요 상태 저장"]
    session --> stop["Stop
세션 종료 요약"]
    compact --> notes["worked / failed / next steps 파일"]
    stop --> notes
    notes --> start["SessionStart
다음 세션 복원"]
    start --> learning["continuous-learning
패턴 추출"]
    learning --> reusable["새 스킬 / instinct 축적"]
    reusable --> session

    classDef stateNode fill:#c5dcef,color:#333,stroke:#6f9fbe,stroke-width:1px;
    classDef hookNode fill:#fde8c0,color:#333,stroke:#d0b070,stroke-width:1px;
    classDef memoryNode fill:#e0c8ef,color:#333,stroke:#a58cbb,stroke-width:1px;
    classDef learnNode fill:#c0ecd3,color:#333,stroke:#75b48e,stroke-width:1px;

      class session stateNode
      class compact,stop,start hookNode
      class notes memoryNode
      class learning,reusable learnNode

이 설계는 단순히 “메모리를 오래 유지한다"는 이야기와 다릅니다. 중요한 것은 어떤 정보를 언제 저장하고, 어떤 권한으로 다시 불러오며, 반복되는 실패나 우회법을 어떻게 재사용 가능한 실행 자산으로 바꿀 것인가입니다. Everything Claude Code는 바로 이 부분을 스킬과 훅의 결합으로 구체화합니다.

토큰 최적화와 병렬화는 많이 돌리는 것이 아니라 잘 나누는 것이다

이 저장소의 longform guide는 MCP를 항상 많이 붙이는 방식에 비판적입니다. GitHub, Supabase, Vercel, Railway 같은 서비스는 MCP가 편리한 래퍼일 수는 있지만, 어떤 경우에는 CLI를 skill이나 command로 감싼 쪽이 컨텍스트와 토큰 측면에서 더 효율적일 수 있다고 설명합니다. 이 관점은 “연결을 늘리는 것"보다 “항상 켜 둘 연결과 필요할 때만 불러올 연결을 구분하는 것"에 가깝습니다.

모델 라우팅도 같은 철학입니다. longform guide는 탐색이나 단순 편집은 더 저렴한 모델에 맡기고, 다중 파일 구현은 중간급 모델, 복잡한 아키텍처 결정이나 보안 분석은 최고급 모델로 올리는 식의 서브에이전트 아키텍처를 제안합니다. 여기서 핵심은 최고 성능 모델 하나를 늘 켜 두는 것이 아니라, 작업 성격에 맞춰 가장 싼 충분조건을 고르는 것입니다.

검증 전략도 분리되어 있습니다. guide는 checkpoint-based evals와 continuous evals를 나누어 설명합니다. 전자는 특정 단계마다 기준을 맞췄는지 확인하고 넘어가는 방식이고, 후자는 일정 시간이나 큰 변경마다 테스트와 린트를 계속 돌리는 방식입니다. 즉 Everything Claude Code는 “잘 만들기"와 “계속 검증하기"를 별도 레이어로 다룹니다.

병렬화 역시 무조건 인스턴스를 많이 띄우는 방향이 아닙니다. 저자는 최소한의 병렬화로 최대 효과를 얻는 것을 목표로 삼고, 코드 변경이 겹치지 않도록 범위를 잘 나누라고 조언합니다. 연구와 질문용 포크를 따로 두고, 실제 코드 변경이 병렬로 필요해질 때만 git worktree를 사용하며, 동시에 다루는 세션 수도 3~4개 수준으로 제한하는 cascade 패턴을 추천합니다.

flowchart TD
    task["작업 특성 판단"] --> enough{"한 세션으로 충분한가"}
    enough -->|예| single["단일 오케스트레이터로 진행"]
    enough -->|아니오| split{"연구와 코드 변경을 분리할 수 있는가"}
    split -->|예| fork["질문 / 리서치용 포크 추가"]
    split -->|아니오| worktree["git worktree로 코드 범위 분리"]
    fork --> cascade["cascade 방식으로 좌에서 우로 관리"]
    worktree --> cascade
    cascade --> limit["동시 세션 수는 3~4개 수준 유지"]

    classDef decisionNode fill:#fde8c0,color:#333,stroke:#d0b070,stroke-width:1px;
    classDef actionNode fill:#c0ecd3,color:#333,stroke:#75b48e,stroke-width:1px;
    classDef resultNode fill:#c5dcef,color:#333,stroke:#6f9fbe,stroke-width:1px;

    class enough,split decisionNode;
    class single,fork,worktree,cascade actionNode;
    class task,limit resultNode;

정리하면, Everything Claude Code의 토큰 전략은 “무엇을 빼야 하는가"와 “무엇을 위임해야 하는가"에 더 가깝고, 병렬화 전략은 “몇 개를 동시에 돌릴 것인가"보다 “겹치지 않게 어떻게 쪼갤 것인가"에 가깝습니다.

실전 적용 포인트

이 저장소를 그대로 베끼기보다, 먼저 rules와 hooks만 좁은 범위로 도입하는 편이 좋습니다. 저자도 selective install과 언어별 rules 구조를 통해 필요한 것만 선택적으로 설치하는 방향을 강화했습니다.
skills는 문서가 아니라 재실행 가능한 운영 절차로 다뤄야 합니다. 반복적으로 쓰는 조사, 리뷰, 테스트, 보안 점검 흐름부터 skill로 굳히는 것이 효과적입니다.
session memory는 “오늘의 요약"이 아니라 “다음 세션이 바로 이어서 실행할 수 있는 상태 파일"이어야 합니다. worked, failed, next steps를 분리하라는 longform guide의 기준이 실용적입니다.
continuous learning을 붙일 때는 세션마다 느려지지 않도록 Stop 시점에 모으는 방식이 합리적입니다. guide가 Stop 훅을 선호하는 이유도 바로 여기에 있습니다.
병렬화는 마지막 단계에서 도입하는 편이 낫습니다. 처음부터 여러 인스턴스를 띄우기보다, 하나의 오케스트레이터와 하나의 리서치 인스턴스로 시작하고 worktree는 충돌 없는 범위 분리가 필요할 때만 쓰는 편이 안전합니다.

핵심 요약

Everything Claude Code는 거대한 프롬프트 저장소가 아니라 설치 -> 실행 -> 가드레일 -> 통합 -> 메모리가 연결된 에이전트 하니스 시스템으로 읽어야 합니다.
이 저장소의 핵심 단위는 skills, commands, agents, rules, hooks이며, 각각이 역할 분리를 통해 메인 에이전트의 부담을 줄이도록 설계되어 있습니다.
longform guide의 핵심 가치는 메모리 지속성, 연속 학습, 검증 루프, 최소 병렬화 같은 운영 원칙을 실제 파일 구조와 훅으로 연결했다는 점입니다.
따라서 이 프로젝트를 참고할 때는 모든 파일을 복제하는 것보다, 자신의 작업 환경에 맞는 최소 레이어를 골라 하니스로 조립하는 접근이 더 적절합니다.

결론

Everything Claude Code가 흥미로운 이유는 Claude Code를 더 똑똑하게 만드는 비법을 숨겨 둔 저장소라서가 아닙니다. 오히려 그 반대입니다. 좋은 에이전트 경험은 단일 프롬프트의 마법이 아니라, 역할 분리된 실행 단위와 자동 검증, 세션 메모리, 선택적 통합을 어떻게 엮느냐에 달려 있다는 점을 아주 노골적으로 보여 줍니다.

Claude Code, Codex, Cursor 같은 도구를 이미 쓰고 있다면 이 저장소에서 가장 먼저 배워야 할 것은 특정 명령어가 아니라 운영 모델입니다. 그리고 그 운영 모델의 요지는 단순합니다. 컨텍스트는 줄이고, 역할은 나누고, 학습은 누적하고, 검증은 자동화하라는 것입니다.