보지도 않은 리뷰가 주간 사용량 19%를 썼다

질문

10월 2일 오후, 폰에서 Codex에 물었다.
"지피티 사용한적이없는것 같은데 사용량이 닳았어. 원인파악"
Codex는 프록시를 거쳐 Claude로 돌려 쓰고 있었고 GPT를 직접 부른 기억은 없었다.

첫 답을 받고 다시 물었다.
9월 27일에 주간 한도가 초기화됐는데 그 뒤로 19%가 어딘가에서 나갔으니 그 사용처를 추적해 달라고 했다.
서버가 돌려준 값도 같았다. 10월 2일 05:13(UTC)에 조회한 7일 창 사용률은 19였고 5시간 창은 0이었다.
그 시점에 10월 1일과 2일의 리뷰분은 아직 집계되지 않은 상태였다.

줄어든 사용량의 주인은 누구였나.
찾고 나서 그것을 계속 켜 둘 이유가 있었나?

판정

GitHub 자동 코드 리뷰는 껐다. 같은 리뷰는 머지 전 검수 스킬인 final-review 안으로 옮겼다.

지적은 대부분 맞았다. 코드를 읽어 대조한 P2 30건 중 22건이 유효했다.
그런데 지적이 달린 PR 25개 가운데 리뷰 뒤에 커밋이 붙은 PR은 0개였다.
21개는 머지가 끝난 뒤 6초~271초 사이에 리뷰가 도착했고 머지 직전에 도착한 4개도 그대로 머지됐다.
맞는 지적 22건이 하나도 반영되지 않은 원인은 리뷰 품질보다는 작업 흐름에 리뷰를 기다리는 단계가 없었다는 데 있었다.

원인을 들은 뒤 내가 처음 물은 것은 "이게 실효가있는 기능인가?"였고, 표본이 전부 머지 뒤에 도착했다는 답을 듣고는 같은 방식의 리뷰를 머지 전에 Codex로 돌려 흐름에 넣자고 했다.
지적을 버리지도 않았다. P2 30건은 다른 세션에서 하나씩 따져 보게 넘겼다.

사용량의 주인은 서버 사용 내역으로 확정했다.
폰의 첫 진단은 로컬 로그를 근거로 다른 범인을 지목했고 같은 세션이 19분 51초 뒤 서버 일별 내역을 읽고 그 진단을 스스로 정정했다.

근거

로컬 기록은 후보까지, 귀속은 서버 내역이 정했다

폰 Codex의 첫 답은 로컬 Codex 로그를 근거로 했다.
채팅 제목 자동 생성과 추천 작업 제안 기능이 메인 모델 설정과 상관없이 GPT를 고정으로 부른다는 진단이었다.
로그에 그 호출이 실제로 찍혀 있어서 그럴듯했다.

두 번째 질문 뒤에는 맥의 Claude Code도 같은 원인을 쫓았다.
맥 쪽은 로컬 런타임 기록(aside·gjc·로컬 Codex·opencodex)을 훑어 9월 27일 이후 GPT 호출이 0건임을 확인했고 GitHub에서 봇이 PR 44개를 리뷰한 것을 찾았다.
그리고 한계도 함께 적었다. 19% 중 리뷰 몫이 얼마인지는 로컬 기록으로 알 수 없고 서버의 사용량 화면을 봐야 확정된다는 내용이었다.

37초 뒤 폰 Codex가 서버 일별 내역을 읽고 답을 고쳤다.
9월 25일 이후 사용처는 100%가 github_code_review였고 첫 답이 지목한 제목 생성과 추천 작업 제안은 서버 기준 9월 22일 이후 0이었다.
고친 답에는 첫 답이 틀렸다는 문장도 들어 있었다.
로컬 로그로 고른 범인은 실제로 GPT를 부르긴 했지만 이번 주 사용량과는 무관했다.
두 쪽 다 로컬 기록으로는 후보까지만 좁혔고 귀속을 정한 것은 서버 내역이었다.

지적은 맞았고 도착은 늦었다

맥 쪽은 원인을 찾은 다음 리뷰가 쓸모 있었는지를 살폈다.
표본 9건은 전부 머지가 먼저였다. Hindsight-Crew의 한 PR에는 머지 6초 뒤에 리뷰가 달렸다.
그때 작업 흐름에는 이미 머지 전 검수 단계인 final-review가 있었고 자동 리뷰는 그 뒤에 따로 도착하고 있었다.

표본 9건만으로 "전부 머지 뒤"라고 쓸 수는 없어서 지적이 달린 25개를 전수로 다시 쟀다.
4개는 머지 직전에 도착했다. 가장 이른 것은 smartthink의 PR으로, 머지 3분 6초 전에 리뷰가 달렸다.
그 PR도 리뷰 뒤 커밋 없이 머지됐다.
리뷰가 머지 전에 와도 그것을 읽고 멈추는 단계가 없었던 것이다.

지적의 내용은 가볍지 않았다.
Hindsight-Crew의 킬스위치가 compose 설정에 배선되지 않아 셸 변수로는 롤백할 수 없다는 지적이 있었고 카나리 판정기가 기준선 형식 오류를 롤백과 같은 종료 코드로 내보낸다는 지적도 있었다.
뒤의 결함이 판정에 어떤 의미였는지는 카나리 판정문에 적어 두었다.
유효한 지적은 티켓 15개가 됐고 같은 날 모듈별 묶음 4개로 합쳐 처리했다.

끄고 옮겼다

끄는 일은 브라우저 에이전트에 맡겼다.
첫 시도에서 에이전트는 다른 무료 계정으로 들어가서 끌 대상이 없다고 보고했다.
계정을 바꿔 다시 보니 개인 기본값인 "자동 검토"가 켜져 있었고 개인 리포 45개가 전부 "개인 설정 따르기"였다.
리포별 옵션에는 끄기 항목이 아예 없었다. 개인 기본값 하나를 끄자 45개가 함께 꺼졌다.

자동 리뷰를 끈 날, 같은 리뷰를 머지 전으로 옮기는 변경도 커밋했다.
final-review의 첫 단계와 병렬로 Codex 리뷰를 돌리고 그 지적은 Opus 검증자를 거쳐야만 채택한다.
한도에 걸리거나, 오류가 나거나, 요청한 모델이 아닌 쪽으로 라우팅되면 Codex 없이 원래 흐름으로 진행한다.
커밋 본문에는 기각한 안도 남아 있다.

Rejected: GitHub 자동 리뷰 유지 | 머지 후 도착, 표본 9건 전부 머지가 먼저, 반영 0건

첫 실행 대상은 이 변경 자신이었다.
옮긴 날 실제로 3회 실행했고 반영한 P2는 3건, 1건, 0건으로 줄었다.
같은 변경을 따로 본 독립 리뷰는 회귀 2건을 mock으로 재현했다. 동시에 돌던 다른 실행의 라우팅 기록이 섞이면 정상 결과를 모델 불일치로 버리는 결함과, 연결 단절 잡음을 한도 초과로 오판해 1시간 쿨다운을 거는 결함이다.
두 건은 첫 실행의 지적을 반영한 수정 커밋에서 앞의 두 항목과 같은 결함이었다.
그 뒤 리뷰어를 늘리고 줄인 실험은 다른 글에 있다.

모델을 비워 둔 호출은 의도와 다른 모델로 돌았다

이 일 전에도 모델을 비워 둔 호출이 사용량을 소모한 적이 두 번 있었다.
9월 8일에는 배치 스크립트가 헤드리스 claude -p 자식 프로세스를 --model 없이 띄웠다.
자식 프로세스는 부모의 모델을 알지 못해 설정 기본 모델(Claude Fable)로 도는 독립 세션이 됐고 그 안의 서브에이전트도 그 모델을 물려받았다. 대책은 헤드리스 호출에 --model을 명시하는 것이었다.
9월 15일에는 model 인자를 비워 띄운 서브에이전트 3개가 부모의 최상위 모델을 그대로 물려받았다.
두 번 다 원인보다 사용량 급증이 먼저 눈에 띄었다.

한계·재검토 트리거

닷새, 리포 네 곳, 계정 하나에서 관측한 결과다.
P2 유효성은 코드를 읽어 대조한 값이고 실행으로 재현하지는 않았다. P1은 5건뿐이라 비율을 말할 만한 크기가 못 된다.
일별 서버 값은 단위가 주간 사용률과 달라서 리뷰 한 건이 한도를 얼마나 쓰는지는 계산하지 않았다.

끈 뒤에도 그날 주간 사용률은 21에서 27로 올랐다.
그 값을 남긴 호출은 전부 머지 전 교차 리뷰로 옮긴 Codex 실행이라, 자동 리뷰 몫이 0이 됐는지는 이 기록으로 가를 수 없다.

같은 날 모델 라우팅 프록시(opencodex)의 갱신 명령이 Codex 기본 모델 줄을 지웠고 지워진 줄은 복구하지 않기로 했다.
따라서 모델을 지정하지 않은 Codex 세션은 GPT 기본값으로 돌아 같은 주간 한도를 쓸 수 있다.

2026-10 기준 / 재검토 트리거: 원인 모를 GPT 사용량 소모가 다시 관측되거나, 작업 흐름이 리뷰를 기다렸다가 머지하는 방식으로 바뀌면 이 판정을 다시 연다.