AI는 10배 빠르게 코드를 짠다. 팀은 1배 속도로 리뷰한다. 이제 어떻게 할 것인가?

아무도 리뷰하고 싶지 않은 1만 줄짜리 PR

내가 아는 한 개발자가 최근 스크린샷을 공유했다. 추가된 코드만 1만 줄이 넘는 PR이었다. 그걸 본 모든 사람의 반응은 같았다 — 경악 반, 체념 반. "이걸 어떻게 리뷰하라는 거지?"

팀의 솔직한 대답은 이랬다. "직접 만나서 같이 보거나, 아니면 아예 안 봐요."

이건 하나의 나쁜 PR 이야기가 아니다. 새로운 일상이다. AI 코딩 에이전트 — Claude Code, Codex, Cursor, Copilot — 는 기존의 리뷰 워크플로를 소방 호스로 물 마시기처럼 느끼게 만드는 속도로 코드를 만든다. 소프트웨어 개발의 병목이 이동했다. 더 이상 코드 작성이 아니다. 코드가 작성된 이후 일어나는 모든 것이다.

속도 불균형 문제

워크플로를 망가뜨리는 수치가 있다.

CodeRabbit 연구에 따르면, AI가 작성한 PR은 PR당 평균 10.83건의 문제를 일으키는 반면, 사람이 작성한 것은 6.45건이다. 논리 오류와 정확성 오류는 75% 더 많다. 별도 연구에서 시니어 엔지니어들은 AI가 만든 제안을 리뷰하는 데 평균 4.3분을 쓰는 반면, 사람이 쓴 코드는 1.2분에 그쳤다.

실무에서 이것이 무엇을 의미하는지 생각해보라. AI는 코드를 더 많이 만들고, 그 코드는 문제가 더 많으며, 각 문제를 평가하는 데는 더 오래 걸린다. 한편, CircleCI의 2,800만 건 CI 워크플로 분석을 보면 팀들이 이전보다 훨씬 많은 코드를 만들면서도 프로덕션에 실제로 도달하는 코드는 오히려 줄었다. 파이프라인이 막혔고, 코드 리뷰가 그 원인이다.

LogRocket이 지적했듯, 이제 배포의 병목은 코드 생성이 아닌 코드 리뷰다.

기존 리뷰 방식이 확장될 수 없는 이유

기존 코드 리뷰는 개발자가 하루에 의미 있는 코드를 100~300줄 작성하는 세계를 위해 설계됐다. 그 세계에서 동료의 200줄짜리 PR을 리뷰하는 건 15분짜리 작업이다. 코드베이스를 알고, 개발자의 패턴을 알고, 의도를 추론할 수 있다.

AI가 만든 PR은 이 가정들을 모두 무너뜨린다.

볼륨. 어떤 기능을 작업하는 AI 에이전트는 한 세션에서 수백 개의 파일을 건드릴 수 있다. 꼭 필요해서가 아니라, "이 참에 이것도 고치자"를 기본 동작으로 삼기 때문이다. 사람이라면 3~4개 파일에 걸쳐 구현할 기능이 50개 파일짜리 PR이 된다.

추적 가능성. 사람이 코드를 짜면 리뷰어는 변경 사항에서 의도를 추론할 수 있다. AI가 만든 코드는 이런 가독성이 떨어지는 경우가 많다. 이 함수를 왜 재구성했는가? 기능에 필요해서인가, 아니면 에이전트가 스스로 "개선"하려 한 것인가? 아키텍처 계획은 리뷰할 수 있지만, 만들어진 코드가 그 계획을 충실하게 구현하는지는 한 줄 한 줄 읽지 않고는 확인할 방법이 없다.

중복. AI 에이전트는 중복 코드를 만들기로 악명 높다. 한 파일에서 유틸리티 함수를 만들면서 다른 곳에 거의 동일한 것이 이미 있다는 걸 모른다. Claude Code 자체 코드베이스 분석에서 상당량의 중복 코드가 발견됐다는 보고도 있다. 코드베이스를 전체적으로 이해하지 못한 작성자의 흔적이 그대로 드러난다.

자신감. 코드가 맞아 보인다. 관례를 따르고, 적절한 변수 이름을 쓰고, 주석도 달려있다. 하지만 맞아 보인다는 것과 실제로 맞다는 것은 다르다. AI가 만든 코드는 표면적 리뷰를 통과하면서 엣지 케이스에서만 드러나는 미묘한 논리 오류를 감출 수 있다. 이런 거짓 안도감은 명백히 나쁜 코드보다 오히려 더 위험하다.

부상하는 세 가지 전략

팀들은 이 문제에 대해 세 가지 뚜렷한 접근 방식으로 수렴하고 있다. 대부분의 조직은 결국 세 가지를 모두 조합하게 되겠지만, 그 비율은 리스크 허용도와 인프라 성숙도에 따라 달라진다.

전략 1: 하네스 엔지니어링 — 나쁜 코드가 만들어지기 전에 막는다

지금 개발자 툴링에서 가장 뜨거운 용어는 "하네스 엔지니어링(harness engineering)"이다. 실수를 사후에 잡는 것이 아니라, 에이전트가 출력물을 만들기 전에 제약을 설계하는 규율이다.

Martin Fowler 팀의 설명에 따르면, 하네스는 에이전트가 운영되는 방식을 규율하는 완전한 인프라다. 에이전트가 접근할 수 있는 도구, 안전하게 유지하는 가드레일, 자가 교정을 돕는 피드백 루프, 사람이 동작을 모니터링하는 관찰 레이어.

실제로는 이런 모습이다.

• 프로젝트 관례, 아키텍처 경계, 금지된 패턴을 저장소에 직접 담는 CLAUDE.md / AGENTS.md 파일. AI는 코드를 짜기 전에 이 규칙들을 읽는다.
• 위반 사항을 제안이 아닌 강제 차단으로 자동 감지하는 프리커밋 훅과 린터.
• 에이전트가 계획을 작성하고, 승인을 받고, 각 단계에서 자동 점검과 함께 실행해야 하는 구조화된 워크플로.
• 각 에이전트 세션이 별도 브랜치에서 운영돼 동시 실행 중인 에이전트들이 충돌하지 않도록 하는 워크트리 격리.

OpenAI의 Codex 하네스 엔지니어링 가이드는 더 나은 모델일수록 하네스 엔지니어링이 덜 중요한 것이 아니라 더 중요해진다고 강조한다. 더 유능한 에이전트는 더 많은 자율성을 얻고, 더 많은 자율성은 더 나은 가드레일을 요구한다.

철학은 선제적이다. 에이전트가 나쁜 출력물을 만들면, 그 출력물만 고치는 것이 아니라 그런 일이 다시 일어나지 않도록 하네스를 고친다.

전략 2: 롤백 친화적 인프라 — 실패를 수용하고, 빠르게 복구한다

두 번째 전략은 철학적으로 반대 입장을 취한다. 나쁜 코드가 모두 배포되는 것을 막는 대신, 나쁜 배포를 되돌리는 것을 쉽게 만드는 것이다.

이 접근 방식은 다음을 요구한다.

• 새 기능을 게이팅하고 문제가 발생하면 즉시 끌 수 있는 기능 플래그.
• 폭발 반경을 제한하는 블루-그린 또는 카나리 배포.
• 오류율 급등이나 성능 저하를 감지하는 자동 롤백 트리거.
• 리뷰에서 잡지 못했더라도 문제가 발생했을 때 알 수 있는 포괄적인 관찰 가능성.

이 전략을 따르는 팀은 본질적으로 "우리는 테스트와 모니터링을 사람의 대규모 리뷰보다 더 신뢰한다"고 말하는 것이다. 잘 계측된 프로덕션 환경이 5,000줄짜리 diff를 훑어보는 사람보다 더 많은 실제 버그를 잡는다는 데 베팅하는 것이다.

이것은 무모한 게 아니다. 몇 년 전 지속적 배포 도입을 이끈 것과 같은 철학이다. 하지만 많은 팀이 아직 갖추지 못한 성숙한 인프라를 요구한다.

전략 3: 정책 기반 리뷰 — 무엇을 리뷰할지 재정의한다

가장 실용적이면서도 논쟁적인 접근 방식이다. 팀이 합의하는 리뷰 대상 자체를 바꾸는 것이다.

일부 팀은 특정 범주의 AI 생성 변경 사항에 기존 리뷰가 불필요하다고 명시적으로 결정하고 있다.

• 자동 포맷팅과 스타일 변경 — 린터를 믿는다.
• 테스트 추가 — CI를 통과하면 배포한다.
• 의존성 업데이트 — 자동화 도구가 이미 처리한다.
• 보일러플레이트와 스캐폴딩 — AI가 템플릿을 따르고, 템플릿은 이미 리뷰됐다.

리뷰 노력은 사람이 실제로 잘 평가할 수 있는 것에 집중된다. 아키텍처 결정, 보안 경계, 비즈니스 로직 정확성, API 계약 변경.

이건 팀의 합의가 필요하다. 한 개발자의 말대로 "정책 문제예요. 팀이 특정 변경 사항을 리뷰하지 않기로 합의하면 해결 가능합니다." 하지만 그 합의를 이끌어내고 — 경계를 정확히 정의하는 것은 들리는 것보다 훨씬 어렵다.

툴링의 반응

툴링 생태계는 이 격차를 메우기 위해 분주히 움직이고 있다. 2026년 3월에 출시된 JetBrains Air는 여러 AI 에이전트(Codex, Claude, Gemini CLI, Junie)가 내장된 워크트리 관리 및 리뷰 워크플로와 함께 독립적인 태스크 루프를 실행할 수 있는 "에이전틱 개발 환경"으로 자리매김한다. 핵심 제안은 IDE가 에이전트 오케스트레이션을 관리하면 리뷰 표면도 관리할 수 있다는 것이다.

CodeRabbit, Greptile, GitHub의 Copilot 기반 리뷰 같은 AI 기반 코드 리뷰 툴들은 AI가 만든 코드를 AI로 리뷰하려 한다. Atlassian은 AI 리뷰어 덕분에 PR 처리 속도가 30.8% 빨라졌다고 보고했지만, 속도는 품질과 다르다. 이 툴들은 린터가 잡는 것과 같은 표면적 문제를 잡는 데는 능숙하지만, 리뷰를 가치 있게 만드는 더 깊은 판단적 결정들을 처리하는 데는 부족하다.

근본적인 아이러니가 있다. 우리는 AI가 만든 문제를 해결하기 위해 AI를 사용하고 있다.

테스트 문제

이 모든 것 한켠에는 테스트에 관한 똑같이 중요한 물음이 있다. AI가 코드와 테스트를 모두 짤 때, 테스트가 실제로 어떤 신뢰를 제공하는가?

내가 이야기해본 팀들 사이에서 나타나는 합의는 놀라울 정도로 최소주의적이다.

• 상태가 있는 로직(리듀서, 상태 머신, 복잡한 유틸리티)에 대한 단위 테스트 — 항상 필요.
• 간단한 컴포넌트나 단순한 함수에 대한 단위 테스트 — 종종 생략.
• E2E 테스트 — 거의 작성하지 않고, 작성하더라도 주로 핵심 사용자 경로에 한정.
• 실제 데이터베이스를 사용하는 통합 테스트 — 목(mock)이 실제 실패를 감출 수 있어 목 테스트보다 선호.

이유는 이렇다. AI가 구현과 테스트를 모두 짰다면, 테스트는 아마도 구현과 같은 가정(그리고 같은 버그)을 담고 있을 것이다. 테스트는 같은 시스템이 코드에 도장 찍는 것이 아닌, 사람의 올바른 동작에 대한 이해를 담을 때 가장 가치 있다.

개인 대 공유 툴링 논쟁

AI 코딩 툴을 도입하는 팀에서 또 다른 긴장이 펼쳐지고 있다. AI 설정을 공유해야 하는가, 개인이 가져야 하는가?

한쪽에서는 표준화를 밀어붙인다. 저장소의 공유 CLAUDE.md 또는 AGENTS.md는 모든 팀원의 AI가 같은 관례를 따르게 한다. 공유된 스킬과 에이전트 설정은 중복 노력을 줄이고 일관성을 보장한다.

반대쪽에서는 많은 개발자들이 이에 저항한다. 한 시니어 엔지니어의 말이다. "팀이 공유 설정을 발행해도 저는 지우고 제 것을 씁니다." 이유는 단순한 반항이 아니다. 각 개발자는 다른 워크플로를 갖고 있고, AI가 보완해줬으면 하는 강점과 커버해줬으면 하는 약점이 다르다.

등장하고 있는 계층적 접근 방식이 실용적으로 보인다. 저장소에 공유 프로젝트 수준 관례(코드베이스가 요구하는 것), 각 머신에 개인 사용자 수준 선호(각 개발자가 일하는 방식), 보안과 컴플라이언스를 위한 조직 정책. 공유하면 안 되는 것은 워크플로다 — 단계의 순서, 자율성 수준, 리뷰 선호도. 이것들은 개인적이며, 표준화를 강요하면 모두가 자신에게 최적화된 것 대신 평범한 설정을 갖게 되는 경우가 많다.

지금 실제로 작동하는 것들

이 문제를 광범위하게 조사하고 실제 팀들이 헤쳐나가는 것을 관찰한 후, 오늘날 효과가 있다고 생각하는 것들이다.

PR을 작게 유지하라. 이것은 변하지 않았다. 거대한 PR을 만드는 것과 같은 AI 툴들을 더 작은 단위로 작업하도록 설정할 수 있다. 기능을 기능 브랜치에 대한 서브 PR로 분리하라. 작은 변경을 강제하는 툴들(Graphite 같은)이 인기 있는 데는 이유가 있다.

리뷰 툴보다 하네스에 먼저 투자하라. 코드가 만들어진 후 리뷰하는 것보다 처음부터 나쁜 코드가 만들어지지 않도록 막는 게 저렴하다. 아키텍처 경계, 금지된 패턴, 테스트 요구 사항이 잘 작성된 CLAUDE.md는 어떤 AI 리뷰 툴보다 더 많은 것을 한다.

어떻게 리뷰하든 롤백 기능을 구축하라. 철저하게 리뷰하든 않든, 되돌릴 능력이 필요하다. 기능 플래그와 카나리 배포는 더 이상 선택 사항이 아니다. 기본 전제다.

리뷰를 건너뛰지 말고 — 무엇을 리뷰할지 바꿔라. 사람의 리뷰는 의도, 아키텍처, 보안에 집중해야 한다. 스타일, 포맷팅, 기본적인 정확성은 자동화 툴이 처리하게 하라. 이것은 기준을 낮추는 것이 아니다 — 사람의 주의를 실제로 중요한 곳으로 이동시키는 것이다.

개인이 자신의 워크플로를 설정하게 하라. 관례를 공유하되, 워크플로는 공유하지 마라. 전체 계획 모드 리뷰를 원하는 개발자와 자율적 실행을 원하는 개발자 모두 완전히 다른 방식으로 일하면서도 같은 아키텍처 규칙을 따를 수 있다.

더 깊은 물음

이 상황 전체에서 불편한 무언가가 있다. 우리는 더 빠르게 만들기 위해 AI 툴을 만들었고, AI 툴이 처음 한 일은 우리가 한 번도 수치화하지 않았던 사람의 대역폭에 의해 지탱되던 프로세스들을 드러내는 것이었다.

코드 리뷰는 리뷰 부하가 감당 가능할 때 작동했다. 테스트 전략은 사람이 도메인 이해를 바탕으로 테스트를 작성할 때 작동했다. 아키텍처 결정은 코드를 짠 사람이 시스템을 이해할 때 작동했다.

AI는 작성 속도라는 제약을 제거했고, 진짜 제약이 항상 이해, 판단, 신뢰였다는 것을 드러냈다. 이것들은 더 빠른 모델이나 더 큰 컨텍스트 윈도우로는 확장되지 않는다.

이 상황을 잘 헤쳐나가는 팀은 가장 좋은 AI 툴을 가진 팀이 아닐 것이다. 프로세스의 어느 부분이 사람의 판단을 요구하고 어느 부분이 그렇지 않은지를 솔직하게 평가한 다음 — 그 평가에 맞는 인프라를 구축하는 팀일 것이다.

1만 줄짜리 PR이 문제가 아니다. 그것은 증상이다. 문제는 우리가 그 출력물을 처리하는 시스템을 업그레이드하지 않고 출력 속도를 최적화했다는 것이다. 그리고 그건 AI의 문제가 아닌 사람의 엔지니어링 문제다.