모두가 AI를 가져도 회사는 여전히 아무것도 배우지 못할 때

6 hours ago 1

직원 개인의 AI 생산성 향상은 자동으로 조직 차원의 학습으로 이어지지 않으며, 실제 발견이 개인에서 팀과 조직 역량으로 이동하는 경로가 핵심 과제가 됨
AI 도입의 복잡한 중간 단계에서는 Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor 같은 도구 사용이 널리 퍼졌지만 팀마다 활용 깊이가 다르고, 일부 학습은 숨겨져 비교와 확산이 어려움
기존 변화 관리 방식인 커뮤니티, 챔피언 네트워크, 데모, 설문, 대시보드는 실제 업무 중 생기는 AI 활용의 맥락·실패·검증·사람의 개입을 충분히 담기 어려움
에이전트형 엔지니어링은 반복 비용을 낮춰 의도에서 프로토타입과 평가까지 빠르게 이동하게 하지만, 조직의 Scrum·스프린트·인수인계 절차는 여전히 반복이 희소하다는 전제에 머물 수 있음
조직에는 Agent Operations, Loop Intelligence, Agent Capabilities가 함께 필요하며, 직원 감시가 아니라 실제 업무 루프를 이해해 재사용 가능한 역량과 더 빠른 학습으로 되돌리는 피드백 하네스가 중요함

조직이 배우지 못하는 AI 도입의 복잡한 중간 단계

Ethan Mollick의 Leadership, Lab, and Crowd 관점에서 개인의 AI 생산성 향상은 자동으로 조직 차원의 성과가 되지 않음
- 직원은 더 빨리 쓰고, 더 많이 분석하고, 자동화하고, “사이보그”처럼 일할 수 있지만 회사는 거의 아무것도 배우지 못할 수 있음
- GitHub Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor 같은 도구가 회사 안에 들어왔고, 공식 교육 자료보다 훨씬 앞서 있는 사람이 각 팀에 있음
- 경영진은 라이선스 사용량, 프롬프트 수, 설문, 내부 PoC, 조향위원회 자료를 볼 수 있지만 실제 학습이 어디서 일어나는지는 잘 보이지 않음
- 일부 회사에서는 AI가 IT 부서로 바로 넘어간 뒤 더 이상 진전되지 않음
AI 도입의 복잡한 중간 단계는 AI 사용이 널리 퍼졌지만 불균등하고, 일부는 숨겨져 있으며, 비교하기 어렵고, 아직 조직 학습과 연결되지 않은 상태에서 시작됨
- 도입 단위가 더 이상 조직 전체도, 어쩌면 팀도 아니며, 실제 업무 안의 루프(loop)로 바뀜

모두 Copilot을 가진 이후에 벌어지는 일

첫 단계의 AI 도입은 기존 엔터프라이즈 롤아웃처럼 보여 비교적 익숙함
- 좌석을 구매하고, 허용 가능한 사용 범위를 정하고, 교육을 진행하고, 챔피언 네트워크를 만들고, Teams 채널에 유스케이스를 공유하게 함
- 이런 채널은 잠시 활발해졌다가 좋은 의도만 쌓인 기업 내부 창고처럼 될 수 있음
두 번째 단계에서는 같은 회사 안에서도 AI 활용 방식이 크게 갈라짐
- 어떤 팀은 Copilot을 자동완성 정도로만 사용함
- 다른 팀은 Claude Code를 테스트, 리뷰, 지속적 조정과 함께 촘촘한 루프로 돌림
- 제품 담당자가 Figma 화면을 만드는 대신 실제 소프트웨어를 프로토타이핑함
- 시니어 엔지니어가 근본 원인 분석을 에이전트에 맡겨 1시간 안에 유효한 해법을 얻고, AI 없이는 2주가 걸렸을 작업을 단축함
- 주니어가 세련된 코드를 만들지만 어떤 아키텍처 가정이 시스템에 끼어들었는지 모를 수 있음
- 지원팀은 반복 티켓을 조용히 워크플로 자동화로 바꾸며, Center of Excellence가 묻지 못한 실제 고통 지점을 알고 있음
Mollick의 구조에서 리더십은 방향과 허가를 정하고, Crowd는 실제 업무를 하므로 유스케이스를 발견하며, Lab은 그 발견을 공유 관행, 도구, 벤치마크, 새 시스템으로 바꿈
- 핵심 난점은 발견이 개인에서 팀으로, 팀에서 조직 역량으로 실제로 어떻게 이동하는지에 있음

기존 변화 관리 방식은 너무 느림

대부분의 회사는 기존 변화 관리 장치로 AI 도입을 처리하려 함
- 실천 공동체, 점심 세션, 챔피언 네트워크, 활성화 자료, 오피스아워, 월간 데모, 설문, 대시보드 등이 사용됨
- 아직 실험 허가 자체가 필요한 조직에서는 이런 방식도 도움이 됨
하지만 흥미로운 AI 활용은 다음 커뮤니티 미팅을 기다리지 않고 실제 업무 중에 생김
- 코드 리뷰, 영업 제안서, 리서치 작업, 제품 프로토타입, 운영 장애, 테스트 전략, 컴플라이언스 질문 안에서 나타남
- 특정 제품 컴포넌트 유형에서 “다크 팩토리”에 가까운 패턴이 만들어질 수 있음
  - 의도를 작성함
  - 에이전트가 느슨한 루프를 돌게 함
  - 충분한 역압(backpressure)을 걸어 궤도를 유지함
  - 강한 시나리오로 결과를 평가함
  - 의도를 다듬고 반복적으로 높은 품질의 결과를 얻음
유용했던 학습은 베스트 프랙티스 슬라이드로 정리될 때 날카로움을 잃기 쉬움
- 실제 가치를 만든 것은 빠진 맥락, 실패한 테스트, 이상한 API 동작, 에이전트가 말도 안 되는 방향으로 퍼졌을 때 사람이 되돌린 마찰이었기 때문임
elastic loop 관점에서 AI 협업은 하나의 모드가 아님
- 촘촘하고 동기적인 공동 운전부터 더 느슨하고 비동기적인 위임까지 늘어남
- 중요한 질문은 “사람들이 AI를 쓰는가”가 아니라 팀이 어떤 루프 크기를 써야 하는지, 어디에 저항이 필요한지, 어떤 산출물이 루프 뒤에도 살아남아야 하는지, 그 산출물이 어떻게 조직 학습이 되는지임
- 이는 도구 사용량이나 토큰 수 계산보다 훨씬 어려운 질문임

Scrum은 비싼 반복을 전제로 만들어졌음

현대 소프트웨어 프로세스의 많은 부분은 인간의 반복이 비쌌기 때문에 존재함
- 스프린트 계획, 추정, 스탠드업, 사용자 스토리, 티켓 정리, 인수인계, 조율과 위험 감소를 위한 의식이 여기에 포함됨
- 한 번의 반복이 며칠 또는 몇 주 걸린다면 낭비되는 반복을 막는 구조가 필요했음
에이전트형 엔지니어링은 반복의 경제성을 바꿈
- 더 많은 선택지를 실제로 만들어볼 수 있게 함
- 의도에서 프로토타입, 평가까지 더 빠르게 이동하게 함
- 제품 담당자가 동작하는 소프트웨어를 더 일찍 보게 함
- 엔지니어가 결정 전에 더 많은 가설을 시험하게 함
- 전달 자체를 마법처럼 쉽게 만들지는 않지만 제약을 구현에서 의도, 검증, 판단, 피드백 쪽으로 이동시킴
많은 조직은 20년 동안 스스로를 애자일이라고 불렀지만 애자일이 제거하려 했던 조직적 반사를 유지함
- AI는 실제 민첩성을 더 그럴듯하게 만들지만, 시스템은 여전히 2주 스프린트 약속, 인수인계 문서, 반복이 희소하다는 전제를 가진 절차를 요구함
- 루프는 조직이 그 루프에서 배운 것을 소화하는 속도보다 더 빠르게 움직일 수 있음

AI 사용료가 조직에 더 나은 질문을 강제함

AI 사용은 더 명확하게 계량될 가능성이 큼
- 현재의 “모두 접근권이 있고 비용은 크게 걱정하지 않는” 엔터프라이즈 분위기는 오래 유지되지 않을 수 있음
- 모델 라우팅, 토큰 예산, 사용량 기반 가격, 추론 비용, 어떤 작업에 어떤 모델을 허용할지에 대한 거버넌스가 더 명시적으로 바뀜
중요한 질문은 추상적으로 토큰 비용을 줄이는 것이 아님
- 소프트웨어 전달에서 중요한 질문이 키 입력 수 최소화가 아니었던 것과 같음
- 더 나은 질문은 “그 토큰을 썼기 때문에 무엇이 바뀌었는가”임
풀 리퀘스트 수를 세는 방식은 피해야 함
- 어떤 루프가 더 빨리 닫혔는가
- 어떤 의사결정이 개선되었는가
- 어떤 근본 원인 분석이 더 날카로워졌는가
- 어떤 리뷰가 더 많은 문제를 잡았는가
- 어떤 팀이 재사용 가능한 패턴을 배웠는가
- 어떤 제품 아이디어가 프로토타입 덕분에 약점이 드러나 더 일찍 폐기되었는가
- AI가 어디서 학습을 만들었고, 어디서 단순히 더 많은 산출물만 만들었는가
“토큰 대비 산출물”은 낡은 측정 반사가 새 옷을 입은 형태임
- 더 중요한 것은 토큰 대비 학습에 가까움

빠진 피드백 경로로서의 Loop Intelligence

AI 도입의 복잡한 중간 단계에서 회사에는 세 가지 역량이 필요함
Agent Operations
- 어떤 에이전트와 AI 도구가 실행 중인지, 어떤 시스템을 건드릴 수 있는지, 어떤 데이터를 볼 수 있는지 관리함
- 어떤 행동에 승인이 필요한지, 정체성, 감사, 권한, 런타임 가시성이 어디에 있는지도 포함됨
- 에이전트형 작업은 결국 실제 시스템을 건드리기 때문에 통제 측면이 중요함
Loop Intelligence
- 어떤 AI 지원 또는 완전 에이전트형 루프가 실제 학습을 만드는지 파악함
- 어떤 루프가 열린 채로 남는지, 어떤 루프가 쇠퇴하는지, 에이전트가 어디서 레버리지를 만드는지, 어디서 곁가지로 퍼지는지 봄
- 어떤 팀이 테스트, 맥락, 직관 부족 때문에 촘촘한 감독에 묶여 있는지, 어떤 팀이 더 느슨한 위임을 할 준비가 되었는지 판단함
Agent Capabilities
- 유용한 역량을 조직 전체에 배포하되, 세 개의 거대한 에이전트가 모두의 일을 할 수 있다고 가정하지 않음
- AI는 단일 애플리케이션 범주보다 유동적인 기반 기술처럼 움직이기 시작함
- “HR 에이전트”, “엔지니어링 에이전트”, “영업 에이전트” 하나씩을 엔터프라이즈 동물원에 두는 방식에는 잘 맞지 않음
- 역량이 실제 일이 일어나는 곳으로 흘러가야 함
  - 직원 하네스(harness)
  - 백그라운드 에이전트
  - 제품 팀
  - 플랫폼 서비스
  - 로컬 스킬
  - MCP 서버
  - 평가 스위트
  - 런북
  - 예시
  - 도메인별 절차

플랫폼 질문과 피드백 하네스

플랫폼 차원에서 중요한 질문은 유용한 역량의 소유와 이동 방식임
- 한 팀에서 발견한 유용한 에이전트 스킬이 죽은 템플릿이 되지 않고 다른 팀에 전달되는 방법이 필요함
- 개발자의 하네스, 제품 담당자의 하네스, 지원팀의 백그라운드 에이전트, 컴플라이언스 워크플로는 서로 다르게 강화되어야 함
- 어떤 역량은 팀 가까이에 있어야 하고, 어떤 역량은 플랫폼 계층에 있어야 하며, 어떤 역량은 로컬 맥락 자체가 핵심이므로 일반화하면 안 됨
세 가지 역량 중 하나만 있으면 빠르게 이상해짐
- Agent Operations만 있고 Loop Intelligence가 없으면 통제 관료제가 됨
- Loop Intelligence만 있고 Agent Capabilities가 없으면 유용한 패턴을 발견하지만 다시 업무로 넣지 못하는 분석 계층이 됨
- Agent Capabilities만 있고 Operations와 Loop Intelligence가 없으면 더 나은 브랜딩을 가진 도구 난립이 됨
- 통제 경로, 학습 경로, 역량 경로는 어딘가에서 만나야 함
내부적으로는 이를 피드백 하네스라고 부를 수 있음
- 고객이 사는 것은 우아한 메커니즘이 아니라 자신감, 더 나은 의사결정, 더 빠른 학습, 더 적은 낭비, 더 안전한 위임임
- 고객에게 더 유용한 개념은 Loop Intelligence Hub일 수 있음
피드백 하네스는 실제 업무 루프를 듣는 장치임
- 작업, 프롬프트, 사양, 리뷰, 시나리오, 채택·거절된 가설, 운영 신호, 재작업, 사람의 결정과 개입을 봄
- 사람을 감시하기 위한 것이 아니라 루프를 이해하기 위한 것임
- 첫 버전이 거대한 플랫폼일 필요는 없음
- 몇 개의 실제 워크플로를 골라 의도, 에이전트 작업, 검증, 사람의 결정이 이미 흔적을 남기는 지점을 계측하고, 루프가 왜 성공하거나 실패했는지 이해할 만큼의 정성 피드백을 모아 반복적인 학습 산출물로 바꾸면 됨
Loop Intelligence Hub는 신호를 조직이 행동할 수 있는 형태로 바꿈
- 활성화 백로그
- 역량 레이더
- 투자 브리프
- 거버넌스 공백
- 재사용 가능한 워크플로
- 교육 필요
- 평가 우선순위
- 모든 곳에 맞는 대시보드가 아니라 관련성에 맞춘 출력이 필요함
흥미로운 산출물은 대시보드 자체가 아니라 그 뒤의 결정임
- 어떤 팀은 더 많이 위임하기 전에 더 나은 역압이 필요함
- 어떤 제품 그룹은 좁은 컴포넌트 유형에 대해 반복 가능한 다크 팩토리 패턴을 가지고 있음
- 어떤 컴플라이언스 워크플로는 거버넌스가 적용된 도구 경계가 필요함
- 어떤 스킬은 다섯 팀이 잘못 재발명했기 때문에 플랫폼으로 옮겨야 함
- 하네스는 수집하고, 허브는 조직이 결정하도록 돕고, 역량 계층은 학습을 다시 업무로 넣음

직원 감시가 되면 실패함

이 구조가 직원 점수 매기기로 변하면 전체가 무너짐
- 직원이 조직이 자신이 AI를 충분히 썼는지 측정한다고 믿으면 신호를 조작함
- 모든 실험이 생산성 기대치가 된다고 믿으면 실험을 숨김
- 최고의 워크플로가 곧 새로운 기본 업무량이 된다고 믿으면 그것을 비공개로 유지함
- 회사는 가시적인 준수와 보이지 않는 학습이라는 최악의 도입 형태를 얻게 됨
유용한 질문은 “누가 AI를 충분히 쓰는가”가 아님
- AI가 어디서 조직이 배울 수 있는 방식으로 일을 바꾸었는가
- 어떤 루프가 더 건강해졌는가
- 어떤 팀이 더 위임하기 전에 더 나은 역압이 필요한가
- 프로토타입이 실제 소프트웨어가 되고 있다면 어떤 제품 팀에 다른 환경이 필요한가
정책은 필요하지만 거버넌스도 학습처럼 사용을 통해서만 현실이 됨
- 에이전트가 운영 인접 작업을 건드릴 때
- 제품 담당자가 명세 작성 대신 프로토타입을 만들 때
- 개발자가 근본 원인 분석을 위임할 때
- 토큰 지출이 커져 경영진이 답을 원할 때
- 조직은 학습 시스템을 만들었는지, 단지 많은 좌석을 샀는지 알게 됨

복잡한 중간 단계는 견뎌낼 단계가 아님

AI 도입의 첫 단계는 접근권에 관한 것이었음
- 누가 도구를 받는지, 누가 허가를 받는지, 누가 계약을 협상하는지, 조달 티켓 없이 최신 모델을 시험할 수 있는지가 중요했음
- 이 단계는 여전히 중요하지만 오래 차별화 요소가 되지는 않음
- 최전선 지능에 대한 접근은 빌릴 수 있지만, 운영 통제와 조직 학습은 같은 방식으로 빌릴 수 없음
다음 우위는 학습 속도임
- 누가 실제 패턴을 더 빨리 찾는가
- 누가 발견을 개인에서 팀으로, 팀에서 조직 역량으로 옮기는가
- 누가 에이전트형 루프에 역압을 넣어 에이전트가 퍼지지 않게 하는가
- 누가 모두에게 맞지 않는 거대 엔터프라이즈 에이전트로 만들지 않고 유용한 에이전트 역량을 배포하는가
- 누가 AI를 기존 의식에 덧붙이는 대신 에이전트형 엔지니어링으로 애자일을 실제에 가깝게 만드는가
확정된 도입 플레이북을 기다려서는 이 변화를 이해하기 어려움
- 벤더, 컨설턴트, AI 연구소의 최종 답을 기다리는 대신 실제 업무를 계측하고, 지저분한 학습을 공유하고, 다른 사람이 허점을 찌르게 두고, 공개적으로 반복해야 함