AX 전환은 설득이 아니라 이주다

조직의 AX 전환이라는 말은 너무 순하게 들린다.

전 직원에게 AI 계정을 준다. 프롬프트 교육을 한다. 팀별 활용 사례를 모은다. 잘 쓴 사람을 발표시킨다. 리더가 "앞으로 AI를 적극적으로 활용합시다"라고 말한다.

다 필요하다.

하지만 이건 전환이 아니다.

이건 도입이다.

전환은 더 거칠다. 기존 조직이 일을 받는 방식, 승인하는 방식, 기록하는 방식, 책임지는 방식을 바꾸는 일이다. 더 정확히는 기존 조직을 설득해서 바꾸는 게 아니라, 새 운영체계를 옆에 만든 뒤 일을 그쪽으로 이주시켜야 하는 일이다.

AX는 adoption이 아니라 migration이다.

기존 조직은 쉽게 바뀌지 않는다

기존 조직이 AI 전환을 못 하는 이유는 사람들이 게을러서가 아니다.

기존 조직은 이미 기존 방식에 최적화되어 있기 때문이다.

일은 늘 가던 길로 간다. 누군가는 메신저로 요청한다. 누군가는 회의에서 결정한다. 누군가는 엑셀에 적는다. 누군가는 머릿속으로만 알고 있다. 누군가는 마지막에 덮어준다. 어떤 결정은 문서로 남고, 어떤 결정은 말로만 지나간다.

그게 조직의 진짜 구조다.

여기에 AI를 얹으면 사람들은 기존 길 안에서 AI를 쓴다. 메일 문장을 고친다. 보고서 초안을 빨리 쓴다. 회의록을 요약한다. 리서치 시간을 줄인다.

나쁘지 않다.

하지만 조직은 그대로다.

요청은 여전히 흩어진다. 승인은 여전히 늦다. 책임은 여전히 흐리다. 정본은 여전히 불명확하다. 같은 질문은 계속 반복된다.

개인 작업은 빨라졌는데 조직 throughput은 안 바뀌는 이유가 여기에 있다.

문제는 AI 사용률이 아니다.

문제는 routing이다.

병행구축이 핵심이다

그래서 AX 전환은 교육 캠페인이 아니라 병행구축이어야 한다.

기존 조직을 바로 부수자는 말이 아니다. 기존 업무를 멈추자는 말도 아니다. 대신 옆에 새 업무 처리 레일을 만든다.

그 레일에는 처음부터 다른 규칙이 있어야 한다.

요청은 어디로 들어오는가. 필요한 context는 어디에 있는가. agent는 무엇을 먼저 읽는가. 어디까지 초안을 만드는가. 사람은 어디서 승인하는가. 완료된 결과는 어디에 남는가. 다음 반복 때 무엇이 재사용되는가.

이 질문에 답하지 못하면 AI는 계속 개인기다.

답할 수 있으면 업무 레일이 된다.

John Kotter가 말한 dual operating system도, HBR의 ambidextrous organization도 결국 같은 긴장을 다룬다. 기존 조직은 오늘의 일을 굴리는 데 필요하지만, 새 방식은 기존 조직 안에서 자연스럽게 자라지 않는다.

옆에 만들어야 한다.

파일럿이 아니라 shadow production이어야 한다

여기서 파일럿이라는 말도 조심해야 한다.

많은 파일럿은 안전한 데모로 끝난다. 작은 실험을 해봤다. 가능성을 확인했다. 발표를 했다. 그리고 다시 원래 방식으로 돌아간다.

AX 병행구축은 그런 파일럿이면 안 된다.

shadow production이어야 한다.

같은 실제 업무를 새 레일에서도 끝까지 처리해본다. 처음부터 agent가 외부 시스템에 쓰거나 최종 결정을 내릴 필요는 없다. 읽고, 정리하고, 누락을 찾고, 초안을 만들고, 사람이 볼 review queue에 올리면 된다.

중요한 건 자동화율이 아니다.

새 업무 흐름이 실제로 도는지다.

BCG가 agent autonomy를 설명하면서 Shadow Mode를 첫 단계로 두는 이유도 여기에 있다. agent가 제안하고 인간이 실행하는 방식은 위험을 키우지 않으면서 실제 업무 맥락에 맞는지 검증하게 해준다.

AX의 질문은 "AI가 할 수 있나?"가 아니다.

"우리 조직의 context 안에서, 이 업무를 어디까지 맡길 수 있나?"다.

그 답은 회의실에서 안 나온다.

굴려봐야 나온다.

어느 순간 옛길을 닫아야 한다

병행구축만으로는 부족하다.

새 레일이 어느 정도 돌아가면 옛길을 닫아야 한다.

이게 제일 어렵다. 새 시스템도 있고, 옛 방식도 있는 상태가 가장 편하기 때문이다. 바쁘면 메신저로 던진다. 급하면 말로 처리한다. 예외는 늘 있다. 그러면 새 레일은 장식이 된다.

조직은 말보다 route에 반응한다.

이 업무는 이제 새 레일로만 접수한다. 이 양식 밖 요청은 반려한다. 승인 기록이 없으면 완료로 인정하지 않는다. 정본에 남지 않은 결정은 결정으로 보지 않는다. 예외는 지정된 책임자가 승인하고, 예외 사유도 기록한다.

이 정도의 route closure가 있어야 이주가 일어난다.

소프트웨어 migration과 똑같다. 새 시스템을 만들고도 옛 시스템을 계속 열어두면 데이터는 갈라진다. 운영 부담은 두 배가 된다. 결국 사람들은 더 익숙한 쪽으로 돌아간다.

조직도 그렇다.

선택사항으로 남긴 새 방식은 기존 방식에 진다.

AX 리더는 전도사가 아니라 이주 설계자다

그래서 AX 리더십은 전도사의 일이 아니다.

좋은 말로 사람들을 설득하고, 멋진 사례를 보여주고, "우리도 할 수 있습니다"라고 말하는 것만으로는 부족하다.

AX 리더는 이주 설계자에 가깝다.

어떤 업무부터 옮길지 정한다. 기존 route를 관찰한다. 새 route를 설계한다. 작은 전환 셀을 만든다. agent가 맡을 일과 사람이 맡을 일을 나눈다. 승인 gate를 둔다. 실제 업무를 shadow production으로 돌린다. 실패한 케이스를 기록한다. 성공한 케이스를 표준화한다. 그리고 어느 시점에 legacy 접수를 닫는다.

사람의 역할도 바뀐다.

단순 실행자는 줄어든다. 대신 결과 책임자, reviewer, exception handler, context curator가 중요해진다. agent가 더 많은 초안과 실행 보조를 맡을수록 사람은 방향을 정하고, 결과를 평가하고, 예외를 처리하는 쪽으로 이동한다.

Microsoft의 2026 Work Trend Index가 말하는 핵심도 비슷하다. AI의 효과는 개인 능력보다 조직 환경, manager support, talent practice 같은 시스템 조건에 더 크게 묶인다. 시스템은 스스로 고쳐지지 않는다. 다시 설계해야 한다.

작게 시작하되 진짜로 옮겨야 한다

시작은 작아야 한다.

전사 AX 전환 같은 말부터 꺼내면 흐려진다. 반복되는 업무 하나를 고르면 된다.

주간 고객 문의 패턴 요약. 캠페인 문안 리스크 점검. 신규 리드 검증. 월마감 증빙 누락 확인. 채용 후보자 1차 정리. 발행 전 글의 출처와 주장 점검.

이 중 하나를 고른다.

요청 양식을 정한다. 필요한 자료 위치를 정한다. agent의 출력 형식을 정한다. 사람이 승인할 기준을 정한다. 완료 결과가 남을 정본을 정한다.

그리고 5번, 10번 실제로 돌린다.

어디서 막히는지 보인다. 어떤 context가 부족한지 보인다. 사람이 어느 지점에서 시간을 쓰는지 보인다. agent가 잘하는 부분과 위험한 부분이 갈린다.

그때부터 rule, checklist, template, permission이 생긴다.

이게 운영 자산이다.

AX 전환은 AI를 많이 쓰자는 캠페인이 아니다.

기존 조직 위에 AI를 붙이는 것도 아니다.

새 업무 레일을 병행 구축하고, 실제 업무로 검증하고, 충분히 작동하면 옛길을 닫아 일을 이주시키는 것이다.

AX는 adoption이 아니라 migration이다.

기존 조직을 AI로 바꾸려 하지 말고, 일이 지나가는 길을 바꿔야 한다.