사용자 경험 전문가 폴 보그는 10월 16일 스매싱 매거진 기고에서 조직의 AI 도입 방식이 과거 디지털 전환의 시행착오를 반복한다고 지적했다. 새 시스템을 제공해도 직원이 자신의 업무에 적용할 이유와 여건을 찾지 못하면 변화가 멈춘다는 주장이다. 그는 2014년 저서의 문제의식을 현재에 연결한다. 이 글은 여러 조직을 대상으로 효과를 측정한 통계 연구가 아니며, 저자의 관찰과 자문 경험을 토대로 한 비평이다. 특정 도구를 쓰면 성과가 난다는 제품 비교 기사로 읽기보다 조직 운영에 관한 질문으로 읽어야 한다.
학습 시간을 주지 않는 생산성 요구
보그가 강조하는 것은 직무에 맞는 학습과 동료 간 경험 공유다. AI가 개인에게 어떤 불편을 줄여 주는지 설명하지 않은 채 더 많은 결과만 요구하면 수용 동기가 약해질 수 있다고 본다. 사용을 독려하면서 실험 과정의 실수나 토큰 사용을 과도하게 문제 삼는 조직의 모순도 짚었다. 승인된 도구가 실제 업무를 해결하지 못해 개인 계정으로 자료를 옮기는 현상은 통제 실패의 신호로 다룬다. 다만 이런 사례가 모든 조직에서 같은 빈도로 발생한다거나 특정 성과를 보장한다는 수치로 제시된 것은 아니다.
사용자 요구에서 출발하는 공식 원칙
함께 참고할 영국 정부의 디자인 원칙은 사용자 요구를 조사하고 실제 이용 데이터를 보며 서비스를 반복 개선하도록 안내한다. 작게 시작해 사용자에게 시험하고, 작동하지 않는 기능은 바꿀 수 있어야 한다는 내용이다. 이 문서는 AI 도입을 위한 실험 결과가 아니라 공공 서비스 설계의 운영 원칙이다. 따라서 보그의 주장에 대한 독립적인 성능 검증으로 볼 수는 없다. 대신 직원도 내부 도구의 사용자라는 관점에서, 도구를 먼저 정하기 전에 업무 맥락을 확인해야 한다는 설계 기준을 제공한다.
도구를 켠 횟수와 일을 끝낸 방식의 차이
라이선스를 받은 사람 수나 로그인 횟수는 접근의 지표다. 같은 자료를 정리할 때 초안에 걸린 시간과 사람이 고친 시간, 다시 확인한 횟수는 작업의 지표다. 도입을 평가할 때 이 둘을 구별하면 사용을 독려한 결과와 실제로 일이 달라진 결과를 나눠 볼 수 있다.
예를 들어 반복 보고서의 초안이 빨리 나와도 검토가 더 오래 걸리면 전체 흐름의 변화는 따로 계산해야 한다. 이 예시는 글의 관점에서 도출한 비교이며 특정 조직의 측정 결과는 아니다. 정부 디자인 원칙의 사용자 요구·반복 개선도 이런 관점을 참고하게 하지만 AI 도입 효과를 검증한 별도의 실험으로 볼 수는 없다.
| 관찰 | 확인하는 것 |
|---|---|
| 계정·로그인 | 도구에 접근했는가 |
| 초안 작성 | 첫 결과까지 어떤 일이 줄었는가 |
| 검토·수정 | 결과를 쓸 수 있게 만드는 부담은 어떤가 |
| 반복 업무 | 다음 작업에서도 같은 흐름으로 쓸 수 있는가 |
AI 도입에 관한 비평은 라이선스 배포 밖의 학습 시간·동기·업무 선택을 묻는다. 작은 업무에서 결과와 검토 부담을 비교하고 사용자가 수정·중단할 수 있는 조건을 함께 마련해야 한다.
ARCH.B 의견
내부 도구의 사용자도 일을 끝내려는 사람이다. 사용 횟수를 늘리는 목표만 두면 그 과정에서 어떤 검토와 정리가 추가됐는지를 놓칠 수 있다. 작은 반복 업무의 시작과 끝을 함께 살피는 것이 조직의 변화라는 큰 말을 구체적으로 만드는 방법이다.
동료와 공유할 기록도 잘 나온 프롬프트 하나에서 끝나지 않을 수 있다. 어떤 자료를 넣었고 어느 결과를 고쳤는지 함께 남기면 다음 사람은 완성 예시와 사용 조건을 동시에 볼 수 있다. 이 글을 성과의 보장보다 업무를 관찰하는 질문으로 읽을 이유다.
