AI를 도입했다고 AX가 되는 것은 아니다 ― 『실전 AX 리포트』를 읽고
“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.”
요즘 기업의 사업계획이나 경영진 메시지에서 AI가 빠지는 경우는 거의 없다. 전담 조직을 만들고 생성형 AI 계정을 배포하며 크고 작은 PoC도 진행하지만, 막상 시간이 지나고 나면 처음의 관심만큼 업무 방식이 달라졌는지는 자신 있게 답하기 어렵다. AI를 도입했다는 사실과 구성원이 AI로 일하고 있다는 상태 사이에는 생각보다 깊은 간격이 있기 때문이다.
박주혜·오현식·공득조가 쓴 『실전 AX 리포트』는 바로 그 간격을 다룬다. 한 부서에서 시작한 AI가 52개 계열사와 3만 5천 명의 사용자에게 확산되기까지 어떤 판단을 내렸고, 무엇이 예상과 달랐으며, 실패한 뒤 무엇을 다시 설계했는지를 비교적 솔직하게 풀어낸 책이다. 성공 사례만 보기 좋게 정리한 홍보성 기록이 아니라 계정을 발급하고도 사용률이 오르지 않았던 시기, 플랫폼을 여러 차례 다시 설계한 과정, 기술보다 사람과 조직에서 더 큰 저항을 만났던 순간까지 담았다는 점에서 제목의 ‘실전’이라는 표현이 과장처럼 느껴지지 않았다.
‘AI 도입’과 ‘AI로 일하는 것’은 다르다
책이 처음부터 강조하는 것은 기술 도입을 곧바로 AX라고 부를 수 없다는 사실이다. 솔루션 계약을 체결하고 계정을 나눠 주는 일은 비교적 빠르게 끝낼 수 있지만, 사용자가 자신의 업무 안에서 AI를 반복적으로 활용하고 그 결과 업무 흐름 자체가 달라지는 데에는 훨씬 긴 시간이 필요하다. 특히 기존 IT 구축 방식처럼 요구사항을 확정하고 외주 개발을 거쳐 몇 달 뒤 완성된 결과물을 전달하는 접근으로는, 모델과 사용자 요구가 빠르게 바뀌는 AI 환경을 따라가기 어렵다는 지적이 현실적으로 다가왔다.
클라우드 전환이나 플랫폼 구축 프로젝트에서도 비슷한 장면을 자주 본다. 기술적으로는 정상 동작하고 검수 기준도 통과했지만, 현장 사용자가 기존 방식을 버릴 만큼 편리하지 않거나 운영 조직이 변화 속도를 감당하지 못하면 서비스는 좀처럼 자리를 잡지 못한다. AX도 마찬가지다. 모델의 성능만으로는 부족하며, 사용자가 접근하는 화면과 업무 시스템의 연동, 데이터와 권한, 비용 통제, 교육과 변화 관리가 함께 움직여야 비로소 조직의 일하는 방식이 달라진다.
PoC 지옥을 만드는 네 개의 벽
가장 공감하며 읽은 대목은 ‘PoC 지옥’에 관한 설명이었다. 파일럿에서는 정확도도 괜찮았고 시연도 성공했는데 전사 확산을 결정하는 순간부터 전혀 다른 문제가 등장한다. 책은 그 원인을 규모, 비용, 조직 저항, 기존 시스템 연동이라는 네 가지 벽으로 정리한다.
소수 사용자와 제한된 문서로 검증한 RAG가 수천 명의 사용자와 수만 건의 문서를 만났을 때 같은 품질을 보장하리라는 법은 없다. 이용량이 늘면 응답 속도와 비용 구조도 달라지고, 기존 그룹웨어나 ERP·CRM 같은 기간계 시스템과 연결하지 못하면 사용자는 AI를 쓰기 위해 업무 흐름을 벗어나야 한다. 여기에 자신의 일하는 방식이 부정당한다고 느끼는 현업의 불안과 학습 부담까지 겹치면, 기술적으로 성공한 PoC가 실제 사업 성과로 이어지지 못하는 상황이 만들어진다.
이 진단이 중요한 이유는 문제의 책임을 모델 하나에 돌리지 않게 해 주기 때문이다. 정확도가 기대보다 낮으면 모델을 바꾸고, 사용률이 낮으면 교육을 더 하면 된다는 식으로 대응하기 쉽지만 실제 원인은 비용 모델이나 접근 동선, 운영 체계, 조직의 수용성에 있을 수 있다. 따라서 PoC는 단순히 ‘되는지’를 보여 주는 행사가 아니라, 전사 확산 시의 사용자 수와 데이터 규모, 비용과 보안, 운영 인력과 시스템 연동까지 미리 검증하는 단계로 설계해야 한다.
체험에서 내재화로, 다시 혁신으로
책은 AX 로드맵을 체험, 내재화, 혁신의 세 단계로 설명한다. 첫 단계에서는 누구나 쉽게 AI를 사용해 보고 효용을 느끼게 하는 것이 중요하다. 두 번째 단계에서는 AI가 개인의 선택적인 도구를 넘어 부서의 실제 업무 프로세스 안으로 들어간다. 마지막 단계에 이르면 AI는 단순한 효율화 수단을 넘어 예측과 시뮬레이션, 최적화, 새로운 비즈니스 모델을 가능하게 하는 전략적 자산으로 다뤄진다.
이 구분에서 특히 눈여겨볼 부분은 많은 조직이 두 번째 단계를 건너뛰려 한다는 지적이다. 경영진은 빠르게 눈에 보이는 혁신 사례를 원하지만, 구성원이 일상 업무에서 AI를 충분히 사용하고 데이터를 쌓으며 운영 역량을 확보하지 못한 상태에서 복잡한 에이전트나 전사 서비스를 추진하면 결국 기반 없는 시스템이 된다. 화려한 시연은 가능해도 현장에 뿌리내리기는 어렵다.
개인적으로도 이 세 단계 중 가장 어렵고 중요한 구간은 내재화라고 생각한다. 체험은 행사와 계정 배포로 시작할 수 있고 혁신은 명확한 목표처럼 보이지만, 내재화는 기존 프로세스를 실제로 바꾸고 부서의 책임과 권한을 다시 조정해야 하기 때문이다. 눈에 잘 띄지 않는 이 중간 과정이 충분해야만 다음 단계의 AI 에이전트나 자동화가 일회성 프로젝트로 끝나지 않는다.
ROI는 하나의 숫자가 아니라 진단 체계다
AI 사업에서 ROI는 늘 까다로운 질문이다. 초기 단계부터 재무 성과를 명확하게 제시하라는 요구가 강해지면, 담당 조직은 장기적인 임팩트가 큰 과제보다 짧은 기간 안에 숫자를 만들기 쉬운 과제를 선택하게 된다. 반대로 ‘AI는 아직 초기이니 성과를 따질 수 없다’며 측정을 미루면 사업의 정당성과 개선 근거를 잃는다.
이 책은 두 극단 사이에서 비교적 실용적인 방법을 제안한다. 성과를 업무 시간 절감, 결과물의 품질, AI 운영 비용의 효율, 사용자 활성도라는 네 축으로 나누고, 다시 AI가 좋은 답을 내놓는지, 현장이 그 답을 실제 업무에 반영하는지, 최종적으로 사업 성과로 연결되는지를 서로 다른 층위에서 보자는 것이다. 모델의 답변 품질은 좋은데 현장에서 채택하지 않는다면 온보딩과 업무 연동을 살펴야 하고, 활용도까지 높은데 재무 성과가 약하다면 애초에 해결하려던 업무의 사업적 가치가 충분했는지를 다시 검토해야 한다.
시간 절감 수치를 곧바로 비용 절감액으로 바꾸지 말아야 한다는 설명도 현실적이다. 직원이 절약한 시간을 다른 가치 있는 업무에 사용하고, 그 변화가 실제 성과로 이어졌을 때 비로소 경제적 효과로 설명할 수 있기 때문이다. 결국 ROI는 예산을 승인받기 위한 장식용 숫자가 아니라, 문제가 모델에 있는지 운영에 있는지 과제 선정에 있는지를 구분하는 진단 도구에 가깝다.
챗봇에서 플랫폼으로, 다시 에이전트 빌더로
클라우드 아키텍트의 관점에서 가장 흥미로웠던 부분은 사내 AI 플랫폼이 1.0에서 4.0으로 진화한 과정이었다. 처음에는 빠른 출시가 중요했기 때문에 챗봇과 기본 도구 중심으로 시작했지만, 실제 사용 데이터를 확인하면서 멀티모달 기능과 업무 특화 기능, 사용자가 직접 만드는 커스텀 챗봇, 외부 연동을 위한 API가 차례로 추가됐다. 기능이 늘어난 뒤에는 여러 화면을 오가야 하는 불편이 드러났고, 이를 해결하기 위해 단일 UI와 LLM 게이트웨이, 업무별 전문 에이전트, 개인화 기능과 업무 도구를 결합한 통합 플랫폼으로 발전했다.
다음 목표인 4.0은 중앙 조직이 모든 에이전트를 직접 개발해 제공하는 구조에서 벗어나, 현업이 필요한 에이전트를 스스로 만들 수 있는 기업용 에이전트 빌더로 전환하는 것이다. 이 방향은 빠른 확산을 위해 자연스럽지만 동시에 더 정교한 거버넌스를 요구한다. 현장의 자율성을 높이면서도 데이터 접근 권한, 실행 한도, 비용, 품질 평가, 변경 이력과 감사 로그는 중앙에서 통제할 수 있어야 하기 때문이다.
MCP를 단순한 최신 기술 용어로 소개하는 데 그치지 않고 도구 연동의 표준화, 인증과 권한, 로깅, 실행 제한으로 이어서 설명한 점도 좋았다. 다만 실제 공공·금융 환경에 적용하려면 망 분리와 데이터 등급, 모델 반출입 절차, 승인 워크플로, 장애 격리와 평가 자동화까지 더 세밀한 설계가 필요하다. 책이 전체 구조와 판단 기준을 보여 준다면, 실제 구현 단계의 보안 통제와 운영 설계는 각 조직이 별도로 구체화해야 할 영역이다.
1개 계열사에서 52개 계열사로 확산한다는 것
전사 확산을 한 번의 대규모 오픈으로 생각하지 않는다는 점도 기억에 남는다. 한 부서에서 사용자의 질문과 반응, 운영 이슈를 가까이 관찰하고, 이후 계열사 단위와 여러 계열사 단위로 범위를 넓히면서 매 단계마다 플랫폼이 다음 규모의 부담을 감당할 수 있는지 확인한다. 준비가 빠른 조직부터 먼저 참여시키고 보안이나 데이터 정리에 시간이 필요한 조직은 다음 차수로 넘기는 방식이 모두를 동시에 끌고 가는 것보다 결과적으로 빠르다는 설명은, 대규모 클라우드 전환에서도 그대로 통하는 원칙이다.
52개 계열사로 확장되는 단계에서는 기술보다 변화 관리와 교육, AI 챔피언 같은 조직 요소가 더 큰 병목이 된다. 인프라도 사람이 수동으로 모든 문제를 처리하는 방식에서 벗어나 사용량 증가에 자동 대응하고, 모니터링과 알림, 장애 복구가 기본으로 작동해야 한다. 현재 사용자의 만족도와 활성화 지표, 운영 이슈의 통제 가능성, 다음 사용자를 감당할 인프라, 보안·법무 검토, 온보딩 준비가 모두 갖춰졌는지 확인한 뒤 다음 단계로 넘어가라는 체크리스트는 실무에서 바로 참고할 만하다.
사용자 온보딩에 관한 내용도 단순하지만 설득력이 있다. 가입자가 실제 사용자로 남으려면 첫 5분 안에 자신의 업무에 도움이 되는 결과를 한 번이라도 경험해야 하며, 이를 위해 빈 입력창을 보여 주기보다 직무별 추천 시나리오와 어느 정도 완성된 프롬프트를 먼저 제공한다. 교육을 마친 뒤 체험하게 하는 대신, 먼저 결과를 경험하게 한 다음 교육으로 연결했을 때 이해와 적용 의지가 높아졌다는 대목도 현실적이다. 사용자를 별도의 AI 사이트로 불러들이는 대신 메일이나 협업 도구, 그룹웨어처럼 원래 일하던 화면에서 AI를 호출하게 해야 한다는 결론 역시 결국 좋은 기술보다 마찰이 적은 경험이 사용을 만든다는 사실을 보여 준다.
중앙 통제와 현장 자율성 사이에서
AX 조직을 CoE로 집중할 것인지 사업부에 분산할 것인지에 대한 논의도 실제 조직 설계에 도움이 된다. CoE는 플랫폼과 표준, 보안과 거버넌스 같은 공통 자산을 일관되게 관리하기 좋지만 사업의 세부 맥락과 현장의 변화를 모두 따라가기 어렵다. 반대로 인력을 각 사업부에 완전히 분산하면 도메인 이해와 실행 속도는 높아지지만 모델, 인프라, 데이터 정책이 제각각 만들어져 중복 투자와 통제 문제로 이어질 수 있다.
책이 제안하는 방향은 두 구조를 결합한 하이브리드 모델이다. 중앙 CoE는 AI 플랫폼과 공통 표준, 거버넌스를 담당하고 각 사업부의 AI 챔피언은 현장의 도메인 문제와 변화 관리를 맡는다. 중요한 것은 두 조직의 권한 경계를 처음부터 분명하게 정하는 일이다. 중앙이 어디까지 표준화하고 현장이 어느 범위까지 자율적으로 만들 수 있는지가 모호하면, 협업 구조가 오히려 책임 공방의 원인이 될 수 있다.
이 부분은 공공과 금융 프로젝트에서도 특히 중요하다. 중앙 조직이 보안과 표준을 이유로 모든 결정을 쥐면 현장의 요구가 늦게 반영되고, 개별 사업이 속도만 앞세우면 기관 전체의 아키텍처와 운영 기준이 흔들린다. 공통 기반은 강하게 관리하되 업무 문제를 정의하고 작은 실험을 반복하는 권한은 현장 가까이에 두는 방식이 현실적인 균형점에 가깝다.
실무자의 관점에서 본 장점과 아쉬움
이 책의 가장 큰 장점은 전략, 아키텍처, 확산, 조직과 문화를 서로 떨어진 주제로 다루지 않는다는 데 있다. AI 플랫폼이 잘 만들어져도 사용자가 돌아오지 않으면 실패하고, 사용률이 높아도 비용 구조를 감당하지 못하면 지속할 수 없으며, 현장의 요구를 빠르게 반영해도 공통 거버넌스가 없으면 전사 자산으로 남기 어렵다는 연결 관계를 한 흐름 안에서 보여 준다. 무엇보다 결과를 자랑하기보다 왜 그런 결정을 내렸고 이전 방식의 어떤 한계가 다음 설계를 만들었는지를 설명하기 때문에, 독자는 특정 회사의 사례를 그대로 복제하기보다 자신의 조직에 맞게 질문을 바꿔 볼 수 있다.
아쉬운 점도 있다. 다루는 범위가 넓은 만큼 인프라 구성, 모델 평가, 보안 통제, 데이터 파이프라인 같은 개별 기술을 깊이 구현하려는 독자에게는 설명이 다소 빠르게 느껴질 수 있다. 또한 대기업 그룹의 인력과 예산, 계열사 구조를 바탕으로 한 경험이므로 중견기업이나 공공기관에 그대로 적용하기는 어렵다. 특히 공공·금융 분야는 조달과 망 구조, 개인정보와 중요정보 처리, 감사와 책임성, 레거시 연동의 제약이 더 강하므로 이 책의 로드맵을 조직 상황에 맞게 축소하거나 순서를 조정해야 한다.
그럼에도 불구하고 이러한 한계가 책의 가치를 크게 떨어뜨리지는 않는다. 이 책은 코드를 따라 치는 기술서라기보다 AX를 추진할 때 무엇을 함께 보아야 하는지를 보여 주는 현장형 가이드에 가깝기 때문이다. 경영진을 설득해야 하는 실무자, 사내 AI 플랫폼을 설계하는 아키텍트와 엔지니어, AI를 실제 사용자 가치로 옮겨야 하는 PM, 도입 후 사용률이 오르지 않아 고민하는 변화 관리 담당자라면 각자의 위치에서 참고할 부분을 찾을 수 있다.
AX는 완성되는 프로젝트가 아니라 계속 움직이는 체계다
마지막까지 읽고 남은 생각은 AX에 명확한 종착점이 없다는 것이다. 모델과 도구는 빠르게 바뀌고, 구성원의 활용 방식과 회사의 사업 환경도 계속 달라진다. 따라서 한 번의 대규모 구축으로 전환을 끝내려 하기보다 사용자 반응과 운영 데이터, 성공과 실패의 사례, 외부 환경의 변화를 다음 의사결정으로 돌려보내는 피드백 루프가 필요하다.
결국 지속 가능한 AX는 몇몇 뛰어난 담당자의 의지에 기대지 않는다. 작은 실험이 반복되고, 실패가 공유되며, 좋은 결과물이 다시 활용되고, 그 기여가 평가와 보상으로 연결되는 구조를 만들어야 한다. 그렇게 해야 담당자가 바뀌거나 새로운 기술이 등장해도 조직이 방향을 다시 그릴 수 있다.
『실전 AX 리포트』는 AX의 정답을 제시하는 책이라기보다, 정답을 찾아가는 동안 무엇을 질문하고 어떤 기준으로 판단해야 하는지 보여 주는 기록이다. AI를 도입했지만 다음 단계가 보이지 않는 조직, PoC를 반복하면서도 전사 확산의 길을 찾지 못한 실무자라면 이 책에서 최소한 한두 걸음 앞서 출발할 수 있는 현실적인 힌트를 얻을 수 있을 것이다.
이런 분께 권합니다
- AI 도입 이후 실제 업무 활용과 전사 확산을 고민하는 경영진과 실무 책임자
- 사내 AI 플랫폼과 에이전트 아키텍처를 설계하는 엔지니어·아키텍트
- PoC는 성공했지만 운영·비용·조직 문제로 확장하지 못한 프로젝트 담당자\
- 공공·금융·대기업 환경에서 AI 거버넌스와 변화 관리를 함께 검토하는 분