저장소(repo) 규모가 작다면 거의 모든 AI 리뷰어가 훌륭해 보입니다. 차이점은 풀 리퀘스트(Pull Request, PR)가 세 개의 패키지에 걸쳐 40개의 파일에 영향을 미칠 때 나타나며, 이때 봇이 영향 범위(blast radius)를 이해하느냐, 아니면 사소한 지적(nitpicks)으로 당신을 괴롭히느냐의 차이로 드러납니다. Greptile과 Graphite 모두 해당 사례를 처리할 수 있다고 주장하지만, 두 도구는 서로 반대되는 방향에서 코드 리뷰에 접근합니다. 하나는 코드베이스 이해 엔진(codebase-understanding engine)으로 먼저 구축되었고, 다른 하나는 나중에 AI 리뷰어를 추가한 풀 리퀘스트 워크플로우(pull-request workflow)로 성장했습니다.

우리는 팀 리더가 실제로 던지는 질문인 "신호(signal)를 묻어버리지 않으면서, 파일 간에 걸쳐 있는 버그를 잡아낼 수 있는가?"라는 동일한 질문을 두 도구에 던졌으며, 그 답은 귀하의 팀이 이미 어떻게 일하고 있는지에 따라 크게 달라집니다.

각 도구가 실제로 코드를 읽는 방식

Greptile의 핵심 가치는 전체 코드베이스 컨텍스트(whole-codebase context)입니다. 이 도구는 저장소를 심볼(symbol)과 참조(reference)의 그래프로 인덱싱(indexing)한 다음, PR을 리뷰할 때 해당 인덱스를 사용합니다. 실질적인 효과는 다음과 같습니다. 한 파일의 변경 사항이 세 파일 떨어진 곳의 가정을 깨뜨릴 때, Greptile은 차이점(diff)만을 고립시켜 리뷰하는 대신 참조를 따라가서 이를 찾아내도록 설계되었습니다. 이러한 파일 간 추론(cross-file reasoning)은 대규모 코드베이스 팀이 가장 중요하게 생각하는 기능입니다. 왜냐하면 차이점만 보는 리뷰어(diff-only reviewers, +/- 라인만 보는 도구)는 모노레포(monorepo)에서 치명적인 실패를 정확히 놓치기 때문입니다.

Graphite는 워크플로우(workflow) 측면에서 접근했습니다. 이 도구는 대규모 변경 사항을 독립적으로 배포 및 리뷰할 수 있는 작고 의존적인 차이점들로 나누는 스택형 풀 리퀘스트(stacked-pull-request) 도구로 시작했으며, 이미 확고한 철학을 가진 리뷰 플랫폼 위에 AI 리뷰어인 Diamond를 추가했습니다. 따라서 Graphite의 강점은 단순히 "AI가 무엇을 말하는가"에 그치지 않습니다. 머지 큐(merge queue), 스태킹(stacking), PR 인박스(inbox), 그리고 AI 코멘트 주변의 리뷰 인체공학(review ergonomics)이 강점입니다. 만약 귀하의 병목 현상이 많은 PR을 관리하는 데 있다면, 이는 모델의 출력 결과만큼이나 중요합니다.

이들은 하나의 접점에서 겹치는 서로 다른 제품들입니다. Greptile은 기본적으로 GitHub나 GitLab에 부착하여 사용하는 AI 리뷰어(AI reviewer)입니다. Graphite는 코드 리뷰 및 머지 플랫폼(merge platform)이며, 여기서 AI 리뷰어는 여러 기능 중 하나입니다. 단순히 "누가 더 많은 버그를 찾아내는가"로만 이들을 비교하는 것은 실제 도입 시 고려해야 할 가치를 과소평가하는 것입니다.

규모가 커질 때 발생하는 문제점

데모 수준의 리뷰어와 대규모 코드베이스(large codebase)에서 신뢰할 수 있는 리뷰어를 구분 짓는 세 가지 요소가 있습니다.

인덱싱(Indexing) 및 최신성(freshness). 그래프 기반(graph-based) 리뷰어는 인덱스를 구축하고 유지 관리해야 합니다. 대규모 저장소(repo)에서는 첫 인덱싱에 시간이 걸리며, 오래된 인덱스는 확신에 찬 오답(confidently wrong) 댓글을 생성합니다. Greptile의 모델은 인덱스가 최신 상태임을 전제로 합니다. 따라서 정확도를 판단하기 전에, 해당 모델이 기본 브랜치(default branch)의 인덱싱을 완료했는지 확인하십시오. Graphite의 리뷰어는 사용자가 여는 PR(Pull Request)에 종속되어 있어, 별도의 전체 저장소 인덱싱 과정을 우회하지만, 이는 곧 컨텍스트 윈도우(context window)가 디프(diff)와 플랫폼의 디프 이해도에 의해 결정됨을 의미합니다.

신호 대 잡음비(Signal-to-noise). 대규모 환경에서 AI 리뷰가 실패하는 방식은 버그를 놓치는 것이 아니라, 바로 '양(volume)'의 문제입니다. 9개의 스타일 관련 지적(nits)과 1개의 실제 동시성 버그(concurrency bug)를 남기는 리뷰어는 팀원들이 10개 모두를 무시하도록 학습시킵니다. 두 도구 모두 이를 조정(tune)할 수 있게 해주지만, 조정 작업은 실제적인 노력이 필요합니다. 댓글이 읽을 가치가 있다고 느껴질 때까지 심각도 임계값(severity thresholds)을 조절하고 카테고리를 뮤트(muting)하는 데 1~2주 정도의 시간이 걸릴 것을 예상하십시오. 이를 위한 예산을 고려해야 합니다.

대규모 PR에서의 지연 시간(Latency). 봇이 리뷰하는 데 8분이 걸리는 50개 파일 규모의 PR은 사람들이 도구를 사용하는 방식을 변화시킵니다. 충분히 빠른 피드백은 작성자가 여전히 맥락(context) 안에 있을 때 읽히지만, 느린 피드백은 작성자가 다른 작업으로 넘어간 뒤 대충 훑어보게 됩니다.

두 도구 모두 장난감 같은 작은 PR(toy PR)로 측정하지 마십시오. 실제 가장 크고 복잡한 풀 리퀘스트(pull requests) — 즉, 패키지 간 리팩터링(cross-package refactors)이나 마이그레이션(migrations) — 를 대상으로 한 달간의 시험 운영을 실시하십시오. 그것만이 코드베이스를 인식하는 리뷰어(codebase-aware reviewer)와 디프 전용 리뷰어(diff-only reviewer)를 구분할 수 있는 유일한 워크로드이며, 데모에서는 절대 보여주지 않는 워크로드입니다.

가격 및 팀 적합성

두 도구 모두 사용자(seat)당 비용을 책정하며, 현재 공개된 가격 수치는 자주 변동되므로 이 글을 포함한 그 어떤 리뷰의 인용 수치를 신뢰하기보다는 실시간 가격 페이지를 직접 확인하는 것이 좋습니다. 더 유용한 질문은 당신이 무엇을 위해 비용을 지불하고 있는가 하는 점입니다.

Greptile의 경우, 당신은 리뷰어와 그 인덱스(index)에 비용을 지불합니다. 만약 당신의 코드가 이미 선호하는 워크플로(workflow, 예: 일반적인 GitHub PR) 내에 있다면, Greptile을 AI 레이어(layer)로 추가하기만 하면 되며 다른 것은 변경할 필요가 없습니다.

Graphite의 경우, 리뷰어는 플랫폼 전환(platform shift)과 함께 제공됩니다. Graphite를 도입한다면, 종종 스택형 디프(stacked diffs)와 Graphite의 머지 큐(merge queue)도 함께 도입하게 됩니다. 이는 사람들이 일하는 방식에 더 큰 변화를 가져옵니다. 만약 당신의 팀이 기존의 일반적인 PR 방식에 만족하고 있다면 이는 비용(부담)이 될 것이고, PR 관리가 진정한 병목 현상(bottleneck)이라면 이는 이점이 될 것입니다.

실질적인 판단 기준: 만약 당신의 고충이 "리뷰가 파일 간 버그(cross-file bugs)를 놓친다"는 것이라면 Greptile의 코드베이스 인식 리뷰(codebase-aware reviewing)를 고려하십시오. 만약 당신의 고충이 "PR이 너무 많고 머지(merge) 과정이 혼란스럽다"는 것이라면, Graphite의 플랫폼은 단독 리뷰어(standalone reviewer)가 건드리지 못하는 문제를 해결해 줄 것입니다.

두 도구 모두 인간 리뷰어를 대체할 수는 없으며, 애초에 리뷰 가능한 코드를 작성해야 하는 작업 자체를 대체할 수도 없습니다. 더 작고 명확한 디프(diff)를 작성할 수 있도록 돕는 AI 보조 에디터(AI-assisted editor)를 사용하면, 봇이 PR을 확인하기 전부터 리뷰 부하를 줄일 수 있습니다.

어떤 것을 선택해야 할까

단 하나의 승자는 없으며, 어느 하나가 승자라고 선언하는 리뷰는 두 도구가 팀에 얼마나 다르게 적합한지를 간과하는 것입니다. 당신의 실제 제약 사항에 따라 선택하십시오:

• 대규모 저장소(repo)에서 파일 간에 걸친 버그를 리뷰가 놓치는 경우: Greptile로 시작하되, 정확도를 판단하기 전에 인덱스(index)가 기본 브랜치(default branch)를 제대로 커버하는지 확인하십시오.
• PR 및 머지(merge) 관리가 병목 현상인 경우: Graphite를 플랫폼으로서 평가하되, Diamond를 핵심 기능이 아닌 보너스로 취급하십시오.
• 확신이 서지 않는 경우: 가장 까다로운 PR들을 대상으로 한 달 동안 두 도구를 모두 시험해 보고, 하나의 지표를 추적하십시오. 바로 팀이 AI의 코멘트를 실제로 수용하는지, 아니면 무시하는지의 비율입니다. 코멘트의 단순 개수가 아니라 그 비율이 어떤 도구가 신뢰를 얻었는지 알려줄 것입니다.

무엇을 선택하든, 최종 관문은 인간으로 유지하십시오. AI 리뷰는 넓은 범위를 스캔하고 지친 리뷰어가 그냥 지나칠 수 있는 파일 간 이슈 (cross-file issue)를 찾아내는 데는 뛰어나지만, 해당 변경 사항이 존재해야 하는지 여부를 판단하는 데는 능숙하지 않습니다.