조직에 Claude Code를 설치한다고 AX가 되지 않는다

1. 들어가며 — 반가움과 불편함 사이

링크드인에 한 스타트업이 전사에 Claude Code를 도입했다는 포스팅이 올라왔다. OpenClaw를 전사 도입해서 생산성이 폭발적으로 올랐다고 주장하는 글도 보았다. 국내의 보수적인 조직문화 — 스타트업조차도 — 를 고려하면 이런 시도는 칭찬받을 만하다.

솔직히 나도 처음엔 “이거 대단한데?”라고 생각했다. 나 역시 AI 도구를 팀에 붙여보고, MCP를 연결해보고, 생산성이 올라가는 걸 체감한 사람이다. 근데 뭔가 이상했다. 도구는 분명 좋아졌는데, 조직이 일하는 방식 자체가 바뀌었다는 느낌은 없었다.

이것이 진정한 조직 레벨의 AX — AI Transformation, AI를 전제로 조직 전체를 재설계하는 것 — 일까? 조직이 AI를 제대로 도입했다고 볼 수 있을까?

Claude Code 이전에 Notion도 있었다. 구글 드라이브도 있었고, Slack도 있었다. 본질적으로 생각해보자. 지난 10여 년간 조직들이 이런 툴들을 도입하면서 정말 이전과 다른 폭발적인 생산성 향상이 있었나? 그 생산성 향상이 정말로 성과(Outcome)로 이어졌나? 과연 도구만을 도입해서 그러한 성과를 만들어낸 사례가 있는가?

지금까지 AI 네이티브 엔지니어에 대한 이런저런 이야기를 해왔는데, 이번에는 AI 네이티브 조직은 어떻게 만들어져야 하는가를 이야기하려 한다. LLM 성능의 급격한 발전으로 우리가 직접 체감하는 것과, 조직 레벨의 성과 사이에 얼마나 큰 갭이 있는가.

이 갭을 정리하려면 먼저 용어를 나눠야 한다. 이 구분이 중요한 이유는, 같은 단어 “AI 도입”을 쓰면서 전혀 다른 수준의 변화를 이야기하는 사람들이 너무 많기 때문이다. 나는 AI와 조직의 관계를 세 단계로 본다.

1단계. AI 사용 — 개인이 ChatGPT, Claude, Copilot을 업무에 쓰는 상태. 대부분의 직장인이 여기에 있다. 아직 도구를 고르고 있거나, 프롬프트를 다듬고 있거나, “이거 꽤 편한데?” 하고 놀라는 단계다.

2단계. AI 도입(Enablement) — 회사가 설치 가이드를 만들고, 교육 세션을 열고, 접근권을 제공하는 상태. 최근 화제가 된 사례들은 대부분 여기에 있다. MCP를 배포하고, 비개발자까지 사용법을 가르치고, 직무별 워크플로우를 시연한다. 충분히 가치 있는 일이다.

3단계. AX 전환 — 역할, 승인 체계, KPI, 파이프라인, 거버넌스, 책임 구조가 AI를 전제로 다시 설계된 상태. 여기까지 간 조직은 거의 없다. Bain은 “GenAI를 툴처럼 다루는 접근은 작동하지 않는다”고 말하고, McKinsey는 “AI 성숙 단계 조직은 1%에 불과하며, 가장 큰 장애물은 리더십”이라고 정리한다.

이 글은 2단계를 3단계로 착각하는 현상에 대한 글이다. 도입과 전환의 차이를 말하고, 그 차이 속에서 조직과 개인 — 특히 Maker(산출하는 사람)와 Closer(성과를 완결하는 사람) — 의 역할이 어떻게 달라져야 하는지를 이야기하려는 글이다.

2. 좋은 도입과 좋은 전환은 다르다

먼저 공정하게 읽자. 최근 화제가 된 국내 사례들이 실제로 잘한 것은 명확하다.

그 회사는 설치 장벽부터 제거했다. OS별 가이드를 만들고, MCP를 배포하고, 전사 세션을 열었다. 비개발자 동료가 직접 시연하게 해서 “나도 할 수 있겠다”는 인식을 만들었다고 한다. BX, HR, PM, 재무, CX, 사업개발 — 직무별로 실제 워크플로우가 만들어졌고, 사내 설문조사에서 응답자 전원이 “거의 매일 사용한다”고 답했다.

이건 대부분의 국내 기업이 아직 못 하는 일이다. 충분히 가치 있다.

해외에서도 좋은 도입 사례는 많다. Morgan Stanley는 재무상담사 워크플로우에 AI를 박아 넣어 회의 노트 → 요약 → 메일 초안 → Salesforce 저장까지 연결했고, 어드바이저 팀의 대다수가 채택했다. 인상적이다. 하지만 Morgan Stanley 스스로도 “인간적 관계가 여전히 핵심”이라고 말하듯, 재무상담사의 역할 자체가 바뀐 건 아니다. 도구가 더 좋아진 것이다.

그런데 여기서 한 발 더 나아가 질문을 해야 한다. 이 변화의 단위는 무엇인가?

PM은 더 빨라진 PM이 되었다. 재무는 더 빨라진 재무가 되었다. HR은 더 빨라진 HR이 되었다. 각자의 직무 안에서 AI가 작업을 가속해준 것이다. 하지만 PM과 재무와 HR 사이의 관계는 바뀌었는가? 승인 체계는? KPI는? 의사결정 흐름은?

레딧에서 본 댓글이 이걸 정확히 짚는다. “AI made the ‘typing’ part instant, but it didn’t solve the organizational friction. So the business sees the same velocity, even if the devs feel like wizards.” — AI가 ‘타이핑’은 즉각적으로 만들었지만, 조직적 마찰은 해결하지 못했다. 비즈니스는 같은 속도를 보는데, 개발자만 마법사가 된 기분이다.

사실 7~8년 전에도 비슷한 풍경이 있었다. Notion을 도입하면 조직의 지식이 흐를 거라고 기대했다. Slack을 도입하면 소통이 빨라질 거라고 믿었다. 결과는? Notion은 부서별 위키가 되었고, Slack은 부서별 채널이 되었다. 도구는 바뀌었지만 정보가 흐르는 구조는 바뀌지 않았다. 지금 AI 도구 도입에서도 같은 패턴이 반복되고 있다.

도구를 잘 깔아주는 것과, 조직이 그 도구를 전제로 다시 설계되는 것은 다른 차원의 일이다. “그래도 시작이 중요하지 않나?” — 맞다. 부정하지 않는다. 다만, 시작점을 목적지로 오해하면 안 된다.

당신의 조직에서 AI를 도입한 후, PM과 개발자 사이의 핸드오프 횟수가 줄었는가? 승인에 걸리는 시간이 줄었는가? 고객에게 가치가 전달되는 속도가 빨라졌는가? 이 질문에 “아니오”라면, 그건 아직 도입이지 전환이 아니다.

물론, 실제로 잘하고 있는 팀도 있다. 한 10년차 엔지니어링 매니저는 팀 전체가 Claude Code를 도입한 경험을 이렇게 정리했다. 단일 에이전트 환경으로 통일하고, 기존 Confluence 런북을 AI 스킬로 변환했다. 코드베이스와 아키텍처 문서를 AI 컨텍스트로 정비하고, 티켓 생성을 자동화하면서 누락 요구사항을 사전에 잡아냈다. 회의록을 AI로 검증해서 논의가 삼천포로 빠지면 즉시 교정했고, 주간 “AI 워크플로우 공유” 미팅까지 새로 만들었다.

여기서 주목할 건, 이 팀이 도구만 깔지 않았다는 점이다. 회의 구조, 티켓 프로세스, 문서 체계, 주간 미팅 — 일하는 방식 자체를 바꿨다. 한 유럽의 소규모 사업자도 비슷한 말을 했다. “가장 큰 전환은 도구 자체가 아니라 일상 워크플로우의 재설계였다. 기존 프로세스 위에 AI를 얹으면 미미한 이득뿐이다.”

잘 된 곳을 들여다보면 패턴이 보인다. 도구를 잘 깔아서 성공한 게 아니라, 일하는 방식 자체를 바꿔서 성공한 것이다. 하지만 이건 한 팀의 이야기다. 팀 단위의 전환은 가능하다. 조직 전체의 전환은 리더십이 구조를 다시 짜야만 일어난다.

3. 왜 기존 기능 조직은 AI를 흡수하면서도 그대로 남는가

기존 기능 조직의 문제는 AI를 못 쓰는 데 있지 않다. 오히려 너무 잘 흡수해버리는 데 있다. 마케팅은 마케팅 안에서, 재무는 재무 안에서, 개발은 개발 안에서 AI를 붙여 더 빨라질 수 있다. 하지만 AX가 필요한 곳은 부서 안이 아니라 부서 사이다. 직무 안이 아니라 가치 흐름 전체다.

AI는 사일로를 깨는 게 아니라 강화한다

사람들은 AI가 부서 간 벽을 허물 거라고 기대한다. 현실은 반대로 갈 수 있다. 각 부서가 자기 업무 안에서만 AI를 최적화하면, 마케팅은 마케팅용 AI를, 고객지원은 고객지원용 AI를 따로 고도화하게 된다. 조직 전체 성과는 좋아지지 않은 채 부서별 AI 섬만 생긴다. HBR은 AI가 오히려 기능 사일로를 강화하는 경우가 많다고 지적한다.

AI를 기능 조직에 얹으면, 기능 조직이 사라지는 게 아니라 더 빠른 기능 조직이 된다. 이건 고속 사일로화, 단어 그대로 부서 이기주의를 가속화할 뿐이다. 이건 AX가 아니다.

병목은 부서 안이 아니라 부서 사이에 있다

내가 CTO로 있을 때 겪은 일이다.

타 부서에서 실제 KPI에 기여할 프로젝트 기획서를 보내왔다. 그런데 R&D 본부에 들어왔을 때 우리 쪽 우선순위에 밀려 몇 주가 흘렀다. 결국 그 부서들은 CEO를 통해 협조를 “요청”이 아닌 “통보”로 내려보냈고, 진행하던 작업을 멈추고 그쪽 작업을 시작하게 되었다. 하지만 그때는 이미 프로젝트 런칭 타이밍이 크게 어긋나 있었다. 시장이 기다려주지 않았다.

같은 본부 안에서도 마찬가지였다. 리드 → PM → 디자인 → 프론트 → 백엔드 → QA로 흐르는 정보 파이프라인이 원활하지 않은 경우가 부지기수였다. 대개 기능 팀 내에서의 KPI — 예를 들어 개발자들은 각자 맡은 기능 배포 — 에 머물다 보니, 제품의 완성도나 사후 분석 같은 어쩌면 개발 단계보다 훨씬 중요한 일이 같은 제품을 만드는 사람들 사이에서조차 진행되지 않았다.

결국엔 “왜 우리가 남의 부서 일을 해야 되나요?”라는 불평이 들리기 시작했다. 나는 그 팀원을 나무랄 수가 없었다. 구조적 한계로 인해 조직원들이 그렇게 변해가는 건 그 사람의 잘못이 아니었다.

그 이후로 조직은 지지부진하게 흘러갔다. 각자의 책임 돌리기에 급급해졌고, 조직 자체가 주도성을 잃었다. 능력 있는 개인들도 빛을 잃어갔다. 리더십에서는 갈수록 수동적인 조직원들에게 불만이 생겼고, 수동적 목표만을 바라보는 조직원들은 조직에 대한 불신과 실망만 커져갔다. 어쩌면 기능 조직의 단점을 극대화한 사례였지만, 리더 입장에서 능력 있고 주도적이었던 팀원들이 그렇게 수동적으로 변하는 경험은 썩 유쾌한 경험이 아니었다.

(승리하지 못하는 조직은 어떻게 무너지는가에서 이 이야기를 더 자세히 다뤘다.)

문제는 “누가 더 빨리 일하느냐”보다 **“어떻게 일이 흘러가느냐”**다. AI가 부서 안 작업을 아무리 가속해도, 부서 사이의 승인 대기, 핸드오프, 의사결정 지연은 그대로다. 국소 생산성은 올라가도, 조직 전체의 처리 시간은 그대로일 수 있다.

각 부서는 더 잘하게 되는데, 회사는 더 잘 이기지 않는다

기능 조직에서는 각 부서가 자기 KPI를 가진다. 마케팅은 MQL, 세일즈는 매출, 개발은 배포 속도, CS는 응답 시간. AI가 들어오면 각 부서가 자기 KPI를 더 잘 달성하는 방향으로만 움직인다. 하지만 조직 전체 성과는 부서별 효율의 합이 아니다. BCG는 보상·평가·거버넌스가 레거시 모델을 보상하면 전환이 멈춘다고 경고한다.

AI의 병목은 프롬프트가 아니라 승인 구조다. 툴은 설치할 수 있지만, 책임 구조는 설치되지 않는다.

상향식 확산만으로는 구조가 안 바뀐다

개발자는 설치 가이드를 만들고, 스킬을 공유하고, MCP를 연결하고, 사내 전도사가 될 수 있다. 하지만 개발자는 인원 정책을 바꾸지 못하고, 평가 제도를 바꾸지 못하며, 부서 간 경계를 다시 긋지 못한다.

Uber의 사례가 이걸 잘 보여준다. 개발자의 84%가 에이전트를 사용하고, PR의 11%를 에이전트가 직접 오픈한다. 수치만 보면 AX에 가까워 보인다. 하지만 동시에 AI 관련 비용은 2024년 대비 6배 증가했고, CFO 레벨에서 이것이 비즈니스 임팩트로 연결되는지는 아직 미해결 과제다. 성공 사례로 보이는 곳도 완벽하지 않다. 채택 속도도 예상보다 느렸다.

이런 체감과 실측의 간극을 보여주는 데이터도 있다. METR의 무작위 대조 실험에서 숙련된 오픈소스 개발자들에게 AI 도구를 주고 작업 시간을 측정했더니, 실제로는 19% 느려졌다. 그런데 작업이 끝난 후 개발자들은 20% 빨라졌다고 보고했다. 이게 조직 단위로 일어나면, “우리는 AI로 혁신했다”는 확신이 실측 데이터와 분리된다.

한 스타트업 대표의 경험담도 같은 맥락이다. “CTO에게 Cursor를 줬더니 1주일짜리 작업을 몇 시간에 끝냈다. 그래서 전체 팀에 줬는데, 같은 결과가 나오지 않았다.” 코드베이스의 맥락을 쥔 한 사람의 생산성과, 팀 전체의 생산성은 다른 문제다.

개발자는 AI를 회사에 퍼뜨릴 수는 있어도, 회사를 AI 기준으로 다시 짤 수는 없다.

4. 무엇이 바뀌어야 전환인가 — 사례에서 읽는 5가지 축

3장에서 기능 조직의 구조적 한계를 말했다. 그렇다면 실제로 그 한계를 넘은 회사들은 무엇을 바꿨는가? 단순히 “AI를 잘 쓴다”가 아니라, 조직의 어떤 축이 달라졌는가를 사례에서 읽어보자.

역할을 바꾼 회사 — Shopify

AX의 첫 번째 축은 역할이다. AI가 들어왔는데 모든 사람이 여전히 같은 일을 하고 있다면, 그건 도입이지 전환이 아니다.

Shopify CEO Tobi Lütke는 AI 사용을 기본 기대치로 규정했다. 새로운 인원이나 자원을 요청하려면 먼저 “왜 AI로 안 되는지” 증명해야 한다. 성과 평가와 동료 평가에도 AI 활용이 반영된다. 이건 권장이 아니라 규칙이다. 기존에 직무별 생산자였던 역할이, AI를 전제로 한 감독자·리뷰어·판단자로 재정의되기 시작한 것이다. 개발자가 아무리 AI를 전파해도 채용 기준, 평가 기준, 리소스 기준은 못 바꾸지만, CEO는 바꾼다.

당신의 조직에서 AI 도입 후, 누군가의 직무 기술서가 바뀌었는가? 바뀌지 않았다면 역할 축은 그대로인 것이다.

파이프라인을 바꾼 회사 — Uber, DBS

두 번째 축은 파이프라인 — 일이 흘러가는 경로 자체다.

앞서 3장에서 Uber의 상향식 채택 한계를 언급했는데, 흥미로운 건 Uber가 그 한계를 인식하고 플랫폼 레벨로 올라갔다는 점이다. Uber는 Claude Code 하나를 깐 게 아니다. MCP 게이트웨이, 백그라운드 에이전트 플랫폼 Minion, 스마트 PR 라우팅 Code Inbox, AI 코드 리뷰 uReview, 자동 테스트 생성 Autocover, 대규모 마이그레이션 관리 Shepherd — 4개 레이어로 구성된 에이전틱 시스템을 구축했다. 개발자 워크플로우 자체가 “단일 IDE에서 코딩”에서 “여러 에이전트를 병렬로 오케스트레이션”하는 방식으로 바뀌었다. 기존의 기능 조직 직렬 핸드오프가 인간-에이전트 혼합 파이프라인으로 전환된 것이다. 다만, 비용은 6배 증가했고 비즈니스 임팩트 연결은 여전히 과제다. 파이프라인을 바꾸는 것이 곧 성공을 보장하지는 않는다.

싱가포르 최대 은행 DBS는 여기서 한 발 더 나갔다. 9개의 운영모델 전환을 완료하고, 인간-AI 협업 워크플로우를 재구축했다. DBS는 이걸 “운영 모델 전환”이라고 불렀다. 단순히 도구를 설치한 것이 아니라, 일이 흘러가는 방식 자체를 다시 설계한 것이다.

KPI와 거버넌스를 바꾼 회사 — 그리고 바꾸지 못한 회사

세 번째와 네 번째 축은 KPI와 거버넌스다. 이 둘은 함께 움직인다. 무엇을 측정하는가(KPI)와 누가 어떤 권한을 가지는가(거버넌스)가 바뀌지 않으면, 아무리 역할과 파이프라인을 바꿔도 조직은 원래 자리로 돌아간다.

BBVA는 3,000명에서 시작해 120,000명 전사로 AI를 확장하면서 CEO 포함 250명의 임원을 직접 교육하고, 보안·법무·컴플라이언스를 시작부터 붙였다. 거버넌스를 나중에 덧대는 게 아니라, 확산 설계에 거버넌스를 내장한 것이다. Box 역시 경영진 후원자 + 기능별 오너십 + 중앙 구축팀 + AI 매니저 구조를 명시적으로 설계하며 AI 도입의 거버넌스를 처음부터 조직 구조에 녹였다. J&J는 900개 AI 활용 사례를 돌린 뒤, 10~15%가 80%의 가치를 만든다는 걸 확인하고 중앙 거버넌스에서 도메인 오너십으로 무게를 옮겼다. “많이 써보자”에서 “뭘 써야 하는지 골라야 한다”로 전환한 셈이다. 전략의 초점이 “사용량”에서 “임팩트”로 바뀐 순간이었다.

Moderna는 스스로 “실시간 AI 조직”으로 규정하며 65% 실사용률을 달성했다. 주목할 점은 사업이 커질수록 사람을 더 필요로 하는 모델을 거부한다는 선언이다. CEO Stéphane Bancel은 수천 명 규모로도 수십억 달러 매출을 운영할 수 있어야 한다고 말했다. 이건 성장의 기준을 “인원 확대”에서 “인당 효율”로 바꾸겠다는 의지다.

반면, 이 축을 건드리지 못하고 무너진 사례도 뚜렷하다.

Klarna는 2024년에 AI 챗봇이 700명분의 일을 대신한다며 인원 축소를 강조했다. 그런데 2025년, CEO는 “비용 절감에 과하게 치우쳤다”고 인정하며 다시 채용으로 돌아갔다. KPI를 “비용 절감”에만 맞추면, 자동화가 곧 운영모델이 되는 착각에 빠진다. 비용은 줄었지만 서비스 품질이 떨어졌고, 결국 다시 사람을 뽑아야 했다.

McDonald’s × IBM은 AI 음성 주문을 시험했지만 2024년에 종료했다. 혼선, 주문 오류, 악센트 인식 문제 — 기술적 한계도 있었지만, 현장이 그 기술을 운영할 준비가 되지 않았다는 게 더 본질적이다. 기술과 운영 준비가 함께 가지 않으면 파이프라인 전환은 실험에서 끝난다.

Duolingo는 AI로 148개 코스를 빠르게 확장하며 비즈니스 성과를 냈지만, “AI 우선” 선언과 함께 외주 인력 대체 메시지가 큰 반발을 샀다. 성과가 나더라도, 역할 전환의 맥락 없이 인원 축소만 강조하면 내부와 외부 모두에서 정당성을 잃는다. 변화 관리 없는 전환은 반쪽짜리다.

다섯 번째 축 — 리소스 재배치

마지막 축은 리소스다. AX에 필요한 예산은 툴 라이선스 비용이 아니다. 업무 재설계, 변화 관리, 교육, 운영 원칙 수립에 들어가는 비용이다. BCG는 “진짜 가치는 도구 배포를 넘어 업무 흐름 재설계를 하는 소수 조직이 가져간다”고 정리한다.

Atlassian은 2026년 3월 약 10%(약 1,600명) 감원을 발표하며 AI와 엔터프라이즈 영업에 재투자하고, 업무 체계(System of Work) 기준으로 재조직하겠다고 밝혔다. “AI 때문에 조직 자체를 다시 짠다”는 의지가 명확한 사례다.

정리하면

이 사례들에서 공통적으로 바뀐 것을 정리하면 5가지 축이 된다.

이 5가지 축 중 하나라도 바뀌지 않았다면, 그건 아직 도입 단계다. 5가지가 함께 움직일 때 비로소 전환이라 부를 수 있다.

5. AX 조직은 어떤 모습인가

5가지 축을 제시했다. 하지만 축만으로는 그림이 보이지 않는다. 실제로 AX가 된 조직에서 하루가 어떻게 다른지 그려보자.

기능 조직의 프로젝트 vs AX 조직의 프로젝트

기능 조직에서 신규 기능 하나가 세상에 나오는 과정을 생각해보자. PM이 기획서를 쓴다. 디자인팀에 넘긴다. 디자이너가 시안을 만들어 다시 PM에게 확인받는다. 개발팀에 전달된다. 프론트엔드가 먼저, 백엔드가 그다음. QA가 테스트하고, 버그가 나오면 다시 개발팀으로 돌아간다. 릴리즈 후 성과 분석은 데이터팀이 한다. 그 결과가 다시 PM에게 돌아올 때쯤이면 이미 한 달이 지나 있다.

이 과정에서 각 팀의 실제 작업 시간을 합치면 이틀이다. 나머지는 전부 대기, 핸드오프, 컨텍스트 전환, 승인 대기다.

AX 조직에서는 이 흐름이 근본적으로 달라진다. 하나의 목적 단위 팀 안에 프로덕트 엔지니어와 프로덕트 디자이너가 함께 있고, AI 에이전트가 파이프라인의 일부로 작동한다. 별도의 PM이 기획서를 써서 넘기는 구조가 아니다. 프로덕트 엔지니어가 AI의 데이터 분석 위에서 방향을 판단하고, 프로덕트 디자이너가 AI의 초안 위에서 적합성을 판단한다. 코드는 AI가 작성하고 엔지니어가 리뷰한다. 테스트는 자동화되고, 배포 후 성과 분석도 같은 팀 안에서 실시간으로 돌아온다.

기존 PM의 역할을 쪼개보면 이렇다. 기획서 작성 — AI가 한다. 부서 간 조율 — 목적 단위 팀이면 핸드오프 자체가 없으니 필요 없다. 데이터 분석과 우선순위 — AI가 먼저 제시하고 사람이 판단한다. 의사결정 — 이건 남는다. 하지만 이건 프로덕트 엔지니어와 프로덕트 디자이너가 직접 할 수 있다. PM이 존재하는 가장 큰 이유 중 하나는 부서 사이의 핸드오프 브릿지 역할이었다. 부서 경계가 녹으면 그 역할의 비중은 줄어든다.

오해하지 말아야 할 것이 있다. PM이 사라진다는 이야기가 아니다. 실제로 Shopify나 Stripe 같은 회사에서도 PM은 존재한다. 다만 그 PM은 부서 간 조율자가 아니라, 고객 문제를 정의하고 제품 방향을 판단하는 사람이다. 기능 조직에서 “기획서를 쓰고 핸드오프를 관리하는 PM”과, 목적 단위 팀에서 “무엇을 만들지 결정하고 그 결과에 책임지는 PM”은 같은 직함이지만 전혀 다른 역할이다. 전자의 PM은 AX 조직에서 존재 이유가 줄어들고, 후자의 PM은 오히려 더 중요해진다.

핵심적인 차이는 두 가지다. 첫째, 핸드오프가 사라진다. 같은 팀 안에서 일이 흐르기 때문이다. 둘째, 인간의 역할이 산출에서 판단으로 바뀐다. 모든 팀원이 Maker가 아니라 Closer로 작동한다. 코드를 짜는 게 아니라 코드 품질을 판단하고, 디자인을 만드는 게 아니라 디자인 적합성을 판단하고, 기획서를 쓰는 게 아니라 제품 방향을 결정한다.

제품팀을 넘어서 — 마케팅, 재무, CS까지 통합되는 모델

여기서 한 발 더 나가보자. 이 논리를 제품팀에만 적용할 이유가 없다.

기존 기능 조직에서는 제품이 출시되면 마케팅팀이 캠페인을 기획하고, 세일즈팀이 영업을 하고, CS팀이 고객 문의를 받고, 재무팀이 수익을 정산한다. 각자의 KPI가 있고, 각자의 보고 라인이 있다. 제품팀이 만든 기능이 시장에서 어떤 반응을 얻었는지 알려면 이 모든 팀의 데이터를 모아야 하는데, 그 과정에서 또다시 핸드오프와 대기가 발생한다.

AX 조직에서는 이 경계가 녹는다. 하나의 고객 여정 또는 비즈니스 미션 단위로 팀이 구성된다. 그 안에 프로덕트 엔지니어, 프로덕트 디자이너뿐 아니라 그로스 담당, 고객 경험 담당, 수익 분석 담당이 함께 있다. 직함은 달라도 같은 KPI를 본다.

예를 들어 “신규 사용자 온보딩 완료율 80%” 같은 미션이 있다면, 그 팀 안에서 AI가 사용자 행동 데이터를 분석하고, 그로스 담당이 실험을 설계하고, 프로덕트 엔지니어가 온보딩 흐름을 개선하고, 고객 경험 담당이 이탈 사용자 피드백을 정리한다. 이 모든 일이 한 팀 안에서, 같은 대시보드를 보면서, 같은 주간 회의에서 논의된다.

AI가 이걸 가능하게 만드는 이유가 있다. 과거에는 마케팅 전문가, 재무 전문가, 데이터 분석가를 각각 채용해야 했다. 각 전문가가 자기 영역의 산출물을 만들어야 했으니까. 하지만 AI가 산출을 대신하면, 한 사람이 AI를 활용해 마케팅 데이터를 분석하면서 동시에 고객 피드백을 정리하고, 수익 모델링까지 할 수 있다. 전문성의 깊이는 유지하되, 커버리지가 넓어지는 것이다.

앞서 언급한 DBS가 고객 여정의 오너십을 재정의한 것이 바로 이 모델이다. 고객 여정 하나하나가 하나의 목적 단위 팀에 귀속되고, 그 팀이 제품뿐 아니라 마케팅, 고객 경험, 수익까지 end-to-end로 책임진다. Uber가 4개 레이어의 에이전틱 시스템을 구축한 것도 마찬가지다. 개인이 Claude Code를 쓰는 것과, 조직이 에이전트를 파이프라인에 내장하는 것은 완전히 다른 차원의 일이다.

기능 조직은 전문성을 기준으로 사람을 묶었다. AX 조직은 미션을 기준으로 사람과 에이전트를 묶는다. 이게 가장 근본적인 차이다.

AX의 주체는 경영자다

이런 전환을 실행할 수 있는 사람은 누구인가. 개발자가 아니다.

개발자가 할 수 있는 것: 설치, 스킬 공유, MCP 연결, 사내 전도. 개발자가 못 바꾸는 것: 인원 정책, 평가 제도, 부서 간 오너십, 리스크 정책, 예산 배분, KPI.

Shopify는 CEO가 이 선을 넘었다. Uber는 플랫폼 팀이 거버넌스와 비용 체계를 중앙에서 설계했다. BBVA는 CEO를 포함한 250명의 임원을 먼저 교육시킨 뒤 전사 확산에 들어갔다. 공통점은 명확하다. AX는 도입 캠페인이 아니라 경영 재설계다. 경영자가 조직도를 다시 그리겠다는 결정을 내리지 않으면, 아무리 좋은 도구를 깔아도 기능 조직은 더 빠른 기능 조직으로 남을 뿐이다.

Andrew Ng는 AI 시대의 병목은 코딩이 아니라 프로덕트 매니지먼트라고 말한다. 무엇을 만들지 결정하는 능력이 구현 능력보다 희소해지는 시대. 그 결정을 내릴 수 있는 사람은 조직의 위에 있다.

6. Maker와 Closer — 개인의 커리어가 바뀌어야 한다

AX 조직의 그림을 그렸다. 미션 단위 팀, 인간-에이전트 혼합 파이프라인, 핸드오프 없는 end-to-end 구조. 그렇다면 그 조직에서 살아남는 사람은 어떤 사람인가.

조직의 기본 단위가 바뀌면, 필요한 인재도 바뀐다

마케팅, 재무, 개발이 별도의 팀으로 나뉘어 있는 것이 문제다. 하나의 목적 단위로 재조직되어야 한다. 해당 조직의 모든 구성원은 같은 KPI 달성에 집중해야 한다.

Andrew Ng은 가장 큰 병목은 결국 인간 — 특히 프로덕트를 결정하는 사람 — 이라고 말한다. 그런데 기존 기능 조직에서는 인간 대 인간 사이보다 조직 간의 병목이 훨씬 더 큰 지연과 손실을 만들고 있다. 목적 단위로 팀을 묶고, end-to-end 가치 흐름 전체를 한 명의 리더가 책임지는 구조 — 그게 AX에 가장 가까운 형태다.

보고 라인은 여러 개일 수 있어도, 성과 책임자는 하나여야 한다.

불편한 진실 — 현재 인재가 미래 조직에 적합한가

조직을 다시 짜는 데는 돈이 든다. 꽤 많이. 그리고 그보다 더 불편한 진실이 있다: 현재 인재들이 변화하는 조직 체계에 맞는 사람인지, 지금 인원 규모가 정말 필요한지를 조직이 이제 묻기 시작했다는 것. 이 질문들이 새로운 채용을 꺼리게 만드는 진짜 이유다.

AI 시대에 채용이 조심스러워지는 이유는 불황이 아니다. 미래 역할 구조를 확신하지 못하기 때문이다.

Maker와 Closer

여기서 한 가지 구분을 제안한다.

Maker — 마케팅, 개발, 재무 분야 상관없이 현재 업무에서 아웃풋을 생산해내는 데 집중하는 사람이다. 기획서를 쓰고, 코드를 짜고, 디자인을 만들고, 보고서를 작성한다.

Closer — 생산된 아웃풋을 이용하여 실제 비즈니스 KPI를 달성하기 위해 실행하는 사람이다. 아웃풋을 성과로 전환하는 마지막 마일을 책임진다.

여기서 Closer는 세일즈의 클로징이 아니다. 핵심은 책임을 어디까지 지느냐다. 내 산출물까지가 책임이고 “내 할 일은 끝났다”고 생각하는 사람이 Maker다. 거기서 더 나아가 이 산출물이 정말 성과로 이어지는지 평가하고 그 결과까지 책임지는 사람이 Closer다. Output(산출물)에서 멈추느냐, Outcome(성과)까지 가느냐. 그 차이다.

행동으로 말하면 이렇다. Closer는 “이 방향이 틀렸다”고 멈출 수 있는 사람이다. 아웃풋이 아무리 훌륭해도, 그것이 고객 성과로 이어지지 않는다고 판단하면 방향을 꺾는다. 산출을 멈추는 결정은 Maker에게는 할 수 없는 일이다.

직업적 커리어에서 Maker가 더 인정받는 경향이 있다. 하지만 비즈니스를 지탱하는 건 Closer다.

산출이 늘면 성과도 따라오면 좋겠지만, 현실은 그렇지 않은 경우가 많다. 아웃풋을 열심히 쌓아도 목적 달성이 잘못된 방향으로 가면 그 모든 아웃풋이 쓸모없어진다. 반대로, 아웃풋이 조금 모자라도 어떻게든 방향을 꺾어 목적을 달성해내는 Closer도 있다. 개발 제품이 부족해도 비즈니스 성과를 내거나, 개발 제품이 훌륭해도 비즈니스가 망하는 케이스는 흔하게 봐왔을 것이다.

5, 6년 전 초기 스타트업 기술 컨설팅을 할 때 많은 조직을 만날 기회가 있었다. 제대로 된 개발자 — 전공자는커녕 부트캠프 출신이라도 — 가 한 명도 없는 조직에서, 대표가 스스로 학습하고 말도 안 되는 형태로 코드를 작성하고, 그걸로 대규모 후속 투자까지 끌어내며 고객 성장을 만들어내는 회사도 봤다. 그 대표는 Maker로서는 형편없었지만 Closer로서는 최고였다. 반면, 정말 천재라고 불릴 만한 백그라운드와 경험을 가진 개발자들이 본인들의 기술에 빠져 소위 “어른의 세계”를 외면하는 모습도 많이 봤다. 완벽한 Maker였지만, Closer는 아니었다.

개발 조직은 대부분 Maker를 지향했다. 디자이너와 PM들도 — 본래 Closer여야 할 사람들인데 — 축소된 권한과 경직된 조직 체계 안에서 결국 Maker의 일을 하고 있었다. Closer가 될 수 없는 구조가 Closer를 만들지 못한 것이다.

당신은 Maker인가, Closer인가

지금 자신의 지난 한 주를 돌아보자. 내가 직접 산출한 것은 무엇인가. 그리고 내가 최종 결정을 내린 것은 무엇인가. 기획서를 쓰고, 코드를 짜고, 보고서를 만드는 데 대부분의 시간을 썼다면 당신은 Maker다. 방향을 결정하고, 우선순위를 판단하고, 결과에 책임을 졌다면 Closer에 가깝다.

Maker가 나쁘다는 게 아니다. 지금까지는 Maker가 조직의 엔진이었다. 하지만 AI가 산출을 대신하기 시작하면, Maker의 가치는 점점 줄어든다. 코드를 짜는 건 AI가 하고, 문서를 만드는 건 AI가 하고, 데이터를 분석하는 것도 AI가 한다. 그때 남는 것은 “무엇을 만들어야 하는가”와 “이것이 정말 고객에게 가치가 있는가”를 판단하는 능력이다.

AX 시대의 커리어 방향

AX가 진행될수록 Maker의 역할은 점점 AI에게 위임될 것이다. 코드를 짜고, 문서를 작성하고, 디자인을 만들고, 데이터를 분석하는 것 — 산출 행위 자체가 AI의 영역으로 넘어간다. 많은 경우에 Closer의 역할이 극대화될 것이고, 완전히 AI Native한 조직 내에서 그들의 의사결정만이 유일한 병목이 될 것이다.

대부분의 직장인 입장에서, AI Native 조직에서는 개인의 커리어가 Maker의 방향이 아니라 Closer의 방향으로 전환되어야 한다. 그렇게 본인의 커리어를 전환한 사람들이 결국 AI 시대에도 살아남는 인재가 될 것이다. 두 분야에 깊은 전문성을 가지면서 end-to-end로 전체 사이클을 운영할 수 있는 사람 — 이게 흔히 말하는 π형 인재다. AI가 산출을 대신해주니까 한 사람의 커버리지가 넓어질 수 있고, 그래서 π형 인재가 비로소 현실적으로 가능해진 시대다.

7. 국내 조직의 AX — 왜 아직 움직이지 않는가

여기까지 읽으면서 “그래, 해외 사례는 알겠는데 우리 현실은 다르잖아”라고 생각했을 수 있다. 맞다. 국내 상황은 다르다. 하지만 다르다는 게 안전하다는 뜻은 아니다.

국내에서는 AI 시대임에도 사람들이 일자리를 쉽게 잃지 않는다. 관행을 버리고 새로운 조직 체계를 만드는 건 시간이 꽤 걸리는 일이기 때문이다.

하지만 OpenClaw든 Claude Code든 전사 도입했다고 해도, 국내 대부분 기업은 AI가 들어와도 마케팅팀은 마케팅팀이고 개발팀은 개발팀이다. 생산성이 어마어마하게 올랐다고 말하지만, 그건 Maker의 생산성이지 Closer의 최종 성과 — 매출이나 비즈니스 KPI — 에 반영되었는지는 별개의 질문이다.

2장에서 언급한 국내 SaaS 스타트업의 사례를 다시 보자. 전사 도입은 성공적이었다. 그렇다면 6개월 뒤, 그 조직은 어떻게 달라졌을까?

개발팀은 Claude Code로 코드를 더 빨리 짜고 있다. 마케팅팀은 ChatGPT로 콘텐츠를 더 빨리 만들고 있다. CS팀은 AI로 고객 문의를 더 빨리 분류하고 있다. 모두 더 빨라졌다. 하지만 개발팀과 마케팅팀 사이의 캠페인 기획 프로세스는 여전히 기획서 → 승인 → 전달 → 구현의 직렬 핸드오프다. CS에서 올라온 고객 피드백이 제품 로드맵에 반영되려면 여전히 PM → 리드 → 스프린트 계획 회의를 거쳐야 한다. AI가 들어왔는데, 일이 흘러가는 방식은 도입 전과 똑같다.

각 부서가 자기 업무를 더 효율적으로 수행하게 된 건 맞다. 하지만 부서 사이의 벽은 그대로다. 오히려 각 부서가 자기만의 AI 도구를 최적화하면서 부서별 AI 섬이 생겼다. 3장에서 말한 고속 사일로화가 정확히 이 모습이다.

왜 국내 조직은 아직 이 질문을 시작하지 않았을까? 몇 가지 구조적 이유가 있다.

첫째, 기능 조직이 너무 깊게 뿌리내렸다. 국내 IT 기업 대부분은 마케팅부, 개발부, 기획부라는 구분이 조직도의 뼈대다. 이 뼈대를 바꾸려면 임원진 전체가 동의해야 하는데, 기능 조직에서 임원이 된 사람들이 기능 조직을 해체하자고 말하기는 어렵다.

둘째, 성과 측정 체계가 산출 중심이다. 개발자는 배포 건수, 마케터는 캠페인 수, PM은 기획서 건수로 평가받는다. 이 구조에서 “당신은 이제 고객 성과로 평가됩니다”라고 바꾸려면 평가 시스템 자체를 뜯어고쳐야 한다.

셋째, 학습과 성장이 장려되지 않는 조직문화가 변화를 가로막는다. 새로운 역할로 전환하려면 학습이 필요한데, 그 학습을 장려하고 지원하는 기업이 얼마나 되는가. 대부분의 조직은 현재 업무를 소화하는 것만으로도 벅차다.

이런 환경에서 대부분의 조직은 게으르게 흘러갈 수밖에 없다. 솔직히, 내가 담당자라도 OpenClaw 도입하고 “AX 했다”고 홍보하는 게 편하지, 사람부터 조직까지 뜯어고쳐야 하는 고민은 현실에 치여서 하지 않을 것이다.

하지만 새로운 기업들이 소위 AI Native한 조직 체계를 가지고 성장했을 때, 기존의 기업들이 그 속도를 따라갈 수 있을까? 국내에서 아직 AI 때문에 대규모 해고가 체감되지 않는다고 해서 안전한 것은 아니다. 충격이 늦게 올 뿐이다.

모든 조직이 지금 당장 5축 전부를 바꿔야 하는 건 아니다. 10명짜리 스타트업이라면 이미 목적 단위 팀에 가깝고, 핸드오프가 적다. AX 전환이 절실한 건 기능 조직이 고착화된 중견 이상의 회사들이다. 하지만 규모가 작은 조직이라도 한 가지는 점검해야 한다 — 지금 깔고 있는 AI 도구가 기존 구조를 강화하고 있는지, 아니면 새로운 구조를 가능하게 하고 있는지.

결국 AI 기술 발전은 우리가 일하는 방식을 궁극적으로 바꾸게 될 것이다. 바뀌지 않는 조직 안에서 바뀌지 않는 개인은, 바뀐 조직의 바뀐 개인에게 추월당할 뿐이다.

8. 나가며 — 도구는 시작을 만든다. 전환은 구조가 만든다.

AI를 전사에 심는 것은 좋은 시작이다. 그 시작을 만들어낸 사람들에게 진심으로 박수를 보낸다.

하지만 시작을 완성이라 부르면 다음 단계가 사라진다.

진짜 AX는 기존 기능 조직 위에 AI를 얹는 게 아니다. 역할을 재정의하고, 파이프라인을 재설계하고, KPI를 바꾸고, 거버넌스를 세우고, 리소스를 재배치하는 일이다. 인간-에이전트 혼합 운영 체계로 조직을 다시 짜는 일이다. 그래서 AX의 주체는 개발자가 아니라 경영자다.

그리고 개인의 커리어는 Maker에서 Closer로 전환되어야 한다. AI가 잠식하는 것은 산출 그 자체이고, 인간에게 더 오래 남는 것은 성과 책임과 방향 결정이다.

나 역시 오랫동안 Maker였다. 코드를 잘 짜면 비즈니스도 따라올 거라고 믿었던 시절이 있다. 지금은 안다. 좋은 산출물은 필요조건이지 충분조건이 아니라는 것을. 방향이 맞아야 산출이 의미를 갖는다. 그 방향을 정하는 게 Closer의 일이다.

조직에 Claude Code를 설치한다고 AX가 되는 게 아니다. AX는 조직도를 다시 그리는 순간부터 시작된다.

References

1. Bain & Company, “Unsticking Your AI Transformation”
2. McKinsey & Company, “AI in the Workplace: Empowering People to Unlock AI’s Full Potential”
3. BCG, “Companies Must Go Beyond AI Adoption to Realize Its Full Potential”
4. BCG, “Five Things Boards Need to Get Right with AI”
5. Harvard Business Review, “Don’t Let AI Reinforce Organizational Silos”
6. The Verge, “Shopify CEO says no new hires without proof AI can’t do the job”
7. The Pragmatic Engineer, “How Uber Uses AI for Development”
8. Business Insider, “Andrew Ng: Product Management Is the New Bottleneck”
9. Computer Weekly, “DBS Rewires Operating Models for AI Reasoning Era”
10. Morgan Stanley, “Launch of AI @ Morgan Stanley Debrief”
11. Moderna, “Our Journey to Becoming a Real-Time AI Organization”
12. Reuters, “Sweden’s Klarna shifts AI focus from cost cuts to growth”
13. AP News, “McDonald’s ends test run of AI-powered drive-thrus with IBM”
14. Reuters, “Duolingo raises 2025 forecast”
15. Wall Street Journal, “Johnson & Johnson Pivots Its AI Strategy”
16. Atlassian, “Team Update March 2026”
17. OpenAI, “BBVA: Scaling AI Across 120,000 Employees”
18. Box, “AI-First: Building the Future of Intelligent Content Management”
19. METR, “Measuring the Impact of AI on Experienced Open-Source Developer Productivity”
20. r/cursor, “Do you believe the claims that AI isn’t improving programmer productivity?”
21. r/ExperiencedDevs, “Did AI increase productivity in your company?”
22. r/ExperiencedDevs, “AI is working great for my team, and y’all are making me feel crazy”