AX팀 리딩에서 깨달은 13가지 핵심 인사이트

게시 2026/03/31

By BLUEBUG

60 분읽는 시간

“AX의 본질은 ‘만들어주는 조직’이 아니라 ‘스스로 만들게 하는 조직’이다.”

작성 배경: Threads(@dev._pill) 계정에 올라온 AX팀 리딩 경험 요약 포스트를 기반으로, 총 13개의 명제 각각이 왜 옳은지, 산업 현장에서 무슨 의미를 갖는지, 그리고 최신 글로벌 연구와 어떻게 맞닿아 있는지를 심층적으로 풀어씁니다. 전반부(1 ~ 6번)는 AX의 본질에 대한 인식론적 선언이고, 후반부(7 ~ 13번)는 AX팀의 실천 구조와 지속가능성에 관한 운영 철학입니다. 이 두 층위를 함께 읽을 때 AX가 완전한 그림으로 보입니다.

요즘 여기저기서 AX AX 하는데
AX팀 리딩하면서 깨달은 점 정리해드림
AX는 AI 에이전트 도입이 아니라 Human Workflow Transformation이다.
에이전트 셋업해준다고 AX 되는 거 아니다.
핵심은 도메인 전문가가 스스로 자신의 워크플로우를 재정의하는 것이다.
AX팀은 문제를 대신 해결하는 조직이 아니라 코칭하고 보조하는 촉진자다.
Top-down으로 방향을 잡고 Bottom-up으로 변화가 퍼져야 한다.
AX는 rollout이 아니라 사람을 통해 퍼지는 확산 모델이다.
결론: AX의 본질은 “무슨 에이전트를 만들까”가 아니라 “누가 바뀔 준비가 되어 있는가”다.
AX팀이 백날 만들어줘봐라, 그거 다 기술부채다.
AX팀이 만들어서 떠먹이면 결국 중앙 의존성만 키우고 확산을 막는다.
100%를 AX팀이 해결하는 것보다 80%를 도메인 전문가가 직접 AI로 해결하는 게 훨씬 강하다.
AX팀의 역할은 빌더가 아니라 인프라를 깔고 판을 만드는 것이다.
실제 빌더는 도메인 전문가여야 지속 가능하다.
그래야 유지보수도, 개선도, 확산도 자연스럽게 일어난다.
결국 AX의 본질은 ‘만들어주는 조직’이 아니라 ‘스스로 만들게 하는 조직’이다.

들어가며: 왜 지금 AX인가

2025년 말부터 2026년 초에 걸쳐 한국의 대형 기업들이 일제히 AX(AI Transformation)를 핵심 전략으로 선언했다. 삼성, LG, SK, 현대차 그룹이 신년 조직 개편에서 AX를 중심축으로 설정했고, 정부 역시 세 개 부처가 공동으로 산업 AX 프로그램을 출범시켜 제조, 공급망, 재고 운영 같은 실질적 산업 환경으로 AI를 확장하겠다는 의지를 밝혔다. 표면적으로는 에이전트를 도입하고, AI 도구를 배포하고, 파일럿 프로젝트를 시작하는 것처럼 보이는 이 흐름은 그러나 현장에서 AX팀을 실제로 이끌어 본 사람들 사이에서 매우 다른 평가를 받고 있다.

“에이전트를 도입했는데 아무것도 바뀌지 않았다”는 좌절이 조용히 쌓이고 있다. BCG의 2025 글로벌 스터디에 따르면, C레벨 임원들을 대상으로 AI 성숙도를 조사했을 때 실질적인 재무 성과(매출 또는 현금 흐름 증가와 함께 유의미한 프로세스·워크플로우 개선)를 이뤄낸 조직은 전체의 단 5%에 불과했다. Salesforce의 한 임원은 “2026년은 ‘고독한 에이전트’의 해가 될 것”이라고 경고하면서, 기업들이 직원 한 명당 수백 개의 에이전트를 만들어 놓지만 대부분이 사용되지 않은 소프트웨어 라이선스처럼 방치될 것이라고 내다봤다. 왜 이런 일이 생기는가. 이 포스트는 그 답을 아주 명확하게 짚어낸다.

1부: AX의 본질 — 무엇을 만드는가가 아니라 누가 바뀌는가

명제 1: AX는 AI 에이전트 도입이 아니라 Human Workflow Transformation이다

이 첫 번째 명제는 나머지 모든 명제의 토대가 되는 가장 근본적인 선언이다. 수많은 조직이 AX를 오해하는 방식은 다음과 같다. “어떤 AI 도구를 구매할 것인가”, “어떤 에이전트를 셋업할 것인가”, “어떤 모델을 사용할 것인가”를 AX의 핵심 질문으로 삼는 것이다. 그러나 실제로 변화를 만들어 내는 것은 기술의 도입이 아니라 사람이 일하는 방식의 재설계다.

BCG는 이 점을 수치로 명확히 제시한다. 수백 개 기업의 사례 연구를 분석한 결과, AI 이니셔티브에서 나오는 가치의 약 10%만이 알고리즘 자체에서 비롯되고, 기술 구현에 필요한 인프라에서 약 20%가 나온다. 그리고 나머지 70%는 사람을 임파워하는 방식에서 나온다. PwC도 유사한 결론에 도달했는데, AI 이니셔티브에서 기술이 기여하는 가치는 약 20%이며 나머지 80%는 일하는 방식의 재설계에서 비롯된다고 봤다.

WEF(세계경제포럼)가 2026년 2월에 발표한 보고서는 “워크포스 트랜스포메이션은 독립적인 이니셔티브나 기술 업그레이드로 취급될 수 없다”고 강조한다. 즉, 에이전트를 도입하는 행위 자체는 AX의 도구이지 AX 그 자체가 아니다. 진정한 AX는 조직 구성원 개개인이 자신이 매일 수행하는 업무의 구조를 바꾸는 것, 그 과정의 총합이다.

IMD의 Mark Greeven 교수는 “2026년에 가장 성공적인 조직들은 AI를 기술 경쟁이 아닌 경영 혁명으로 취급하기 시작할 것”이라고 말했다. 가장 많은 모델을 배포한 곳이 이기는 게 아니라, 의사결정·팀·책임의 방식을 AI 중심으로 재발명한 곳이 이긴다는 것이다.

명제 2: 에이전트 셋업해준다고 AX 되는 거 아니다

이 명제는 현장에서 AX를 추진해 본 사람이라면 뼈저리게 공감할 진술이다. 기술팀이 에이전트를 구축하고, 그럴듯한 데모를 만들고, 현업팀에 인계한다. 그런데 몇 주가 지나도 아무도 쓰지 않는다. 혹은 몇 번 쓰다가 “역시 AI는 안 되네”라는 결론과 함께 방치된다.

이 실패 패턴은 구조적이다. MIT NANDA의 2025년 연구에 따르면 기업 AI 파일럿의 95%가 의미 있는 성과를 내는 데 실패한다. McKinsey의 2025년 글로벌 서베이에서는 응답자의 88%가 최소 한 개 이상의 비즈니스 기능에서 AI를 “정기적으로 사용”한다고 답했지만, 상당수는 여전히 실험 또는 파일럿 단계에 머물러 있으며 AI 프로그램을 실제로 스케일링하기 시작한 곳은 약 3분의 1에 불과하다.

실패의 핵심 원인은 에이전트와 사람의 워크플로우 간의 정합성 결여다. 에이전트를 만드는 것은 기술 행위다. 그러나 그 에이전트가 실제로 사람의 일을 대체하거나 보완하려면, 먼저 그 사람이 오늘 어떤 방식으로 일하는지, 어떤 단계가 병목인지, 어떤 결정에서 인지적 부담을 가장 크게 느끼는지를 깊이 이해해야 한다. 이것은 기술 지식이 아니라 업무 지식이다.

McKinsey는 이 문제를 “gen AI 패러독스”라고 부른다. 코파일럿처럼 수평적으로 확산되는 AI는 파급효과가 분산되어 측정하기 어렵고, 진정으로 변환적인 기능별 수직 활용 사례들은 파일럿 단계에서 벗어나지 못하고 있다는 것이다. 에이전트는 워크플로우를 볼트처럼 덧붙이는 게 아니라, 워크플로우를 재설계함으로써 가치를 낸다는 점을 인식해야 한다.

명제 3: 핵심은 도메인 전문가가 스스로 자신의 워크플로우를 재정의하는 것이다

이 명제야말로 AX의 정수다. 그리고 동시에 가장 달성하기 어려운 목표다.

왜 도메인 전문가여야 하는가? 이유는 단순하다. 외부 컨설턴트나 AI팀이 아무리 뛰어나도, 특정 업무의 세부적인 맥락과 비공식적 지식은 그 일을 수년간 수행해 온 당사자만이 안다. 마케터는 캠페인 기획에서 어느 단계가 가장 많은 시간을 잡아먹는지 안다. 법무팀 직원은 어떤 계약서 검토가 루틴이고 어떤 것이 판단을 요하는지 안다. 재무 분석가는 보고서 작성의 어떤 부분이 기계적 반복이고 어떤 부분이 진짜 통찰을 필요로 하는지 안다.

이 지식을 토대로 워크플로우를 재정의하는 주체는 AI팀이 아니라 도메인 전문가 본인이어야 한다. AX팀은 그 과정을 설계하고 촉진할 수 있지만, 실제로 “내 일의 어떤 부분을 AI에게 맡기고, 어떤 부분은 내가 더 잘할 수 있는가”를 결정하는 것은 그 업무의 주인이 해야 한다.

Deloitte는 Toyota의 Jason Ballard 사례를 통해 이 점을 명확히 보여준다. “에이전트 AI만으로는 충분하지 않다. 프로세스 재설계와 사람이 경쟁 우위를 만드는 핵심이다.” 도요타가 만든 것은 AI 도구가 아니라, 현장 직원들이 스스로 자신의 작업 방식을 바꾸는 문화적 환경이다.

BCG가 제시한 프레임워크에서도 AI 스케일링의 핵심은 “학습이 일상 업무 안에 내재되는 것”이다. 연간 워크숍이나 시나리오 기반 훈련이 아니라, 실제 도구로 실제 업무를 수행하면서 실제 피드백을 받는 것이 가장 효과적인 학습 방식이다. 도메인 전문가가 스스로 워크플로우를 재정의하는 과정 자체가 이 학습이다.

Gartner의 2025년 12월 CHRO 110명 대상 서베이에서도 78%가 “워크플로우와 역할이 AI 투자를 최대화하기 위해 바뀌어야 한다”고 동의했다. 그런데 중요한 것은 ‘바뀌어야 한다’는 인식과 ‘실제로 바꾸는 것’ 사이의 간극이다. 그 간극을 메우는 것이 AX팀의 역할이다.

명제 4: AX팀은 문제를 대신 해결하는 조직이 아니라 코칭하고 보조하는 촉진자다

이 명제는 AX팀의 자기 정체성에 관한 것이다. 많은 조직에서 AI팀이나 DX팀이 범하는 가장 흔한 실수는 “우리가 솔루션을 만들어 현업에 납품한다”는 프레임을 갖는 것이다.

이 프레임의 문제는 두 가지다. 첫째, 납품된 솔루션은 현업의 소유감(ownership)을 만들어 내지 못한다. 사람들은 자신이 만들거나 설계에 참여한 것에 애착을 갖고 사용한다. 외부에서 주어진 도구는 불편하면 즉시 포기한다. 둘째, AX팀이 모든 현업의 문제를 대신 해결하려 하면 스케일이 불가능하다. AX팀은 소수이고, 변환되어야 할 워크플로우는 조직 전체에 걸쳐 수천 가지다.

‘촉진자(facilitator)’로서의 AX팀은 다르게 행동한다. 현업이 스스로 자신의 문제를 발견하고, 스스로 AI를 실험하고, 스스로 판단할 수 있도록 역량을 키워준다. 구체적으로는 AI 리터러시 교육, 프롬프트 엔지니어링 기초, 워크플로우 재설계 워크숍, 파일럿 실험 설계 방법론 등을 코칭한다.

Axios가 2026년 3월 워싱턴에서 진행한 커뮤니케이션 리더십 라운드테이블에서도 유사한 결론이 나왔다. “리더들이 변화에 대해 솔직하게 말하면서 업스킬링과 장기적 커리어 발전을 강조할 때 도입이 가장 잘 이루어진다”는 것이다. 이것이 촉진자의 역할이다.

Gartner는 또한 “퍼포머티브 파티시페이션(performative participation)”을 식별하고 줄여야 한다고 경고한다. 직원들이 기회를 얻기 위해 변화를 ‘흉내만 내는’ 현상이다. 이것은 AX팀이 솔루션 납품자로 행동할 때 가장 빈번하게 발생한다. 진정한 촉진자는 표면적 참여가 아닌 실질적 변화를 이끌어 낸다.

명제 5: Top-down으로 방향을 잡고 Bottom-up으로 변화가 퍼져야 한다

이 명제는 AX의 거버넌스 구조에 관한 것이다. 그리고 이것은 많은 조직이 한쪽으로 치우치는 지점이다.

Pure Bottom-up의 실패: PwC의 2026 AI 예측 보고서는 이 점을 날카롭게 지적한다. 많은 조직이 리더십이 방향을 정하는 탑다운 프로그램 대신, 현장의 이니셔티브를 수집해서 전략으로 만들려는 보텀업 접근을 취한다. 결과적으로 생기는 것은 기업 우선순위와 맞지 않는 프로젝트들, 정밀하게 실행되지 않는 이니셔티브들, 그리고 거의 변환으로 이어지지 않는 결과물들이다. “AI 노력을 크라우드소싱하면 인상적인 도입 숫자를 만들어 낼 수는 있지만, 의미 있는 비즈니스 성과를 내는 경우는 드물다”고 PwC는 결론짓는다.

Pure Top-down의 실패: 반대로 경영진이 “AI를 쓰라”는 지시만 내리고 실제로 현장이 어떻게 적용할지 스스로 발견하도록 내버려 두지 않으면, 형식적인 준수만 이루어진다. Gartner가 지적한 퍼포머티브 파티시페이션이 바로 이 경우에 발생한다. 직원들은 AI를 쓰는 척하면서 평가를 받고, 실제로는 아무것도 바뀌지 않는다.

올바른 구조: 경영진은 “어디서 AI 투자의 성과가 가장 클 수 있는가”를 선별하고, 그 방향을 명확히 정의한다. 집중해야 할 워크플로우와 비즈니스 프로세스를 탑다운으로 지정하는 것이다. 그 다음, 해당 영역 안에서 도메인 전문가들이 스스로 실험하고, 변화를 만들고, 이 변화를 동료들에게 전파하는 보텀업 확산이 이루어진다. AX팀은 이 두 방향 사이의 다리 역할을 한다.

명제 6: AX는 rollout이 아니라 사람을 통해 퍼지는 확산 모델이다

‘롤아웃(rollout)’이라는 단어는 소프트웨어 배포 언어다. 일정이 있고, 마일스톤이 있고, 완료 기준이 있다. 그리고 배포가 완료되면 프로젝트는 끝난다. AX를 이렇게 이해하면 반드시 실패한다.

AX는 사회적 전염 모델에 가깝다. 한 부서에서 누군가가 AI를 통해 자신의 일을 실질적으로 바꾸는 데 성공하면, 그 사람이 동료에게 얘기하고, 그 동료가 따라 해보고, 그게 또 다른 사람에게 퍼지는 방식이다. 이 확산은 인증된 배포 계획이 아니라 신뢰와 성공 경험의 이동으로 이루어진다.

이 현상을 잘 설명하는 것이 ‘AI 챔피언(champion)’ 개념이다. AI 전환 플레이북들이 공통적으로 권고하는 것 중 하나가 “각 부서에 AI 챔피언을 임명하고 도입률과 성과를 주 단위로 측정하라”는 것이다. AI 챔피언은 기술 전문가가 아니라, 해당 도메인에서 AI를 성공적으로 적용하고 동료들에게 이것을 코칭할 수 있는 열의를 가진 사람이다. 이들이 확산의 벡터다.

중요한 역설이 있다. 확산 모델에서는 열정 있는 소수가 냉소적인 다수보다 훨씬 더 중요하다. 50명의 조직 구성원이 모두 AI를 피상적으로 쓰는 것보다, 5명이 깊이 이해하고 변화를 경험하며 나머지를 견인하는 것이 훨씬 빠른 AX로 이어진다. 이것이 바로 “누가 바뀔 준비가 되어 있는가”가 가장 중요한 질문인 이유다.

2부: AX팀의 실천 구조 — 무엇을 만드는가보다 어떻게 만들게 하는가

이 두 번째 장은 1부의 철학적 명제들을 한층 더 날카롭고 실천적인 언어로 계승한다. 명제 8~13는 “AX팀이 어떻게 행동해야 지속가능한가”에 대한 운영 원칙이다. 놀랍게도 이 원칙들은 소프트웨어 개발 방법론, 조직 설계 이론, 그리고 교육학이 동시에 도달하는 결론과 정확히 일치한다.

명제 7: AX팀이 백날 만들어봐라, 그거 다 기술부채다

이 명제는 매우 도발적으로 들리지만, 기술적으로도 조직적으로도 정확한 지적이다. 기술부채(technical debt)란 원래 소프트웨어 개발에서 쓰던 개념으로, 빠른 납기나 편의를 위해 임시방편으로 만든 코드나 시스템이 나중에 유지보수, 확장, 변경을 어렵게 만드는 비용의 누적을 뜻한다. AX팀이 현업의 문제를 대신 해결해 주는 방식으로 에이전트나 자동화 워크플로우를 계속 만들어 나가면, 이것이 정확히 같은 구조의 부채가 된다.

왜인가? 첫째, AX팀이 만든 도구는 그 도구가 풀려는 문제의 맥락을 AX팀이 아닌 현업이 갖고 있다. 비즈니스 로직이 바뀌거나, 팀 구조가 바뀌거나, 사용하던 외부 서비스가 변경되면, 그 도구는 즉시 쓸모가 없어진다. 그런데 그것을 고칠 수 있는 사람은 AX팀이고, AX팀은 이미 다음 문제를 만들러 가 있다. 둘째, 현업은 그 도구의 내부 작동 방식을 모르기 때문에 문제가 생겼을 때 자체적으로 대응할 수 없다. 모든 변경 요청이 AX팀을 통해야 하는 병목이 생긴다.

DEV Community의 2026년 3월 분석은 AI가 만들어내는 새로운 형태의 기술부채를 경고한다. AI 코딩 도구가 2026년 신규 상업 코드의 41%를 작성하고 있지만, 이것이 오히려 부채를 빠르게 누적시키는 구조를 만들고 있다는 것이다. 핵심 통찰은 이렇다. “AI는 빠른 부분을 더 빠르게 만들었다. 그리고 느린 부분을 더 느리게 만들었다.” 코드를 쓰는 것은 빠르지만, 그 코드를 이해하고 디버깅하고 수정하는 것은 더 어려워졌다. AX팀이 만들어 납품한 에이전트에도 똑같은 논리가 적용된다.

MIT Sloan Management Review와 Accenture가 19개 산업, 1,500개 글로벌 기업을 분석한 연구에서도 “변화에 잘 대응하는 기업들은 재발명 준비가 된 ‘디지털 코어’를 가지고 있다”고 밝혔다. 그 핵심 요소 중 하나는 IT 예산의 약 15%를 기술부채 해소에 할당하는 것이다. AX팀이 계속 새것을 만들기만 하고 유지보수 구조를 설계하지 않으면, 조직은 결국 아무도 관리하지 않는 에이전트 무덤을 갖게 된다.

기술부채의 아이러니는 여기서 끝나지 않는다. 좋은 코드베이스일수록 AI가 더 많은 가치를 만들어 낸다. 엉킨 코드베이스일수록 AI가 더 많은 손상을 가한다. 마찬가지로, 현업이 자신의 워크플로우를 잘 이해하고 관리하는 조직일수록 AI 도구가 더 큰 가치를 낸다. AX팀이 현업 몰래, 현업 대신 만든 솔루션은 이 이해도를 높이는 것이 아니라 낮춘다.

명제 8: AX팀이 만들어서 떠먹이면 결국 중앙 의존성만 키우고 확산을 막는다

이 명제는 조직설계의 관점에서 매우 중요한 경고다. “떠먹이는” 방식이 왜 문제가 되는지를 이해하려면, 조직에서 지식과 역량이 어떻게 형성되는지를 알아야 한다.

사람은 자신이 직접 만든 것을 통해 배운다. 반제품을 받아 사용하는 과정에서는 그 제품이 작동하는 원리나 그것이 풀려는 문제의 구조를 깊이 이해하기 어렵다. AX팀이 에이전트를 만들어 현업에 건네주면, 현업은 그 에이전트의 ‘사용자’가 된다. 사용자는 에이전트가 잘 작동할 때 쓰고, 잘 작동하지 않을 때 불평하고, 결국 포기한다. 그리고 다시 AX팀에 새로운 것을 요청한다. 이것이 중앙 의존성이다.

중앙 의존성의 악순환 구조는 다음과 같다. AX팀이 만든다 → 현업이 사용한다 → 문제가 생긴다 → 현업이 AX팀에 요청한다 → AX팀이 수정하거나 새것을 만든다 → 현업은 더욱 AX팀에 의존한다. 이 사이클에서 현업의 AI 역량은 전혀 성장하지 않는다. 오히려 “AI는 어렵고, 우리는 못 한다. 전문가가 해줘야 한다”는 인식이 강화된다.

이것이 확산을 막는다. 확산은 성공 경험을 가진 사람이 동료에게 그 경험을 나눌 때 일어난다. 그런데 ‘사용자’로서의 경험은 전파 가능한 성공 경험이 되기 어렵다. “AI팀이 만들어 줬더니 잘 됐어”라는 말은 동료의 자발적 시도를 유도하지 못한다. “내가 직접 AI로 이걸 해봤더니 이렇게 됐어”라는 경험이 확산을 만든다.

Forrester의 2025년 개발자 서베이는 기업들이 ‘시티즌 디벨로퍼(citizen developer)’ 전략을 얼마나 심각하게 받아들이고 있는지 보여준다. 개발 임원의 89%가 자사가 시티즌 디벨로퍼 전략을 현재 실행 중이거나 적극적으로 계획 중이라고 답했다. 이 전략의 본질은 도메인 전문가가 스스로 도구를 만들게 하는 것이다. “이것이 AI 비즈니스 가치를 실세계에서 발견하고 스케일링하는 가장 실용적인 전략”이라는 것이 Forrester의 결론이다.

명제 9: 100%를 AX팀이 해결하는 것보다 80%를 도메인 전문가가 직접 AI로 해결하는 게 훨씬 강하다

이 명제는 완성도와 지속가능성 사이의 트레이드오프를 다룬다. 직관적으로 생각하면 더 정교하게 만들어진 솔루션이 낫다고 생각할 수 있다. 그러나 조직의 관점에서 보면, 80점짜리 솔루션을 현업이 스스로 갖고 있는 것이 100점짜리를 AX팀에 의존하는 것보다 훨씬 강력하다. 이유는 세 가지다.

첫째는 적응력이다. 도메인 전문가가 만든 80점짜리 솔루션은 그 전문가 본인이 고칠 수 있다. 비즈니스 상황이 바뀌면 즉시 수정할 수 있다. AX팀이 만든 100점짜리 솔루션은 AX팀이 없으면 변경할 수 없다. 완성도가 높을수록 내부 구조가 복잡해지고, 그 복잡성은 유지보수 의존성을 더욱 높인다.

둘째는 확산력이다. 도메인 전문가가 자신의 문제를 스스로 80%까지 AI로 해결했다는 경험은 동료들에게 전파된다. “나도 할 수 있다”는 자기효능감을 심어준다. 반면 AX팀의 100점짜리는 “전문가들이나 할 수 있는 것”으로 인식된다. 이 인식 차이가 조직 전체의 AI 내재화 속도를 결정한다.

셋째는 맥락 적합성이다. 도메인 전문가는 자신의 업무 맥락을 가장 잘 안다. 그 맥락 안에서 만들어진 80점짜리 솔루션은 실제 사용성 측면에서 맥락을 모르는 팀이 만든 100점짜리보다 높은 점수를 받는 경우가 많다. 기술적 완성도가 실용적 유용성과 항상 일치하지는 않는다.

Citizen Developer 프레임에서 이 논리는 반복적으로 검증된다. “도메인 전문가들이 프로토타입을 직접 만들 때, 신선한 솔루션들이 더 빠르게 나오고 실험이 일상화된다”는 것이 시장에서 반복 확인된 사실이다. Gartner는 2026년까지 대형 기업의 75%가 앱 개발에 로우코드 도구를 사용하게 될 것이며, 그 상당 부분이 IT 외부 인력에 의해 만들어질 것이라고 예측했다.

‘80% 법칙’은 여기서 더 확장된다. 도메인 전문가가 80%까지 해결하고 나면, 나머지 20%는 AX팀 혹은 IT팀이 보강하는 방식의 협업이 가장 효율적이다. 이것을 Citizen Developer 문헌에서는 ‘퓨전팀(fusion team)’이라고 부른다. IT의 보안·확장성·통합 전문성과 현업의 도메인 지식이 결합될 때, 결과물은 빠르게 만들어지고 실제 사용자 워크플로우에 정확히 맞아 들어간다.

명제 10: AX팀의 역할은 빌더가 아니라 인프라를 깔고 판을 만드는 것이다

이 명제는 AX팀이 무엇을 해야 하는지에 대한 가장 명쾌한 재정의다. ‘빌더’가 아닌 ‘인프라 레이어’로서의 AX팀은 무엇을 만드는가?

첫 번째 인프라는 플랫폼과 거버넌스다. 어떤 AI 도구들이 조직 내에서 승인되어 사용될 수 있는지, 데이터 접근 권한은 어떻게 설계되는지, 보안과 컴플라이언스 규정은 무엇인지를 정의하고 관리한다. 이것 없이는 현업이 아무리 좋은 의지로 AI를 쓰려 해도 “어디서, 무엇을, 어떻게”가 불분명해 혼란만 생긴다. 가이드라인 없이 방임하면 섀도우 AI(shadow AI) 문제가 생긴다. 기업 ChatGPT 사용의 93%가 비공식 개인 계정을 통해 이루어진다는 조사 결과는 이 인프라 부재가 낳는 현실을 보여준다.

두 번째 인프라는 학습 생태계다. AI 리터러시 교육 커리큘럼, 프롬프트 작성 가이드, 내부 사례 공유 채널, 실험 결과를 축적하고 공유하는 지식베이스가 여기에 해당한다. Gartner의 권고처럼 각 부서의 AI 챔피언을 연결하는 커뮤니티 오브 프랙티스(Community of Practice)가 이 생태계의 핵심이다. 개인의 성공 경험이 조직의 자산이 되도록 하는 인프라다.

세 번째 인프라는 실험 공간이다. 도메인 전문가들이 AI로 자신의 워크플로우를 실험할 수 있는 안전한 환경을 제공한다. 실험이 실패해도 페널티가 없고, 성공하면 공유와 확산으로 이어지는 심리적·제도적 조건을 만드는 것이다.

네 번째 인프라는 가드레일과 측정이다. 자유로운 실험을 허용하면서도 조직의 데이터 보안, 품질 기준, 규제 컴플라이언스가 지켜지도록 하는 정책과 모니터링 체계다. PwC가 권고한 대로, 에이전트가 자신의 결정과 행동을 자동으로 문서화하도록 설계하면 연속적인 모니터링이 가능해지고, 이것이 이해관계자들의 신뢰를 쌓는다.

이 네 가지 인프라를 갖춘 AX팀은 “판을 깔아준” 것이다. 이 판 위에서 도메인 전문가들이 자유롭게 AI를 써보고, 실패하고, 성공하고, 동료에게 전파하는 것이 진정한 AX다. Citizen Developer 거버넌스 모델이 권고하는 IT 부서의 역할도 정확히 이것이다. “빌더에서 인에이블러(enabler)로의 전환.” IT가 모든 것을 직접 만들던 역할에서, 현업이 안전하게 만들 수 있는 환경을 제공하는 역할로 바뀌는 것이다.

명제 11: 실제 빌더는 도메인 전문가여야 지속가능하다

이 명제는 지속가능성(sustainability)을 핵심어로 삼는다. AX에서 지속가능성이란 무엇인가? 담당자가 바뀌어도, 예산이 줄어도, AX팀이 다른 프로젝트로 이동해도, AI를 통한 업무 혁신이 계속 이루어지고 심화되는 상태다.

이 상태는 도메인 전문가가 빌더일 때만 가능하다. 왜냐하면 도메인 전문가는 그 일의 주인이기 때문이다. 마케팅팀의 캠페인 분석 자동화를 마케터가 직접 만들었다면, 그 마케터가 팀에 있는 한 그 자동화는 유지되고 개선된다. 그 마케터가 후임자에게 인수인계할 때 “이게 어떻게 작동하는지, 왜 이렇게 만들었는지”를 설명할 수 있다. 반면 AX팀이 만들어 준 자동화는 마케터가 퇴사해도, 입사해도 그것을 왜 그렇게 만들었는지 아는 사람이 없다.

더 깊은 차원에서 보면, 도메인 전문가가 빌더가 되는 과정은 단순한 도구 습득이 아니라 사고방식의 전환이다. “내 일의 어떤 부분이 반복인가? 그 반복을 AI에게 맡기면 나는 무엇을 더 잘할 수 있게 되는가?” 이 질문을 자신에게 던지고 답을 찾아가는 과정이 진짜 업스킬링이다. BCG는 이것을 “맥락적 판단, 문제 프레이밍, 결과 해석”이라는 핵심 인간 역량으로 표현한다. AI가 대체하는 역량이 아니라, AI와 함께 일하기 위해 더욱 중요해지는 역량이다.

MIT Sloan Management Review의 2026년 1월 보고서는 AI에 능숙한 현장 직원들이 앱, 모바일 애플리케이션, 자동화 워크플로우, 데이터 분석을 만드는 방식으로 기업의 디지털 변환을 이끌고 있다고 분석한다. 이들이 바로 도메인 전문가 빌더다. 기술 배경이 없어도, 자신이 매일 하는 일을 깊이 알기 때문에 진짜 문제를 풀 수 있는 솔루션을 만들어 낸다.

명제 12: 그래야 유지보수도, 개선도, 확산도 자연스럽게 일어난다

이 명제는 앞선 명제들이 현실에서 어떻게 작동하는지를 설명한다. 도메인 전문가가 빌더가 되면 세 가지가 자연스럽게 따라온다.

유지보수의 자연화: 도구의 주인이 그 도구를 매일 쓰는 사람이기 때문에, 문제가 생기면 즉시 알아차리고 즉시 수정한다. AX팀에 티켓을 올리고 우선순위 조율을 기다리는 과정이 없다. 비즈니스 로직이 바뀌면 그 로직을 가장 잘 아는 사람이 도구도 바꾼다. 이것이 진짜 애자일이다.

개선의 자연화: 사용하면서 생기는 불편, 더 잘 할 수 있겠다는 아이디어가 즉시 개선으로 이어진다. 도메인 전문가는 그 도구로 해결하려는 문제를 가장 깊이 알기 때문에, 지속적인 개선의 방향도 가장 잘 판단할 수 있다. 외부 팀에게 요청해서 기다리는 대신, 본인이 직접 개선한다.

확산의 자연화: 앞서 설명한 것처럼, “내가 직접 해봤더니 이렇게 됐다”는 경험은 전파된다. 성공 경험을 가진 도메인 전문가가 동료들에게 “이렇게 하면 돼”라고 가르쳐 주는 것이 가장 강력한 확산 메커니즘이다. Citizen Developer 사례 연구에서 반복되는 패턴이 바로 이것이다. 풀뿌리 운동처럼 시작된 개인의 실험이 동료에게 전파되고, 그것이 팀의 표준이 되고, 다시 조직 전체로 번진다.

이 세 가지가 자연스럽게 일어나는 조직은 AX팀의 추가 투입 없이도 AI 내재화 깊이가 계속 심화된다. 반면 AX팀이 모든 것을 만들어 납품하는 방식에서는, AX팀이 떠나는 순간 모든 것이 멈춘다. 전자가 진정한 AX이고 후자는 AI 프로젝트다.

ServiceNow의 경험도 이를 뒷받침한다. “예산이 빠듯해도 새 앱과 자동화에 대한 수요는 줄지 않는다. IT 백로그를 줄이고, 디지털 트랜스포메이션을 가속화하며, 앱 갭을 해소하는 것은 시티즌 디벨로퍼의 힘을 빌릴 때 가능하다”는 것이 시장에서 검증된 결론이다.

명제 13: 결국 AX의 본질은 ‘만들어주는 조직’이 아니라 ‘스스로 만들게 하는 조직’이다

이 최종 명제는 1부의 결론(“누가 바뀔 준비가 되어 있는가”)과 2부의 결론이 하나로 수렴되는 지점이다. 그리고 동시에 전통적인 IT 조직, 컨설팅 펌, DX팀이 오래된 관성으로 반복하는 실수에 대한 가장 명확한 반론이기도 하다.

‘만들어주는 조직’의 논리는 이렇다. “우리는 전문가다. 현업은 기술을 모른다. 우리가 만들어 주면 된다.” 이것은 단기적으로 성과처럼 보인다. 에이전트가 완성되고, 데모가 인상적이고, 경영진이 박수를 친다. 그러나 6개월 후, 1년 후를 보면 현업의 AI 역량은 그대로고, 의존성만 높아져 있고, 에이전트들은 방치되거나 업데이트가 밀려 있다.

‘스스로 만들게 하는 조직’의 논리는 다르다. 단기적으로는 더 느리다. 현업이 처음에는 어색하게 AI를 써보고, 실수도 하고, 성과도 불완전하다. 그러나 이 과정을 통해 조직 안에 실질적인 역량이 축적된다. 6개월 후, 1년 후에는 조직 전체가 AI를 자신의 도구처럼 다루고 있다. 이것이 진정한 복리(compound interest)다.

이 구분은 교육학에서 오래된 구분이기도 하다. “물고기를 잡아주는 것”과 “물고기 잡는 법을 가르치는 것”의 차이. AX의 맥락에서 이것은 더욱 중요하다. AI는 계속 진화한다. 오늘 AX팀이 만들어 준 에이전트는 내년에는 구식이 될 수 있다. 그러나 도메인 전문가가 “내 문제를 AI로 풀 수 있다, 내가 직접 할 수 있다”는 역량과 자신감을 가지게 되면, 새로운 AI 도구가 나와도 스스로 적응하고 활용할 수 있다. 이것이 지속가능한 조직 역량이다.

IMD의 교수들이 2026년 AI 트렌드를 전망하면서 반복적으로 사용하는 표현이 있다. “가장 성공적인 리더들은 AI를 이용해 인간이 고유한 가치를 발휘하는 방법에 집중할 것”이라는 것이다. AX팀이 ‘스스로 만들게 하는 조직’이 될 때, 도메인 전문가들은 루틴에서 해방되어 자신만이 할 수 있는 고유한 가치에 집중하게 된다. 이것이 AX가 궁극적으로 만들어내야 하는 상태다.

결론: 두 가지 질문이 하나로 수렴하다

이 13개의 명제를 관통하는 두 가지 핵심 질문이 있다. 1부의 결론 질문인 “누가 바뀔 준비가 되어 있는가”와 2부의 결론 질문인 “우리는 만들어주는 조직인가, 스스로 만들게 하는 조직인가”다. 이 두 질문은 서로 다른 것처럼 보이지만 실제로는 같은 진실의 두 면을 가리킨다.

사람이 바뀔 준비가 되어 있으려면, 스스로 만들어볼 수 있는 환경이 있어야 한다. 스스로 만들게 하는 조직이 되려면, 바뀔 준비가 된 사람들을 먼저 찾고 그들을 씨앗으로 삼아야 한다. 이 두 조건이 서로를 강화하는 선순환 구조를 만드는 것이 AX팀 리딩의 핵심이다.

변화의 의지(Willingness), 변화의 역량(Capability), 변화의 기회(Opportunity). 이 세 가지가 갖추어진 사람들이 조직 안에서 ‘스스로 만드는 경험’을 하게 되면, 그 경험이 확산 벡터가 된다. 그 벡터들이 연결된 네트워크가 바로 진정한 AX가 이루어진 조직의 모습이다.

가장 정교한 에이전트도 그것을 받아들이고 발전시킬 사람 없이는 의미가 없다. AX의 ROI는 기술 스택이 아니라, 조직 안에서 “나도 할 수 있다”는 경험을 가진 사람의 수에서 나온다.

부록: 관련 데이터 요약

출처	핵심 데이터	관련 명제
BCG (2026)	AI에서 실질적 재무 성과를 낸 기업 5%	1, 2
BCG (2026)	AI 가치의 70%는 인적 임파워에서 발생	1, 9
McKinsey (2025)	88%가 AI 사용, 그러나 스케일링 기업은 1/3	2
MIT NANDA (2025)	기업 AI 파일럿 95% 실패	2, 7
Gartner (2026)	CHRO의 78%: 워크플로우와 역할 변화 필요 동의	3
Gartner (2026)	2026년까지 대형 기업 75%가 앱 개발에 로우코드 사용	9, 11
WEF (2026)	2030년까지 9,200만 개 일자리 소멸, 1억 7,000만 개 창출	1
Deloitte (2025)	인력 개발 투자 기업, 더 나은 재무 성과 확률 1.8배	3, 11
Forrester (2025)	개발 임원 89%: 시티즌 디벨로퍼 전략 실행 중 또는 계획 중	8, 9, 11
MIT Sloan / Accenture (2025)	변화 대응 기업은 IT 예산의 15%를 기술부채 해소에 할당	7
DEV Community (2026)	AI 코딩 도구가 신규 코드의 41% 작성, 그러나 부채 가속화	7
PwC (2026)	기술은 가치의 20%, 나머지 80%는 일하는 방식 재설계	1, 9
Axios (2026)	AI 도입 속도는 결국 인간과 조직의 적응 능력에 의해 제한	13

출처: BCG Build for the Future x AI 2025 Global Study, McKinsey State of AI 2025, Gartner CHRO Survey Dec 2025 / Enterprise Low-Code Platforms, WEF Future of Jobs Report 2025, MIT NANDA State of AI in Business 2025, Deloitte Human Capital Trends 2025, PwC 2026 AI Business Predictions, Forrester Developer Survey 2025, MIT Sloan Management Review / Accenture 2025, DEV Community AI Technical Debt Analysis 2026, Axios AI 2026 Trends, ServiceNow Workflow 2026

AI, Material

AI ai-transformation AX human-workflow-transformation technical-debt citizen-developer Claude.write