모두가 AI를 가지고 있지만 회사가 여전히 아무것도 배우지 못할 때: 기업 AI 도입의 혼란스러운 중간 지점

이 기사에서는 Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor 등의 라이선스가 제공되었지만 회사 전체가 거의 아무것도 배우지 못하는 고통스러운 AI 도입 단계에 대해 논의합니다. Ethan Mollick의 리더십, 연구소, 군중(Leadership, Lab, and Crowd) 모델이 인용됩니다: 리더십이 방향을 설정하고, 군중이 사용 사례를 발견하며, 연구소는 발견된 사례를 공유된 관행으로 전환해야 하지만, 학습은 거의 전파되지 않습니다.

현재 AI 도입의 주요 문제점

• 첫 번째 단계는 표준적인 엔터프라이즈 롤아웃과 유사합니다: 좌석 구매, 허용 사용 정의, 교육 실시, 챔피언 네트워크 구축, Teams 채널에서 사용 사례 공유 요청 (죽은 다락방이 됨).
• 두 번째 단계는 더 혼란스럽습니다: 한 팀은 Copilot을 자동 완성 기능으로 사용하고, 다른 팀은 Claude Code를 긴밀한 루프와 리뷰로 운영하며, 제품 소유자는 Figma 목업 대신 실제 소프트웨어를 프로토타이핑하고, 시니어 엔지니어는 근본 원인 분석을 에이전트에 위임하여 1시간 이내에 유효한 솔루션을 얻습니다 (이전에는 2주 소요), 주니어는 아키텍처 영향을 이해하지 못한 채 깔끔한 코드를 작성하고, 지원팀은 Center of Excellence에서 적절한 질문을 한 번도 하지 않았기 때문에 반복되는 티켓을 조용히 워크플로 자동화로 전환합니다.
• 도입 단위는 더 이상 조직이나 팀이 아닙니다 — 바로 작업 내부의 루프입니다.

전통적인 변화 메커니즘이 실패하는 이유

실무 커뮤니티, 브라운백 세션, 챔피언 네트워크, 역량 강화 자료, 월간 데모, 설문 조사 등은 너무 느립니다. 흥미로운 AI 작업은 코드 리뷰, 영업 제안, 연구 작업, 제품 프로토타입, 운영 장애, 테스트 전략, 규정 준수 질문 내에서 나타납니다. 그 이야기가 모범 사례 슬라이드가 될 때쯤이면 학습은 이미 힘을 잃었습니다. 유용했던 것은 마찰이었습니다: 누락된 맥락, 실패한 테스트, 이상한 API 동작, 에이전트가 무의미한 결과를 내놓아 누군가가 제지해야 했던 순간입니다.

탄력적 루프 프레임워크

저자는 탄력적 루프를 통해 생각할 것을 제안합니다: AI 협업은 하나의 모드가 아닙니다. 긴밀하고 동기적인 공동 운전에서 느슨하고 비동기적인 위임까지 확장됩니다. 실제 도입 질문은 '사람들이 AI를 사용하고 있는가?'가 아니라: 팀이 어떤 루프 크기를 사용해야 하는지 알고 있는가? 저항이 필요한 부분은 어디인가? 어떤 산출물이 루프에서 살아남아야 하는가? 그 산출물이 조직이 배울 수 있는 것으로 어떻게 변하는가? 이것은 도구 사용이나 토큰 계산보다 훨씬 어렵습니다.