에이전트 기반 코드 리뷰
TMT에이전트 덕분에 ‘코드를 쓰는 일’은 거의 공짜가 되었습니다. 하지만 ‘코드를 이해하는 일’에 드는 비용은 예전과 똑같습니다. 그래서 지금은 코드 리뷰가 전체 흐름의 병목이 되었습니다. 2026년 데이터는 이 점에서 놀라울 정도로 일관된 모습을 보여줍니다. 그럼에도 현재 떠도는 AI 코드 리뷰 관련 조언 대부분은 대부분의 사람에게 잘못된 방향을 제시합니다. 사용자도 없는 1인 개발자와 10년 된 애플리케이션을 유지보수하는 팀이 맞닥뜨린 문제는 전혀 다르고, 이 둘에게 같은 해법을 적용할 수는 없기 때문입니다.
올해 제 업무 방식에서 가장 크게 바뀐 점은 “에이전트가 제 코드를 대부분 대신 써준다”는 사실이 아닙니다. “그 코드들을 리뷰하는 일이 제가 하는 일 중 가장 비싼 일이 되었다”는 점입니다. 그리고 이 변화가 무엇을 뜻하는지, 우리가 집단적으로 아직 충분히 받아들이지 못하고 있다고 생각합니다.
예전의 코드 리뷰가 잘 작동했던 건, 우연에 가까운 속도 차 덕분이었습니다. 시니어 엔지니어는 주니어가 코드를 작성하는 속도보다 빠르게 코드를 읽을 수 있었고, 그래서 별도의 설계를 하지 않아도 리뷰는 자연스럽게 속도를 맞출 수 있었습니다. 팀원들은 서로의 diff를 읽는 과정에서 시스템이 어떻게 맞물려 돌아가는지 함께 이해하게 되었고, 이 역시 리뷰의 부산물로 따라온 효과였습니다. 이 모든 것은 의도적으로 설계된 결과가 아니었습니다. “코드를 쓰는 일은 느리고 비싸고, 읽는 일은 빠르고 싸다”는 단 하나의 사실에서 자연스럽게 흘러나온 결과였습니다.
그 사실은 더 이상 유효하지 않습니다. 에이전트는 이 문단을 제가 읽는 것보다 훨씬 짧은 시간 안에, 그럴듯하고 포맷도 잘 맞고 대체로는 맞는 코드 수천 줄을 뽑아낼 수 있습니다. “작성” 비용은 거의 0에 수렴했습니다. 인간이 코드를 읽는 속도는 변하지 않았습니다. 원래부터 존재하던 진짜 제약 조건, 즉 “누군가 인간이 실제로 이 변경사항을 이해해야 한다”는 요구가 이제는 파이프라인 전체를 붙들어 세우는 요소가 되었고, 제가 이야기를 나눠 본 대부분의 팀은 이를 아예 모르거나, 알면서도 의도적으로 언급하지 않고 넘어가는 편을 택한 듯 보입니다.
여기서 하나 아이러니를 먼저 짚고 넘어가고 싶습니다. 이 아이러니는 글 전체의 방향을 좌우합니다. 지금의 코드 홍수를 만들어 내는 바로 그 도구들이, 동시에 그 홍수를 감당하는 데 가장 큰 도움을 주는 도구이기도 하다는 점입니다. 제가 맡은 프로젝트들, 특히 인기 있는 오픈소스 프로젝트에서는 이제 Claude Code나 Codex를 PR 큐에 붙여서 한 번에 들어오는 PR 묶음을 분류·정리(triage)하게 하고 있는데, 이 방식은 실제로 제가 시간을 쓰는 방식을 완전히 바꿔 놓았습니다. 그래서 이 글은 AI를 반대하는 논의가 아닙니다. 오히려 AI를 정확히 어떻게 활용하고 있는지로 다시 돌아올 것입니다.
이 글은 데이터만 잔뜩 나열하는 글도 아닙니다. 또, “모델이 코드를 쓰는 게 멋진 일인가, 장인 정신의 종말인가” 같은 낡은 프레이밍을 반복하려는 것도 아닙니다. 이런 식의 논쟁은 실제 코드베이스 앞에서는 아무 힘도 못 씁니다. 진짜 답은 항상 “상황에 따라 다르다”뿐입니다. 소수의 사람만 써보는 사이드 프로젝트를 감으로 찍어가며 만드는 개발자와, 10년 된 결제 시스템을 석 달만 더 버티게 만들려 애쓰는 팀은 공유할 만한 제약 조건이 거의 없습니다. 지금 떠도는 조언 대부분은, 사실상 이 둘 중 한 사람이 다른 쪽에게 “내 방식대로 살아야 한다”고 말하는 것에 불과합니다.
2026년 데이터가 실제로 말해 주는 것
AI가 가져다주는 실제 생산성 향상은 고작 10% 남짓인데, 코드 양은 대략 네 배로 늘어납니다. AI가 추가로 만들어 주는 것의 대부분은 ‘가치’가 아니라, 사람이 리뷰해야 할 코드 뭉치이며, 서로 다른 네 개의 데이터셋이 이 점만큼은 한목소리를 내고 있습니다.
2~3년 동안은 이런 얘기들이 전부 “카더라”에 가까웠습니다. 이제는 전혀 이해관계가 같지 않은 여러 조직이, 심지어 상업적으로는 서로 경쟁 관계에 있는 조직들까지 포함해, 대규모로 측정한 데이터들이 쌓이고 있고, 그 결과는 계속 같은 방향을 가리킵니다. AI는 산출량을 급격히 끌어올리지만, 코드 품질과 리뷰 용이성은 동시에 떨어뜨린다는 것입니다.
Faros AI는 4,000개 팀, 22,000명의 개발자를 계측해, 해당 팀들이 AI를 거의 쓰지 않는 단계에서 적극적으로 도입하는 단계로 옮겨갈 때 무슨 일이 벌어졌는지 추적했습니다. 이건 2026년 3월 데이터로, 여기서 다루는 것 중 가장 최신에 속합니다. 먼저 좋은 소식부터 인정하겠습니다. 개발자들은 훨씬 더 많은 PR을 머지하고 훨씬 더 많은 작업을 마무리하며, 엔지니어 1인당 처리량도 증가했습니다. 그 다음이 이 보고서의 핵심입니다.
- 코드 변동(churn) 861% 증가
- 인시던트 대비 PR 비율 242.7% 증가
- 개발자 1인당 결함률 **9% → 54%**로 상승
- 리뷰 ‘소요 시간’ 중앙값 441.5% 증가, 첫 리뷰까지 걸리는 시간과 평균 리뷰 시간은 둘 다 거의 두 배
- 리뷰 없이 머지된 PR 비율 31.3% 증가
마지막 숫자가 제가 가장 무시하기 힘든 지점입니다. 이 수치는 아무도 “의도적으로” 선택하지 않았습니다. “이제부터 리뷰를 하지 말자”라는 결정이 있었던 게 아닙니다. 단지 리뷰어들이 물량을 감당하지 못했고, 그래서 코드가 읽히지 않은 채 머지되기 시작했고, 그것이 어느새 ‘정상’이 되어 버렸습니다. 제가 계속 곱씹게 되는 디테일은, 성숙하고 규율 잡힌 엔지니어링 문화를 가진 팀들조차 이 충격에서 예외가 아니었다는 점입니다. 훌륭한 프로세스도, 원래 그 프로세스가 처리하도록 설계된 범위를 훨씬 넘어서는 물량 앞에서는 보호막 역할을 하지 못했습니다.
여기서 한 가지는 끝까지 유념해야 합니다. CodeRabbit과 Faros는 둘 다 이 시장에 제품을 파는 회사이므로, 이들이 내세우는 ‘프레이밍’은 이해관계에서 완전히 자유롭지 않습니다. 그렇다고 해서 숫자 자체가 틀렸다는 뜻은 아닙니다. 효과 크기는 크고, 서로 관계없는 출처들 간에도 일관되게 나타납니다. 다만, 벤더가 수행한 연구라면 그 점을 감안하고 읽어야 한다는 의미입니다.
CodeRabbit은 2025년 12월에 오픈소스 PR 470건(이 중 320건은 AI 공동 작성, 150건은 인간 단독 작성)을 분석해, AI가 관여한 변경사항에서 문제가 1.7배 더 많이 발견된다는 결과를 내놓았습니다. 논리·정확성 영역 문제는 약 75% 증가했고, 보안 이슈는 1.5~2배 더 흔하게 나타났으며, 가독성 문제는 세 배 이상 늘어났습니다. 이 회사의 AI 디렉터 David Loker는 이를 “예측 가능하고, 측정 가능한 약점이며, 조직이 적극적으로 완화 전략을 가져가야 한다”고 표현했습니다. 여기서 핵심 단어는 ‘예측 가능하다’는 점입니다. 어떤 부분에서 이런 버그가 나올지 우리는 이미 알고 있습니다. 단지 그 지점을 더 이상 잘 들여다보지 않을 뿐입니다.
GitClear는 제가 이 주제를 이야기할 때 가장 먼저 꺼내고 싶은 숫자를 제공합니다. 2025년까지의 생산성 데이터를 보면, 매일 AI를 사용하는 개발자들은 비(非) 사용자에 비해 원시 코드량이 약 4배 많았습니다. 그러나 같은 개발자들이 일 년 전 자신과 비교했을 때, 실제 생산성 향상은 **대략 12%**에 그칩니다. “네 배의 코드를 생성해, 실질적인 가치 측면에서는 대략 10% 남짓을 더 얻어낼 뿐이고, 그 네 배의 코드를 모두 사람이 리뷰해야 한다”는 뜻입니다. GitClear의 Bill Harding은 이 12% 중 일부조차 사실은 ‘선택 편향’ 때문이라고 명시합니다. 실력이 좋은 개발자들이 AI를 더 적극적으로 쓰는 경향이 있기 때문입니다. “4배의 코드 vs 10% 남짓의 가치”라는 간극은, 코드 리뷰 문제가 한 줄로 응축된 표현입니다.
GitHub에 따르면 Copilot Review는 지금까지 6천만 건이 넘는 리뷰를 수행했으며, 이는 1년 새 약 10배 증가한 수치입니다. 이제 플랫폼에서 이뤄지는 리뷰 중 다섯 건 중 한 건 이상에는 에이전트가 관여합니다. 더 이상 틈새적인 실험이 아닙니다. 지금은 그저 코드가 만들어지는 기본 방식입니다.
서로 다른 네 개의 데이터셋, 네 가지 접근법, 하나의 결론. 우리는 인간 속도에 맞춰 설계된 시스템 안에, 기계 속도의 출력을 그대로 부어넣었습니다. 병목은 사라지지 않았습니다. 단지 검증 단계로 옮겨갔을 뿐, 그리고 코드 리뷰는 바로 그 비용 청구서가 도착하는 지점입니다.
모두가 서로 다른 문제를 풀고 있다
어떤 변경사항이 어느 정도 리뷰를 받아야 하는지는, 거의 전적으로 그 변경의 ‘폭발 반경’에 달려 있습니다. 그리고 당신이 읽는 조언의 대부분은, 당신과는 전혀 다른 폭발 반경에서 일하는 사람이 쓴 글입니다.
위에 언급한 우려스러운 데이터의 상당수는, 엔터프라이즈급 조직의 텔레메트리와, 몰려드는 PR에 압도당한 오픈소스 유지관리자들의 경험에서 나옵니다. 이 환경에서라면 모든 숫자가 지극히 현실적입니다. 하지만 지금 당신이 혼자서, 소수의 사용자만 존재하는 프로젝트를 개발하고 있다면, 그중 상당 부분은 당장 당신에게 그대로 적용되지 않습니다. 그리고 마치 그대로 적용되는 것처럼 느껴야 할 이유도 없습니다.
당신이 어느 위치에 있는지는 세 가지 변수가 거의 다 결정합니다.
- 폭발 반경(blast radius): 깨졌을 때 어떤 일이 벌어지나요. 아무 일도 안 일어나나요, 아니면 성난 사용자·돈·민감 정보(PII)가 한꺼번에 걸려 있나요.
- 코드의 수명: 다음 주에 갈아엎을지도 모르는 일회용 프로토타입인가요, 몇 년을 유지보수해야 하는 코드베이스인가요.
- 이 코드를 이해해야 하는 사람 수: 당신 혼자 머릿속에 구조를 전부 넣고 있으면 되나요, 아니면 시간이 지나도 팀 전체가 공동으로 이해하고 소유해야 하나요.
똑같은 diff라도 이 세 가지 렌즈로 들여다보면, “좋은 리뷰”가 의미하는 바는 완전히 달라집니다.
사용자 없는 그린필드 프로젝트를 혼자 진행 중이라면, 리뷰의 두 번째 역할인 “지식을 팀 전체로 전파하는 기능”은 당신에게 존재하지 않습니다. 팀이 곧 당신 한 사람인 셈입니다. 이런 위치에서 합리적인 선택지는 테스트와 자동화에 강하게 기대고, 진짜 중요한 부분만 리뷰하며, 나머지는 어느 정도 느슨하게 가져가는 것입니다. 코드가 한 달 뒤에도 남아 있을지 알 수 없다면, 중복과 churn(자주 바뀌는 코드)로 인한 비용은 상대적으로 작습니다. 코드가 망가져서 새벽 3시에 호출을 받는 사람도 어차피 당신뿐입니다. 다만 많은 사람이 뼈저리게 배우는 함정이 있습니다. 이 전략은 테스트가 ‘제대로’ 갖춰져 있을 때만 통한다는 점입니다. 안전망 없이 리뷰를 생략하는 건, 일을 없애는 것이 아니라 더 비싼 시점으로 미루는 것에 불과합니다. 누군가 기준선을 잡아 주지 않으면 품질 기준은 반드시 조금씩 미끄러집니다. “사용자가 없다”는 사실은 리뷰를 미뤄도 되는 여지를 줄 뿐이지, 검증을 통째로 건너뛰어도 된다는 허가증은 아닙니다.
그러다 프로젝트에 사용자들이 붙기 시작합니다. 이 단계가 가장 위험한 중간지대이며, 보통은 그 시점에 있는 사람들조차 스스로 위험지대를 건너고 있다는 사실을 잘 자각하지 못합니다. 버그가 실제 사람들에게 피해를 주기 시작하면서 리뷰의 첫 번째 역할(버그 잡기)이 돌연 중요해지고, 더 이상 혼자가 아니게 되면서 “지식 공유” 역할도 갑자기 켜집니다. 많은 팀이 이 전환기를, 혼자일 때의 습관을 조금 오래 유지한 채로 지나갑니다. 그러다 어느 날 포스트모템을 쓰게 되고, Faros 리포트의 숫자들이 더 이상 그래프가 아니라 자신들의 대시보드 위 수치가 됩니다.
스펙트럼의 다른 끝에는, 오래된 코드베이스와 많은 사용자를 가진 대규모 조직이 있습니다. 여기서는 위에서 거론한 모든 우려 지표들이 100% 힘을 발휘합니다. 중복된 헬퍼 함수 하나는 단순한 스타일 논쟁거리가 아닙니다. 앞으로 수년 동안 복리로 쌓여 갈 유지보수 비용과, 잠재적인 버그 표면적의 증가를 의미합니다. 아무도 제대로 이해하지 못한 채 들어간 변경사항은 이해 부채(comprehension debt)를 남기고, 이는 누군가의 온콜 이슈로 돌아옵니다. 이 환경에서 리뷰는 여러 역할을 동시에 수행해야 하고, 여기에 에이전트가 뿜어내는 코드 물량이 더해지면 기존 리뷰 체계는 조용히, 그러나 확실하게 망가집니다. Faros 리포트 중 “성숙한 팀도 똑같이 얻어맞았다”는 대목은 바로 이 구간을 정면으로 겨냥합니다.
그래서 포인트는 “엔터프라이즈는 조심하고, 솔로 개발자는 마음 편히 가도 된다” 정도가 아닙니다. 진짜 핵심은 “리뷰의 목적이 당신이 서 있는 위치에 따라 달라지므로, 규칙도 그에 맞게 달라져야 한다”는 점입니다. 엔터프라이즈 수준의 잠금장치, 다계층 에이전트, 증거 기반 파이프라인을 2인 프로토타입 팀에 그대로 가져다 붙이면, 비용 대비 얻는 건 거의 없이 마찰만 늘어납니다. 반대로 “테스트가 통과하면 그냥 배포하자”는 문화를 결제 시스템에 적용한다면, 녹색 체크마크를 얹은 인시던트 생성기를 만든 것과 다름없습니다. 이 영역에서 나쁜 조언의 대부분은, 이 스펙트럼의 한 지점에 있는 사람이 완전히 다른 지점의 사람에게 처방을 내리는 데서 나옵니다.
지금 코드 리뷰가 실제로 해야 하는 일
리뷰는 원래 “작성자의 추론을 점검하는 일”이었습니다. 하지만 에이전트가 쓴 코드에는 작성자도, 그 작성자의 추론도 없습니다. 그래서 리뷰는 이제, 애초에 어느 누구의 머릿속에도 존재하지 않았던 ‘이유’를 다시 구성해야 하는 일이 되어 버렸고, 이는 더 느리고 근본적으로 다른 작업입니다.
진짜로 바뀐 지점은 바로 이 부분이라고 생각합니다. 그리고 이 변화의 중요성이 아직 충분히 이해되지 못하고 있다고 느낍니다.
사람이 코드를 쓸 때는, 의도가 공짜로 따라옵니다. 무슨 생각을 했는지, 어떤 대안을 검토하다가 버렸는지, 이런 것들이 작성자의 머릿속에 있고, 리뷰는 그 추론 과정을 점검하는 작업에 가깝습니다. 반면 에이전트가 쓴 코드에는 그런 추론이 없습니다. “어떤 사람이 왜 이 코드를 이렇게 썼는지”를 알고 있는 사람 자체가 존재하지 않습니다. 어느 누구도 머릿속으로 ‘왜’를 이해한 뒤 그 결과를 코드로 옮긴 적이 없습니다. 이 때문에 리뷰의 역할은 “사람이 한 생각을 확인하는 일”에서, “애초에 존재하지 않았던 생각을 추론해 복원하는 일”로 조용히 바뀌었습니다. 이 일은 훨씬 더 어렵고 느린데, 우리는 여전히 “리뷰 시간이 441% 늘어났다”는 사실에 놀란 척하고 있습니다.
2026년에 발표된 논문 AI Slop and the Software Commons은 “AI slop”을 주제로 개발자들이 토론한 15개의 Reddit·Hacker News 스레드, 1,154개 글을 분석했습니다. 그 안에서 한 개발자가 남긴 말이 제 머릿속에 오래 남아 있습니다. 에이전트가 만든 PR을 리뷰하는 경험을 이렇게 표현했습니다. “이 코드를 ‘처음으로 눈으로 보는’ 사람이 나였다(first human being to ever lay eyes on this code)”.
이 표현은 한 번쯤 곱씹어 볼 만합니다. 기존의 리뷰에서는, 작성자가 이미 변경사항을 이해하고 있고, 당신은 그 작업을 확인하는 위치에 있습니다. 반면 지금은 어느 누구도 이해해 본 적 없는 PR이 있고, 리뷰어가 최초로 그 코드를 이해해 보려는 사람이 됩니다. 논문은 “리뷰는 ‘빠진 의도’를 되살려내도록 설계된 도구가 아니었다”고 말합니다. 우리는 원래 “추론을 확인하는 도구”로 설계된 시스템을, 이제 와 “추론을 처음부터 만들어내는 시스템”으로 쓰고 있고, 그러면서 그것이 느리다고 불평하는 셈입니다.
논문은 또 구조적인 함정도 잘 짚어냅니다. 이 출력물들은 표면적으로 그럴듯해 보이고, 생성은 싸고 빠르지만, 리뷰는 비싸고 느리고, 무엇보다도 거의 무한정 만들어낼 수 있다는 점입니다. 이 세 가지 조건이 합쳐지면, 모든 공유 자원—리뷰어의 집중력은 물론, 코드베이스 자체, 사람들 사이의 신뢰까지—를 조금씩 갈아 넣게 됩니다. 그리고 한 개발자가 얻은 생산성 이득은, 그 뒤를 받치는 모든 사람의 비용으로 치러집니다.
이 지점 때문에 “AI가 AI를 리뷰하게 하자”는 해법은 절반짜리 답에 그칩니다. 서로 다른 사전 분포(prior)를 가진 두 번째 모델이, 사람 눈을 그대로 스쳐 지나갔을 버그를 잡아 줄 수 있다는 점은 분명 의미가 있습니다. 하지만 이 방식은 “애초에 이 변경이 맞는 방향인지”라는, 더 근본적인 질문에 답하지 못합니다. “코드가 형식적으로 맞는가”가 아니라, “이걸 하는 게 맞는가”를 판단하는 일은 여전히 사람에게 남아 있고, GPU를 더 늘린다고 해서 그 작업이 갑자기 빨라지지는 않습니다.
도구들은 충분히 좋다. 다만 스스로 내세우는 이유 때문만은 아니다
지금 나와 있는 AI 리뷰어들은 실제로 꽤 쓸 만하고, 서로 같은 줄을 지적하는 일이 거의 없습니다. 그래서 “최고의 도구 하나를 고르는 것”보다, 성격이 다른 둘을 함께 돌리는 편이 훨씬 낫습니다.
전용 AI 리뷰 도구들은 이제 상당히 잘 만든 편이고, 개인 프로젝트를 포함해 웬만하면 모든 변경에 하나 정도는 붙여 두는 편이 좋다고 봅니다. CodeRabbit은 가장 널리 배포된 도구 중 하나이고, 독립 벤치마크인 Martian benchmark(2026년 1~2월 기준)에서 F1 점수 1위(정밀도 약 49%, 리콜은 전체 도구 중 최고)를 기록했습니다. Greptile은 정밀도 일부를 희생하는 대신 리콜을 크게 끌어올리는 쪽에 가깝습니다. 한 벤치마크에서는 CodeRabbit이 약 44% 수준의 버그를 잡을 때 Greptile은 약 82%를 포착했지만, 그만큼 false positive가 많습니다. Anthropic의 Code Review는 내부 엔지니어들이 “틀렸다”고 표시한 결과가 1% 미만이라고 밝히며, 제가 매니저라면 가장 먼저 보여 줄 법한 숫자를 하나 더 제시합니다. 바로 PR 중 ‘실질적인’ 리뷰를 받은 비율을 16%에서 54%까지 끌어올렸다는 점입니다. 예전에는 대충 훑어보고 승인되던 긴 꼬리(long tail)의 변경들이, 이제는 최소한 무언가의 ‘읽힘’을 받는다는 뜻입니다.
올해 제가 본 결과 중 가장 흥미로운 것은, 벤더가 아닌 개인 엔지니어가 수행한 실험입니다. 한 엔지니어가 실제 코드베이스에서 3주 반 동안, 146개 PR과 679개 지적사항을 대상으로 CodeRabbit, Sentry Seer, Greptile, Cursor BugBot 네 개 리뷰어를 병렬로 돌린 실험을 했습니다.
617개의 서로 다른 지적 위치 중, 93.4%는 네 도구 중 딱 한 도구만 발견했습니다. 두 도구가 겹쳐 잡은 경우는 6%였고, 세 도구가 동시에 잡은 경우는 거의 없었습니다. 네 도구가 모두 같은 줄을 지적한 경우는 단 한 번도 없었습니다.
네 도구는 단 한 줄도 동시에 지적하지 않았습니다. 각 도구는 서로 다른 유형의 문제에 강했습니다. Greptile은 정확성과 아키텍처 쪽에서 false positive가 거의 없었고, CodeRabbit은 폭넓은 범위를 포착하면서 원클릭 수정까지 제안해 줬고, Seer는 실제 프로덕션 장애로 이어질 수 있는 심각도 판단이 가장 뛰어났습니다. 이는 “적대적 리뷰(adversarial review)”의 장점을, 논문이 아니라 실제 코드베이스 위에서 보여 준 셈입니다. 이질성이 바로 핵심입니다. 같은 모델 네 개를 돌리는 건, 결국 한 명짜리 리뷰어에게 더 큰 청구서를 보내는 것과 다름없지만, 성격이 다른 네 리뷰어는 어느 한 명도 혼자서는 찾지 못할 버그 집합을 함께 찾아냅니다. 인간 리뷰어를 포함해서 말입니다.
실무적인 결론은 이렇습니다. “최고의 도구 하나”를 뽑느라 고민할 필요는 없습니다. 그런 도구는 없습니다. 위험도가 높은 서비스라면 캐릭터가 분명히 다른 두 도구를 의도적으로 함께 돌리세요(위 실험에서는 Greptile을 일상적인 정확성 용도로, Seer를 프로덕션 장애 심각도 판단용으로 짝지어 썼고, 겹치는 부분은 거의 없었습니다). 혼자 일한다면, 충분히 괜찮은 리뷰어 하나와 “진짜” 테스트만으로도 충분합니다. 그리고 마케팅이 뭐라고 말하든, 항상 당신 코드베이스에서 직접 효과를 측정하세요. 여기 언급된 모든 수치는 특정 코드베이스에서 나온 결과이며, 당신의 코드베이스는 반드시 다를 것이기 때문입니다.
정말 AI에게 더 많은 리뷰를 맡겨야 할까?
기계는 이미 당신보다 더 많은 코드를 리뷰하고 있습니다. 이제 남은 진짜 결정은, 이를 의도적으로 설계할지, 아니면 “아직도 사람이 다 읽고 있다”는 척을 하며 자연 발생적으로 방치할지입니다. 남겨둘 인간의 비율은 폭발 반경에 비례해서 정해야 합니다.
예전 같으면 신성모독에 가까웠을 질문을, 이제는 경험 많은 엔지니어들까지 자주 묻습니다. “리뷰 대부분을 기계에게 맡겨야 하는 것 아닐까?” 저는 이제 이 질문이 어리석다고 생각하지 않습니다.
불편한 진실은, AI 리뷰가 실제로 ‘된다’는 점입니다. Anthropic이 보고한 대로 잘못된 지적은 1% 미만이었고, AI 리뷰어들은 사람이 그대로 지나쳤을 버그를 잡아냅니다. 이들은 하루 서른 번째 PR을 처리할 때도 지치지 않습니다. 바로 그 시점이 인간 리뷰어가 가장 믿기 어려워지는 시점인데도 말입니다. 한편 인간 리뷰어들은 확실히 속도를 따라잡지 못하고 있습니다. 리뷰 없이 머지되는 PR은 31% 늘었고, 리뷰 시간은 세 자릿수 퍼센트로 늘었습니다. 현실적으로 기계는 이미, 우리가 직접 읽는 것보다 더 많은 코드를 리뷰하고 있습니다. 솔직한 프레이밍은 “AI에게 더 많은 리뷰를 맡겨야 할까?”가 아니라, “AI가 이미 상당 부분 리뷰를 하고 있는 상황에서, 이를 인정하고 설계할 것인가, 아니면 여전히 사람이 다 읽고 있다고 믿는 척을 할 것인가”에 가깝습니다.
루프 엔지니어링(loop engineering)을 도입하면 이 화두는 더욱 선명해집니다. 루프의 전제는, 사람이 직접 에이전트에게 프롬프트를 던지는 역할에서 물러나, “시스템이 에이전트를 프롬프트하도록” 만드는 것입니다. 이 시스템의 핵심 요소 중 하나가 심판(judge)입니다. 작업이 끝났는지 여부를 판단하고, 다음 단계로 넘어갈지 말지를 결정하는 에이전트입니다. 리뷰어는 지금, 의도적으로 루프의 안쪽에서 제거되려는 다음 역할입니다. 우리는 지난 1년 동안 “작성”을 자동화하는 데 집중했고, 이제 루프들이 “검사” 단계까지 자동화하는 중입니다. 인간은 계속해서 한 단계씩 바깥으로 밀려나고 있습니다. “인간이 어디에 남을 것인가”는 세미나에서 토론할 주제가 아니라, 루프를 설계할 때마다—심지어 스스로 그 사실을 의식하지 못한 채로—매번 내리고 있는 결정입니다.
제가 지금 시점에서 내린 결론(그리고 이 결론에 크게 집착하지 않으려 한다면)은 이렇습니다. 해답은 “사람이 모든 줄을 읽는다”가 아닙니다. 그 시대는 끝났습니다. 물량이 그 가능성을 없애버렸고, 여전히 그 말을 고집하는 사람은 더 이상 존재하지 않는 세계를 설명하고 있을 뿐입니다. 그렇다고 “루프가 스스로 리뷰하게 내버려 두고 떠난다”가 답인 것도 아닙니다. 한 에이전트가 코드를 쓰고, 또 다른 에이전트가 그것을 리뷰하고, 세 번째 에이전트가 판정을 내리는 구조라면, 결국 비슷한 데이터로 학습된 모델들로 닫힌 루프를 만드는 셈입니다. 이들은 같은 사각지대를 공유하고, 같은 지점에서 자신만만하게 틀릴 수 있습니다. 사람은 어디에도 없는데 “괜찮아 보인다”라는 자신감 넘치는 평가가 내려진다면, 그것은 빌려 온 확신(borrowed confidence)에 불과합니다. 시스템의 확신이 곧 당신의 확신이 되고, 그 과정에서 아무도 실제로는 아무것도 이해하지 못한 상태가 됩니다. 이런 루프는 동시에 매우 확신에 차 있으면서도, 똑같이 크게 틀려 있을 수 있고, 그 차이를 구분해 줄 사람도 남아 있지 않습니다.
그래서 인간은 사라지지 않습니다. 대신 한 단계 위로 올라갑니다. 이제는 모든 diff를 일일이 리뷰하기보다, 모델로 대체할 수 없는 지점에 책임을 집니다. 장애가 났을 때 호출을 받을 주체는 여전히 사람이고, “이 변경이 애초에 만들어야 할 올바른 변경인가”라는 판단도 사람의 몫입니다. 잘 돌아가는 코드와는 별개의 문제입니다. 폭발 반경이 큰 지점에서의 최종 승인 역시 그렇습니다. 또 하나 중요한 부분은, 아무도 명시하지 않은 동작입니다. 모델은 “존재하는 코드”만 리뷰합니다. 그러다 보니, 처음부터 요구사항으로 적어 두지 않은 행동은 절대 지적하지 못합니다. 이 부분은 당분간 사람 모양의 빈 자리로 남을 것이고, 쉽게 메워질 것 같지도 않습니다. “사람이 루프 안에(human in the loop)” 있는 구조는 “사람이 루프 위에(human on the loop)” 서는 구조로 바뀝니다. 모든 PR을 읽는 대신 시스템을 표본 추출·스팟 체크·감사하는 방향으로 역할이 옮겨가고, 사람의 한정된 주의력은 “틀리면 진짜로 크게 아픈 곳”에만 쓰이게 됩니다.
이건 이미 제가 제 프로젝트에서 일하는 방식입니다. 인기 있는 오픈소스 프로젝트처럼, 하루에도 제가 한밤중까지 꼼꼼히 읽기엔 너무 많은 PR이 들어오는 경우도 포함해서 말입니다. 저는 Claude Code나 Codex를 PR 큐에 붙이고, 들어온 PR 묶음에 대해 1차 평가를 맡깁니다. “당장 머지해도 안전해 보이는 것”, “더 작업이 필요한 것”, “진짜 위험해 보이는 것”을 구분해 달라고 합니다. 저는 이 결과를 기반으로 자동 머지를 걸지 않습니다. 에이전트가 좋다고 한 건 대충 보고 머지하는 식으로도 쓰지 않습니다. 이 셋업이 주는 가치는, 제 주의를 어디에 쓸지 배치할 수 있게 해 준다는 점입니다. 에이전트가 저위험으로 분류한 변경은 몇 분 정도 확인만 하고, 위험 신호를 켠 변경에는 더 많은 시간을 씁니다. 중요한 건, 이게 예전의 “리뷰 한 시간을 조금 더 빠르게 만든 것”이 아니라는 점입니다. 같은 한 시간이라도 모양이 완전히 다릅니다. 그리고 지금 제가 상대하는 물량에서는, 이 방식 덕분에 큐가 간신히라도 감당 가능한 수준으로 유지되고 있습니다.
Claude Code(왼쪽)와 Codex(오른쪽)이 PR 묶음을 처음부터 위험도 순으로 읽어 정리해 줍니다. 저를 돕는 건 이 1차 분류 작업이고, 머지 여부를 결정하는 일은 여전히 제 몫입니다.
좀 더 극단적인 버전의 같은 움직임이 있습니다. 메타 출신 L8 엔지니어였던 Kun Chen은 지금은 혼자서 하루에 PR을 40개 정도 머지하는 빌더인데, 거의 리뷰를 하지 않습니다. 이 이야기를 가볍게 치부하기 쉬운데, 흥미로운 점은 그가 L8이라는 사실입니다. 즉 스스로가 그만둔 바로 그 일을 원래는 매우 잘하던 사람이라는 의미입니다. 그는 20~30개 에이전트를 병렬로 돌려놓고, 자신의 에너지를 “플랜을 짜는 일”에 집중합니다. 먼저 아주 자세한 플랜을 쓰고, 그 플랜을 기준으로 에이전트들이 몇 시간씩 돌아가게 만듭니다. 그의 말에 따르면 “플랜의 질이 에이전트가 사람 개입 없이 얼마나 오래 돌아갈 수 있는지를 결정한다”. 앞에서 제가 설명한 움직임이 가장 극단적으로 구현된 사례입니다. 여기서 실제로 일어난 일을 정확히 짚어 보겠습니다. 그는 “검증을 통째로 버린 것”이 아닙니다. 의도가 사라진 게 아니라, 플랜이라는 형태로 앞단에 옮겨졌습니다. “이 변경을 왜 하는가”를 한 번이라도 사람이 이해하고 적어 둔 셈입니다. 그래서 ‘이 코드를 처음 이해해 보는 사람이 리뷰어’라는 문제가 절반은 풀립니다. 또한 그는 안전망 없이 일하지 않았습니다. No Mistakes라 부르는 자동 리뷰 게이트를 만들어 두고, 코드가 머지되기 전 거기서 자동 검사를 거치게 했습니다. 에이전트가 막힐 때 개입하는 역할도 그가 맡습니다. 사람은 코드가 생기기 전에 비싼 사고 과정을 수행하고, 코드를 줄 단위로 살피는 일은 기계에게 넘기는 구조입니다. 앞으로 이 방향이 주류가 될 가능성이 크다고 생각합니다.
하지만 그는 대규모 팀도, 10년 된 지뢰밭 코드베이스도 없습니다. “리뷰 거의 없이 하루 40개 PR을 머지하는 게 합리적인 선택인 조건”은, 대부분의 독자에게는 존재하지 않습니다. 그의 워크플로를 사용자가 많은 팀에 그대로 이식하면, Faros 리포트의 그래프를 당신 회사 대시보드에서 그대로 재현하게 될 것입니다. 그가 틀린 게 아닙니다. 다만 스펙트럼 한쪽 끝에서 상당히 멀리 나간 사례라는 점을 이해해야 합니다.
여기서 다시 스펙트럼 이야기가 나옵니다. 사용자가 없는 솔로 개발자라면, 거의 모든 리뷰를 AI에 맡기는 것도 2026년 현재 충분히 방어 가능한 입장입니다. 죄책감을 느낄 필요는 없습니다. 반대로 많은 사용자를 상대하는 대규모 시스템을 유지하는 입장이라면, 1차·2차·지루한 90%까지 AI에게 맡기는 건 자연스러운 수순입니다. 하지만 진짜 폭발 반경이 큰 경로—실수하면 크게 아픈 부분—에는 반드시 사람이 붙어 있어야 하고, 사람의 눈이 단 한 번도 지나가지 않은 채 루프가 완전히 닫히는 영역을 만들어서는 안 됩니다. “얼마나 많은 사람 리뷰를 남겨 둘 것인가”라는 다이얼은, 죄책감이 아니라 폭발 반경으로 맞춰야 합니다.
실제로 무엇을 해야 할까
모든 변경사항을 같은 깊이로 리뷰하는 것을 멈추세요. 사람의 한정된 주의력은 “틀리면 비싼 곳”에만 쓰고, 나머지는 값싼 결정적(deterministic) 검증과 AI 리뷰어에게 맡기세요.
핵심 아이디어는, “틀렸을 때 비용”에 리뷰 강도를 맞추고, 값싼 결정적 검사들을 가능한 한 앞단으로 밀어붙이며, 진짜 사람의 주의를 “사람만 할 수 있는 일”에만 쓰게 만드는 것입니다.
저자(author)가 아니라 리스크로 티어링하세요. 설정 파일 한 줄 바꾸는 변경은 린터와 한 번의 훑어보기면 충분합니다. 결제 경로 변경은 다릅니다. 타입, 테스트, 서로 다른 두 개 AI 리뷰어, 해당 시스템을 책임지는 사람, 필요하다면 보안 리뷰까지 풀 스택으로 붙여야 합니다. 템플릿 코드에 무거운 리뷰를 쓰지 말고, 인증·권한 같은 부분은 “테스트가 통과했다”는 이유만으로 가볍게 흘려보내지 마세요. 레이어를 쌓는 접근 자체는 모든 곳에서 같습니다. 바뀌는 건 “어떤 diff가 얼마나 많은 레이어를 통과해야 하는가”뿐입니다.
비싼 꼬리를 초반에 자르세요(fast-fail). 에이전트 PR에 허우적대는 팀에게 최근 가장 유용했던 결과는 2026년 1월 논문 Early-Stage Prediction of Review Effort입니다. 이 논문은 에이전트가 작성한 PR 33,707건을 분석했습니다. 에이전트는 작고 잘 정의된 변경에는 강합니다. 약 28%는 거의 즉시 머지됩니다. 하지만 조금만 주관적인 피드백이 오가기 시작하면, 리뷰의 핵심인 “앞뒤 주고받기”가 시작되려는 바로 그 지점에서, 에이전트는 곧잘 “유령처럼 사라져 버린다(ghosting)”. (동반 논문에서는 리뷰어 이탈이 전체 에이전트 PR 거절의 38%를 차지한다는 결과도 내놓았습니다.) 연구진은 파일 타입, 패치 크기 같은 값싼 신호만으로 “앞으로 리뷰에 큰 공수가 들 PR”을 예측하는 회로 차단기(circuit breaker)를 만들었고, 이게 꽤 잘 작동했습니다. 핵심은, 에이전트 PR을 초기에 분류하고, 사소한 건 빠르게 통과시키며, 사람 한 명이 대형 변경에 한 시간씩 빨려 들어가기 전에 “이 PR은 에이전트가 어차피 중간에 손을 놓을 확률이 크다”는 경고를 주는 것입니다.
‘리뷰 받을 자격’을 올리세요. 물량에 깔려 죽지 않으려면, 리포지토리를 잠그는 게 아니라, 증거 없이 날아온 변경은 아예 리뷰하지 않는 룰을 세워야 합니다. 리뷰 전에 반드시 요구할 것들: 이 변경이 무엇을 위한 것인지에 대한 설명, 3,500줄짜리 노코멘트(diff) 같은 건 아닌지, 테스트 결과, 실제로 실행해 봤다는 증거. 이렇게 해야 “이 코드를 처음 읽어 보는 사람이 리뷰어”가 되는 상황을 막을 수 있습니다. 비싼 “의도 복원 작업”을 리뷰어에게 떠넘기는 대신, 가장 싸게 할 수 있는 제출자에게 다시 돌려보내는 셈입니다.
PR은 의도적으로 작게 유지하세요. Faros 데이터에 따르면 에이전트가 만든 PR은 사람이 만든 것보다 평균 51% 더 큽니다. 리뷰어 참여도는 PR이 실제로 머지될지의 가장 강력한 예측 변수 중 하나입니다. 너무 커서 도저히 읽을 수 없는 PR은 통째로 거부당하거나, 더 나쁘게는 대충 승인됩니다. 에이전트에게 “작은 커밋을 내라”고 명시적으로 지시하세요. 사람이 실제로 읽을 수 있는 diff는 이제 예의 차원이 아니라, 시스템 설계의 제약 조건입니다.
코드보다 테스트 변경을 더 꼼꼼히 읽으세요. 이게 에이전트의 대표적인 실패 패턴입니다. 에이전트가 동작을 바꾸고, 그 뒤에 “깨진 테스트를 고치겠다”며 테스트의 단언(assertion)을 새로 바뀐(틀린) 동작에 맞춰 다시 써 버립니다. 테스트 200개가 수정된 뒤의 초록색 체크마크는, 그 수정이 올바른지 확인하지 않는 한 아무 의미가 없습니다. 테스트를 대규모로 고치는 diff는 깃발로 취급하고, 먼저 그 부분부터 읽으세요. 여기서 변이 테스트(mutation testing)는 도입할 가치가 있습니다. 커버리지는 한 줄이 실행됐다는 사실까지만 말해 줍니다. 변이 테스트는 “그 줄이 틀렸을 때 테스트가 실제로 실패하는가”를 말해 줍니다.
CI를 ‘절대 물러서지 않는 벽’으로 취급하세요. GitHub가 지금 리뷰어에게 알려주는 패턴들을 주의 깊게 보세요. 테스트 제거, 린트 스킵, 커버리지 기준 완화, 이미 존재하는 헬퍼의 중복 추가, 그리고 “신뢰할 수 없는 입력”이 프롬프트로 흘러 들어가는 코드. 마지막 항목은 특히 강조할 만합니다. 에이전트가 만드는 기능은 프롬프트 인젝션의 새로운 공급원입니다. 사용자 제어 입력을 아무 생각 없이 LLM 호출에 흘려 넣으면, 이 취약점은 diff에는 드러나지 않고, 나중에 들어올 데이터에 잠복하게 됩니다. 에이전트는 CI도 스스로 약화시킵니다. 악의가 있어서가 아니라, “초록불로 가는 가장 싼 경로”를 찾는 과정에서 자연스럽게 그렇게 됩니다. 결정적 게이트만이, 그 어떤 그럴듯한 문단으로도 설득당하지 않는 파이프라인의 유일한 부분입니다. 이 경계는 끝까지 엄격하게 유지해야 합니다.
머지에는 항상 사람이 책임자로 있어야 합니다. 모델은 새벽 3시에 전화를 받을 수 없고, 자신이 배포한 결과에 대해 책임을 질 수도 없습니다. 머지 버튼을 누르는 사람은 항상 그 결과에 대한 책임을 집니다. AI 리뷰가 차분하고 자신감 있는 목소리로 “괜찮아 보인다”고 말하는 순간, 그건 스스로 충분히 벌지 못한 확신을 당신에게 전가하는 것입니다. AI 리뷰는 항상 “판결”이 아니라 “센서”로 취급하세요. 의사결정이 아니라 의사결정에 필요한 데이터로만 이해해야 합니다.
사용자가 없는 솔로라면, 리스크 티어링·테스트 변경에 대한 엄격함·CI만 있어도 대부분을 해결할 수 있습니다. 나머지는 사람들이 생긴 뒤에나 의미를 갖는 오버헤드입니다. 대규모 조직이라면, 지금까지 언급한 모든 것이 기본값입니다. 여기에 에이전트 PR 트리아지와 리뷰 인입 기준을 더해야만, “점점 속으로 붕괴하는 리뷰 프로세스” 대신 “물량이 늘어나도 겨우 버티는 체계”를 가질 수 있습니다.
팀을 운영한다면 무엇을 의미할까
이제 병목은 “코드를 얼마나 빨리 쓸 수 있는가”가 아니라, “신뢰받는 인간이 얼마나 빨리 리뷰에 자신감을 가질 수 있는가”에 있습니다. “AI 덕분에 빨라졌다”며 그 신뢰를 제공하는 사람을 줄이면, 절감한 비용은 미래 인시던트로 그대로 되돌아옵니다.
배포 속도를 결정하는 진짜 제약은 더 이상 코드 작성 속도가 아닙니다. “신뢰받는 사람이, 이 변경이 옳다고 확신하는 데 필요한 시간”입니다. 코드 생성만 병목으로 보고, 리뷰를 공짜 자원으로 취급하는 계획은, 벨로시티 대시는 계속 초록색인 채로, 팀이 서서히 물에 잠기는 시나리오와 같습니다.
Faros 리포트는 이 점을 아주 노골적으로 짚습니다. 산출량이 늘어날수록 QA와 리뷰 업무도 함께 증가합니다. 따라서 “AI 덕분에 빨라졌다”며 엔지니어링 인력을 줄이는 건, 리뷰 격차를 먼저 해소하지 않는 이상 위험한 선택입니다. 리뷰 시간의 세 자릿수 증가라는 “시니어 엔지니어 세금”은, 그 누구보다도 귀한 인력에게 가장 심하게 부과됩니다. 이 비용은 “머지된 PR 개수”만 보는 메트릭에는 절대 드러나지 않습니다.
오픈소스 유지관리자들은 이 벽에 가장 먼저, 가장 세게 부딪혔습니다. 겉보기에는 그럴듯하지만 속이 빈 기여의 꾸준한 유입은, 기여자의 의도가 좋았든 아니든, 유지관리자에게는 실제 triage 시간이라는 비용을 청구합니다. 이들은 카나리아(canary)입니다. 그 다음 순서는 기업입니다. 잘 대응하는 회사들은 리뷰 용량을 “실제로 측정·보호·계획해서 써야 할 자원”으로 다룹니다. “AI가 생겼으니 생긴 여유” 정도로 취급하지 않습니다.
쓰는 일은 싸졌지만, 이해하는 일은 그대로다
에이전트가 등장했다고 해서 코드 리뷰의 중요성이 줄어든 게 아닙니다. 오히려 중심이 되었습니다. 코드를 쓰는 일은 점점 해결된 문제에 가까워지고 있고, 매달 더 싸집니다. 남는 차별점은 그 코드들을 “믿을 수 있게 만드는 시스템”입니다.
어느 방향에서든, 한 가지 답으로 모든 상황을 해결하려 들지 마세요. 사용자 없는 솔로 개발자라면, 엔터프라이즈가 겪는 churn과 중복의 공포는 내일의 리스크이지 오늘의 화재는 아닙니다. 그러니 테스트에 기대고, 진짜 중요한 것만 리뷰하며, “미뤄둔 일은 언젠가 값을 치러야 한다”는 사실만 솔직하게 인정하고 가면 됩니다. 많은 사람에게 서비스를 제공하는 대규모 시스템을 유지한다면, 여기 등장한 모든 우려 지표는 그대로 당신 이야기입니다. 이 경우 버틸 수 있는 유일한 해법은, 폭발 반경에 따라 층을 나누고, 증거 없이는 리뷰를 시작하지 않고, 서로 다른 성격의 리뷰어들을 의도적으로 섞어 쓰며, 최종 머지에는 항상 사람이 책임을 지는 체계입니다.
스펙트럼 전체에 공통으로 흐르는 건 결국 경제성입니다. 우리는 “쓰는 일”을 싸게 만들었고, “이해하는 일”의 비용은 예전 그대로입니다. 앞으로 몇 년 동안 잘 나갈 팀은 가장 많은 코드를 생성한 팀이 아니라, **“리뷰 시스템을 믿을 수 있도록 만든 팀”**일 것입니다. 그리고 절대 “테스트가 통과했다”를 “누군가 이 코드가 무엇을, 왜 하는지 이해하고 있다”와 혼동하지 않는 팀일 것입니다. Simon Willison의 말을 빌리면, 당신의 일은 “작동함이 증명된 코드를 전달하는 것”입니다. 에이전트는 이 사실을 바꾸지 않았습니다. 오히려 “증명하는 일”이 곧 일의 전부가 되게 만들었습니다.