왜 도구를 뿌리는 것으로 끝나지 않는가
도어대시는 2025년 Claude Code를 도입한 뒤, 엔지니어링 밖에서도 터미널로 직접 배포하는 사람들이 나타나는 걸 보고 전 직원에게 코딩 에이전트를 지급했습니다. 목표는 회사 전체의 AI 활용 기본기, 즉 '바닥'을 끌어올리는 것이었습니다. 많은 직원이 AI를 여전히 채팅으로만 쓰는데, Gmail·캘린더·Slack에 연결되는 순간 지식노동의 효율이 달라지기 때문입니다.
그런데 처리량이 오르자 가려져 있던 병목이 드러났습니다. 코드가 쏟아지니 머지 대기와 코드 리뷰가 밀리고, 보안 이슈가 업계 전반에서 늘었습니다. 도어대시는 이를 다시 AI 코드 리뷰 에이전트로 자동화해 대응했습니다. 속도를 한 겹 풀면 다음 벽이 나오고, 그 벽을 또 자동화하는 반복이 AX의 실제 모습입니다.
학습은 어떻게 조직 전체로 퍼지는가
가장 확장성 있는 확산 수단은 '글로 남긴 산출물(written artifacts)'입니다. 잘한 사람과 성공 사례를 뽑아 문서로 남기게 하면 회사 전체가 읽을 수 있고, 부산물로 에이전트가 참조할 자료까지 쌓입니다. 사람을 붙여 일일이 가르치는 방식은 조직 규모에서 확장되지 않습니다.
성공만 공유하게 해선 안 됩니다. '이 워크플로는 안 됐다', '이 MCP 통합은 토큰만 낭비했다' 같은 실패도 똑같이 편하게 공유하는 문화가 있어야 합니다. 각 팀이 자기 채널에서 성과와 한계를 함께 드러낼 수 있어야 학습이 축적됩니다.
실험 팀은 무엇이 있어야 움직이는가
특정 팀에게 'AI로 3~5배 빨리 해보라'는 과제를 줄 때, 평소 업무 범위 안에서만 시키면 사람들은 금방 포기합니다. 코드 생성 밖의 장벽 — 교차기능 합의, 리뷰 프로세스, 승인 절차 — 이 그대로 남아 있기 때문입니다.
그래서 도어대시는 실험 팀에 VP·임원급 스폰서십을 붙입니다. 토큰 예산만 주는 게 아니라 '코드 밖에서 무엇이 너를 막는지'를 위로 제기할 권한을 함께 줍니다. 리더가 직접 뛰어들어 막힌 걸 뚫어줄 때 팀이 안전하게 실험합니다.
AI 챔피언은 어떻게 찾는가
톱다운으로 '이 워크플로를 자동화하라'고 지정하면 대개 틀린 워크플로나 틀린 사람을 고릅니다. 정작 어디가 병목인지는 그 일을 매일 하는 사람만 압니다.
그래서 자유를 주고 자발적으로 튀어나오는 챔피언을 찾습니다. 영업·마케팅·운영·지원 각 도메인에서, 남는 시간에도 도구를 파고드는 사람들이 스스로 드러납니다. 열정 때문에 Slack에서 성과를 공유하지 않고는 못 배기기 때문입니다. 이들이 도메인의 진짜 병목을 찾아 자동화하거나, 동료가 쓸 공용 skill로 만듭니다.
그래서 조직은 무엇을 재설계해야 하는가
가장 인상적인 재설계는 리뷰 프로세스였습니다. 과거엔 엔지니어가 디자인을 픽셀 단위까지 맞추느라 시간을 썼지만, 이제는 엔지니어가 동작하는 상태까지만 만들고 디자이너가 완성도를 자립적으로 마무리합니다. 그러자 제품 리뷰·디자인 리뷰가 오히려 병목이 됐고, 도어대시는 '이 리뷰가 여전히 같은 형태로 필요한가'를 되물었습니다.
핵심 원리는 자립성입니다. 개인과 팀이 자립적일수록 빨라지므로, 도메인 전문가 게이트키퍼는 소수만 두고 나머지는 코드베이스를 넘나드는 제너럴리스트로 키웁니다. 코드 속도가 병목이던 시절엔 그 속도가 팀 구성·프로세스·리뷰 주기를 규정했지만, 엔지니어링이 빨라진 지금은 그 전부를 다시 설계해야 합니다.
ROI는 두 갈래로 봅니다. 하나는 모두가 하는 업무의 시간을 줄여 '기준선'을 올리는 것, 다른 하나는 부서·도메인별로 특정 워크플로를 자동화하는 것입니다. 후자가 더 큰 임팩트를 낼 수 있습니다. 전 직원이 10%만 더 생산적이어도 규모가 큰 조직에선 막대한 차이가 됩니다. 결국 지표는 코드가 머지되는 속도가 아니라 고객 가치가 더 빨리 전달되는가입니다.