에이전틱 코드 리뷰

올해 내 작업 방식에서 가장 크게 달라진 점은 에이전트가 코드 대부분을 작성한다는 게 아니다. 그 코드를 검토하는 일이 내가 하는 일 중 가장 큰 비용이 됐다는 것이다. 그리고 이 변화가 무엇을 의미하는지, 우리는 아직 제대로 받아들이지 못하고 있다.

코드 리뷰가 제대로 작동했던 건 사실 우연히 맞아떨어진 속도 덕분이었다. 시니어 엔지니어는 주니어가 코드를 작성하는 것보다 빠르게 읽을 수 있었다. 그러니 별도로 설계하지 않아도 리뷰가 개발 속도를 따라잡을 수 있었고, 팀원들은 서로의 diff를 읽는 과정에서 자연스럽게 시스템 전체를 파악하게 됐다. 이 모든 게 의도적으로 만들어진 구조가 아니었다. 단 하나의 사실, 즉 코드를 작성하는 것이 느리고 비용이 큰 반면 읽는 것은 빠르고 저렴하다는 사실에서 자연스럽게 비롯된 결과였다.

이제 그 전제는 무너졌다. 에이전트는 내가 이 단락을 읽는 시간도 안 되어 그럴듯하고 잘 정돈된, 대체로 정확한 코드를 천 줄씩 쏟아낸다. 작성 비용은 0에 수렴했다. 인간의 독해 속도는 그대로다. 결국 언제나 진짜 제약이었던 것, 즉 실제로 변경 사항을 이해하는 인간 한 명이 파이프라인 전체를 기다리게 만드는 존재가 됐다. 내가 대화를 나눠본 팀 대부분은 이 사실을 아직 눈치채지 못했거나, 눈치채고도 모른 척하고 있었다.

한 가지 아이러니를 먼저 짚고 싶다. 이 글의 방향과 직결된 문제이기 때문이다. 코드 홍수를 만들어내는 도구가, 동시에 그 홍수를 감당하는 데 가장 도움이 되는 도구이기도 하다. 나는 내 프로젝트, 인기 있는 오픈소스 프로젝트들을 포함해서, 들어오는 PR 묶음에 Claude Code나 Codex를 붙여 큐를 먼저 추려내도록 하고 있다. 이 방식이 내 시간 사용 방식을 실제로 바꿔놨다. 그러니 이 글은 AI를 반대하는 주장이 아니다. 내가 AI를 구체적으로 어떻게 활용하는지는 뒤에서 다시 다룰 것이다.

데이터를 나열하거나, 모델이 코드를 작성하게 두는 게 훌륭한지 아니면 장인 정신의 종말인지를 또 한 번 논쟁할 생각도 없다. 그런 프레임 자체가 쓸모없기 때문이다. 실제 코드베이스를 앞에 두면 "상황에 따라 다르다"는 대답만이 살아남는다. 사이드 프로젝트를 바이브 코딩으로 만들어 열두 명쯤 써볼 개발자와, 10년 된 결제 시스템을 한 분기 더 살려야 하는 팀은 공유하는 제약이 거의 없다. 그런데 지금 돌아다니는 조언 대부분은, 둘 중 한 사람이 다른 사람에게 자기 방식대로 살라고 훈수를 두는 꼴이다.

2026년 데이터가 실제로 말하는 것

AI가 가져다주는 실질적인 생산성 향상은 10% 정도에 불과한 반면, 코드 볼륨은 약 4배로 늘어난다. AI가 더하는 것의 대부분은 가치가 아니라 인간이 검토해야 할 코드의 양이다. 서로 다른 결론에 동의하는 게 거의 없는 네 개의 독립적인 데이터셋이 바로 이 점에서만큼은 한목소리를 낸다.

몇 년간은 일화와 주장에 머물렀던 이야기가 이제는 대규모로 측정된 결과다. 공통된 이해관계도 없고 일부는 상업적으로 경쟁 관계에 있는 조직들이 각자 측정했는데, 숫자가 계속 같은 방향을 가리킨다. AI는 산출량을 가파르게 끌어올리고, 품질과 리뷰 가능성을 동시에 떨어뜨린다.

Faros AI는 4,000개 팀의 개발자 2만 2,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개(AI 공동 작성 320개, 인간 단독 작성 150개)를 분석했다. AI가 작성한 변경 사항에는 약 1.7배 더 많은 문제가 담겨 있었다. 로직과 정확성 문제는 약 75% 증가했고, 보안 문제는 1.5~2배, 가독성 문제는 세 배 이상 늘었다. CodeRabbit의 AI 디렉터 David Loker는 이를 "조직이 적극적으로 완화해야 할 예측 가능하고 측정 가능한 약점"이라고 표현했다. '예측 가능하다'는 표현이 핵심이다. 버그가 어디에 집중되는지 우리는 알고 있다. 그런데도 확인하기를 멈췄다.

GitClear에는 내가 가장 먼저 꺼내고 싶은 수치가 있다. 2025년까지의 생산성 데이터에 따르면, AI를 매일 사용하는 개발자는 비사용자에 비해 약 4배의 원시 산출량을 낸다. 그런데 1년 전 자신의 산출량과 비교하면, 실질적인 생산성 향상은 고작 12%에 불과하다. 코드는 약 4배 생성되는데 실제로 전달된 가치는 10분의 1 정도 더 늘어난 셈이다. 그리고 그 4배의 코드를 인간이 전부 검토해야 한다. GitClear의 Bill Harding은 그 12%조차 선택 편향일 수 있다고 솔직하게 밝혔다. AI 사용 집단에 더 뛰어난 개발자들이 집중됐을 가능성이 있기 때문이다. 4배의 코드 대 10분의 1의 가치, 이 간극이 곧 리뷰 문제를 한 문장으로 압축한 것이다.

GitHub에 따르면 Copilot 리뷰는 현재 6,000만 건을 돌파했다. 1년도 안 되어 10배 증가한 수치이며, 플랫폼 전체 리뷰의 5건 중 1건 이상에 에이전트가 개입하고 있다. 이제 에이전트는 틈새 기술이 아니다. 코드가 만들어지는 방식 자체가 됐다.

네 개의 데이터셋, 네 가지 방법론, 하나의 결론. 우리는 인간의 속도에 맞게 설계된 시스템에 기계의 속도로 산출물을 쏟아부었다. 병목은 사라지지 않았다. 검증 단계로 이동했을 뿐이며, 리뷰가 그 청구서를 받는 곳이다.

모두가 다른 문제를 풀고 있다

변경 사항에 리뷰가 얼마나 필요한지는 거의 전적으로 그 영향 범위에 달려 있다. 그런데 우리가 읽는 조언 대부분은 전혀 다른 영향 범위에서 일하는 사람이 쓴 것이다.

위에서 언급한 놀라운 데이터는 대부분 엔터프라이즈 텔레메트리나 PR 홍수에 압도된 오픈소스 메인테이너들에게서 나온 것이다. 그 상황에 처해 있다면 완전히 실제적인 이야기다. 하지만 혼자서, 몇 명이나 써볼까 싶은 무언가를 만들고 있다면 그 내용 대부분은 해당 사항이 없다. 그렇게 느끼도록 만들어선 안 된다.

자신의 위치를 결정하는 변수는 세 가지다.

• 영향 범위: 무너졌을 때 어떤 일이 벌어지는가. 아무 일도 없거나, 아니면 화난 사용자와 돈과 개인정보가 걸리거나.
• 코드의 수명: 다음 주에 다시 만들 수도 있는 일회용 프로토타입인가, 아니면 수년간 유지보수할 코드베이스인가.
• 이해해야 하는 사람의 수: 전체를 혼자 머릿속에 담고 있어도 되는가, 아니면 팀 전체가 오랫동안 공동으로 소유권을 나눠야 하는가.

같은 diff도 이 세 가지를 통과시키면 '좋은 리뷰'의 의미가 완전히 달라진다.

사용자 없이 혼자 그린필드 프로젝트를 진행 중이라면, 리뷰의 두 번째 기능, 즉 팀 전체에 지식을 분산하는 역할이 애초에 존재하지 않는다. 당신이 곧 팀이다. 합리적인 선택은 테스트와 자동화에 단단히 기대고, 정말 중요한 부분만 리뷰하고, 나머지는 가볍게 넘기는 것이다. 코드가 한 달 후에 사라질 수도 있고, 새벽 3시에 누가 호출될 일도 없다면 중복이나 churn의 비용은 훨씬 낮다. 단, 이 방식이 통하려면 테스트가 실질적이어야 한다는 조건이 있고, 이 부분에서 고통스럽게 깨닫는 사람들이 많다. 안전망 없이 리뷰를 건너뛰는 건 일을 없애는 게 아니라 더 높은 값을 치르고 미루는 것이다. 아무도 반박해주지 않으면 기준은 낮아지기 마련이다. 사용자가 없다는 건 리뷰를 미룰 수 있다는 허가지, 검증을 건너뛰어도 된다는 허가가 아니다.

그러다 프로젝트에 사용자가 생긴다. 이게 위험한 중간 지점이고, 이 전환점은 그 순간에는 좀처럼 인식되지 않는다. 버그를 잡아내는 리뷰의 역할이 갑자기 중요해진다. 이제 버그가 사람을 다치게 하기 때문이다. 지식 공유 역할도 켜진다. 더 이상 혼자가 아니기 때문이다. 팀들은 1인 개발 시절 습관을 몇 달 더 이어가고, 그러다 사후 분석(postmortem)이 열리면서 Faros의 숫자가 차트 속 이야기가 아니라 자신들의 대시보드가 된다.

스펙트럼의 끝은 오래된 코드베이스와 많은 사용자를 가진 대규모 조직이다. 여기서는 모든 경고 수치가 그대로 직격탄이 된다. 중복된 헬퍼 함수는 스타일 문제가 아니라 미래의 버그 표면이자 수년간 복리로 쌓이는 유지보수 비용이다. 아무도 이해하지 못한 채 머지된 변경 사항은 이해 부채(comprehension debt)가 되어 결국 누군가의 온콜 인시던트로 돌아온다. 리뷰는 동시에 여러 가지 역할을 수행하는데, 에이전트 산출물의 볼륨이 그 모든 역할을 조용히 무너뜨린다. Faros가 성숙한 팀에 관해 발견한 내용은 정확히 이 지점을 겨냥하고 있다.

요점은 "엔터프라이즈는 신중해야 하고 1인 개발자는 긴장을 풀어도 된다"가 아니다. 리뷰의 목적 자체가 위치에 따라 달라지기 때문에 규칙도 함께 달라져야 한다는 것이다. 두 명짜리 프로토타입 팀에 엔터프라이즈의 엄격한 멀티 에이전트 검증 파이프라인을 그대로 붙이면 아무 이득 없이 마찰만 생긴다. 반대로 결제 시스템에 "테스트 통과, 배포"를 적용하면 녹색 체크마크를 달고 인시던트를 만들어내는 기계가 된다. 이 공간에서 나쁜 조언 대부분은 스펙트럼의 한쪽 끝에 있는 사람이 다른 쪽 끝에 있는 사람에게 처방을 내리는 것이다.

지금 코드 리뷰는 무엇을 위한 것인가

리뷰는 원래 작성자의 사고 과정을 확인하기 위해 설계됐다. 에이전트 코드에는 작성자도, 사고 과정도 없다. 그래서 리뷰는 이제 어떤 인간의 머릿속에도 존재한 적 없는 근거를 역으로 재구성해야 하는데, 이는 더 느리고 본질적으로 다른 작업이다.

이것이 진짜로 달라진 부분이고, 내 생각엔 아직 충분히 인식되지 못하고 있다.

인간이 코드를 작성할 때는 의도가 무료로 따라온다. 고려했다가 기각한 대안들, 그 모든 사고 과정이 작성자의 머릿속에 있었고, 리뷰는 그 사고를 확인하는 작업이었다. 에이전트가 작성한 코드에서 그 사고는 누구의 머릿속에도 존재한 적이 없다. 인간이 '왜'를 이해하고 코드로 옮긴 게 아니다. 리뷰는 조용히, 누군가의 사고를 확인하는 일에서 애초에 존재하지 않았던 사고를 재구성하는 일로 바뀌었다. 더 어렵고 더 느리다. 그러면서 시간이 441%나 더 걸린다는 사실에 계속 놀란다.

2026년 논문 AI Slop and the Software Commons는 개발자들이 "AI slop"을 논의한 레딧과 해커뉴스 스레드 15개의 게시물 1,154건을 분석했다. 한 개발자의 말이 머릿속을 떠나지 않는다. 에이전트의 PR을 리뷰하면서 자신이 "이 코드를 처음으로 눈에 담는 인간"이 된 느낌이었다는 것이다.

AI Slop and the Software Commons

이 표현은 곱씹을 가치가 있다. 평범한 리뷰에서는 작성자가 이미 변경 사항을 이해하고 있었고, 리뷰어는 그 작업을 확인하는 것이었다. 이제는 어떤 인간도 이해한 적 없는 PR이 존재하고, 리뷰어가 처음으로 이해를 시도하는 사람이 된다. 논문의 표현대로, 리뷰는 "사라진 의도를 복원하도록 만들어진 도구가 아니었다". 우리는 사고를 확인하기 위해 설계된 도구를 가지고 사고를 처음부터 만들어내는 데 쓰면서, 왜 느리냐고 불평하고 있다.

논문은 구조적인 함정도 잘 짚어낸다. 이 산출물은 표면적으로는 유능해 보이고, 생성하는 비용은 낮은 반면 검토하는 비용은 높으며, 제한 없이 만들어낼 수 있다. 이 세 가지가 합쳐져 공유 자원 모두를 갉아먹는다. 리뷰어의 주의가 먼저 닳고, 이어서 코드베이스 자체와 사람들 사이의 신뢰도 무너진다. 누군가의 생산성 향상 비용은 그 하류에 있는 모든 사람이 치른다.

그래서 "AI가 AI를 리뷰하게 하자"는 답의 절반밖에 되지 않는다. 다른 선입견을 가진 두 번째 모델이 실제 버그를 잡는 건 분명히 의미 있는 일이다. 하지만 이게 옳은 변경인지 판단하는 데 필요한 인간의 의도를 재구성하지는 못한다. 그 판단은 여전히 사람에게 남아 있고, GPU를 더 붙인다고 빨라지지 않는다.

도구는 훌륭하다, 다만 광고와는 다른 이유로

지금의 AI 리뷰 도구들은 실제로 훌륭하고, 서로 같은 줄을 지적하는 경우가 거의 없다. 그러니 최선의 도구 하나를 고르는 게 아니라, 서로 다르게 만들어진 두 가지를 함께 실행하는 것이 맞다.

전문 AI 리뷰 도구들은 이제 실력이 충분하다. 사이드 프로젝트를 포함해 모든 것에 최소 하나는 돌리는 게 좋다. CodeRabbit은 가장 널리 배포된 도구로, 독립적인 Martian 벤치마크(2026년 1~2월)에서 F1 기준 1위를 차지했다. 정밀도 약 49%에 업계 최고 재현율을 기록했다. Greptile은 정밀도 대신 재현율에 무게를 둔다. 한 벤치마크에서 버그 탐지율이 CodeRabbit의 44% 대비 약 82%였으나, 거짓 양성(false positive)이 더 많다는 단점이 있다. Anthropic의 Code Review는 엔지니어들이 발견 사항의 1% 미만을 오류로 표시했다고 보고했다. 내가 관리자에게 실제로 보여줄 수치는 따로 있다. 이 도구 덕분에 실질적인 리뷰를 받는 PR 비율이 내부적으로 16%에서 54%로 높아졌다. 예전에는 흘끗 보고 승인 도장을 찍었을 긴 꼬리의 변경 사항들이 이제는 제대로 읽힌다.

올해 내가 본 가장 유용한 결과는 벤더에서 나온 것이 아니다. 한 엔지니어가 리뷰어 네 개를 병렬로 실행했다. CodeRabbit, Sentry Seer, Greptile, Cursor BugBot을 3주 반 동안 실제 PR 146개, 발견 사항 679건에 대해 돌린 것이다.

식별된 고유 위치 617개 중 93.4%는 네 도구 중 정확히 하나에게만 발견됐다. 6%는 두 개에서 발견됐다. 세 개에서 발견된 건 거의 없었다. 네 개 모두에서 발견된 건 단 하나도 없었다.

네 도구는 단 한 번도 같은 줄을 동시에 지적하지 않았다. 각 도구는 서로 다른 종류의 문제에 강점을 보였다. Greptile은 정확성과 아키텍처에서 거짓 양성이 거의 없었고, CodeRabbit은 가장 넓은 그물을 치고 원클릭 수정을 제공했으며, Seer는 프로덕션 장애 심각도 판단에서 가장 뛰어났다. 이것이 논문이 아닌 실제 코드베이스에서 증명된 적대적 리뷰(adversarial review)의 논거다. 이질성이 핵심이다. 같은 모델 네 개는 청구서만 큰 단일 리뷰어일 뿐이지만, 진정으로 다른 리뷰어 네 개는 구성원 누구도, 인간 포함해서 혼자서는 찾아낼 수 없는 버그 집합을 표면으로 끌어올린다.

실용적인 조언을 하자면, 최선의 도구 하나를 고르려 애쓰지 마라. 그런 건 없다. 위험도가 높은 환경에서는 의도적으로 성격이 다른 두 가지를 함께 써라. 앞서의 실험은 일상적인 정확성 검토를 위한 Greptile과 프로덕션 장애 심각도를 위한 Seer를 조합했는데, 겹침이 거의 없었다. 혼자 작업한다면 좋은 리뷰 도구 하나에 실질적인 테스트를 더하는 것으로 충분하다. 그리고 마케팅 문구가 뭐라 하든, 자신의 코드로 직접 측정하라. 이 결과들은 모두 특정 코드베이스에서 나온 것이고, 당신의 코드베이스도 마찬가지일 것이다.

AI에게 리뷰를 더 맡겨야 할까?

이미 기계가 당신보다 더 많은 코드를 리뷰하고 있다. 남은 진짜 선택지는 그것을 의도적으로 할 것인지 여부뿐이며, 인간이 얼마나 개입할지는 영향 범위에 비례해 조정해야 한다.

1년 전이었다면 이단 취급을 받았을 질문을 이제 경험 많은 엔지니어들로부터 계속 듣는다. 기계가 리뷰를 더 많이, 어쩌면 대부분을 해야 하지 않을까? 나는 더 이상 이걸 어리석은 질문이라고 생각하지 않는다.

불편한 사실은 AI 리뷰가 효과적이라는 것이다. Anthropic의 발견 사항 중 오류 표시는 1% 미만이고, 인간이 그냥 넘기는 버그를 잡아내며, 하루에 서른 번째 PR에서도 지치지 않는다. 정확히 그 순간이 인간이 가장 믿음직스럽지 못한 때다. 반면 인간이 따라잡지 못하고 있다는 건 눈에 보인다. 리뷰 없는 머지가 31% 늘었고, 리뷰 시간은 세 자릿수로 늘었다. 실질적으로 기계가 이미 인간보다 더 많은 코드를 리뷰하고 있다. 솔직한 질문은 "AI에게 더 맡겨야 하는가"가 아니라 "AI가 이미 하고 있는데, 우리가 의도적으로 할 것인가, 아니면 인간이 여전히 다 읽는 척하면서 그냥 흘러가게 둘 것인가"다.

루프 엔지니어링(loop engineering)은 이 문제를 더 날카롭게 만든다. 루프의 전제는 에이전트에게 직접 프롬프트를 입력하는 사람이 아니라, 에이전트에게 프롬프트를 넣는 시스템을 만드는 사람이 되는 것이다. 그 시스템의 핵심 요소는 판단자(judge), 즉 다음으로 넘어가기 전에 작업이 완료됐는지 판단하는 에이전트다. 리뷰어는 지금 의도적으로 내부 루프에서 설계되어 나가고 있는 다음 역할이다. 1년을 작성을 자동화하는 데 썼고, 이제 루프는 확인까지 자동화하고 있다. 인간은 계속 위로, 바깥으로 밀려난다. "인간이 어디에 남는가"는 세미나 주제가 아니다. 루프를 설계할 때마다 내리는 결정이고, 자신이 결정하고 있다는 사실을 인식하든 못 하든 그렇다.

루프 엔지니어링(loop engineering)

지금 내가 잠정적으로 내린 결론, 다만 느슨하게 쥐고 있는 것은 이렇다. "인간이 모든 줄을 읽는다"는 건 끝났다. 볼륨이 그걸 끝냈고, 아직도 그렇다고 주장하는 사람은 더 이상 존재하지 않는 세계를 묘사하는 것이다. 그렇다고 "루프가 스스로 리뷰하게 하고 자리를 뜬다"도 아니다. 에이전트가 코드를 작성하고, 다른 에이전트가 리뷰하고, 세 번째가 판단한다면, 당신에겐 대체로 같은 데이터로 학습됐고, 같은 맹점을 공유하며, 같은 곳에서 자신 있게 틀리는 모델들의 닫힌 루프가 생긴다. 어디에도 인간이 없는 자신감 넘치는 "괜찮아 보입니다"는 빌린 자신감(borrowed confidence)이다. 시스템의 확신이 당신의 확신이 되고, 실제로는 아무도 아무것도 이해하지 못한 것이다. 루프는 매우 확신에 차 있으면서 동시에 매우 틀릴 수 있고, 그 차이를 알아챌 인간이 남아있지 않다.

그러니 인간이 사라지는 게 아니라, 인간이 한 단계 위로 이동한다. 모든 diff를 리뷰하는 것을 멈추고, 모델에게 넘길 수 없는 영역을 맡는다. 새벽 3시에 모델을 호출할 수 없기 때문에 필요한 책임감. 코드가 올바른지와는 별개로, 이게 과연 만들어야 할 변경인지에 대한 판단. 틀렸을 때 대가가 큰 고위험 관문. 그리고 불편한 마지막 하나, 아무도 명세하지 않은 동작이다. 모델은 존재하는 코드를 리뷰하고, 아무도 쓰지 않은 요구사항은 절대 지적하지 않는다. 이 부분은 인간의 형태를 한 빈틈(human-shaped gap)으로 당분간 닫힐 것 같지 않다. 루프 안의 인간은 루프 위의 인간이 된다. 모든 PR을 읽는 대신 시스템을 샘플링하고, 발췌 점검하고, 감사한다. 그리고 틀렸을 때 실제로 아픈 곳에 한정된 주의를 집중한다.

이게 이미 내 작업 방식이다. 하루에 들어오는 PR이 저녁에 꼼꼼히 읽을 수 있는 양을 훌쩍 넘어버린 오픈소스 프로젝트들을 포함해서. 나는 들어오는 PR 묶음에 Claude Code나 Codex를 붙여 1차 검토를 요청한다. 무난히 머지해도 될 것, 더 작업이 필요한 것, 실제로 위험한 것을 큰 그림에서 읽어달라고. 결과물을 자동 머지하지 않고, 승인된 것을 대충 머지하지도 않는다. 이게 내게 주는 건 주의를 배분하는 방법이다. 저위험으로 분류된 변경들은 몇 분 만에 확인하고, 위험하다고 표시된 것들에는 진짜 신중한 시간을 쓴다. 중요한 건 이게 내 예전 리뷰 시간을 조금 빠르게 만든 게 아니라는 것이다. 모양 자체가 달라진 시간이다. 지금 내가 처리하는 볼륨에서, 이 방식이 큐를 감당 가능하게 유지하는 주된 이유다.

Claude Code(왼쪽)와 Codex(오른쪽)가 PR 묶음을 위험도 순으로 1차 정리해준 결과. 트리아지가 핵심 도움이고, 머지 결정은 내가 내린다.

같은 방식의 더 극단적인 사례가 있다. 전직 메타 L8 엔지니어 Kun Chen은 현재 1인 빌더로 하루 약 40개의 PR을 만들며 코드 리뷰를 거의 하지 않는다. 무시하기 쉬운 이야기처럼 보이지만, 그가 L8이라는 사실, 즉 그만두기로 한 바로 그 일을 이례적으로 잘하는 사람이라는 점이 흥미롭게 만든다. 그는 에이전트 20~30개를 병렬로 돌리고, 계획을 세우는 데 노력을 집중한다. 상세한 계획을 앞서 작성하고, 에이전트들이 그에 맞춰 몇 시간씩 돌아간다. 계획의 품질이 에이전트가 무감독으로 얼마나 오래 실행될 수 있는지를 결정한다고 그는 말한다. 이것이 앞서 설명한 방식의 가장 순수한 형태다. 실제로 무슨 일이 일어난 건지 정확히 짚을 필요가 있다. 그가 검증을 멈춘 게 아니기 때문이다. 의도가 사라진 게 아니라, 그가 계획에 직접 써넣었다. "이 코드를 처음으로 눈에 담는 인간" 문제가 절반은 해결됐다. 인간이 '왜'를 이해한 것은 맞고, 다만 코드가 작성된 후가 아니라 전에 이루어진 것이다. 그리고 그는 안전망 없이 작업하지 않았다. 코드가 머지되기 전에 확인하는 자동화 리뷰 관문(그는 No Mistakes라고 부른다)을 만들었고, 에이전트가 막힐 때를 위한 에스컬레이션도 유지한다. 인간은 코드가 생기기 전에 값비싼 사고를 하고, 기계는 그 후 줄 단위로 처리한다. 이것이 앞으로의 방향이 될 모양새일 수도 있다.

하지만 그는 대규모 팀도 없고, 지뢰밭 같은 10년 된 시스템도 없는 1인 빌더다. 그에게 하루 40개의 PR을 리뷰 없이 만드는 것을 합리적으로 만드는 조건들이 대부분의 독자에게는 없다. 그의 워크플로우를 많은 사용자에게 배포하는 팀에 그대로 복사하면 자신의 대시보드에서 Faros 수치를 재현하게 된다. 그가 틀린 게 아니다. 스펙트럼의 한쪽 끝으로 아주 멀리 내려간 것이다.

결국 스펙트럼 이야기다. 사용자 없는 1인 개발자라면 AI가 거의 모든 것을 리뷰하게 두는 것이 2026년 기준 충분히 방어 가능한 선택이고, 죄책감을 가질 필요 없다. 많은 사람을 위해 대규모 시스템을 유지보수한다면 기계에게 1차, 2차, 지루한 90%를 맡기되, 핵심 경로에는 실제 인간을 두고, 누군가를 다치게 할 수 있는 것에는 루프를 완전히 닫지 마라. 인간을 얼마나 남길지는 조절 가능한 다이얼이며, 죄책감이 아닌 영향 범위에 따라 설정하는 것이다.

실제로 무엇을 해야 하는가

모든 것을 같은 깊이로 리뷰하는 것을 멈춰라. 부족한 인간의 주의력은 오직 틀렸을 때 대가가 큰 곳에만 쓰고, 나머지는 저렴한 결정론적 관문과 AI 리뷰어에게 맡겨라.

핵심 원칙은 리뷰 노력을 틀렸을 때의 비용과 맞추고, 저렴하고 결정론적인 작업을 가능한 한 앞단에 배치하며, 인간만이 할 수 있는 것에 인간의 주의를 아껴두는 것이다.

작성자가 아닌 위험도에 따라 단계를 나눠라. 설정 파일 변경에는 린터와 훑어보기면 충분하다. 결제 경로에는 전체 스택이 필요하다. 타입 검사, 테스트, 성격이 다른 AI 리뷰어 두 개, 해당 시스템의 담당자, 보안 검토까지. 보일러플레이트에 무거운 리뷰를 낭비하지 말고, 테스트가 녹색이라고 인증 변경을 그냥 통과시키지 마라. 계층적 접근 방식은 어디서나 동일하다. 달라지는 건 특정 diff가 얼마나 많은 계층을 통과해야 하는지다.

비용이 큰 꼬리를 빠르게 걸러내라. 에이전트 PR 홍수에 허덕이는 팀에게 가장 유용한 최근 연구는 Early-Stage Prediction of Review Effort(2026년 1월)다. 에이전트가 작성한 PR 3만 3,707개를 분석한 결과다. 에이전트는 작고 명확하게 정의된 변경에 강해서 약 28%는 거의 즉시 머지된다. 하지만 주관적인 피드백이 오는 순간 "사라져버리는" 경향이 있다. 리뷰가 실제로 요구하는 주고받기를 포기하는 것이다. (2026년 동반 논문은 리뷰어 이탈이 거절된 에이전트 PR의 38%를 차지한다는 것을 발견했다.) 연구진은 인간이 보기 전에 파일 유형과 패치 크기 같은 저렴한 신호들로 고유지보수 PR을 예측하는 "서킷 브레이커"를 만들었고, 효과가 좋았다. 에이전트 PR은 앞단에서 트리아지하고, 간단한 것은 빠르게 처리하며, 막히는 순간 에이전트가 포기할 복잡한 변경에 사람이 한 시간을 쏟지 않도록 하라.

리뷰할 대상의 기준을 높여라. 쌓인 PR에서 벗어나는 방법은 저장소를 잠그는 게 아니라, 근거 없이 들어온 변경은 리뷰를 거부하는 것이다. 리뷰 전에 다음을 요구하라. 이 변경이 무엇을 위한 것인지에 대한 설명, 주석도 없이 3,500줄이 아닌 diff, 테스트 결과, 그리고 실제로 실행했다는 증거. 이것이 당신이 코드를 처음으로 읽는 인간이 되지 않는 방법이다. 의도 재구성 작업을 제출한 사람에게, 즉 비용이 낮은 곳으로 돌려보내는 것이다. 당신이 흡수하면 비용이 높아진다.

PR을 의도적으로 작게 유지하라. 에이전트 PR은 크게 나오는 경향이 있다. Faros 데이터에서 평균 51% 더 크다. 그리고 리뷰어 참여도는 PR이 머지되는지를 예측하는 가장 강력한 지표 중 하나다. 크고 리뷰하기 어려운 PR은 그냥 거절되거나, 더 나쁘게는 눈도장만 찍힌다. 에이전트에게 작은 커밋을 만들도록 지시하라. 인간이 실제로 읽을 수 있는 diff는 이제 배려가 아닌 설계 제약이다.

코드보다 테스트 변경을 더 꼼꼼히 읽어라. 이게 에이전트의 대표적인 실패 패턴이다. 에이전트가 동작을 변경하고, 깨진 새 동작에 맞춰 어설션을 다시 써서 테스트를 "고친다". 200개의 편집된 테스트 위에 녹색 체크는 그 편집이 올바른지 확인하기 전까지 아무 의미가 없다. 테스트를 대거 다시 쓰는 diff는 경고 신호로 보고 그것부터 읽어라. 뮤테이션 테스팅이 여기서 제 역할을 한다. 커버리지는 어떤 줄이 실행됐는지 알려주고, 뮤테이션 테스팅은 그 줄이 틀렸을 때 테스트가 알아챌 수 있는지를 알려준다.

CI를 움직이지 않는 벽으로 취급하라. GitHub이 리뷰어들에게 경고하는 패턴들을 주목하라. 삭제된 테스트, 건너뛴 린트, 낮아진 커버리지 임계값, 이미 다른 곳에 존재하는 중복 헬퍼, 그리고 신뢰할 수 없는 입력이 프롬프트로 흘러들어가는 것. 마지막 것은 특별히 강조할 필요가 있다. 에이전트가 만든 기능은 프롬프트 인젝션의 새로운 원천이기 때문이다. 사용자가 제어하는 텍스트를 LLM 호출에 파이프하면서 그 텍스트가 모델에게 무엇을 지시할 수 있는지 생각하지 않는다면, 취약점은 diff에서 보이지 않는다. 나중에 도착할 데이터 속에 잠재해 있다. 에이전트는 자신을 통과시키기 위해 CI를 약화시키기도 한다. 악의는 없다. 그냥 그래디언트 디센트가 녹색으로 가는 가장 싼 경로를 찾는 것이다. 결정론적 관문은 자신 있는 단락에 설득당하지 않는 파이프라인의 유일한 부분이므로, 엄격하게 유지하라.

머지는 인간이 책임진다. 모델은 호출할 수 없고, 배포한 것에 책임을 질 수 없다. 그러니 머지 버튼을 누르는 사람이 그것을 소유한다. AI 리뷰가 차분하고 자신 있는 목소리로 "괜찮아 보입니다"라고 할 때, 그것은 반드시 벌었다고 할 수 없는 자신감을 당신에게 건네는 것이다. 모든 AI 리뷰를 판결이 아닌 센서로 다뤄라. 결정이 아닌 데이터다.

사용자 없이 혼자 작업한다면, 위험도 단계 구분, 테스트 변경 규율, CI가 필요한 것의 대부분이다. 나머지는 사람들이 생기기 전까지 오버헤드다. 대규모 조직이라면 이 모든 것이 기본이고, 트리아지와 접수 기준이 확장 가능한 리뷰 프로세스와 조용히 무너지는 것 사이의 차이다.

팀을 이끈다면

병목은 더 이상 코드를 얼마나 빨리 쓰느냐가 아니라, 신뢰할 수 있는 인간이 리뷰에 얼마나 빠르게 확신을 가질 수 있느냐다. "AI 덕분에 빨라졌으니"라는 이유로 그 확신을 제공하는 사람들을 줄이는 것은 단순히 절감액을 미래의 인시던트로 전환하는 것이다.

배포의 실질적인 제약은 더 이상 코드를 얼마나 빨리 쓰느냐가 아니다. 신뢰할 수 있는 인간이 변경 사항이 올바르다고 확신하는 데 걸리는 시간이다. 생성을 병목으로 보고 리뷰를 공짜로 취급하는 계획은 속도 대시보드가 녹색을 유지하는 동안 천천히 가라앉는 계획이다.

Faros 보고서는 이 점에서 직접적이다. 산출량이 늘어도 QA와 리뷰 작업도 같이 늘기 때문에, 리뷰 격차를 먼저 메우지 않고 "AI 덕분에 빨라졌다"는 이유로 엔지니어링 인원을 줄이는 것은 위험하다. 시니어 엔지니어가 부담하는 리뷰 시간, 세 자릿수로 늘어난 그 시간은 가장 병목이 되어서는 안 되는 사람들에게 가장 무겁게 떨어진다. 그리고 머지된 PR 수만 세는 지표에는 보이지 않는다.

오픈소스 메인테이너들이 이 벽에 가장 먼저, 가장 세게 부딪혔다. 그럴듯해 보이지만 속이 빈 기여들의 꾸준한 흐름은 선의로 만들어졌더라도 실제 트리아지 시간을 소비한다. 이게 카나리아다. 기업들이 다음이다. 잘 대처하는 곳들은 리뷰 역량을 AI가 풀어준 여유가 아니라, 측정하고 보호하고 의도적으로 써야 할 실제 자원으로 취급한다.

작성은 저렴해졌고, 이해는 그러지 않았다

에이전트가 등장했다고 코드 리뷰가 덜 중요해진 게 아니다. 오히려 핵심 활동이 됐다. 코드 작성은 갈수록 해결된 문제가 되어가고 달마다 더 저렴해지는 반면, 오래가는 경쟁력은 작성된 것을 신뢰할 수 있게 만드는 시스템이다.

어느 방향으로도 획일적인 답을 따르지 마라. 사용자 없이 혼자라면, 엔터프라이즈의 churn과 중복에 관한 공포 이야기는 오늘의 불이 아니라 미래의 위험이다. 테스트에 기대고, 중요한 것을 리뷰하되, 미뤄진 작업이 여전히 빚으로 남아있다는 것을 솔직하게 인정하라. 많은 사람을 위해 큰 것을 유지보수한다면, 여기 있는 모든 경고 수치가 당신 이야기이고, 버티는 것은 계층화되고 증거를 요구하며 의도적으로 이질적인 리뷰 프로세스, 그리고 머지를 소유하는 인간뿐이다.

스펙트럼 전체에 걸쳐 변하지 않는 건 근본적인 경제학이다. 우리는 작성을 저렴하게 만들었고, 이해는 언제나 그랬던 것과 정확히 같은 비용으로 남아있다. 앞으로 몇 년간 잘하는 팀은 코드를 가장 많이 생성하는 팀이 아니라, 실제로 신뢰할 수 있는 리뷰 시스템을 만들고, "테스트가 통과됐다"와 "사람이 이것이 무엇을 하는지, 왜 하는지 이해했다"를 절대 혼동하지 않는 팀이 될 것이다. Simon Willison이 계속 말하는 것처럼, 당신의 역할은 작동한다고 증명한 코드를 전달하는 것이다. 에이전트는 그것을 바꾸지 않았다. 그들은 증명하는 것 자체를 일 전부로 만들었다.