# 변화관리
> **이 장에서 배우는 것**
> 왜 기술이 아니라 사람에서 막히는지, 저항이 어떤 얼굴로 오는지, 그리고 배포 후
> 3~6개월을 어떻게 버티는지.
## 로드맵에 안 적힌 절반
[앞의 네 장](/guide/ax-roadmap-overview)은 **일이 어떻게 흘러가는지**를 다뤘습니다.
그런데 그 일을 하는 건 사람이고, 실패의 대부분은 여기서 납니다.
공개된 조사들이 일관되게 말하는 것이 있습니다.
- AI 프로젝트의 상당수가 확장 단계에서 실패하는데, **주된 원인은 알고리즘이 아니라
변화관리**입니다.
- 한 조사에서는 도입 난이도의 **약 38%를 사용자 숙련도**가, **약 16%를 기술 이슈**가
차지한다고 봤습니다.
> 수치는 조사마다 다릅니다. 다만 **기술보다 사람 쪽이 크다**는 방향은 여러 조사에서
> 공통적입니다.
기술에 10을 쓰고 사람에 1을 쓰면 비중이 원인과 반대가 됩니다.
## 저항은 반대라는 얼굴로 오지 않습니다
"저는 반대합니다"라고 말하는 사람은 오히려 다루기 쉽습니다. 이유를 들으면
되니까요. 실제 저항은 이렇게 옵니다.
| 겉으로 나오는 말 | 실제로 하는 말 |
|---|---|
| "바빠서 회의 참석이 어렵습니다" | 관여하고 싶지 않습니다 |
| "우리 업무는 좀 특수해서요" | 내 일은 건드리지 마세요 |
| "일단 다른 팀 먼저 해보시죠" | 실패하는 걸 보고 싶습니다 |
| "그거 예전에도 해봤는데요" | 또 흐지부지될 겁니다 |
| (침묵) | 그냥 지나가길 기다립니다 |
**마지막이 가장 흔하고 가장 위험합니다.** 아무도 반대하지 않아서 잘 되고 있는 줄
알았는데, 배포 후에 아무도 안 씁니다.
## 저항의 세 가지 뿌리
```mermaid
graph TD
R1["내 일이 없어질까"] --> A["협조 회피"]
R2["내가 못 따라갈까"] --> A
R3["또 흐지부지될 텐데"] --> A
A --> B["실제 업무 정보가 안 나옴"]
B --> C["엉뚱하게 만들어짐"]
C --> D["안 쓰임"]
```
### 뿌리 1 — 내 일이 없어질까
가장 직접적인 두려움입니다. [비용 절감](/guide/ax-cost)에서 다룬 대로, **절감된
시간이 어디로 가는지 먼저 말하는 것**이 답입니다.
말로만 하면 안 믿습니다. **첫 과제를 아무도 하기 싫어하는 일로 고르면** 말보다
빠르게 증명됩니다.
### 뿌리 2 — 내가 못 따라갈까
특히 연차가 높은 인력에게 큽니다. 지금까지 쌓은 숙련이 쓸모없어질까 하는
불안입니다.
이 불안은 **실제로 근거가 있습니다.** 다만 방향이 다릅니다 — 없어지는 건 숙련이
아니라 **숙련이 쓰이던 자리**입니다. 판단 능력은 오히려 더 중요해집니다.
[조심할 것](/guide/ai-cautions)에서 본 것처럼, AI 결과가 맞는지 판정하려면 그
업무를 아는 사람이 필요합니다.
이 설명이 통하게 하려면 **그 사람을 검증자로 세워야** 합니다. "당신 일을
대체합니다"가 아니라 "당신이 이걸 검증해주셔야 합니다"가 되면 위치가 바뀝니다.
### 뿌리 3 — 또 흐지부지될 텐데
이전에 실패한 IT 프로젝트가 있는 조직에서 강하게 나옵니다. 그리고 **대개 맞는
예측**입니다 — 실제로 흐지부지된 적이 있으니까요.
여기에는 말이 안 통합니다. **작은 것 하나를 실제로 끝내는 것**만 통합니다.
[첫 과제를 작게](/guide/ax-sequencing) 잡으라는 권고가 여기서도 맞아떨어집니다.
## 무엇을 해야 하나
### 1. 역할별로 다른 이야기를 하세요
같은 내용을 전사에 뿌리면 아무에게도 안 닿습니다.
| 대상 | 이 사람이 궁금한 것 |
|---|---|
| 경영진 | 얼마 들고 얼마 돌아오나, 리스크는 |
| 중간관리자 | 우리 팀 일이 어떻게 바뀌나, 인원은 |
| 실무자 | **내 일이 어떻게 바뀌나**, 뭘 배워야 하나 |
| IT | 우리가 뭘 해야 하나, 보안은 |
실무자에게 ROI를 설명하면 "결국 사람 줄이겠다는 거네"로 들립니다.
### 2. 당사자를 설계에 넣으세요
가장 효과가 큰 한 가지입니다. 그 업무 담당자가 설계에 참여하면:
- 실제 절차와 예외가 나옵니다 (안 그러면 POC에서 터집니다)
- **자기 일을 없애는 사람**이 아니라 **다시 짜는 사람**이 됩니다
- 배포 후 그 사람이 전파자가 됩니다
### 3. 첫 3~6개월은 집중 지원 기간으로 두세요
배포하고 손을 떼면 안 됩니다. 이 기간에 막히는 사람이 한 번 막히고 포기하면
돌아오지 않습니다.
```
집중 지원 기간에 준비할 것:
□ 물어볼 곳 (채널 하나, 담당자 지정)
□ 자주 나오는 질문 정리 (계속 갱신)
□ 재교육 기회 (한 번 듣고 다 이해 못 합니다)
□ 사용량 모니터링 (안 쓰는 사람이 누군지 보임)
```
### 4. 계속 이야기하세요
한 번의 공지로 끝나지 않습니다. 성과가 나오면 알리고, 개선되면 알리고, 다음
계획을 알립니다. **조용해지는 순간 "또 흐지부지되는구나"가 확인됩니다.**
## 특히 조심할 것 — 기술 습득의 반감기
AI 도구는 빠르게 바뀝니다. 한 번 교육하고 끝내면 몇 달 뒤에는 내용이 안 맞습니다.
**교육을 행사가 아니라 주기로** 잡아야 합니다.
## 자주 하는 오해
### "우리 조직은 위에서 지시하면 다 따릅니다"
지시를 따르는 것과 **협조하는 것**은 다릅니다. 지시로는 회의 참석까지는 되지만,
"이 업무에 이런 예외가 있습니다"라는 정보는 안 나옵니다. 그 정보 없이 만들면
POC에서 무너집니다.
### "교육을 충분히 하면 되지 않나?"
교육은 **뿌리 2**(내가 못 따라갈까)에만 듣습니다. 뿌리 1(일이 없어질까)과 뿌리
3(또 흐지부지)에는 안 듣습니다. 이 둘은 **말이 아니라 행동**으로만 해결됩니다 —
절감된 시간을 어디에 쓰는지 실제로 보여주고, 작은 것 하나를 실제로 끝내는 것.
---
## 확인
**1. 가장 위험한 형태의 저항은 무엇입니까?**
답
**침묵**입니다. 아무도 반대하지 않아 잘 되는 줄 알았는데 배포 후 아무도 안
씁니다. 명시적 반대는 이유를 들을 수 있어 오히려 다루기 쉽습니다.
**2. "또 흐지부지될 텐데"라는 저항에는 왜 설명이 안 통합니까?**
답
**대개 맞는 예측**이기 때문입니다. 실제로 흐지부지된 경험이 있어서 나오는 말이라
말로는 뒤집히지 않습니다. 작은 것 하나를 실제로 끝내는 것만 통합니다.
**3. 실무자에게 ROI를 설명하면 왜 역효과가 납니까?**
답
"결국 사람 줄이겠다는 거네"로 들리기 때문입니다. 실무자가 궁금한 것은 **내 일이
어떻게 바뀌고 뭘 배워야 하는가**입니다. 역할마다 궁금한 게 다르므로 같은 내용을
전사에 뿌리면 아무에게도 안 닿습니다.
---
여기까지가 **도입 절차**입니다. 다음 파트는 기술 파트로 넘어가기 전의 발판 —
기술 배경이 있다면 건너뛰어도 됩니다 →
[컴퓨터는 지금 무엇을 하고 있나](/guide/it-what-is-computer)