코드 리뷰에 무슨 일이 일어나고 있는가?

https://newsletter.pragmaticengineer.com/p/what-is-happening-with-code-reviews

2026년에는 AI가 개발자들이 따라갈 수 없을 만큼 많은 코드를 생성합니다. 그렇다면 코드 리뷰 절차는 여기에 맞춰 바뀌어야 할까요, 아니면 사라질 운명일까요? 수십 년 동안 이어져 온 이 관행과 이를 대체할 수 있는 접근 방식들을 살펴봅니다

제가 이야기를 나눠 온 CTO와 엔지니어링 책임자들의 머릿속을 떠나지 않는 질문이 하나 있습니다. 많은 테크 기업에서 AI 에이전트가 코드 대부분을 생성하게 된 지금, 계속 늘어나기만 하는 방대한 양의 코드 리뷰를 어떻게 처리해야 하느냐는 것입니다.

2025년 말부터 스타트업과 빅테크에서는 개발자가 손으로 코드를 작성하던 시대가 끝난 것처럼 보입니다. AI 에이전트는 개발자가 하던 것보다 빠르게 작업하면서 훨씬 많은 풀 리퀘스트(PR)를 만들어 내고, 그 풀 리퀘스트의 크기도 함께 커지고 있습니다.

이번 글에서는 이 새로운 국면에서 여러 일터가 코드 리뷰에 접근하는 방식들을 정리했습니다. 다루는 내용은 다음과 같습니다.

1. 사람이 AI의 코드 리뷰를 검토합니다. 가장 널리 쓰이는 방식입니다. AI 코드 리뷰 도구가 코드 변경 사항을 훑고, 개발자는 그 리뷰 자체를 검토합니다.
2. 영향 범위(blast radius)로 분류한 뒤 방식을 정합니다. 위험도가 낮은 변경은 사람이 리뷰하지 않고, 위험도가 높은 변경만 사람이 리뷰합니다. OpenAI와 Anthropic 등이 이 방식을 택했습니다.
3. 구현 대신 계획과 테스트, 데이터베이스 스키마를 리뷰합니다. 구현 자체를 보는 대신, 구현 이전과 이후의 상태를 리뷰하는 데 집중합니다.
4. 코드를 더 적게 만듭니다. 리뷰하기 쉽고 이해하기도 쉬운 작은 PR을 만들도록 AI 에이전트를 설정합니다.
5. 전부 사람이 직접 리뷰합니다. 모든 조직이 AI 코드 리뷰 도구를 도입한 것은 아닙니다. 도입한 곳에서도 새로 작성된 코드를 개발자가 전부 읽어 본 뒤에야 프로덕션에 올리도록 요구하는 경우가 있습니다.
6. 사람의 코드 리뷰를 아예 없앨 수 있을까요? 지금까지는 사람의 코드 리뷰를 없애자는 이야기가, 실제로 그렇게 하고 있다는 증거보다 훨씬 많습니다. 제가 찾아낸 사례는 AI 스타트업들이 이 방식을 쓰면서 프로덕션 배포를 더 안전하게 만드는 장치를 따로 쌓아 두는 정도가 전부였습니다.
7. 애초에 우리는 왜 코드를 리뷰할까요? 코드 리뷰를 계속 유지해야 할지 판단하기 전에, 코드 리뷰가 존재하는 근본적인 이유를 기술과 팀, 조직의 측면에서 다시 짚어 볼 필요가 있습니다.

예상할 수 있듯이, AI가 만들어 낸 코드 리뷰가 밀려드는 상황을 어떻게 처리할지에 대해 모두에게 들어맞는 해법은 없다는 점이 분명합니다. 여러분의 팀이나 회사가 이 새롭고 시급한 문제를 어떻게 다루고 있는지 아래에 댓글로 남겨 주시면 좋겠습니다!

AI 개발이 이 단계에 이른 지금 코드 리뷰에서 무슨 일이 벌어지고 있는지는, 아래에 실은 GitHub의 그래프에서 한눈에 확인할 수 있습니다. 이 그래프가 알려 주는 배경은 상당히 극적입니다. 이 인기 있는 플랫폼에서 3년 동안 PR과 커밋의 수가 어떻게 변해 왔는지를 담고 있습니다.

3년 동안 PR과 커밋, 새 저장소의 수가 어떻게 변했는지 보여 줍니다. 출처: GitHub

이 기간에 새로 열린 PR의 수는 다섯 배로 늘었습니다. 엄청난 증가입니다! 게다가 2025년 말부터는 증가 속도가 더 빨라져서, 그 기간에만 PR과 커밋이 거의 두 배가 되었습니다! 그렇다면 팀들은 이렇게 쏟아지는 추가 업무를 어떻게 처리하고 있을까요? 더 알아보기 위해 여러 사람에게 물어보았습니다.

1. 사람이 AI의 코드 리뷰를 검토합니다

가장 흔한 방식은 모든 풀 리퀘스트에 AI 코드 리뷰 단계를 끼워 넣는 것이며, 그 방법은 여러 가지입니다.

• 한 곳 이상의 업체에 PR 리뷰를 맡깁니다. 이 기능을 제공하는 업체는 수십 곳에 이릅니다. CodeRabbit, Gitar, Greptile, GitHub Copilot Code Review, Qodo, Claude Code Review, Ellipsis 등이 있습니다. 많은 팀이 이 가운데 하나 이상을 골라 쓰는데, 그러면 봇이 PR을 검토하고 개발자가 볼 수 있도록 코멘트를 남깁니다. 예를 들어 Anthropic이 진행하는 Bun 프로젝트에서는 CodeRabbit과 GitHub Code Review, Claude Code Review가 모두 PR에 코멘트를 남기고 있습니다.
• 여러 에이전트가 함께 코드 리뷰를 합니다. 여러 모델이나 에이전트가 코드를 검토하고 수정안을 제안하도록, 직접 만든 도구를 사용합니다.
• 에이전트가 수정 사항을 PR에 반영합니다. 외부 업체의 도구든 직접 만든 도구든, 에이전트에게 수정 내용을 PR에 반영하게 하고 리뷰를 다시 돌리도록 지시할 수 있습니다. 물론 에이전트가 합리적으로 수정할 것이라고 믿을 수 있어야 가능한 이야기입니다!

흔히 쓰이는 절차는 다음과 같습니다.

AI 코드 리뷰가 개발 주기의 일부로 점점 더 자리를 잡고 있습니다

위와 같은 경우에 엔지니어는 보통 코드가 아니라 리뷰 자체를 검토합니다. AI 데이터베이스 소프트웨어를 만드는 Weaviate의 공동 창업자이자 CTO인 Etienne Dilocker는 자신들의 방식이 마음에 드는 이유를 이렇게 설명합니다.

"에이전트가 [코드 리뷰의] 균형을 제대로 잡기란 매우 어렵습니다. 사람의 코드 리뷰를 완전히 빼고 에이전트에게만 맡기면, 모든 PR이 작업 범위가 계속 불어나는 문제를 겪거나 치명적인 문제를 그대로 내보내게 됩니다. 물론 그렇다고 전부 사람이 직접 검토할 수도 없습니다. 그래서 지금 제가 가장 마음에 들어 하는 구성은 이렇습니다.

1. (일부러 반대 입장을 취하는) 에이전트가 리뷰를 합니다.

2. 사람이 작업 범위를 결정합니다.

3. 에이전트가 피드백을 반영해 구현합니다.

4. 이 과정을 반복하거나 여기서 멈춥니다. 멈추는 판단은 사람이 하게 될 가능성이 큽니다.

정리하면 90퍼센트는 에이전트에게 맡기고, 중요한 범위 결정과 종료 기준을 판단할 때에만 사람이 개입하는 방식입니다."

AI 코드 리뷰에서는 잡음이 큰 문제입니다. 시리즈 C 단계의 여행 테크 기업 WeTravel은 AI가 만들어 내는 잡음이 너무 많아서, 코드 리뷰에 AI를 쓰지 않기로 결정했습니다. 6월에 다시 평가해 보니 많이 나아지기는 했지만, 그래도 이 업무에 AI를 도입할 만한 수준에는 이르지 못했습니다.

현재로서는 코드 리뷰의 잡음을 줄이려면 직접 만든 도구가 필요해 보입니다. Uber는 이를 위해 영리한 방법을 만들었는데, uReview라는 에이전트 파이프라인입니다.

uReview가 하는 일은 다음과 같습니다.

• 봇들이 코드 리뷰 코멘트를 대량으로 만들어 냅니다.
• 코멘트마다 점수를 매기고, 신뢰도가 낮은 코멘트를 걸러 냅니다.
• 남은 코멘트를 합치고 분류한 뒤, 중요하지 않은 것을 다시 제거합니다.
• 그 결과 AI 리뷰는 최종적으로 중요한 코멘트만 개발자에게 보여 줍니다.

2. 영향 범위로 분류한 뒤 방식을 고릅니다

또 하나 흔한 방식은 변경이 얼마나 위험한지에 따라, 사람이 직접 리뷰할지 AI에게 맡길지 정하는 것입니다.

• 위험도가 낮은 변경: 사람의 리뷰 없이 AI만 검토합니다. AI 에이전트가 문제없다고 판단하면 바로 프로덕션에 올릴 수 있습니다.
• 위험도가 높은 변경: 사람의 리뷰를 반드시 거칩니다.

Anthropic과 OpenAI가 이 방식을 따르고 있으며, 저는 두 회사와 직접 이야기를 나누어 이 사실을 확인했습니다. Anthropic의 Jarred Sumner는 위험도가 낮은 변경도 사람이 병합하고 있지만, 결국에는 또 다른 Claude 인스턴스가 위험도 낮은 변경을 병합하게 만드는 것이 목표라고 말해 주었습니다.

이런 흐름은 앞서가는 AI 연구소에만 국한되지 않습니다. 클라우드와 AI 컴퓨팅 자원, 계약을 관리해 주는 15인 규모의 스타트업 Duckbill도 절차를 바꾸었는데, 공동 창업자이자 CEO인 Mike Julian이 이렇게 설명했습니다.

"우리는 Duckbill Group에서 코드 리뷰를 (거의) 없앴습니다.

한 달쯤 전에, 다섯 명인 팀에 열려 있는 PR이 60개나 쌓여 있다는 사실을 발견했습니다. 몇 주에 걸쳐 밀려 있던 것이었고, 코드 리뷰만 하는 데 이틀이 걸리는 상황이라는 것을 우리 모두 그때 문득 깨달았습니다.

저는 코드 리뷰를 전부 AI에게 맡기는 방안을 한동안 생각해 오던 참이라, 팀에 이렇게 물었습니다. 우리가 PR을 아예 리뷰하지 않는다면 어떨까요?

그래서 두 가지를 하기로 했습니다.

• 위험도를 기준으로 삼는 체계로 바꾸었습니다. 이 체계에서는 공개 API나 MCP, 인증, 디자인 시스템, 단순 추가가 아닌 데이터베이스 스키마 변경, 에이전트 스킬을 건드리는 변경이라면 사람의 리뷰를 받도록 합의했습니다. 그리고 셸 스크립트로 GitHub 레이블을 붙여서 이 규칙을 강제했습니다.
• 안전장치를 강화했습니다. 단위 테스트와 E2E 테스트, 배포 이후의 관측 가능성, 더 엄격한 린팅과 타입 검사 등이 여기에 해당합니다. 안전장치를 강화하는 일 자체는 꽤 쉬웠고, 토큰과 주의력이 많이 들었을 뿐입니다. ruff와 prettier, eslint, ty의 규칙을 거의 전부 켰고, 단위 테스트 커버리지를 최소 85퍼센트까지 끌어올렸습니다.

적용 전과 후의 결과는 이렇습니다.

• 병합된 PR: 353개 → 684개 (주당 80개 → 154개, 94퍼센트 증가)
• 1시간 안에 병합된 비율: 28퍼센트 → 45퍼센트, 24시간 안에 병합된 비율: 76퍼센트 → 80퍼센트
• 사람이 리뷰한 PR의 병합 시간 중간값: 26시간
• 사람이 리뷰하지 않은 PR의 병합 시간 중간값: 1시간"

이 방식을 그림으로 나타내면 다음과 같습니다.

영향 범위에 따라 코드 리뷰 방식을 고릅니다

어떤 회사들은 개발자가 어느 리뷰에 집중해야 하는지 쉽게 알 수 있도록 별도의 도구를 만들었습니다. 예를 들어 Uber가 직접 만든 Code Review Inbox는 영향이 큰 변경을 눈에 띄게 표시해 주기 때문에, 개발자는 그런 변경에 시간과 노력을 더 들여야 한다는 것을 알 수 있습니다.

영향이 큰 변경을 따로 구분해 주는 방향으로 코드 리뷰 도구가 발전하고 있습니다. 출처: Uber가 개발에 AI를 활용하는 방법

3. 구현 대신 계획과 테스트, 데이터베이스 스키마를 리뷰합니다

일부 개발자와 팀은 코드, 즉 구현을 리뷰하는 일을 그만두고, 대신 작업 이전과 이후의 상태를 리뷰합니다.

계획을 리뷰합니다. 예전보다 훨씬 많은 시간을 계획에 들여서, 한층 상세한 명세를 만들어 냅니다. Matt Pocock이 만든 /grill-me 스킬을 쓰는 방법이 널리 쓰이고 있으며, 저도 사전 계획을 꼼꼼하게 세우는 용도로 이 방법을 좋아합니다. Musixmatch의 프린시펄 엔지니어인 Andrea Francesco Speziale 역시 마찬가지입니다.

"/grill-me에 세 시간을 썼으니, 구현은 한 번에 제대로 나와 줘야 합니다. 저는 리뷰에 단 1분도 쓰지 않을 겁니다!"

테스트를 리뷰합니다. 테스트 주도 개발(TDD)로 진행하는 방법이 있습니다. 테스트를 미리 작성하는 일이 번거롭게 느껴질 때, 에이전트를 함께 쓰면 이 과정이 훨씬 수월해집니다. 아니면 소프트웨어가 제대로 테스트되었는지 확인하는 데 리뷰의 초점을 맞추는 방법도 있습니다.

이 방식을 옹호하는 근거 하나는, 소프트웨어를 구매하는 고객과 사용하는 사용자는 대개 코드에 관심이 없다는 점입니다. 다만 한 가지 유의할 점이 있습니다. 자동화된 테스트는 여러 종류의 소프트웨어를 검증할 수 있고 비즈니스 로직을 검증하는 데는 특히 뛰어나지만, UI가 보기에 좋은지, 쓰는 느낌이 좋은지는 제대로 검증하지 못합니다.

데이터베이스 스키마를 리뷰합니다. AI 스타트업 Sigil의 공동 창업자이자 CEO이고 예전에 Square에서 엔지니어로 일했던 Jackie Luo는 이렇게 말합니다.

"제 현재 생각은, 정말 중요한 것은 데이터베이스 스키마뿐이라는 것입니다. 빠르게 움직이는 스타트업의 관점에서 말씀드리면 이렇습니다.

1. 데이터를 제외한 나머지는 모두 유동적이고 되돌릴 수도 있습니다.

2. 스키마는 지금까지 만들어 온 것이 굳어진 형태로 드러난 결과이고 가장 위험한 변경이 무엇인지 알려 주기 때문에, 들이는 주의와 얻는 효과를 견주어 보면 리뷰할 가치가 큽니다.

3. 비즈니스 로직이 중요한 이유는 제품이 어떻게 동작하는지가 중요하기 때문입니다. 그러니 코딩 에이전트를 쓰기 시작하기 전에 제품의 동작에 관해 미리 합의해 두는 것이 가장 좋습니다. 그리고 코드가 작성된 뒤에는, 추상화를 활용해 그 과정에서 내려진 다른 중요한 결정들을 파악하면 됩니다.

코드보다 제품을 이해하십시오. 추상화를 활용해 코드를 제품의 언어로 옮기면 됩니다. 스키마만은 예외입니다!"

Jackie가 지적하는 요점은, 어떤 시스템에서든 데이터, 즉 상태가 가장 단단하게 굳어 있어서 바꾸기 어려운 부분이라는 것입니다. 상태를 갖지 않는 비즈니스 로직은 이제 바꾸기가 쉬운데, 그것이 '그저' 코드일 뿐이고 코드는 생성하고 다시 생성하기가 쉽고 빠르기 때문입니다. 스타트업이라면 데이터 스키마를, 그리하여 자신의 상태 기계를 제대로 설계해 두는 편이 좋습니다. 그렇게 해 두면 나머지는 모두 쉽고 빠르게 개선해 나갈 수 있습니다.

제가 보기에 이 방식은 제품과 시장의 적합성(product-market fit)을 찾으려고 계속 시도하는 스타트업에게는 아주 잘 맞습니다. 다만 사업이 자리를 잡은 뒤에는 비즈니스 로직을 테스트로 지키고 싶어질 것입니다. 그러지 않으면 제품이 망가질 수 있고, 그런 일이 생기면 기존 사용자들이 불만을 품게 됩니다!