ECC, 여러 AI 에이전트 툴을 하나의 OS처럼 묶는 오픈소스

배경

지금 AI 코딩 에이전트를 쓰는 환경은 점점 분산되고 있어요. Claude Code, Codex, OpenCode, Cursor 같은 도구는 각자 자신의 설정 파일, 스킬 구조, 후킹 방식을 따릅니다. 그래서 한 팀에서 여러 하니스(에이전트 실행 환경)를 섞어 쓰게 되면 컨텍스트 관리, 보안 정책, 워크플로가 전부 조각나기 쉬워요. ECC는 이 흩어진 실행 환경을 하나의 체계로 묶어주는 MIT 라이선스 오픈소스 프로젝트예요.

ECC가 해결하려는 문제

ECC가 겨냥하는 핵심 과제는 하니스 간 호환성과 운영 일관성이에요. 대부분의 에이전트 설정은 특정 도구에 강하게 묶여 있어서, 툴을 바꾸면 스킬과 규칙을 다시 작성해야 해요. 반면 ECC는 skills, instincts, memory, security, research-first 개발 같은 요소를 하니스 독립적으로 재구성하고자 해요. 저장소 설명은 이를 agent harness performance optimization system, 즉 에이전트 실행 환경의 성능과 운영을 최적화하는 시스템이라고 정의해요.

여기서 중요한 건 성능이 단순히 속도가 아니라 품질과 일관성이라는 점이에요. ECC의 공식 소개글은 에이전트가 코드를 쓸 수 있다면, ECC는 계획, 테스트, 리뷰, 기억, 개선까지 갖춘 엔지니어링 시스템을 준다는 표현을 써요. plan → test → implement → review → verify → remember → improve 흐름을 매번 프롬프트로 다시 만들지 않고, 설치 한 번으로 에이전트의 기본 동작 방식에 녹이는 거죠.

구조와 지원 범위

레포 구성은 JavaScript 70.9%, Rust 20.9%, Python 4.6%, Shell 2.4%, TypeScript 1.1%, Swift 0.1%로 되어 있어요. 언어 비율 자체가 ECC의 지향점을 잘 보여줘요. JS/TS는 플러그인과 환경 통합을 담당하고, Rust는 성능·보안 관련 로직, Python/Swift는 생태계별 어댑터와 예시를 담당하는 구조예요.

지원 목록은 꽤 넓어요. Claude Code를 일급 지원으로 두고, Codex 동기화 경로를 지원하며, Cursor, OpenCode, Gemini, Zed, GitHub Copilot, Antigravity, Qwen 등에는 기능 제한이 있는 어댑터를 제공해요.

.claude-plugin, .codex, .adal, .agents, .gemini 같은 하니스별 디렉토리가 저장소에 함께 들어 있어서, 각 툴의 규격에 맞춰 설치하도록 되어 있어요.

패키지 규모를 보면 현재 68개 에이전트, 286개 스킬, 94개 커맨드가 포함되어 있다고 README가 밝히고 있어요. 에이전트는 계획, 리뷰, 빌드 수리, 보안, 아키텍처, 도메인 작업에 특화되어 있고, 스킬은 TDD, 리서치, 보안, 문서, 프런트엔드, 데이터, ML, 운영에 걸쳐 있어요.

2.0에서 달라진 점

ECC 2.0.0은 스스로를 stable graduation, 즉 운영 가능한 정식 버전으로 소개해요. 가장 큰 변화는 하니스를 가로지르는 세션 어댑터 계층이에요. ecc.session.v1은 Claude Code, Codex, OpenCode, dmux의 세션 데이터를 같은 인터페이스로 감싸서, 도구마다 세션 저장 방식이 달라 생기던 혼란을 줄여요.

또한 MCP 인벤토리가 전환점이에요. ecc.mcp.v1은 여러 하니스에 걸친 MCP 서버 설정을 한 번에 점검하고, 설정이 분산되거나 실제와 어긋난(drift) 부분을 감지하며, 시크릿 값은 자동으로 가려서 보여줘요. 운영자가 각 설정 파일을 일일이 비교하던 수고를 덜어주는 부분이에요.

마지막으로 워크트리 수명주기 서비스가 있어요. 병렬 에이전트들이 여러 워크트리에서 동시에 작업할 때 충돌 가능성을 미리 예측하고, 안전한 정리(GC)를 지원해요. 멀티 에이전트 워크플로를 실제로 돌리는 팀이라면 가장 직접적으로 와닿는 기능이에요.

여기에 orch-* 오케스트레이터 스킬 패밀리와 rollout에서 나온 최적화 팩(병렬 실행 최적화, 벤치마크 최적화 루프, 데이터 처리량 가속, 지연 시간 중요 시스템 등)도 새로 더해졌어요. 보안 하드닝도 신경 썼는데, curl 자격증명을 argv에 남기지 않도록 바꾸고, gateguard가 force/path 체크아웃을 파괴적 명령으로 분류하도록 조정했어요.

특히 Node 21 이상에서 플러그인 훅이 조용히 무시되던 문제를 2.0.0에서 고쳤어요. 실전에서 바로 만날 수 있는 변경이라, 최신 Node를 쓰는 환경이라면 업데이트가 필요해요. 2026년 8월 말에는 2.2.0도 나와서, 가이드 기반 다중 하니스 설치 프로그램과 유니버셜 셋업 경로를 소개하고 있어요.

어떤 팀에 유용할까

ECC는 에이전트 하나를 대체하는 도구가 아니라, 여러 에이전트를 동시에 관리하는 레이어예요. 한두 개 툴만 쓰는 개인이라면 진입장벽이 체감될 수 있어요. 반면 팀에서 Claude Code, Codex, OpenCode를 혼용하거나, 병렬 에이전트 작업을 한다면 ECC 규격으로 설정·규칙·워크플로를 통일하는 게 유리해요.

설치 환경에 따라 스킬과 커맨드 개수가 달라져서, 문서가 밝히는 숫자는 저장소 상태 기준으로 봐야 해요. 또 모든 하니스가 동일한 기능 파리티를 갖는 건 아니라서, 도입 전에 공식 지원 상태 매트릭스(프로젝트 README의 platform support)를 먼저 확인하는 걸 권해요.

설치는 공식 채널을 통해서만 하도록 되어 있어요. GitHub 저장소, npm의 ecc-universal·ecc-agentshield, GitHub App, 프로젝트 사이트인 ecc.tools가 공식 경로예요. 비공식 미러나 재배포판은 보안 위험이 있다고 프로젝트가 직접 경고하고 있어요.

공식 문서와 Discord 커뮤니티가 운영 중이니, 도입 전에 현재 환경과의 호환 여부를 확인해볼 수 있어요.

요약하면 ECC는 에이전트 툴을 하나로 강제하자는 프로젝트가 아니라, 여러 하니스를 쓰더라도 운영 계층을 통일하자는 접근이에요. 멀티 하니스 환경을 실제로 운영하는 팀이라면 MCP 설정, 세션 관리, 워크트리 정책을 ECC 규격으로 점검해볼 만한 가치가 있어요.

참고 링크

• affaan-m/ECC GitHub 저장소
• 공식 사이트 ecc.tools
• ECC 2.0.0 릴리스 공지
• ECC 2.2.0 릴리스 노트