코드 리뷰가 병목이 되는 이유 | 메타 시니어 엔지니어가 AI 코드 리뷰 하는법

한 줄 핵심

코드 리뷰 병목을 줄이기 위해 PR 전 셀프 리뷰와 PR 후 자동 리뷰를 결합한 AI 코드 리뷰 에이전트를 만들고, 리스크 점수와 안전 가드로 자동 머지까지 단계적으로 확장하는 방법을 보여준다.

시간별 요약

1. 0:00
   추석 인사와 무료 공개 안내 연휴 인사와 함께 이번 강의의 두 번째 편이 무료로 공개되었고, 할인 안내와 후속 이벤트 예고가 덧붙는다. 가볍게 핵심만 훑어보는 복습용 영상이라는 성격이 강조된다.
2. 0:53
   이번에 만들 것: 코드 리뷰 에이전트 리포지토리에서 자동으로 코멘트를 달고, 조건이 맞으면 사람을 거치지 않고 머지까지 이어질 수 있는 코드 리뷰 워크플로를 만든다. 단순한 “리뷰해 줘”가 아니라 실제 저장소에 바로 적용 가능한 흐름을 목표로 한다.
3. 1:45
   2024년과 2026년 — 바뀌는 리뷰 풍경 사람이 수동으로 PR을 처리하던 2024년과 달리, 2026년에는 AI가 1차 리뷰를 끝내고 사람은 중요한 PR만 깊게 보는 구조가 된다. 사람을 대체하는 것이 아니라 더 중요한 판단에 재배치하는 변화다.
4. 2:48
   AI 리뷰어의 4가지 강점 24/7 즉시성, 일관된 기준, 긴 PR에서의 누락 감소, 그리고 사람이 고차원 판단에 집중할 수 있게 하는 점이 핵심 강점이다. 특히 컨벤션 위반 같은 저가치 작업을 AI가 맡아야 리뷰 병목이 줄어든다.
5. 4:10
   두 갈래 리뷰 시점: PR 전과 PR 후 리뷰는 커밋 또는 PR 생성 전에 로컬에서 한 번, PR이 올라간 뒤에 한 번 돌아야 한다. 전자는 명백한 실수와 저품질 변경을 막고, 후자는 팀 전체가 보는 정제된 1차 리뷰 역할을 한다.
6. 6:34
   리뷰 유형과 라벨 기반 라우팅 전체 훑기, 파일 단위 리뷰, 보안 특화, 성능 특화, 테스트 확인, 아키텍처 변경 확인처럼 리뷰를 유형별로 나눌 수 있다. PR 라벨로 라우팅하면 인증 변경에는 보안 리뷰, 마이그레이션에는 아키텍처 리뷰를 자동으로 붙일 수 있다.
7. 8:32
   리스크 점수 루브릭 설계 (0~100) 보안, 범위, breaking change, 테스트 커버리지, 마이그레이션 위험 등을 기준으로 PR에 0~100점의 리스크를 매긴다. 점수가 높으면 사람 검토가 필요하고, 점수가 낮으면 자동 처리 범위를 넓힐 수 있다.
8. 11:25
   리스크별 액션 매트릭스와 자동 머지 기준 low는 코멘트 후 자동 머지 후보, medium은 사람 승인 필수, high는 추가 리뷰, critical은 머지 차단으로 대응한다. 자동 머지는 처음부터 보수적으로 시작하고, 데이터가 쌓인 뒤 임계치를 조정하는 것이 안전하다.
9. 12:38
   사람이 봐야 할 것과 AI에게 맡길 것 아키텍처 결정, 보안 모델, 트레이드오프, 비즈니스 적합성, API 설계 같은 고차원 판단은 사람이 맡아야 한다. 규칙, 패턴, 일관성, 누락 탐지처럼 반복적이고 명확한 영역은 AI가 맡는 것이 효율적이다.
10. 13:21
    도구: /code-review · Ultra Review · Codex 크로스 리뷰 Claude의 /code-review, 더 정밀하지만 비용이 드는 Ultra Review, 그리고 Codex와의 교차 리뷰가 소개된다. 같은 모델의 자기 리뷰보다 서로 다른 에이전트를 교차 사용하면 확증 편향을 줄일 수 있다.
11. 14:30
    도입 전 안전 가드 자동 머지는 바로 도입하지 말고 팀 합의, 저위험 PR부터의 점진적 적용, 코멘트만 먼저 달아보는 드라이런이 필요하다. 야간·주말 비활성화, 작성자 화이트리스트 같은 게이트도 안전장치로 유효하다.
12. 16:09
    실습 ① PR 전 셀프 리뷰 훅 만들기 커밋 또는 PR 생성 전에 Claude 코드 리뷰를 강제로 돌리는 훅을 설정한다. 이 단계에서 기본적인 실수와 컨벤션 위반을 잡아 동료의 시간을 아끼고 PR 신뢰도를 높인다.
13. 21:52
    커밋 대신 pre-push 훅으로 커밋마다 리뷰를 돌리기보다 pre-push 시점에서 실행하는 편이 토큰 낭비와 생산성 저하를 줄인다. 즉, 너무 이른 단계가 아니라 실제로 올리기 직전에 한 번 정제하는 구조가 적절하다.
14. 24:30
    세션 fork로 테스트하기 본 세션을 복제한 fork 환경에서 실제 훅 동작을 시험해 본다. 실제 저장소를 건드리지 않고도 리뷰 흐름이 제대로 작동하는지 검증할 수 있다.
15. 26:18
    일부러 버그를 심어 훅이 막는지 확인 명백한 버그를 넣은 브랜치를 푸시해 훅이 실제로 문제를 잡아내고 푸시를 중단하는지 확인한다. 리뷰 자동화가 단순 설정이 아니라 실제 방어선으로 동작하는지를 검증하는 단계다.
16. 27:41
    실습 ② GitHub Actions + GPT PR 리뷰 스크립트 GitHub Actions에서 GPT API를 사용해 PR이 열리거나 갱신될 때 자동으로 리스크를 계산하고 코멘트를 달게 만든다. 환경변수와 스크립트, 루브릭을 엮어 PR 후 리뷰 자동화를 구현한다.
17. 31:06
    API 키가 노출됐다면 지우고 새로 만들기 API 키는 집 열쇠처럼 다뤄야 하며, 노출됐다면 즉시 폐기하고 새로 발급해야 한다. 자동화 실습 중에도 비밀 정보 관리가 최우선이라는 점을 다시 강조한다.
18. 34:21
    테스트 PR로 risk low 판정 확인 README 같은 문서 변경 PR을 올려 low risk 판정과 자동 처리 흐름이 제대로 나오는지 확인한다. 이 단계는 자동 머지 기준을 실제 데이터로 검증해 볼 수 있는 테스트다.
19. 36:03
    숙제와 정리 low risk일 때 자동 머지하도록 직접 바꿔 보라는 숙제가 제시된다. 핵심은 AI 리뷰를 PR 전과 PR 후에 나눠 적용하고, 보수적인 기준으로 시작해 팀 단위 리뷰 병목을 점진적으로 줄이는 것이다.

실무 인사이트

• AI 코드 리뷰는 사람을 대체하는 도구가 아니라, 사람을 아키텍처·보안·트레이드오프 같은 고차원 판단으로 재배치하는 장치로 설계해야 한다.
• 실무에서는 PR 전 셀프 리뷰 훅과 PR 후 GitHub Actions 리뷰를 분리해 두 단계로 운영해야 병목을 줄이면서 품질도 유지할 수 있다.
• 자동 머지는 기술보다 거버넌스가 더 중요하므로, 처음에는 low/medium 기준을 보수적으로 잡고 팀 합의와 테스트 데이터를 쌓은 뒤 확장해야 한다.