Hacker News가 코드 리뷰를 도마 위에 올렸다. AI는 병목을 외면할 수 없게 만들었다

이번 주 Hacker News에서는 날카로운 충돌이 드러났다. AI는 코드를 더 빠르게 생성하지만, 숙련된 엔지니어는 여전히 사람의 속도로만 변경 사항을 검토한다. 이 논의는 Thoughtworks CTO Rachel Laycock이 풀 리퀘스트를 소프트웨어 개발의 중심으로 여기는 관행을 멈춰야 한다고 주장하면서 시작됐다.

그의 입장은 단순히 반복 검사를 자동화하자는 것보다 더 급진적이다. Laycock은 팀이 설계 판단, 지식 공유, 아키텍처 논의를 개발 프로세스의 더 이른 단계로 옮겨야 한다고 본다. 사람의 리뷰는 계속 남지만, 지연을 감수할 만한 가치가 있는 변경에만 적용된다.

이는 보다 보수적인 AI 리뷰 전략과 대립한다. 이 접근법은 자동화로 일상적인 작업을 걸러내고 위험을 식별하면서도 사람의 승인을 유지한다. 양측 모두 과부하가 걸린 동일한 리뷰 대기열을 보고 있다. 다만 그 대기열을 고칠 것인지, 아니면 많은 변경을 대기열에서 아예 제외할 것인지를 두고 의견이 다르다.

Hacker News 토론은 깨진 방정식에서 시작됐다

AI는 코드 생산량을 늘렸지만, 자격을 갖춘 리뷰어의 관심을 더 만들어내지는 못했다.

논쟁은 이 이야기가 Hacker News에 올라오기 전부터 시작됐다. 개발자 인텔리전스 기업 DX의 Brian Houck은 AI가 이미 부담을 받고 있던 리뷰 프로세스의 약점을 드러냈다고 주장했다.

그의 우려는 소프트웨어 생산 방식에서 측정 가능한 변화에 근거한다. Meta의 2026년 RADAR 연구는 사람이 실제 반영한 diff당 유의미한 코드 라인이 연간 105.9% 증가했다고 보고했다. 개발자 1인당 diff 규모는 51% 늘었다.

이 논문은 해당 성장의 80% 이상을 에이전트형 AI에 기인한다고 분석했다. 이 맥락에서 에이전트형 시스템은 제한된 사람의 개입만으로 여러 단계의 코딩 작업을 완료하는 시스템이다.

DX의 별도 연구는 2026년 2분기에 400개 이상의 조직을 조사했다. AI 코드 분석은 대규모 사람의 재작성 없이 AI가 작성한 코딩 작업의 비율이 51.9%에 달한다고 추정했다.

이 수치는 자기보고 데이터에서 나온 것이므로, 생성된 모든 코드 라인을 문자 그대로 측정한 결과로 받아들여서는 안 된다. DX는 이를 위임된 코딩 작업의 추정치로 제시했다.

같은 분석에 따르면, 풀 리퀘스트의 중앙값 크기는 2025년 7월 44줄에서 2026년 6월 72줄로 증가했다. 1년 사이 약 64% 성장한 셈이다.

이러한 변화는 불리한 비율을 만든다. 코드는 더 빠르게 도착하고, 개별 리뷰 단위는 더 커지며, 관련 시스템 지식을 지닌 엔지니어의 공급은 여전히 제한적이다.

AI 코딩 도구는 구현 시간을 몇 시간에서 몇 분으로 줄일 수 있다. 그러나 익숙하지 않은 아키텍처 결정을 평가하는 데 필요한 맥락을 리뷰어에게 자동으로 제공할 수는 없다.

그 결과 생기는 대기열은 단순한 불편이 아니다. 지연된 리뷰는 작성자의 작업을 끊고, 리뷰어가 맥락을 다시 복구하게 하며, 결정과 수정 사이의 거리를 늘린다.

Houck은 사람의 리뷰가 여러 기능을 동시에 수행하므로 이를 보호해야 한다고 주장한다. 리뷰는 결함을 발견하고, 지식을 확산하며, 엔지니어를 교육하고, 공동 책임을 만들어낼 수 있다.

Laycock도 이러한 목표는 받아들인다. 그러나 9월 2일 공개된 그의 코드 리뷰 주장은 풀 리퀘스트가 이를 전달해야 한다는 가정에 이의를 제기한다.

그의 핵심 질문은 간단하다. 가장 중요한 결정을 논의하기 전에 왜 구현이 완료될 때까지 기다려야 하는가?

이 질문은 익숙한 생산성 불만을 프로세스에 대한 도전으로 바꿨다. 문제는 더 이상 AI가 과도한 코드를 만든다는 데만 있지 않다. 더 깊은 문제는 팀이 사람의 판단을 어디에 배치하느냐다.

풀 리퀘스트는 대개 누군가 접근 방식을 선택하고, 구현을 작성하며, 통합할 변경을 준비한 뒤에 등장한다. 리뷰어는 이미 여러 중요한 선택이 굳어진 후에 참여한다.

그 시점에서 설계에 이의를 제기하는 일은 사회적으로도 경제적으로도 부담이 크다. 리뷰어는 수정을 요청할 수 있지만, 대규모 변경은 이미 완료된 작업을 버리는 일을 뜻한다.

이 구조는 근본적인 대안 대신 국지적 세부 사항에 대한 코멘트를 부추긴다. 팀은 더 큰 설계를 관성적으로 받아들이면서 이름 짓기, 서식, 작은 로직 선택을 논의할 수 있다.

Hacker News 논의가 중요한 이유는 리뷰에 대한 두 가지 서로 다른 정의를 드러내기 때문이다. 하나는 리뷰를 필수 검사 단계로 본다. 다른 하나는 리뷰를 협업적 추론이 일어날 수 있는 여러 장소 중 하나로 본다.

이 차이는 제안되는 모든 해결책의 방향을 결정한다.

풀 리퀘스트는 너무 많은 문제를 담는 그릇이 됐다

현대의 코드 리뷰는 하나의 비동기 체크포인트가 애초에 감당하도록 설계되지 않은 책임을 떠안고 있다.

코드 리뷰는 품질 관리 관행으로 시작됐지만, 팀은 점차 훨씬 더 넓은 역할을 부여했다. 이제 풀 리퀘스트는 결함 검사, 보안 관문, 멘토링 세션, 아키텍처 기록의 역할을 모두 수행할 수 있다.

또한 규정 준수의 증거, 인접 팀을 위한 알림 시스템, 공동 소유권의 최종 표현으로도 작동할 수 있다. 어느 한 기능에서 실패해도 리뷰어 또는 검사를 하나 더 추가해야 한다는 압력이 생긴다.

연구는 오래전부터 리뷰가 결함 탐지를 넘어선 결과를 낳는다는 점을 보여 왔다. Microsoft의 현대적 리뷰 연구는 개발자 17명을 관찰하고 리뷰 댓글 570개를 분류했다.

연구진은 관리자 165명과 프로그래머 873명도 설문조사했다. 그 결과 결함 관련 댓글은 실제 리뷰 활동에서 비교적 작은 비중을 차지했다.

개발자들은 리뷰를 통해 변경을 이해하고, 대안적 해결책을 탐색하며, 지식을 공유하고, 팀원의 작업에 대한 인식을 유지했다. 맥락과 변경 사항에 대한 이해는 효과적인 리뷰의 핵심이었다.

이런 이점은 실제로 존재하지만, 그것만으로 풀 리퀘스트가 최선의 전달 수단이라는 점이 증명되지는 않는다. 이는 조직이 현재 리뷰에 의존해 달성하는 일이 무엇인지만 보여 준다.

Laycock의 전환은 여기서 시작된다. 그는 가치 있는 피드백이 그 피드백이 뒷받침할 결정을 내리는 시점에 더 가까이 이동해야 한다고 주장한다.

대안적 해결책은 하나의 해결책이 완전히 구현되기 전에 논의돼야 한다. 생성된 코드가 하나의 결정을 수십 개 파일에 걸쳐 퍼뜨리기 전에 아키텍처 경계를 합의해야 한다.

지식 이전은 숙련된 엔지니어가 문제를 추론하는 동안 이뤄져야 한다. 주니어 엔지니어는 완료된 diff를 나중에 읽는 것보다, 트레이드오프가 전개되는 과정을 보면서 더 많이 배운다.

페어 프로그래밍은 하나의 경로를 제공한다. 두 명의 엔지니어가 의사결정, 구현 맥락, 즉각적인 피드백을 공유하며 같은 작업을 함께 진행한다.

몹 프로그래밍은 이 패턴을 그룹으로 확장한다. 집단 설계 세션도 누군가 코드를 작성하거나 에이전트에게 코드 작성을 지시하기 전에 비슷한 목표를 달성할 수 있다.

이러한 접근법에는 시간이 필요하지만, 코드 리뷰도 이미 시간을 소비한다. 차이는 조직이 그 비용을 언제 지불하는지, 그리고 대화가 여전히 저렴하게 설계를 바꿀 수 있는지에 있다.

자동화된 검사는 결정론적인 문제를 처리해야 한다. 서식, 린트 위반, 알려진 취약 의존성, 재현 가능한 테스트 실패에는 부족한 시니어의 판단이 필요한 경우가 드물다.

피트니스 함수는 아키텍처 제약을 실행 가능한 테스트로 인코딩할 수 있다. 피트니스 함수는 시스템이 의도한 아키텍처 특성을 보존하는지 지속적으로 확인한다.

예를 들어, 팀은 한 서비스가 다른 서비스의 비공개 컴포넌트를 import하지 못하도록 할 수 있다. 이 검사는 리뷰어가 변경을 받기 전에 실행된다.

정적 분석은 프로그램을 실행하지 않고도 정의된 버그 패턴을 탐지할 수 있다. 보안 스캐너는 알려진 취약점, 노출된 시크릿, 의존성 위험을 식별할 수 있다.

이러한 시스템 중 어느 것도 엔지니어링 판단을 없애지는 않는다. 대신 예측 가능한 작업을 제거해 사람이 모호성, 시스템 동작, 비즈니스 영향에 집중하게 한다.

이 접근법은 엔지니어링 팀이 문서화하는 방식도 바꾼다. 풀 리퀘스트 댓글은 유용하지만, 수백 건의 병합된 변경을 거쳐 몇 달 후 이를 재구성하기는 어렵다.

중요한 설계 추론은 오래 보존되고 검색 가능한 기록에 담겨야 한다. 팀은 설계 문서, 기술 토론, 로컬 프로젝트 자료를 바탕으로 엔지니어링 지식 베이스를 구축할 수 있다.

목표는 문서 자체를 위한 문서를 더 만드는 것이 아니다. 향후 유지보수 담당자가 장애, 마이그레이션, 재설계 중에 필요한 의도를 보존하는 일이다.

풀 리퀘스트가 그 의도가 존재하는 유일한 장소라면, 자동화는 배포 지표를 개선하면서 조직의 기억을 의도치 않게 지워버릴 수 있다.

진정한 대립은 전수 리뷰와 예외 기반 리뷰 사이에 있다

핵심 선택은 모든 변경이 사람의 검사를 받아야 하는지, 아니면 명시적인 위험 임계값을 넘는 변경만 받아야 하는지다.

Laycock은 코드 리뷰를 끝내자고 제안하지 않는다. 그는 예외 기반 리뷰를 제안한다.

이 모델에서 팀은 또 다른 숙련된 사람이 구현을 검사해야 하는 상황을 식별한다. 근본적인 아키텍처 변경은 여전히 분명한 후보이다.

민감한 보안 경계를 넘는 변경은 사람의 주의를 받아야 한다. 핵심 시스템 내부에서 이뤄지는 익숙하지 않은 수정과 잠재적 영향 범위가 큰 변경도 마찬가지다.

불확실성 자체가 리뷰의 계기가 될 수 있다. 작성자나 팀이 확신하지 못한다면, 그 신호만으로도 또 다른 정보에 밝은 관점을 요청하기에 충분해야 한다.

일상적이고 범위가 명확한 변경은 다른 경로를 따른다. 자동화된 테스트, 정적 분석, 정책 검사, 명시적인 아키텍처 규칙이 통합 전에 신뢰를 구축한다.

이는 전수 리뷰에 대한 직접적인 도전이다. 많은 조직은 위험도, 새로움, 복잡성과 관계없이 모든 풀 리퀘스트에 승인을 요구한다.

전수 리뷰는 단순한 정책을 제공한다. 설명하고, 측정하고, 리포지터리 설정을 통해 강제하기 쉽다.

그러나 정책 수준의 단순함은 리뷰어에게 무차별적인 수요를 만들 수 있다. 의존성 업데이트와 새로운 권한 부여 모델이 모두 같은 넓은 대기열로 들어간다.

팀은 흔히 비공식적인 우선순위 조정으로 이를 보완한다. 작은 변경은 빠르게 승인되고, 어려운 변경은 이를 이해하는 소수의 사람을 기다린다.

이 패턴은 의례로 퇴화할 수 있다. 대기열이 속도를 요구하기 때문에 리뷰어는 피상적인 검사 뒤에 일상적인 작업을 승인한다.

초록색 체크 표시는 여전히 남아 있지만, 정보로서의 가치는 떨어진다. 필수 승인이 리뷰어가 변경을 이해했다는 보장은 아니다.

예외 기반 리뷰는 더 나은 위험 분류를 요구한다. 팀은 어떤 시스템, 파일, 변경 유형, 행동 신호가 더 강한 검토를 받아야 하는지 정의해야 한다.

또한 일상적인 것으로 분류된 변경을 통해서도 실수가 유입될 수 있음을 받아들여야 한다. 어떤 임계값도 위험을 없애지는 못한다.

Meta의 RADAR 시스템은 상당한 규모에서 이 모델을 구현한 사례를 보여 준다. RADAR는 Risk Aware Diff Auto Review의 약자다.

이 시스템은 적격성 게이트, 정적 휴리스틱, 머신러닝 위험 점수, 대규모 언어 모델 리뷰, 결정론적 검증을 사용한다. 자격을 갖춘 저위험 변경만 자동 반영 절차를 거친다.

Meta의 연구에 따르면 RADAR는 535,000개 이상의 diff를 검토하고 331,000개 이상을 반영했다. 저자들은 적격 자동 변경에서 되돌리기와 프로덕션 인시던트 비율이 더 낮았다고 보고했다.

이 연구는 RADAR가 검토한 diff의 되돌리기 비율이 비-RADAR diff의 3분의 1이었다고 밝혔다. 보고된 프로덕션 인시던트 비율은 50분의 1 수준이었다.

이러한 비교는 신중하게 해석해야 한다. RADAR는 의도적으로 저위험에서 중간 위험의 변경을 선택하는 반면, 비교 그룹에는 더 어렵고 위험한 작업이 포함된다.

따라서 낮은 사고율이 동등한 변경에 대해 자동화가 사람의 검토보다 안전하다는 증거는 아니다. 이는 제약된 자동화가 관찰된 결과가 유리한, 선별된 대상군을 처리할 수 있음을 보여줄 뿐이다.

이 구분은 필수적이다. 예외 기반 검토는 적격성 규칙이 일상적인 작업을 신뢰성 있게 식별할 때만 성공한다.

팀은 헤드라인의 결과만 가져와 광범위한 사람 승인을 제한 없는 AI 검토자로 대체할 수 없다. Meta의 배포는 여러 통제 장치, 광범위한 내부 텔레메트리, 신중하게 조정된 임계값을 사용한다.

규모가 작은 조직은 변경 위험을 추정할 만큼 충분한 과거 데이터를 갖추지 못했을 수 있다. 자동화된 테스트가 더 적거나 운영 신호가 더 약할 수도 있다.

가장 중요한 교훈은 모든 기업이 자체 RADAR를 구축해야 한다는 것이 아니다. 선택적 자동화에는 명시적인 경계와 근거가 필요하다는 점이다.

판단을 앞당기면 압박을 받는 주체도 바뀐다

시니어 엔지니어는 여전히 제약 요인이지만, 그들의 업무는 결과물을 검사하는 일에서 의사결정을 설계하는 일로 이동한다.

전면적 검토는 압박을 구현의 마지막 단계에 집중시킨다. 작성자는 기다리고, 검토자는 맥락을 전환하며, 변경 사항은 지식 있는 유지보수 담당자 뒤에 쌓인다.

예외 기반 검토는 그 압박의 일부를 더 이른 단계로 옮긴다. 시니어 엔지니어는 설계 세션에 참여하고, 경계를 정의하며, 자동화된 통제를 개선해야 한다.

이는 공짜로 생기는 여력이 아니다. 여력을 사용하는 방식이 달라지는 것이다.

이 전환은 초기 협업이 재작업을 막고 재사용 가능한 제약을 만들 때 효과가 있다. 하나의 아키텍처 규칙은 반복적인 설명 없이도 이후의 많은 변경을 이끌 수 있다.

모든 작업에 긴 설계 회의가 붙으면 실패한다. 판단을 앞당긴다고 해서 가벼운 변경까지 위원회식 의사결정으로 만들어서는 안 된다.

팀에는 비례에 맞는 관행이 필요하다. 작고 익숙한 변경이라면 명확한 의도 설명과 통과한 검사만으로 충분할 수 있다.

새로운 데이터 모델에는 짧은 설계 논의가 필요할 수 있다. 여러 시스템에 걸친 권한 부여 변경에는 더 폭넓은 검토와 명시적인 위협 분석이 필요할 수 있다.

이러한 비례성은 전면적 승인 규칙보다 어렵다. 엔지니어링 리더가 시스템을 이해하고 신뢰할 수 있는 위험 범주를 설정해야 하기 때문이다.

이는 개인 기여자에 대한 기대도 바꾼다. 작성자는 구현 전에 의도를 설명할 책임을 지며, 완료된 파일을 나중에 설명하는 데 그쳐서는 안 된다.

검토자는 초기에 가정을 질문할 책임을 진다. 불명확한 설계를 마지막 pull request가 구해줄 것이라고 기대할 수 없다.

관리자에게도 또 다른 압박 지점이 있다. 생성된 결과물이 검토 부담과 장기적인 복잡성을 늘리더라도 처리량 지표는 코드량에 보상할 수 있다.

완료된 pull request 수를 세는 방식은 유지보수 담당자에게 전가된 비용을 숨길 수 있다. 생성된 코드 줄 수를 측정하면 과도한 구현이 생산적으로 보일 수 있다.

AI는 여기서 특히 강한 유혹을 만든다. 특히 프롬프트가 아키텍처 제약 없이 결과만 지정할 경우, 도구는 문제 해결에 필요한 것보다 더 많은 코드를 생성할 수 있다.

더 큰 변경은 검토, 테스트, 되돌리기가 더 어렵다. 또한 미묘한 불일치가 발생할 수 있는 표면적도 넓어진다.

따라서 관련 있는 생산성 단위는 생성된 코드가 아니다. 팀이 여전히 이해하고 운영할 수 있는, 안전하게 제공된 기능이다.

2025년 Microsoft의 개발자 업무 주간 연구는 소프트웨어 개발자 484명을 조사했다. 연구는 이상적인 업무 배분과 실제 업무 배분 간 격차가 클수록 생산성과 만족도가 낮아지는 상관관계가 있음을 발견했다.

이 연구가 예외 기반 검토를 처방한 것은 아니다. 다만 개발자가 가치 있다고 여기는 업무에서 시간을 빼앗아 배분하는 비용을 뒷받침한다.

반복적인 검토를 제거하는 일은 도움이 될 수 있다. 단, 조직이 그 관심을 설계, 테스트, 공동 이해에 다시 투자할 때에만 그렇다. 그렇지 않으면 추가적인 코드 생산을 위한 여력만 늘리게 된다.

도구 공급업체도 압박을 받는다. 더 많은 의견을 내놓는 AI 검토자는 의사결정을 개선하지 못한 채 활동량만 늘릴 수 있다.

유용한 시스템은 결정론적 발견 사항과 불확실한 제안을 구분해야 한다. 변경이 왜 위험해 보이는지 보여주고, 사람이 검토할 수 있는 근거를 제공해야 한다.

또한 책임성을 보존해야 한다. 팀은 어떤 자동화 검사가 실행됐는지, 어떤 발견 사항이 기각됐는지, 누가 남은 위험을 수용했는지 알아야 한다.

추적 가능한 추론 없는 AI 생성 승인은 또 하나의 대기열 단축 수단이 된다. 검토의 외형은 유지하지만 거버넌스 기능은 약화시킨다.

가장 큰 위험은 아무도 완전히 이해하지 못하는 소프트웨어다

시스템의 성장이 팀의 공동 정신 모델을 앞지를 때, 더 빠른 통합은 위험해진다.

Houck의 가장 강력한 반론은 인지 부채와 의도 부채에 관한 것이다. 인지 부채는 소프트웨어가 책임 있는 팀이 이해할 수 있는 속도보다 빠르게 확장될 때 나타난다.

의도 부채는 사람들이 아키텍처와 구현 선택의 이유를 잃어버릴 때 발생한다. 시스템은 여전히 작동하지만, 그 근거를 복원하기는 어려워진다.

전통적인 기술 부채는 미래의 변경을 어렵게 만드는 타협을 설명한다. 인지 부채와 의도 부채는 시스템 동작과 사람의 이해 사이에서 커지는 격차에 초점을 둔다.

의무적 검토는 그 격차에 어느 정도 보호막을 제공한다. 동료의 변경을 읽으면 인식이 퍼지고 엔지니어가 낯선 구성 요소를 접할 수 있다.

그러나 그 보호는 불완전하다. 바쁜 검토자는 영향을 받는 시스템에 대한 지속적인 이해를 형성하지 않은 채 변경을 승인할 수 있다.

대규모 AI 생성 diff는 이 문제를 악화시킨다. 코드를 한 줄씩 읽는다고 해서 검토자가 더 넓은 의도나 창발적 동작을 파악한다는 보장은 없다.

Laycock은 엔지니어가 단순히 diff가 아니라 시스템을 이해해야 한다고 주장한다. 이 문구는 검토를 그대로 유지하는 것에 반대하는 가장 강력한 논거를 담고 있다.

diff는 텍스트 변경을 표현한 것이다. 런타임 의존성, 운영상 결과, 또는 설계 뒤에 있었던 기각된 대안을 자동으로 보여주지는 않는다.

그러나 초기 협업 역시 시스템 이해를 보장하지는 않는다. 팀은 지속적으로 남는 기록 없이 설계 세션을 진행할 수 있다.

페어링은 지식을 팀 전체로 퍼뜨리지 못한 채 한 사람이 아닌 두 사람에게 집중시킬 수 있다. 자동화된 아키텍처 검사는 오래된 가정을 완벽하게 강제할 수 있다.

따라서 예외 기반 검토에는 보완적인 안전장치가 필요하다. 팀은 설계 의도를 보존하고, 운영 책임을 순환시키며, 사고 이후 위험 규칙을 재검토해야 한다.

엔지니어가 원래 작성자에게 묻지 않고도 핵심 흐름을 설명할 수 있는지 검증해야 한다. 또한 신입 엔지니어가 중요한 의사결정에 의미 있게 노출되는지도 살펴야 한다.

운영 책임이 중요한 이유는 프로덕션 시스템이 코드 검토로는 알 수 없는 관계를 드러내기 때문이다. 장애에 대응하는 엔지니어는 어떤 경계가 유지되고 어떤 가정이 무너지는지 배운다.

공동 온콜 책임은 이러한 학습을 분산할 수 있다. 사고 후 분석은 개인의 발견을 조직 지식으로 전환할 수 있다.

리포지터리 이력은 여전히 유용하지만, 모든 부담을 짊어질 수는 없다. 설계 결정은 요구사항, 제약, 대안, 예상되는 운영 동작을 연결해야 한다.

이는 Laycock의 제안에 대한 회의적인 검증 기준을 만든다. 팀이 이러한 관행을 강화하지 않은 채 일상적인 사람 검토를 없앤다면, 지식을 더 빠르게 잃을 수 있다.

당장의 지표는 여전히 좋아 보일 수 있다. 병합 시간은 줄고, 대기열 길이는 짧아지며, 생성된 작업은 더 빨리 프로덕션에 도달한다.

피해는 나중에 나타난다. 장애, 보안 조사, 직원 퇴사, 대규모 재설계가 누락된 맥락을 드러낼 것이다.

이 지연된 피드백 때문에 인지 부채는 관리하기 어렵다. 조직은 검토 지연 시간을 쉽게 측정할 수 있지만, 공동 이해는 하나의 대시보드 숫자로 환원되기 어렵다.

대리 신호가 도움이 될 수 있다. 팀은 사고 발생 시 원래 작성자가 필요한 빈도나, 지식 있는 유지보수 담당자가 한 명뿐인 핵심 구성 요소의 수를 추적할 수 있다.

아키텍처 결정이 발견 가능한지, 그리고 검토자가 기계적으로 승인하는 대신 실질적인 내용을 질문하는지도 살펴볼 수 있다.

자동화된 변경이 장애를 일으킨 뒤 학습 검토를 진행할 수도 있다. 목적은 프로세스를 신뢰한 엔지니어를 비난하는 것이 아니라 임계값을 재조정하는 데 있어야 한다.

안전한 결론은 어느 극단보다 좁다. 의무적 검토는 충분한 보호 장치가 아니지만, 이를 없애는 것이 자동으로 진전은 아니다.

중요한 질문은 대체 방식이 구현 전, 구현 중, 구현 후에 더 강한 이해를 만들어내는가이다.

AI 검토는 승인을 모방하는 대신 관심을 배분해야 한다

가장 신뢰할 만한 단기 시스템은 자동화로 위험을 분류하면서 중요한 변경에 대해서는 사람이 책임을 지도록 한다.

이 입장은 전면적인 수동 검토와 제한 없는 자동화 승인 사이에 있다. 또한 워크플로를 즉시 재설계할 수 없는 팀에 실용적인 전환 경로를 제공한다.

첫째, 결정론적 도구는 사람이 프로세스에 들어오기 전에 완료돼야 한다. 포매팅, linting, 테스트 실행, 의존성 정책, 알려진 보안 검사는 자동화에 속한다.

둘째, AI는 변경의 목적과 영향을 받는 영역을 요약할 수 있다. 비정상적인 의존성 경로, 누락된 테스트, 기존 패턴과의 불일치를 식별할 수 있다.

이러한 발견 사항은 판결이 아니라 근거로 기능해야 한다. 시스템은 불확실성을 드러내고, 자격을 갖춘 엔지니어가 그 추론에 이의를 제기할 수 있도록 해야 한다.

셋째, 위험 규칙이 검토 경로를 결정해야 한다. 보안에 민감한 변경, 아키텍처 변경, 영향 범위가 큰 변경, 익숙하지 않은 변경은 신중한 사람의 검토를 받아야 한다.

일상적인 변경은 테스트와 안전장치가 충분한 신뢰를 제공할 때 더 가벼운 경로를 따를 수 있다. 팀은 이 경로를 점진적으로 도입하고 결과를 모니터링해야 한다.

넷째, 조직은 학습이 자동으로 일어난다고 가정하는 대신 이를 재배치해야 한다. 설계 세션, 페어링, 운영, 문서화된 결정이 일상적인 검토가 이전에 제공했던 지식을 대체해야 한다.

이 균형 잡힌 모델은 일반적인 AI 검토자보다 Meta의 접근 방식에 더 가깝다. RADAR는 단순히 모델에게 코드가 수용 가능한지 묻지 않는다.

여러 계층을 통해 적격성을 좁힌다. 이 아키텍처는 언어 모델만으로는 프로덕션 위험을 신뢰성 있게 나타낼 수 없음을 인정한다.

이 구분은 상업적으로도 중요하다. 많은 제품이 pull request에 의견을 생성할 수 있지만, 의견의 양은 부실한 성공 지표다.

유용한 검토자는 가치가 낮은 검사를 줄이는 동시에 중요한 의사결정에 대한 관심은 높인다. 또한 개발자에게 추측성 발견 사항을 쏟아붓는 일을 피한다.

거짓 양성은 자동화가 절약하겠다고 약속한 것과 동일한 희소한 관심을 소모한다. 반복되는 약한 경고는 개발자가 시스템을 무시하도록 학습시킨다.

거짓 음성은 다른 위험을 낳는다. 자동화된 승인은 시스템의 실제 근거를 넘어서는 확신을 만들 수 있다.

따라서 팀은 AI 검토를 구체적인 범주별로 평가해야 한다. 보안 문제, 논리 오류, 아키텍처 위반, 테스트 공백에 대해 각각 별도의 성능 데이터가 필요하다.

또한 유사한 변경끼리 비교해야 한다. 사전에 선별된 저위험 diff의 결과로는 사람 검토를 광범위하게 대체할 수 있다는 주장을 뒷받침할 수 없다.

시스템이 일상적인 변경을 자동으로 반영하더라도 사람의 책임성은 여전히 중요하다. 누군가는 적격성 정책과 그 운영상 결과를 책임져야 한다.

그 책임자가 모든 diff를 승인할 필요는 없다. 다만 임계값, 예외, 사고 피드백이 계속 연결되도록 보장해야 한다.

새롭게 떠오르는 설계는 인공적인 팀원이라기보다 항공 교통 관제사에 가깝다. 사람의 판단이 가장 큰 가치를 지니는 상황으로 관심을 유도한다.

이 역할은 모든 사람의 검토 의견을 재현하는 척하는 AI 에이전트보다 더 잘 확장될 수 있다. 또한 그 트레이드오프를 가시화한다.

세 가지 신호가 코드 검토가 정말 변하고 있는지를 보여줄 것이다

다음 단계는 검토의 품질, 시스템에 대한 이해, 그리고 통제된 자동화에서 나온 증거가 결정할 것이다.

첫 번째 신호는 조직이 자동화된 저위험 변경에 대해 비교 가능한 결과를 공개하는지 여부다. Meta는 이례적으로 상세한 배포 데이터를 제공했지만, 표본 선택 효과 역시 중요하게 고려해야 한다.

다른 엔지니어링 조직도 적용 대상 기준, 되돌리기 비율, 장애, 검토 지연 시간을 보고해야 한다. 가능하다면 AI가 생성한 변경과 사람이 작성한 작업을 구분해야 한다.

여러 배포에서 유사한 위험군에 걸쳐 안정적인 결과가 나타난다면, 예외 중심 검토 방식은 더 큰 지지를 얻을 수 있다. 성과가 제한적인 내부 조건에 의존한다면, 광범위한 도입에는 신중해야 한다.

두 번째 신호는 팀이 검토를 줄인 뒤에도 이해도를 측정하는지 여부다. 병합 속도가 빨라졌다는 사실만으로는 Laycock의 주장을 검증할 수 없다.

리더들은 지식 집중도, 장애 복구, 아키텍처 표류, 원작성자에 대한 의존도를 살펴봐야 한다. 또한 주니어 엔지니어들이 여전히 의미 있는 기술적 추론을 접하고 있는지도 추적해야 한다.

이해도가 안정적으로 유지된 채 처리량이 향상된다면 판단을 앞단으로 옮겨야 한다는 주장은 더 설득력을 얻을 것이다. 소유권 격차가 커진다면, 검토가 단순한 형식 이상의 무언가를 제거했다는 뜻이다.

세 번째 신호는 리포지터리 플랫폼과 AI 코딩 제품이 위험을 어떻게 표현하는가다. 일반적인 승인 버튼으로는 선택적 자동화에 필요한 신뢰 수준을 표현할 수 없다.

유용한 플랫폼은 변경이 자동 처리 대상이 된 이유를 드러낼 것이다. 모델의 판단 결과, 결정론적 검사, 정책 결정, 사람의 재정의도 보존할 것이다.

또한 계획 산출물과 생성된 변경을 연결할 수도 있다. 이러한 연결이 있다면 검토자는 코드만으로 의도와 제약을 다시 구성하는 대신, 이를 직접 검토할 수 있다.

도구들이 댓글 수나 자동 승인 건수를 놓고 경쟁한다면, 업계는 합성 검토자로 기존 병목을 재현하게 될 것이다. 반대로 주의가 필요한 지점을 투명하게 배분한다면, 프로세스는 진정으로 바뀔 수 있다.

Hacker News 논쟁은 코드 검토가 쓸모없어졌다는 사실을 입증하지 않는다. 그것은 AI가 생산하는 코드 규모에서는 모든 변경을 동일한 방식으로 검토하는 모델이 더 이상 확장되지 않는다는 점을 보여준다.

Laycock의 제안이 설득력 있는 이유는 단지 판단의 속도가 아니라, 판단이 이루어지는 위치를 겨냥하기 때문이다. 검토가 숨은 조직적 가치를 지탱해 왔다는 Houck의 반론 역시 여전히 중요하다.

승리하는 모델은 시니어 엔지니어가 점점 불어나는 일상적 코드의 흐름을 일일이 살피게 하지 않으면서도 그 가치를 보존할 것이다. 예측 가능한 검사는 자동화하고, 불확실한 결정은 더 높은 수준으로 끌어올릴 것이다.

엔지니어링 팀은 한 가지 실용적인 질문에서 시작해야 한다. 어떤 변경이 정말로 다른 사람의 판단을 필요로 하며, 그 구분을 뒷받침하는 증거는 무엇인가?

이에 정직하게 답하면 현재의 검토 정책이 소프트웨어를 보호하는지, 아니면 익숙한 의례를 보호할 뿐인지를 드러낼 것이다.