전 직원이 AI를 쓰면 AX 성공일까: 역량 평가와 성과 검증법

직원 모두에게 AI 계정을 지급했다는 발표는 눈길을 끈다. 그러나 실제 업무가 나아졌는지는 별개의 질문이다. AI 활용 능력은 무엇으로 평가하고, 전사 AX의 성공은 어떤 증거로 확인할 수 있을까?

사용률은 출발점이지 성과가 아니다

클코단에서는 AI 활용 능력을 시험하는 도구를 찾는 질문이 나왔다. 전사 AX 성공담의 근거를 확인해야 한다는 의견도 있었다. 구성원이 겪는 변화가 대외적으로 소개된 사례와 다를 수 있다는 반응도 나왔다. 다만 이 논의만으로 특정 기업의 발표가 틀렸다고 판정할 수는 없다.

Microsoft의 2025년 Work Trend Index에서는 조사에 참여한 리더의 24%가 조직 전반에 AI를 배포했다고 답했다. 그 수치는 도입 범위를 보여주지만 업무 품질이나 고객에게 전달한 가치까지 증명하지는 않는다. Microsoft가 설명한 전환 단계도 개인의 AI 보조, 사람과 에이전트의 협업, 사람의 감독 아래 운영되는 업무 흐름을 구별한다. 같은 보고서에 나온 ‘전사 배포’를 곧바로 마지막 단계의 달성으로 읽을 수 없는 이유다. (microsoft.com)

업무를 쪼개 보면 차이가 선명해진다. 직원이 Claude Code로 초안을 더 빨리 작성하는 일은 개인의 도구 활용이다. 요구사항 전달부터 검토·테스트·배포 판단까지 달라지고 그 변화가 반복해서 확인된다면, 업무 방식이 바뀌었다고 볼 근거가 생긴다. 조직 전체를 평가하려면 개발팀 밖의 업무에도 같은 질문을 던져야 한다.

AI 역량 평가는 무엇을 시험해야 하나

AI 활용 능력을 하나의 점수로 매기기는 어렵다. 원하는 답을 얻도록 지시하는 능력과 그 답이 틀렸을 때 알아채는 능력은 다르다. 업무 자료를 어디까지 입력해도 되는지 판단하거나 사람에게 결정을 넘기는 능력도 별도로 봐야 한다.

시중의 자격 평가가 제공하는 범위를 먼저 확인할 필요가 있다. Microsoft Applied Skills의 Microsoft Foundry 에이전트 평가는 대화형 실습에서 모델 배포, 에이전트 생성, 테스트를 살핀다. 실제 수행을 관찰한다는 장점은 있지만, 이 평가의 통과를 모든 직무의 AI 역량이나 회사 AX 성과로 확대할 수는 없다. UNESCO의 교사용 AI 역량 체계 역시 활용 기술뿐 아니라 윤리, 인간의 주도권, 업무에 맞는 적용을 나눠 다룬다. (learn.microsoft.com)

작은 팀이라면 공통 퀴즈보다 실제 직무 과제가 더 직접적일 수 있다. 예를 들어 개발자에게 재현 가능한 버그 설명과 테스트 저장소를 주고 수정안과 검증 결과를 제출하게 한다. 평가자는 완료 여부뿐 아니라 잘못된 가정을 찾아낸 과정, 변경 범위, 테스트 실패에 대한 대응도 기록한다. 이는 특정 제품의 공인 평가법이 아니라 팀의 업무에 맞춰 검토할 수 있는 과제 설계다.

성공 사례의 숫자는 어디서부터 읽을까

공개 사례에는 유용한 단서가 있다. Anthropic이 소개한 Rakuten의 Claude Code 사례는 새 기능의 출시 소요 기간이 평균 24영업일에서 5영업일로 줄었다고 전한다. 다만 공급자가 게시한 고객 사례라는 출처와 측정한 업무의 범위·기간을 함께 읽어야 한다. 그 숫자만으로 회사 모든 부서가 같은 속도로 변했다고 말할 수는 없다. (anthropic.com)

반대 방향의 근거도 있다. 연구단체 METR은 2025년 초, 익숙한 대형 오픈소스 저장소에서 일하는 숙련 개발자를 조사했다. 해당 실험에서는 AI 도구를 허용한 작업의 완료 시간이 평균 19% 더 길었다. METR은 2026년 후속 연구를 설명하며 도구와 사용 환경이 바뀌었고 새 실험에는 참가자 선택 편향이 있어 현재 효과의 크기를 확정하기 어렵다고 밝혔다. 한 사례의 속도 향상도 이전 실험의 지연도 모든 팀에 적용되는 판결은 아니다. (metr.org)

사례를 읽을 때는 발표된 숫자의 분모를 물어야 한다. 어느 팀의 어떤 작업이었는가. 시작과 종료를 어디로 잡았고 검토와 재작업 시간을 포함했는가. 고객이 받은 결과물의 품질과 비용은 어떻게 확인했는가. 답이 빠진 사례는 시도해 볼 이유가 될 수는 있어도 전사 AX의 검증 자료로는 부족하다.

Claude Code로 한 업무를 시험하는 순서

Claude Code를 쓰는 소규모 개발팀이라면 추상적인 ‘활용률’보다 반복되는 업무 하나를 고르는 편이 낫다. 가령 매주 들어오는 버그 수정을 위해 이슈 설명, 관련 코드와 기존 테스트를 준비한다. 작업 전에는 사람이 소요 시간과 완료 기준을 적는다. Claude Code에는 원인 조사와 수정안, 테스트 실행 결과를 요청한다. 담당자는 변경 사항을 검토한 뒤 필요한 수정을 하고 검토에 든 시간까지 남긴다.

산출물은 실행된 코드만이 아니다. 이슈별로 최초 수정안, 테스트 결과, 사람의 검토 기록, 다시 고친 횟수가 남아야 비교가 가능하다. AI를 쓰지 않은 유사 작업과 비교하더라도 난도와 담당자의 경험이 다르면 숫자를 그대로 맞세우지 않는다. 검토가 밀려 전체 완료가 늦어진다면 초안 생성 시간만 줄었다고 성공이라 부르기 어렵다.

DORA의 2025년 연구는 AI 활용이 많은 조직에서 소프트웨어 전달량과 전달 과정의 불안정성이 함께 늘어나는 연관성을 보고했다. 연구는 도구 자체보다 도구를 받아들이는 조직의 일하는 방식을 강조한다. 실제로 써본 사람들 사이에는 초안은 빨라졌어도 검토 부담이 커졌다는 반응과 익숙한 작업을 덜어 다른 일에 집중할 수 있었다는 반응이 공존한다. 자기 팀에는 어느 쪽이 가까운지 알려면 작업 전체를 기록해야 한다. (dora.dev)

사람의 승인 지점까지 바뀌었는가

위험이 큰 업무에서는 빠른 초안보다 판단을 멈추는 지점이 중요하다. AI가 자료를 정리하거나 누락된 항목을 표시하더라도 확인되지 않은 조건을 채워 넣어 승인까지 진행해서는 안 된다. 미국 NIST의 AI 위험관리 프레임워크는 적용할 업무와 성능을 정의하고 사람의 감독 절차와 책임을 문서화하도록 제시한다. (airc.nist.gov)

영상 속 가상 제조 현장처럼 작업 단계와 안전 자료를 대조하는 구상은 평가 과제를 만드는 데 참고할 수 있다. 그러나 그 장면의 시간 절감이나 완전한 위험 탐지를 실제 성과로 받아들일 근거는 없다. 시험할 질문은 명확하다. 핵심 정보가 빠졌을 때 시스템이 무엇을 표시하는가. 누가 현장을 확인하고 누구의 승인 전에는 다음 단계로 가지 못하는가.

클코단에서 제기된 의문은 AI를 몇 명이 쓰는지보다 무엇이 달라졌는지를 묻는다. 전사 AX 성공담의 무게는 사용 계정 수가 아니라 업무의 시작부터 최종 승인까지 남은 기록이 결정한다.