AI 코드 리뷰는 이제 클라우드 워크로드(Cloud Workload)입니다

코드 리뷰는 과거에 매우 인간 중심적인 확장성 문제(Scaling problem)를 가지고 있었습니다.

Pull Request (PR)는 준비되었고, 테스트는 통과(Green)되었습니다. 하지만 충분한 맥락을 알고, 충분한 인내심을 가졌으며, 어쩌면 제대로 읽기 위해 충분한 커피를 마신 누군가가 나타날 때까지 그 상태로 방치되었습니다.

AI 코드 리뷰는 그 대기열을 변화시킵니다. GitHub Copilot은 Pull Request를 자동으로 리뷰할 수 있으며, 6월 1일부터 이러한 리뷰는 GitHub AI Credits를 소비합니다. Private Repository (비공개 저장소)의 경우, Copilot이 환경을 준비하고 코드를 분석하는 동안 GitHub Actions minutes를 소비할 수도 있습니다.

이는 놀라운 일이 아닙니다. 모델에는 비용이 듭니다. Runner (러너)에도 비용이 듭니다.

하지만 이는 제품 카테고리를 훨씬 더 명확하게 만들어 줍니다.

AI 코드 리뷰는 더 이상 단순히 도움이 되는 코멘트 봇이 아닙니다. 그것은 당신의 개발 프로세스에 의해 트리거되는 클라우드 워크로드 (Cloud workload)입니다.

그리고 클라우드 워크로드에는 예산이 필요합니다.

리뷰 버튼은 이제 인프라 결정 사항입니다

개발자 도구에는 익숙한 발전 과정이 있습니다.

처음에는 기능이 작고 로컬(Local)하게 느껴집니다. 누군가 그것을 활성화합니다. 몇몇 사람들이 사용해 봅니다. 사용량이 제한적이고 청구서가 더 큰 항목에 섞여 있기 때문에 비용은 보이지 않습니다.

그러다 채택(Adoption)이 늘어납니다.

곧 동일한 기능이 수백 개의 저장소, 수천 개의 Pull Request, 그리고 변경 사항당 여러 번의 리뷰 패스(Review passes)에 걸쳐 실행됩니다. 에디터의 편의 기능처럼 느껴졌던 제품이 운영 비용 (Operating expense)이 됩니다.

우리는 이미 CI를 통해 이를 배웠습니다.

첫 번째 파이프라인은 저렴합니다. 그다음에는 모든 커밋마다 단위 테스트 (Unit tests), 통합 테스트 (Integration tests), 보안 스캔 (Security scans), 프리뷰 배포 (Preview deployments), 브라우저 테스트 (Browser tests), 그리고 왜 추가되었는지 아무도 기억하지 못해 삭제하고 싶어 하지 않는 수십 가지의 체크 항목들이 실행됩니다.

파이프라인은 유용합니다. 동시에 그것은 청구서이기도 합니다.

AI 리뷰도 동일한 단계에 진입하고 있습니다.

GitHub의 새로운 과금 모델은 명시적입니다: 코드 리뷰는 AI Credits를 소비하며, Private Repository는 분석 중에 Actions minutes를 사용합니다. 조직(Organizations)은 기본 Runner를 구성하고 사용자 수준에서 예산을 적용할 수 있습니다.

이러한 제어 기능들은 지루하게 들릴 수 있습니다.

하지만 이것이야말로 엔지니어링 리더들이 관심을 가져야 할 부분입니다.

모든 것을 리뷰하는 것은 전략이 아닙니다

모든 곳에서 AI 리뷰를 활성화하고 싶은 유혹이 생길 수 있습니다.

왜 안 되겠습니까? 리뷰가 적은 것보다는 많은 것이 더 좋아 보입니다. 만약 봇이 보안 버그 하나, 누락된 테스트 하나, 혹은 의심스러운 API 변경 사항 하나라도 잡아낸다면, 한 달 치 비용은 충분히 뽑고도 남을 것입니다.

어떤 팀들에게는 아마 그 말이 맞을 것입니다.

하지만 그렇다고 해서 모든 리뷰가 똑같이 가치 있는 것은 아닙니다.

열 줄짜리 의존성 업데이트 (dependency bump)와 대규모 인증 리팩토링 (authentication refactor)이 반드시 동일한 대우를 받아야 하는 것은 아닙니다. 생성된 문서 변경 사항에는 AI 리뷰어가 필요하지 않을 수도 있습니다. 위험한 데이터베이스 마이그레이션 (database migration)은 아마도 한 번의 자동화된 검사와 빠른 인간의 승인 이상의 과정이 필요할 것입니다.

리뷰에 비용이 측정되기 시작하면, 다음과 같은 정책적 질문들이 피할 수 없게 됩니다.

어떤 저장소 (repositories)가 기본적으로 AI 리뷰를 요청해야 하는가?
어떤 풀 리퀘스트 (pull requests)가 자동으로 리뷰를 트리거해야 하는가?
생성된 변경 사항이 사람이 작성한 변경 사항과 동일한 리뷰 예산을 할당받아야 하는가?
코멘트가 소음 (noise)이 되기 전까지 몇 번의 리뷰 라운드가 유용한가?
각 저장소에 실제로 필요한 러너 (runner) 크기는 얼마인가?
어떤 팀이 코드베이스 분석이 더 어려워서 더 많은 비용을 지출하고 있는가?

이것들은 단순히 재무적인 질문만이 아닙니다.

이것들은 청구서를 통해 표현된 아키텍처 (architecture) 및 엔지니어링 관리 (engineering-management)에 관한 질문들입니다.

비용 귀속 (cost attribution)은 유용한 강제 함수 (forcing function)입니다

저는 비용 측정 (metering)이 무조건 나쁘다고 생각하지 않습니다.

무료처럼 보이는 인프라는 나쁜 습관을 숨기는 경향이 있습니다. 예산은 팀이 실제로 무엇을 가치 있게 여기는지 결정하도록 강제할 수 있습니다.

만약 어떤 저장소가 다른 저장소보다 훨씬 더 많은 AI 리뷰 크레딧과 러너 분 (runner minutes)을 사용한다면, 거기에는 타당한 이유가 있을 수 있습니다. 아마도 그것이 핵심 서비스일 수도 있습니다. 혹은 차이점 (diffs)이 복잡할 수도 있습니다. 또는 팀이 리뷰어를 추가적인 보안 계층으로 사용하고 있을 수도 있습니다.

아니면, 아무도 기본 설정을 확인하지 않아서 모든 아주 작은 풀 리퀘스트가 비용이 많이 드는 워크플로 (workflow)를 트리거하고 있는 것일 수도 있습니다.

유용한 결과는 어떤 대가를 치르더라도 청구서를 최소화하는 것이 아닙니다. 유용한 결과는 그 청구서가 무엇을 나타내는지 이해하는 것입니다.

CI 시간 (CI minutes)은 테스트가 너무 느리거나, 너무 광범위하거나, 혹은 너무 불안정(flaky)하다는 것을 알려줄 수 있습니다. 클라우드 비용 (Cloud spend)은 아키텍처가 너무 빈번하게 통신(chatty)하거나, 과다 할당(over-provisioned)되었거나, 캐싱(cached)이 제대로 되지 않았음을 알려줄 수 있습니다. AI 리뷰 비용 (AI review spend)은 워크플로가 모델에게 가치가 낮은 수많은 변경 사항을 검토하도록 요청하고 있다는 사실을 드러낼 수 있습니다.

비용은 아키텍처에 대한 피드백입니다.

또 다른 청구서는 리뷰어의 주의력입니다

GitHub 인보이스에는 나타나지 않는 두 번째 비용이 있습니다.

모든 AI 리뷰 코멘트는 인간에게 주의력을 소비할 것을 요구합니다.

어떤 코멘트는 유용할 것입니다. 어떤 코멘트는 기술적으로는 정확하지만 무관할 것입니다. 어떤 코멘트는 코드가 왜 이상해 보이는지 이해하지 못한 채 실제 우려 사항을 식별할 것입니다. 어떤 코멘트는 확신에 차서 더 깔끔한 구현을 제안하지만, 추하고 중요하지만 놓치기 쉬운 예외 케이스(edge case)를 조용히 깨뜨릴 수도 있습니다.

이는 가장 저렴한 AI 리뷰가 항상 최선의 리뷰는 아니라는 것을 의미합니다.

몇 크레딧의 비용만 들지만 엔지니어 두 명에게 10분의 집중력 분산을 초래하는 리뷰는 다른 방식으로 비용이 많이 듭니다. 이를 대규모 조직 전체로 곱해 보면, 더 큰 문제는 모델 사용량이 아니라 신호의 품질(signal quality)일 수 있습니다.

이것이 바로 "AI 리뷰 코멘트 수"가 형편없는 성공 지표인 이유입니다.

제가 원하는 지표는 더 실용적입니다:

AI 코멘트가 얼마나 자주 코드 변경으로 이어지는가?
어떤 카테고리의 코멘트가 일관되게 유용한가?
코멘트가 노이즈(noise)로 치부되는 빈도는 어느 정도인가?
AI 리뷰가 인간의 리뷰 시간을 줄여주는가, 아니면 또 다른 리뷰 대기열을 추가하는가?
테스트와 정적 분석(static analysis)이 놓친 결함을 잡아내는가?
봇이 이미 차이점(diff)을 확인했다는 이유로 팀들이 리뷰를 형식적으로 승인(rubber-stamp)하기 시작하는가?

목표는 더 많은 코멘트가 아닙니다.

목표는 낭비되는 주의력을 줄이면서 더 나은 변경 사항이 프로덕션(production)에 도달하게 하는 것입니다.

인간을 불편한 부분에 머물게 하세요

AI 리뷰는 광범위하고 인내심 있는 검사에 능숙합니다.

AI는 다섯 번째 유사한 파일을 읽는 것에 지루함을 느끼지 않습니다. 누락된 에러 핸들링(error handling), 의심스러운 패턴, 일관성 없는 테스트, 그리고 재검토가 필요한 변경 사항을 알아차릴 수 있습니다. 또한 인간 리뷰어가 도착하기 전에 풀 리퀘스트(pull request) 작성자에게 피드백을 줄 수 있습니다.

그것은 유용합니다.

하지만 가장 가치 있는 리뷰 질문들은 대개 불편하고 맥락적입니다:

이것이 시스템을 위한 올바른 변경인가?
이 추상화 (abstraction)가 향후 장애 발생 시 디버깅(debug)을 더 쉽게 만드는가, 아니면 더 어렵게 만드는가?
문서화되지 않은 API 계약 (API contract)을 우리가 유지하고 있는가?
마이그레이션 (migration) 계획이 운영 부하 (production load) 환경에서 현실적인가?
이 복잡성이 반드시 필요한 것인가, 아니면 생성된 코드가 그럴싸해 보였기 때문에 우리가 만들어낸 것인가?

그러한 질문에는 판단력이 필요합니다.

AI 리뷰어는 증거를 드러내는 데 도움을 줄 수 있습니다. 하지만 AI 리뷰어가 대화를 건너뛰어도 되는 이유가 되어서는 안 됩니다.

이번 주에 내가 할 일

만약 귀하의 조직이 Copilot 코드 리뷰를 사용하고 있다면, 저는 6월 1일자 청구 금액 변경을 인보이스(invoice)가 귀하를 대신해 처리하기 전에 워크플로 (workflow)를 점검할 좋은 구실로 삼겠습니다.

가시성 (visibility) 확보부터 시작하십시오. 어떤 리포지토리 (repositories)가 자동 리뷰를 사용하는지, 어떤 러너 (runners)를 사용하는지, 그리고 리뷰가 얼마나 자주 실행되는지 확인하십시오. 예산이 넉넉하더라도 일단 예산을 설정하십시오. 예산은 제한 수단이기 이전에 알림 (alerting) 메커니즘입니다.

그다음 출력 결과물을 샘플링하십시오.

몇 주간의 리뷰 코멘트 (review comments)를 가져와 분류해 보십시오. 유용한 결함 포착, 도움이 되는 제안, 스타일 선호도, 기존 체크 항목의 중복, 오답, 무시됨 등으로 분류하십시오.

첫날부터 복잡한 대시보드 (dashboard)가 필요하지는 않습니다. 스프레드시트 (spreadsheet)와 솔직한 대화가 허영 지표 (vanity metric)보다 더 많은 것을 알려줄 것입니다.

마지막으로, 파이프라인 (pipeline) 내에서 AI 리뷰가 어디에 위치해야 할지 결정하십시오.

어쩌면 핵심 서비스 (critical services)에서 자동으로 실행될 수도 있습니다. 어쩌면 작성자가 인간의 리뷰를 요청하기 전에 AI에게 먼저 요청할 수도 있습니다. 어쩌면 작은 의존성 업데이트 (dependency bumps)는 리뷰를 건너뛸 수도 있습니다. 어쩌면 보안에 민감한 변경 사항에는 더 신중한 정책이 적용될 수도 있습니다.

정답은 코드베이스 (codebase)에 따라 다를 것입니다.

그것이 핵심입니다.

결론

AI 코드 리뷰는 인프라 (infrastructure)가 되어가고 있습니다.

이는 모델 크레딧 (model credits)을 소비합니다. 러너 분 (runner minutes)을 소비할 수 있습니다. 운영 데이터 (operational data)를 생성합니다. 각 워크플로에서 기본값 (defaults), 예산, 그리고 존재해야 할 이유가 필요합니다.

그렇다고 해서 유용성이 떨어지는 것은 아닙니다.

오히려 엔지니어링 대화를 더 솔직하게 만듭니다.

"AI가 모든 것을 리뷰하게 하라"는 말은 모든 풀 리퀘스트(Pull Request)가 컴퓨팅 자원을 소모하고 모든 코멘트가 주의력을 소모하기 전까지는 생산성 전략처럼 들립니다.

AI 리뷰로부터 가치를 얻는 팀은 가장 많은 자동화된 코멘트를 생성하는 팀이 아닐 것입니다.

그들은 어떤 리뷰에 비용을 지불할 가치가 있는지를 아는 팀이 될 것입니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위해 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.