Gemini의 리뷰는 보조 자료 수준에 그쳤다. 버그 수정 PR 40건으로 Claude와 익명 심사 대결을 펼치다 (총 3회)

저는 C#에서 GPU용 코드를 생성하는 자체 컴파일러(Henicos)를 LLM 에이전트만으로 개발하고 있습니다. 인간은 코드 한 줄도 작성하지 않았습니다.

이 시리즈에서는 Gemini와 Claude를 제가 만든 코드로 비교해 왔습니다. 1차에서는 중복을 찾는 벤치마크에서 Claude가 Gemini Flash보다 약 2배 많은 결과를 찾아냈습니다. 2차에서는 주력으로 Claude를 사용하고, Gemini는 외부의 두 번째 리뷰어 역할로 남겨두었습니다.

이번이 마지막 회입니다. 2차에서 남긴 'Gemini를 두 번째 리뷰어로 사용하는 것'은 정말 도움이 될까요? 알고 싶은 것은 다음 한 가지입니다.

Gemini가 작성한 리뷰가 Claude가 다시 한번 확인해야 하는 '보조 자료'에 그칠지, 아니면 사람이 거의 보지 않아도 LGTM(Looks Good To Me)으로 통과시킬 수 있는 결과물이 될 수 있는지 말입니다.

그래서 실제로 쌓여 있던 버그 수정 PR 40건을 Gemini와 Claude에게 동일한 지침서로 각각 리뷰하게 했습니다. 그 결과는 작성자를 숨긴 심사위원에게 판정받았습니다.

먼저 결론부터 말씀드립니다.

결론: Gemini의 리뷰는 Claude의 확인이 필요한 '보조 자료'에 머문다. 제시된 지적 사항은 대체로 맞지만, 'LGTM'이라는 결론과 '확인했다'라는 서술은 신뢰하기 어렵다.

• Gemini가 제시한 실제 지적 19건은 모두 내용이 정확했습니다. 하지만 이 모든 것을 Claude도 찾아냈습니다. 오직 Claude만이 발견한 실제 지적은 66건이었고, 그중 병합을 막아야 하는(blocking) 것은 12건이었습니다.
• Gemini는 blocking 이슈가 있는 12개 PR 모두를 'blocking 없음'으로 결론 내렸으며, 이 중 다수에는 'Ready to merge', 'LGTM'이라고 작성되어 있었습니다.
• Gemini의 서술에는 존재하지 않는 타입명, 테스트명, 줄 번호 인용이 6건 있었습니다. '읽고 확인했다'라고 적은 지적 중에는 인용한 코드가 실제로 존재하지 않는 경우도 있었습니다. Claude의 오류는 1건이었습니다.
• 한편,
  심사위원으로서의 Gemini는 유용했습니다. 두 LLM의 리뷰와 인간 심사위원이 놓친 CI 실패를, 오직 Gemini의 심사위원만이 발견했습니다.

아래에 대상 PR, 대결 조건, 판정 방법, 결과, 그리고 결론 순서로 작성하겠습니다.

계기는 리팩토링 결과를 Claude에게 코드 리뷰를 시켰기 때문이었습니다. 버그가 너무 많이 발견되어 도중에 계획을 변경하여 버그 찾기로 전환했습니다.

• 제가 Claude에게 내린 지침은 'src 전체에 /code-review를 가해달라'는 정도의 대충한 것이었습니다. 구체적인 사양이나 의심스러운 부분은 전달하지 않았습니다.
• Claude(오케스트레이터)가 이를 스스로 계획으로 정리했습니다. src를 19 단위로 나누고, 19명의 리뷰어를 병렬로 돌리고 있습니다. 리뷰어에게의 지침은 '버그만 찾을 것. 구체적인 입력과 C#라면 어떻게 될지 손으로 계산해서 쓸 것. 코드는 실행하지 말 것'이었습니다.
• 소견은 109건 나왔습니다. 그중 83건을 다른 작업 트리를 이용해 실제로 돌려 재현을 시도했고, 78건이 재현되었습니다.
• 재현된 것을 issue로 만들었습니다. 잘못된 결과를 반환하는 것(M1)이 41건입니다. 모두 재현 절차와 기대 결과가 첨부되어 있습니다.
• 또 다른 Claude 에이전트(약 14개 병렬)에게 M1의 issue를 하나씩 고치게 하고 PR로 만들었습니다. 이번 40건이 그것입니다.

즉, 버그 발견도 수정도 인간의 대충한 한마디에서 LLM이 스스로 계획을 짜서 진행한 것입니다. 따라서 PR 중에는 '애초에 버그가 아니다(사양대로)'인 것이 섞여 있을 가능성이 있습니다.

리뷰 전에, 40건의 issue가 주장하는 동작이 정말 계약 위반인지 Claude에게 하나씩 확인하게 했습니다.

마지막 4건은 'System.Linq에 맞출지, GPU 명령에 맞출지'처럼 무엇을 사양(specification)으로 할지에 따라 답이 달라지는 것이었습니다. 사람(저자)이 판단하여 4건 모두 PR의 구현대로를 사양으로 결정했습니다. 결과적으로 40건 모두 버그 수정으로서 타당했습니다.

• 수정되었는가: issue의 재현 및 기대값에 대해, 수정이 증상을 사라지게 했는지 여부. - 테스트가 본질적인가: 추가된 테스트가, 수정 이전에 실제로 실패하는지 (수정만 되돌려서 실행). - 규칙을 위반하지 않았는가: 프로젝트의 의미론적 헌장, 진단 방침, 테스트 및 구조 규칙.

주장에는 모두 파일:줄을 붙이고, "실행하여 확인했는지" 또는 "읽기만 했는지"를 쓰도록 했습니다. GPU를 사용하는 테스트는 모든 레인에서 공유 잠금(lock)을 확보한 후 실제 장치에서 실행하고 있습니다.

Gemini가 먼저 리뷰를 GitHub에 게시했기 때문에, Claude에게는 PR의 댓글과 리뷰 읽기를 금지했습니다. Claude의 결과는 게시하지 않고 파일에 작성하도록 했습니다.

어느 쪽 지적이 '진짜'인지는 두 명의 심사위원에게 개별적으로 판정하게 했습니다.

• 심사위원 1 (Claude Opus 5.5): 먼저 판정했습니다. 다만, 어느 것이 어떤 리뷰인지 알고 있는 상태였습니다. Claude가 자신의 편에 치우치는 경향이 있을 수 있습니다. - 심사위원 2 (Gemini 4 Argon): 편향성을 상쇄하기 위해, 익명으로 하여 판정하게 했습니다. - 두 리뷰의 댓글과 실행 로그를 PR마다 r

• 16진수 6자리 무작위 ID 폴더에 복사했습니다. ID는 PR마다 재할당하고, 어느 것이 먼저 오는지도 무작위로 했습니다. - "Gemini", "Claude"와 같은 모델명, 작성자가 알 수 있는 경로, 맨 앞의 정형 문구를 삭제했습니다.

• 원본 리뷰, 심사위원 1의 결과, GitHub 상의 PR 댓글을 읽는 것을 금지했습니다.

• 대응표는 저자만 가지고 있습니다. 판정 후에 ID를 다시 지정하여 집계했습니다.

• 문체의 차이까지는 지울 수 없기 때문에, 내용을 읽으면 추측할 수 있는 정도의 익명화입니다.

• 두 리뷰의 댓글과 실행 로그를 PR마다-

• 판정 기준 (두 심사위원 모두 동일):-
  real
  (주장이 올바름)/false
  (주장이 틀림)/unclear

• blocking
  (잘못된 결과, 빌드 실패, 진단 없는 실패, main과의 충돌, CI 실패, 이슈를 닫는 데 수정되지 않음)/non-blocking

• 결정 방법은,
  git merge-tree로 main과의 충돌을 확인하고, gh pr checks로 CI를 보고, 인용된 파일:줄을 열어 실제로 존재하는지 확인하며, 실행 로그가 주장을 뒷받침하는지 확인하는 순서입니다. 인용된 코드가 존재하지 않으면 false-

120줄이 넘는 지적은 양쪽 모두 거의 전 건에서 나왔기 때문에 집계에서 제외했습니다.

결과 1: Gemini만 발견한 진짜 지적은 0건. Claude만 발견한 진짜 blocking은 12건. 두 심사위원의 의견이 일치했습니다.

익명으로 판정한 심사위원 2 (Gemini 4 Argon)의 결과입니다. 총 92건의 지적을 판정했습니다.

| Gemini 리뷰 | Claude 리뷰 | 양쪽 모두 지적 |
|---|---|
| 진짜 지적 (한 쪽만) | 0 | 66 | 19 |
| うち blocking | 0 | 12 | 1 |
| 잘못된 지적 | 6 | 1 | 0 |

심사위원 1 (Claude Opus 5.5, 작성자를 알고 있음)의 결과도 거의 동일했습니다.

| 심사위원 1 (Claude) | 심사위원 2 (Gemini, 익명) | |
|---|---|
| 한쪽에서만 발견된 실제 blocking | Claude 12, Gemini 0 | Claude 12, Gemini 0 (12건의 내용도 일치) |
| ... |
두 명의 심사위원 모두에게서, blocking이 있는 12건은 단 하나도 빠짐없이 일치했습니다. 차이는 오기(誤り)를 세는 방식에 있을 뿐이며, 심사위원 2는 리뷰 본문에 있는 잘못된 인용까지 계산하고 있습니다. Claude의 심사위원이 자신에게 관대했다는 것은 아니었습니다. 오히려 Claude의 리뷰에서 발견된 오기 1건은 Gemini의 심사위원만이 찾아냈습니다.

결과 2: Gemini는 blocking이 있는 12건의 PR 전체를 'blocking 없음'으로 판단했습니다.

Gemini의 리뷰는 blocking이 있는 12건의 PR 모두를 'blocking 없음'으로 결론지었습니다. 'Ready to merge', 'LGTM', 'APPROVE'라고 적힌 코멘트는 총 15건 있었습니다.

만약 Gemini의 리뷰를 믿고 병합(merge)했다면, 다음과 같은 일이 발생했을 것입니다.

• main과 충돌한 PR을 6건이나 병합하려 시도 (애초에 병합 불가능)
• CI가 빨간색으로 표시된 PR을 2건 병합함
• 잘못된 결과를 반환하는 수정, 빌드가 통과하지 않는 수정을 4건 병합함

결과 3: 놓친 것의 2/3는 main과 CI를 대조해 보면 알 수 있었습니다. 나머지는 수정 외곽의 입력을 시도해보지 않으면 보이지 않았습니다.

Claude만이 찾아낸 12건은 두 가지 유형으로 나뉩니다.

1. 한 번 명령을 실행하면 알 수 있었던 것 (8건)

main과의 충돌이 6건, CI 실패가 2건입니다.

• 충돌의 대부분은 PR이 생성된 후에 main 측에서 테스트 파일이 분할되거나 삭제되었기 때문이었습니다. PR은 이미 존재하지 않는 파일에 테스트를 추가하고 있었습니다.
• CI 실패는 PR이 소스 코드에 라인을 추가했기 때문에, 생성 코드 스냅샷에 포함된 라인 번호가 어긋난 것이었습니다.

git merge-tree

또는 gh pr checks

을 한 번 실행하면 알 수 있습니다. 다만, 지침서에 이 절차를 넣지 않은 것은 필자의 실수입니다. Gemini는 지시대로 PR의 최단점만 검증했고, Claude는 지시가 없었음에도 main과의 대조 및 CI 확인을 스스로 수행했습니다. 이 8건은 '지침서에 적으면 다음부터 Gemini도 찾아낼 수 있는' 부분입니다.

2. 수정 외곽의 입력을 직접 만들어 시도한 것 (4건)

PR에 붙어있는 테스트는 모두 통과하고 있습니다. PR이 수정한 범위 안만 보고 있으면, 이 4건은 보이지 않습니다. '이 수정의 옆 입력에서는 어떻게 될까'를 스스로 생각해서 시도해 볼 필요가 있습니다. 이곳은 지침서로 강제하기 어렵고, 모델 간의 차이가 그대로 드러난 부분이라고 생각합니다.

Gemini의 오기 6건은 대부분 '존재하지 않는 것의 인용'이었습니다.

• 존재하지 않는 타입 이름과 테스트 이름을 인용하고, 그것을 실행한 결과인 것처럼 작성했다.
• 행 번호가 다르거나, 실제로 존재하지 않는 테스트 프로젝트를 실행 대상으로 언급했다.
• "이 제외는 이름의 문자열 비교만"이라며 존재하지 않는 코드를 인용했다 (실제로는 심볼(symbol)을 해결하고 있었다).
• "표준 CI 러너에서는 메모리가 부족하여 이 테스트는 건너뛴다"고 작성했다 (실제로는 CI에서 실행되어 통과했었다).
• 의미론적 헌장(憲章)으로부터 인용하는 것처럼 보였으나, 헌장 어디에도 없는 문장을 적어 넣었다.

이 프로젝트에서는 이전부터 "Gemini의 주장은 파일:행을 명시하고, 직접 열어서 확인한 후에 이슈를 생성한다"는 규칙을 정했습니다. 이번 결과는 그 규칙이 필요했음을 입증합니다.

Claude가 저지른 오류 1건은 스스로 "읽기만 했다"고 적은 지적 사항이었습니다. "1 단어 테스트에서는 최상위 단어를 선택하는 처리를 망가뜨려도 놓칠 수 있다"고 작성했지만, 실제로는 다른 테스트가 실패합니다. 실행하여 확인한 지적에는 오류가 없었습니다.

결과 4: 가장 큰 문제는, 확인하지 않은 것을 확인한 것처럼 서술하고, 그 위에 "병합해도 좋다(mergeable)"는 결론을 내리는 점이었습니다.

수치뿐 아니라 리뷰를 작성하는 방식 자체에도 차이가 있었습니다. 먼저, 차이가 없었던 부분입니다.

• 수정 전에 테스트가 실패하고, 수정 후에 통과한다는 것은 양쪽 모두 총 40건에서 실제로 실행하여 확인했습니다.
• Gemini의 실제 지적 사항 19건은 내용이 모두 정확했습니다.

차이가 있었던 점은 다음과 같습니다.

• 양쪽 리뷰와 Claude의 심사위원 모두가 놓친,
  CI 실패를 1건 발견했습니다 (switch 문 수정으로 인해 공유되는 생성 코드 스냅샷 8건이 구식이 되어 있었다). 필자가 gh pr checks로 현재도 실패하고 있음을 확인했습니다. - Claude의 리뷰 오류 1건을 발견했습니다.
• 인용에 엄격하여, 리뷰 본문의 잘못된 행 번호나 타입 이름까지 찾아냈습니다.

제1차 벤치마크에서도 Gemini 4 Argon은 심사위원으로서 Claude Opus 5.5와 거의 비슷한 정확도를 보였습니다. '무(無)에서 문제를 발견하는 것'은 서툴지만, '작성된 주장이 옳은지 확인하는 것'은 능숙한 것으로 보입니다.

결과 5: Gemini의 리뷰는 Claude보다 약 2배의 시간과 최소 약 5배의 토큰을 사용했습니다. 그럼에도 불구하고, 실제 blocking(막히게 하는) 지적은 0건이었습니다.

먼저, 리뷰 간의 비교입니다.

| Gemini의 리뷰 | Claude의 리뷰 | |
|---|---|
| 시간 (5 레인 병렬, 처음부터 끝까지) | 2시간 19분 | 1시간 11분 |
| 신규 입력 | 894만 | 내역은 파악되지 않음 |
| 캐시 읽기 | 3억 4,901만 | 내역은 파악되지 않음 |
| 출력 | 71만 | 내역은 파악되지 않음 |
| ... |
토큰 수 계산에 대하여

Claude 측은 Claude Code가 서브 에이전트별로 내는 총합계만 측정할 수 있어, 신규 입력/캐시 읽기/출력의 세부 내역을 알 수 없습니다. 따라서 총합계를 직접 비교할 수는 없습니다.

하지만 하한선은 말할 수 있습니다. Claude가 캐시 읽기를 포함하지 않은 약 192만 토큰이라면, Gemini의 캐시 읽기를 제외한 965만 토큰과 비교했을 때 약 5배입니다. 만약 캐시 읽기를 포함한다면, Gemini의 3.6억 토큰과 비교하게 되어 차이는 거의 190배로 벌어집니다. 어느 쪽으로 보아도, Gemini는 5배 이상을 사용하고 있습니다.

다음으로, 심사위원 간의 비교입니다.

| Gemini의 심사위원 (익명, 5 레인 + 부모) | Claude의 심사위원 | |
|---|---|
| 시간 | 21분 | 12분 |
| ... |

• Claude의 리뷰는 수정 전후로 테스트를 실제로 실행하고, 시도용 테스트나 커널도 작성하기 때문에, 시간의 대부분은 빌드와 테스트에 할애됩니다.
• Gemini의 심사위원은 판정을 내리기 위해 캐시 읽기를 포함하여 약 1,700만 토큰을 읽었습니다. 신규 입력과 출력만으로 따지면 약 181만 토큰입니다.

첫 번째 질문에 답합니다.

Gemini가 작성한 리뷰는 Claude가 다시 한번 확인해야 할 '보조 자료' 수준에 그칠까요? 아니면 LGTM(Looks Good To Me) 결과물이 될 수 있을까요?

답은 '보조 자료에 머문다'입니다.

Gemini가 지적한 내용은 대체로 정확했습니다. 지적 사항을 읽어보는 자료로는 활용할 수 있습니다.

그럼에도 불구하고 LGTM의 결과물이 될 수 없는 이유는 결론이 신뢰할 수 없기 때문입니다.

• blocking 이슈가 있는 12건의 PR에 'blocking 없음'이라고 적었고, 다수에는 'Ready to merge'라고 작성했습니다.
• '확인했다'고 적었더라도 인용된 코드가 존재하지 않는 경우가 있었습니다.

지적 사항이 적기만 하다면, 'Gemini가 문제없다고 한 부분은 보지 않아도 된다'며 수고를 덜 수 있습니다. 하지만 '문제없음'과 '확인했다' 모두 신뢰할 수 없기에 아무것도 건너뛸 수 없습니다. 결국 매번 Claude나 사람이 역으로 확인하는 과정이 필요합니다.

이번에는, 역으로 확인하는 측의 Claude 리뷰가 Gemini의 실제 지적 사항을 모두 포함하고 있었습니다. 따라서 Gemini의 리뷰를 추가해도 늘어나는 실제 지적 사항은 없었습니다.

다만, 역할을 바꾸면 이야기가 달라집니다.

필자의 운영 방식은 다음과 같이 변경합니다.

리뷰는 Claude만으로 진행한다. 두 회사에 리뷰를 나누어도 이번에는 이득이 없었습니다. -
지침서에 놓쳤던 blocking 이슈의 2/3는 이것으로 막을 수 있었습니다. git merge-tree

과 gh pr checks
을 필수 절차로 포함시킵니다. -
Gemini는 Claude 리뷰의 '주장을 확인하는 심사위원'으로 사용한다. 작성자를 익명 처리하고, 인용이 실제로 존재하는지, 주장이 옳은지만 판정하게 합니다.

리포지토리 1개에 PR 40건만입니다. 다른 언어나 사람이 작성한 코드 리뷰에서 같은 차이가 나타난다고 할 수는 없습니다. -
PR은 Claude가 작성했습니다. Claude가 자신들이 작성한 코드의 습관을 알고 있어 유리했을 가능성은 있습니다. 다만, 놓쳤던 blocking 내용(main과의 충돌, CI, 수정 외곽 입력)은 작성자의 습관과는 관계없는 것이었습니다. -
지침서는 Claude가 작성했습니다. main과의 비교와 CI 확인을 빠뜨린 것도 그 지침서입니다. Claude는 이를 스스로 보완했고, Gemini는 보완하지 못했습니다. -
사고의 깊이는 둘 다 Medium입니다. Gemini를 High로 설정했을 때 결과가 달라지는지는 시험해 보지 않았습니다 (1차에서는 Flash를 high로 해도 성능 향상이 없었습니다). -
실행 환경이 다릅니다: Gemini는 Antigravity이고, Claude는 Claude Code의 서브 에이전트입니다. 도구 작동 방식의 차이도 결과에 포함됩니다. -
익명화가 완벽하지 않습니다: 문체나 형식에서 작성자를 추측할 수는 있습니다. 다만, 익명 처리하지 않은 Claude 심사위원과 익명 처리한 Gemini 심사위원 간에는 blocking 판정이 일치했습니다.

• 클로드가 발견하고 수정한 버그 수정 PR 40건을 Gemini 4 Argon과 Claude Opus 5.5에 동일한 지침서로 개별 리뷰를 시켰다.
• 익명으로 처리한 Gemini 심사위원과 작성자를 아는 Claude 심사위원 모두 결론은 같았다. Gemini만 발견한 실제 지적 사항은 0건, Claude만 발견한 실제 Blocking(차단) 문제는 12건이었다.
• Gemini의 지적은 대체로 정확했지만, Blocking이 있는 12건 모두를 "Blocking 없음"으로 처리했고, 존재하지 않는 코드를 인용한 사례가 6건 있었다. 결론과 "확인했다"라는 부분이 신뢰하기 어려워 Claude의 확인이 필요한 보조 자료 수준에 머문다.
• 놓친 부분의 2/3는 지침서에 절차를 추가하면 막을 수 있었다. 나머지는 "수정 외적인 입력을 스스로 시도하는" 능력의 차이였다.
• 한편으로, 작성된 주장을 확인하는 심사위원으로서의 Gemini는 모두가 놓친 부분을 찾아냈다.
• 시리즈를 통해 얻은 결론:
  주력은 Claude. Gemini는 "제로(0)부터 발견하는 역할"이 아니라 "확인하는 역할"로 사용한다.

모델은 몇 달 간격으로 교체됩니다. 다음 Gemini가 나오면, 동일한 지침서와 익명 판정으로 다시 측정할 계획입니다.

• "Claude가 코드를 더 잘 읽는가?" 실무 컴파일러로 중복 탐지 벤치마크를 만들어 Gemini와 비교했다

https://qiita.com/kassyi/items/01331b709cc5fb51bf25 - Gemini를 주력 에이전트에서 제외하고 Claude로 이동한 사례

https://qiita.com/kassyi/items/c134f3b244368d913f09 - Henicos(대상 리포지토리)