이제는 아무도 코드를 읽지 않는다
출처: Dev.to
2026년에 코드 리뷰가 어떻게 변했는지 보세요. AI가 코드를 작성하고, AI가 코드를 검토한다. 인간은 승인만 클릭한다. PR이 머지되고, 모두 다음 일로 넘어간다. 그 체인 안에서 실제로 diff를 읽은 사람은 아무도 없다.
이것은 예측이 아니다. 오늘 일어난 일이다.
현재 GitHub에 올라온 모든 코드 중 46%가 AI가 만든 것이다. Java 레포지토리에서는 그 비율이 61%에 달한다. AI 도입률이 높은 팀은 이전에 비해 풀 리퀘스트를 98% 더 많이 머지한다. 그리고 그 풀 리퀘스트를 검토하는 데 소요되는 시간은 91% 증가한다. 이는 사람들이 더 신중히 검토하기 때문이 아니라, 검토해야 할 양이 늘어나고 스키밍하는 데 시간이 더 걸리기 때문이다.
AI가 만든 코드 양은 올해 인간이 검토할 수 있는 능력을 40% 초과할 것으로 예상된다. 코드는 인간이 읽을 수 있는 속도보다 빠르게 쏟아져 들어오고, 그래서 사람들은 읽는 것을 포기한다.
과거 코드 리뷰는 의미가 있었다. 시니어 개발자는 풀 리퀘스트를 한 줄씩 읽었다. 놓친 버그를 잡아냈고, 접근 방식에 숨겨진 성능 문제를 설명해 주었으며, 아키텍처에 대해 이의를 제기하고, 무언가를 가르쳐 주었다. 리뷰는 게이트가 아니라 대화였다.
이제는 게이트가 되었고, 그 게이트는 고무로 만들어졌다.
풀 리퀘스트가 도착한다. 400줄에 달한다. AI 에이전트가 데이터베이스 쿼리를 재구성하고, 오류 처리를 추가하고, 테스트까지 작성했다. 코드는 깔끔해 보이고, 테스트는 통과하고, 린터도 만족한다. CI는 초록색이다. 리뷰어는 자신도 AI가 만든 PR을 배포해야 한다. 그들은 작성자와 같은 토큰을 쫓고 있다. 그들은 diff를 대충 훑어보고 승인 버튼을 클릭한다. 모두 다음 단계로 넘어간다.
코드를 읽은 사람은 없었다. 코드는 검토되었다. 이것은 서로 다른 두 가지이며, 업계는 이를 동일하게 착각하고 있다.
리뷰 옹호자들은 데이터를 들고 있다. AI가 만든 코드 중 40~45%에 보안 취약점이 존재한다. 이는 스탠포드, NYU, Veracode 등 여러 연구에서 일관되게 나타난 결과다. AI가 만든 Java 코드에서는 XSS 실패율이 86%에 달한다. 설계 수준의 보안 결함, 인증 우회, 직접 객체 참조 취약, 세션 관리 오류 등이 153% 증가했다.
AI 보조 개발자는 코드를 3~4배 더 많이 생산하지만, 보안 이슈는 10배 더 많이 만든다. AI가 만든 코드만으로도 매월 10,000건 이상의 새로운 보안 발견이 보고된다. 그리고 AI가 만든 코드 변경 중 43%는 QA와 스테이징을 통과했음에도 불구하고 프로덕션 디버깅이 필요하다.
GitHub Copilot Chat에 있었던 프롬프트 인젝션 취약점(CVSS 9.6)은 공격자가 PR 댓글에 숨은 명령을 삽입해 사설 레포지토리에서 AWS 키를 탈취하게 만들었다. 코드 리뷰 과정이 이를 잡아야 했지만, 아무도 프롬프트 인젝션을 위한 댓글을 읽지 않았기 때문에 놓쳤다. 이 위협은 기존 리뷰 프로세스가 설계될 당시에는 존재하지 않았다. 이러한 취약점은 업계가 대비하지 못한 수렴 현상의 한 축이다.
이 진영은 인간 리뷰가 AI 생성 취약점에 대한 최후의 방어선이라고 주장한다. 91% 증가한 리뷰 시간이 최적화 대상이 아니라, 리뷰가 더 엄격해져야 한다는 증거라고 말한다. 인간을 완전히 배제하면 팀 내 어느 누구도 보증할 수 없는 코드를 배포하게 된다는 것이다.
반대 진영은 다른 논리를 제시한다. 그것은 옹호자들이 원하는 만큼 쉽게 무시할 수 없는 주장이다.
실제로 500줄짜리 PR을 읽는 사람은 없다. AI 이전에도 읽지 않았고, 양이 두 배가 된 지금은 더더욱 읽지 않는다. 고무도장 문화는 새로운 것이 아니다. AI는 그 양을 폭증시켜 겉으로 드러나게 만든 것이다.
코드 리뷰의 죽음에 관한 유명한 에세이가 말하듯, 모든 엔지니어링 조직에는 같은 더러운 비밀이 있다. 며칠씩 머무는 PR, 고무도장 승인, 리뷰어는 자신의 작업이 있기 때문에 500줄 diff를 대충 훑는다. 인간이 작성한 코드는 2025년에 사라졌고, 인간 코드 리뷰는 2026년에 사라진다.
논점은 리뷰가 의미가 없다는 것이 아니다. 논점은 AI가 만든 코드를 한 줄씩 검토하는 것이 잘못된 체크포인트라는 것이다. 인간은 사양과 수용 기준을 앞 단계에서 정의하고, 자신이 직접 작성하지 않은 diff를 뒤에서 읽으며 전체 맥락을 파악할 수 없는 속도로 검토해서는 안 된다.
이 진영은 코드 리뷰 의식이 정치적 이유로 보존되고 있다고 말한다. 엔지니어링적 이유가 아니라는 것이다. “LGTM”이 가장 흔한 리뷰 코멘트였으며, AI는 그 사실을 숨길 수 없게 만들었다.
Amazon은 2026년 3월에 이를 체감했다. AI 보조 코드 변경이 적절한 리뷰 없이 배포돼 약 630만 건의 주문 손실을 초래한 장애가 발생했다. Amazon은 335개 시스템에 걸쳐 90일간 코드 안전 리셋을 시행했다. GitHub 자체도 2025년 5월부터 2026년 4월까지 257건의 사고를 기록했으며, 이는 주당 한 건 정도에 해당한다. 모두 AI가 만든 코드와 에이전시 워크플로우 급증이 원인이다.
이들은 프로세스가 느슨한 작은 기업이 아니다. 코드를 생성하는 도구를 만든 기업들이다. 리뷰를 따라잡지 못한다면, 누구도 따라잡을 수 없다.
패턴은 일관된다. AI는 인간이 검토할 수 있는 속도보다 빠르게 코드를 만든다. 백로그가 쌓이고, 배포 압박이 커지며, 리뷰는 형식적으로만 진행된다. 버그가 프로덕션에 떠밀리고, 사고가 발생한다. 대응은 언제나 “리뷰 프로세스를 개선해야 한다”는 것이다. 하지만 문제는 프로세스가 아니라 양이다. 양은 줄어들지 않는다.
보안 헤드라인 아래에는 더 조용한 위기가 있다. 코드 리뷰는 엔지니어 간 지식 전달의 장이었다. 시니어가 주니어 PR을 검토할 때는 버그를 잡는 것뿐 아니라 아키텍처를 가르치고, 특정 패턴이 대규모에서 왜 문제를 일으키는지 설명하며, 문서에 남지 않은 시스템 컨텍스트를 공유했다.
AI가 코드를 쓰고 AI가 리뷰하면 그 전달이 끊어진다. 시니어는 주니어가 작성한 코드를 읽지 않는다(주니어가 직접 코드를 작성하지 않았기 때문에). 주니어는 자동화된 리뷰에서 배우지 못한다. 코드베이스는 기능은 늘어나지만 이해도는 줄어든다. 더 많은 기능, 그 작동 방식을 아는 사람은 점점 적어진다.
낙관적인 데이터에 따르면, AI 피드백을 받은 주니어는 코드 품질이 3.2배 빨리 향상돼 온보딩 기간이 6개월에서 8주로 단축된다. 비관적인 해석은, 그들이 AI 기준을 만족시키는 방법만 배우고, 그 기준이 왜 존재하는지 이해하지 못한다는 것이다. 메트릭에 최적화했지만 원칙은 배우지 못한다.
Gartner는 2027년까지 엔지니어의 80%가 AI 협업을 위해 재교육이 필요할 것이라고 예측한다. 코드베이스는 AI에게는 읽기 쉬워도, 이를 책임지는 인간에게는 불투명해진다. AI가 이해하지 못하는 방식으로 무언가가 깨지면, 인간도 이해하지 못하는 상황에서 콜을 받게 된다.
과거 소프트웨어 개발의 병목은 코드를 작성하는 것이었다. 그 다음은 코드를 배포하는 것이었고, 이제는 코드를 이해하는 것이 병목이다.
AI는 몇 시간 만에 서비스를 만들 수 있다(몇 주가 걸리던 일). AI는 PR을 검토해 명백한 문제를 잡아내고, 행복한 경로와 대부분의 엣지 케이스를 커버하는 테스트를 생성한다. 하지만 AI는 이 서비스가 현재 시스템에 적합한지, 사용량이 두 배가 되었을 때 아키텍처가 버틸 수 있는지, 오늘 만든 트레이드오프가 6개월 뒤에 프로덕션 사고가 될지를 판단하지 못한다.
이러한 판단은 이해가 필요하고, 이해는 읽기가 필요하며, 아무도 읽지 않는다.
이 문제를 해결하는 팀은 한 줄씩 리뷰로 돌아가지 않을 것이다. 그 배는 이미 떠났다. 그들은 인간 체크포인트를 앞 단계로 옮길 것이다. 스펙을 검토하고, 구현이 아니라 동작을 검증한다.