AX팀 신설이 AX를 실패하게 만드는 이유

AX 한다고 AX팀부터 만드는 게 왜 틀린 방향인지를 납득할 수 있게 써놓은 글.

AIAX
--
AX팀 신설이 AX를 실패하게 만드는 이유

제목부터 좀 과격하다 싶었다.

AX팀을 만드는 순간, 당신의 조직은 AX에 실패한다 — Flowkater.io의 Tony Cho가 쓴 글인데, 읽다가 중간에 멈춘 지점이 몇 군데 있었다.

분량이 꽤 긴 글이다. 그냥 훑고 넘기기엔 아까워서 읽은 것들을 조금 정리해두려고 한다.


반복되는 패턴

글쓴이가 먼저 꺼내는 건 기시감이다.

DX 추진 TF. 클라우드 전환 본부. 빅데이터 혁신팀. 조직에서 무언가를 혁신하겠다고 할 때마다 새로운 팀을 만드는 방식. 그게 몇 번째 반복인지 돌아보면, 사실 결과가 어떻게 됐는지도 대부분 기억난다.

AX팀도 같은 패턴이라는 게 요지다.

그리고 그 이유로 제시하는 게 흥미롭다. AX의 본질은 계층을 줄이는 것인데, AX팀을 신설하는 건 기존 계층 위에 하나를 더 올리는 일이라는 것. 해결하려는 방향과 정반대되는 수단을 쓰고 있다는 지적이다.

MIT 연구 데이터도 인상적이었다. GenAI 파일럿의 95%가 실패하는데, 성공한 5%는 중앙 AI 조직이 아니라 현장의 line manager가 직접 도입을 이끈 조직이었다는 것.


도구가 아니라 정체성의 문제

글 중반에 사람 얘기가 나오는데, 이 부분이 가장 오래 읽혔다.

사람들은 직무를 정체성으로 생각한다. 15년차 마케터가 AI가 자기 일주일치 리포트를 3시간 만에 뽑아내는 걸 봤을 때 드는 첫 감정이 "신기하다"가 아닐 거라는 것. 그 전에 "그럼 나는 뭐지?"가 먼저 온다는 말.

개발자도 다르지 않다. 자신이 몇 년 동안 익혀온 패턴을 AI가 제법 그럴듯하게 복제하는 걸 보는 순간은, 단순히 생산성 도구를 접한 게 아니라 자기 전문성의 경계를 다시 보게 되는 순간이다.

그래서 AX는 도입보다 전환이 어렵다. 라이선스 사는 건 도입이다. 사람의 정체성을 다시 짜는 건 전환이다. 이 둘은 완전히 다른 일이다.

데모는 넘치는데, 그다음 월요일에 사람이 뭘 해야 하는지 말해주는 곳이 없다는 문장도 찔렸다. "당신 직무의 60%가 자동화됩니다"까지는 말한다. 하지만 "남은 40%에서 당신은 이제 무엇을 책임져야 합니다"까지 가는 조직은 드물다고.


컨설팅으로 CTO가 된 얘기

글쓴이가 개인 경험을 꺼내는 부분이 있다. 공개적으로 처음 하는 이야기라고 했다.

한 회사의 기술 조직 컨설팅을 맡았는데, 주 4번을 하루 3시간씩 저녁에 그 회사 사무실에 출근했다. 한 달 동안 그 조직의 코드를 읽고, 회의에 들어가고, 사람들과 이야기했다. 기술 스택은 당시 자신이 써본 적 없는 것들이었다. 그런데 한 달 뒤 CTO로 합류했다.

기술은 배우면 된다. 도메인은 파면 된다. 하지만 같이 일할 사람이 없으면 아무것도 안 된다는 게 그 결정의 이유였다고.

그리고 막상 풀타임으로 들어갔더니 컨설팅 기간에는 보이지 않던 문제들이 산더미처럼 쌓여 있었다는 것도 솔직하게 썼다.

이 이야기를 꺼낸 이유는 결국 하나로 모인다. 조직을 바꾸려면 조직을 이해해야 하고, 그러려면 시간을 써야 한다. 바깥에서 프레임워크를 던지는 방식으로는 안 된다는 것.


개인 자동화는 신호일 뿐 증거가 아니다

후반부에 나오는 이 구분이 꽤 날카로웠다.

조직원들이 하나씩 자기만의 툴을 만들어오기 시작할 때 뿌듯한 감정이 드는 건 자연스럽다. 그런데 그게 조직의 AX일까라는 질문을 던진다.

개인의 마찰은 줄여주지만 조직의 병목은 건드리지 못한다면, 그건 고도화된 각자도생이라는 표현을 썼다. 툴은 늘어나는데 조직은 더 잘 안 맞물리는 상태.

활동 지표와 성과 지표를 구분하는 표도 있는데, 사내 AI 사용자 수나 만든 자동화 툴 개수는 활동 지표고, 고객 리드타임이나 핸드오프 감소량이 성과 지표라는 것. 사내 발표용으로 쓰기 좋은 건 전자지만 진짜 AX는 후자로 측정해야 한다.

개인 자동화 20개가 흩어진 조직보다 공통 병목 하나를 제대로 없앤 조직이 훨씬 더 AX에 가깝다는 말이 머리에 남는다.


그래도 AX팀이 이미 만들어졌다면

현실적인 이야기도 한다.

AX팀에 필요한 건 AI 전문가가 아니라, 현장의 병목이 어딘지 실제로 아는 사람들이라는 것. 마케팅 병목을 아는 마케터, 개발 파이프라인의 진짜 문제를 아는 엔지니어. 이 사람들이 모여서 자기 현장의 일하는 방식을 재설계해야 한다.

미션도 중요하다. "AI 도입 촉진"은 미션이 아니라 슬로건이다. "고객 문의 1차 응답 시간을 24시간에서 4시간으로 줄인다"처럼 구체적이어야 팀이 도구가 아니라 프로세스를 보게 된다.

그리고 마지막에 쓴 말이 인상적이었다.

AX팀이 성공하려면, AX팀이 스스로 사라지는 것을 목표로 해야 한다. 각 현장 조직이 자체적으로 AX를 수행할 수 있게 되면 별도의 AX팀은 필요 없어진다. 존재의 목적이 자기 소멸인 팀.

역설적이지만, 유일하게 작동하는 설계라고 했다.


요즘 AX 관련 글들이 쏟아지는데, 도구 시연이나 성공 사례 번역에 그치는 경우가 많다. 이 글은 왜 실패하는지를 구조적으로 짚고, 본인 경험도 솔직하게 얹은 편이라 읽는 맛이 달랐다.

원문: AX팀을 만드는 순간, 당신의 조직은 AX에 실패한다

댓글

0/2000
Newsletter

이 글이 도움이 되셨나요?

새로운 글이 발행되면 이메일로 알려드립니다.

뉴스레터 구독하기