Chapter 13

사람과 조직: 변화 관리

AX가 실패하는 이유를 추적하면 마지막에는 거의 언제나 사람이 나온다. 모델이 나빠서가 아니라 아무도 쓰지 않아서, 쓰는 사람이 일만 늘었다고 느껴서, 현업이 "IT가 만든 것"이라고 선을 그어서 실패한다. 이 장은 AI 조직의 운영 모델, 현장에 들어가 함께 만드는 FDE, 명함이 아니라 실제로 작동하는 역할, 전 직원 역량 체계, 저항의 원인과 변화 관리 프레임워크, 그리고 새 도구가 조직에 퍼지는 속도를 설명하는 확산 모델을 다룬다.

중앙 CoE, 허브-스포크, 연합형 운영 모델의 장단점을 비교하고 우리 조직의 단계에 맞는 모델을 고를 수 있다.
CoE 엔지니어가 현업 팀에 상주해 함께 만들고 재사용 부품을 플랫폼으로 되돌리는 FDE 방식을 운영하고, 그 성과를 "떠난 뒤"로 평가할 수 있다.
도메인 전문가·프로덕트 오너·데이터/AI 엔지니어·데이터 스튜어드·AX 챔피언의 역할과 "현업이 주인"이어야 하는 이유, 역할이 작동하는 다섯 조건(권한·시간·예산·지원·평가)을 설명할 수 있다.
저항의 신호를 원인(불안·추가 업무·불신·평가)별로 진단하고 ADKAR, 코터 8단계로 대응을 설계할 수 있다.
Bass 확산 모델의 혁신 계수 p와 모방 계수 q로 채택 곡선을 해석하고, 교육·챔피언·사용 마찰이 확산에 미치는 영향을 추정할 수 있다.

파일럿은 성공했는데, 아무도 쓰지 않는다

A사(글로벌 전자부품 제조사) 품질 부문은 6개월 동안 고객 클레임 대응을 돕는 AI 도구를 만들었다. 과거 8D 보고서에서 유사 사례를 찾아 주고, D2~D4 초안을 써 준다. 파일럿에 참여한 엔지니어 다섯 명은 만족했고, 경영진 보고에서는 "초안 작성 시간 예시 60% 단축"이라는 숫자가 나왔다. 그리고 전사 오픈 석 달 뒤, 주간 활성 사용자는 대상자 120명 중 열한 명이었다.

현장을 돌아보면 이유가 보인다. 2파트 박 파트장은 이렇게 말한다. "엑셀 양식에 바로 쓰면 10분인데, 이 도구는 클레임 번호를 시스템에 다시 입력하고, AI가 쓴 초안을 검토하고, 틀린 부분을 고치고, 결국 엑셀에 다시 옮겨야 해요. 30분이 걸립니다. 그리고 AI가 쓴 걸 그대로 냈다가 틀리면 누가 책임집니까?" 박 파트장은 변화를 싫어하는 사람이 아니다. 그의 계산이 맞다. 도구는 기존 업무에 한 단계를 더했을 뿐, 어떤 단계도 없애지 않았다.

이 장면에는 AX 조직 문제의 거의 모든 요소가 들어 있다. 파일럿 참여자는 자발적인 얼리어답터였고(대표성 없음), 도구는 기존 양식·시스템과 연결되지 않았고(사용 마찰), 책임 기준이 없었고(불신), 파트장의 KPI에는 도구 사용으로 얻는 것이 없었다(인센티브). 기술은 마지막 한 걸음까지 왔지만, 일하는 방식은 한 걸음도 움직이지 않았다.

"채택"이 아니라 "업무 재설계"를 목표로

AI 도구를 기존 업무 위에 얹으면 일이 늘어난다. 도구를 넣으면서 무엇을 빼는지를 같이 설계해야 한다. 박 파트장의 경우라면 엑셀 양식을 없애고 도구 안에서 8D 보고서가 완성되게 하거나, 도구가 엑셀 양식을 직접 채우게 해야 한다. 그리고 AI 초안을 어디까지 검토하면 되는지 기준을 정해야 한다. 이것이 3장의 프로세스 재설계가 사람 문제와 만나는 지점이다.

운영 모델: 중앙 CoE, 허브-스포크, 연합형

AI 역량을 조직 어디에 둘 것인가는 AX의 첫 번째 구조 결정이다. 크게 세 가지 형태가 있다. 정답은 없고, 조직의 성숙도에 따라 옮겨 가는 것이 일반적이다.

그림 13-1. 세 가지 운영 모델. 중앙 CoE(Center of Excellence)는 AI 인력과 표준을 한곳에 모으고, 허브-스포크는 플랫폼·거버넌스·고급 인력은 허브에 두되 각 사업부에 AI 담당을 심고, 연합형은 사업부가 자체 AI 팀을 갖고 공통 표준만 함께 지킨다.

모델	장점	단점	잘 맞는 상황
중앙 CoE	희소 인재 집중, 표준·플랫폼 일관성, 보안 통제 쉬움	요청 대기열 병목, 현업과 거리감, "IT 과제"로 인식	AX 초기, AI 인력이 적을 때, 보안 민감도가 높을 때
허브-스포크	공통 플랫폼 + 현업 밀착, 재사용과 속도의 균형	이중 보고 라인, 스포크 인력의 소속감·경력 경로 문제	여러 사업부가 각자 유스케이스를 가질 때, 확산 단계
연합형	사업부 자율과 속도, 도메인 깊이	중복 투자, 도구·데이터 파편화, 표준 이탈	사업부별 데이터 성숙도가 높고 사업 성격이 크게 다를 때

INTERACTIVE

운영 모델 선택기

사업부(사업장) 수 사업 간 다양성 데이터 성숙도 사업부 내 데이터·AI 인력 보안·규제 민감도

FDE: 현장에 들어가 함께 만드는 엔지니어

어느 운영 모델을 고르든 한 가지 간극이 남는다. 기준과 맥락은 현장에만 있는데, AI를 만들 줄 아는 사람은 현장 밖(CoE, IT, 외부 업체)에 있다. 요구사항 문서로 이 간극을 메우려 하면 문서에는 "수율 데이터로 다음 조건 추천" 한 줄만 남고, "2팀은 작년 4월부터 수율 정의가 다르다"는 사실은 빠진다. 현장 사람은 그것이 중요한지 모르고, 개발자는 그런 것이 있는지 모른다.

FDE(Forward Deployed Engineer)는 이 간극을 사람으로 메우는 방식이다. 원래는 일부 소프트웨어·AI 기업이 고객사 현장에 엔지니어를 보내 실제 데이터와 업무 위에서 시스템을 만들게 하는 직무의 이름으로 알려졌다. 사내 AX에서는 이렇게 번역할 수 있다. CoE(허브)의 엔지니어가 현업 팀(스포크)에 일정 기간 상주하며, 그 팀의 실제 업무와 데이터 위에서 함께 만들고, 만든 것 중 일반화할 수 있는 것을 공통 플랫폼으로 되돌린다. 허브-스포크를 사람으로 잇는 방법이자, 앞의 "CoE는 스스로를 덜 필요하게 만든다"는 원칙을 실행하는 방법이다. 기준과 맥락이 자주 바뀌는 연구·실험 조직(7장)에서 특히 효과가 크다.

그림 13-2. 사내 FDE의 순환. 핵심은 ③이다. 상주해서 만든 것이 그 팀만의 맞춤 도구로 끝나면 FDE는 비싼 외주 개발자와 다르지 않다. 두 번째 팀부터 같은 부품(이슈 카드 추출기, 기준 레지스트리 템플릿, 평가 세트 양식)을 재사용할 수 있어야 한다.

방식	어디서 일하나	무엇을 남기나	한계
강의·컨설팅	강의실·회의실	개념, 동기, 전략 문서	업무에 붙지 않으면 잊히고, 실행은 남는 사람의 몫
SI·외주 개발	개발사	요구사항대로 만든 시스템	요건이 계속 바뀌는 업무에 약하다
중앙 CoE 접수형	CoE	요청받은 도구	대기열 병목, 현장 맥락 손실
FDE 상주형	현업 팀 안	돌아가는 업무 + 팀의 역량 + 재사용 부품	인력이 귀하다. 환류가 없으면 맞춤 도구만 늘어난다

사내 FDE를 운영하는 법

기간과 졸업 조건을 먼저 정한다. 수 주~한 분기 단위로 잡고, 시작할 때 "FDE 없이도 팀이 이 도구를 운영하고 기준을 갱신한다" 같은 졸업 조건을 적는다.
팀에서 짝을 한 명 붙인다. FDE가 떠난 뒤 운영할 사람이고, 다음 단계의 AX 챔피언이 된다.
실제 업무 한 건을 끝까지 관통한다. 데모가 아니라 이번 주의 실제 건이 처리되어야 한다(17장의 얇은 수직 슬라이스).
환류를 의무로 만든다. 상주 기간의 일정 부분은 만든 것을 일반화해 플랫폼으로 올리는 데 쓰고, 이것을 FDE의 성과 지표에 넣는다.
성과는 "떠난 뒤"로 잰다. 졸업 3개월 후에도 쓰이는가, 팀이 스스로 확장했는가, 다음 팀이 재사용한 부품이 몇 개인가.
도메인 출신을 FDE로 키운다. 외부 개발자에게 공정을 가르치는 것보다 공정을 아는 엔지니어에게 AI로 만드는 법을 가르치는 편이 빠른 경우가 많다. 현업 출신 빌더가 가장 좋은 후보다.

FDE는 직무명보다 일하는 방식이다

FDE라는 직함을 만들 필요는 없다. 중요한 것은 "만드는 사람이 쓰는 사람 옆에 앉는다", "요구사항 문서가 아니라 실제 데이터로 시작한다", "한 팀에서 배운 것을 다음 팀이 재사용한다"는 세 가지다. 인원이 적다면 CoE 엔지니어 한 명이 분기마다 한 팀씩 옮겨 다니는 것으로도 시작할 수 있다.

역할: 현업이 주인이고, 명함이 아니다

AI 유스케이스는 소프트웨어 프로젝트처럼 "요구사항을 주면 IT가 만들어 준다"로는 성공하지 않는다. 이유는 세 가지다. ① 정답을 아는 사람이 현업뿐이다. AI 출력이 맞는지 판단하고 평가 세트를 만드는 일은 도메인 전문가만 할 수 있다(12장). ② 업무 재설계 권한이 현업에 있다. 엑셀 양식을 없애고 결재 단계를 바꾸는 결정은 IT가 할 수 없다. ③ 운영 중 개선이 끝없이 필요하다. 만들고 넘기는 방식으로는 문서·공정·고객이 바뀔 때 따라가지 못한다.

그림 13-3. 유스케이스 하나를 끝까지 책임지는 프로덕트 팀. 왼쪽 세 역할은 현업에서, 오른쪽 세 역할은 허브(CoE)나 IT에서 온다. 한 사람이 여러 역할을 겸할 수 있지만, 프로덕트 오너가 현업이 아니면 "IT 과제"가 된다.

PRODUCT OWNER

프로덕트 오너

현업 팀장·파트장급. 무엇을 만들지, 어떤 업무 단계를 없앨지, 성공을 무엇으로 측정할지 결정한다. 이 사람의 KPI에 유스케이스 성과가 들어가야 한다.

DOMAIN EXPERT

도메인 전문가

20년 차 공정 엔지니어, 클레임을 수백 건 처리한 품질 담당. 평가 세트의 정답을 확정하고, AI가 틀리는 패턴을 찾는다. 업무 시간의 일부를 공식적으로 배정해야 한다.

STEWARD

데이터 스튜어드

불량 코드·설비 명칭·단위 같은 기준정보의 관리자(5장). AI 검색이 같은 불량을 다른 이름으로 놓치지 않게 한다.

CHAMPION

AX 챔피언

팀 안의 자발적 파워유저. 공식 교육보다 "옆자리 동료가 쓰는 걸 본 것"이 더 강하게 퍼진다. 챔피언에게는 시간과 인정을 공식적으로 줘야 한다.

역할은 명함이 아니다

AX 조직을 만들 때 가장 쉬운 일은 이름을 붙이는 것이다. "AX 챔피언", "AI 리더", "데이터 오너". 이름을 받은 사람은 대개 본업을 그대로 하면서 역할을 하나 더 얹고, 몇 달 뒤 그 역할은 회의 참석과 취합 담당이 되어 있다. 위의 역할들이 실제로 작동하려면 다섯 가지가 함께 와야 한다.

요소	명함뿐인 역할	작동하는 역할
권한	"추진해 주세요"	양식·업무 단계·우선순위를 바꿀 수 있는 범위가 문서로 정해져 있다
시간	본업 + 알파	업무 시간의 일정 비율이 공식 배정되고, 그만큼 본업이 줄어든다
예산	필요하면 품의	도구·컴퓨트·외부 지원에 쓸 작은 재량 예산이 있다
지원	"모르면 물어보세요"	FDE·CoE·플랫폼 조직이 함께 만들어 준다(앞 절)
평가	평가 항목에 없음	역할의 성과가 본인 평가에 들어가고, 상사도 그것을 안다

"누구든 역할을 주면 된다"가 위험한 이유

역할을 주는 것은 비용이 들지 않아 보여서 가장 흔한 AX 투자 방식이 된다. 하지만 시간과 권한 없이 역할만 받은 사람은 본업을 희생하거나 역할을 형식적으로 수행하는 것 중 하나를 고른다. 어느 쪽이든 조직은 비용을 치른다. 역할을 하나 만들 때마다 "이 사람의 어떤 일을 덜어 줄 것인가"를 함께 정하자. 역할에 드는 사람 시간을 투자 예산의 한 항목으로 다루는 법은 17장에서 본다.

역량 체계: 전 직원 리터러시에서 전문가까지

"전 직원 AI 교육"을 한 번 하고 끝내는 회사가 많다. 그러나 필요한 역량은 층마다 다르다. 모든 사람이 모델을 만들 필요는 없지만, 모든 사람이 AI에 무엇을 넣으면 안 되는지, 출력을 어떻게 검증하는지는 알아야 한다. 흔히 쓰는 4층 구조는 다음과 같다(비율과 시간은 예시).

AI 리터러시 · 전 직원생성형 AI가 무엇을 잘하고 못하는지, 환각과 검증, 데이터 등급별 사용 기준, 승인 도구 사용법. 반나절~하루 수준.
파워유저 · 직원의 일부업무에 맞는 프롬프트 작성, 사내 검색·요약 도구 활용, 자기 업무의 반복 작업을 AI로 바꾸기, 동료 코칭. 수일 과정 + 실습 과제.
빌더 · 소수노코드·로우코드 도구로 업무 자동화와 간단한 에이전트 워크플로 구축, 평가 세트 작성, 데이터 정리. 수주 과정 + 실제 과제 졸업.
전문가 · 극소수데이터·AI 엔지니어, ML 운영(MLOps), 보안. 채용과 장기 육성, 외부 협력.

층별 인원을 정하면 교육 부담이 계산된다. 대부분의 시간은 꼭대기 전문가가 아니라 가장 넓은 바닥층에서 소모된다는 점, 그리고 실습형 과정은 반(코호트) 단위로 운영되어 강사·멘토가 병목이 된다는 점을 확인해 보자.

INTERACTIVE

역량 피라미드와 교육 필요량 계산

대상 인원 파워유저 비율 빌더 비율 전문가 비율 코호트(반) 정원

총 교육 시간—

1인 평균—

실습 코호트 수—

현업 1명당 챔피언 비—

교육 시간(예시 가정): 리터러시 8시간(전원), 파워유저 +24시간, 빌더 +80시간, 전문가 +200시간(재교육·심화). 파워유저·빌더 과정은 코호트 단위로 운영한다고 보고 반 수를 계산했다. 마지막 지표는 파워유저 1명이 맡는 동료 수로, 챔피언 네트워크의 밀도를 가늠하는 값이다.

저항은 어디서 오는가

"현장이 변화를 싫어한다"는 진단은 거의 언제나 틀렸다. 저항은 대부분 합리적인 계산의 결과다. 박 파트장의 30분처럼, 저항하는 사람의 계산을 따라가 보면 설계의 구멍이 보인다. 겉으로 드러나는 신호와 진짜 원인을 나눠 보자.

들리는 말	진짜 원인	대응
"그거 쓰면 일이 더 많아져요"	추가 업무: 도구가 기존 단계를 대체하지 않고 얹힘	무엇을 없앨지 함께 설계, 시스템 연동, 이중 입력 제거
"AI가 틀리면 누가 책임져요?"	불신과 책임 불명확	검토 기준과 책임 범위 문서화, 근거(출처) 표시, 정확도 공개
"결국 사람 줄이려는 거잖아요"	일자리·역할 불안	절감 시간을 어디에 쓸지 먼저 약속, 역할 전환 경로와 교육
"우리 팀 업무는 특수해서 안 돼요"	전문성의 가치가 사라질 것 같은 두려움	도메인 전문가를 평가 세트·규칙의 주인으로 세움
"바빠서 교육 들을 시간 없어요"	인센티브 부재: KPI에 반영 안 됨	교육·개선 활동을 업무 시간으로 공식 인정, 팀 KPI 반영
(말없이 안 씀)	사용 마찰: 로그인, 느린 응답, 결과를 다시 옮겨 적기	사용 로그로 이탈 지점 확인, UX 개선을 최우선 과제로

"사람을 줄이지 않는다"는 약속은 구체적이어야 한다

막연한 안심 메시지는 믿음을 얻지 못한다. 더 설득력 있는 것은 "보고서 작성에서 절감한 시간은 현장 개선 활동과 재발 방지 분석에 쓴다"처럼 절감 시간의 용도를 정하고 실제로 그렇게 운영하는 것이다. 첫 성공 사례에서 이 약속이 지켜지는지를 모두가 지켜본다.

박 파트장 팀: 처음

엑셀 양식 + AI 도구 + 시스템 입력 3중 작업
AI 초안을 어디까지 믿어야 할지 기준 없음
도구 사용은 개인의 선의
건당 30분, 사용자 11명

박 파트장 팀: 재설계 후

엑셀 양식 폐지, 도구 안에서 8D 완성 후 시스템 자동 등록
D2·D3는 근거 확인 후 승인, D4 원인은 엔지니어 확정
파트장이 프로덕트 오너, 팀 KPI에 리드타임 반영
건당 소요 시간과 사용자 수를 매주 공유(예시 목표 설정)

변화 관리 프레임워크: ADKAR와 코터 8단계

변화 관리 분야에는 오래 쓰여 온 두 가지 틀이 있다. 하나는 개인의 변화를 보는 틀, 하나는 조직의 변화를 보는 틀이다. AX에는 둘 다 필요하다.

ADKAR: 한 사람이 바뀌는 다섯 단계

Prosci의 제프 하이엇(Jeff Hiatt)이 정리한 ADKAR 모델은 개인이 변화를 받아들이는 순서를 다섯 단계로 본다. 핵심은 순서다. 왜 해야 하는지 모르는 사람에게 사용법 교육(Knowledge)부터 하면 효과가 없다.

단계	질문	AX에서의 예
Awareness 인식	왜 바꿔야 하나?	클레임 회신이 경쟁사보다 늦어 고객 평가가 떨어진 데이터를 공유
Desire 욕구	나는 왜 참여하고 싶은가?	보고서 작성 대신 현장 분석에 시간을 쓸 수 있다는 구체적 이득
Knowledge 지식	어떻게 하는가?	도구 사용법, 검토 기준, 데이터 등급 기준 교육
Ability 능력	실제로 할 수 있는가?	실제 클레임으로 실습, 챔피언의 옆자리 코칭, 막혔을 때 도움 창구
Reinforcement 강화	계속 하게 되는가?	팀 KPI 반영, 성공 사례 공유, 예전 방식(엑셀 양식) 폐지

코터 8단계: 조직이 바뀌는 순서

존 코터(John Kotter)가 『Leading Change』(1996)에서 제시한 8단계는 조직 차원의 변화 순서다. AX 프로그램에 대응시키면 다음과 같다.

위기감 조성"AI를 해야 한다"가 아니라 "이 문제를 이대로 두면 안 된다". 리드타임, 재발률, 지식 손실 같은 우리 숫자로.
변화 선도 연합 구성경영진 후원자 + 현업 팀장 + IT·보안. IT만으로는 연합이 아니다.
비전과 전략 수립3년 뒤 우리 업무가 어떻게 달라지는지 한 장으로(17장의 로드맵).
비전 전달타운홀 한 번이 아니라 팀 회의마다 반복. 리더가 직접 도구를 쓰는 모습이 가장 강한 메시지다.
장애물 제거와 권한 부여보안 심사 병목, 데이터 접근 권한, 이중 입력, 엑셀 양식 같은 구조적 장애물을 치운다.
단기 성과 창출3~6개월 안에 눈에 보이는 성공 1~2개. 등대 프로젝트.
성과 공고화와 확산성공을 근거로 다음 유스케이스와 다음 사업장으로. 첫 성공에서 멈추지 않는다.
문화로 정착새 방식이 "원래 일하는 방식"이 되도록 평가·승진·채용 기준에 반영.

확산 곡선: Bass 모델로 보는 채택 속도

새 도구가 조직에 퍼지는 모양은 대개 S자 곡선이다. 에버렛 로저스(Everett Rogers)의 『Diffusion of Innovations』는 채택자를 혁신자(약 2.5%), 초기 수용자(13.5%), 초기 다수(34%), 후기 다수(34%), 지체자(16%)로 나눴다. 제프리 무어(Geoffrey Moore)는 초기 수용자와 초기 다수 사이에 넘기 어려운 간극, 캐즘(chasm)이 있다고 했다. 파일럿 참여자(혁신자·초기 수용자)가 만족한 도구가 다수에게 퍼지지 않는 A사의 장면이 바로 캐즘이다.

그림 13-4. 로저스의 채택자 분류와 무어의 캐즘(분할 위치는 개념도). 파일럿 참여자는 대개 혁신자·초기 수용자라서, 그들의 만족은 다수의 채택을 보장하지 않는다. 다수는 기술이 아니라 "내 일이 쉬워지는가"와 "동료가 쓰는가"로 판단한다.

이 S자 곡선을 수식으로 설명하는 가장 유명한 모델이 프랭크 배스(Frank Bass)가 1969년에 발표한 Bass 확산 모델(Bass diffusion model)이다. 아직 채택하지 않은 사람이 어느 시점에 채택할 확률을 두 가지 힘의 합으로 본다. 외부 자극(교육, 공지, 경영진 메시지)에 반응해 스스로 시작하는 힘 $p$, 이미 쓰는 동료를 보고 따라 하는 힘 $q$다.

$$ \frac{dN}{dt} = \left(p + q\,\frac{N(t)}{M}\right)\bigl(M - N(t)\bigr), \qquad F(t) = \frac{N(t)}{M} = \frac{1 - e^{-(p+q)t}}{1 + \frac{q}{p}\,e^{-(p+q)t}} $$

$N(t)$: 시점 $t$까지의 누적 채택자 수, $M$: 잠재 채택자 수(대상 인원 중 실제로 쓸 수 있는 사람), $p$: 혁신 계수(외부 영향), $q$: 모방 계수(내부 영향, 입소문), $F(t)$: 누적 채택 비율. 신규 채택이 최대가 되는 시점은 $t^* = \ln(q/p)/(p+q)$이다.

소비재 확산을 다룬 메타분석(Sultan·Farley·Lehmann, 1990)에서 자주 인용되는 평균값은 $p \approx 0.03$, $q \approx 0.38$(연 단위) 수준이다. 이는 시장 제품의 값이라 사내 도구에 그대로 쓸 수는 없지만, 한 가지 교훈은 그대로 통한다. 대개 $q$가 $p$보다 훨씬 크다. 공지와 교육보다 동료의 사용이 확산을 더 강하게 끈다. 챔피언 네트워크가 중요한 이유다.

아래 시뮬레이터는 월 단위로 Bass 모델을 돌린다. 교육은 $p$를 키우고, 챔피언은 $q$를 키우며, 사용 마찰(로그인, 느린 응답, 이중 입력)은 두 계수를 모두 깎고 잠재 채택자 $M$을 줄이며 이탈을 만든다고 가정했다(교육용 가정).

INTERACTIVE

채택 확산 시뮬레이터 (Bass 모델)

혁신 계수 p (월) 모방 계수 q (월) 교육·커뮤니케이션 챔피언 비율 사용 마찰(UX)

누적 채택률(현재 설정)개입 없음(교육·챔피언 0, 같은 마찰)월간 신규 채택(막대, 상대 높이)

24개월 채택률—

50% 도달—

신규 채택 최대 시점—

실효 p / q—

해볼 것: ① 교육만 100으로 올려 보자. 출발은 빨라지지만 곡선 모양은 크게 바뀌지 않는다. ② 교육은 30에 두고 챔피언 비율을 5%로 올려 보자. 중반 이후 기울기가 가팔라진다. ③ 마찰을 90으로 올리면 교육·챔피언을 아무리 늘려도 상한이 낮아진다. 마찰 제거가 가장 싼 확산 정책인 경우가 많다.

인센티브, KPI, 그리고 성공을 나누는 법

사람은 측정되는 것을 한다. AX 프로그램이 "로그인 수"나 "교육 이수율"을 KPI로 잡으면, 사람들은 로그인하고 교육을 이수한다. 업무는 바뀌지 않는다. KPI는 세 층으로 나눠 잡는 것이 좋다.

사용

채택 지표

대상자 중 주간 활성 사용자 비율, 업무 건 중 도구를 거친 비율. 초기 6개월의 선행 지표로만 쓴다.

업무

프로세스 지표

클레임 회신 리드타임, 8D 완료 기간, 재작업률, 검색 소요 시간. 업무가 실제로 바뀌었는지 보여 준다.

성과

사업 지표

재발률, 품질 비용(COPQ), 고객 평가, 설비 가동률. 경영진이 투자를 계속할 근거다(8장).

팀장이 할 수 있는 일

팀 회의에서 도구를 직접 써서 보여 준다. 리더가 안 쓰는 도구는 팀도 안 쓴다.
도구 도입과 함께 없앨 업무(양식, 보고, 이중 입력)를 하나 이상 선언한다.
AI 출력의 검토 기준을 팀 차원에서 정한다. "근거 문서가 표시된 항목은 확인 후 승인, 수치와 원인은 담당자가 확정."
챔피언에게 업무 시간의 일부(예: 주 2~4시간)를 공식 배정하고 인사 평가에 반영한다.
실패 사례도 공유한다. "AI가 이렇게 틀렸다"는 공유가 불신이 아니라 학습이 되게 한다.
절감된 시간이 어디에 쓰였는지 분기마다 팀에 보고한다.

성공 사례는 숫자보다 이야기로 퍼진다

"리드타임 예시 40% 단축"보다 "2파트 이 선임이 금요일 밤 클레임을 토요일 출근 없이 처리했다"가 더 빨리 퍼진다. 사내 사례 공유회는 경영진 보고 형식이 아니라 현업이 현업에게 말하는 형식이 효과적이다. 이 사례들은 14장의 계층별 목표와 17장의 로드맵에서 확산의 연료가 된다.

핵심 정리

AI 도구를 기존 업무 위에 얹으면 일이 늘어난다. 무엇을 없앨지 함께 설계하는 업무 재설계가 채택의 전제다.
운영 모델은 중앙 CoE → 허브-스포크 → 연합형으로 성숙도에 따라 진화하는 경우가 많다. CoE의 성공은 현업이 CoE 없이 만든 성과로 측정한다.
FDE는 CoE 엔지니어가 현업 팀에 상주해 실제 데이터로 함께 만들고, 재사용 부품을 플랫폼으로 되돌리는 방식이다. 성과는 FDE가 떠난 뒤에도 남는 것(팀의 자립, 다음 팀의 재사용)으로 잰다.
프로덕트 오너와 도메인 전문가는 현업이어야 한다. 정답 판단, 평가 세트, 업무 재설계 권한이 현업에 있기 때문이다. 역할은 권한·시간·예산·지원·평가가 함께 올 때만 작동하므로, 역할을 만들 때마다 덜어 줄 본업을 정한다.
역량은 리터러시–파워유저–빌더–전문가의 층으로 설계하고, 교육 부담의 대부분은 넓은 바닥층과 실습 코호트 운영에서 생긴다.
저항은 대부분 합리적 계산의 결과다. 추가 업무, 책임 불명확, 일자리 불안, 인센티브 부재, 사용 마찰을 각각 다르게 다룬다.
ADKAR는 개인 변화의 순서(인식–욕구–지식–능력–강화), 코터 8단계는 조직 변화의 순서다.
Bass 모델에서 확산은 외부 영향 p와 모방 q의 합이며, 대개 q가 크다. 챔피언과 마찰 제거가 교육보다 확산을 크게 바꾸는 경우가 많다.

확인 퀴즈

1. 파일럿 참여자 5명은 만족했지만 전사 오픈 후 사용률이 10% 미만이다. 가장 먼저 의심할 원인은?

파일럿 참여자는 대개 불편을 감수하는 혁신자·초기 수용자다. 다수는 "내 일이 쉬워지는가"로 판단하므로, 이중 입력과 추가 검토가 생기면 쓰지 않는다. 사용 로그와 현장 관찰로 이탈 지점을 먼저 확인한다.

2. AI 인력이 적고 보안 민감도가 높으며 데이터 성숙도가 낮은 AX 초기 조직에 가장 적합한 운영 모델은?

희소한 인재와 표준·보안 통제를 한곳에 모으는 중앙 CoE가 초기에 유리하다. 다만 병목이 되지 않도록 현업 역량을 키워 허브-스포크로 옮겨 가는 계획을 함께 세운다.

3. CoE 엔지니어를 한 분기 동안 품질팀에 FDE로 상주시켰다. 이 FDE의 성과 지표로 가장 적절한 것은?

FDE의 목적은 팀을 스스로 움직이게 하고, 한 팀에서 배운 것을 플랫폼으로 되돌려 다음 팀을 빠르게 하는 것이다. 맞춤 도구 개수만 늘면 유지 부담만 커진다.

4. ADKAR 모델의 다섯 단계를 순서대로 나열한 것은?

인식(왜) → 욕구(나는 왜 참여하나) → 지식(어떻게) → 능력(실제로 할 수 있나) → 강화(계속하나) 순이다. 왜 해야 하는지 모르는 사람에게 사용법 교육부터 하는 것이 흔한 실수다.

5. Bass 확산 모델에서 모방 계수 q가 혁신 계수 p보다 훨씬 크다는 것이 시사하는 바는?

q 항은 이미 채택한 비율 N/M에 비례하므로, 초반에는 작지만 사용자가 늘수록 커져 S자 곡선을 만든다. p는 출발을 만들고, q가 가속을 만든다. 교육은 p를 키우는 데 의미가 있다.

6. 다음 중 AX 프로그램의 KPI로 가장 부적절한 단독 지표는?

로그인 횟수는 업무가 바뀌었는지 보여 주지 못하는 허영 지표가 되기 쉽다. 채택 지표는 선행 지표로만 쓰고, 프로세스·사업 지표와 함께 봐야 한다.

7. "AI 쓰면 결국 사람 줄이는 거 아니냐"는 우려에 가장 효과적인 대응은?

막연한 안심 메시지보다 절감 시간의 구체적 용도와 그것이 지켜지는 첫 사례가 신뢰를 만든다. 역할 전환 경로와 교육도 함께 제시한다.