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을 생성했거나, 잘못 청구했거나, 유용한 결과를 생성하지 않고 코드를 분석했다고 명시될 때
범위 제한
- 형제 저장소
ECC-Tools에서만 작업하고,everything-claude-code에서는 작업하지 않음 - 사용자가 명확하게 수정을 요청하지 않는 한 읽기 전용으로 시작
- 분석 비용을 추적하는 동안 관련 없는 청구, 체크아웃 또는 UI 흐름을 변경하지 않음
- 앱이 생성한 브랜치와 앱이 생성한 PR은 반증될 때까지 위험 신호 재귀 경로로 취급
- 다음 세 가지를 명시적으로 분리:
- 저장소 측 비용 소모 근본 원인
- 고객 대면 청구 영향
- 백로그 후속 조치가 필요한 제품 또는 권한 격차
워크플로우
1. 저장소 범위 고정
- 형제 저장소
ECC-Tools로 전환 - 먼저 브랜치와 로컬 diff 확인
- 감사 대상 정확한 표면 식별:
- 웹훅 라우터
- 큐 생산자
- 큐 소비자
- PR 생성 경로
- 사용량 예약 / 청구 경로
- 모델 라우팅 경로
2. 이론화 전에 인그레스 추적
- 먼저
src/index.*또는 메인 진입점 검사 - 수정을 제안하기 전에 모든 큐 등록 경로 매핑
- 어떤 GitHub 이벤트가 동일한 큐 유형을 공유하는지 확인
- push, pull_request, synchronize, comment 또는 수동 재실행 이벤트가 동일한 비용 경로로 수렴될 수 있는지 확인
3. 워커 및 부작용 추적
- 분석을 처리하는 큐 소비자 또는 예약된 워커 검사
- 대기 중인 분석이 항상 다음 중 하나로 끝나는지 확인:
- PR 생성
- 브랜치 생성
- 파일 업데이트
- 프리미엄 모델 호출
- 사용량 증가
- 분석이 토큰을 소비한 후 출력이 유지되기 전에 실패할 수 있으면, 출력이 손상된 비용 소모로 분류
4. 고위험 비용 경로 감사
PR 배수
- PR 헬퍼와 브랜치 명명 검사
- 중복 제거, 동기화 이벤트 처리, 기존 PR 재사용 확인
- 앱이 생성한 브랜치가 분석에 재진입할 수 있으면 우선순위 0 재귀 위험으로 취급
할당량 우회
- 할당량이 확인되는 위치와 사용량이 예약되거나 증가되는 위치 검사
- 큐 등록 전에 할당량이 확인되지만 사용량이 워커 내에서만 청구되면, 동시 프론트 도어 통과를 실제 경합 조건으로 취급
프리미엄 모델 누수
- 모델 선택, 티어 분기, 공급자 라우팅 검사
- 프리미엄 키가 존재할 때 무료 또는 제한된 사용자가 여전히 프리미엄 분석기에 도달할 수 있는지 확인
재시도 비용 소모
- 재시도 루프, 중복 큐 작업, 결정론적 실패 재실행 검사
- 동일한 비일시적 오류가 반복적으로 분석 비용을 소모할 수 있으면, 품질 개선보다 먼저 수정
5. 비용 순서로 수정
사용자가 코드 변경을 요청한 경우 다음 순서로 수정 우선순위를 지정:
- 자동 PR 배수 중단
- 할당량 우회 중단
- 프리미엄 누수 중단
- 중복 작업 확산 및 의미 없는 재시도 중단
- 재실행/업데이트 안전 격차 해소
동일한 근본 원인이 여러 파일에 명확하게 걸쳐 있지 않는 한, 수정은 1~3개의 직접 수정으로 제한.
6. 가장 작은 증명 단계로 확인
- 변경된 경로를 다루는 대상 테스트 또는 통합 조각만 재실행
- 비용 경로가 현재:
- 차단됨
- 중복 제거됨
- 더 저렴한 분석으로 다운그레이드됨
- 또는 조기에 거부됨 을 확인
- 최종 상태를 정확히 명시:
- 로컬에서 변경됨
- 로컬에서 확인됨
- 푸시됨
- 배포됨
- 여전히 차단됨
고위험 실패 패턴
1. 모든 트리거에 하나의 큐 유형
푸시, PR 동기화 및 수동 감사가 모두 동일한 작업을 큐에 등록하고 워커가 항상 PR을 생성하면, 분석은 PR 스팸과 같습니다.
2. 큐 등록 후 사용량 예약
사용량이 프론트 도어에서 확인되지만 워커에서만 증가되는 경우, 동시 요청이 모두 게이트를 통과하여 할당량을 초과할 수 있습니다.
3. 프리미엄 경로의 무료 티어
키가 존재할 때 무료로 큐에 등록된 작업이 여전히 Anthropic 또는 다른 프리미엄 공급자로 라우팅될 수 있다면, 사용자가 프리미엄 결과를 보지 못하더라도 실제 비용 누수입니다.
4. 앱이 생성한 브랜치가 웹훅에 재진입
pull_request.synchronize, 브랜치 푸시 또는 댓글 트리거 실행이 앱 소유 브랜치에서 발생하면, 앱은 자신의 출력을 재귀적으로 분석할 수 있습니다.
5. 지속성 안전 이전의 고비용 작업
시스템이 토큰을 소비한 후 PR 생성, 파일 업데이트 또는 브랜치 충돌로 실패할 수 있다면, 가치를 제공하지 않고 비용만 소모하는 것입니다.
함정
- 광범위한 저장소 탐색으로 시작하지 말고, 웹훅 -> 큐 -> 워커 순서로 정착
- 고객 청구 추론을 코드 기반 제품 진실과 혼합하지 않음
- 가장 높은 비용 경로가 차단되기 전에 낮은 가치의 품질 문제를 수정하지 않음
- 좁은 증명 단계가 재실행될 때까지 비용 소모가 수정되었다고 주장하지 않음
- 사용자가 요청하지 않으면 푸시 또는 배포하지 않음
- 이미 진행 중인 관련 없는 저장소 로컬 변경 사항을 건드리지 않음
확인
- 근본 원인은 정확한 파일 경로와 코드 영역을 인용
- 수정 사항은 코드 정리가 아닌 비용 영향 순서로 정렬
- 증명 명령의 이름을 지정
- 최종 상태는 로컬 변경, 확인, 푸시 및 배포를 구분