2026년 자동 코드 리뷰: 좌석 구매 없이 모든 PR에서 실행하기

자동 코드 리뷰는 diff를 언어 모델에 보내고, 영향받는 줄에 발견 사항을 게시하며, 심각한 문제를 발견하면 상태 확인을 실패 처리하는 CI 작업입니다. 좌석별 구독 없이 모든 풀 리퀘스트에서 이를 실행하는 방법은 오픈소스 하네스를 자체 호스팅하는 것입니다. 저장소에 약 15줄짜리 워크플로우를 복사하고 API 키 하나를 추가하면, 각 리뷰가 소비하는 토큰에 대해서만 비용을 지불하면 됩니다. 구매할 좌석 수가 없습니다. 좌석 자체가 없기 때문입니다. 우리가 유지 관리하는 참조 구현은 Orca-Code-Review 저장소로, 공개된 MIT 라이선스이며 2026년 6월 25일 생성된 이후 OrcaCode Review GitHub Action의 기반 코드입니다. 기본 제공 라우팅 레시피는 리뷰 패스를 DeepSeek V4 Flash로, 독립 검증 판정을 GLM-5.3으로 기본 설정하며, 둘 다 변경할 수 있습니다. 이 문서에서는 모든 푸시에서 실제로 실행되는 것, 구성할 항목, 토큰 비용, 그리고 2주차에 마주하게 될 실패 모드에 대해 설명합니다.

간단히 말하면, 모든 푸시마다 리뷰가 한 번 진행됩니다. 발견 사항은 변경된 줄에 인라인으로 게시됩니다. P0 및 P1 발견 사항은 검사를 실패시키고 병합을 차단하며, 문제가 없으면 통과합니다. 필요할 때 /orcacode-review라고 댓글을 달아 다시 리뷰를 요청할 수 있습니다. 워크플로는 저장소에 있고, 리뷰 로직은 게시된 액션에 있으며, 모델 선택은 자신의 워크스페이스에서 편집할 수 있는 라우팅 레시피에 있습니다. 리뷰어는 diff와 저장소 파일을 읽을 뿐 PR의 코드를 절대 실행하지 않습니다. 그리고 미리 솔직한 경고를 드리자면, 실제 버그를 잡아내지만 코드가 왜 그렇게 작성되었는지 아는 사람이 필요한 버그는 여전히 놓칩니다.

• 워크플로우 하나 + 시크릿 하나 + 토큰 과금. 어떤 경우에도 시트별 라이선스는 없습니다.

• 하네스는 오픈소스입니다. 복사하고, 포크하고, 감사하고, 커밋 SHA에 고정하세요.

• 모델은 설정이지, 공급업체가 아닙니다. 리뷰어를 변경하려면 라우팅 레시피를 편집하세요. YAML을 다시 쓰거나 액션을 올리는 것이 아닙니다.

• 과도하게 큰 diff는 비용이 들지 않습니다. 크기 가드는 모델보다 먼저 실행됩니다.

• 코드를 읽기만 할 뿐 실행하지 않습니다. 그것이 바로 pull_request_target을 완전히 안전하게 사용할 수 있게 해 주는 핵심 속성입니다.

자동화된 코드 리뷰가 실제로 작동하는 방식

모든 자동화된 리뷰 시스템은 겉모습만 다를 뿐 동일한 세 가지 요소로 이루어져 있습니다: 이벤트(event), 러너(runner), 리뷰어(reviewer).

해당이벤트가 트리거입니다. 제공된 워크플로우는 풀 리퀘스트 이벤트(opened, synchronize(새 푸시), ready_for_review(초안이 준비됨)) 및 PR 댓글에서 실행됩니다. 이 워크플로우는 pull_request_target으로 실행되므로 워크플로우 정의가 기본 브랜치에서 읽히며, 따라서 워크플로우가 PR에 대해 실행되려면 먼저 기본 브랜치에 존재해야 합니다. 푸시마다 리뷰 하나; concurrency 블록은 이전 실행을 취소하므로, 빠르게 연속된 푸시가 오래된 코드에 대한 리뷰 다섯 개를 대기시키지 않습니다.

해당 runner는 ubuntu-latest에서 GitHub Actions입니다. 작업에는 세 가지 권한이 필요합니다: 콘텐츠 읽기 권한, 풀 리퀘스트 쓰기 권한(인라인 댓글 작성용), 이슈 쓰기 권한(요약 게시 및 오래된 댓글 정리용).

그 리뷰어는 언어 모델입니다. 이 액션은 PR 헤드를 가져오고, 엔진이 선택하는 diff와 저장소 컨텍스트를 조합하여 리뷰 모델에 전송합니다. 결과는 각각 심각도가 태그되고 파일과 라인에 연결된 발견 사항들의 집합입니다. 이 액션은 그 발견 사항들을 인라인 PR 댓글로 게시하고, 푸시할 때마다 제자리에서 교체되는 요약 댓글 하나를 PR 설명 상단의 마커 영역에 작성합니다.

그 게이트는 상태 확인입니다. GitHub는 “리뷰”가 무엇을 의미하는지 알지 못하며, 단지 리뷰 확인이 통과하는지 여부만 압니다. 분기 보호에서 해당 확인을 필수로 표시하여 게이트를 실제로 만듭니다. 이것이 병합 차단 메커니즘의 전부입니다 — 관리자 API 호출도, 라벨도 없이, 단지 실패한 필수 확인뿐입니다.

무슨 일이 일어나지 않는가: PR의 코드를 실행하는 것은 아무것도 없습니다. 엔진은 읽기만 합니다. 그 단 하나의 불변 조건이 권한 있는 pull_request_target 트리거를 유료 API 키와 함께 사용해도 안전하게 만듭니다.

오픈소스 하니스가 차별화 요소다.

위의 모든 내용은 많은 도구에 해당됩니다. 대부분의 도구에는 해당되지 않는 점은 전체가 검사 가능하고 자체 호스팅이 가능하다는 것이며, 이것이 Orca-Code-Review 저장소가 제공하는 것입니다. 이 저장소는 MIT 라이선스의 공개 GitHub 저장소(JavaScript, 2026년 6월 25일 생성)로서 리뷰를 재사용 가능한 복합 GitHub Action과 설치 프로그램으로 패키징하며, 그것은 동일한 코드이며, 호스팅된 OrcaCode Review 앱이 그 코드를 실행합니다.

트리에서 10분을 보내면 PR에 닿는 모든 부분을 말할 수 있습니다:

• action.yml — 약 15개의 문서화된 입력값을 가진 복합 액션입니다. 어디에도 모델 이름이 하드코딩되어 있지 않습니다.

• workflows/orca-code-review.yml — 예시 소비자 워크플로우, 즉 .github/workflows/에 복사하는 약 15줄입니다.

• recipes/ — 라우팅 DSL입니다. 여기서 실제로 모델이 선택됩니다.

• rules/ — 심각도 기준(P0–P3), 필수 출력 형식, 그리고 프로젝트 자체 컨벤션 문서를 신뢰할 수 없는 참조 데이터로 검토에 제공하는 컨벤션 지시문.

• scripts/ — 정밀 필터(L1 및 L2 판정기), diff 가드, 병합 게이트, 실행 보고서, 토큰 측정기입니다. 각각은 작고 읽기 쉬운 .mjs 파일이며 테스트가 포함되어 있습니다.

• skills/setup-orca-code-review — 설치 프로그램이 코딩 에이전트에 넣는 스킬로, 설치, 재구성, 문제 해결, 제거를 다룹니다.

• .claude-plugin/ — Claude Code가 스킬을 자동 업데이트되는 플러그인으로 설치할 수 있게 해주는 것입니다.

설치는 AI에게 제품이 무엇인지 가르쳐준 다음 멈추는 한 줄짜리 명령입니다:

npx @orcarouter/code-review

CLI는 사용 중인 코딩 에이전트를 감지합니다 — 카탈로그는 Claude Code, Cursor, Codex, OpenCode, Windsurf부터 GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode 등 36개 플랫폼을 아우르며 — 스킬을 설치하고 처리를 넘깁니다. 그런 다음 에이전트에게 평범한 언어로 요청합니다: "이 저장소에 OrcaCode Review를 설정해 줘," "P0만 차단해," "리뷰가 왜 실행되지 않았어?" 이 스킬이 전체 라이프사이클을 담당합니다: 워크플로를 작성하고, API 키 입력을 안내하며, 게이트를 설정하고, 정말로 당신의 몫인 질문만 던집니다.

Claude Code는 대신 스킬을 플러그인으로 설치할 수 있으며, 그러면 저장소가 이동할 때마다 스킬이 최신 상태로 유지됩니다:

/plugin marketplace add Continuum-AI-Corp/orca-code-review

/plugin install orca-code-review

에이전트가 전혀 없나요? 동일한 수명 주기는 단순한 하위 명령들입니다 — init 워크플로를 작성하고, reconfigure 차단 규칙과 diff 제한을 변경하고, doctor 실행되지 않거나 게시되지 않는 리뷰를 진단하고, uninstall 해당 항목을 제거합니다(필수 체크를 먼저 해제). 스킬은 정문일 뿐, 유일한 문은 아닙니다. 또는 직접 연결하세요: 워크플로를 복사하고, 다음 이름의 시크릿을 하나 추가하세요: ORCAROUTER_API_KEY, 그리고 review 체크를 필수로 표시하세요.

밑바탕이 되는 엔진은 정확한 버전으로 고정되고 Apache-2.0 라이선스가 적용된 Ali​baba’s Open Code Review입니다. OrcaCode는 검토 방법을 결정하고, OrcaRouter는 어떤 모델이 실행될지 결정합니다. 셀프 호스트 대 호스팅의 장부 — 즉, 오픈소스 리뷰어를 셀프 호스트할 때 “무료”가 실제로 얼마나 비용이 드는지 — 는 오픈 코드 리뷰에 관한 기사에서 자세히 다루었습니다.

푸시 때마다 순서대로 실행되는 것은 무엇인가요?

각 단계가 독립적으로 실패하거나 건너뛸 수 있으므로 순서를 아는 것이 도움이 됩니다:

• diff 가드는 모델보다 먼저 실행됩니다. 만약 merge-base diff가 512KB를 초과하거나 300개 이상의 파일을 포함하면, 리뷰는 건너뛰어지고 알림이 게시됩니다. 기본값은 on-oversized-diff: fail입니다. 따라서 한도를 초과하도록 부풀려진 diff는 필수 게이트를 검토 없이 통과할 수 없습니다. 이것은 또한 지출 통제이기도 합니다: 초과 크기 PR은 토큰 비용이 0입니다.

• 엔진이 diff를 검토합니다. 단일 패스, 파일당 동시성 기본값 24, 패스당 벽시계 시간 상한 20분.

• 정밀 필터는 원시 결과를 후처리합니다. L1(결정적 필터)은 각 결과가 주장하는 기존 코드 스니펫을 검토된 커밋과 대조하여 불일치 항목을 재배치하거나 제외합니다. L2(LLM 판정기)는 결과를 근본 원인별로 클러스터링하고 신뢰도가 낮은 클러스터를 제외합니다. 두 계층 모두 소프트 실패 방식입니다. 오류가 발생하면 이전 단계의 결과를 유지하며 리뷰를 중단하지 않습니다.

• 게이트가 적용됩니다. P0 및 P1 결과는 검사에 실패합니다. PR 요약에는 diff에서 음소거된 결과를 포함한 모든 결과가 집계됩니다.

• 미터는 비용을 출력합니다. 해당 미터 입력은 호출별 토큰 회계(프롬프트, 완료, 캐시된 토큰, 그리고 라우터가 결정한 모델)를 기록하고 작업 로그에 합계 테이블을 출력합니다.

• 선택적 실행 보고서는 심각도 카운트와 게이트 메타데이터를 분석 대시보드용 OrcaRouter 컨트롤 플레인으로 전송합니다. 코드, diff, 발견 사항 텍스트는 포함하지 않습니다.

실제로 구성하는 내용

세 개의 표면이 있으며, 그 폭발 반경은 매우 다릅니다.

1. 워크플로우 파일. 소비자 워크플로우는 의도적으로 매우 얇습니다. 건드릴 가치가 있는 입력 값들은 액션에 있습니다: block-on (어떤 심각도가 검사에 실패하는지 — 기본값 P0,P1), fix-first (어떤 심각도가 전체 검토를 조기에 중단하는지), auto-review-authors (자동 검토를 받는 대상에 대한 허용 목록), max-diff-kb 및 max-diff-files 및 on-oversized-diff (크기 가드), timeout-minutes, concurrency, meter 및 report. 각각 문서화된 기본값이 있으므로, 새 워크플로우는 YAML 다섯 줄과 비밀 하나면 충분합니다.

2. 대시보드.설정값이 settings: true(기본값)인 경우, 각 실행은 OrcaRouter → Apps → OrcaCode Review에서 저장소별 설정(모델, 리뷰 모드, 병합 정책, 보고 심각도, 조용한 모드, 심층 검토, 사용자 지정 루브릭, 가드레일)을 가져옵니다. 설정은 settings: "false"로 하면 워크플로 파일이 우선합니다. — 대시보드 값으로는 이를 덮어쓸 수 없습니다. 콘솔을 열지 않아도 하네스의 기능을 잃지 않으며 YAML로만 구성하면 됩니다.

3. 라우팅 레시피 — 사람들이 놓치는 것.액션은 모델을 직접 지정하지 않는다. 대신, 원시 사실들을 요청 헤더로 주입한다 — 실행이 어떤 티어로 기록되었는지, 이전 패스에서 P0/P1이 발견되었는지, 그리고 요청이 L2 심판일 때의 렌즈 마커 — 그리고 워크스페이스 라우터의 DSL 레시피는 그 헤더들을 구체적인 모델로 매핑한다. 기본 레시피는 리뷰를 DeepSeek V4 Flash로, 심판을 GLM-5.3으로 설정하며, 의도적으로 둘을 별도의 모델로 라우팅한다. 코드를 리뷰하는 모델을 변경하는 것은 자신의 워크스페이스에서 그 레시피를 수정하는 것이다: 액션 버전을 올릴 필요도, YAML을 다시 작성할 필요도, 재배포할 필요도 없다.

심각도 규약은 하나가 아닌 두 개의 독립적인 설정입니다. 병합 정책은 병합을 차단할 항목을 결정하고, 보고 심각도는 diff에 게시할 항목을 결정합니다. 기본 제공 설정은 P0/P1 차단, P2/P3 통과입니다. 차단하는 심각도는 보고 설정과 관계없이 항상 게시됩니다. diff에 설명이 전혀 없는 실패 검사는 시끄러운(noisy) 검사보다 더 나쁩니다. P0는 악용 가능한 보안 취약점, 데이터 손실, 정상 경로에서의 크래시, 또는 빌드 손상을 의미합니다. P1은 실제로 발생하지만 영향이 제한된 버그를 의미합니다. P2는 비정상적인 사전 조건에서만 발생하는 실제 결함을 의미합니다. P3는 스타일 문제입니다. 두 등급 사이에서 고민될 때, 평가 기준에 따르면 더 낮은 심각도 등급을 선택합니다.

비용

토큰당 요금이며, 좌석당 요금이 아닙니다. OrcaRouter에서 모델을 선택하며, 결제는 소비된 토큰 기준으로 이루어지고, 그 미터가 실행당 수치를 모호하게 하지 않고 명확하게 보이게 합니다. GitHub 메커니즘, 2026년 6월 1일부터 시행된 Copilot의 사용량 측정 코드 리뷰, 그리고 타사 리뷰어가 해당 워크플로우에 어떻게 맞물리는지는 GitHub 코드 리뷰 가이드에서 다룹니다. 필드별 전체 비용 비교(좌석당 제품 대 토큰당 제품, 구체적인 예시 포함)는 저희 AI 코드 리뷰 도구 비교 글에 있으며, 리뷰어가 실제로 저장소를 탐색할 때 단일 리뷰 패스가 토큰으로 얼마나 드는지에 대한 질문(봇 대 에이전트 구분)은 코드 리뷰 에이전트 글에서 다룹니다. 이 글이 추가로 전달하는 핵심은 청구서의 형태입니다. 즉, 비용은 리뷰하는 코드의 양에 비례하며, 리뷰하는 인원수에는 비례하지 않습니다.

첫날에 중요한 두 가지 비용 제어 기능이 있습니다. 공개 저장소에서, pull_request_target은 GitHub의 포크 승인 게이트를 우회하며, 리뷰 키는 지갑 기준으로 측정됩니다 — 낯선 사람이 PR을 열어 유료 리뷰를 유발할 수 있습니다. 키에 알림이 있는 지갑 예산을 설정하고, auto-review-authors를 OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR와 같은 값으로 설정하여 알 수 없는 기여자가 자동 리뷰되지 않게 하세요. 그리고 언급했듯이 diff 가드는 과도하게 큰 PR에 비용이 전혀 들지 않게 합니다.

무엇이 깨지나요?

자동 리뷰는 CI다. CI처럼 깨지며, 실패 모드는 대부분 모델 탓이 아니다:

• 워크플로가 실행되지 않습니다.의 경우pull_request_target 워크플로는 기본 브랜치에서 읽힙니다 — PR 브랜치에만 추가된 워크플로는 병합될 때까지 실행되지 않습니다. 또한 앱이 활성화되어 있는지, auto_review가 켜져 있는지, PR이 초안이 아닌지(초안은 ready_for_review 모드에서 건너뜁니다), 그리고 리포지토리에서 Actions가 활성화되어 있는지 확인하세요(포크된 리포지토리에서는 기본적으로 비활성화되어 있습니다).

• /orcacode-review는 아무것도 하지 않습니다. 댓글 트리거는 댓글이 다음 네 가지 표기 중 하나로 시작해야 합니다 — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — 그리고 댓글 작성자는 OWNER, MEMBER 또는 COLLABORATOR여야 합니다. 앞에 공백이 있으면 매치가 실패합니다. 외부 기여자의 명령은 의도적으로 조용히 무시됩니다. 명령은 유료 키를 보유한 권한 있는 워크플로우를 실행하기 때문입니다.

• 인증 오류입니다. 시크릿 이름이 잘못되었거나 누락되었거나, 키가 폐기되었거나 예산이 초과되었거나, 워크플로가 pull_request로 전환되었습니다(포크의 시크릿을 읽을 수 없습니다).

• 체크가 빨간색이며 “diff too large” 알림이 표시됩니다. 이것은 구성된 대로 작동하는 크기 가드입니다. PR을 분할하거나, 한도를 높이거나, 설정하세요: on-oversized-diff: pass — 그리고 필수 체크에서 pass는 충분히 큰 PR이 리뷰 없이 게이트를 그냥 통과한다는 뜻임을 이해하세요.

• 리뷰는 실행되지만 코멘트가 표시되지 않습니다. 세 가지 원인이 있으며, 모두 무해하거나 설정된 것입니다. 클린 실행은 인라인 코멘트 대신 요약을 게시하고, quiet 모드는 게시 시점에 P2를 음소거하며(게이트와 리포트에는 여전히 집계됨), 또는 정밀도 필터가 발견 항목을 걸러냈습니다. 즉, L1은 스니펫이 커밋과 일치하지 않는 발견 항목을 삭제하고, L2는 신뢰도가 낮은 클러스터를 삭제합니다. 작업 로그의 심각도 수치가 어떤 원인인지 알려줍니다.

보안 태세는 전체 설계를 안전하게 만드는 핵심이므로 분명히 밝힐 가치가 있습니다. 엔진은 diff와 저장소 파일만 읽으며 PR 코드를 절대 실행하지 않습니다. 리뷰어에게는 병합 권한이 없습니다. 발견 사항이 병합을 차단하거나 코멘트를 추가할 수는 있어도, 모델 출력이 저장소를 승인하거나 변경하게 하는 코드 경로는 없습니다. 태그가 없는 발견 사항은 안전하게 실패하여 권고가 아닌 차단으로 처리됩니다. 또한 실행 보고서에는 코드나 발견 사항 텍스트가 포함되지 않습니다. 단일 패스 리뷰가 놓치는 부분을 잡아내는 2계층 구성은 AI 코드 리뷰 보안 글의 주제이며, 위의 위협 모델은 저장소의 SECURITY.md에 문서화되어 있습니다.

자동 검토가 잘못된 도구일 때

그것은 툴링 공급업체들이 인정하는 것보다 더 자주 틀립니다. 다음과 같은 경우에는 건너뛰십시오:

• 문제는 양이 아니라 맥락입니다.리뷰가 느린 이유가 리뷰어들이 코드가 왜 이렇게 작성되었는지 이해해야 하기 때문이라면, diff를 읽는 LLM은 별로 도움이 되지 않습니다. LLM은 지난달의 스레드에 대한 기억이 없고 시스템의 역사에 대한 이해도 없습니다.

• 이 diff는 대부분 생성되었거나 벤더링된 코드입니다. 자동 포맷 출력, 스캐폴딩된 파일, 의존성 스냅샷. 이를 검토하면 토큰을 소모하고 노이즈를 발생시키며, 이는 컨벤션 지침이 가장 도움이 되지 않는 바로 그 지점입니다 — 코드는 선택에 따라 프로젝트 스타일을 따르는 것이 아니기 때문입니다.

• 팀은 이미 모든 것을 페어 리뷰합니다. 자동화된 리뷰는 검토량을 늘리는 지렛대입니다. 모든 변경 사항이 이미 그 자리에 있던 사람의 검토를 거쳤다면, 기계가 추가하는 두 번째 의견은 대개 첫 번째보다 정보가 부족합니다.

• 아무도 결과를 읽지 않습니다. 아무도 실행에 옮기지 않는 검토는 영원히 그린(green) 상태로 실패하는 워크플로우입니다. 이것은 가장 흔한 조용한 실패이며, 어떤 정밀 필터로도 해결되지 않습니다.

• 리뷰는 코드를 실행해야 합니다.PR에 대한 테스트 스위트가 필요하다면, LLM 리뷰는 잘못된 도구입니다. 읽기만 할 뿐 실행하지 않습니다. 아티팩트를 빌드하고 실행해야 하는 보안 스캔은 별도의 신중하게 범위가 지정된 작업에 속합니다. — 리뷰 워크플로우는 PR 제어 코드를 실행하도록 절대 확장되어서는 안 된다는 점을 기억하세요.

• 저장소는 아주 작거나 일회용입니다. 일정 변경 빈도 이하에서는, 리뷰가 잡아내는 버그보다 오버헤드가 더 큽니다.

거짓 긍정(false positives), 그리고 정밀도 필터링이 해결하는 것과 해결하지 못하는 것

모든 AI 리뷰어에 대한 비난은 거짓 경보를 울린다는 것이다. 하네스는 이 문제를 {{1}}두 계층{{/1}}에서 공략하며, {{2}}어느 계층이 어떤 실패를 해결하는지{{/2}}를 정확히 구분하는 것이 도움이 된다.

그 결정적 계층 (L1)은 유령 발견을 제거합니다: 엔진이 때때로 존재하지 않는 코드를 주장합니다 — 표류한 스니펫, 형제 파일에 복사된 발견과 같은 것입니다. L1은 각 발견의 기존 코드 스니펫을 실제 검토된 커밋과 대조하여 불일치 항목을 다시 배치하거나 삭제합니다. 이로써 "이 줄은 존재하지도 않는다"는 부류의 거짓 양성이 해결되며, 이는 기계적이고 검증 가능합니다.

심판 계층(L2)은 중복 및 근거 없는 클레임을 제거합니다. LLM 심판은 근본 원인별로 발견 사항을 클러스터링하며, 신뢰도가 심판 임계값(기본값 0.5)보다 낮은 클러스터는 폐기합니다. 이를 통해 "동일한 버그가 세 가지 방식으로 보고된 경우"와 추측성 발견을 해결합니다.

어느 쪽 레이어도 해결하지 못하는 문제는 분명히 말해 둘 만하다. 틀렸지만 자신 있는 결과는 판정자를 통과한다. 판정자는 LLM이고, 확신에 차 보이는 LLM과 실제로 참인 결과는 같은 것이 아니다. 리뷰어와 같은 모델에서 실행되는 판정자는 자기 자신과 일치하게 되고, 패스는 성공을 보고하면서도 무력해진다. 그래서 배포된 레시피는 판정자를 리뷰어와 다른 모델에 연결한다. 또 심각도 루브릭은 의도적으로 보수적이다. "두 단계 사이에서 망설여지면 낮은 쪽을 선택하라"는 기준인데, 그 결과 실제로 존재하는 조건부 버그는 차단용 P1보다는 P2 어드바이저리로 분류될 가능성이 더 높다. 모든 것을 차단해서는 안 되는 도구에는 그런 보정이 옳다. 하지만 그것은 보정일 뿐이다. 놓친 차단 항목을 더 적은 오탐지와 맞바꾸는 트레이드오프다. PR 요약은 항상 모든 파인딩을 집계하므로, 눈에 띄지 않는 P2들도 여전히 읽을 수 있다. 그 트레이드오프가 팀에 맞지 않는다면, 루브릭과 판정자 임계값은 지원 티켓이 아니라 설정값이다.

요점

이미 GitHub Actions에서 작업하는 팀에게 오픈소스 하네스는 모든 PR에 자동 코드 리뷰를 도입하는 가장 저렴한 방법입니다. 워크플로 파일 하나, 시크릿 하나, 리뷰되는 코드에 따라 늘어나는 토큰 비용, 그리고 직접 선택하는 모델을 갖게 됩니다. 운영 부담이 전혀 없고 연락할 공급업체를 원한다면 좌석당 과금 제품을 구매하세요. 리뷰가 더 좋아서가 아니라, 직접 문제를 관리하는 대신 다른 사람의 문제를 사는 것이니까요. 그리고 무엇이든 설정하기 전에 리뷰가 실제로 읽힐 것인지 자문해 보세요. 하네스는 리뷰가 자동으로 이루어지게 할 수 있습니다. 하지만 누군가가 그것을 읽게 할 수는 없습니다.

동일한 리뷰어를 직접 실행하지 않고도 사용하고 싶으신가요? OrcaCode Review는 바로 이 하네스를 호스팅된 GitHub 앱으로 실행합니다 — 동일한 오픈 레시피, 동일한 토큰당 요금, 좌석 수 제한 없음.