Claude Code로 만든 프로젝트: ECC는 어떻게 GitHub 스타 253K를 찍었나

대부분의 "Claude Code로 만들었다" 스토리는 출시 트윗 하나와 수백 개의 스타에서 끝납니다. ECC — 원래 "Everything Claude Code"라는 이름의 해커톤 프로젝트를 줄인 것 — 는 그 지점을 훌쩍 넘어섰습니다.

이번 주 기준 GitHub 전체 일간 트렌딩 페이지 #6에 올라 있고, 하루 만에 1,897개의 스타를 얻었으며, 저장소는 GitHub 트렌딩 페이지와 저장소 자체 기준으로 총 약 253,000개의 스타와 37,900개의 포크를 기록하고 있습니다. 이 거의 모든 것 뒤에 있는 계정은 단 한 명입니다.

ECC는 정확히 무엇인가

ECC는 GitHub 저장소 설명에서 스스로를 "the agent harness performance optimization system"(에이전트 하네스 성능 최적화 시스템)이라고 소개합니다 — Claude Code, Codex, Cursor, OpenCode 같은 AI 코딩 에이전트 위에 얹히는 레이어로, 자체 README에 따르면 "a coordinated engineering system and toolbox: it plans before it builds, verifies changes with tests, reviews its own work from a fresh context, remembers what matters, and turns repeated wins into reusable skills and workflows"(빌드하기 전에 계획하고, 테스트로 변경 사항을 검증하고, 새로운 컨텍스트에서 자신의 작업을 리뷰하고, 중요한 것을 기억하고, 반복되는 성공을 재사용 가능한 스킬과 워크플로우로 바꾸는 조율된 엔지니어링 시스템이자 툴박스)를 제공합니다. 구체적으로는 "68 agents, 286 skills, and 94 legacy command shims, plus hooks, rules, memory, continuous learning, and AgentShield security scanning"(에이전트 68개, 스킬 286개, 레거시 커맨드 심 94개, 그리고 훅·규칙·메모리·지속 학습·AgentShield 보안 스캐닝)으로 패키징되어 있으며, 개발자가 이미 쓰고 있는 코딩 에이전트 위에 플러그인이나 npm 패키지 형태로 설치합니다.

이건 Claude Code를 다시 만든 게 아닙니다. 오히려 기존 에이전트에게 무엇을 만들지가 아니라 어떻게 일할지 — 먼저 계획하고, 테스트를 쓰고, 작업을 끝냈다고 선언하기 전에 자신의 diff를 리뷰하라 — 를 지시하는, 주관이 뚜렷한 운영 레이어에 가깝습니다. 첫 워크플로우를 출시한 뒤 에이전트가 후속 작업을 실제로 얼마나 스스로 끝내는지 측정하는 것과 같은 본능에서 나온 접근입니다.

출발점: 주말 해커톤에서 Claude Code로 만들다

진지하게 봐야 할 부분은 이 프로젝트가 어디서 시작됐느냐입니다. ECC 자체 README는 보안 스캐닝 모듈의 출처로 특정 이벤트를 명시합니다: "Built at the Claude Code Hackathon (Cerebral Valley x Anthropic, Feb 2026). 1282 tests, 98% coverage, 102 static analysis rules."(Claude Code 해커톤에서 만들어짐 — Cerebral Valley x Anthropic, 2026년 2월. 테스트 1,282개, 커버리지 98%, 정적 분석 규칙 102개.) 같은 해커톤 출처가 독립된 AgentShield 저장소에서도 별도로 등장합니다 — ECC의 보안 스캐닝이 기반으로 삼고 있는, 같은 계정이 만든 별도의 MIT 라이선스 프로젝트입니다. 저장소 두 개, 저자 한 명, 같은 출발점 이야기가 두 번 등장하는 셈입니다.

저장소의 원래 이름도 이야기뿐 아니라 구조적으로도 이를 뒷받침합니다: 예전 URL인 affaan-m/everything-claude-code는 지금도 연결되며 — 저장소 이름이 바뀌었을 때 GitHub가 보이는 표준 동작대로, 현재의 affaan-m/ECC 저장소로 이어집니다. "everything Claude Code"로 시작한 툴이 Codex, Cursor, Gemini 등 다른 에이전트 하네스까지 지원하기 시작하면서 원래 이름이 감당하지 못할 만큼 커졌고, 약자만 남았습니다.

숫자들, 그리고 그 출처

여기 나오는 정량적인 수치는 전부 GitHub 자체에서 누구나 직접 셀 수 있는 것들입니다. 저희가 다룬 Aider의 본인 발표 기준 설치 수·토큰 지표가 넘지 못했던 기준보다 더 높은 기준입니다 — 이 ECC 수치들은 메인테이너가 직접 써넣은 뱃지가 아니라, 저장소 페이지에서 직접 확인한 플랫폼 표시 수치입니다:

• 스타 약 253,000개, 포크 약 37,900개 — 저장소 페이지에 표시된 수치.
• 메인 브랜치 기준 커밋 2,667개.
• 열린 이슈 43개, 열린 풀 리퀘스트 124개 — 오래된 스타에 기대어 잠들어 있는 저장소가 아니라 실제로 활발하게 쌓이고 있는 백로그입니다.
• GitHub 일간 트렌딩 리스트 #6, 하루 만에 스타 1,897개 증가 — github.com/trending에서 직접 확인.
• npm 패키지 **ecc-universal**은 실제로 운영 중입니다: 공개 npm 레지스트리에는 최신 배포 버전인 2.2.0이 2026년 8월 27일에 나온 것으로 표시되어 있는데, 이는 메인 브랜치의 저장소 자체 package.json에 이미 선언된 2.2.1보다 한 버전 뒤처진 상태입니다.

이 차이는 얼버무리지 않고 짚어둘 만합니다: 저장소의 버전 파일이 실제로 npm에 배포된 것보다 앞서 나가고 있다는 뜻인데, 뭔가 잘못됐다는 증거라기보다는 흔히 있는 사소한 지연입니다 — 다만 package.json 숫자를 액면 그대로 받아들이지 말고 레지스트리를 직접 확인해야 하는 이유이기도 합니다. 이는 Aider 기사에서 GitHub의 태그된 릴리스와 PyPI 사이에 나타났던 것과 같은 종류의 간극이며, AI 에이전트를 위해(사람이 아니라) 만들어지고 있는 브라우저·OS 제품들이 플랫폼 수치가 아니라 대체로 자체 트랙션을 보고하는 것과는 다른 종류의 규율입니다.

이름 하나, MIT 라이선스, 그리고 Pro 티어

LICENSE 파일은 짧고 구체적입니다: MIT 라이선스이며, "Copyright (c) 2026 Affaan Mustafa"라는 문구가 적혀 있습니다. package.json의 author 필드에 적힌 이름도 같고, 모든 릴리스에 붙는 이름도 이것 하나뿐입니다. 그의 GitHub 프로필에는 "💫 everything is tokens"라는 소개 문구, 팔로워 10.3k, 그리고 Ito-Markets와 ECC-Tools라는 두 개의 작은 GitHub 조직 소속이 적혀 있습니다 — 이 중 ECC-Tools는 현재 공개 저장소가 단 하나뿐인데, 이는 실제 ECC 코드베이스가 회사 조직이 아니라 그의 개인 계정 아래에 있다는 뜻입니다.

비즈니스 모델은 README에 직접 적혀 있습니다: "OSS stays free. This repo is MIT-licensed forever."(오픈소스는 계속 무료입니다. 이 저장소는 영원히 MIT 라이선스입니다.) — 그리고 그 옆에는 유료 레이어가 있습니다: "ECC Pro is the hosted GitHub App for private repos"(ECC Pro는 프라이빗 저장소를 위한 호스팅 GitHub 앱입니다)이며, "[p]rivate repos from $19/seat/mo"(프라이빗 저장소는 좌석당 월 $19부터)라는 문구가 프로젝트 자체 가격 페이지로 링크되어 있습니다. 이 가격 문구는 제3자 리뷰가 아니라 프로젝트 자체 README에서 가져온 것입니다. 저희는 이번 검증 과정에서 마케팅 사이트 자체를 독립적으로 불러오지 못했기 때문에, $19/seat 수치는 메인테이너가 공개한 그대로 정확하다고 보되 — 실제 결제 페이지와 대조해 독립적으로 재검증하지는 못했다는 점을 밝힙니다. 저장소 어디에도 매출 수치는 공개되어 있지 않으므로, 이 글에서도 매출 수치는 언급하지 않습니다.

낭만적으로 보기 쉬운 부분 — 그리고 그렇지 않은 부분

"스타 253K, GitHub 계정 하나"를 순수한 1인 해커 성공담으로 읽고 싶어질 수 있습니다. 하지만 두 가지가 그 그림을 복잡하게 만듭니다.

첫째, 열려 있는 풀 리퀘스트 124개는 메인테이너 한 명이 정리하기엔 상당히 많은 외부 기여입니다 — Aider가 자신의 백로그에서 겪는 것과 같은 병목입니다. 라이선스에 이름이 하나뿐이라고 해서 들어오는 모든 것을 그 한 사람이 직접 읽고 머지하고 있다는 뜻은 아닙니다.

둘째, 프로젝트 자체 CHANGELOG는 보통 해커톤 데모 단계에서는 살아남지 않는 종류의 엔지니어링 규율을 보여줍니다. 가장 최근 항목인 v2.2.0은 의도적인 축소를 기록하고 있습니다: 기본으로 제공되는 MCP 커넥터 세트를 "after the June 2026 audit"(2026년 6월 감사 이후) 여섯 개에서 하나(chrome-devtools)로 줄였고, 그 근거는 별도의 MCP-CONNECTOR-POLICY.md 문서에 명시되어 있습니다 — 새로운 기본 커넥터는 "Universal"이어야 하고 "MCP beats a CLI/API wrapped in a skill"(MCP가 스킬로 감싼 CLI/API보다 낫다)이어야 한다는 정책이며, "Popular"(인기가 많다는 것) 하나만으로는 정당화 사유가 될 수 없다고 명시적으로 거부합니다. 같은 해 초에 해커톤 출품작으로 시작한 프로젝트치고는, 이는 대부분의 스타트업이 몇 년이 지나서야 겨우 작성하는 성문화된 거버넌스 프로세스입니다.

이것이 일반화되는 지점

여기서 다른 곳에도 적용할 수 있는 교훈은 "해커톤에서 우승하고 운을 바라라"가 아닙니다. 핵심은 ECC의 성장이 대부분의 바이럴 GitHub 프로젝트와 달리 눈으로 확인 가능하다는 점입니다: 이 글에 나온 모든 숫자 — 스타, 포크, 커밋, npm 버전, 라이선스, 해커톤 출처 — 는 지금 당장 직접 열어볼 수 있는 파일이나 플랫폼 페이지 안에 그대로 들어 있습니다. 이 프로젝트는 데모 하나로 운이 좋았던 게 아닙니다; 자체 changelog에 따르면, 스타 수가 계속 올라가는 와중에도 무언가를 거절하는 이유를 계속 기록해두었습니다 (MCP 커넥터 여섯 개를 하나로 줄이면서, 다시 자리를 얻으려면 어떤 조건을 충족해야 하는지 문서화된 규칙까지 남겨두었습니다). Claude Code, Cursor, 혹은 비슷한 도구로 빠르게 만들어내는 1인 빌더에게, 이것이야말로 처음 해커톤 빌드 자체보다 지키기 어려운 습관입니다: 프로젝트가 그 무엇에도 거절할 이유가 가장 적어 보이는 바로 그 순간에, 무엇을 추가하지 않을지에 대한 규칙을 써두는 것 말입니다.