# 전환이 실패하는 방식
> **이 장에서 배우는 것**
> 전환이 무너지는 세 가지 전형적인 경로, 각각의 조기 징후, 그리고 이미 그
> 상태라면 무엇을 되돌려야 하는지.
## 실패는 조용히 옵니다
AI 전환은 **폭발적으로 실패하지 않습니다.** 시스템이 멈추거나 사고가 나는 게
아니라, 어느 순간 아무도 얘기하지 않게 됩니다. 계정은 살아 있고 비용은 계속
나가는데 그 프로젝트를 아무도 언급하지 않습니다.
그래서 실패를 **미리 알아보는 눈**이 필요합니다. 세 가지 경로를 순서대로
보겠습니다.
---
## 실패 1 — 목적 없이 도입한 경우
### 어떻게 시작되나
대개 이런 문장에서 출발합니다.
> "요즘 다들 AI 쓴다는데 우리도 뭐라도 해야 하지 않나?"
나쁜 동기는 아닙니다. 문제는 이 문장에 **무엇을 해결할지가 없다**는 것입니다.
목적이 없으면 자연스럽게 "일단 다 열어주고 알아서 쓰게 하자"로 갑니다.
### 진행 과정
| 시점 | 벌어지는 일 |
|---|---|
| 1개월 | 전사 계정 발급, 사용 안내 메일, 초기 관심 높음 |
| 2개월 | 활발히 쓰는 소수와 안 쓰는 다수로 갈림 |
| 4개월 | 활발히 쓰던 사람도 특정 용도(번역·요약)로만 씀 |
| 6개월 | "그래서 뭐가 좋아졌나요?" 질문에 아무도 답 못 함 |
### 왜 이렇게 되나
목적이 없으면 **성공을 정의할 수 없고**, 정의할 수 없으면 개선할 수도 없습니다.
사용자들은 각자 알아서 쓸모를 찾는데, 개인이 혼자 찾을 수 있는 쓸모는 대개
**번역·요약·문장 다듬기** 정도입니다. 그건 조직의 지표를 움직이지 못합니다.
### 조기 징후 — 2개월차에 보입니다
이 질문을 던져보세요.
> **"이 프로젝트가 성공했다는 걸 무엇으로 압니까?"**
답이 이렇게 나오면 이미 이 경로입니다.
- "직원들이 잘 쓰고 있으면요"
- "생산성이 올라가면요" (무엇으로 재는지 없음)
- "일단 써봐야 알죠"
### 되돌리는 법
전면 확대를 멈추고 **업무 하나를 고릅니다.** 숫자가 있는 업무여야 합니다 —
"월 보고서 작성에 40시간", "문의 중 60%가 같은 세 질문". 그 하나로 결과를 만든
뒤에 넓힙니다. 다음 장의 [세 가지 질문](/guide/ax-choosing-tasks)이 그 고르는
기준입니다.
---
## 실패 2 — 효과를 측정할 기준이 없는 경우
### 어떻게 시작되나
이번에는 목적이 있습니다. "청구서 처리 자동화" 같은 구체적인 과제로 시작합니다.
그런데 **시작 전의 상태를 기록해두지 않았습니다.**
### 진행 과정
6개월 뒤 성과 보고 자리에서 이런 대화가 오갑니다.
> **경영진**: 시간이 얼마나 줄었습니까?
> **담당자**: 확실히 빨라졌습니다. 팀에서도 만족합니다.
> **경영진**: 얼마나요?
> **담당자**: ...정확한 수치는 없는데, 체감상 절반 정도?
> **경영진**: 그 절반이면 인력을 다른 데 쓸 수 있습니까?
> **담당자**: 그건... 좀 더 봐야 합니다.
이 대화 이후 **확대 예산이 나오지 않습니다.** 실패했기 때문이 아니라 **성공을
증명하지 못했기 때문**입니다. 이게 가장 아까운 실패입니다 — 실제로는 효과가
있었을 수 있습니다.
### 왜 이렇게 되나
시작 시점에는 다들 바쁩니다. "일단 만들고 효과는 나중에 측정하자"가 자연스럽게
나옵니다. 그런데 **나중에는 이전 상태를 알 수 없습니다.** 예전에 몇 시간
걸렸는지 아무도 기록해두지 않았고, 기억은 서로 다릅니다.
### 조기 징후 — 시작 전에 보입니다
이 표를 채울 수 있는지 확인하세요. 착수 전에 빈칸이 있으면 그 자리가 나중에
그대로 빈칸으로 남습니다.
| 항목 | 값 |
|---|---|
| 지금 이 업무에 걸리는 시간 | ? |
| 월 처리 건수 | ? |
| 현재 오류율 / 재작업 건수 | ? |
| 담당 인원 | ? |
| **측정 방법** | ? |
마지막 줄이 특히 중요합니다. "시간을 잰다"고만 하면 안 되고, **누가 언제 어떻게
재는지**가 있어야 합니다.
### 되돌리는 법
이미 시작했다면 **지금이라도 현재 상태를 기록**하세요. 시작 전 데이터가 없으면
"도입 후 3개월"과 "도입 후 6개월"을 비교하는 방식으로라도 추세를 만들 수
있습니다. 아무 숫자도 없는 것보다 낫습니다.
---
## 실패 3 — 업무 흐름을 그대로 둔 경우
이게 **가장 흔하고 가장 알아채기 어렵습니다.** 앞 장 A사가 정확히 이 경우였습니다.
### 어떻게 시작되나
목적도 있고 측정 기준도 있습니다. 그런데 기존 절차를 건드리지 않고 그 안에 AI
단계만 **추가**합니다. 조직 입장에서 가장 안전해 보이는 선택이라 자주 벌어집니다.
### 진행 과정
```mermaid
graph TD
A["기존 절차
읽기 → 작성 → 발송"] --> B["AI 단계 삽입"]
B --> C["읽기 → AI 요청 → 초안 검토 → 수정 → 발송"]
C --> D["단계가 늘어남"]
D --> E["개인은 더 바빠짐"]
E --> F["현장에서 조용히 안 씀"]
```
### 왜 이렇게 되나
AI가 만든 결과물은 **누군가 확인해야 합니다.** 그 확인이 기존 업무에 얹히면
총 작업량이 늘어납니다. 작성이 검토로 바뀐 게 아니라 **작성 + 검토**가 된
것입니다.
이 실패가 특히 위험한 이유는 **초기 지표가 좋아 보인다**는 점입니다. 사용량은
높습니다 — 다들 쓰고 있으니까요. 결과물 품질도 나쁘지 않습니다. 그런데 몇 달
뒤 조용히 사용량이 떨어집니다.
### 조기 징후 — 3~4개월차, 이 말이 나올 때
> "AI가 만든 거 확인하는 게 더 오래 걸려요"
> "그냥 제가 쓰는 게 빨라요"
> "초안은 쓸 만한데 결국 다 고쳐야 해요"
이건 **품질 불만이 아니라 구조 신호**입니다. 모델을 바꾸거나 프롬프트를 고쳐서
해결되지 않습니다. 절차가 그대로이기 때문에 나는 말입니다.
### 되돌리는 법
질문을 바꿔야 합니다.
| 실패하는 질문 | 되돌리는 질문 |
|---|---|
| "이 업무를 AI가 어떻게 도울까?" | "이 업무가 **아예 발생하지 않게** 할 수 있나?" |
| "초안을 잘 만들려면?" | "사람이 검토할 필요가 없는 건 어디까지인가?" |
| "누가 확인하지?" | "확인 없이 나가도 되는 것과 아닌 것을 어떻게 가르나?" |
B사가 한 것이 왼쪽에서 오른쪽으로 질문을 바꾼 일이었습니다. 82%를 **상담원에게
오지 않게** 만들었고, 남은 18%에만 사람을 붙였습니다.
---
## 세 실패를 나란히
| | 실패 1 | 실패 2 | 실패 3 |
|---|---|---|---|
| 무엇이 없나 | 목적 | 측정 기준 | 절차 변경 |
| 언제 드러나나 | 6개월 | 성과 보고 시점 | 3~4개월 |
| 조기 징후 | "성공을 무엇으로 아나?"에 답 못 함 | 착수 전 표에 빈칸 | "직접 하는 게 빠르다" |
| 잘못 진단하면 | "직원 교육이 부족" | "효과가 원래 없었다" | "모델이 부족" |
마지막 줄을 눈여겨보세요. **세 실패 모두 엉뚱한 원인으로 진단되기 쉽습니다.**
그래서 교육을 더 하거나 모델을 바꾸는 데 시간을 더 씁니다. 원인이 다른 곳에
있으니 나아지지 않습니다.
## 자주 하는 오해
### "실패 사례가 많다니 아직 시기상조 아닌가"
세 실패 중 **기술 때문인 것은 하나도 없습니다.** 목적 부재, 측정 부재, 절차
미변경은 전부 조직이 통제할 수 있는 영역입니다. 시기의 문제가 아니라 준비의
문제입니다.
### "우리는 작게 시작하니까 해당 없다"
규모와 무관합니다. 작게 시작해도 목적이 없으면 실패 1이고, 측정을 안 하면
실패 2입니다. 오히려 작은 시작일수록 측정이 더 중요합니다 — 확대 여부를
그 숫자로 결정해야 하기 때문입니다.
---
## 확인
**1. 실패 3(절차 미변경)이 가장 알아채기 어려운 이유는 무엇입니까?**
답
**초기 지표가 좋아 보이기 때문**입니다. 사용량도 높고 결과물 품질도 나쁘지
않습니다. 문제는 총 작업량이 늘었다는 것인데, 그건 몇 달 뒤 사용량이 조용히
떨어질 때에야 드러납니다. 게다가 그때 나오는 말("직접 하는 게 빠르다")이 품질
불만처럼 들려서 모델이나 프롬프트 문제로 오진하기 쉽습니다.
**2. "AI가 만든 걸 확인하는 게 더 오래 걸린다"는 말을 들었습니다. 무엇을 해야
합니까?**
답
모델이나 프롬프트를 손대는 게 아니라 **절차를 봐야 합니다.** 이 말은 기존 절차에
AI 단계가 추가되기만 했다는 구조 신호입니다. "이 업무가 아예 발생하지 않게 할 수
있나", "사람 검토 없이 나가도 되는 범위는 어디까지인가"로 질문을 바꿔야 합니다.
**3. 착수 전에 반드시 기록해야 하는 것은 무엇입니까?**
답
현재 상태의 숫자입니다 — 걸리는 시간, 월 처리 건수, 오류·재작업 건수, 담당 인원,
그리고 **측정 방법**(누가 언제 어떻게 재는지). 나중에는 이전 상태를 알 수 없고
기억은 서로 다르기 때문에, 효과가 실제로 있었더라도 증명하지 못하게 됩니다.
---
이 셋에 우리 조직을 대입해봅니다. 40분입니다 →
[우리 조직의 준비도를 채점해보기](/guide/ax-try-readiness)