affaan-m/ECC는 새 코딩 에이전트를 만드는 프로젝트가 아니다. README의 첫 문장은 명확하다. "The agent harness performance optimization system." Claude Code, Codex, Opencode, Cursor — 이미 쓰이고 있는 코딩 에이전트 harness 위에 얹어, 그 harness가 더 효율적으로 일하게 만드는 레이어를 표방한다. 하루 2,052 stars, 트렌딩 4위라는 숫자보다 이 포지셔닝 자체가 흥미롭다. 시장의 관심이 '또 다른 에이전트'에서 '에이전트를 둘러싼 운영 환경'으로 이동하고 있다는 신호이기 때문이다.
구성은 다섯 축으로 압축된다. Skills는 작업 단위로 재사용 가능한 행동을 모듈화한다. Instincts는 매 호출마다 LLM에게 다시 가르치지 않아도 되는 디폴트 판단을 외부 시스템에 박아두는 발상이다. Memory는 단일 세션을 넘어 누적되는 컨텍스트를 다루고, Security는 도구 호출과 파일 접근의 경계를 코드 수준에서 정의한다. 마지막 축인 research-first development는 에이전트가 코드를 쓰기 전에 먼저 조사하고 계획하도록 워크플로 자체를 강제한다. 다섯 축이 어느 하나도 빠지지 않고 함께 다뤄진다는 점이 이 레포의 무게중심이다.
언어 선택에도 의도가 읽힌다. 에이전트 인프라가 대부분 Python으로 흐르는 분위기에서 ECC는 JavaScript를 택했다. 이는 모델 SDK 옆이 아니라 IDE·CLI 통합 표면 옆에 붙겠다는 선언에 가깝다. Cursor 확장, VS Code 플러그인, Claude Code의 settings.json 훅 같은 곳에 자연스럽게 꽂힐 수 있는 결이다. 모델 벤더가 아니라 에이전트를 매일 손에 쥐고 있는 개발자의 자리에서 출발한 설계로 읽힌다.
남는 긴장은 분명하다. harness를 '최적화'한다는 말은 곧 현재 harness의 결함을 인정한다는 뜻이고, 그 결함의 상당 부분은 시간이 지나면 벤더가 SDK 레벨에서 흡수할 가능성이 있다. 그럼에도 harness 사이를 가로지르는 공통 운영 레이어 — Claude Code에서도, Codex에서도, Cursor에서도 똑같이 통하는 instinct와 memory와 security 정의 — 는 어느 단일 벤더도 직접 깔기 어려운 자리다. ECC가 노리는 곳이 거기라면, 지금 자기 팀의 에이전트 워크플로에서 매번 반복 주입되는 컨텍스트가 몇 줄이나 되는지 한 번 세어보는 것이 가장 정직한 첫 검증이다. 그 숫자가 클수록, 이 레포가 푸는 문제는 곧 내 문제가 된다.