ecc-tools-cost-audit

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. 비용 소모 우선순위대로 수정

사용자가 코드 변경을 요청했다면 다음 순서로 우선 수정합니다.

1. stop automatic PR multiplication
2. stop quota bypass
3. stop premium leakage
4. stop duplicate-job fanout and pointless retries
5. 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 생성, 파일 업데이트, 브랜치 충돌에서 실패할 수 있다면, 가치를 전달하지 못한 채 비용만 소모하는 상태입니다.

주의점

• 저장소 전체를 떠도는 식으로 시작하지 말고, 웹훅 -> 큐 -> 워커 순서부터 고정합니다.
• 고객 과금 추정과 코드로 입증된 제품 동작을 섞지 않습니다.
• 가장 큰 비용 소모 경로를 막기 전까지 부가적인 품질 문제를 먼저 손대지 않습니다.
• 좁은 범위의 검증 단계를 다시 실행하기 전에는 비용 문제가 해결됐다고 말하지 않습니다.
• 사용자가 요청하지 않았다면 푸시나 배포를 하지 않습니다.
• 이미 진행 중인 관련 없는 로컬 변경은 건드리지 않습니다.

검증 기준

• 근본 원인은 정확한 파일 경로와 코드 영역을 근거로 제시합니다.
• 수정 우선순위는 코드 미관이 아니라 비용 영향 기준으로 정합니다.
• 입증에 사용한 명령을 명시합니다.
• 최종 상태는 로컬 변경, 검증, 푸시, 배포를 구분해서 적습니다.