코드는 쏟아지는데 '진짜 진척'은 어떻게 아나 — AI 시대 외주 프로젝트 진행률 다시 측정하기
커밋은 늘었는데, 왜 마음은 놓이지 않을까
외주 개발 프로젝트를 맡긴 발주사 대표님·기획자분들이 최근 부쩍 자주 하시는 말씀이 있습니다. "지난주보다 커밋도 많고 화면도 여러 개 늘었는데, 정작 오픈 날짜는 왜 안 당겨지나요?" 코드가 눈에 띄게 빨리 쌓이는데 안심이 되기는커녕 오히려 불안해지는 이 감각, 우연이 아닙니다.
Google Cloud의 DORA 2025 리포트에 따르면 개발자의 약 90%가 이미 업무에 AI 도구를 사용하고 있습니다. 코드가 생산되는 속도는 확실히 빨라졌습니다. 문제는 진척을 재던 기존의 자(尺)가 이 속도를 따라가지 못한다는 데 있습니다. 커밋 수, PR 개수, 누적 코드량 같은 전통적 지표는 '얼마나 많이 만들었나'는 잘 보여주지만, '얼마나 제대로 나아갔나'는 거의 말해주지 않습니다. AI 시대에는 이 둘의 간극이 전보다 훨씬 크게 벌어졌습니다.
산출량 지표가 발주사를 속이는 방식
발주사가 보고받는 진행률은 대개 '만든 양'에 기반합니다. 화면 몇 개, 기능 몇 건, 이번 스프린트 커밋 몇 회. 직관적이고 세기 쉬우니까요. 그런데 코드 생성이 저렴해지면 이 숫자들은 실제 가치보다 쉽게 부풀려집니다.
이 함정은 수치로도 드러납니다. 코드 분석 업체 GitClear가 2억 1,100만 줄의 코드를 분석한 결과, 커밋된 지 2주 안에 다시 고쳐지거나 되돌려지는 코드의 비율, 이른바 '코드 처른(code churn)'이 AI 확산과 함께 AI 도입 이전 약 3.3% 수준에서 2024년 5.7%, 2025년 7.1%로 약 두 배 늘었습니다(GitClear, AI Copilot Code Quality 2025). 쉽게 말해, 만들어진 코드의 상당 부분이 곧 다시 뜯어고쳐지고 있다는 뜻입니다. 커밋 그래프는 우상향하는데, 그 안에는 '진짜 전진'과 '방금 만든 것을 되돌리는 작업'이 뒤섞여 있습니다.
더 눈여겨볼 대목은 방향성입니다. DORA는 AI 도입이 개인의 생산성과 코드 품질 '체감'은 끌어올리는 동시에, 소프트웨어 배포 안정성과는 음(-)의 상관관계를 보인다고 지적합니다. 앞단이 빨라진 만큼 하류 단계(검증·통합·배포)의 약점이 더 선명하게 드러난다는 것이죠. 리포트의 핵심 메시지도 여기에 있습니다. AI는 팀을 고쳐주지 않고 '증폭'시킨다는 것. 원래 튼튼한 팀은 더 좋아지지만, 프로세스가 약한 팀은 기존 문제가 오히려 더 심해집니다.
병목이 어디로 옮겨갔는지도 분명합니다. Faros AI 리서치에 따르면 AI 도입률이 높은 팀에서 PR 병합은 크게(약 98%) 늘었지만, PR 리뷰에 걸리는 시간은 그에 못지않게(약 91%) 함께 늘었습니다. 코드를 만드는 일은 빨라졌지만, 그것을 사람이 검토하고 승인하는 단계로 병목이 이동한 것입니다. 즉 '많이 만들어졌다'는 신호는 넘치는데, '검증까지 끝났다'는 신호는 그만큼 따라오지 못합니다.
발주사가 진짜 봐야 할 것: 산출량에서 '흡수량'으로
그래서 관점을 바꿔야 합니다. 얼마나 쏟아졌는지(산출량)가 아니라, 그중 얼마가 검증을 통과해 실제로 굳어졌는지(흡수량)를 봐야 합니다. SI 파트너로서 발주사에 권해드리는 체크포인트는 다음과 같습니다.
보고서에서 확인할 지표
- 되돌림·재작업 비중: 이번 기간에 새로 만든 코드 중 최근 2주 안에 다시 손댄 비율이 어느 정도인지. 이 값이 계속 높다면 요구사항이 흔들리거나 초기 설계가 불안정하다는 신호입니다.
- 리뷰를 통과해 병합된 비율: '작성된 PR'이 아니라 '리뷰·검증을 거쳐 병합된 PR'을 기준으로 진척을 보고받으세요. 열린 채 쌓여만 가는 PR은 진척이 아니라 부채입니다.
- 배포 성공률과 롤백 빈도: 스테이징·운영에 얼마나 자주 안정적으로 반영되는지. 배포가 자주, 문제없이 이뤄지는지가 속도보다 건강성을 잘 보여줍니다.
- 결함 재발률: 고쳤다던 버그가 얼마 뒤 다시 올라오는 빈도. 재발이 잦다면 '고친 것처럼 보이는' 코드가 양산되고 있을 수 있습니다.
- 동작하는 데모: 숫자 대신, 실제로 눌러볼 수 있는 기능 단위 데모를 정기적으로 요구하세요. 굴러가는 화면 하나가 커밋 100건보다 정직합니다.
계약·회의에서 정해둘 것
- 진행률의 정의를 착수 시점에 합의하세요. '완료'는 코드 작성이 아니라 리뷰·테스트·수용 기준 통과까지로 못 박습니다.
- 정기 보고에 산출량 지표와 함께 재작업률·리뷰 대기 현황을 나란히 넣어달라고 요청하세요. 한쪽만 보면 착시가 생깁니다.
- AI 활용 여부와 무관하게, 사람이 검증하는 리뷰 단계에 충분한 시간과 인력이 배정돼 있는지 확인하세요. 병목은 대개 여기입니다.
국내 스타트업·중소기업 프로젝트는 오픈 일정이 투자 라운드나 마케팅 시점에 묶여 있는 경우가 많습니다. 그럴수록 '빨리 많이'라는 신호에 안심하기 쉬운데, 정작 오픈 직전에 재작업이 몰리면 일정은 더 밀립니다. 초반부터 흡수량 기준으로 진척을 보는 편이 결과적으로 더 빠릅니다.
속도는 수단이고, 안정적인 전진이 목적입니다
AI가 코드 생산을 가속한 것은 분명한 현실이고, 잘 다루면 발주사에도 큰 이점입니다. 다만 그 가속이 그대로 '진척'으로 번역되지는 않습니다. 빨라진 앞단만큼 검증과 안정성이 받쳐줘야 비로소 속도가 성과가 됩니다.
FIRSTPIP은 외주 개발 파트너로서, 커밋 그래프가 아니라 검증을 통과해 실제로 굳어진 결과물을 기준으로 진척을 투명하게 보고드리는 것을 원칙으로 삼습니다. 지금 진행 중인 프로젝트의 진행률 보고가 '만든 양'에만 기대고 있다면, 오늘 정리한 체크포인트로 한 번 점검해 보시길 권합니다. 숫자가 많아지는 것과 프로젝트가 나아가는 것은, AI 시대에 더더욱 같은 말이 아닙니다.