AI는 빨라졌는데 왜 일은 늦어졌나: 검증된 산출물까지의 시간을 재는 법

상반된 AI 생산성 연구를 작업·사용자·결과 정의의 차이로 읽고, 도입 성과를 초안 속도가 아니라 검증된 산출물까지의 시간으로 측정하는 방법을 제안한다.

생성형 AI를 업무에 처음 도입하면 속도 향상은 곧바로 눈에 띈다. 빈 문서가 채워지고, 코드 골격이 생기며, 회의록과 비교표가 몇 분 안에 나온다. 대시보드가 생성량과 응답 시간을 보여 주면 도입은 이미 성공한 듯 보인다.

막상 팀의 하루는 다른 곳에서 길어진다. 초안에 섞인 가정을 확인하고, 출처를 다시 열며, 테스트를 돌리고, 어긋난 요구사항을 다시 맞추는 시간이 늘어난다. 생성 단계에서 아낀 시간이 검토와 재작업으로 옮겨 갔는데도, 조직은 여전히 첫 출력의 속도만 측정할 수 있다.

하지만 “AI가 생산성을 높였는가”라고만 물으면 범위가 너무 넓다. 같은 도구도 어떤 작업을 누구에게 주었는지, 완료를 무엇으로 판정했는지에 따라 가속 장치가 되거나 새로운 마찰이 된다. 찬반을 먼저 가르기보다 측정 단위를 바꿔야 한다. 첫 초안까지의 시간과 검증된 산출물까지의 시간을 분리해야 한다.

같은 AI가 누구에게는 가속, 누구에게는 마찰이 되는 이유

2025년 METR 연구는 숙련된 오픈소스 개발자 16명이 익숙한 성숙 프로젝트에서 실제 과제 246개를 수행하도록 하고, 과제마다 초기 2025년 AI 도구 사용 허용 여부를 무작위로 배정했다. 참여자들은 평균 5년 동안 해당 저장소를 다뤘다. 연구 전에는 AI가 완료 시간을 24% 줄일 것이라고 예상했고, 연구 뒤에도 20% 빨라졌다고 추정했다. 실제 측정에서는 AI 사용 조건의 완료 시간이 19% 늘었다.[1]

이 수치만 보면 AI 코딩이 생산성을 떨어뜨린다는 결론을 내리기 쉽다. 그러나 연구가 관찰한 것은 숙련자가 잘 아는 대규모 코드베이스에서 경계가 분명한 실제 이슈를 해결하는 특정 조건이다. 참여자 수가 작고, 사용 모델과 도구는 2025년 상반기 수준이며, 저장소의 품질 기준과 암묵지가 높다. 연구진도 이 결과를 미래 모델이나 다른 개발 환경에 그대로 일반화하지 않는다.[1]

반대 방향의 현장 연구도 있다. 고객 지원 상담원 5,179명의 순차적 AI 도입을 분석한 Generative AI at Work는 시간당 해결 건수로 측정한 생산성이 평균 14% 높아졌다고 보고했다. 초보·저숙련 상담원은 34% 개선됐지만, 숙련·고숙련 집단에서는 영향이 작았다.[2]

두 결과 중 하나만 맞고 다른 하나는 틀렸다고 볼 필요는 없다. 개발 연구의 핵심 결과는 미리 정한 과제의 완료 시간이고, 고객 지원 연구의 핵심 결과는 시간당 해결 건수다. 전자는 숙련자가 복잡한 기존 시스템을 수정하는 일이고, 후자는 대화 중 축적된 모범 사례를 제안받아 반복 업무를 처리하는 일이다. 작업의 불확실성, 사용자의 기존 숙련도, 품질 기준, AI가 개입하는 위치가 모두 다르다.

이 차이를 지운 채 도입 효과를 하나의 평균값으로 묶으면 중요한 정보가 사라진다. AI가 빠른 초안을 만드는 능력과 조직이 유효한 결과를 더 빨리 내는 능력은 같은 지표가 아니다. 무엇이 개선됐는지 알려면 생성 이후의 검토와 수정까지 측정 범위에 넣어야 한다.

첫 초안 대신 ‘검증된 산출물까지의 시간’을 잰다

업무 생산성을 측정하려면 먼저 무엇을 완료로 볼지 고정해야 한다. 글이라면 필수 주장에 근거가 연결되고 공개 안전 검사를 통과한 상태, 코드라면 요구사항과 회귀 테스트를 통과한 상태, 고객 응대라면 문제가 실제로 해결되고 재접촉이 발생하지 않은 상태가 될 수 있다. “모델이 답변을 반환했다”는 사건은 이 완료 조건의 일부일 뿐이다.

검증된 산출물까지의 시간은 다음 구간으로 나눠 기록할 수 있다.

time_to_validated_outcome
= scope_definition
+ generation
+ review
+ rework
+ integration
+ acceptance

이 식은 보편적인 생산성 공식이 아니라 측정 경계를 드러내기 위한 운영 모델이다. generation만 줄어도 첫 출력은 빨라진다. 하지만 요구사항을 다시 정하는 scope_definition, 사실·코드·정책을 확인하는 review, 잘못된 출력을 고치는 rework, 기존 시스템과 합치는 integration, 최종 책임자가 판정하는 acceptance가 늘면 전체 완료 시간은 길어질 수 있다.

이 시간을 한 값으로 뭉개지 말고 나란히 보는 편이 낫다.

여기에 AI를 쓰지 않은 기준선이 필요하다. 같은 종류의 작업을 기존 방식으로 처리한 시간과 품질을 남기지 않으면, 어려운 일을 AI에 몰아주고 쉬운 일을 사람이 처리한 뒤 도구 효과를 비교하는 오류가 생긴다. 무작위 배정이 어렵다면 작업 난도, 사용자 숙련도, 저장소나 고객 유형, 검토 기준을 최소한 맞춰 비교해야 한다.

체감 속도도 별도 지표로 남길 가치가 있다. METR 연구에서는 참여자들이 실제로 느려진 조건에서도 사후에 더 빨라졌다고 추정했다.[1] 빠르게 나타나는 텍스트와 자동완성은 체감 대기 시간을 줄이지만, 중간중간 발생한 읽기·수정·맥락 전환은 한 덩어리의 비용으로 기억되지 않을 수 있다. 도입 만족도와 실제 완료 시간을 함께 보아야 “편해졌다”와 “빨라졌다”를 구분할 수 있다.

인간–AI 협업은 검토 비용의 위치를 다시 설계한다

AI 도입의 실무적 질문은 사람을 넣을지 뺄지가 아니다. 모델 앞에서 사람이 무엇을 판단하고, 모델 뒤에서 무엇을 검사할지 정해야 한다. 요구사항이 모호한 상태에서 생성량만 늘리면 검토자는 더 많은 후보를 읽어야 한다. 반대로 완료 기준과 금지 조건을 먼저 고정하면 모델의 탐색 폭을 실제 의사결정에 필요한 범위로 줄일 수 있다.

작업도 위험과 가역성에 따라 다르게 배치해야 한다. 다시 만들기 쉽고 결정론적으로 검사할 수 있는 변환은 자동화 비중을 높일 수 있다. 외부 공개, 비용 지출, 정책 판단, 고객 데이터 처리처럼 되돌리기 어렵거나 책임이 큰 작업은 사람의 승인과 실제 대상의 readback이 필요하다. 모든 단계에 같은 수준의 검토를 붙이면 자동화의 이점이 사라지고, 어느 단계도 검토하지 않으면 오류 비용이 뒤로 밀린다.

AKM 같은 지식 운영체계에 이 관점을 적용한다면 파일 수나 답변 수보다 검증을 통과해 다음 실행을 바꾼 지식을 결과 단위로 삼을 수 있다. 회수된 자료가 초안을 만들었는지뿐 아니라, 원문을 직접 확인했는지, 주장을 실제로 지지했는지, 충돌이 남았는지, 실행 뒤 절차나 평가 기준이 갱신됐는지를 단계별로 기록하는 방식이다. 이것은 특정 시스템의 성과를 입증하는 사례가 아니라, Execute → Verify → Learn Back의 비용과 효과를 함께 재기 위한 적용안이다.

검증을 생산성의 반대말로 놓으면 비용이 어디로 옮겨 갔는지 놓치기 쉽다. 검증을 생략하면 보고 시점의 속도는 좋아질 수 있지만, 게시 뒤 수정, 장애 복구, 고객 재접촉, 잘못된 지식의 재사용으로 비용이 이전된다. 반대로 모든 출력을 최고 위험 수준으로 심사하면 작은 작업까지 병목이 된다. 검토 강도는 실패의 영향, 되돌릴 수 있는 정도, 자동 검사의 신뢰도에 맞춰 달라져야 한다.

측정이 늘면 일이 자동으로 좋아지는 것은 아니다

time_to_validated_outcome도 완전한 지표는 아니다. 창의적 아이디어, 학습 효과, 팀의 자신감, 장기 유지보수성처럼 당장 승인 여부로 환원하기 어려운 가치가 있다. 고객 지원의 시간당 해결 건수와 복잡한 소프트웨어 변경의 완료 시간은 서로 바꿔 쓸 수 없다. 같은 조직에서도 탐색, 초안 작성, 의사결정, 외부 실행에는 각기 다른 측정 계약이 필요하다.

측정에도 비용이 든다. 타이머와 분류표 관리가 사람의 본업을 방해할 수 있고, 지표가 평가와 보상에 연결되면 쉬운 작업을 고르거나 결함 보고를 늦추는 행동이 생길 수 있다. rework_cycles를 줄이려다가 필요한 수정을 숨길 수도 있다. 그래서 지표는 개인 순위를 만드는 도구보다 시스템의 병목을 찾는 진단 장치로 사용하는 편이 안전하다.

연구 결과의 시간 경계도 중요하다. 모델, 인터페이스, 사용 습관은 빠르게 바뀐다. 2025년 상반기의 코딩 도구 결과가 2026년의 모든 에이전트 환경을 대신할 수 없고, 한 기업의 고객 지원 결과가 창작·법률·교육 업무의 기준이 될 수도 없다. 도입 뒤에도 같은 과제군과 완료 기준으로 재측정하고, 모델이나 워크플로가 크게 바뀌면 기준선을 다시 열어야 한다.

도입 평가를 “몇 퍼센트 빨라졌는가”로 끝내서는 안 된다. 어떤 사용자가 어떤 작업을 맡았는가, 첫 출력 뒤 어떤 검토와 재작업이 발생했는가, 완료를 누가 무엇으로 판정했는가, 승인 뒤 오류 비용은 어디로 갔는가를 함께 물어야 한다. 이 질문들이 기록되지 않으면 빠른 초안은 쉽게 빠른 업무로 오인된다.

도입의 성공은 모델이 가장 빨리 말한 순간이 아니라, 사람이 결과를 믿고 사용할 수 있게 된 순간에서 판정해야 한다. AI가 줄여야 할 것은 타이핑 시간만이 아니다. 목표 설정부터 생성, 검토, 수정, 통합, 승인까지 이어지는 전체 경로에서 불필요한 마찰은 줄이고, 신뢰에 필요한 마찰은 보이게 해야 한다. 그때 AX는 빠른 생성 기능을 더하는 일이 아니라 신뢰 가능한 결과까지의 경로를 다시 설계하는 일이 된다.

Sources

[1] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — arXiv (2025) [2] Generative AI at Work — The Quarterly Journal of Economics (2025) · 공개 working-paper PDF