| name | ecc-tools-cost-audit |
| description | 증거 우선 방식의 ECC Tools 비용 소모 및 과금 감사 워크플로입니다. ECC Tools 저장소에서 PR 과다 생성, 쿼터 우회, 프리미엄 모델 누수, 중복 작업, GitHub App 비용 급증을 조사할 때 사용합니다. |
| origin | ECC |
ECC Tools 비용 감사
사용자가 ECC Tools GitHub App이 비용을 과도하게 소모하거나, PR을 과다 생성하거나, 사용량 제한을 우회하거나, 무료 사용자를 프리미엄 분석 경로로 보내고 있다고 의심할 때 이 스킬을 사용합니다.
이 스킬은 형제 저장소인 ECC-Tools를 대상으로 하는 집중 운영자 워크플로입니다. 일반적인 과금 스킬도 아니고, 저장소 전체를 훑는 코드 리뷰 패스도 아닙니다.
스킬 스택
필요할 때 다음 ECC 스킬을 함께 사용합니다.
autonomous-loops: 웹훅, 큐, 과금, 재시도를 가로지르는 다단계 감사를 제한된 범위에서 수행할 때agentic-engineering: 요청 경로를 분리 가능하고 입증 가능한 단위로 추적할 때customer-billing-ops: 저장소 동작과 고객 영향 계산을 명확히 분리해야 할 때search-first: 헬퍼를 새로 만들거나 로컬 유틸을 재구현하기 전에security-review: 인증, 사용량 게이트, 권한, 시크릿을 다룰 때verification-loop: 재실행 안전성과 수정 후 정확한 상태를 증명할 때tdd-workflow: 워커, 라우터, 과금 경로에 회귀 방지 커버리지가 필요할 때
사용 시점
- 사용자가 ECC Tools의 비용 소모율, PR 재귀, 과다 PR 생성, 사용량 제한 우회, 프리미엄 모델 누수를 언급할 때
- 작업이 형제 저장소
ECC-Tools에 있고 웹훅 핸들러, 큐 워커, 사용량 예약, PR 생성 로직, 유료 게이트 강제에 의존할 때
- 고객 제보에 따르면 앱이 PR을 너무 많이 만들었거나, 잘못 과금했거나, 코드 분석은 했지만 쓸 수 있는 결과를 남기지 않았을 때
범위 가드레일
- 작업 대상은
everything-claude-code가 아니라 형제 저장소 ECC-Tools입니다.
- 사용자가 명확히 수정을 요청하지 않았다면 읽기 전용으로 시작합니다.
- 분석 비용 소모를 추적하는 동안 관련 없는 과금, 체크아웃, UI 흐름을 변경하지 않습니다.
- 앱이 생성한 브랜치와 PR은 반증되기 전까지 재귀 위험 경로로 간주합니다.
- 다음 세 가지는 반드시 구분해서 다룹니다.
- 저장소 측 비용 소모의 근본 원인
- 고객-facing 과금 영향
- 백로그 후속 조치가 필요한 제품/권한 체계의 공백
워크플로
1. 저장소 범위 고정
- 형제 저장소
ECC-Tools로 이동합니다.
- 먼저 브랜치와 로컬 diff를 확인합니다.
- 감사 대상 영역을 정확히 특정합니다.
- 웹훅 라우터
- 큐 생산자
- 큐 소비자
- PR 생성 경로
- 사용량 예약 / 과금 경로
- 모델 라우팅 경로
2. 추측보다 먼저 유입 경로 추적
- 먼저
src/index.* 또는 메인 엔트리포인트를 확인합니다.
- 수정안을 제안하기 전에 모든 enqueue 경로를 맵핑합니다.
- 어떤 GitHub 이벤트가 같은 큐 타입을 공유하는지 확인합니다.
- push, pull_request, synchronize, comment, manual re-run 이벤트가 같은 고비용 경로로 합류하는지 확인합니다.
3. 워커와 부수 효과 추적
- 분석을 처리하는 큐 소비자 또는 스케줄된 워커를 확인합니다.
- 큐에 들어간 분석이 항상 다음 중 무엇으로 끝나는지 확인합니다.
- PR 생성
- 브랜치 생성
- 파일 업데이트
- 프리미엄 모델 호출
- 사용량 증가
- 토큰은 소모했는데 결과를 저장하기 전에 실패할 수 있다면, 이를 출력 손상 동반 비용 소모로 분류합니다.
4. 비용 소모 신호가 큰 경로 감사
PR 증식
- PR 헬퍼와 브랜치 네이밍을 확인합니다.
- 중복 제거, synchronize 이벤트 처리, 기존 PR 재사용 여부를 확인합니다.
- 앱이 생성한 브랜치가 다시 분석으로 들어갈 수 있다면 최우선 재귀 위험으로 봅니다.
쿼터 우회
- 쿼터를 어디서 검사하는지와 사용량을 어디서 예약/증가시키는지 확인합니다.
- enqueue 전에 쿼터를 검사하지만 사용량은 워커 내부에서만 청구된다면, 동시 요청의 정문 통과를 실제 경쟁 상태로 간주합니다.
프리미엄 모델 누수
- 모델 선택, 티어 분기, 공급자 라우팅을 확인합니다.
- 프리미엄 키가 있을 때 무료 또는 제한 사용자도 프리미엄 분석기로 들어갈 수 있는지 검증합니다.
재시도 비용 소모
- 재시도 루프, 중복 큐 작업, 결정적 실패의 재실행을 확인합니다.
- 같은 비일시적 오류가 분석 비용을 반복 소모할 수 있다면, 품질 개선보다 먼저 이 문제를 막습니다.
5. 비용 소모 우선순위대로 수정
사용자가 코드 변경을 요청했다면 다음 순서로 우선 수정합니다.
- stop automatic PR multiplication
- stop quota bypass
- stop premium leakage
- stop duplicate-job fanout and pointless retries
- close rerun/update safety gaps
같은 근본 원인이 여러 파일에 명확히 걸쳐 있지 않다면, 수정 범위는 직접적인 1~3개 변경으로 제한합니다.
6. 최소한의 입증 단계로 검증
- 변경된 경로를 커버하는 대상 테스트나 통합 슬라이스만 다시 실행합니다.
- 비용 소모 경로가 이제 다음 중 어떤 상태인지 확인합니다.
- 차단됨
- 중복 제거됨
- 더 저렴한 분석으로 강등됨
- 초기에 거절됨
- 최종 상태는 정확히 명시합니다.
- 로컬에서 변경됨
- 로컬에서 검증됨
- 푸시됨
- 배포됨
- 여전히 차단됨
고신호 실패 패턴
1. 모든 트리거가 하나의 큐 타입으로 합쳐짐
push, PR 동기화, 수동 감사가 모두 같은 작업을 enqueue하고 워커가 항상 PR을 만든다면, 분석이 곧 PR 스팸이 됩니다.
2. enqueue 이후 사용량 예약
정문에서 사용량을 검사하지만 증가 처리는 워커에서만 한다면, 동시 요청이 모두 게이트를 통과해 쿼터를 초과할 수 있습니다.
3. 무료 티어가 프리미엄 경로로 진입
키가 존재할 때 무료 작업도 Anthropic이나 다른 프리미엄 공급자로 라우팅될 수 있다면, 사용자가 프리미엄 결과를 보지 못하더라도 실제 비용 누수입니다.
4. 앱 생성 브랜치가 웹훅으로 재진입
pull_request.synchronize, 브랜치 push, 댓글 기반 실행이 앱 소유 브랜치에서 발생한다면, 앱이 자기 결과물을 재귀적으로 다시 분석할 수 있습니다.
5. 저장 안전성 확보 전의 고비용 작업
시스템이 토큰을 소모한 뒤 PR 생성, 파일 업데이트, 브랜치 충돌에서 실패할 수 있다면, 가치를 전달하지 못한 채 비용만 소모하는 상태입니다.
주의점
- 저장소 전체를 떠도는 식으로 시작하지 말고, 웹훅 -> 큐 -> 워커 순서부터 고정합니다.
- 고객 과금 추정과 코드로 입증된 제품 동작을 섞지 않습니다.
- 가장 큰 비용 소모 경로를 막기 전까지 부가적인 품질 문제를 먼저 손대지 않습니다.
- 좁은 범위의 검증 단계를 다시 실행하기 전에는 비용 문제가 해결됐다고 말하지 않습니다.
- 사용자가 요청하지 않았다면 푸시나 배포를 하지 않습니다.
- 이미 진행 중인 관련 없는 로컬 변경은 건드리지 않습니다.
검증 기준
- 근본 원인은 정확한 파일 경로와 코드 영역을 근거로 제시합니다.
- 수정 우선순위는 코드 미관이 아니라 비용 영향 기준으로 정합니다.
- 입증에 사용한 명령을 명시합니다.
- 최종 상태는 로컬 변경, 검증, 푸시, 배포를 구분해서 적습니다.
