퇴근 전에 AI 개발 도구에 버그 수정 다섯 건을 맡겼다고 가정해 보겠습니다. 다음 날 아침에는 설명이 잘 정리된 코드 변경안 다섯 개와 테스트 결과가 도착해 있습니다. 코드를 만드는 시간만 보면 큰 폭으로 줄었습니다.

하지만 그 코드를 바로 서비스에 반영할 수 있는 것은 아닙니다. 각 변경안이 요구사항을 제대로 이해했는지, 예상하지 않은 파일을 건드리지 않았는지, 테스트가 실제 위험을 확인했는지 사람이 판단해야 합니다. AI가 만든 설명까지 같은 잘못된 가정을 따를 수 있으므로 요약만 읽고 승인하기도 어렵습니다. 개발팀에서는 이렇게 검토를 요청하는 코드 변경 묶음을 PR(Pull Request)이라고 부릅니다.

AI는 이런 변경안을 여러 개 동시에 만들 수 있지만, 최종 반영을 판단할 사람까지 자동으로 늘려주지는 않습니다. 고객이 체감하는 개발 기간은 코드가 나온 순간이 아니라 검수와 서비스 반영을 마칠 때까지 이어집니다.

만든 코드 수보다 검수 대기 시간을 봅니다

AI가 하루에 만든 변경안 수만 세면 생산성이 크게 오른 것처럼 보입니다. 실제 개발 속도는 사람이 내용을 이해하고 승인해 서비스에 반영한 변경안 수에서 결정됩니다. 검토할 변경안은 빠르게 쌓이는데 담당자가 그대로라면, 코드를 빨리 만든 만큼 검수 대기 시간이 길어질 수 있습니다.

저는 AI 도입 효과를 볼 때 완료했다고 보고된 작업 수보다 다음 세 시간을 함께 봅니다.

  • 코드 변경안이 나온 뒤 첫 검토가 시작되기까지 걸린 시간
  • 첫 검토부터 실제 반영까지 걸린 시간과 수정 횟수
  • 서비스 반영 뒤 되돌림이나 긴급 수정에 든 시간

만든 코드가 늘어도 이 시간이 길어지면 병목이 코드 작성에서 검수로 이동했을 뿐입니다.

정돈된 코드가 올바른 결과의 증거는 아닙니다

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

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

AI에 맡기기 전에 바꿔도 되는 범위를 정합니다

긴 변경 내역을 만든 뒤 사람에게 꼼꼼히 읽으라고 하면 검토 비용은 변경량만큼 커집니다. 저는 AI에 일을 맡기기 전에 작업 카드에 경계를 먼저 적습니다.

  • 해결할 문제와 사용자가 확인할 완료 조건
  • 이번 작업에서 바꾸지 않을 범위
  • 수정해도 되는 파일이나 디렉터리
  • 문제가 실제로 재현되는 것을 먼저 보여주는 테스트 또는 재현 절차
  • 권한·결제·삭제·데이터 이전과 구조 변경처럼 별도 검토가 필요한 위험

허용하지 않은 파일을 수정하면 코드 품질과 관계없이 작업을 멈춥니다. 완료 조건을 보여주는 테스트가 없다면 검수를 요청하기 전에 보완합니다. 이 두 조건만 기계적으로 확인해도 담당자가 긴 변경 내역에서 작업 의도를 다시 추측하는 시간을 줄일 수 있습니다.

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

검수 자료에는 요약보다 증거를 둡니다

무엇을 변경했습니다라는 문장만으로는 검수를 시작하기 어렵습니다. AI가 작성한 변경안에는 담당자가 첫 1분 안에 위험을 판단할 수 있는 정보를 남깁니다.

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

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

AI 검토는 최종 승인보다 사전 점검에 가깝습니다

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

따라서 AI의 검토 의견은 사람이 볼 곳을 좁히는 선별 결과로 사용합니다. 코드 오류를 자동으로 찾는 검사와 기능별·전체 흐름 테스트처럼 결과가 재현되는 도구를 함께 실행하고, 업무 규칙과 위험한 변경은 사람이 승인합니다.

GitHub Copilot의 코드 검토 기능이 이 구분을 잘 보여줍니다. 2026년 8월 기준 Copilot은 검토 의견인 Comment만 남기며, 필수 승인으로 계산되지 않습니다.[1] AI의 지적은 서비스 반영 결정이 아니라 사람이 확인할 검토 재료입니다.

이 검토 재료를 다른 AI에 넘겨 수정을 맡길 때도 담당 개발자가 먼저 실제 문제인지 판단하고, 무엇을 왜 고칠지 정해야 합니다. 이 단계가 빠지면 사람은 두 AI 사이에서 메시지만 전달하고, 최종 반영 근거를 설명할 주체도 사라집니다.

위험에 따라 서비스 반영 기준을 나눕니다

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

  • 낮은 위험: 문서, 형식 정리, 도구가 자동으로 만들어 내는 파일 갱신은 자동 검사와 변경 범위 확인
  • 중간 위험: 화면과 일반 업무 기능은 시나리오 테스트와 담당자 한 명의 승인
  • 높은 위험: 인증, 권한, 결제, 삭제, 데이터 이전과 구조 변경은 별도 테스트 환경과 되돌림 검증, 두 사람의 승인

바뀐 코드가 짧아도 위험은 높을 수 있습니다. 권한 조건 한 줄과 데이터 삭제 명령 한 줄은 수백 줄의 테스트 코드보다 더 깊게 봐야 합니다. 검수 시간은 변경량보다 실패했을 때의 피해 범위에 맞춥니다.

좋은 AI 개발은 사람이 덜 읽어도 확인할 수 있게 만듭니다

AI가 만든 코드를 전부 줄 단위로 다시 읽어야만 안심할 수 있다면 자동화 효과는 오래가기 어렵습니다. 반대로 AI가 썼다는 이유로 요약과 자동 테스트 통과 표시만 보고 서비스에 반영하면 속도는 얻어도 책임을 잃습니다.

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

AI를 쓰는 개발사에 일을 맡길 때도 어떤 도구를 쓰는지보다 세 가지를 확인하는 편이 낫습니다. 작업 전에 범위와 완료 조건을 정하는지, 검수할 수 있는 테스트와 화면 증거를 남기는지, 권한·결제·삭제처럼 위험한 변경을 별도로 승인하는지입니다.

AI 개발 도구의 성능은 코드를 몇 건 만들었는지만으로 판단하기 어렵습니다. 담당자가 의도를 다시 추측하지 않고 어떤 근거로 서비스에 반영했는지 설명할 수 있을 때, 비로소 코드 생성 속도가 실제 개발 기간 단축으로 이어집니다.

출처