CodeJury는 모든 변경 사항을 서로 다른 모델로 구성된 독립적인 심판단(panel of independent, differently-modelled judges)이 리뷰하는 터미널 우선(terminal-first) 멀티 에이전트 코딩 파이프라인입니다.

모든 에이전트 기반 코딩 도구는 결국 리뷰어가 필요하며, 거의 모든 도구가 동일한 설계를 사용합니다. 즉, 하나의 모델에게 diff가 괜찮은지 묻는 방식입니다.

이 방식은 예측 가능한 형태로 실패합니다. 단일 심판은 작성자가 보지 못한 바로 그 지점에서 자신만만하고, 빠르며, 눈이 멀어 있습니다 — 동일한 학습 분포(training distribution), 무엇이 "맞아 보이는지"에 대한 동일한 직관, 그리고 기능을 실제로 연결하지 못하는 그럴듯한 diff를 수용하려는 동일한 성향을 가집니다. 이는 이전 단계에서 틀린 것을 잡아내는 것이 주 목적인 단계에서 단일 판단 지점(single point of judgement)을 두는 것과 같습니다.

따라서 CodeJury는 모든 변경 사항을 독립적이고 서로 다른 모델로 구성된 심판단의 **패널(panel)**로 보내며, 여기에 하나의 평결을 종합하는 의장(foreperson)을 추가합니다.

증거

이것은 단순한 짐작이 아닙니다. SE-Jury (Zhou et al., 2025)는 생성된 코드가 올바른지에 대해 자동 심판이 인간 전문가와 얼마나 잘 일치하는지를 측정했습니다:

문헌상 최고의 단일 심판은 49.6점을 기록했습니다. 동일한 모델을 패널로 구성했을 때는 64.3점을 기록했습니다. 이 격차는 코딩 에이전트가 실제로 결과물을 내놓는 작업과 가장 유사한 논문의 작업인 **프로그램 수정 (program repair, +75.2%)**에서 가장 크게 나타났습니다.

절제 연구(ablation)를 통해 명백한 반론("어쩌면 단일 심판이 그냥 운이 좋았던 것 아닐까")을 제거했습니다. 모든 개별 전략은 평균 48~58점을 기록하여 모두 패널의 64.3점보다 낮았습니다. 또한 단일 심판은 매우 불안정합니다. 전체에서 가장 뛰어난 심판이 요약(summarization) 작업에서는 _두 번째로 최악_이었습니다. 어떤 심판을 선택하든, 당신은 그 심판의 사각지대(blind spot)도 함께 선택하는 것입니다.

해당 수치들은 SE-Jury의 것이며, SE-Jury 상에서 측정된 결과입니다. 이는 아키텍처(architecture)에 대한 증거이지, 제 리포지토리(repo)의 벤치마크가 아닙니다. 전체 표와 인간 일치도(human-agreement) 결과는 README에서 확인할 수 있습니다.

6단계, 각 단계마다 원하는 모델 사용

CodeJury는 리뷰어가 단순히 결합된 하나의 에이전트가 아닙니다. 이는 6단계로 구성되어 있으며, 터미널에서 실시간으로 각 단계에 사용할 제공업체(provider)와 모델을 선택할 수 있습니다:

/model dev anthropic claude-sonnet-5
/model planner gemini gemini-3.5-flash-lite
/jury                                     # 심판 임명, 해임, 모델 변경, 브리핑 재실행

Claude가 계획(plan)하고, Codex가 작성(write)하며, GPT가 리뷰(review)합니다. 작성자와 _다른 계열(family)_의 모델을 사용하는 리뷰어를 배치하는 것은, 한 단계 높은 수준에서 동일한 탈상관(decorrelation) 논리를 적용하는 것입니다.

API 키가 전혀 필요하지 않을 수도 있습니다 — 각 단계는 이미 로그인되어 있는 코딩 CLI(Claude Code, Codex, Cursor, Aider, Gemini CLI) 상에서 기존 구독을 통해 헤드리스(headless)로 실행됩니다. 또는 원하는 키를 가져와 사용할 수도 있습니다. 기본값은 Groq의 무료 티어를 대상으로 하므로, 전체 과정을 0달러로 실행할 수 있습니다.

배심원단은 토큰을 소모하지만, 파이프라인은 토큰을 되찾아옵니다.

준비되지 않은 에이전트(cold agent)는 모든 작업(grep, open, guess, backtrack, 아키텍처를 처음부터 다시 도출하기 등)에서 국소화 비용(localization tax)을 지불합니다. CodeJury는 이를 한 번만 지불하며, BM25와 결합된 로컬 시맨틱 검색(local semantic search) 기능이 포함된 영구적인 코드 그래프(158개 언어 지원)에 저장합니다.

Textualize/textual (~82.5k LOC) 및 rich (~35.6k) 프로젝트에서 동일한 일반 영어 요청을 사용했을 때, 일반 claude -p와의 직접 비교 결과입니다:

극단적인 사례에서, 베이스라인은 단 하나의 캐시 데코레이터(cache-decorator) 버그를 찾기 위해 207회의 턴과 1,430만 개의 토큰을 사용하여 $6.83를 소모했습니다. 리포지토리의 크기가 핵심이 아니라, 국소화 가능성(localizability)이 핵심입니다.

또한 때로는 손해를 보기도 합니다. 매우 저렴한 작업의 경우 고정된 게이트 비용(fixed gate floor)이 콜드 런(cold run)을 통해 절약한 비용보다 더 클 수 있으며, 가장 어려운 버그의 경우 저렴한 승리(cheap win)가 더 좁은 범위의 수정 사항을 배포할 수도 있습니다. 이 두 가지 사례는 전체 보고서에 기록되어 있습니다.

사용해 보기

Python 3.11+ 및 git이 필요합니다. 이것이 유일한 요구 사항입니다.

git clone https://github.com/krishagarwal314/CodeJury
cd codejury && ./run.sh

그다음, 시작부터 끝까지의 과정은 다음과 같습니다:

/kb add https://github.com/pallets/click     # 리포지토리 인덱싱
add a --dry-run flag to the CLI runner       # 평문 영어; PM 에이전트가 범위를 지정함
/approve all                                 # 인간의 승인(human gate)
...

데모 모드가 기본적으로 활성화되어 있으므로, 사용자가 직접 참여(opt in)하기 전까지 PR 단계는 드라이 런(dry run)으로 진행됩니다.

⭐ github.com/krishagarwal314/CodeJury — MIT 라이선스, 기여를 환영합니다.

배심원단(jury)이 어디서 틀리는지 진심으로 듣고 싶습니다. 리포지토리에서 실행해 보시고, 만약 패널이 명백한 것을 놓치거나 — 혹은 차단해서는 안 될 것을 차단한다면 — 차이점(diff)과 함께 이슈(issue)를 생성해 주세요. 그것이 제가 가장 데이터를 얻고 싶은 실패 모드(failure mode)입니다.