배경 및 맥락
AI code review는 단순히 diff를 요약하는 기능에서 벗어나, 변경된 코드 주변을 탐색하고 repository의 invariant를 확인한 뒤 실제 결함만 지적하는 agent workflow로 진화하고 있다. 이 과정에서 같은 모델을 써도 어떤 도구를 노출하고, 탐색 순서를 어떻게 안내하며, 충분한 증거의 기준을 어디에 두는지에 따라 token 비용과 comment 품질이 크게 달라진다.
GitHub은 Copilot code review의 탐색 도구를 자체 도구에서 Copilot CLI와 공유하는 Unix-style grep, glob, view로 바꾸면서 이 문제를 직접 관찰했다. 유지보수성이 높은 도구로의 단순 교체가 자동으로 성능 향상을 보장하지 않았다는 점이 핵심이다.
핵심 내용
GitHub이 공유한 사례에서 도구 교체 직후에는 review cost가 높아지고 발견되는 issue가 줄었다. 이후 팀은 PR diff에 anchor를 둔 custom tool instruction, tool trace, 내부 benchmark를 결합해 agent가 먼저 범위를 좁히고 독립 검색을 묶으며 필요한 근거가 있을 때만 파일을 읽도록 조정했다.
측정은 최종 comment의 품질만 보지 않았다. agent가 diff와 관련된 evidence를 찾았는지, 넓은 탐색을 반복하지 않았는지, tool error가 줄었는지, 동일한 review example에서 trace가 어떻게 달라졌는지를 함께 비교했다. 그 결과 production에서 quality를 막을 만한 신호 없이 average review cost가 약 20% 낮아졌다고 GitHub은 밝혔다.
경쟁 구도 / 비교
일반적인 agent 개선은 더 좋은 모델이나 더 많은 도구를 추가하는 방식에 치우치기 쉽다. 그러나 이 사례는 shared tool 자체가 핵심 해결책이 아니며, 도구의 semantics와 instruction이 작업 형태에 맞아야 한다는 반례를 제공한다. tool description과 system instruction은 에이전트에게는 API documentation처럼 행동한다.
GitHub은 같은 focused instruction을 interactive CLI에 적용했을 때 동일한 이득이 없었다고도 설명한다. code review는 명확한 diff와 review question에 묶여 있지만 CLI 작업은 사용자가 여러 턴에 걸쳐 목표를 바꾸고 넓은 탐색 자체가 필요한 경우가 많다. 따라서 한 작업의 cost optimum을 다른 agent surface에 그대로 복제하면 품질을 해칠 수 있다.
의미
생산 환경의 agent quality는 단일 benchmark score가 아니라, 모델·도구·instruction·관측성·평가 루프가 결합된 시스템 특성이다. AI code review가 보편화될수록 조직의 비용은 호출 단가보다 불필요한 tool exploration, false positive로 인한 재검토, reviewer 신뢰 하락에서 새기 쉽다.
개발 도구 팀은 task별 golden PR set, expected finding, 허용 가능한 review latency, tool trace budget을 정의해야 한다. 배포 뒤에는 cost per accepted finding, false positive, first-review latency, review cycle, tool-call distribution을 함께 모니터링하고, prompt나 도구 변경을 A/B test로 검증하는 것이 바람직하다.