
이 그림을 보신 적 있으신가요. 요구사항 수집의 어려움을 묘사한 아주 유명한 그림이죠.
이 그림은 나무에 그네를 매다는 프로젝트를 표현하고 있습니다.
고객이 설명한 요건, 프로젝트 리더의 이해, 애널리스트의 디자인, 프로그래머의 코드가 전부 다릅니다.
실제 운용은 또 다르고, 청구 금액은 롤러코스터입니다. 정작, 고객이 정말 필요했던 건 타이어 그네 하나였죠.
흔히 이 그림을 보고 요구사항 수집의 어려움에 대해 이야기합니다. 맞는 말입니다. 하지만, 저는 여기서 다른 걸 봅니다.
개발자는 열심히 코딩했고, 디자이너는 성실하게 설계했습니다. 각자 자기 영역에서는 최선을 다했습니다.
하지만 결과는 엉망입니다.
공통의 목표 없이, 각자의 영역 안에서만 움직였기 때문입니다. 사일로(silo: 부서 간 단절 구조)의 대표적인 사례죠.
Tony Cho는 “조직에 Claude Code를 설치한다고 AX가 되지 않는다“에서 도입과 전환은 다르다고 진단했습니다.
이 글에서는 이를 바탕으로 AI 도구가 조직을 바꾸지 못하는 이유(AI 사일로), 그리고 진짜 AX(AI Transformation)가 무엇인지에 대해 정리하고자 합니다.
목차
AI 도구를 깔면 위 그림이 달라질까요
많은 기업이 지금 AI 도구를 전사적으로 도입하고 있습니다.
개발팀에 Claude Code를, 마케팅팀에 ChatGPT를, CS팀에 AI 챗봇을 붙여줍니다. 생산성이 오릅니다.
각자의 일은 실제로 더 빨라집니다.
그런데 잠깐 생각해 보겠습니다.
그림 속 인물들에게 각자 더 좋은 도구를 쥐여줬다고 상상해 보세요.
프로그래머에게는 더 좋은 IDE를, 디자이너에게는 더 좋은 툴을. 그러면 결과물이 달라질까요.
아닙니다. 각자가 더 빠르게, 더 정교하게, 서로 다른 그네를 만들 뿐입니다.
AI 도구도 마찬가지입니다.
개발팀은 개발팀대로 AI를 최적화하고, 마케팅팀은 마케팅팀대로 AI를 최적화합니다. 부서 내 생산성은 올라갑니다.
하지만 부서 간 병목은 그대로입니다. 고객 요구사항이 제품에 반영되기까지의 프로세스도 그대로입니다.
AI가 새로운 사일로를 만들어내는 것은 아니다.
그러나 기존에 존재하던 사일로를 더욱 공고히 할 가능성은 충분하다.
기능 단위의 최적화가 전사적 최적화를 보장하지 않으며, 각 부서가 서로 다른 데이터와 맥락으로 판단한다면 AI는 사일로를 허무는 도구가 아니라 이를 강화하는 기술이 된다.
– AI, 조직의 사일로를 허물 것인가 더 공고히 할 것인가, 김태완 (ZDNet Korea, 2026)
기업 AI가 실패하는 이유는 모델이 아니라, 조직 내부의 복잡성과 단절이다.
AI의 성공 여부는 모델의 정교함이 아니라, 실제 업무 흐름에 얼마나 깊이 통합되느냐에 달려 있다.
AI 시대의 승자는 가장 먼저 AI를 도입한 조직이 아니라, 업무 방식을 재설계한 조직이 될 것이다.
– AI는 준비됐다…문제는 ‘사일로 조직’, 매튜 피츠패트릭 (넷제로뉴스, 2026)
McKinsey의 2025 State of AI 보고서도 같은 결론을 이야기합니다.
AI를 도입한 기업 중 전사적 스케일링에 도달한 곳은 1/3에 불과합니다. 나머지 2/3는 여전히 파일럿 단계에 머물러 있습니다.
도구는 사일로를 해결하지 않습니다. 지금 있는 구조를 더 빠르게 돌릴 뿐입니다.
과정지표의 함정
AI 도입 성과를 측정할 때 흔히 쓰는 지표들이 있습니다.
“AI 도구 사용률 80%”, “자동화된 태스크 수”, “절감된 작업 시간”. 이것들은 모두 과정지표입니다.
조직이 얼마나 열심히 움직이는지를 보여줄 뿐, 고객에게 실제 가치가 전달되는지는 알려주지 않습니다.
진짜 목표는 결과지표여야 합니다.
AI를 도입한 후에 프로젝트 리드타임이 얼마나 빨라졌는지, 시장문제가 해결되는 시간이 얼마나 짧아졌는지, End-to-End 관점의 결과를 보아야 합니다.
하지만, 이 숫자들은 사일로가 있으면 결코 줄일 수 없습니다.
부서 내에서 A도구로 최적화를 잘 했어도, 부서 간 경계에서 대기하고 협의하고 조율하는데 시간이 쌓이기 때문입니다.
개발이 빨라졌는데 출시가 안 빨라졌다면, 실제 문제는 개발이 아닙니다.
그럼 무엇이 바뀌어야 할까요
다시 앞쪽 그림으로 돌아갑니다. 이 프로젝트가 성공하려면 무엇이 필요했을까요? 더 좋은 도구가 아닙니다.
모두가 같은 그림을 보는 것. 고객이 원하는 게 무엇인지, 그걸 위해 각자가 무엇을 해야 하는지를 함께 아는 것입니다.
AX도 똑같습니다. 필요한 건 세 가지입니다.
① 문제점 찾기
AI로 해결할 곳을 찾기 전에, 지금 어디가 막혀 있는지를 먼저 봐야 합니다.
대부분 병목은 부서 내부가 아니라 부서와 부서 사이에 있습니다.
② 공통 목표 세우기
부서가 달라도 같은 숫자를 바라봐야 합니다.
과정지표는 각 부서별로 관리하면 됩니다. 부서 간에 공유해야 할 End-to-End 목표를 세워야 합니다.
③ 역할과 프로세스 재설계
이게 가장 어렵고, 가장 중요합니다.
부서별로 문제점 파악이 끝났으면, 각 도메인 전문가들이 각자 일하는 방식을 다시 짜야 합니다. 도구는 그 다음입니다.
McKinsey에 따르면,
AI 고성과 조직은 그렇지 않은 조직에 비해 워크플로우를 근본적으로 재설계하는 비율이 3배 가까이 높습니다(55% vs 20%).
도구가 아니라 구조를 먼저 바꾼 결과입니다.
Tony Cho는 AX팀 역설을 다룬 글에서 같은 결론을 냅니다.
AI 전문가 조직이 아니라, 현장의 병목을 아는 각 도메인의 전문가들이 자기 일하는 방식을 재설계해야 한다고 이야기합니다.
Top-down이 필요한 진짜 이유
AX는 Top-down으로 해야 한다는 말을 자주 듣습니다. 맞습니다. 단, 이유를 정확히 알아야 합니다.
부서 간 경계를 다시 긋고, 평가 기준을 바꾸고, 우선순위를 조정하는 일은 현장에서 아래로부터 할 수 없습니다.
조직 구조 자체를 건드려야 하는 일이기 때문에 의사결정 권한이 있는 리더십이 나서야 합니다.
단, 상명하복식으로 단순히 전 부서는 X월말까지 AX 해라고 명령만 내리면 된다는 뜻이 결코 아닙니다.
이런 접근으로는 바꿀 수가 없습니다. 결국 각자가 자기 방식대로 해석하고, 자기 영역 안에서만 움직일 테니까요.
리더십의 역할은 명령이 아니라 구조를 여는 것입니다.
공통의 목표를 제시하고, 부서 간 벽을 낮출 권한을 주고, 현장 전문가들이 스스로 재설계할 수 있는 환경을 만드는 것입니다.
큰 조직이라면 한 번에 전부 바꾸려 하지 마세요.
작은 팀 하나에서 파일럿하고, 증명하고, 그 결과를 가지고 확산하는 것이 현실적입니다.
맺음말
그림 속 고객은 타이어 그네 하나를 원했습니다.
그걸 만들지 못한 건 각자의 능력 부족이 아닙니다.
같은 목표를 보지 않고, 각자의 영역 안에서만 움직인 구조의 문제입니다.
AI 도구를 아무리 좋은 걸 깔아도, 이 구조가 바뀌지 않으면 결과는 같습니다.
더 빠르게, 더 정교하게, 서로 다른 그네를 만들 뿐입니다.
AX는 도구의 문제가 아닙니다. 구조의 문제입니다.
ChulJoo Kim (김철주).
참고
- Tony Cho, 조직에 Claude Code를 설치한다고 AX가 되지 않는다 (2026)
- Tony Cho, AX팀을 만드는 순간, 당신의 조직은 AX에 실패한다 (2026)
- 김태완, AI, 조직의 사일로를 허물 것인가 더 공고히 할 것인가, ZDNet Korea (2026)
- 매튜 피츠패트릭, AI는 준비됐다…문제는 ‘사일로 조직’, 넷제로뉴스 (2026)
- McKinsey & Company, The State of AI in 2025: Agents, Innovation, and Transformation (2025)
ckarch.kr
© 2026
is licensed under
CC BY-NC-SA 4.0