GitHub Code Quality 유료화 — 커미터당 $10의 숨은 함정

다음 달 GitHub 청구서, 예상보다 0 하나 더 붙어 있을지도 모릅니다. 😅

2026년 7월 20일. GitHub Code Quality가 조용히 프리뷰를 끝내고 정식 출시(GA)됐습니다. 조용히? 아니요. 같은 날부터 과금이 자동으로 시작됐거든요. 유예 기간, 없습니다.

"커미터당 월 $10이라며? 그 정도야 뭐." 라고 생각했다면 잠깐. 이 글 끝까지 보면 왜 그 $10이 '시작 가격'일 뿐인지 알게 됩니다. 👇

우선, 뭐가 바뀌었나

GitHub 공식 발표(github.blog 체인지로그)부터 보죠. 핵심 한 줄은 이렇습니다.

"AI가 코드 생산량을 끌어올리는 시대, Code Quality는 팀이 '믿고 배포할' 코드를 만들도록 돕는다."

CodeQL의 결정론적 분석에 AI 기반 탐지를 얹어서, 풀 리퀘스트 단계에서 유지보수성·신뢰성 문제를 잡아준다는 겁니다. GA와 함께 붙은 기능들:

• 조직 대시보드 — 저장소 전체의 유지보수성·신뢰성 점수를 한눈에
• 커버리지 게이트 — Cobertura XML 리포트를 PR에 바로 렌더, 임계값 미달이면 병합 차단
• 품질 게이트 + 평가 모드 — 룰셋으로 점진 롤아웃
• API — 저장소 활성화·탐지 결과를 프로그래밍으로 관리

GitHub 자체 조직에선 "PR 병합 전에 Code Quality 지적사항의 67.3%를 해결한다"고 하고, 프리뷰엔 이미 1만여 개 기업이 참여했다고 하네요. 기능만 놓고 보면 따로 사던 SAST·커버리지 툴을 대체할 만합니다. 여기까진 좋아요.

그런데 여기서 반전이 시작됩니다.

진짜 비용은 $10이 아니다

CritiquePlus의 지적이 날카롭습니다. 요지는 이거예요.

"기본 가격은 활성 개발자당 월 $10이 맞다. 그런데 그 숫자는 전체 비용을 뜻하지 않는다."

과금이 3층 구조거든요.

1. 고정 라이선스 — 활성 커미터당 $10/월
2. AI 사용량 — AI 탐지·Copilot Autofix는 GitHub AI 크레딧을 태웁니다 (1크레딧 = $0.01)
3. Actions 분(分) — CodeQL 분석이 GitHub Actions 실행 시간을 잡아먹습니다

문제는 2번·3번이 쓰는 만큼 붙는다는 것. PR 많고 자동수정 자주 도는 활발한 저장소일수록, 기본가($10)가 말하는 것보다 훨씬 더 나옵니다. CritiquePlus의 표현을 빌리면 "고정 라이선스 + AI 사용량 + Actions 분이 섞인 요금제라 지출 예측이 어렵다."

30명 팀이면 기본만 월 $300. 여기에 얼마가 더 얹힐지는… 한 달 돌려봐야 압니다.

그리고 더 놀라운 건, '커미터'의 정의

TechTimes가 짚은 대목이 진짜 함정입니다. active committer = 최근 90일 안에 커밋을 푸시한 전원.

이게 왜 무섭냐면요.

• 정규직만? 아니요. 계약직·외주·외부 협업자도 90일 안에 커밋 하나 밀어넣었으면 카운트됩니다.
• 오픈소스 컨트리뷰터가 PR 하나 머지했다? 그 사람도 committer.
• "우리 팀 10명인데" → 실제 청구 대상은 20명일 수도 있다는 얘기.

게다가 유예 없이 7월 20일부터 즉시 청구입니다. 1만여 개 프리뷰 기업이 그날 바로 청구 대상이 됐고, 핵심은 "지금 팀 인원수 ≠ 청구 대상"이라는 것.

그럼 지금 뭘 해야 하나

ChatForest의 빌더용 체크리스트가 실용적입니다. 도입 전 이 7가지는 보고 가세요.

1. Code Quality가 켜진 저장소 전체 목록 뽑기
2. 저장소별 90일 활성 커미터 수 세기 (= 진짜 청구 대상)
3. 조직 전체 배포 설정 상태 확인
4. GitHub Actions 소비량 기준선 측정
5. 병합 차단 규칙 실제 동작 테스트
6. AI 기능 사용량 추적
7. 비용 계산기로 사전 예측 + 예산 상한 걸기

ChatForest는 냉정하게 이렇게도 말합니다. "지적사항을 실제로 안 고치는 저장소, $10이 부담인 소규모 팀, 이미 SAST·커버리지 툴이 있는 팀이라면 꺼두는 것도 방법"이라고. $10 기본가 자체는 타사 코드스캐닝 애드온과 비슷한 수준이니, 진짜 문제는 가격표가 아니라 '어디에 켜느냐'라는 거죠.

---

정리하면 네 소스가 같은 사건을 이렇게 다르게 봅니다. GitHub는 "믿을 수 있는 코드"라는 가치를, CritiquePlus는 "예측 불가한 청구서"라는 리스크를, TechTimes는 "즉시·전원 과금"이라는 규모를, ChatForest는 "그래서 선택적으로 켜라"는 실무를 말하죠. 저는 이 중 CritiquePlus의 경고가 지금 가장 유효하다고 봅니다. 세 소스 모두 3층 과금 구조를 인정하는데, 공식 발표는 그걸 담담히 나열하고 넘어갈 뿐 실제 청구서를 받는 건 결국 팀이니까요. 그렇다고 CritiquePlus 편만 드는 건 아닙니다. ChatForest의 균형 감각도 공정해요 — $10 자체는 바가지가 아니고, 진짜 변수는 '관리'라는 것.

한국 팀엔 committer 정의가 특히 뼈아플 수 있습니다. 외주·파견·프리랜서로 굴러가는 프로젝트가 흔한데, 90일 안에 커밋 한 번 남긴 외부 인력이 전부 과금 대상이 되면 계산이 순식간에 틀어지거든요. 오픈소스 메인테이너나 사이드 프로젝트를 굴리는 인디 빌더도 마찬가지입니다. 컨트리뷰터가 늘수록 청구서도 같이 커지니까요. 그러니 "우리 인원수"가 아니라 "90일 커밋 로그"로 비용을 다시 계산해 보는 게 순서입니다.

물론 한계도 분명합니다. 아직 GA 첫 주라 실제 청구서 사례가 거의 없고, AI 크레딧·Actions 분 소모량은 팀 습관마다 천차만별이라 지금 나온 숫자들도 추정에 가깝습니다. GitHub가 초기 반응을 보고 요금을 손볼 여지도 남아 있고요. 그래서 지금은 '패닉'보다 '측정'이 정답입니다. 대표 저장소 몇 개만 켜서 한 달 돌려보고, false positive와 Actions 소모를 재본 뒤 확대해도 늦지 않아요.

자, 그래서 궁금한데요. 여러분 팀이라면 이 기능, 전 저장소에 다 켜시겠어요, 아니면 핵심 레포 몇 개만 골라서 켜시겠어요? 90일 committer 계산해 보니 예상보다 인원이 많던 분들, 댓글로 몇 명 나왔는지 살짝 공유해 주세요. 👇