계층형 AI 코드 리뷰: AI 생성 PR을 위한 프레임워크

리뷰 큐(review queue)에 변화가 생겼습니다. 코드 차이(diffs)는 더 커졌고, 더 빠르게 도착하며, 점점 더 많은 비중의 코드들이 사람이 변경 사항을 고민하며 작성한 것이 아니라 AI 도구에 의해 생성되고 있습니다. 이것은 불평이 아닙니다. 하지만 여러분의 리뷰 프로세스가 이에 적응하지 못했다면 그것은 문제입니다.

GitClear의 AI 보조 코드 출력에 대한 종단적 분석은 수백만 줄의 코드를 추적하여 AI 도구 사용이 코드 변동성(churn, 작성 직후 다시 작성되거나 삭제되는 라인)의 증가, 복사-붙여넣기 빈도 증가, 그리고 코드 재사용성 감소와 상관관계가 있음을 발견했습니다. NYU의 동료 검토(peer-reviewed) 연구에 따르면 AI 어시스턴트를 사용하는 개발자들은 보안성이 현저히 낮은 코드를 생성하며 이에 대해 과도한 자신감을 보였습니다. 100개 이상의 LLM을 아우르는 Veracode의 분석은 이러한 상황을 더욱 명확히 보여줍니다. AI가 생성한 샘플의 45%가 보안 검사를 통과하지 못했으며, 동일한 인간 작성 코드보다 2.74배 더 많은 취약점을 생성했습니다.

이러한 발견 중 어느 것도 AI 코딩 도구가 순수하게 부정적이라는 의미는 아닙니다. 이를 사용하는 팀은 더 빠르게 제품을 출시합니다. 문제는 모든 AI 생성 PR을 인간이 작성한 PR과 동일한 깊이로 다루는 획일적인 리뷰가 병목 현상을 만든다는 점입니다. 또한 "AI가 아마 맞게 작성했을 거야"라며 리뷰를 건너뛰는 것은 최악의 시점에 드러나는 결함 부채(defect debt)를 조용히 축적하게 만듭니다.

해결책은 보정(calibration)입니다. 즉, 모든 것에 하나의 규칙을 적용하는 대신, 각 PR의 실제 위험도에 맞춰 리뷰 노력을 조절하는 계층형 AI 코드 리뷰(tiered AI code review) 접근 방식입니다.

계층형 코드 리뷰를 위한 세 가지 신호

리뷰어가 diff를 열기 전에, 세 가지 신호가 여러분이 무엇을 다루고 있는지 대략적으로 알려줍니다:

**Code origin (코드 출처)**는 이번 변경 사항 중 얼마만큼이 AI 도구로부터 생성되었는지를 나타냅니다. Copilot의 제안을 몇 번 수락한 사람과, 전체 기능을 계획하고 초안을 작성하여 커밋까지 완료한 Claude Code 세션은 다릅니다. 이 구분이 중요한 이유는 AI 생성 코드(AI-generated code)가 구문론적으로는(syntactically) 결함이 없더라도 논리적으로는 얕을(logically shallow) 수 있기 때문입니다. 린터(linters)는 통과하지만, 불변량(invariants)을 놓치거나, 에러 경로(error path) 처리를 잊거나, 팀의 기억 속에만 존재하는 비즈니스 규칙을 조용히 무시하기도 합니다.

**Change scope (변경 범위)**는 얼마나 많은 줄(lines)이 변경되었는지를 나타냅니다. 완벽한 신호는 아니지만 유용한 신호입니다. Diff가 클수록 리뷰어가 무언가를 놓칠 수 있는 표면적이 넓어지고, 명시적인 인간의 의도 없이 내려진 결정이 많아지며, 단일 리뷰어가 전체 변경 사항을 한 번에 머릿속에 담을 가능성이 낮아집니다.

**Blast radius (영향 범위)**는 코드가 무엇을 건드리는지를 나타냅니다. Fixture 파일을 수정하는 PR은 문제가 생겨도 복구가 가능합니다. 하지만 인증 흐름(auth flow), 결제 프로세서 통합(payment processor integration), 또는 데이터베이스 마이그레이션 스키마(database migration schema)를 건드리는 PR은 그렇지 않습니다. 놓친 결함의 비용은 영향 범위(blast radius)에 따라 커지므로, 리뷰의 깊이가 가장 높아야 하는 지점이 바로 이곳입니다.

세 가지 신호가 결합하여 리뷰 티어(review tier)를 할당하는 방식. 영향 범위(Blast radius)는 우선순위 결정권(override)을 가집니다: 크리티컬 패스(critical path)는 출처나 범위에 관계없이 항상 Tier 3에 해당합니다.

티어 결정 매트릭스 (The tier decision matrix)

Code Origin (코드 출처)	Change Scope (변경 범위)	Blast Radius (영향 범위)	Review Tier (리뷰 티어)
Human only (인간 전용)	Any (모든 범위)	Tests, docs, scripts (테스트, 문서, 스크립트)	Tier 1: Skim (훑어보기)
...

마지막 행은 팀들이 가장 실행을 소홀히 하기 쉬운 부분입니다. OAuth 콜백 핸들러(OAuth callback handler)에 대한 40줄짜리 AI 생성 변경 사항은 여전히 Tier 3입니다. 영향 범위(blast radius)는 다른 모든 것을 압도합니다.

리뷰 티어 분류에 따른 상대적 결함 위험도 (예시이며, GitClear 2024의 일반적인 조사 결과에서 도출되었으며, 티어별로 측정된 데이터는 아님). AI가 생성한 Tier 3 PR은 리뷰 전 미검출 결함(uncaught-defect) 위험이 가장 높음.

각 티어가 실제로 요구하는 사항

Tier 1 (Skim, 훑어보기): 리뷰어 1명. CI(지속적 통합) 통과 필수. 문제가 없어 보이는 부분을 포함하여 전체 diff(차이점)를 처음부터 끝까지 읽어야 합니다. "CI 통과" 외에 유일하게 필수적인 확인 사항은 하드코딩된 자격 증명(credentials)이나 API 키가 없는지 확인하는 것입니다. 목표 처리 시간: 4시간.

Tier 2 (Scrutinize, 정밀 검토): 리뷰어 1명, 더 높은 주의 필요. 리뷰어는 포맷팅을 평가하는 것이 아니라 로직을 이해하려는 의도로 변경된 모든 함수를 읽습니다. 새로운 브랜치에 대한 테스트 커버리지(Test coverage)는 선택 사항이 아닌 필수 사항입니다. 프로젝트에 추가되는 모든 새로운 의존성(dependency)은 라이선스, 유지 관리 상태, 그리고 예상치 못한 요소를 포함하는지 여부에 대해 감사를 받습니다. 만약 PR이 AI에 의해 생성되었고 서비스 경계(service boundary)를 넘나든다면, 보안 스캔(security scan)을 실행하십시오. 목표 처리 시간: 24시간.

Tier 3 (Mandatory Sign-off, 필수 승인): 리뷰어 2명, 그 중 한 명은 테크 리드(tech lead). CI 필수. 보안 스캔 필수. PR 설명에는 롤백 계획(rollback plan)과 해당 변경 사항이 스테이징(staging) 환경에서 테스트되었다는 증거가 포함되어야 합니다. EU AI Act의 적용을 받는 시스템(고위험 AI 의무 사항은 2026년 8월부터 적용됨)을 구축하는 팀의 경우, 이 티어는 규제 관련 접점(regulatory touchpoints)을 표시하고 문서화하는 단계이기도 합니다. 목표 처리 시간: 48시간.

Tier 3는 제약이 아니라 관문(gate)입니다. 결제 흐름(payment flow)을 건드리기 때문에 Tier 3에 속하게 된 PR은 문제가 있는 PR이 아닙니다. 그것은 다른 종류의 주의를 기울일 가치가 있는 PR일 뿐입니다.

티어 할당 자동화

수동 레이블링(Manual labeling)은 하루에 약 5개 정도의 AI 생성 PR까지는 효과적입니다. 그 이상의 경우에는 diff 크기와 변경된 경로를 읽어 적절한 레이블을 자동으로 할당하는 GitHub Actions 워크플로우를 사용할 수 있습니다. 기여자가 푸시(push)할 때 ai-generated 레이블을 추가하면, 워크플로우가 그 시점부터 티어(tier) 계산을 처리합니다.

# .github/workflows/pr-tier.yml
name: PR Review Tier

...

이 워크플로우가 실행되기 전에, GitHub 저장소 설정에서 세 가지 레이블(review/tier-1, review/tier-2, review/tier-3)을 생성하십시오. grep -qE에 사용된 경로 패턴은 예시일 뿐이므로, 실제 디렉토리 구조에 맞게 조정하십시오.

ai-generated 레이블은 현재 기여자가 수동으로 설정합니다. 만약 사용 중인 AI 도구의 GitHub App이 커밋(commit) 시 레이블링을 지원한다면, 이 과정 또한 자동화할 수 있습니다.

팀이 커밋할 수 있는 정책 템플릿

자동화는 할당(assignment)을 처리합니다. 명문화된 정책은 리뷰어가 실제로 무엇을 해야 하는지를 다룹니다. 이 내용을 .github/에 커밋하고 CONTRIBUTING.md에서 이를 참조하십시오:

# .github/ai-review-policy.yml
# AI 보조 및 AI 생성 풀 리퀘스트(pull requests)를 위한 리뷰 정책.
# 이 파일의 버전을 관리하십시오. 팀의 신뢰 보정(trust calibration) 상태가 변할 때 업데이트하십시오.
...

이것은 시작점일 뿐입니다. 특히 서비스 수준 협약(SLA)은 팀의 실제 역량과 일치해야 합니다. 티어 3(Tier 3)에 대한 48시간은 목표가 아니라 상한선입니다.

리뷰 도구가 할 수 있는 것과 할 수 없는 것

2026년 3월, Anthropic은 Claude를 위한 전용 코드 리뷰 도구를 출시하며, CodeRabbit, Bito 등의 기존 도구들과 합류했습니다. 이러한 도구들은 명백한 문제들을 자동으로 드러내 주며, 모든 PR에 대한 CI(지속적 통합)의 일부로 실행할 가치가 있습니다. 하지만 이 도구들이 티어 할당(tier assignment)을 대체하지는 않습니다.

티어(tier)는 누가, 어느 정도의 주의를 기울여, 어떤 체크리스트를 가지고 결과물을 검토할지를 결정합니다. 자동화된 리뷰어는 의심스러운 SQL 삽입(SQL interpolation)을 찾아낼 수 있습니다. 하지만 새로운 인증 미들웨어(auth middleware)가 제3자 SSO 연동의 동작을 중요한 방식으로 변경하는지 여부는 알려줄 수 없습니다. 그것은 여전히 인간의 판단 영역이며, 티어는 적절한 사람이 그 판단을 내리도록 보장하는 방법입니다.

티어를 정착시키는 방법

아무도 읽지 않는 파일에만 존재하는 정책은 유지될 수 없습니다. 문서화보다 더 도움이 되는 두 가지 요소는 다음과 같습니다:

라벨이 가시적이어야 합니다. 리뷰어가 PR(Pull Request) 목록을 열었을 때 4개의 열린 PR에 review/tier-3가 표시되어 있다면, 클릭하기 전부터 해당 리뷰에 무엇이 필요한지 알 수 있습니다. 이러한 가시성은 대충 훑어보는 것이 실제 리뷰를 대신하게 될 가능성을 줄여줍니다.

패턴 추적 또한 중요합니다. 만약 Tier 3 대기열이 지속적으로 특정 서비스, 특정 기여자 패턴, 또는 특정 유형의 AI 생성 결과물에 의해 점유된다면, 이는 리뷰 시점에만 대응할 것이 아니라 근본적으로 해결해야 할 신호입니다. 일부 팀은 어떤 작업 항목이 AI 에이전트(AI agents)에 의해 완료되었고 어떤 항목이 여전히 인간의 승인을 기다리고 있는지 추적하기 위해 공유 작업 보드(task board)를 사용합니다. 예를 들어, Agiflow의 Claude Code 연동은 엔지니어링 리드에게 진행 중인 작업과 함께 AI 에이전트의 작업 인수인계(handoffs) 현황을 보여주므로, 리뷰어가 diff(차이점)를 열기 전에 맥락을 파악할 수 있게 해줍니다.

증거를 통한 신뢰

AI 코드 품질에 대한 데이터는 실재하며, 이에 대한 올바른 대응은 AI가 생성한 코드를 영구적으로 의심스러운 것으로 취급하는 것이 아닙니다. 대신, 시간이 지남에 따라 여러분의 보정(calibration)이 올바른지 알려주는 일종의 증거 추적(evidence trail)을 구축하는 것입니다.

매트릭스(matrix)로 시작하세요. 라벨을 추가하세요. 워크플로(workflow)를 배포하세요. 한 달 뒤, AI 생성 PR과 인간 생성 PR의 Tier 2 결함률(defect rate)을 비교해 보세요. 두 수치가 수렴하고 있다면 임계값(thresholds)을 강화하십시오. 만약 수렴하지 않는다면, 어디에 더 많은 주의를 기울여야 하는지를 알려주는 신호를 발견한 것입니다.

그것이 바로 계층형 코드 리뷰 시스템에서 유지되는 신뢰의 형태입니다. 도구가 개선됨에 따라 획득되고, 구체적이며, 조정되는 신뢰 말입니다. 이는 반사적인 승인도 아니며, 영구적인 의심도 아닙니다.