AI가 성과를 올렸는지 아무도 모른다, 사용량 말고 산출을 재는 도구

어떤 문제인가

회사는 AI를 쓰라고 밀어붙이고, 그 성과를 사용량으로 잰다. 좌석 몇 개, 프롬프트 몇 번, 코드 제안 수락률 몇 퍼센트. 문제는 사용량이 산출이 아니라는 점이다. 많이 썼다고 일이 나아졌다는 보장이 없고, 심지어 강제가 걸리면 사용량 지표는 채우기 쉽게 부풀려진다. 관리자는 대시보드의 파란 그래프가 오르는 걸 보며 잘 되고 있다고 믿지만, 정작 팀의 결과물이 전보다 좋아졌는지는 모른다.

증거는 이 착시를 정면으로 가리킨다. 임원 약 6,000명을 조사한 NBER 연구에서 80%가 넘는 기업이 AI로 뚜렷한 생산성 영향을 못 느꼈다. 개발 쪽 텔레메트리는 더 매섭다. 패로스 AI가 개발자 2만 2천 명을 2년간 추적했더니 75%가 AI 도구를 쓰는데도 대다수 조직에서 성과 개선이 측정되지 않았고, 처리량은 66% 늘었지만 사고와 버그가 그보다 빨리 늘었다. 병합된 PR 한 건당 운영 장애 확률은 1년 새 세 배가 넘었고 개발자당 버그는 54% 늘었다. 사용량은 오르는데 품질은 내려가는 구간이 실재한다는 뜻이다. 관리자는 그 사이에서 눈을 가린 채 판단하고 있다.

왜 지금인가

지금 두 흐름이 겹친다. 하나는 AI 의무화가 널리 퍼졌다는 것. 위에서 사용을 강제하는 회사가 늘수록, 사용량이 아니라 진짜 효과를 대는 측정에 대한 목마름도 커진다. 다른 하나는 기존 도구의 사각지대다. 엔지니어링에는 이미 측정 도구가 있다. 패로스 AI나 DX의 DX Core 4가 깃·PR 텔레메트리로 처리량과 품질을 잡는다. 그런데 두 가지가 비어 있다. 첫째, 이 도구들도 상당 부분은 여전히 사용량과 처리량을 보고한다. 인과적으로 “이 사람이 AI 덕분에 정말 나아졌는지”까지는 잘 가르지 못한다. 둘째, 영업·지원·운영·마케팅·법무처럼 깃 로그가 없는 지식 노동에는 대응 도구가 거의 없다. 의무화는 이 전 직군에 걸리는데, 측정은 개발팀에서 멈춰 있다.

flowchart LR
  A[도입 전 기준선<br/>사람별 산출·품질] --> C[인과 측정<br/>홀드아웃·단계적 롤아웃]
  B[AI 사용 후 산출<br/>속도·재작업·오류율] --> C
  C --> D[사람별 실제 개선<br/>품질 보정 델타]
  D --> E[관리자용 정직 신호<br/>사용량 아닌 산출]

어떻게 만들 수 있나

한 직군, 산출이 눈에 잡히는 곳부터 좁게 시작한다. 예를 들어 고객지원이라면 티켓 해결 시간, 재문의율, 품질 평가 점수가 산출이 된다. 핵심은 세 가지다. 첫째, 도입 전 기준선을 사람별로 남긴다. 둘째, 인과적으로 잰다. 누구는 먼저 AI를 켜고 누구는 나중에 켜는 단계적 롤아웃이나 홀드아웃 집단을 써서, 상관이 아니라 실제 개선분을 뽑는다. 셋째, 품질로 보정한다. 빨라졌지만 재작업·오류·장애가 늘었다면 그 손실을 산출에서 깐다. 그렇게 나온 사람별 델타를 관리자에게 조용히 넘긴다. 감시가 아니라 코칭 신호로 쓰이게 접근 권한과 표시 방식을 좁혀야 한다.

수익은 팀·좌석 단위 구독이 자연스럽다. 도입의 초기 저항을 낮추려면 처음부터 사람을 줄 세우지 말고, 어떤 작업 유형에서 AI가 실제로 먹히고 어디서는 헛도는지 팀 단위 지도부터 그려주는 게 좋다. 개인 랭킹은 신뢰가 쌓인 뒤에.

성공 조건

두 조건이 맞아야 한다. 첫째, 게이밍에 강하고 품질로 보정된 산출 지표를 직군마다 정의할 수 있어야 한다. 지표가 허술하면 이 도구도 결국 또 하나의 사용량 대시보드로 전락한다. 둘째, 조직이 “이 의무화는 안 먹혔다”는 정직한 신호를 받아들일 수 있어야 한다. AI 도입을 밀어붙인 경영진에게 효과 없음을 들이대는 건 정치적으로 불편한 일이고, 그 불편을 견디는 문화가 없으면 도구는 서랍에 들어간다. 이 둘을 넘긴 팀은 사용량 게임을 걷어내고, AI가 어디서 진짜로 일을 낫게 하는지에 처음으로 값을 매긴다. 그다음 질문은 하나다. 우리 팀에서 AI가 실제로 나아지게 한 작업은, 지금 몇 개인가.