← 블로그 목록

AI가 코드를 빨리 쏟아내도 인도는 왜 더 늦어지나: 발주사가 일정과 계약에 넣어야 할 리뷰·QA 병목 대비

2026.09.115분

외주 개발을 검토하는 자리에서 "AI를 쓰면 개발이 빨라지니 일정도 당길 수 있지 않냐"는 질문을 자주 받습니다. 절반은 맞습니다. 코드 초안을 뽑아내는 속도는 분명히 빨라졌습니다. 그런데 정작 화면이 켜지고, 결제가 돌고, 실사용자가 쓰는 시점, 즉 '인도(delivery)'는 기대만큼 당겨지지 않거나 오히려 뒤로 밀리는 경우가 생깁니다. 발주사 입장에서 이 어긋남을 미리 이해하지 못하면 일정 협상과 계약 조건이 통째로 흔들립니다.

monitor showing Java programming

속도는 앞단에서 빨라지고, 병목은 뒷단으로 옮겨간다

Google Cloud가 2025년 9월 발표한 2025 DORA 보고서(약 5,000명의 기술 전문가 조사)는 이 현상을 데이터로 보여줍니다. AI 도입은 소프트웨어 인도 처리량(throughput)과는 긍정적으로 상관하지만, 인도 안정성(delivery stability)과는 여전히 부정적으로 상관했습니다. 보고서의 결론을 한 문장으로 옮기면 "AI는 팀을 고치는 것이 아니라 이미 있는 상태를 증폭한다"입니다. 리뷰·테스트·배포 역량이 약한 팀이 AI를 얹으면, 약점이 그대로 커진다는 뜻입니다.

같은 보고서에서 응답자의 90%가 업무에 AI를 사용하고 80% 이상이 생산성이 올랐다고 답했지만, 약 30%는 AI가 생성한 코드를 거의 또는 전혀 신뢰하지 않는다고 답했습니다. 신뢰하지 못하는 코드는 결국 사람이 더 오래 들여다봐야 합니다. 코드가 많아질수록 검수 부담은 오히려 늘어납니다.

Harness의 State of AI-Driven Software Releases 2026 조사도 같은 방향을 가리킵니다. 조직의 57%가 위험도와 무관하게 AI가 생성한 모든 코드 라인에 사람이 개입하는 수동 리뷰를 요구했고, 그 그룹의 38%는 AI 도구 도입 전보다 코드 리뷰에 더 많은 시간을 쓰고 있다고 답했습니다. 앞단에서 아낀 시간이 뒷단에서 다시 나가는 구조입니다.

왜 재작업과 배포 실패가 늘어나는가

문제는 검수 시간만이 아닙니다. 배포 단위 자체가 커지고 있습니다. 같은 Harness 조사에서 응답자의 32%는 AI 생성 코드 도입 이후 릴리스(배포 단위) 크기가 커졌다고 답했습니다. 한 번에 나가는 변경이 크면 문제가 생겼을 때 원인을 좁히기 어렵고, 롤백 비용도 커집니다.

code editor displaying react source code

더 눈여겨볼 지점은 검증 체계입니다. AI 생성 코드에 대한 별도의 가드레일을 갖춘 조직은 49%에 그쳤습니다. 나머지 절반가량은 AI 이전과 똑같은 리뷰·검증 프로세스로 AI 코드를 배포하고 있다는 뜻입니다. 코드는 몇 배로 쏟아지는데 그것을 거르는 체는 예전 그대로라면, 새는 곳이 늘어나는 것은 당연합니다. 발주사가 체감하는 결과는 '재작업이 잦다', '배포하면 뭔가 터진다', '검수가 안 끝난다'로 나타납니다.

발주사가 일정과 계약에 명시해야 할 것

핵심은 관점의 전환입니다. 일정을 '코드가 얼마나 빨리 나오는가'가 아니라 '검수·QA가 얼마나 빨리 소화되는가', 즉 다운스트림 처리량 기준으로 잡아야 합니다. 견적서에 '개발 2주'라고 적혀 있어도, 리뷰와 테스트가 그 속도를 못 따라가면 인도일은 그 뒤에 결정됩니다.

일정 산정 기준

  • 리뷰 용량을 병목 자원으로 명시: 코드를 검토할 시니어 리뷰어의 주당 처리 가능 분량을 전제로 일정을 계산하도록 요구하세요. 리뷰어가 한 명뿐이라면 개발자를 아무리 늘려도 인도는 그 한 명의 속도에 묶입니다.
  • 재작업 버퍼를 일정에 별도 항목으로: 리뷰·QA에서 되돌아오는 수정 시간을 '없는 셈'으로 잡지 말고, 마일스톤마다 명시적 버퍼로 잡아 두세요.
  • 큰 배포 대신 작은 단위 인도: 한 번에 몰아 받지 말고 기능 단위로 잘게 나눠 받도록 계약하세요. 릴리스가 작을수록 문제 격리와 롤백이 쉽습니다.

계약·마일스톤에 넣을 지표

  • 변경 실패율: 배포 후 장애나 롤백, 긴급 수정으로 이어진 배포의 비율을 완료 조건에 포함하세요. 기능이 '동작한다'만이 아니라 '안정적으로 배포된다'를 검수 기준으로 삼는 것입니다.
  • 재작업률: 리뷰·QA에서 반려되어 다시 손대는 작업의 비중을 추적 항목으로 넣으세요. 이 수치가 계속 높으면 속도가 아니라 초안 품질에 문제가 있다는 신호입니다.
  • AI 코드에 대한 별도 검증 절차 확인: 파트너가 AI 생성 코드에 대해 사람 리뷰, 자동 테스트 커버리지, 배포 전 검증 게이트를 어떻게 두는지 계약 전에 문서로 확인하세요. '예전과 같은 절차로 처리한다'는 답이면 위험 신호입니다.
  • 테스트·문서 산출물을 인도물에 포함: 코드만 인도물로 잡으면 검증되지 않은 코드를 받게 됩니다. 테스트 코드, 배포 절차, 롤백 방법을 함께 인도 조건으로 명시하세요.

정리

AI는 개발의 시작을 빠르게 하지만, 끝을 자동으로 앞당겨 주지는 않습니다. DORA와 Harness의 조사가 공통으로 보여주듯 병목은 코드 생성에서 리뷰·테스트·배포 안정성으로 이동했고, 검증 체계를 함께 손보지 않은 팀에서는 재작업과 배포 실패가 늘어납니다. 발주사가 할 일은 '더 빨리 만들어 달라'가 아니라, 검수·QA 처리량을 일정의 기준으로 놓고 안정성 지표를 계약에 적어 두는 것입니다. FIRSTPIP은 견적과 마일스톤을 짤 때 리뷰 용량과 재작업 버퍼, 변경 실패율·재작업률을 함께 설계해, 받는 시점이 아니라 안정적으로 쓰기 시작하는 시점을 기준으로 일정을 합의합니다.