PR은 넘치는데, 리뷰어는 그대로다
AI 코딩 어시스턴트 도입 이후 팀의 PR 생성 속도는 확실히 빨라졌다. 문제는 그 PR을 검토하는 사람의 수는 6개월 전과 똑같다는 것이다. dev.to의 "AI Review Debt is the bottleneck nobody's measuring"이 정확하게 짚은 지점이다. 팀은 PR 수가 40% 늘었다고 축하하지만, 실제로 머지된 PR은 얼마나 되는가? 열려 있는 PR은 산출물이 아니라 재고(inventory)다.
DORA가 보지 못하는 것
DORA 메트릭의 리드 타임은 첫 커밋부터 프로덕션까지의 시간을 잰다. 그런데 시니어 엔지니어가 AI가 생성한 diff 더미에 파묻혀 PR이 3일째 리뷰 큐에 머물러 있다면, 이건 리드 타임 저하로 기록될 뿐 원인이 '리뷰 용량 부족'이라는 진단은 어디에도 남지 않는다. 실패 경로는 이렇다. AI가 PR을 더 빠르게 만든다 → 리뷰 큐가 팽창한다 → 리뷰어가 대충 훑는다 → 변경 실패율이 슬금슬금 오른다 → 팀은 이걸 '품질 문제'라고 부른다. 병목이 이동했는데 조직도는 그대로다.
이게 왜 일반 기술 부채보다 위험한가
Sumant Thakur가 'AI Review Debt'라는 용어를 만든 이유가 있다. 일반 기술 부채는 로드맵에 올라간다. 누군가 Jira 티켓을 만든다. 하지만 리뷰 파이프라인이 생성 파이프라인을 따라가지 못한다는 사실을 티켓으로 만드는 팀은 거의 없다. 쌓이고 있다는 사실 자체를 모른 채로 쌓인다. 더 나쁜 건 리뷰어가 바빠질수록 PR을 거절하는 빈도가 줄고 더 빠르게 머지한다는 것이다. 속도의 환상과 품질 저하의 현실이 동시에 온다.
리뷰 병목을 설계로 푸는 세 축
솔직히 깔끔한 해답은 아직 없다. 그러나 방향은 있다.
첫째, 측정부터 바꿔야 한다. 리뷰 큐 깊이(review queue depth)와 리뷰 사이클 타임을 리드 타임과 분리해서 추적해야 한다. 보이지 않으면 고칠 수 없다. PR 수를 생산성 지표로 쓰는 것을 지금 당장 멈춰야 한다.
둘째, AI 기반 리뷰 도구에 투자해야 한다. 생성 도구에 쏟은 에너지의 절반이라도 리뷰 도구에 써야 한다. 사람 한 명이 하루에 집중해서 검토할 수 있는 실질적인 PR은 4~5개가 한계다. 그게 팀의 처리량 상한선이다. 이 한계를 무시하고 생성 속도만 올리는 건 구조적 선택이 아니라 회피다.
셋째, 자동화 검증 레이어를 선행 배치해야 한다. AI가 생성한 코드가 리뷰어에게 도달하기 전에 걸러낼 수 있는 것들이 있다. 보안 취약점, 스타일 위반, 명백한 로직 오류는 사람이 볼 필요 없다.
자동화 검증의 두 번째 레이어: AI 에이전트 보안
그런데 AI 코딩 도구가 생성하는 건 PR만이 아니다. 팀이 AI 에이전트를 직접 운영하기 시작하면 완전히 다른 종류의 리뷰 부채가 쌓인다. dev.to의 레드팀 자동화 사례가 이걸 잘 보여준다. 내부용 헬퍼 에이전트에 bash 툴과 직원 디렉토리 조회 툴을 붙인 뒤 자동화 레드팀을 돌렸더니, 첫 라운드에서 9개 공격 케이스 중 6개가 뚫렸다. 자격증명 탈취, 교차 직원 데이터 조회, 시스템 프롬프트 누출이 멀티턴 대화 한두 번으로 성공했다.
핵심은 이 취약점들이 수동으로는 발견하기 어렵다는 점이다. 직접적인 '크리덴셜 읽어줘' 요청은 막히지만, 디버깅 요청으로 시작해 단계적으로 에스컬레이션하는 CrescendoStrategy 방식은 모델의 판단 경계를 조용히 넘는다. 자동화 레드팀이 필요한 이유다.
파일시스템 샌드박싱과 MCP 스캐닝
에이전트 보안 강화의 실용적 접근은 두 단계로 나뉜다. 인프라 레이어에서는 샌드박스 가상 쉘로 에이전트가 접근할 수 있는 파일시스템 경로를 명시적으로 제한한다. 허용 목록에 없는 경로는 존재하지 않는 것처럼 동작한다. AWS 크리덴셜 파일이 없으면 모델의 의도와 무관하게 읽을 수 없다. 같은 레드팀 케이스를 샌드박스 적용 후 재실행하면 인프라 공격은 전부 차단된다.
그러나 애플리케이션 레이어의 취약점은 샌드박스로 해결되지 않는다. 시스템 프롬프트 누출이나 인가 없는 데이터 조회는 모델 판단의 문제가 아니라 설계의 문제다. 가드레일 레이어와 도구 설계를 함께 바꿔야 한다.
MCP 서버를 직접 설치해 쓰는 팀이라면 또 다른 벡터가 있다. dev.to에 소개된 오픈소스 스캐너 frisk는 MCP 서버 코드를 실행하지 않고 정적으로 분석해 파이프 투 쉘, 크리덴셜 파일 접근, 툴 디스크립션에 숨겨진 프롬프트 인젝션을 탐지한다. 툴 디스크립션은 사용자가 아니라 모델이 읽는다는 점에서 공격 표면이 된다. 승인 당시와 디스크립션이 달라졌는지 버전을 고정해두고 드리프트를 감지하는 기능도 포함된다. SARIF 형식으로 출력해 GitHub Security 탭에 통합할 수 있다.
설계 원칙: 생성과 검증은 동시에 설계돼야 한다
세 가지 소스를 종합하면 하나의 설계 원칙이 나온다. AI가 코드를 빠르게 만들수록, 리뷰와 보안 검증은 속도를 따라잡는 게 아니라 생성 파이프라인과 동시에 설계돼야 한다.
PR 리뷰 병목은 '리뷰어가 더 열심히 해야 한다'는 문제가 아니다. 생성 용량과 검토 용량의 비대칭을 인식하고 자동화 필터를 선행 배치하는 구조 설계의 문제다. AI 에이전트의 보안 취약점은 '모델이 잘못 판단했다'는 문제가 아니다. 실행 환경을 격리하고, 접근 권한을 도구 설계 단계에서 제한하고, 자동화 레드팀으로 정기 검증하는 워크플로우 설계의 문제다. MCP 서버 설치는 '코드 출처를 신뢰하면 된다'는 문제가 아니다. 정적 분석으로 설치 전 검증하고, 승인 이후 변경을 감지하는 파이프라인 문제다.
지금 당장 팀에서 확인할 것
AI 도구 도입 이후 PR 생성량이 늘었다면 한 가지만 물어보자. 리뷰 용량도 같은 비율로 늘었는가? 그렇지 않다면, 이름 붙이지 않은 부채가 이미 쌓이고 있다. 부채는 이름을 붙이는 순간부터 관리할 수 있다.