AI 코딩 도구가 한 번에 수백 줄을 만들고 여러 작업을 병렬로 처리하기 시작하면, 가장 먼저 부족해지는 것은 코드를 쓰는 시간이 아니다. 그 코드가 맞는지 확인하는 시간이다. DORA가 2026년 3월 공개한 분석에서도 AI가 초안 작성 속도를 높인 만큼 절약된 시간이 감사와 검증에 다시 쓰이는 현상이 나타났다. AI 활용도가 높은 조직에서는 배포 처리량과 함께 불안정성도 높아지는 상관관계가 관찰됐다.[^1]
이 변화는 “코드 리뷰가 사라진다”는 주장보다 조금 더 정확하게 볼 필요가 있다. 사람이 모든 변경을 줄 단위로 읽어 승인하는 방식의 비중은 줄어들 수 있지만, 품질 확인 자체는 오히려 더 중요해진다. 중심이 사람의 육안 검토에서 테스트, 정책, 격리된 실행환경, 관찰성, 복구 가능성처럼 실행 가능한 증거로 옮겨가는 쪽에 가깝다.
결국 AI 시대의 개발 속도를 결정하는 것은 얼마나 많은 코드를 생성할 수 있느냐보다, 생성된 변경을 얼마나 싸고 빠르게 검증할 수 있느냐다.
코드 생성량이 늘면 기존 리뷰 방식부터 포화된다
전통적인 Pull Request 리뷰는 사람이 변경 내용을 읽고 설계 의도와 코드 품질을 확인한다. 변경량이 비교적 제한적이고 작성자가 코드의 세부 맥락을 직접 이해하고 있을 때는 꽤 잘 작동한다.
에이전트형 개발은 이 전제를 흔든다. 한 명의 개발자가 여러 에이전트에 서로 다른 작업을 맡길 수 있고, 각 에이전트는 사람이 직접 작성할 때보다 훨씬 많은 코드를 짧은 시간 안에 만들어낼 수 있다. 생성 능력은 거의 즉시 확장되지만 숙련된 리뷰어의 시간은 같은 속도로 늘지 않는다.
그래서 단순히 기존 리뷰 인원을 늘리는 방식으로는 생산성 향상을 온전히 가져가기 어렵다. DORA 조사에서 개발자들이 체감한 문제도 비슷하다. AI는 일을 시작하는 마찰을 줄이고 낯선 코드베이스를 탐색하는 데 도움을 주지만, 개발자 30%가 AI 생성 코드에 거의 또는 전혀 신뢰를 두지 않는다고 답했다. 작성 단계에서 얻은 시간이 검증 단계에서 다시 소비되는 ‘verification tax’가 생기는 이유다.[^1]
여기서 중요한 것은 리뷰를 없애는 것과 리뷰의 대상을 바꾸는 것을 구분하는 일이다. AI가 만든 700줄을 사람이 700줄 그대로 읽는 대신, 그 변경이 어떤 계약을 건드렸는지, 어떤 테스트를 통과했는지, 실패했을 때 어떻게 되돌릴 수 있는지를 검토하는 편이 더 효율적일 수 있다.
일부 팀은 리뷰 방식 자체를 다시 설계하고 있다
AMP는 이 변화를 공격적으로 실험하는 팀 가운데 하나다. 회사는 2026년 들어 코딩 에이전트를 에디터 안의 보조 도구가 아니라 독립적으로 오래 실행되는 작업 단위로 재설계하고 있다. AMP의 Orbs는 작업마다 저장소와 개발 도구가 준비된 원격 머신을 만들고, 에이전트가 브라우저를 띄우거나 애플리케이션을 실행해 엔드투엔드 검증까지 수행할 수 있게 한다.[^2]
이 접근의 핵심은 “사람이 보지 않아도 된다”가 아니다. 사람이 보기 전에 기계가 만들어야 하는 증거의 범위를 넓히는 것이다. 에이전트가 변경만 제출하는 것이 아니라 실행 결과, 테스트, 실제 화면, diff와 같은 검증 자료를 함께 남기면 사람은 구현의 모든 세부보다 위험한 결정과 예외에 집중할 수 있다.
AMP가 “코딩 에이전트는 죽었다”고 표현한 이유도 비슷하다. 최신 모델 자체보다 코드베이스를 어떻게 구성하고 조직이 에이전트를 어떻게 사용하는지가 새로운 병목이라는 주장이다.[^3] 이런 실험이 모든 회사에서 필수 코드 리뷰를 줄여도 된다는 근거는 아니다. 작은 고신뢰 팀과 금융·의료·대규모 플랫폼 조직은 실패 비용과 규제 조건이 다르다. 다만 코드 생성 속도가 급격히 올라갈수록 기존의 동일한 승인 절차가 병목이 될 가능성은 분명히 커진다.
품질의 단위도 ‘좋은 코드’에서 ‘좋은 변경’으로 넓어진다
AI가 깔끔한 함수와 테스트 코드를 빠르게 만들 수 있게 되면 가독성, 네이밍, 포맷 같은 구현 품질은 점차 자동화하기 쉬운 영역이 된다. 더 어려운 문제는 그 코드가 애초에 올바른 해결책인지 판단하는 것이다.
예를 들어 알림 기능을 만든다고 하자. API와 데이터베이스 테이블, 큐 소비자와 화면 코드는 AI가 빠르게 작성할 수 있다. 하지만 동기 처리와 비동기 처리 중 무엇이 맞는지, 장애가 났을 때 중복 발송을 어떻게 막을지, 사용자가 1만 명에서 1천만 명으로 늘어날 때 같은 구조를 유지할 수 있는지는 시스템 맥락을 봐야 한다.
IBM도 AI가 더 많은 코드를 쓰는 환경에서는 팀 규칙을 기계가 읽을 수 있는 형태로 명시하는 것이 중요하다고 설명한다. 회사가 2026년 5월 공개한 글에 따르면 조사된 엔지니어링 리더의 55%가 코드베이스가 어떻게 진화하는지에 대한 공통 이해가 약해질 것을 우려했고, 39%는 AI 에이전트가 더 많은 코드를 작성할수록 자신 있게 배포하기 어려워질 것을 걱정했다.[^4]
이 문제는 코드 스타일 통일만으로 해결되지 않는다. 어떤 변경에는 계약 테스트가 필요하고, 어떤 변경에는 성능 한계나 보안 정책이 더 중요하다. 즉 품질 관리의 최소 단위가 파일과 함수에서 시스템에 들어간 하나의 변경과 그 영향 범위로 넓어진다.
그래서 하니스가 모델만큼 중요해진다
에이전트를 실제 개발에 쓰려면 모델 주위에 작업환경이 필요하다. 저장소를 읽을 권한, 실행 가능한 샌드박스, 테스트 명령, 브라우저, 로그, 정책, 성공 조건과 종료 조건이 함께 있어야 한다. 흔히 하니스(harness)라고 부르는 이 계층이 모델의 행동 범위를 정한다.
좋은 하니스는 모델을 더 똑똑하게 만드는 마법이 아니다. 대신 모델이 틀렸을 때 그 오류가 빨리 드러나게 한다. 예를 들어 변경 직후 계약 테스트가 자동으로 깨지고, 실제 서비스와 비슷한 환경에서 화면이 렌더링되며, 배포 후 오류율이 기준을 넘으면 즉시 되돌릴 수 있다면 에이전트가 만든 코드의 양이 늘어도 검증 비용을 통제할 수 있다.
반대로 문서에만 “보안을 확인하라”, “기존 패턴을 따르라”고 적혀 있고 실제 워크플로우에서 강제하지 않으면 생성 속도만 빨라진다. DORA가 AI를 조직 역량의 ‘증폭기’라고 표현하는 이유도 여기에 있다. 테스트와 플랫폼이 강한 조직에서는 AI가 생산성을 높이지만, 깨지기 쉬운 인프라와 분절된 도구를 가진 조직에서는 기술부채를 더 빨리 만들 수 있다.[^1]
사람의 역할은 승인 버튼보다 판단에 가까워진다
자동 검증이 강해져도 인간 엔지니어가 사라지는 것은 아니다. 사람이 해야 할 일의 위치가 달라진다.
테스트는 “정해진 요구사항을 만족했는가”를 잘 확인하지만, 요구사항 자체가 맞는지는 스스로 결정하지 못한다. 시스템이 어떤 실패를 허용할지, 개인정보를 어디까지 사용할지, 속도와 안정성 중 무엇을 우선할지 같은 문제는 사업과 운영 맥락을 포함한다. 테스트가 모두 통과해도 잘못된 제품 결정을 구현했을 수 있다.
따라서 앞으로 가치가 커지는 리뷰는 코드를 다시 써주는 리뷰보다 이런 질문에 답하는 리뷰다. 변경의 목적이 맞는가. 위험 수준에 맞는 검증이 붙었는가. 되돌릴 수 있는가. 운영 중 예상하지 못한 행동을 알아챌 수 있는가.
이 관점에서는 “코드 리뷰를 유지할까 없앨까”라는 질문 자체가 조금 좁다. 더 중요한 질문은 사람이 직접 읽어야 하는 부분과 시스템이 증명해야 하는 부분을 어떻게 나눌 것인가다.
AI가 코드를 더 빨리 만드는 만큼 이 구분은 더 중요해진다. 앞으로 생산성이 높은 팀은 생성량이 가장 많은 팀이 아니라, 많은 변경을 만들어도 신뢰 수준을 떨어뜨리지 않는 팀일 가능성이 높다. 그때 코드 리뷰는 사라지기보다 형태가 바뀐다. 구현물을 읽는 절차에서, 변경을 뒷받침하는 증거와 중요한 판단을 검토하는 절차로 이동한다.
Sources
[^1]: DORA, Balancing AI tensions: Moving from AI adoption to effective SDLC use, 2026-03-10 [^2]: Amp, What Are Orbs? [^3]: Amp, The Coding Agent Is Dead, 2026-02-19 [^4]: IBM, How to standardize AI code generation across your development team, 2026-05-22