AI 코드 리뷰어 비용 68% 절감 및 성능 최적화 달성

AI 코드 리뷰 시스템의 변화

AI 코드 리뷰 시스템의 평균 리뷰 비용이 $2.43에서 $0.77로 68% 절감되었다. 이와 함께 중앙값 리뷰 시간은 4분 09초에서 1분 32초로 단축되었다. 이러한 개선은 9월 중순부터 시작된 비용 최적화 노력의 결과이다. 전체 절감액 중 약 40%는 리뷰어 코드의 변경 및 최적화에서, 나머지 60%는 사용 모델 및 노력 수준 조정에서 비롯되었다.

주요 변경 사항으로는 OpenCode v1에서 v2로의 전환, Anthropic 모델 및 Sonnet 5.5와 같은 최신 모델 도입, 그리고 캐시 활용 방식 및 대규모 언어 모델(LLM) 호출 횟수 최적화 등이 포함된다. 이러한 다각적인 접근을 통해 비용 효율성과 성능을 동시에 향상시켰다.

비용 증가의 배경과 원인

이전 4월에 평균 $1.19였던 리뷰 비용은 8월 말에 약 $2.46으로 급증했다. 월별 평균 비용은 3월 $1.22에서 6월 $1.44, 7월 $1.74, 그리고 8월 $2.32로 꾸준히 상승했다. 이러한 비용 증가는 주로 모델 변경에 기인한다.

8월 초 모든 리뷰어를 Anthropic 모델로 전환하면서 작업당 비용이 $1.38에서 $2.03으로 상승했다. 이는 Anthropic 모델이 특정 워크로드에서 더 나은 성능을 보였기 때문이다. 또한, 내부 표준 리뷰어인 Codex는 Claude Opus 4.7로 전환되며 리뷰당 비용이 약 $0.25에서 $0.88로 증가했다. 캐시 적중률은 4월 85.7%에서 9월 97%로 개선되었지만, 리뷰당 토큰 수는 0.91백만에서 2.99백만으로 세 배 이상 증가하여 캐시 읽기 비용이 낮음에도 불구하고 총 비용이 증가하는 결과를 초래했다.

비용 지출의 대부분은 캐시 쓰기(43%)와 캐시 읽기(34%)에 집중되었으며, 이는 모델이 이미 처리했거나 다시 처리할 컨텍스트에 대한 비용이었다. 평균적으로 코드 품질 리뷰어는 리뷰당 16.6회의 LLM 호출을 수행했으며, 각 호출은 전체 대화를 컨텍스트로 전송하여 세션 비용이 호출 횟수와 컨텍스트 크기에 비례하여 증가했다.

캐시 및 LLM 호출 최적화 전략

비용 최적화를 위해 OpenCode v1에서 v2로의 전환이 이루어졌다. v2는 v1을 전면 재작성한 버전으로, 10월 초 모든 리뷰가 v2로 전환되었다. 비교 테스트에서 v1과 v2는 98%의 병합 요청에서 승인 결정이 일치했으며, v2의 풀 티어 리뷰는 약 13% 더 빠르게 완료되었다.

캐시 활용 효율성 개선을 위해 9월 16일 에이전트 프롬프트 끝에 마커를 추가하고 플러그인 훅을 통해 블록을 분할하여 공유 가능한 접두사(prefix)가 독립적으로 캐시되도록 했다. 이전에는 OpenCode v1의 시스템 프롬프트 구성 방식 때문에 공유 부분이 독립적으로 저장되지 않아 다른 저장소에서 재사용할 수 없었다. 이 변경으로 리뷰당 비용이 $2.47에서 $2.02로 감소했다.

LLM 호출 횟수를 줄이기 위한 여러 코드 변경도 적용되었다. 9월 21일과 23일에 배포된 변경 사항들은 리뷰당 약 $0.20의 추가 절감을 가져왔다. 여기에는 서브 리뷰어가 사용할 수 없는 도구 제거, 파일 병렬 읽기, 재검토 시 불필요한 리뷰어 건너뛰기, 리뷰 게시 후 불필요한 요약 작성 중단, 느린 리뷰어 처리 방식 개선, 취소된 작업의 즉시 중단 등이 포함된다. 특히 코드 품질, 보안, 성능 리뷰어가 동일한 첫 요청을 보내고, 한 리뷰어가 캐시에 쓰고 다른 두 리뷰어가 읽도록 하여 캐시 재사용을 극대화했다.

모델 및 노력 수준 조정의 효과

모델 및 노력 수준 변경은 전체 절감액의 더 큰 부분을 차지했다. 8월부터 코디네이터는 세 가지 모델 및 노력 조합을 실행했으나, 동일 모델에서 중간 노력 수준의 풀 티어 작업이 20% 더 빨리 완료되는 것을 확인하고 다른 두 가지를 중단했다. Opus 5.5 중간 노력 수준은 Opus 5와 비교하여 리뷰 결과나 중요 발견 사항에 측정 가능한 변화가 없어 Opus 5.5로 전환되었다. Opus 5.5는 Opus 5보다 토큰당 비용이 저렴하며, 이는 약 $0.20의 비용 절감에 기여했다. 나머지 절감은 더 적은 토큰을 전송하고 생성하는 데서 비롯되었다. 9월 초 이후 리뷰당 캐시 읽기는 82%, 캐시 쓰기는 54%, 출력은 67% 감소했다.

10월 3일에는 모든 Sonnet 리뷰어를 Sonnet 5와 Sonnet 5.5로 50/50 분할했다. 2.5일 후 Sonnet 5.5는 코드 품질에서 실행당 62%, 성능에서 58%, 보안에서 47% 더 저렴한 것으로 나타났다. 두 모델의 토큰당 비용은 동일하므로, 이는 모두 더 적은 토큰 사용에서 비롯된 결과이다. 풀 티어 리뷰에서 Sonnet 5.5 리뷰어는 Sonnet 5와 거의 동일한 수의 중요 및 경고 발견 사항을 게시하여 10월 5일 모든 리뷰어를 5.5로 전환했다.

Sonnet 5.5 중간 노력 수준에서 코드 품질 리뷰어는 실행당 6.2회 대신 1.7회 LLM 호출을 수행하며, 절반 이상이 단일 호출로 완료된다. 높은 노력 수준에서는 실행당 3.4회 호출한다. 10월 5일부터 코드 품질 리뷰어는 5.5 모델에서 중간 및 높은 노력 수준으로 50/50 분할 테스트되었다. 하루 후, 높은 노력 수준은 실행당 61% 더 많은 비용이 들었지만 58% 더 많은 중요 및 경고 발견 사항을 게시하여, 코드 품질 리뷰는 높은 노력 수준으로 전환되고 있다.

개발자 경험 및 리뷰 품질에 미치는 영향

이번 최적화 작업은 리뷰 속도 향상에도 기여했다. 9월 14일 이전에는 37.9%의 리뷰가 5분 이상 소요되었으나, 현재는 0.7%만이 그렇다. 99번째 백분위수 리뷰 시간은 4월의 75% 리뷰보다 빨라졌다. 풀 티어 리뷰의 중앙값은 5분 16초에서 1분 54초로, 라이트 티어는 2분 58초에서 1분 14초로, 트리비얼 티어는 77초에서 30초로 단축되었다. 이는 개발자들이 더 빠르게 피드백을 받을 수 있게 되었음을 의미한다.

비용 절감에도 불구하고 리뷰 품질은 유지되거나 개선되었다. 코드 품질 리뷰어(높은 노력 수준)는 이전과 거의 동일한 수의 실제 문제를 발견하며, 불필요한 노이즈와 과장된 심각도가 크게 줄었다. 저자들이 리뷰어의 심각한 발견 사항에 조치하는 비율은 34%에서 59%로 증가했으며, 1,000회 리뷰당 조치로 이어진 발견 사항 수는 145개에서 132개로 거의 동일하게 유지되었다. 모든 4개 리뷰어에서 조치로 이어진 심각한 발견 사항은 1,000회 리뷰당 229개에서 321개로 증가했다.

모델 평가 결과, 사라진 대부분은 사소한 발견 사항, 중복, 또는 검증 불가능한 발견 사항이었다. 중요한 발견 사항 수는 리뷰당 0.28개에서 0.30개로 거의 변화가 없었다. 특히 심각도 평가에서, 과장된 심각도로 평가된 중요/경고 발견 사항의 비율이 리뷰당 0.46개에서 0.14개로 70% 감소하여, 리뷰어가 사소한 문제를 중요하게 분류하는 경향이 크게 줄었음을 보여준다. 신뢰성 또한 향상되어, 판정 없이 종료되는 리뷰는 0.79%에서 0.27%로, 보안 리뷰어 재시도는 3.5%에서 0.04%로 감소했다.

최적화의 한계 및 향후 과제

이번 최적화 작업에도 불구하고 몇 가지 한계점과 향후 과제가 존재한다. 중간 노력 수준에서는 실제 발견 사항이 감소할 수 있다는 점이 확인되었다. 코드 품질 리뷰어의 경우 중간 노력 수준에서 높은 노력 수준의 약 1/4에 해당하는 조치로 이어진 발견 사항을 보였다. 이는 비용 절감과 품질 유지 사이의 균형점을 찾는 것이 중요함을 시사한다.

성능 리뷰어는 중간 노력 수준에서 실제 발견 사항이 감소했으며(리뷰당 중요한 성능 문제 약 64% 감소), 보안 리뷰어도 약 25% 감소했지만 통계적으로 유의미하지는 않다. 이 두 리뷰어는 현재 중간 노력 수준에 머물러 있으며, 높은 노력 수준에서의 추가 테스트가 필요하다. 이는 각 리뷰어의 특성과 중요도에 따라 적절한 노력 수준을 개별적으로 설정해야 함을 의미한다.

리뷰 품질 평가 방법론에도 한계가 있다. 저자가 플래그된 라인을 변경했다고 해서 발견 사항이 항상 옳았다는 의미는 아니며, 평가 모델 자체도 모델이라는 점, 그리고 각 그룹의 발견 사항 수가 35~66개로 적다는 점, '현재' 기간의 데이터가 단 하루치라는 점 등이 제약으로 작용한다. 그럼에도 불구하고 두 가지 평가 방법이 서로 일치하며 코드 품질이 실제 문제를 덜 발견한다는 증거는 없었다. 에이전트를 대량으로 운영하는 경우, 각 세션의 첫 요청이 캐시에서 읽는지 여부와 지불하는 노력 수준에서 리뷰어가 여전히 실제 문제를 찾는지 확인하는 것이 중요하다.