Cloudflare가 10월 19일(현지시간) 공식 블로그에서 자사 AI 코드 리뷰어의 추론 비용을 줄인 과정을 공개했다. 코드 품질 리뷰어를 높은 추론 강도로 돌리는 조건에서 리뷰 한 건의 평균 비용은 0.77달러다. 최적화를 시작하기 전 가장 비쌌던 두 주의 평균 2.43달러보다 68% 낮다. 리뷰 시간의 중앙값도 4분 9초에서 1분 32초로 짧아졌다고 회사는 밝혔다.
절감분의 약 40%는 리뷰어 코드를 고쳐서, 나머지는 사용 모델과 모델이 들이는 노력의 수준을 실험해서 얻었다. 4월 글에서 1.19달러였던 평균 리뷰 비용은 8월 말 약 2.46달러까지 올랐다. 조정자가 같은 전문 리뷰어 집합에 일을 맡기는 구조와 위험 등급별 리뷰 강도는 그대로였다. Cloudflare는 9월 중순 에이전트에게 토큰이 어디로 새는지 찾아 줄이도록 시켰다.
비용이 두 배로 뛴 이유
등급 구성을 고정해 계산한 평일 평균 리뷰 비용은 3월 1.22달러, 6월 1.44달러, 7월 1.74달러, 8월 2.32달러로 올랐다. 가장 비싼 전체 리뷰 등급의 비중은 3월 59%에서 8월 65%로 커졌지만 비용 상승에서 차지한 몫은 작다. Cloudflare는 모델이 좋아져 엔지니어가 더 크고 복잡한 변경을 올리기 때문일 것으로 추정한다. 비용 상승의 대부분은 같은 기간의 모델 교체에서 나왔다.
8월 초 Cloudflare는 모든 리뷰어를 Anthropic 모델로 옮겼다. 사내 평가에서 이 작업에는 Anthropic 모델이 다른 모델보다 나았다는 이유다. 작업당 비용은 1.38달러에서 2.03달러로 올랐다. 사내 표준 리뷰어인 Codex는 성능과 안정성을 따져 Claude Opus 4.7에 배정됐고, 리뷰당 비용이 0.25달러에서 8월 0.88달러로 뛰어 조정자 에이전트보다 비싸졌다. 이 Codex는 Cloudflare 내부 리뷰어의 이름이다.
캐시 적중률은 4월 85.7%에서 9월 97%로 올랐지만, 리뷰당 토큰이 0.91백만 개에서 2.99백만 개로 세 배 넘게 늘어 읽기 단가가 낮아도 총비용은 커졌다. 최적화 직전 지출은 출력 토큰 약 23%, 캐시 쓰기 43%, 캐시 읽기 34%였다. 돈 대부분이 모델이 이미 본 맥락, 또는 곧 다시 볼 맥락에 들어갔다는 뜻이다.
코드 품질 리뷰어는 리뷰 한 건에서 LLM을 평균 16.6번 호출했다. 호출마다 대화 전체를 맥락으로 보내기 때문에 캐시에 7만 2천 토큰을 쓰고 108만 토큰을 읽었다. 호출 횟수와 맥락 크기를 둘 다 천천히 키워 온 결과였다.
Anthropic의 프롬프트 캐시는 모델이 이미 계산한 프롬프트의 앞부분(접두부)을 저장해 다음 요청이 재사용하게 한다. 대화 중간이나 끝은 재사용할 수 없고, 캐시 중단점이 끝을 표시한 접두부만 저장된다. 쓰기 비용은 일반 입력 가격의 1.25배, 읽기는 0.1배이며 읽는 요청이 없으면 5분 뒤 만료된다. 리뷰어 세션은 하네스 도구, 시스템 프롬프트, 앞부분 메시지가 거의 바뀌지 않아 접두부 캐시에 알맞았다. Cloudflare는 세션 첫 요청이 캐시를 쓰지 않고 읽게 하는 일, 세션당 호출 수를 줄이는 일을 과제로 잡았다.
저장소 간 캐시 공유와 호출 줄이기
Cloudflare는 9월 14일부터 리뷰어별 첫 호출의 토큰 사용량과, 제공자에게 보낸 첫 시스템 블록의 해시를 기록했다. 세션 첫 요청이 캐시된 접두부를 찾은 비율은 14~26%에 그쳤다. 도구 정의와 에이전트 프롬프트 1만 1천~2만 1천 토큰은 심사하는 모든 저장소에서 똑같아 대부분 적중해야 했다.
원인은 OpenCode v1이 시스템 프롬프트를 만드는 방식이었다. 에이전트 프롬프트에 작업 디렉터리와 날짜가 든 환경 섹션을 이어 붙여 블록 하나로 만들고, 캐시 중단점을 그 끝에만 뒀다. 공통 부분이 따로 저장되지 않아 한 저장소의 리뷰가 쓴 캐시를 다른 저장소의 리뷰가 읽을 수 없었다.
9월 16일 Cloudflare는 모든 에이전트 프롬프트 끝에 표식을 넣고, 이 표식에서 블록을 둘로 나누는 플러그인 훅을 추가했다. 앞 절반은 모든 작업이 공유하는 바이트로 끝나며 자체 중단점을 갖는다. 이를 유지하려고 저장소별 내용을 앞에서 뺐다. 사용 가능한 스킬 목록을 끄고 도구 설명이 작업마다 바뀌지 않게 했다. 같은 날 Codex 리뷰어의 참조 색인(내부 표준 표, 스킬 파일, 참조 파일 목록)도 프롬프트에 넣었다. 그 전에는 세션이 처음 세 턴을 도구 호출로 파일을 읽는 데 썼다. 이 리뷰어의 실행당 LLM 호출은 15.9회에서 9.6회로, 실행당 비용은 1.12달러에서 0.72달러로 줄었다. 두 조치로 리뷰당 비용은 2.47달러에서 2.02달러가 됐다.
9월 21일과 23일에는 개별로는 눈에 띄지 않지만 합치면 리뷰당 약 0.20달러를 깎는 변경이 배포됐다.
| 변경 | 당시 문제 | 효과 |
|---|---|---|
| 쓸 수 없는 도구 제거 | 하위 리뷰어가 최종 코멘트 게시 도구를 보고 세션의 57~76%에서 호출을 시도했다가 서버 검사에서 거부당했다 | 낭비 호출 한 번 제거, 하위 리뷰어 요청마다 도구 정의 약 2.9k 토큰 감소 |
| 파일 병렬 읽기 | 코드 품질 리뷰어 턴의 64%가 도구를 정확히 한 번만 호출했고 대개 파일 하나를 읽었다 | 첫 응답에서 공유 맥락과 담당 패치를 최대 150KB까지 한꺼번에 읽는다 |
| 재리뷰에서 리뷰어 생략 | 작업의 약 3분의 2가 같은 머지 리퀘스트의 두 번째 이후 리뷰이고, 리뷰어 셋이 볼 새 내용이 없는 경우가 많다 | 전체 등급 재리뷰에서 AGENTS.md 리뷰 56%, 성능 리뷰 23%, 문서 리뷰 13% 생략 |
| 리뷰 게시 후 중단 | OpenCode가 결과를 모델에 한 번 더 넘겨 대화 전체를 다시 읽고 아무도 보지 않는 요약을 썼다 | 작업당 약 0.07달러 절감 |
| 느린 리뷰어와 제공자 장애 구분 | 시간 제한에 걸린 리뷰어를 제공자 장애처럼 같은 제한으로 재시작했다 | 시간 제한 연장, 낮은 추론 강도와 함께 보안 리뷰어 타임아웃이 1.8%에서 거의 사라졌다 |
| 취소된 작업 중단 | GitLab의 Kubernetes executor가 취소를 스크립트에 알리지 않아 취소된 446건 중 358건이 리뷰 종료까지 계속 실행됐다 | 작업이 15초마다 자기 상태를 확인하고 취소됐으면 멈춘다 |
가장 손이 많이 간 변경은 세 리뷰어가 접두부 하나를 공유하게 한 일이다. 코드 품질, 보안, 성능 리뷰어는 같은 도구, 공통 규칙 파일, 전체 패치가 들어간 머지 리퀘스트로 동일한 첫 요청을 보낸다. 각자의 지침은 그 뒤에 붙는다. 캐시 항목은 이를 쓴 응답이 스트리밍을 시작해야 읽을 수 있고 세 리뷰어는 동시에 출발하므로, 둘째와 셋째 리뷰어는 첫째의 응답이 시작될 때까지 최대 20초 기다렸다가 첫 요청을 보낸다. 조금 느려지는 대신 리뷰어당 약 9센트를 아낀다.
리뷰어는 OpenCode v2로 옮겼다. v1을 처음부터 다시 쓴 버전이다. 모든 카나리 저장소의 리뷰를 v1과 v2로 함께 돌리는 섀도 모드에서 시험했고, 시험한 머지 리퀘스트의 98%에서 두 버전의 승인 판단이 같았다. 그래서 10월 초 한꺼번에 전환하고 v1 코드를 지웠다. 같은 모델로 이틀을 비교하면 v2의 전체 등급 리뷰가 약 13% 빨리 끝난다. Cloudflare는 Durable Objects와 pi-durable만으로 리뷰어를 돌리는 방식도 시험 중이라고 했다.
모델과 추론 강도 조정
절감액 1.67달러 중 코드 변경은 0.65달러, 모델과 추론 강도 변경은 1.06달러다. Cloudflare는 각 변경 전후의 평일 시간대를 비교했을 뿐이라 통계적으로 엄밀한 통제 실험은 아니라고 밝혔다.
조정자 에이전트는 8월부터 모델과 강도 조합 세 가지를 쓰고 있었다. 같은 모델에서 중간 강도가 전체 등급 작업을 20% 빨리 끝내 나머지 둘은 버렸다. 이후 무작위 분할 시험에서 Opus 5.5 중간 강도는 Opus 5와 견줘 리뷰 결과와 치명적 발견에 측정 가능한 차이가 없어 Opus 5.5로 바꿨다. Opus 5.5 높은 강도는 중간 강도보다 비용만 더 들고 발견은 의미 있게 늘지 않았다.
Opus 5.5는 Opus 5보다 토큰당 싸지만 이 단가 차이가 설명하는 비용 하락은 약 0.20달러에 그친다. 나머지는 보내고 생성하는 토큰이 줄어서 생겼다. 9월 초 이후 리뷰당 캐시 읽기는 82%, 캐시 쓰기는 54%, 출력은 67% 감소했다.
가장 최근 변경은 Sonnet 모델이다. 10월 3일 Cloudflare는 모든 Sonnet 리뷰어를 Sonnet 5와 Sonnet 5.5에 반반 나눴다. 이틀 반 뒤 Sonnet 5.5의 실행당 비용은 코드 품질 62%, 성능 58%, 보안 47% 낮았다. 두 모델의 토큰 단가는 같아서 절감은 전부 토큰 사용량 감소에서 나왔다. 전체 등급 리뷰에서 치명적 발견과 경고가 Sonnet 5와 비슷하게 올라와 10월 5일 전부 5.5로 옮겼다.
Sonnet 5.5 중간 강도에서 코드 품질 리뷰어의 실행당 LLM 호출은 6.2회에서 1.7회로 줄었고, 실행의 절반 넘게가 호출 한 번으로 끝난다. 이 경우 저장소의 다른 파일은 열지 않는다. 높은 강도에서는 실행당 3.4회 호출한다. 큰 등급에서 강도를 높이면 발견이 돌아오는지 보려고 10월 5일부터 코드 품질 리뷰어를 중간과 높음으로 반반 나눴다. 하루 뒤 높은 강도는 실행당 비용이 61% 더 들고 치명적 발견과 경고가 58% 더 나왔다. 리뷰당 약 2센트 차이라 코드 품질은 높은 강도로 옮기기로 했고, 글의 비용 수치도 이를 전제로 한다.
속도와 품질
속도를 목표로 한 작업은 아니었지만 호출이 줄자 지연 시간도 줄었다. 9월 14일 이전 4주간 5분을 넘긴 리뷰는 37.9%였는데 지금은 0.7%다. 99번째 백분위 소요 시간은 4월 리뷰의 4분의 3보다 빠르다. 전체 등급 중앙값은 5분 16초에서 1분 54초로, lite 등급은 2분 58초에서 1분 14초로, trivial 등급은 77초에서 30초로 줄었다. 8월에는 중앙값이 4월 보고치보다 14%, 99번째 백분위가 48% 느렸기 때문에 이번 작업의 상당 부분은 원래 속도를 되찾은 것이다.
싼 리뷰가 문제를 덜 찾는다면 의미가 작다. 실제로 8월 말과 비교하면 Sonnet 5.5 높은 강도의 코드 품질 리뷰어는 치명적 발견과 경고를 40% 적게 올린다. 중간 강도를 유지한 보안과 성능 리뷰어는 각각 56%, 71% 적다. Cloudflare는 이 감소만으로는 실제 문제를 놓치는지 잡음이 줄었는지 알 수 없다며 두 방법으로 따져 봤다.
첫째 방법은 작성자의 반응이다. 심각한 발견 표본마다 리뷰된 커밋과 작성자의 다음 푸시를 비교해, 지적한 줄이 바뀌었으면 반영된 것으로 셌다. 발견 위치에서 30~40줄 떨어진 줄은 모든 기간에 약 15% 바뀌어 우연한 수정의 기준선이 됐다. 코드 품질 리뷰어의 심각한 발견 중 작성자가 반영한 비율은 이전 34%에서 지금 59%로 올랐다. 리뷰 1,000건당 반영된 발견은 145건에서 132건으로 오차 범위 안이다. 리뷰어 넷 전체로는 229건에서 321건으로 늘었다.
둘째 방법은 모델 판정이다. 서로 다른 제공자의 모델 둘이 Sonnet 리뷰어 셋의 발견 657건을 시기를 모른 채 해당 diff와 함께 판정했고, 의견이 갈린 건은 세 번째 모델이 가렸다. 발견은 중요, 사소, 중복, 오류, 검증 불가로, 심각도는 적정, 과대, 과소로 분류했다. 사라진 것은 대부분 사소한 발견과 일부 중복, diff만으로 검증할 수 없는 발견이었다. 리뷰당 중요한 발견은 0.28건에서 0.30건으로 구간이 겹친다. 변화가 큰 쪽은 심각도다. 실제보다 심각하다고 판정된 치명적 발견과 경고가 리뷰당 0.46건에서 0.14건으로 70% 줄었고, Cloudflare는 이를 가장 뚜렷한 결과로 꼽았다. 치명적 발견 감소의 상당 부분은 사소한 문제를 치명적이라 부르지 않게 된 데서 나온다.
결과는 리뷰어마다 다르다. 코드 품질 높은 강도에서는 사라진 것이 대부분 잡음과 부풀린 심각도였고 실제 문제는 이전과 비슷하게 찾는다. 중간 강도는 실제 발견을 잃었다. 무작위 분할에서 중간 강도는 높은 강도의 약 4분의 1만큼만 반영된 발견을 냈고, 그래서 높은 강도로 옮겼다. 성능 리뷰어는 중요한 성능 문제가 리뷰당 약 64% 줄어, 전체 등급 리뷰 24건에 중요한 발견이 하나 빠지는 수준이다. 보안은 약 4분의 1 줄었으나 통계적으로 유의하지 않다. 둘 다 중간 강도라서 높은 강도 시험이 다음 순서다.
두 방법에는 한계가 있다. 작성자가 지적된 줄을 고쳤다고 그 발견이 옳았다는 증거는 아니다. 판정자도 모델이고 그룹별 발견은 35~66건뿐이다. 지금 구간도 하루 분량이다. Cloudflare는 그럼에도 두 방법의 결과가 서로 맞고 코드 품질이 실제 문제를 덜 찾는다는 신호는 없다고 밝혔다. 판정 없이 끝난 리뷰는 0.79%에서 0.27%로, 보안 리뷰어 재시도는 3.5%에서 0.04%로 줄어 안정성도 유지됐다.
이 사례에서 가장 큰 절감은 세션 첫 요청이 제공자에게 어떻게 도착하는지 들여다본 데서 나왔다. 추론 강도를 낮추면 발견 수가 같이 줄어드는 리뷰어가 있어, 비용 비교는 리뷰어별 발견 품질과 함께 봐야 한다.
Cloudflare는 에이전트를 대량으로 돌리는 팀이라면 먼저 두 가지를 점검하라고 권했다. 각 세션의 첫 요청이 실제로 캐시를 읽는지, 그리고 지금 지불하는 추론 강도에서 리뷰어가 여전히 실제 문제를 찾는지다. 이 글을 쓴 Ryan Skidmore는 10월 20일 오후 12시 30분(태평양시간) San Francisco의 Cloudflare Connect 세션에서 리뷰어를 사 오지 않고 직접 만든 과정을 발표한다.
출처
이 기사는 아래 자료를 바탕으로 정리했습니다. 제목을 누르면 원문이 새 창으로 열립니다.
- Cutting our inference bill by 68% by being obsessive about optimization blog.cloudflare.com