한 영역에서 통한 확산이 옆 영역에서 무너진 장면
개발 자동화에서 작은 흐름 하나가 리드타임을 줄였고(L3), 게이트를 통과해 ‘확대’ 판정을 받았다(12장). 전환 오너는 다음 수를 둔다. “이 방식 그대로 다른 영역에도 깔자.” 개발 각본 — 제한 범위에서 검증, 수용률 확인, 통과한 흐름만 확대 — 을 업무 자동화와 데이터 분석 자동화에 복사한다.
그 각본은 영역마다 다른 이유로 막힌다. 업무 자동화는 도구를 깔았는데 안 쓴다. 데이터 분석 자동화는 지표 정의가 조직마다 달라 같은 질문에 다른 숫자가 나오고, 접근권은 막혀 있는데 엉뚱한 영역은 과잉 개방돼 있다.
확산은 하나의 각본을 전사에 복사하는 일이 아니다. 4개 적용 영역(4장)은 대상·위험·교육·성과 기준이 다르다. 같은 차수를 밟아도 각 차수의 일과 막히는 지점이 영역마다 다르다. 개발 자동화의 병목은 reviewer(검토자) 수용률과 repo(코드 저장소) 정책, 데이터 분석 자동화는 지표 정의·권한·PII, 사내업무 보조는 검증이 아니라 채택 — 좌석을 줘도 쓰지 않는 것이다. 한 영역에서 검증된 방식을 복사하면 빠른 확산이 아니라 영역별로 다른 실패를 동시에 떠안는다.
그래서 이 장은 둘을 분리한다. (1) 4개 영역을 같은 차수 모델(0~4)로 묶되, 각 차수를 영역별로 다르게 하는 법. (2) 어느 영역에서나 확산을 무너뜨리는 두 변화관리 함정 — 데이터 리터러시 갭과 비협조.
이 장은 12장에서 ‘확대’ 판정을 받은 흐름을 넓히는 데서 시작하고, 성공을 재사용 자산으로 바꾸는 방법(15장)과 짝을 이룬다 — 차수 3(재사용 자산화)이 연결점이다.
핵심 프레임: 같은 차수, 다른 일
확산은 전 영역 공통의 5개 차수(0~4)로 관리한다. 차수를 공통으로 두는 이유는 리더가 모든 영역을 같은 언어로 리뷰하기 위해서다 — “이 영역은 지금 몇 차인가” 하나로 전 영역 진척을 비교한다. 그러나 각 차수의 일은 영역마다 다르다. 일까지 공통이라 착각하면 도입부의 실패가 재현된다. 한 각본을 네 영역에 그대로 복사했다가 영역별로 다른 실패를 동시에 떠안는 것은, AI를 도입하는 조직에서 흔히 반복되는 함정이다.
공통 확산 차수 모델 (0~4)
| 확산 차수 | 공통 목적 | 통과해야 다음 차수로 |
|---|---|---|
| 차수 0 — 기준 정렬 | 리더와 champion(현업 전파자)이 같은 언어로 AX를 설명한다 | 4개 영역·안티슬롭 게이트·데이터·보안·비용 기준 공유 완료 |
| 차수 1 — 기본 사용과 후보 발굴 | 안전하게 써보고 후보를 찾는다 | 담당자 있는 후보 업무 목록 확보 |
| 차수 2 — 제한 검증 | 검토 가능한 작은 흐름을 실행한다 | 기준선 대비 전후 비교(L2 이상) 확보 |
| 차수 3 — 재사용 자산화 | 반복 가능한 자산으로 남긴다 | Skill·MCP·템플릿이 카탈로그에 담당자와 함께 등록 |
| 차수 4 — 성과 리뷰 | 확대·보류·폐기를 판정한다 | 12장 게이트 판정 + 비용 배분 확인 |
차수 2의 ‘통과’는 8장(파일럿)·10장(증거 등급)·12장(게이트) 도구를 그대로 쓴다. 차수는 확산의 진행 단계, 게이트는 각 차수 끝의 통과 판정이다. 새 척도가 아니라 같은 L0~L5와 같은 4지선다(확대·유지·보류·폐기) 위에서 돈다.
4개 영역이 다른 네 가지 — 한눈에
같은 차수를 밟아도 대상·위험·교육·성과가 영역마다 다르다. 이 표가 이 장의 척추다.
| 영역 | 먼저 여는 대상 | 가장 큰 위험 | 먼저 잡을 교육 | 성공 신호(사용량 아님) |
|---|---|---|---|---|
| 사내업무 보조 | 전 구성원(단, 리더·champion 먼저) | 좌석은 늘고 실사용은 공백 | 금지선·역할별 체감 예시 | 실제 업무 적용률, 중복 라이선스 감소, 미사용 좌석 회수 |
| 업무 자동화 | 반복·승인 조건 명확한 운영성 조직 | 사람 절차의 단순 복제, 승인 판단 자동화 | 6분류 판정·승인 보조 경계 | 반복 요청 감소, 처리 리드타임, 사람 검토 시간 감소 |
| 개발 자동화 | PO·PD·개발·QA·플랫폼 | merge(병합) 자동화 착각, 검토 없는 산출 | repo 정책·reviewer 기준·HITL | reviewer 수용률, test 통과율, 리드타임, 결함 유출 감소 |
| 데이터 분석 자동화 | 데이터팀·분석가·반복 요청 현업 | 지표 정의 불일치, 권한·PII 사고 | 지표 정의·읽기 전용 질의·PII 기준 | 셀프서비스 전환율, 질의 승인률, 요청 대기 감소, 비용 예측 오차 |
읽는 법: 개발 자동화의 성공 신호(reviewer 수용률)를 데이터 분석 자동화에 갖다 대면, 데이터의 진짜 병목(지표 정의·권한)은 측정되지도 않는다. 영역별로 다른 성공 신호를 같은 잣대로 보지 않는다 — 5장의 “A는 요청 감소, F는 처리량”이 영역 단위로 확장된 규칙이다.
영역별 차수 적용: 같은 0~4를 다르게 밟는다
각 영역이 차수 1~3에서 무엇을 다르게 하는지 못 박는다. (차수 0은 공통, 차수 4는 12장 게이트로 수렴해 영역차가 작다.)
사내업무 보조 — 병목은 검증이 아니라 채택
이 영역만 차수 1의 무게가 다르다. 다른 셋은 차수 2(검증)가 산이지만, 이 영역은 차수 1(기본 사용)에서 무너진다. 좌석과 공통 교육을 줘도 자기 업무에 쓸 이유를 못 찾으면 미사용 좌석만 쌓인다. 그래서 차수 1을 셋으로 쪼갠다 — (1) 관리형 도구·사용 가능 데이터·금지 업무 공지, (2) 공통 교육 뒤 역할별 체감 예시(문서 작성·회의 정리·리서치·시트 정리), (3) 사용량·교육 이수·미사용 좌석·반복 질문을 보고 다음 교육과 회수 대상 결정. 성공은 사용량이 아니라 적용률·중복 라이선스 감소·보안 위반·사례 재사용성으로 본다. 가장 흔한 실패는 “활용량 늘리기”를 KPI로 거는 것이다. 쓰지도 않을 셋업과 강제 사용 평가만 낳는다.
업무 자동화 — 중앙 TFT가 대신 만들지 않는다
이 영역은 5장(6분류 트리)을 차수 안에 끼워 넣는다. 차수 1에서 반복 요청을 모으되 바로 자동화하지 않고 6분류 중 어디인지 먼저 판정한다. 차수 2에서 Skill·MCP·기존 도구·시스템 설정으로 되는지 보고(6장 안티슬롭 게이트), 승인자·예외·위험 작업·감사 기록이 명확한 업무만 검증 후보로 올린다. 중앙 TFT가 모든 부문 자동화를 대신 만들지 않는다. 담당자와 champion이 자기 기준을 정하고, 중앙은 가드레일·공통 도구·카탈로그 기준만 댄다. 중앙이 다 만들면 차수 3에서 “운영 주인 공석”으로 무너진다.
개발 자동화 — 제한된 repo·reviewer 안에서만 1차 확산
이 영역은 1차 확산을 전사 표준 배포로 시작하지 않는다. 제한된 repo와 지정 reviewer 안에서 경량 PRD가 preview(미리보기) 또는 PR draft(검토 요청 초안)까지 이어지는지로 연다. 차수 1에서 자동화 흐름이 “merge 자동화가 아니라 검토 가능한 산출물을 만드는 제한 흐름”임을 먼저 설명한다 — 이 한 줄을 빼면 “AI가 알아서 머지한다”는 오해가 확산을 오염시킨다. 차수 2에서 관리형 CLI·repo policy·reviewer·test·QA 기준을 맞추고 검증한다. 차수 3 조건은 생성량이 아니라 수용률·test 통과·리뷰 품질·추적 로그가 확인된 흐름이다. 성공 신호도 PRD → PR 리드타임·review turnaround(검토 회수 시간)·수용률·결함 유출 감소다.
데이터 분석 자동화 — 도구 배포보다 지표·권한·PII가 먼저
이 영역은 차수 1 진입 전 할 일이 가장 많다. 도구 배포 전에 지표 정의·테이블·컬럼 의미·접근 권한·PII 기준을 먼저 정리한다. 정리 없이 도구만 깔면 같은 지표가 조직마다 다른 테이블을 참조해 숫자가 갈리고, “정답이 뭐냐” 합의가 안 돼 검증이 무한 반복된다. 이 무한 반복은 데이터 분석 자동화를 도입하는 조직에서 흔히 나타나는 전형적 실패로, 업계 전반에서 정리를 건너뛰고 도구부터 깐 영역에서 거의 예외 없이 재현된다. 차수 2에서 데이터·리포트 생성은 view 복제가 아니라 읽기 전용 질의·리포트 초안의 검토 흐름으로 시작한다. 대량 처리는 작업 단위로 비용 태그·품질 샘플링·실패 격리·담당자를 붙인다. 차수 3에서 검증된 산출물을 공식 BI 등록 기준으로 넘긴다. 접근권은 “신청하면 다 준다”와 “정작 분석 영역은 막혀 있다”가 공존하기 쉽다 — 확산 전에 필요 접근권과 관리 주체부터 정비한다.
공통 원칙: 4개 영역을 섞지 않는다. 통제 기준이 다른 영역을 한 계획에 묶으면, 가장 느슨한 영역의 사고가 가장 엄격한 영역의 신뢰까지 무너뜨린다.
확산 적용 체크리스트
영역 하나를 놓고 순서대로 채운다. 빈칸이 남으면 그 영역의 확산은 시작하지 않는다.
| # | 점검 항목 | 채우지 못하면 |
|---|---|---|
| 1 | 이 영역의 ‘먼저 여는 대상’을 한 줄로 댈 수 있는가 | 전사 동시 확산 위험. 대상부터 좁혀라 |
| 2 | 이 영역의 ‘가장 큰 위험’이 다른 영역과 다름을 적었는가 | 옆 영역 각본 복사 위험 |
| 3 | 이 영역의 성공 신호가 ‘사용량’이 아닌 검증된 산출로 정의됐는가 | 활용량 KPI 함정. 측정 챕터(9·10장) 재확인 |
| 4 | 차수 0(기준 정렬)에서 champion이 같은 언어로 설명 가능한가 | 차수 1로 넘어가지 마라 |
| 5 | 이 영역의 차수 1 ‘후보 발굴’에 담당자가 붙어 있는가 | 주인 없는 후보. 운영 주인부터 |
| 6 | 차수 2 검증에 기준선(전후 비교)이 있는가 | 측정 없는 파일럿(8·10장). 검증 금지 |
| 7 | 차수 3 자산화 시 카탈로그 담당자·승인자·사용 조건이 정해졌는가 | 자산이 떠다님(15장). 등록 보류 |
| 8 | 데이터·시스템 영역이면 지표 정의·권한·PII가 도구보다 먼저 정리됐는가 | 데이터 영역 차수 1 진입 금지 |
| 9 | 이 영역 champion을 한 명 이상 지명했는가 | 중앙 병목. champion 네트워크부터 |
| 10 | 변화관리(교육·인센티브) 예산이 확산 예산과 별도로 잡혔는가 | 채택 실패 예약. 아래 절 참조 |
10번이 이 장의 분기점이다. 차수와 영역 적용이 정교해도 변화관리를 예산화하지 않으면 사람이 따라오지 않는다. 다음 두 절이 그 변화관리다.
변화관리 함정 ① — 데이터 리터러시 갭
확산이 차수 2~3에서 멈추는 가장 조용한 원인은 도구가 아니라 역량 격차다. AX 전환은 사람의 일을 줄이는 게 아니라 사람이 맡는 판단의 위치를 바꾸는 일이다. 에이전트가 탐색·분류·대조·초안·반복 검증의 규모를 넓힐수록 오히려 더 강하게 남아야 하는 역량이 있고, 이 역량이 비면 확산은 차수 1에서 활용량만 올리다 멈춘다.
AX가 줄이는 게 아니라 키워야 하는 역량
| 역량 | 무엇을 할 수 있어야 하나 | 비면 생기는 확산 실패 |
|---|---|---|
| 문제 정의·업무 흐름 설계 | 무엇을 자동화하고 무엇을 제외할지 설명한다(5장 6분류) | 후보 분류 없이 “다 자동화”로 묶임 |
| 도메인 규칙·예외 설계 | 업무 규칙·승인 조건·예외·금지선을 문서화한다 | 승인 판단까지 자동화하는 사고 |
| 처리 규모 설계·품질 검증 | 사람이 다 볼 수 없는 양을 샘플링·평가·승인 기준으로 통제한다 | 양은 늘고 검증이 못 따라감(슬롭) |
| 데이터·시스템 이해 | 에이전트가 읽는 데이터·권한·로그·경계를 이해한다 | 권한 양극화, PII 사고 |
| 에이전트 운영 관리 | 비용·품질·실패·재시도·감사 기록을 운영 기준 안에서 관리한다 | 비용 폭증, 추적 불가 |
세 번째 행이 6장(안티슬롭 게이트)과 직결된다. 처리 규모를 키우면서 품질 검증 역량을 함께 키우지 않으면, 확산은 슬롭을 대량 생산하는 일이 된다.
역할 기반 차등 교육 — 모두에게 같은 교육은 실패다
데이터 리터러시 갭을 메우는 교육은 역할별로 다르게 설계한다. 같은 교육을 주면 경영진은 지루해하고 현업은 못 따라온다. 핵심 원칙 넷: (1) 역할 기반 차등, (2) 정책과 실습을 함께, (3) 재이수·갱신 전제, (4) 필수와 선택 분리.
| 대상 | 학습 목표 | 먼저 잡을 주제 |
|---|---|---|
| 경영진 | AI 전략·리스크를 경영 의사결정 수준에서 이해 | 전략·투자·고위험 승인·사고 책임 |
| 관리자(팀장·리드) | 정책을 현업에 적용하고 예외를 통제 | 위험 분류·승인 체계·데이터 정책·팀 운영 기준 |
| 개발자 | 안전하고 재현 가능한 시스템 구축 | 보안·모델 변경관리·평가·로그·HITL |
| 전 직원 | 기본 가이드와 금지 행위 이해 | 허용·금지·민감정보·출력 검증·신고 절차 |
Enablement가 정책보다 먼저 체감돼야 한다. 현업이 “도와준다”는 경험을 먼저 해야 공식 경로를 따른다. 샌드박스 온보딩·오피스아워·템플릿 라이브러리가 통제 메시지보다 앞서야 차수 1의 채택이 일어난다.
미성숙 확산 가드 — 외형이 갖춰졌다고 차수를 건너뛰지 않는다
리터러시 갭만큼 조용히 확산을 무너뜨리는 게 검증 단계를 건너뛴 조기 전사 공유다. “외형이 안 갖춰지면 설득 비용이 크다”, “맞건 틀리건 일단 공개하고 자연 흡수에 맡기자”는 압박은 AI를 도입하는 조직 어디에서나 강하게 작동한다. 그러나 능력 경계가 선언되지 않고 산출이 비결정적이며 “다 됐다”는 낙관만 위로 올라간 상태(능력 경계 명세는 10장 참조)에서 전사로 퍼지면, 기대에 못 미치는 채 확산돼 도구와 추진 조직의 신뢰를 동시에 깎는다. 2026년 들어 보고된 AI 도입 실패의 대부분이 모델 성능이 아니라 전략·거버넌스·변화관리에서 비롯된다는 업계 관찰과 같은 맥락으로, 이는 특정 조직의 문제가 아니라 미성숙한 산출을 검증 없이 푸는 거의 모든 조직이 겪는 공통 현상이다 — 활용량 KPI 함정(앞 절)과 같은 뿌리다.
외형 확보일은 출시 가능일이 아니다(2장). 전사 공유는 차수 2 검증(L2 이상)과 한 팀 단위 통과·실패 판정을 거친 뒤에만, 그리고 공유 자료에 능력 경계 명세(되는 것·안 되는 것·사람 확인 구간, 10장)를 붙여 연다. 외형이 갖춰졌다고 차수 2를 건너뛰면, 다음 절의 ‘품질 불신’ 저항을 스스로 예약하는 셈이다.
변화관리 함정 ② — 비협조와 저항
역량을 키워도 협조하지 않으면 확산은 멈춘다. 비협조는 게으름이 아니라 대부분 합리적 이유가 있는 저항이다. 같은 “안 쓴다”라도 원인이 다르면 처방이 다르다.
저항 유형별 처방
| 저항 유형 | 회의에서 보이는 신호 | 잘못된 대응 | 맞는 대응 |
|---|---|---|---|
| 승인 절차 피로감 | 우회 사용, 미등록 실험 | 통제 강화 | 저위험 패스트트랙·셀프 체크리스트(17장) |
| 품질 불신 | 재사용 저조, 수동 회귀 | “그냥 믿고 써라” | 검증 기준 공개·우수 사례 공유 |
| 보안 우려 | 사용 기피, 과잉 차단 요구 | 무조건 허용 | 허용 범위 명확화·안전 가이드 |
| 관리자 소극성 | 학습 참석 저조, 전파 미흡 | 현업만 닦달 | 관리자 평가 지표에 반영·브리핑 강화 |
| Shadow AI 관성 | 개인 계정·우회 툴 지속 | 차단·적발 | 공식 샌드박스·오피스아워를 더 편리하게 |
마지막 행이 핵심 원리다. Shadow AI는 적발로 사라지지 않는다. 공식 경로가 우회보다 더 편할 때만 사라진다. 통제로 누르면 우회가 깊어지고, 편의로 끌어당기면 협조가 따라온다.
champion 네트워크 — 중앙이 다 못 한다
비협조를 푸는 가장 강한 지렛대는 중앙팀이 아니라 현업 champion 네트워크다. 중앙팀이 모든 현업 질의를 직접 처리하면 그 자체가 병목이다. champion은 중앙과 현업의 번역자로, 추상 정책을 부서 언어로 바꾸고 1차 코칭·사례 공유·위험 신호 조기 에스컬레이션을 한다.
champion 네트워크를 세울 때 못 박을 것:
- 선발: 각 본부·실·팀에 최소 1명. 직함이 아니라 디지털 친화도와 팀 내 영향력으로 고른다.
- 권한·보상: 공식 역할로 지명하고 성과에 반영한다. 직함만 주고 권한·시간을 안 주면 책임만 떠안고 절차 돌파에 에너지를 소진한다.
- 운영: 정기 커뮤니티로 우수·실패 사례를 공유하고, 데모데이로 확산을 가속한다.
- 측정: champion 지표는 활용량이 아니라 팀 내 활성 사용자 수·사례 발굴 수·위반 감소율이다.
Before/After: 영역 무시 확산 vs 영역별 확산
예를 들어 한 채용 플랫폼 기업이 개발 자동화에서 첫 성공(L3, 확대 판정)을 낸 뒤 업무 자동화·데이터 분석 자동화 두 영역으로 확산을 넓힌다고 하자.
Before — 한 각본을 복사한 확산
전환 오너가 개발 각본(제한 범위 검증 → 수용률 확인 → 확대)을 두 영역에 그대로 깐다. 같은 성공 신호·교육(공통 1회)·속도. 결과는 이렇다. 업무 자동화는 안 쓰고(차수 1이 산인데 차수 2를 산으로 봄), 데이터는 지표가 조직마다 갈려 검증이 무한 반복되고, 예산이 없어 champion은 직함만 받고 안 움직인다. 리더 보고는 “두 영역에 확산했습니다” → 무엇이 검증된 산출로 남았는지 말할 수 없다.
After — 영역별로 다르게 편 확산
전환 오너가 영역별 차이 표를 먼저 채운다. 업무 자동화는 병목을 채택으로 잡고 차수 1을 셋으로 쪼갠 뒤(공지 → 역할별 예시 → 회수 대상) 5장 6분류로 후보를 판정한다. 데이터는 차수 1 진입 전 지표·권한·PII를 정리하고 읽기 전용 질의 검토 흐름으로 시작한다. 교육은 역할별 차등, champion에게는 권한·시간·보상, 예산은 확산과 별도. 리더 보고: “운영지원은 반복 요청을 기준선 대비 줄였고, 데이터는 셀프서비스 전환율로 검증 중이며, 두 영역 모두 차수 3 자산이 카탈로그에 등록됐습니다.” → 영역별로 다른 검증된 산출을 비교로 말한다.
한 줄 차이
| 구분 | Before(각본 복사) | After(영역별 확산) |
|---|---|---|
| 차수 모델 | 공통(각본까지 공통) | 공통(각 차수의 일은 영역별) |
| 성공 신호 | 전 영역 동일(수용률) | 영역별 상이 |
| 데이터 영역 진입 | 도구부터 | 지표·권한·PII 먼저 |
| 변화관리 예산 | 확산 예산에 묻힘 | 별도 편성 |
| champion | 직함만 | 권한·시간·보상 |
| 리더 보고 | “확산했다” | “영역별로 무엇이 검증됐다” |
두 갈래는 같은 첫 성공에서 출발했다. 갈린 지점은 하나 — 개발 각본을 복사했는가, 영역별 차이 표를 먼저 채웠는가.
흔한 실패모드
각 모드 끝의 레드플래그는 “이 말이 나오면 의심하라”는 회의용 판별구다.
1 — 각본 복제(영역 무시). 통한 방식을 다른 영역에 복사 → 영역별로 다른 실패를 동시에 떠안음. 레드플래그: “개발에서 됐으니 여기도 똑같이.” 차단: 영역별 차이 표를 먼저 채운다.
2 — 활용량 KPI. 사내업무 성공을 사용량으로 잼 → 쓰지도 않을 셋업과 강제 사용 평가. 레드플래그: “활용량 N배”가 목표로 걸린다. 차단: 성공 신호를 적용률·중복 라이선스 감소로 교체.
3 — 데이터 영역에 도구부터. 지표·권한·PII 정리 전 도구 배포 → 숫자 불일치로 검증 무한 반복. 레드플래그: “일단 도구 깔고 지표는 나중에.” 차단: 차수 1 진입 조건에 지표·권한·PII 정리.
4 — 중앙 TFT 과집중. 중앙이 모든 자동화를 대신 만듦 → 차수 3에서 운영 주인 공석으로 자산이 죽음. 레드플래그: “그건 중앙팀이 만들어 드릴게요.” 차단: 담당자·champion이 기준을 정하고 중앙은 가드레일·카탈로그만.
5 — 변화관리 무예산. 교육·인센티브·champion 운영비를 안 잡음 → 채택 실패 예약. 레드플래그: 변화관리를 “공지로 갈음”. 차단: 별도 예산 라인으로 승인(신호 박스).
6 — champion에 직함만. 권한·시간·보상 없이 지명만 → 책임만 떠안고 안 움직임. 레드플래그: champion이 본업 100%에 역할을 무보상 겸직. 차단: 지명과 동시에 권한·시간·보상·에스컬레이션 경로를 같은 문서에 명시.
7 — Shadow AI 적발 모드. 우회를 통제·적발로 누름 → 우회가 더 깊어짐. 레드플래그: “개인 계정 사용을 적발해 제재.” 차단: 공식 샌드박스·오피스아워를 우회보다 더 편하게.
8 — 미성숙 산출물의 조기 전사 공유. 능력 경계 미선언 + 비결정 산출 + 상향 낙관(“다 됐다”)이 검증 없이 누적된 채 “맞건 틀리건 일단 공개” → 기대에 못 미치는 산출이 전사로 퍼져 도구와 추진 조직의 신뢰가 함께 깎임. 레드플래그: “외형 갖췄으니 일단 전사 공개하자”가 단계적 검증 없이 일정으로 박힌다. 차단: 전사 공유 전 한 팀 단위 검증(통과·실패 판정 → 교훈 반영 → 확대)을 통과시키고, 공유 자료에 능력 경계 명세(되는 것·안 되는 것·사람 확인 구간, 10장)를 첨부한다.
리더가 승인·요구할 신호
확산 계획서를 사이에 둔 양쪽이 같이 쓰는 게이트다. 승인자에게는 “무엇을 보면 통과시킬지”, 실무자에게는 “무엇을 미리 준비해야 통과되는지”의 기준이다. 거버넌스 세부는 16~18장에 있고, 여기서는 회의용 신호만 남긴다.
요구할 것 (없으면 확산 테이블에 올리지 않는다)
- 영역별 차수 계획이 있는가. “4개 영역에 같은 각본”이면 반려한다. 각 영역의 대상·위험·교육·성과가 다르게 적혀 있어야 한다.
- 각 영역의 성공 신호가 사용량이 아닌 검증된 산출로 정의됐는가. 활용량 KPI는 반려한다.
- 데이터·시스템 영역이면 지표 정의·권한·PII가 도구보다 먼저 정리됐는가.
- champion 네트워크가 지명됐고, 각 champion에게 권한·시간·보상이 함께 주어졌는가. 직함만 준 계획은 반려한다.
반려할 것
- 한 영역의 확산 각본을 다른 영역에 복사한 계획.
- 중앙 TFT가 모든 부문 자동화를 대신 만드는 구조(차수 3에서 운영 주인 공석을 예약).
- 변화관리 예산 없이 교육을 공통 1회로 끝내는 계획.
- 검증을 건너뛴 조기 전사 공유. 외형만 갖췄으니 일단 전 영역에 연다는 계획. 전사 공유는 차수 2 검증(L2 이상)과 한 팀 단위 통과·실패 판단을 거친 뒤, 능력 경계 명세(10장)를 첨부해서만 연다 — 이 순서를 건너뛰면 가장 느슨한 영역의 미검증 산출이 전사 신뢰를 먼저 깎는다.
승인할 것
- 변화관리(교육·인센티브)를 확산 예산과 별도로 예산화하는 결정. “공지로 갈음”하는 계획은 채택 실패를 예약한 것이다. 이 별도 예산이 이 장에서 리더가 내려야 할 가장 중요한 승인이다.
- 영역별로 다른 차수 속도와 다른 성공 신호를 인정하는 결정(개발은 차수 2가 산, 사내업무는 차수 1이 산 — 같은 속도를 강요하지 않는다).
- Shadow AI를 적발이 아니라 공식 경로 편의 개선으로 흡수하는 결정.
이 장의 요약
- 확산은 한 각본의 전사 복사가 아니다. 4개 영역(4장)은 대상·위험·교육·성과가 다르다. 같은 차수 모델(0~4)을 밟되 각 차수의 일을 영역별로 다르게 한다.
- 차수는 공통, 일은 영역별. 사내업무는 차수 1(채택)이 산, 나머지 셋은 차수 2(검증)가 산이다. 같은 속도를 강요하지 않는다.
- 성공 신호를 같은 잣대로 보지 않는다. 사내업무=적용률, 업무자동화=반복 요청 감소, 개발=수용률·결함 유출 감소, 데이터=셀프서비스 전환율. 활용량 KPI는 함정이다.
- 데이터 영역은 도구보다 지표·권한·PII가 먼저. 거꾸로 하면 숫자 불일치로 검증이 무한 반복된다.
- 변화관리 함정 둘 — 리터러시 갭과 비협조. 갭은 역할별 차등 교육과 Enablement 우선 체감으로, 비협조는 저항 유형별 처방과 champion 네트워크로 푼다.
- Shadow AI는 적발이 아니라 편의로 흡수한다. 공식 경로가 우회보다 편할 때만 사라진다.
- 가장 중요한 결정: 변화관리를 확산 예산과 별도로 예산화하는 것. 차수와 영역 적용이 정교해도, 예산화하지 않으면 사람이 따라오지 않는다.
4개 영역 구분·차수 모델(0~4)·영역별 차이 표·변화관리 함정 분류는 도구·모델이 바뀌어도 유지되는 골격이다. 본문의 도구 범주(관리형 CLI·BI 등록 기준 등)는 예시일 뿐이니, 각 영역의 ‘먼저 여는 대상’과 ‘성공 신호’는 당신 조직 값으로 바꿔 읽으면 된다.