전환이 실패하는 방식

이 장에서 배우는 것 전환이 무너지는 세 가지 전형적인 경로, 각각의 조기 징후, 그리고 이미 그 상태라면 무엇을 되돌려야 하는지.

실패는 조용히 옵니다

AI 전환은 폭발적으로 실패하지 않습니다. 시스템이 멈추거나 사고가 나는 게 아니라, 어느 순간 아무도 얘기하지 않게 됩니다. 계정은 살아 있고 비용은 계속 나가는데 그 프로젝트를 아무도 언급하지 않습니다.

그래서 실패를 미리 알아보는 눈이 필요합니다. 세 가지 경로를 순서대로 보겠습니다.

실패 1 — 목적 없이 도입한 경우

어떻게 시작되나

대개 이런 문장에서 출발합니다.

"요즘 다들 AI 쓴다는데 우리도 뭐라도 해야 하지 않나?"

나쁜 동기는 아닙니다. 문제는 이 문장에 무엇을 해결할지가 없다는 것입니다. 목적이 없으면 자연스럽게 "일단 다 열어주고 알아서 쓰게 하자"로 갑니다.

진행 과정

왜 이렇게 되나

목적이 없으면 성공을 정의할 수 없고, 정의할 수 없으면 개선할 수도 없습니다. 사용자들은 각자 알아서 쓸모를 찾는데, 개인이 혼자 찾을 수 있는 쓸모는 대개 번역·요약·문장 다듬기 정도입니다. 그건 조직의 지표를 움직이지 못합니다.

조기 징후 — 2개월차에 보입니다

이 질문을 던져보세요.

"이 프로젝트가 성공했다는 걸 무엇으로 압니까?"

답이 이렇게 나오면 이미 이 경로입니다.

• "직원들이 잘 쓰고 있으면요"
• "생산성이 올라가면요" (무엇으로 재는지 없음)
• "일단 써봐야 알죠"

되돌리는 법

전면 확대를 멈추고 업무 하나를 고릅니다. 숫자가 있는 업무여야 합니다 — "월 보고서 작성에 40시간", "문의 중 60%가 같은 세 질문". 그 하나로 결과를 만든 뒤에 넓힙니다. 다음 장의 세 가지 질문이 그 고르는 기준입니다.

실패 2 — 효과를 측정할 기준이 없는 경우

어떻게 시작되나

이번에는 목적이 있습니다. "청구서 처리 자동화" 같은 구체적인 과제로 시작합니다. 그런데 시작 전의 상태를 기록해두지 않았습니다.

진행 과정

6개월 뒤 성과 보고 자리에서 이런 대화가 오갑니다.

경영진: 시간이 얼마나 줄었습니까? 담당자: 확실히 빨라졌습니다. 팀에서도 만족합니다. 경영진: 얼마나요? 담당자: ...정확한 수치는 없는데, 체감상 절반 정도? 경영진: 그 절반이면 인력을 다른 데 쓸 수 있습니까? 담당자: 그건... 좀 더 봐야 합니다.

이 대화 이후 확대 예산이 나오지 않습니다. 실패했기 때문이 아니라 성공을 증명하지 못했기 때문입니다. 이게 가장 아까운 실패입니다 — 실제로는 효과가 있었을 수 있습니다.

왜 이렇게 되나

시작 시점에는 다들 바쁩니다. "일단 만들고 효과는 나중에 측정하자"가 자연스럽게 나옵니다. 그런데 나중에는 이전 상태를 알 수 없습니다. 예전에 몇 시간 걸렸는지 아무도 기록해두지 않았고, 기억은 서로 다릅니다.

조기 징후 — 시작 전에 보입니다

이 표를 채울 수 있는지 확인하세요. 착수 전에 빈칸이 있으면 그 자리가 나중에 그대로 빈칸으로 남습니다.

마지막 줄이 특히 중요합니다. "시간을 잰다"고만 하면 안 되고, 누가 언제 어떻게 재는지가 있어야 합니다.

되돌리는 법

이미 시작했다면 지금이라도 현재 상태를 기록하세요. 시작 전 데이터가 없으면 "도입 후 3개월"과 "도입 후 6개월"을 비교하는 방식으로라도 추세를 만들 수 있습니다. 아무 숫자도 없는 것보다 낫습니다.

실패 3 — 업무 흐름을 그대로 둔 경우

이게 가장 흔하고 가장 알아채기 어렵습니다. 앞 장 A사가 정확히 이 경우였습니다.

어떻게 시작되나

목적도 있고 측정 기준도 있습니다. 그런데 기존 절차를 건드리지 않고 그 안에 AI 단계만 추가합니다. 조직 입장에서 가장 안전해 보이는 선택이라 자주 벌어집니다.

진행 과정

graph TD
  A["기존 절차<br/>읽기 → 작성 → 발송"] --> B["AI 단계 삽입"]
  B --> C["읽기 → AI 요청 → 초안 검토 → 수정 → 발송"]
  C --> D["단계가 늘어남"]
  D --> E["개인은 더 바빠짐"]
  E --> F["현장에서 조용히 안 씀"]

왜 이렇게 되나

AI가 만든 결과물은 누군가 확인해야 합니다. 그 확인이 기존 업무에 얹히면 총 작업량이 늘어납니다. 작성이 검토로 바뀐 게 아니라 작성 + 검토가 된 것입니다.

이 실패가 특히 위험한 이유는 초기 지표가 좋아 보인다는 점입니다. 사용량은 높습니다 — 다들 쓰고 있으니까요. 결과물 품질도 나쁘지 않습니다. 그런데 몇 달 뒤 조용히 사용량이 떨어집니다.

조기 징후 — 3~4개월차, 이 말이 나올 때

"AI가 만든 거 확인하는 게 더 오래 걸려요" "그냥 제가 쓰는 게 빨라요" "초안은 쓸 만한데 결국 다 고쳐야 해요"

이건 품질 불만이 아니라 구조 신호입니다. 모델을 바꾸거나 프롬프트를 고쳐서 해결되지 않습니다. 절차가 그대로이기 때문에 나는 말입니다.

되돌리는 법

질문을 바꿔야 합니다.

B사가 한 것이 왼쪽에서 오른쪽으로 질문을 바꾼 일이었습니다. 82%를 상담원에게 오지 않게 만들었고, 남은 18%에만 사람을 붙였습니다.

세 실패를 나란히

마지막 줄을 눈여겨보세요. 세 실패 모두 엉뚱한 원인으로 진단되기 쉽습니다. 그래서 교육을 더 하거나 모델을 바꾸는 데 시간을 더 씁니다. 원인이 다른 곳에 있으니 나아지지 않습니다.

자주 하는 오해

"실패 사례가 많다니 아직 시기상조 아닌가"

세 실패 중 기술 때문인 것은 하나도 없습니다. 목적 부재, 측정 부재, 절차 미변경은 전부 조직이 통제할 수 있는 영역입니다. 시기의 문제가 아니라 준비의 문제입니다.

"우리는 작게 시작하니까 해당 없다"

규모와 무관합니다. 작게 시작해도 목적이 없으면 실패 1이고, 측정을 안 하면 실패 2입니다. 오히려 작은 시작일수록 측정이 더 중요합니다 — 확대 여부를 그 숫자로 결정해야 하기 때문입니다.

확인

1. 실패 3(절차 미변경)이 가장 알아채기 어려운 이유는 무엇입니까?

2. "AI가 만든 걸 확인하는 게 더 오래 걸린다"는 말을 들었습니다. 무엇을 해야 합니까?

3. 착수 전에 반드시 기록해야 하는 것은 무엇입니까?

이 셋에 우리 조직을 대입해봅니다. 40분입니다 → 우리 조직의 준비도를 채점해보기