
생성형 AI의 효과 측정을 이용 횟수에서 제외하는 Python 집계
요약
생성형 AI 도입 효과를 단순 이용 횟수가 아닌 실제 작업 시간 단축과 재작업률로 측정하는 Python 집계 스크립트를 소개합니다. 작업 로그를 기반으로 AI 사용 전후의 성과를 정량적으로 분석하는 방법을 다룹니다.
핵심 포인트
- 단순 이용 횟수는 AI 도입의 실질적 성과를 왜곡할 수 있음
- 실제 작업 시간(actual_minutes)과 재작업률(rework_rate) 중심의 지표 설정 필요
- Python 표준 라이브러리를 활용한 데이터 집계 로직 구현
- 진행 중인 업무와 중복 데이터를 제외하여 데이터 신뢰성 확보
생성형 AI의 이용 횟수가 늘어나면 도입이 진척된 것처럼 보입니다. 하지만 영업이나 기획 현장에서 알고 싶은 것은 이용 횟수가 아닙니다. 업무가 끝나기까지 시간이 단축되었는지, 혹은 재작업 (rework)이 늘어나지는 않았는지입니다.
7월 28일에는 Google의 이용 데이터를 다룬 분석으로서 "많은 업무는 AI로 자동화되지 않았다"라는 기사도 나왔습니다. Ars Technica의 기사를 읽으며, 이용률만을 월간 보고서에 두는 위험성을 다시 한번 느꼈습니다. 채팅 횟수가 늘어난다고 해서 성과가 늘어났다고 단정할 수는 없습니다.
이용 횟수는 사내에서 사용할 수 있는 사람이 늘어났는지를 보는 보조선은 될 수 있습니다. 다만, 제안문을 몇 번이고 다시 만들거나, 출력물을 확인하는 시간이 늘어나더라도 횟수는 늘어납니다. 횟수가 높을수록 순조롭다고 해석하면, 현장에서 일어나고 있는 우회(돌아가는 과정)를 포착할 수 없습니다.
그래서 저는 작업 로그를 1태스크 1행으로 남기고, 완료 건수·실제 작업 시간·재작업률 (rework rate)을 동일한 표에서 보도록 하고 있습니다. 아래의 스크립트는 해당 CSV를 팀별로 집계하는 것입니다. Python 표준 라이브러리만으로 동작합니다.
열은 다음 8개입니다. baseline_minutes에는 AI를 사용하지 않았을 때의 동일 종류 업무에서 실제로 걸렸던 표준 시간을 넣습니다. 견적 시간이 아니라, 과거 로그를 통해 결정하는 것이 포인트입니다.
date,team,task_id,ai_used,baseline_minutes,actual_minutes,rework,status
2026-07-28,영업,S-101,yes,45,31,no,done
2026-07-28,영업,S-102,no,30,28,no,done
...
status가 done이 아닌 행은 집계하지 않습니다. 진행 중인 업무까지 "AI로 완료된 건수"에 포함하면, 도입 직후일수록 숫자가 좋아 보이기 때문입니다. task_id의 중복도 방지합니다. 동일한 안건을 이중으로 계산하는 실수는 스프레드시트에서는 의외로 찾아내기 어렵습니다. 참고로, AI 이용 여부에 따라 난이도가 다른 안건을 단순 비교하기 위한 표는 아닙니다. 우선은 팀 내의 변화를 추적합니다.
ai_effect_report.py로 저장하고, CSV와 같은 폴더에서 실행합니다.
import csv
import sys
from collections import defaultdict
...
실행은 이것뿐입니다.
python ai_effect_report.py work_log.csv
위의 6행을 사용한 출력은 다음과 같습니다. 진행 중인 P-203이 포함되지 않았음을 확인할 수 있습니다.
team,done_tasks,ai_tasks,ai_use_rate,baseline_minutes,actual_minutes,time_delta_minutes,rework_rate
기획,2,1,50.0%,140,120,-20,0.0%
영업,3,2,66.7%,135,101,-34,33.3%
time_delta_minutes는 실제 작업 시간에서 표준 시간을 뺀 값입니다. 음수라면 해당 팀은 시간을 단축하고 있는 것입니다. 다만 영업은 34분을 단축했음에도 재작업률이 33.3%입니다. 이 숫자만으로 "잘 되었다"라고 말할 수는 없습니다. 오히려 초안 작성에는 효과적이지만 리뷰 전 확인이 부족하다는 식으로, 다음에 살펴봐야 할 지점이 결정됩니다. 이 부분이 은근히 중요합니다.
오늘 아침, 수중에 있는 테스트용 6행으로 이 출력을 확인했을 때도, 진행 중인 1행을 제외하는 처리와 중복된 task_id에서 멈추는 처리를 나누어 확인했습니다. 집계 로직은 한 번 섞인 숫자를 나중에 수정하는 것보다, 입구에서 막는 것이 훨씬 편합니다.
이 집계는 인과관계를 증명하는 것이 아닙니다. 어려운 안건이 우연히 AI 이용 측에 편중되면, 시간과 재작업 모두 나쁘게 나올 수 있습니다. 안건의 종류가 다른 팀끼리 비교하는 용도로도 적합하지 않습니다.
첫 한 달은 동일한 팀의 전월 대비 수치만 보는 것으로 충분합니다. baseline_minutes를 정하는 방식을 도중에 바꾸지 말 것, 재작업의 정의를 팀 내에서 통일할 것. 이 두 가지를 지키면 숫자가 회의용 장식으로 끝나지 않습니다.
생성형 AI의 도입 효과는 이용 횟수 그래프만으로는 판단할 수 없습니다. 완료된 업무로 한정하여 시간 차이와 재작업을 나란히 두면, 다음에 개선해야 할 공정이 보입니다.
우선 이번 주의 정례 작업 5건만 기록해도 충분합니다. 숫자가 작을 때는 결론을 서두르지 말고 동일한 형식으로 계속 이어가세요. AI를 사용하는 것 자체보다, 업무가 앞으로 나아갔는지를 가시화하는 것이 영업이나 기획 분야에서는 더 오래 남는 가치라고 생각합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기