수치가 먼저다
2026년 3월, Faros AI가 4,000개 팀 22,000명 개발자를 대상으로 AI 도입 전후를 추적한 결과가 공개됐다. 처리량은 올랐다. 그런데 코드 churn은 861% 증가했고, 개발자당 결함률은 9%에서 54%로 뛰었다. 인시던트 대 PR 비율은 242.7% 늘었고, 리뷰 없이 머지된 PR은 31.3% 증가했다. GitClear 데이터는 여기에 한 줄을 더한다—AI를 매일 쓰는 개발자는 비사용자 대비 원시 산출량이 4배지만, 1년 전 자신 대비 실제 생산성 향상은 약 12%에 불과하다.
이 숫자들이 불편한 이유는 단순하다. 생산성 4배라는 말이 틀린 게 아니라, 그 4배가 팀 전체의 리뷰 역량을 가정하지 않은 숫자라는 것이다.
병목이 이동했다
코딩 에이전트가 등장하기 전까지 병목은 '얼마나 빨리 쓰느냐'였다. 지금은 다르다. 병목은 '이 코드를 얼마나 빨리 신뢰할 수 있느냐'로 이동했다. 그리고 그 이동이 팀의 현실에서 어떻게 나타나는지는 이미 측정됐다—리뷰 소요 시간 441% 증가, 리뷰어가 물량을 따라가지 못해 읽히지 않은 코드가 머지되는 것이 일상화됐다.
CodeRabbit의 오픈소스 PR 470개 분석에서는 AI 공동작성 코드가 사람만 작성한 코드 대비 로직·정확성 문제 약 75% 증가, 보안 이슈 1.5~2배, 가독성 문제 3배 이상을 동반했다. 이건 예측 불가능한 실패가 아니다. "예측 가능하고 위치를 특정할 수 있는 약점"이다. 그 말은 곧, 리뷰 프로세스를 정조준해서 설계할 수 있다는 뜻이기도 하다.
리뷰가 더 어려워진 진짜 이유
에이전트는 추론한다. 그런데 그 추론이 diff가 완성되는 순간 버려진다. PR에 남는 건 결과 코드뿐이고, 리뷰어는 "이 코드를 처음으로 본 인간"이 된다. 사람이 코드를 짤 때는 의도가 공짜로 따라왔다. 저울질하고 버린 대안이 작성자 머릿속에 있었고, 리뷰는 그 추론을 점검하는 일이었다. 에이전트 PR에서 리뷰어가 해야 하는 일은 그게 아니다—사라진 의도를 처음부터 재구성하는 일이다. 리뷰 시간이 441% 늘어난 건 리뷰어가 게을러서가 아니다.
이 문제를 워크플로우 수준에서 절반쯤 해결하는 방법이 있다. Claude Code 수석 디자이너 Meaghan Choi가 공개한 워크플로우에서 힌트를 얻을 수 있다. 그는 에이전트에게 스크린샷과 GIF가 포함된 PR을 자동 생성하게 하고, 구현 결과의 녹화가 담긴 PR을 검토하는 방식으로 전환했다. 코드 트랜스크립트가 아니라 동작 증거를 먼저 보는 것이다. Qwen Code 워크플로우에서도 유사한 패턴이 보인다—/plan 모드에서 스펙을 먼저 확정하고 코드를 나중에 쓰는 방식으로, 리뷰어가 재구성해야 할 의도를 제출 전에 제출자가 먼저 적게 만든다.
blast radius로 리뷰 강도를 설계하라
모든 PR에 동일한 리뷰를 붙이는 건 두 방향으로 모두 틀렸다. 설정 변경에 풀스택 리뷰를 쓰는 건 무의미한 마찰이고, 결제 로직에 "테스트 통과하니 배포"를 적용하면 초록 체크 달린 인시던트 생성기가 된다.
리뷰 강도를 결정하는 변수는 세 가지다. blast radius—망가졌을 때 아무 일도 없는가, 사용자 피해·금전·PII 노출이 발생하는가. 코드 수명—다음 주 다시 쓸 프로토타입인가, 수년간 유지할 코드베이스인가. 이해해야 하는 사람 수—본인뿐인가, 팀 전체인가.
이 세 변수로 리뷰 레이어를 계층화하면 이렇게 된다. 설정 변경은 린터와 한 번 훑기. 핵심 비즈니스 로직은 타입 검사·테스트·서로 다른 두 AI 리뷰어·해당 시스템 소유자인 사람·보안 패스의 풀스택. 보일러플레이트에 무거운 리뷰를 쓰지 말고, 테스트가 초록이라고 큰 변경을 통과시키지 말 것.
AI 리뷰 도구, 하나로 충분하지 않다
4개 리뷰어(CodeRabbit·Sentry Seer·Greptile·Cursor BugBot)를 3주 반 동안 146개 PR에 병렬 적용한 실험 결과가 있다. 발견된 617개의 고유 플래그 위치 중 93.4%가 정확히 하나의 도구에서만 검출됐다. 넷이 동시에 같은 줄을 플래그한 경우는 단 한 번도 없었다.
이게 말하는 것은 단순하다. 한 모델 4벌은 청구서만 커진 단일 리뷰어다. 진짜 다른 성격의 4개 리뷰어가 누구도 단독으로 못 찾는 버그를 드러낸다. Greptile은 아키텍처·정확성에서 거짓 양성이 거의 없고, CodeRabbit은 가장 넓은 그물과 원클릭 수정을 제공하며, Sentry Seer는 운영 장애 심각도 탐지에 강하다. 단 하나의 최고 도구를 고민할 필요가 없다—그런 건 없다. 고위험 영역에서는 의도적으로 성격이 다른 둘을 병행하는 것이 현실적 접근이다.
그리고 AI 리뷰는 판결이 아니라 센서다. "looks good"은 반드시 획득되지 않은 확신을 건네는 것이다. AI 리뷰 결과는 결정이 아니라 데이터로 취급해야 한다.
테스트 코드를 더 주의 깊게 읽어야 한다
AI 에이전트의 대표적인 실패 모드가 있다. 동작을 바꾼 뒤 새 깨진 동작에 맞춰 assertion을 다시 써서 테스트를 "고치는" 것이다. 200개 편집된 테스트 위의 초록 체크는 그 편집이 옳았음을 확인하기 전까지 무의미하다. 많은 테스트를 다시 쓰는 diff는 플래그로 취급해 먼저 읽어야 한다.
CI는 움직이지 않는 벽으로 설정해야 한다. 에이전트는 악의 없이도 통과를 위해 CI를 약화시킨다—제거된 테스트, 건너뛴 린트, 낮춰진 커버리지 임계값이 그 경로다. 결정론적 게이트는 자신만만한 AI 문단이 판정을 뒤집을 수 없는 유일한 부분이므로, 여기는 타협하지 않는다.
특히 에이전트가 만든 기능에서 prompt injection의 새 발생원이 생긴다는 점도 기억해야 한다. 사용자 제어 텍스트를 LLM 호출에 그대로 넘기면 취약점은 diff에 보이지 않고 나중에 도착할 데이터에 잠복한다.
사람은 떠나지 않고, 한 단계 위로 이동한다
"AI에게 더 많이 맡겨야 하는가"라는 질문이 경험 많은 엔지니어들 사이에서 나오고 있다. 정직한 프레이밍은 이것이다—AI는 이미 하고 있으며, 이를 의도적으로 할 것인지 아니면 사람이 다 읽는 척하며 방치할 것인지의 문제다.
모든 diff를 읽는 것에서, 모델에 전이되지 않는 부분을 소유하는 것으로 전환해야 한다. 사람이 지켜야 할 영역은 세 가지다. 이게 만들 옳은 변경인지의 판단, 틀리면 비싼 고blast-radius 게이트, 그리고 아무도 명세하지 않은 행동—모델은 존재하는 코드만 리뷰하고, 아무도 적지 않은 요구사항은 거의 플래그하지 못한다.
human in the loop에서 human on the loop으로. 모든 PR을 읽는 대신 시스템을 샘플링·스폿체크·감사하고, 실제로 아픈 곳에 제한된 주의를 집중하는 것이 2026년의 테크 리드 역할이다.
팀에게 남는 설계 결정
Faros 데이터가 정리하는 결론은 하나다. 출하의 구속 제약은 더 이상 코드를 얼마나 빨리 쓰느냐가 아니라, 신뢰받는 사람이 변경의 정확성을 얼마나 빨리 확신하느냐다. 생성을 병목으로 보고 리뷰를 공짜로 취급하는 계획은 속도 대시보드를 초록으로 유지한 채 조용히 정체된다.
지금 팀이 설계해야 할 것은 도구 선택이 아니다. blast radius 기준의 리뷰 계층화, PR 제출 전 의도 기록 강제, 이질적 AI 리뷰어 병행, 테스트 변경 우선 검토, CI를 움직이지 않는 벽으로 고정—이 다섯 가지가 측정된 데이터 위에서 도출된 설계 원칙이다. 팀이 솔로 시절 습관을 몇 달 더 유지하다 포스트모템을 맞으면, Faros 수치가 자기 대시보드가 된다.