AI 코드 리뷰를 켰는데, 왜 팀이 더 피로해졌나
AI 코드 리뷰 자동화를 도입한 팀들이 공통적으로 겪는 문제가 있다. 리뷰 코멘트가 쏟아지기 시작하는 순간, 오히려 개발 속도가 느려지고 팀원들의 피로감이 올라간다. 직관적으로는 이상하다. 리뷰어가 하나 늘었는데 왜 일이 더 많아지는가.
답은 단순하다. 리뷰 코멘트를 처리하는 프로토콜 없이 AI 리뷰어만 추가했기 때문이다. dev.to에 공유된 실무 경험담에 따르면, AI가 생성한 리뷰 코멘트를 모두 동일하게 취급하는 순간 문제가 시작된다. '코멘트가 왔으니 처리한다'는 방식은, 인간 리뷰어 한 명이 모든 말을 들어야 하는 것만큼 비효율적이다. AI 리뷰어는 틀린 말도 하고, 이미 해결된 문제를 다시 지적하기도 하며, 의도를 잘못 읽고 더 큰 리팩터링을 암시하기도 한다. 이 노이즈를 필터링하는 구조가 없으면 AI 리뷰는 '더 긴 크리티컬 패스'가 될 뿐이다.
트리아주 프로토콜: 코멘트를 세 버킷으로 분류하라
실무에서 검증된 접근은 모든 AI 리뷰 코멘트를 세 버킷으로 즉시 분류하는 것이다.
- 버킷 1 — 바로 처리: 명확하고, 아키텍처에 영향 없고, 리스크가 낮다. 중복 문서 섹션 삭제, 링크 수정 같은 기계적 작업. 판단 없이 실행하고 다음으로 넘어간다.
- 버킷 2 — 사람이 결정: 코멘트가 모호하거나, 보안 정책·아키텍처 판단이 얽혀 있거나, 암묵적으로 더 큰 변경을 요구한다. AI가 혼자 해석하고 실행하면 안 된다. 반드시 사람의 판단이 개입해야 한다.
- 버킷 3 — 조용히 무시: 이미 처리된 문제의 재지적, 구버전 파일 기준의 제안. 응답할 필요도 없다. 리뷰 스레드에 '이미 처리했습니다' 댓글을 남기는 것조차 주의력 낭비다.
이 분류가 중요한 이유는 리뷰 피로의 진짜 원인이 코멘트 양이 아니라 '모호한 코멘트를 바로 실행하다 잘못 처리하고, 재리뷰하는 루프'이기 때문이다. 특히 위험한 패턴은 AI가 코드를 쓰고, 두 번째 AI가 리뷰하고, 첫 번째 AI가 리뷰를 그대로 수용하는 회로다. 두 모델이 서로 동의하는 것처럼 보이지만, 실제로는 상관된 오류가 복리로 쌓이는 구조다. 버킷 2는 이 루프를 끊기 위해 존재한다.
CLAUDE.md는 프롬프트 파일이 아니라 운영 경계 문서다
AI 코드 리뷰 에이전트를 팀 워크플로우에 심을 때 두 번째로 설계해야 할 레이어가 있다. 에이전트의 운영 경계(Operating Boundary)다. dev.to의 또 다른 실무 글은 이 문제를 정면으로 다룬다: CLAUDE.md를 '더 좋은 프롬프트'로 쓰는 팀은 결국 실패한다.
'신중하게 생각해라', '작은 변경만 해라' 같은 문장은 동기부여 메모일 뿐이다. 에이전트에게 필요한 것은 이 리포지터리에서 '좋다'는 게 무엇인지다. 생성 파일을 수정해야 하는 리포와 절대 건드리면 안 되는 리포는 다르다. 프로덕션 배포가 자동으로 트리거되는 구조와 수동 확인이 필요한 구조도 다르다. 이 차이를 제네릭 프롬프트로 전달할 수 없다.
운영 경계 문서는 세 섹션으로 시작하면 충분하다.
- Project: 이 리포지터리가 운영 언어로 무엇을 하는가. '생산성을 향상시킨다'가 아니라 '마크다운 아티클을 note.com 드래프트로 변환하고 드래프트 URL을 유지한다'처럼 작성해야 한다. AI에게 무엇이 깨지면 안 되는지를 알려주는 문장이다.
- Boundaries: AI가 확인 없이 할 수 있는 것, 확인이 필요한 것, 절대 자동으로 하면 안 되는 것.
rm -rf, 강제 푸시, 배포, 빌링, 외부 계정 변경은 기본이고—생성 파일 읽기 전용 여부, 마이그레이션 롤백 필수 여부, 사용자 편집 복원 금지 여부 같은 프로젝트 로컬 경계도 여기에 담긴다. - Done: '완료'가 무엇을 의미하는가. 편집이 끝나는 것이 완료가 아니다. 빌드+린트+브라우저 스크린샷인지, 테스트+계약 샘플인지를 명시해야 에이전트가 중간에 멈추지 않는다.
핵심은 규칙이 실패했을 때 더 강하게 쓰는 게 아니라 스톱 컨디션으로 바꾸는 것이다. '배포 전에 신중해라'를 열 번 강조하는 것보다, 'owner_reviewed: false이면 멈추고 드래프트 URL을 출력하라'가 훨씬 안정적으로 작동한다. 구체적인 스톱 컨디션일수록 모델의 해석 여지가 줄어든다.
Read-Only First: 권한은 신뢰를 증명한 뒤에 확장하라
세 번째 레이어는 에이전트 도입의 순서 설계다. dev.to의 플랫폼 엔지니어링 관련 글은 이 문제를 'Read-Only First 모델'로 정리한다.
프로덕션에 에이전트를 투입할 때 가장 흔한 실수는 처음부터 쓰기 권한을 주는 것이다. 에이전트가 인시던트를 자동으로 수정하게 하는 것보다, 먼저 상황을 빠르게 이해하게 하는 것이 훨씬 안전하고 실제로 더 큰 가치를 만든다. 대부분의 인시던트는 '수정'보다 '파악'이 먼저다: 무엇이 바뀌었는가, 어느 파드가 실패 중인가, 롤아웃이 방금 일어났는가.
단계적 롤아웃 모델은 이렇게 설계할 수 있다.
- 1단계: 읽기 전용 단일 클러스터 인스펙션
- 2단계: 읽기 전용 멀티 클러스터 인스펙션
- 3단계: 승인된 채널 ChatOps 통합
- 4단계: 승인 게이트 진단 exec
- 5단계: 승인 게이트 저위험 remediation
- 6단계: PR 기반 설정 수정
- 7단계: 정책 기반 자동 remediation
각 단계는 이전 단계의 신뢰를 증명한 후에만 열린다. 읽기 전용이라고 가드레일이 불필요한 게 아니다. 로그에 민감 데이터가 있을 수 있고, 리소스 이름이 아키텍처를 노출할 수 있다. 읽기 전용 에이전트도 인증, 인가, 감사 로그, 네임스페이스 스코핑, 레이트 리밋이 필요하다. 차이는 실패 시 블라스트 레이디어스가 작다는 것이다.
팀 리드가 설계해야 할 것
세 소스를 조합하면 AI 코드 리뷰 에이전트를 팀에 안전하게 심기 위한 구조가 보인다.
트리아주 프로토콜 → 운영 경계 문서 → 단계적 권한 확장, 이 세 레이어를 순서대로 설계하지 않으면 각각이 단독으로는 작동하지 않는다. 트리아주 없이 AI 리뷰를 켜면 노이즈가 쌓인다. 운영 경계 없이 에이전트를 리포에 넣으면 암묵적 규칙을 에이전트가 추측한다. 단계 설계 없이 쓰기 권한을 주면 팀의 신뢰가 한 번의 사고로 무너진다.
지금 AI 코드 리뷰를 도입하는 팀에게 가장 먼저 물어볼 것은 이것이다: 코멘트가 왔을 때 팀이 어떻게 행동하는가가 명문화되어 있는가. 도구를 켜는 것보다 그 도구의 출력을 처리하는 프로토콜을 먼저 써두는 팀이, 6개월 뒤에 AI 리뷰를 진짜 자산으로 운영하고 있다.
전망: 에이전트의 권한은 팀의 성숙도를 따라간다
AI 코드 리뷰 에이전트는 앞으로 더 빠르게 리포 전체에 확산될 것이다. GitHub Actions, CI 파이프라인, PR 자동화가 결합되면 에이전트가 코드를 리뷰하고, 수정하고, 머지까지 제안하는 워크플로우는 기술적으로 이미 가능하다.
하지만 기술적 가능성과 팀 운영 준비는 다른 문제다. Read-Only First 모델이 말하는 것처럼, 에이전트의 권한은 팀이 증명한 신뢰의 크기를 넘지 않아야 한다. 트리아주 프로토콜이 팀 문화에 정착되지 않은 상태에서 에이전트에게 머지 권한을 주는 것은, 두 AI가 서로의 출력을 검증 없이 수용하는 루프를 프로덕션에 심는 것과 같다.
설계는 도구보다 먼저다. AI 코드 리뷰를 켜기 전에 팀의 프로토콜을 먼저 써라.