퇴근 전에 AI 코딩 에이전트에 버그 수정 다섯 건을 맡겼다고 가정해 보겠습니다. 다음 날 아침에는 설명이 잘 정리된 PR 다섯 개가 열려 있고 테스트도 모두 통과합니다. 코드를 만드는 시간만 보면 큰 폭으로 줄었습니다.

하지만 병합 버튼 앞에는 여전히 사람이 있습니다. 각 PR이 요구사항을 제대로 이해했는지, 예상하지 않은 파일을 건드리지 않았는지, 테스트가 실제 위험을 확인했는지 판단해야 합니다. 에이전트가 만든 설명까지 같은 잘못된 가정을 따를 수 있으므로 요약만 읽고 승인하기도 어렵습니다.

코드 생성은 여러 에이전트에 나누어 맡길 수 있지만 병합 책임은 자동으로 늘어나지 않습니다. AI 코딩의 다음 병목은 작성 속도가 아니라 사람이 검토할 수 있는 형태로 작업을 제한하고 증거를 남기는 일입니다.

PR 수보다 판단 대기열을 봅니다

에이전트가 하루에 만든 PR 수만 세면 생산성이 크게 오른 것처럼 보입니다. 실제 배포 속도는 사람이 내용을 이해하고 승인한 PR 수에서 결정됩니다. 열려 있는 PR이 빠르게 쌓이고 검토자가 그대로라면 생성 속도가 빨라진 만큼 판단 대기열이 길어집니다.

2026년 7월 공개된 사전 공개 연구는 2,361개 GitHub 저장소의 에이전트 작성 PR 25,264건을 분석했습니다. 한 명의 개발자가 에이전트의 기여를 검토하거나 수정하는 감독 형태가 가장 흔했습니다.[1]

저는 도입 효과를 볼 때 에이전트가 완료한 작업 수보다 다음 세 시간을 함께 봅니다.

  • PR이 열린 뒤 첫 검토가 시작되기까지 걸린 시간
  • 첫 검토부터 병합까지 걸린 시간과 수정 회수
  • 병합 뒤 되돌림이나 긴급 수정에 든 시간

생성량이 늘어도 이 시간이 길어지면 병목이 개발자 키보드에서 리뷰 화면으로 이동했을 뿐입니다.

깔끔한 diff가 올바른 변경의 증거는 아닙니다

AI가 만든 코드는 변수명, 주석과 테스트까지 일정한 형식으로 정리될 수 있습니다. 그래서 사람이 급하게 만든 코드보다 첫인상이 더 안정적으로 보이기도 합니다. 문제는 구현과 테스트가 같은 잘못된 가정에서 함께 만들어질 수 있다는 점입니다.

예를 들어 에이전트가 ‘취소된 주문은 매출 집계에서 제외한다’고 잘못 이해했다면 코드도 그 기준으로 만들고, 테스트도 취소 주문을 제외하는 결과를 정답으로 둘 수 있습니다. CI가 통과했다는 사실은 코드와 테스트가 서로 일치한다는 뜻이지, 고객이 합의한 업무 규칙과 일치한다는 뜻은 아닙니다.

에이전트를 실행하기 전에 리뷰 범위를 줄입니다

긴 diff를 만든 뒤 사람에게 꼼꼼히 읽으라고 하면 검토 비용은 변경량만큼 커집니다. 저는 에이전트를 실행하기 전에 작업 카드에 경계를 먼저 적습니다.

  • 해결할 문제와 사용자가 확인할 완료 조건
  • 이번 작업에서 바꾸지 않을 범위
  • 수정해도 되는 파일이나 디렉터리
  • 먼저 실패해야 하는 테스트 또는 재현 절차
  • 권한·결제·삭제·마이그레이션처럼 별도 검토가 필요한 위험

허용하지 않은 파일을 수정하면 코드 품질과 관계없이 작업을 멈춥니다. 완료 조건을 보여주는 테스트가 없다면 PR을 열기 전에 보완합니다. 이 두 조건만 기계적으로 확인해도 리뷰어가 diff에서 의도를 역추적하는 시간을 줄일 수 있습니다.

모든 작업을 작은 파일 하나로 제한할 수는 없습니다. 구조 변경처럼 범위가 넓은 작업은 먼저 설계 결정을 검토한 뒤 구현을 나누는 편이 낫습니다. 사람이 가장 중요한 결정을 PR 마지막 단계에서 처음 발견하지 않게 하는 것이 핵심입니다.

PR 첫 화면에는 요약보다 증거를 둡니다

무엇을 변경했습니다라는 문장만으로는 리뷰를 시작하기 어렵습니다. 에이전트가 작성한 PR에는 리뷰어가 첫 1분 안에 위험을 판단할 수 있는 정보를 남깁니다.

  • 왜 이 변경이 필요한지와 연결된 요구사항
  • 바뀐 파일과 각 파일을 건드린 이유
  • 실행한 테스트·검증 명령과 실제 결과
  • 확인하지 못했거나 건너뛴 항목
  • 화면 변경 전후의 스크린샷이나 재현 로그
  • 에이전트가 세운 가정과 사람이 확인해야 할 항목
  • 문제가 생겼을 때 되돌리는 방법

여기서 중요한 것은 결과를 길게 설명하는 일이 아닙니다. 리뷰어가 같은 명령을 실행하고 같은 화면을 확인할 수 있어야 합니다. 스크린샷도 성공한 화면 한 장보다 입력 조건, 오류 상태와 모바일 화면처럼 실패 가능성이 있는 경계를 보여주는 편이 유용합니다.

AI 리뷰는 승인보다 선별에 가깝습니다

두 번째 AI에게 첫 번째 AI의 코드를 검토하게 하면 누락된 예외, 반복 코드와 일반적인 보안 문제를 빠르게 찾을 수 있습니다. 다만 두 도구가 같은 저장소와 요구사항을 보면 같은 빈칸을 같은 방식으로 추측할 가능성도 있습니다.

AI 에이전트가 참여한 코드 리뷰에서 결정 시간이 짧아지는 패턴은 관찰됐지만, 그 속도가 더 나은 리뷰 품질로 이어지지는 않았다는 2026년 7월 사전 공개 연구 결과도 있습니다.[2] 저는 이 결과를 ‘AI 리뷰가 쓸모없다’는 뜻으로 보지 않습니다. 빠른 검토와 올바른 승인을 서로 다른 지표로 관리해야 한다는 뜻으로 봅니다.

따라서 AI 리뷰 의견은 사람이 볼 곳을 좁히는 선별 결과로 사용합니다. 정적 분석, 타입 검사, 단위·통합 테스트처럼 결과가 재현되는 도구를 함께 실행하고, 업무 규칙과 위험한 변경은 사람이 승인합니다.

이 글의 GitHub Copilot 동작 설명은 2026년 8월 기준입니다. GitHub Copilot 코드 리뷰는 Comment만 남기고 필수 승인으로 계산되지 않습니다.[3]

리뷰 봇의 지적을 다른 AI에 그대로 전달하는 방식도 피합니다. 담당 개발자는 지적이 실제 문제인지 확인하고, 수정할 이유를 자신의 판단으로 남겨야 합니다. 그렇지 않으면 사람은 두 AI 사이에서 메시지만 전달하고 병합 책임은 누구도 설명하지 못합니다.

위험에 따라 병합 기준을 나눕니다

문서 오탈자와 결제 로직을 같은 깊이로 검토하면 중요한 PR에 쓸 시간이 부족해집니다. 작업을 맡길 때부터 위험 등급을 붙이면 승인 절차를 다르게 운영할 수 있습니다.

  • 낮은 위험: 문서, 형식 정리, 생성 파일 갱신은 자동 검사와 변경 범위 확인
  • 중간 위험: 화면과 일반 업무 로직은 시나리오 테스트와 담당자 한 명의 승인
  • 높은 위험: 인증, 권한, 결제, 삭제, 데이터 마이그레이션은 별도 테스트 환경과 되돌림 검증, 두 사람의 승인

줄 수가 적어도 위험은 높을 수 있습니다. 권한 조건 한 줄과 데이터 삭제 쿼리 한 줄은 수백 줄의 테스트 코드보다 더 깊게 봐야 합니다. 리뷰 시간은 diff 크기보다 실패했을 때의 피해 범위에 맞춥니다.

좋은 에이전트 운영은 사람이 적게 읽는 구조를 만듭니다

AI가 만든 코드를 전부 줄 단위로 다시 읽어야만 안심할 수 있다면 자동화 효과는 오래가기 어렵습니다. 반대로 AI가 썼다는 이유로 요약과 초록색 CI만 보고 병합하면 속도는 얻어도 책임을 잃습니다.

제가 원하는 운영은 중간에 있습니다. 작업 전에 범위와 완료 조건을 고정하고, 실행 중에는 허용 범위를 벗어나면 멈추며, PR에는 재현 가능한 증거와 남은 위험을 남깁니다. 사람은 모든 문장을 다시 쓰는 대신 요구사항과 위험한 경계를 확인하고 최종 결정을 내립니다.

AI 코딩 에이전트의 성능은 PR을 몇 개 열었는지만으로 판단하기 어렵습니다. 리뷰어가 의도를 다시 추측하지 않고, 어떤 근거로 병합했는지 설명할 수 있을 때 비로소 코드 생성 속도가 팀의 배포 속도로 이어집니다.

출처