모두가 AI 를 갖췄는데 회사는 여전히 아무것도 배우지 못한다

이탄 몰릭 (Ethan Mollick) 은 오랫동안 조직 내 AI 도입에 대해 글을 써왔다. 그의 저서『AI 를 활용하는 리더십, 실험실, 대중』(Making AI Work: Leadership, Lab, and Crowd) 에서 그는 개인적인 생산성 향상에서 조직적인 이득으로의 전환이 자동으로 이루어지지 않는다고 지적한다. 사람들은 더 빠르게 일하거나, 더 잘 쓰거나, 더 많이 분석하거나, 더 많이 자동화하거나, 조용히 자신들의 사이보그 버전이 될 수도 있다. 하지만 회사는 여전히 거의 아무것도 배우지 못할 수 있다.

많은 기업들이 이제 GitHub Copilot 라이선스를 할당하고, ChatGPT Enterprise 가 스택에 존재하며, Claude 나 Gemini 나 Cursor 가 포켓에 나타나고, 공식적인 활성화 자료보다 훨씬 앞서 있는 사람이 적어도 한 명씩 있는 팀이 있다는 단계로 진입하고 있다. 이 중 일부는 눈에 띄지만, 많은 부분은 그렇지 않다. 경영진은 라이선스 사용량을 보고 ("지난해 Anthropic 에 200 만 유로를 지불한 ROI 는 어디에 있는가?") 할지 모른다. 프롬프트 수나 설문조사를 보거나, 몇 가지 내부 PoC 를 통해 방향설정 위원회 데크에 넣을 만큼 충분히 고무적이라고 생각할지도 모른다. 다른 기업들에서는 AI 가 IT 로 바로 넘어가고 죽었다.

모두가 이 단계가 복잡해지고, 정말로 복잡해지는 단계임을 알고 있을 것이다. AI 도입의 "혼란스러운 중간" (messy middle) 단계는 AI 사용이 어디에나 존재하고, 불균형하며, 부분적으로 숨겨져 있고, 비교하기 어렵고, 조직 학습과 아직 연결되지 않았을 때 시작된다.

이제 모두 Copilot 을 갖췄다

AI 도입의 첫 번째 단계는 (대부분) 다른 기업 배포와 비슷해 보이기 때문에 편안하다. 좌석을 구매한다. 허용 가능한 사용을 정의한다. 교육을 실행한다. 챔피언 네트워크를 만든다. 사람들이 Teams 채널에서 사용 사례를 공유하도록 요청하며, 이는 잠시 동안 살아있어 보이지만 곧 더 많은 기업 아틀리에가 되어버린다.

두 번째 단계는 훨씬 낯선 것이다: 한 팀은 Copilot 을 자동 완성기로 사용하고 끝낸다. 다른 팀은 Claude Code 를 테스트, 검토, 지속적인 방향 설정과 함께 긴 루프에서 실행한다. 제품 소유자는 갑자기 Figma 에서 화면을 모방하는 대신 실제 소프트웨어를 프로토타입한다. 상급 엔지니어는 원인 분석을 에이전트에 위임하고 AI 에게 1 시간 만에 유효한 해결책을 얻는다. 이는 AI 가 없었으면 2 주가 걸렸을 것이다. 초급자는 다듬어진 코드를 생성하지만, 어떤 구조적 가정이 시스템에 은밀하게 들어갔는지 전혀 모른다. 지원 팀은 반복되는 티켓을 워크플로우 자동화로 조용히 전환하며, 그들이 정확히 어디에서 작업이 고통스러운지 알고 있기 때문이다. Excellence 센터의 누구도 올바른 질문을 하지 않았기 때문이다.

이 모든 것이 같은 회사에서 동시에 일어날 수 있다. 이것이 혼란스러운 중간이 혼란스러운 이유다: 도입 단위는 조직이 아니며, 아마도 팀조차 아닐 것이다. 그것은 작업 내부의 루프이다!

몰릭의 Leadership, Lab, and Crowd 프레임은 여기서 유용하다. 리더십은 방향과 허가를 설정한다. 대중 (Crowd) 은 실제 작업을 수행하기 때문에 사용 사례를 발견한다. 실험실 (Lab) 은 이러한 발견을 공유된 실천, 도구, 벤치마크, 그리고 새로운 시스템으로 전환한다. 하지만 내가 계속 막히는 부분은 또 다른 에이전트 엔지니어링에서 반복되어 나타나는 것과 같은 부분이다: 학습이 어떻게 실제로 이동하는가?

기존 변화 기구는 너무 느리다

대부분의 기업은 이미 가진 기계를 통해 AI 도입을 처리하려고 할 것이다. 실천 커뮤니티, 브라운 배지 세션, 챔피언 네트워크, 활성화 데크, 오피스 시간, 월간 데모, 설문조사, 아마도 대시보드. 충분히 이해한다. 내가 했어, 너도 했어. 그 중 일부는 도움이 되며, 특히 실험을 하도록 허가가 필요한 조직에서는 더욱 그렇다.

하지만 흥미로운 AI 작업은 다음 커뮤니티 회의에 기다리지 않습니다. 코드 리뷰, 영업 제안, 연구 과제, 제품 프로토타입, 생산 사고, 테스트 전략, 준수 질문 속으로 나타납니다. 또는 특정 제품 컴포넌트 클래스를 위해 어둠 공장을 세울 수 있다고 누군가가 깨달았을 때입니다: 의도를 작성하고 에이전트가 매우 느슨한 루프를 실행하게 하고, 충분할 만큼 백프레셔를 적용하여 그 상태를 유지하며, 강력한 시나리오에 대해 결과를 평가하고, 의도를 개선하며, 반복적으로 고품질의 결과를 얻습니다. 이야기가 실용적인 슬라이드로 정리될 때까지는 중요한 학습은 종종 그 이빨을 잃어버립니다. 그것이 유용하게 만든 것은 마찰이었습니다: 누락된 컨텍스트, 실패한 테스트, 이상한 API 동작, 에이전트가 무의미로 퍼져버린 순간과 누군가가 그것을 다시 잡아야 했던 순간입니다.

나는 이것을 탄성 루프와 같은 렌즈를 통해 생각해 왔습니다. AI 협업은 하나의 모드가 아닙니다! 그것은 긴밀한 동기화 공동 운전에서 느슨한 비동기 위임으로 늘어납니다. 채택 질문은 단순히 "사람들이 AI 를 사용하고 있는가"가 아니라, 팀이 어떤 루프 크기를 사용해야 하는지, 어디에 저항이 필요한지, 어떤 아티팩트가 루프를 통과할 수 있는지, 그리고 그 아티팩트가 조직이 배울 수 있는 것이 되는지는 무엇인지입니다.

그것은 도구 사용이나 빈 (토큰) 카운팅보다 훨씬 어려운 질문입니다.

스크럼은 비싼 반복을 위해 만들어진 것입니다

나는 현대 소프트웨어 프로세스의 대부분은 인간 반복이 과거에 비쌌기 때문에 존재한다고 주장했습니다. 스프린트 계획, 추정, 스탠드업, 사용자 스토리, 티켓 그룸핑, 전달, 조정과 리스크 감소 주변의 모든 의식적인 절차. 제약 조건이 합리적이라면. 만약 단일 반복이 일주일이나 주일 걸리면, 사람들이 너무 많은 것을 낭비하지 못하도록 구조가 필요합니다.

하지만 에이전트 엔지니어링은 경제학을 바꿉니다: 더 많은 옵션을 현실화하게 만듭니다! 그것은 팀이 의도에서 프로토타입으로 평가로 훨씬 빠르게 이동하게 합니다. 그것은 제품 사람들이 작업하는 소프트웨어를 더 일찍 볼 수 있게 합니다. 그것은 엔지니어들이 약속하기 전에 더 많은 가설을 테스트할 수 있게 합니다. 그것은 배달을 쉽게 만들지 않지만, 제약 조건을 구현에서 의도, 검증, 판단, 피드백으로 옮깁니다.

그것은 어색한 것입니다: 많은 조직들은 20 년 동안 애그리지를 자칭하면서 애그리지가 제거해야 한다고 생각했던 조직적 반사기를 보존했습니다. 이제 AI 가 진정한 애그리지를 더 합리적으로 만들지만, 시스템은 여전히 반복이 희소하다고 가정하는 2 주 스프린트 약속, 전달 문서, 그리고 모든 것을 요청합니다.

그것은 다시 의식 절차 묘지입니다. 하지만 이제 채택 수준에서입니다. 루프는 조직이 루프가 배운 것을 대사할 것보다 더 빠르게 이동할 수 있습니다.

열린 바는 영원히 열리지 않을 것입니다

모든 것에 아래에 다른 압력이 쌓이고 있습니다. AI 사용은 더 가시적으로 측정될 것입니다. 현재 기업 감정의 "모두에게 접근 권한이 있고, 지출에 대해 너무 걱정하지 마라"는 것은 영원히 지속되지 않을 것입니다, 최소한 사람들이 익숙해 진 형태로 아닙니다. 모델 라우팅, 토큰 예산, 사용 조건부 가격, 추론 비용, 어떤 모델이 어떤 작업에 허용되는지에 대한 거버넌스: 모든 것이 회사들이 우연의 도움에서 진지한 에이전트 작업으로 이동함에 따라 더 명시적으로 될 것입니다.

이 글을 비용 패닉 (cost panic) 이야기로 만들지 않겠습니다. 이것이 "임대 지능" (rented intelligence) 을 생각할 때 가장 흥미롭지 않은 접근법일 것입니다. 질문은 추상적으로 토큰 소비를 최소화하는 것이 아니라, 소프트웨어 배포가 어떻게 키패드 입력을 최소화하는 것과 마찬가지로, 토큰 소비를 최소화하는 것 자체가 결코 목표는 아니었습니다.

하지만 청구서는 더 나은 질문을 강요합니다: 우리가 그 토큰을 사용함으로써 무엇이 변했는가?

바쁘게, 저는 여러분에게 요청드립니다. 풀 리퀘스트 (pull requests) 를 세지 마십시오. 오히려: 어떤 루프가 더 빨리 닫혔는가? 어떤 결정이 개선되었는가? 근본 원인 분석 (root-cause analyses) 이 더 날카로워졌는가? 어떤 리뷰가 더 많은 것을 발견했는가? 어떤 팀이 재사용 가능한 패턴을 학습했는가? 프로토타입이 약점을 명확하게 만들기 때문에 어떤 제품 아이디어가 더 일찍 폐기되었는가? AI 가 어디에서 학습을 창출했고, 어디에서는 단순히 더 많은 출력을 창출했는가?

토큰 대비 출력 (token-to-output) 은 새로운 옷을 입은 오래된 측정 반사입니다. 토큰 대비 학습 (token-to-learning) 이 중요한 것에 더 가깝습니다.

루프 지능 (Loop Intelligence) 이 누락된 피드백 경로입니다

나는 항상 3 가지 능력을 기업들이 혼란스러운 중간에 필요로 할 것입니다.

에이전트 운영 (Agent Operations): 어떤 에이전트와 AI 도구가 실행되고, 그들이 무엇을 시스템에 닿을 수 있고, 어떤 데이터를 볼 수 있으며, 어떤 행동이 승인 요구를 하고, 정체성, 감사, 권한, 런타임 가시성이 어디에 있는지. 이것이 제어 측 (control side) 이며, 이는 에이전트 작업이 결국 실제 시스템을 만지기 때문에 중요합니다.
루프 지능 (Loop Intelligence): AI 를 보조하거나 완전히 에이전트인 루프가 실제로 학습을 생성하는지, 어떤 루프는 열려 있는지, 어떤 루프는 감퇴하는지, 에이전트가 어디에서 이점을 창출하고, 어디에서는 사이드 퀘스트로 퍼져나가는지, 팀이 테스트, 컨텍스트, 직관을 부족하기 때문에 긴 감독에 갇혀 있는지를. 어떤 팀은 더 느슨한 위임에 준비되었는가?
에이전트 능력 (Agent Capabilities): 세 개의 거대한 에이전트가 모든 사람의 일을 할 수 있다고 pretending 하지 않고 조직 전체에 유용한 능력이 어떻게 분배되는지. AI 는 이제 하나의 애플리케이션 카테고리가 아니라 유동적인 기본 기술 (fluid base technology) 과 더 비슷하게 행동하기 시작했습니다. 그것은 기업 동물원 (enterprise zoo) 에서 HR 에이전트, 엔지니어링 에이전트, 판매 에이전트 각각이 어디에 있는 것처럼 한 "HR 에이전트", 하나의 "엔지니어링 에이전트", 하나의 "판매 에이전트"로 깔끔하게 들어맞지 않습니다. 더 나은 질문은 능력이 일이 일어나는 곳으로 어떻게 흐르는가입니다: 직원 하네스 (employee harnesses), 배경 에이전트, 제품 팀, 플랫폼 서비스, 로컬 스킬, MCP 서버, 평가 세트, 운영서, 예제, 도메인 특화 절차.

이것이 플랫폼 질문이 흥미로운 곳입니다. 이 능력을 누가 소유하는가? 하나의 팀에서 발견된 유용한 에이전트 기술이 다른 팀에 어떻게 활용 가능한지 되돌아가지 않고 죽은 템플릿으로 변하지 않는가? 개발자의 하네스를 제품 사람의 하네스, 지원 팀의 배경 에이전트, 또는 컴플라이언스 워크플로우와 다르게 풍부하게 하는 방법은 무엇인가? 어떤 능력은 팀 근처에 속하고, 어떤 능력은 플랫폼 레이어에 속하며, 어떤 능력은 로컬 컨텍스트가 전체 포인트이기 때문에 결코 일반화되어서는 안 되는가?

다른 것 하나를 가지고는 빠르게 이상해집니다. 루프 지능이 없는 에이전트 운영은 통제 관료주의가 됩니다. 에이전트 능력을 가진 루프 지능은 유용한 패턴을 발견하지만 이를 작업으로 다시 전달할 방법이 없는 분석 레이어가 됩니다. 에이전트 능력은 도구 퍼짐 (tool sprawl) 이며 더 나은 브랜딩이 있습니다. 우리는 모두 이제 아름다운 차트를 가질 수 있습니다, IT 부서를 대시보드를 구축하도록 요청할 필요가 없으니, 맞습니까?

제어 경로, 학습 경로, 능력 경로는 어디인가에서 만나야 합니다.

내부적으로는 '피드백 하니스 (feedback harness)'라고 부르고 있습니다. 고객에게는 이 용어가 마음에 들지 않습니다. 이는 너무도 아키텍처 다이어그램에서 온 듯한 느낌을 주며, 고객은 그 메커니즘이 우아하더라도 올해의 제품이라 할지라도 하니스를 구매하지는 않습니다. 그들은 신뢰와 더 나은 결정, 빠른 학습, 낭비 감소, 안전한 위임감을 구매합니다.

따라서 고객에게 더 유용한 개념은 '루프 인텔리전스 허브 (Loop Intelligence Hub)'일 수 있습니다.

피드백 하니스는 실제 작업 루프를 경청합니다: 과제, 프롬프트, 사양서, 검토, 시나리오, 수용 및 거절된 가설, 프로덕션 신호, 재가공, 인간 결정과 개입. 사람을 감시하는 것이 아니라 루프를 이해하기 위함입니다. 첫 번째 버전은 거대한 플랫폼일 필요는 없습니다. 몇 가지 실제 워크플로우를 선택하고 의도, 에이전트 작업, 검증, 인간 결정이 이미 흔적을 남긴 지점을 도구로 삼고, 루프가 왜 작동했는지 혹은 실패했는지 이해하기 위해 충분한 질적 피드백을 수집한 후 이를 반복 학습 아티팩트로 변환합니다.

루프 인텔리전스 허브는 이러한 신호를 조직이 행동에 취할 수 있는 것으로 전환합니다: 엔이블먼트 백로그, 역량 라디오, 투자 브리핑, 거버넌스 격차, 재사용 워크플로우, 교육 필요성, 평가 우선순위. 모든 것이 동일한 대시보드는 아닙니다. 관련성에 맞게 커스터마이징됩니다. 흥미로운 출력은 대시보드 그 자체는 아닙니다. 다음 결정입니다: 이 팀이 더 위임할 수 있는前に 더 나은 백압력을 필요로 함 (루프를 늘림), 이 제품 그룹은 좁은 컴포넌트 클래스에 대해 반복 가능한 다크팩토리 패턴을 가짐, 이 준수 워크플로우에는 거버넌드 도구 경계가 필요함, 이 기술은 5 개의 팀이 이를 나쁘게 재발명했기 때문에 플랫폼으로 이동해야 함.

하니스는 수집하고 허브는 조직이 결정하도록 돕습니다. 역량 레이어는 학습을 작업으로 다시 피드합니다.

이는 직원 감시로 변해서는 안 된다

모든 것이 직원 점수로 변하면 죽습니다.

사람들이 조직이 충분한 AI 를 사용했는지 측정하는지 믿으면, 그들은 신호를 조작할 것입니다. 모든 실험이 생산성 기대치가 된다고 믿으면, 그들은 실험을 숨길 것입니다. 최고의 워크플로우가 단순히 새로운 기본 작업량으로 될 것이라고 믿으면, 그들은 이를 사적으로 유지할 것입니다. 회사는 가능한 최악의 채택 버전 (가시적 준수와 불가시적 학습) 을 얻게 됩니다.

이러한 이유로 정직한 의도 (단순히 프레임링뿐만 아니라) 이 매우 중요합니다. 유용한 질문은 "AI 를 얼마나 사용하는가"가 아닌: 조직이 배울 수 있는 방식으로 AI 가 작업을 어떻게 변화시켰는가입니다? 어떤 루프가 더 건강해졌는가? 더 위임할 수 있는前に 어떤 팀이 더 나은 백압력을 필요로 하는가? 프로토타입이 실제 소프트웨어가 될 때 제품 팀은 다른 환경을 필요로 하는 곳은 어디인가?

이를 위한 정책을 작성할 수 있고, 아마도 그렇게 해야 합니다. 하지만 거버넌스와 학습은 사용에서만 진정한 것이 됩니다. 에이전트가 프로덕션 인접 작업에 닿고, 제품 담당자가 사양서를 대신 프로토타입을 만들고, 개발자가 근본 원인 분석을 위임하고, 토큰 소모량이 관리자가 답변을 원할 정도로 충분히 커지면, 조직은 학습 시스템을 구축했는지 아니면 많은 좌석을 구매했는지를 발견합니다.