AI 리뷰는 Rate Limit(속도 제한)으로 막힌다 — Claude / Codex / Gemini를 가용성 측면에서 다중화하기

서론

AI에게 코드나 기사를 리뷰하게 하는 것은 이제 드문 일이 아닙니다. 다만 한 대에게만 맡기면 놓치는 부분이나 편향(Bias)이 남을 수 있으므로, "여러 AI에게 보여주면 된다"라고 생각하게 됩니다. 하지만 실제로 해보면 리뷰 내용에 도달하기도 전에 다른 벽에 부딪힙니다. Rate Limit (429)입니다.

Codex CLI나 Gemini CLI와 같은 외부 AI 리뷰 CLI를 여러 개 연결하여 다각도 리뷰를 돌리려고 하면, 429 에러, 인증 에러, trusted-directory 계열의 에러로 인해 허무하게 멈춰버립니다. 이 기사에서는 실제로 이러한 막힘을 경험한 바탕 위에서, Rate Limit로 인해 멈추지 않는 AI 리뷰의 가용성 설계를 정리합니다.

결론

AI 리뷰는 정확도뿐만 아니라 가용성 (Availability) 측면에서 설계해야 합니다. 요점은 다음과 같습니다.

즉, **"똑똑한 한 대"가 아니라 "멈춰도 돌아가는 여러 대"**로서 AI 리뷰를 설계합니다.

이 기사에서 다루는 두 가지 축

이 기사에서는 AI 리뷰를 두 가지 축으로 정리합니다. 첫 번째는 가용성으로, 리뷰가 멈추지 않고 돌아가는지, 혹은 멈추더라도 판단을 중단하지 않아도 되는지를 봅니다. 두 번째는 독립성으로, 동일한 놓침이나 동일한 편향을 피할 수 있는지를 봅니다. 비슷해 보이지만 서로 다른 것입니다.

축	보는 것
가용성	리뷰를 멈추지 않고 돌릴 수 있는가
독립성	동일한 사각지대를 피할 수 있는가

본 기사의 L1 / L2 / L3는 가용성의 분류입니다.

반면, 셀프 리뷰, 동일 모델의 별도 에이전트, 별도 모델 리뷰는 독립성의 분류입니다.

이 부분을 나누어 두면 AI 리뷰 설계가 상당히 쉬워집니다.

다각도 AI 리뷰란

다각도 AI 리뷰란, 동일한 대상을 여러 AI의 관점에서 리뷰하고 소견을 대조하는 방법입니다.

한 대의 AI에게만 의존하면 놓침, 선입견, 환각 (Hallucination)이 그대로 통과됩니다. 반면, 여러 개의 독립된 관점으로 보면 다음과 같이 판단하기 쉬워집니다.

소견	취급
여러 관점에서 일치한 지적	고확도 지적으로 우선 처리
...

실제로 어떤 스크립트를 리뷰할 때, 단 하나의 독립된 AI만이 치명적인 허점을 실증과 함께 지적한 적이 있었습니다. 자신의 셀프 리뷰에서는 알아채지 못했던 허점이었습니다. 이 경험 이후, AI 리뷰에서는 똑똑함보다 독립된 관점을 어떻게 만들 것인가를 중시하고 있습니다. 하지만 독립성을 추구하며 외부 AI를 늘릴수록, 이번에는 가용성이 문제가 됩니다.

실제로 일어난 일

어떤 변경 사항을 여러 AI로 리뷰하려고 했을 때의 일입니다. 대상은 어떤 가드 스크립트였으며, 자신의 리뷰에 더해 Claude, Codex, Gemini의 다각도 확인을 할 계획이었습니다. 그런데 순차적으로 막혀갔습니다.

• Gemini CLI는 429 You have exhausted your capacity on this model로 정지 - 비대화형 실행에서는 trusted-directory 계열의 에러도 발생
• flash 계열 모델로 전환하면 작동하지만, 소견이 얕아질 뿐만 아니라 존재하지 않는 기술에 대한 언급 등 빗나간 지적도 섞임 - Codex CLI도 사용 제한에 도달
• 결과적으로, 수중에 있는 외부 CLI 리뷰가 갖춰지지 않음

이때 비교적 안정적으로 사용할 수 있었던 것은 PR에 연결된 bot 리뷰뿐이었습니다. 여기서 뼈저리게 느낀 점은, 외부 CLI를 품질 게이트(Quality Gate)의 주 경로에 두면, 리뷰 내용 이전의 이유로 멈춘다는 것입니다. 리뷰는 품질 게이트여야 하는데, 외부 서비스의 Rate Limit나 인증 상태 때문에 게이트가 열리지 않는다면, 그것은 품질 보증이 아니라 운영 리스크입니다.

L1 / L2 / L3의 정의

그래서 AI 리뷰어를 가용성이 높은 순서대로 3개 층으로 나눕니다.

층	실체	위치 선정	멈췄을 때
L1	직접 기동·제어하기 쉬운 독립 에이전트	필수 주 경로	중단
...

제 환경에서는 다음과 같이 할당하고 있습니다.

층	구체적인 예
L1	Claude Code의 셀프 리뷰 + 관점별 서브 에이전트
...

중요한 것은 L3를 "멈추면 곤란한 주 경로"로 만들지 않는 것입니다.

L3의 가치는 다른 모델의 관점을 얻을 수 있다는 점입니다. 다만, 가용성(Availability)은 낮습니다. 따라서, 작동하면 강력하지만, 중단되어도 멈추지 않는 보조 프레임으로 취급합니다.

L1은 관점별 에이전트 팀으로 구성한다

L1을 단 1개로 한정할 필요는 없습니다.

Claude Code의 서브 에이전트(Sub-agent)를 사용하면, 관점별 리뷰 에이전트를 병렬로 구동할 수 있습니다.

예를 들어, 다음과 같이 나눕니다.

에이전트	관점
correctness	로직의 정확성, 경계 조건, 버그
...

각 에이전트에는 다른 에이전트의 소견을 전달하지 않습니다. 자신의 소견도 전달하지 않습니다.

대상 파일과 리뷰 관점만을 전달하여, 백지 상태에서 검증하게 합니다.

이를 통해 추인 편향 (Confirmation Bias)을 피하기 쉬워집니다.

대상: target.js
역할: correctness reviewer
이 파일의 로직의 정확성만을 검증해 주세요.
...

L1도 Claude 측의 이용 제한(Rate Limit)으로부터 완전히 자유롭지는 않습니다.

하지만 외부 CLI 고유의 trusted-directory, 인증, 모델 전환, CLI별 용량 제한에 비하면, 자신의 개발 환경에 통합하기 쉽고 운영상의 제어성이 높은 계층으로 취급할 수 있습니다.

L2는 PR 연동 안정 프레임으로 사용한다

L2에는 GitHub 상에서 동작하는 bot 리뷰를 배치합니다.

예를 들어, GitHub Copilot review나 Gemini Code Assist bot과 같은 PR 연동 리뷰입니다.

L2의 장점은 개발 플로우와 자연스럽게 연결될 수 있다는 점입니다.

• PR을 생성
• bot 리뷰가 실행됨
• 코멘트가 PR에 남음
• 인간의 리뷰와 동일한 장소에서 확인 가능

로컬 CLI보다 PR에 묶인 bot 리뷰가 더 안정적으로 사용되는 상황이 있습니다.

다만, L2도 만능은 아닙니다. 플랜, 조직 설정, 리포지토리 설정, 권한, 서비스 측의 상태에 의존합니다.

따라서 L2는 '항상 안정적'인 것이 아니라, PR 운영과 궁합이 좋은 보조 경로로 취급하는 것이 현실적입니다.

L3는 즉시 폴백(Fallback)한다

L3에는 Codex CLI나 Gemini CLI와 같은 외부 CLI를 배치합니다.

L3는 강력합니다. 다른 모델의 관점을 넣을 수 있기 때문에, 동일한 모델에서는 놓칠 수 있는 사각지대를 포착할 가능성이 있습니다.

반면, 가용성을 예측하기 어렵습니다.

• 429 에러로 중단됨
• 인증이 만료됨
• trusted-directory 문제로 중단됨
• 모델을 사용할 수 없음
• 상위 모델을 사용할 수 없어 하위 모델로 전환할 경우 지적 수준이 얕아짐

참고로 trusted-directory 계열의 에러는 비대화형 실행(Non-interactive execution) 시 신뢰 확인을 스킵하여 회피할 수 있는 경우가 있습니다. 로컬의 gemini-cli v0.42에서는 --skip-trust 플래그나 GEMINI_CLI_TRUST_WORKSPACE=true 환경 변수로 통과되었습니다 (플래그 명칭 및 필요 여부는 버전에 따라 다르므로 공식 문서를 확인해야 합니다).

따라서 L3는 다음 규칙으로 취급합니다.

L3가 429, 인증 에러, trusted-directory 계열 에러로 중단되면, 해당 회차는 즉시 skip한다.
리트라이(Retry)로 버티지 않는다.
L3의 회복을 기다리느라 리뷰 전체를 멈추지 않는다.

이는 포기가 아닙니다. L3는 '사용할 수 있으면 강력한' 프레임으로 설계한다는 뜻입니다.

판단 규칙

저의 운용 방식에서는 다음과 같이 판단합니다.

상황	판단
L1이 중단됨	중단함
...

원칙은 심플합니다.

리뷰의 가부(可否)를 가장 불안정한 계층인 외부 CLI에 맡기지 않는다.

어떤 변경에 어느 계층까지 사용할 것인가

모든 변경에 모든 계층을 사용할 필요는 없습니다.

변경의 리스크에 따라 리뷰 계층을 늘립니다.

변경 유형	권장 리뷰 계층
typo / README / 경미한 문구 수정	L1
...

AI 리뷰는 편리하지만, 모든 것을 AI에게 맡기는 것이 아닙니다. 리스크가 높은 변경에서는 인간의 리뷰, 정적 분석 (Static Analysis), 의존성 스캔 (Dependency Scan), 시크릿 탐지 (Secret Detection)와 병행합니다.

리뷰 결과에는 skip 로그를 남긴다

또 하나 중요한 것은 어떤 계층이 실행되었고, 어떤 계층이 skip 되었는지를 명시하는 것입니다.

아무런 표시 없이 skip 하면, 독자나 리뷰어는 '모든 관점에서 리뷰가 완료되었다'고 오해할 수 있습니다.

예를 들어, 다음과 같이 남깁니다.

계층	결과	비고
L1 correctness	OK	경계 조건 지적 있음
...
SKIP

(해당 계층이 실행되지 않음)과 DEGRADED

(하위 모델로 넘겨서 소견의 질이 떨어짐)을 구분하여 남기면, 나중에 "어디까지 신뢰할 수 있는 리뷰였는가"를 판단하기 쉬워집니다.

이 로그가 있으면 판단의 투명성이 높아집니다.

중요한 것은 AI 리뷰의 결과 그 자체보다, 어떤 전제로 판단했는가를 남기는 것입니다.

요약

다관점 AI 리뷰는 강력하지만, 외부 CLI를 주 경로로 사용하면 Rate Limit (속도 제한)이나 인증 에러로 인해 쉽게 중단됩니다. 따라서 가용성 측면에서 다중화한 L1 / L2 / L3 중 L1 + L2가 갖춰지면 L3를 기다리지 않고 판단할 수 있도록 하고, L3는 중단될 것을 전제로 취급합니다. 그리고 skip / DEGRADED 로그를 남겨 어디까지 신뢰할 수 있는 리뷰였는지를 명확히 합니다. 이 3가지가 운영의 핵심입니다.

AI 리뷰에서 중요한 것은 똑똑한 모델 하나를 선택하는 것만이 아닙니다.

중단되어도 돌아가는 리뷰 체제를 만드는 것.

실무에서 AI 리뷰를 운영에 도입하려면, 정확도뿐만 아니라 가용성과 독립성을 분리하여 설계해야 합니다.

"똑똑한 1개"보다 "중단되어도 돌아가는 여러 개".

이것이 AI 리뷰를 일상적인 운영에 도입하며 얻은 가장 큰 교훈입니다.

FAQ

Q. 왜 단일한 똑똑한 AI 하나로는 안 되나요?

하나만 사용하면 간과(Oversight), 편향(Bias), 환각(Hallucination)이 그대로 통과됩니다.

물론 단일 AI라도 리뷰를 하지 않는 것보다는 낫습니다. 다만, 중요한 변경 사항에서는 여러 관점에서 확인하는 것이 더 안전합니다.

특히 다른 모델이나 다른 관점의 리뷰에서만 나오는 지적 사항이 있습니다.

Q. 같은 모델의 서브 에이전트(Sub-agent)를 병렬로 배치하는 것이 의미가 있나요?

의미가 있습니다.

관점을 나누어 독립적으로 검증하게 하면, 같은 모델이라도 리뷰의 입도(Granularity)는 높아집니다.

단, 같은 모델이라면 동일한 사각지대를 공유할 가능성은 남아 있습니다. 그 사각지대를 줄이기 위해 L3에서 다른 모델의 제3자 리뷰를 도입합니다.

Q. L3가 자주 중단된다면, 더 이상 필요 없는 것 아닌가요?

필요하지 않습니다.

L3의 가치는 가용성이 아니라 모델의 다양성에 있습니다. 실행되었을 때는 L1이나 L2와는 다른 지적 사항이 나올 가능성이 있습니다.

다만, 주 경로로 삼지는 않습니다. "사용할 수 있으면 강력하지만, 중단되어도 멈추지 않는다"는 보조 프레임워크로 취급합니다.

Q. AI 리뷰 결과가 전원 일치하면 안전한가요?

반드시 안전한 것은 아닙니다.

일치는 확신도를 높여주지만, 과신은 금물입니다. 같은 모델, 같은 프롬프트(Prompt), 같은 전제 조건에서 일치하는 것이라면 동일한 사각지대를 공유하고 있을 가능성이 있습니다.

일치 여부를 확인할 때는 얼마나 독립적인 관점에서 일치했는지를 확인합니다.

Q. 리뷰가 늘어나면 비용이나 시간이 늘어나지 않나요?

늘어납니다.

그렇기 때문에 모든 변경 사항에 모든 계층의 리뷰를 적용할 필요는 없습니다.

경미한 변경은 L1만. 일반적인 기능 추가는 L1 + L2. 인증, 권한, 결제, DB Migration, 보안 영향이 있는 변경에 대해서만 L3나 사람의 리뷰를 강화합니다.

리스크에 따라 계층을 추가하는 것이 현실적입니다.

참고

Discussion