사람들이 AI를 사용하고 있는가, 아니면 조직이 그로부터 배우고 있는가? 토큰을 써서 무엇이 달라졌고, 발견은 어떻게 개인에서 팀으로, 다시 조직의 역량으로 이동하는가를 묻는 글.
사람들이 AI를 사용하고 있는가, 아니면 조직이 그로부터 배우고 있는가? 우리가 그 토큰을 써서 무엇이 달라졌는가? 그리고 발견은 누가 개인에서 팀으로, 다시 조직의 역량으로 옮기는가?
2026년 05월 05일— 9분 읽기
Ethan Mollick은 조직에서의 AI 도입에 관해 한동안 글을 써오고 있다. Making AI Work: Leadership, Lab, and Crowd에서 그는 AI로 인한 개인의 생산성 향상이 자동으로 조직의 성과 향상으로 이어지지는 않는다고 지적한다. 사람들은 더 빨라질 수 있고, 더 잘 쓸 수 있으며, 더 많이 분석하고, 더 많이 자동화하거나, 조용히 자기 자신의 사이보그 버전이 될 수도 있다. 그런데 회사는 여전히 거의 아무것도 배우지 못할 수 있다.
지금 많은 회사가 GitHub Copilot 라이선스가 배포되고, ChatGPT Enterprise가 기술 스택 어딘가에 존재하며, Claude나 Gemini나 Cursor가 여기저기서 나타나고, 모든 팀에 공식 활성화 자료가 가정하는 수준보다 훨씬 앞서 있는 사람이 적어도 한 명쯤은 있는 단계에 들어서고 있다. 이 중 일부는 눈에 보이지만, 상당수는 보이지 않는다. 경영진은 라이선스 사용량을 본다(“작년에 Anthropic에 200만 유로를 냈는데 ROI는 어디 있지?”), 어쩌면 프롬프트 수를 보고, 어쩌면 설문을 보고, 어쩌면 운영위원회 발표 자료에 넣기에는 충분히 고무적으로 느껴지는 몇 가지 내부 PoC를 본다. 다른 회사들에서는 AI가 곧바로 IT로 넘어갔다가 그대로 죽어버리기도 했다.
내 생각에 누구나 지금이 일이 복잡해지는 단계라는 것을 알고 있다. 아니, 정말로 아주 복잡해지는 단계다. AI 도입의 “지저분한 중간 단계”는 AI 사용이 어디에나 존재하지만 불균등하고, 부분적으로 숨겨져 있으며, 비교하기 어렵고, 아직 조직 학습과 연결되지 않았을 때 시작된다.
AI 도입의 첫 번째 단계는 다른 엔터프라이즈 롤아웃처럼 보이기 때문에 대체로 편안하다. 좌석을 구매한다. 허용 가능한 사용 기준을 정의한다. 교육을 진행한다. 챔피언 네트워크를 만든다. Teams 채널에서 사용 사례를 공유해 달라고 요청하는데, 그 채널은 잠깐 활기를 띠었다가 이내 좋은 의도만 가득한 또 하나의 회사 다락방이 된다.
두 번째 단계는 훨씬 더 낯설다. 어떤 팀은 Copilot을 자동완성 정도로만 쓰고 거기서 끝낸다. 다른 팀은 Claude Code를 테스트, 리뷰, 지속적인 조향과 함께 촘촘한 루프 속에서 돌린다. 한 제품 책임자는 Figma에서 화면 목업을 만드는 대신 실제 소프트웨어를 갑자기 프로토타이핑하기 시작한다. 한 시니어 엔지니어는 근본 원인 분석을 에이전트에게 위임하고 한 시간도 안 되어 타당한 해답을 들고 돌아온다. AI가 없었다면 이 일은 2주가 걸렸을 것이다. 한 주니어는 매끈한 코드를 만들어내지만 어떤 아키텍처 가정이 시스템 안으로 슬그머니 들어왔는지는 전혀 모른다. 한 지원팀은 반복되는 티켓을 조용히 워크플로 자동화로 바꿔버리는데, 그들은 정확히 어디서 일이 아픈지 알고 있었고 Center of Excellence에서는 누구도 올바른 질문을 한 적이 없었기 때문이다.
이 모든 일은 같은 회사 안에서 동시에 일어날 수 있다. 바로 그것이 지저분한 중간 단계를 지저분하게 만드는 이유다. 도입의 단위가 더 이상 조직이 아니고, 어쩌면 팀조차 아닐 수 있기 때문이다. 그것은 일 안에 들어 있는 루프다!
Mollick의 Leadership, Lab, and Crowd 프레임은 여기서 유용하다. Leadership은 방향과 허용을 제공하고, Crowd는 실제 일을 하기 때문에 사용 사례를 발견한다. Lab은 그런 발견을 공유 가능한 관행, 도구, 벤치마크, 새로운 시스템으로 바꾼다. 하지만 내가 계속 막히는 지점은 에이전트형 엔지니어링에서도 반복해서 나타나는 바로 그 부분이다. 학습은 실제로 어떻게 이동하는가?
대부분의 회사는 자신들이 이미 가지고 있는 장치를 통해 AI 도입을 처리하려 할 것이다. 실천 공동체, 브라운백 세션, 챔피언 네트워크, 활성화 자료, 오피스 아워, 월간 데모, 설문, 어쩌면 대시보드까지. 그럴 만하다. 나도 해봤고, 당신도 해봤다. 그중 일부는 도움이 된다. 특히 아직 실험할 허가 자체가 필요한 조직에서는 더 그렇다.
하지만 흥미로운 AI 작업은 다음 실천 공동체 회의를 기다리지 않는다. 그것은 코드 리뷰, 영업 제안서, 연구 과제, 제품 프로토타입, 운영 사고, 테스트 전략, 컴플라이언스 질문 안에서 나타난다. 또는 누군가가 특정 종류의 제품 컴포넌트에 대해서는 거의 암흑 공장에 가까운 무언가를 세울 수 있다는 사실을 알아차리는 순간에도 나타난다. 의도를 적고, 에이전트를 매우 느슨한 루프에서 돌리게 하고, 궤도를 유지할 만큼 충분한 역압을 가하고, 강한 시나리오에 비추어 결과를 평가하고, 의도를 다듬고, 그렇게 반복해서 높은 품질의 결과를 얻는다. 그 이야기가 베스트 프랙티스 슬라이드가 될 만큼 정리될 때쯤이면, 중요한 학습은 이미 날카로움을 잃은 경우가 많다. 그것을 유용하게 만든 것은 마찰이었다. 빠져 있던 맥락, 실패한 테스트, 이상한 API 동작, 에이전트가 말도 안 되는 방향으로 퍼져나가서 누군가가 다시 끌어와야 했던 순간이 바로 그것이었다.
나는 이것을 탄성 루프와 같은 렌즈로 생각해왔다. AI 협업은 하나의 모드가 아니다! 그것은 촘촘하고 동기적인 공동 운전에서 더 느슨하고 비동기적인 위임까지 늘어난다. 도입의 질문은 단순히 “사람들이 AI를 쓰고 있는가?”가 아니다. 팀이 어떤 루프 크기를 써야 하는지, 어디에 저항이 필요한지, 어떤 산출물이 루프를 지나도 살아남아야 하는지, 그리고 그 산출물이 어떻게 조직이 배울 수 있는 무언가가 되는지를 알고 있는가의 문제다.
그것은 도구 사용량이나 콩 세기(토큰 세기)보다 훨씬 더 어려운 질문이다.
나는 주장한 바 있다. 현대 소프트웨어 프로세스의 상당 부분은 인간의 반복이 예전에는 비쌌기 때문에 존재한다고. 스프린트 계획, 추정, 스탠드업, 사용자 스토리, 티켓 그루밍, 핸드오프, 조정과 위험 감소를 둘러싼 모든 의식 말이다. 제약 조건을 고려하면 합리적이었다. 한 번의 반복이 며칠 또는 몇 주가 걸린다면, 사람들이 그것을 너무 많이 낭비하지 않도록 막는 구조가 필요하다.
하지만 에이전트형 엔지니어링은 경제성을 바꾼다. 그것은 더 많은 선택지를 현실화 가능하게 만든다! 팀이 의도에서 프로토타입, 평가로 훨씬 더 빨리 이동할 수 있게 한다. 제품 담당자가 더 이른 시점에 작동하는 소프트웨어를 볼 수 있게 한다. 엔지니어가 커밋하기 전에 더 많은 가설을 시험할 수 있게 한다. 이것이 전달을 마법처럼 쉽게 만들어주지는 않지만, 제약을 구현에서 의도, 검증, 판단, 피드백 쪽으로 이동시킨다.
어색한 점은 많은 조직이 지난 20년 동안 스스로를 애자일하다고 불러왔으면서도, 애자일이 원래 제거하려 했던 조직적 반사작용은 그대로 보존해왔다는 것이다. 이제 AI는 진짜 민첩성을 더 그럴듯하게 만들고 있는데, 시스템은 여전히 2주짜리 스프린트 약속, 핸드오프 문서, 그리고 반복이 희소하다고 가정하는 온갖 것을 요구한다.
이것은 다시 의식의 공동묘지이지만, 이제는 도입 수준에서 그렇다. 루프는 조직이 루프가 배운 것을 소화하는 속도보다 더 빨리 움직일 수 있다.
이 모든 것 아래에는 또 다른 압력이 쌓이고 있다. AI 사용량은 더 눈에 띄게 계량될 것이다. 지금의 엔터프라이즈 분위기, 즉 “모두에게 접근 권한이 있으니 비용은 너무 걱정하지 마라”라는 감각은 영원히 유지되지 않을 것이고, 적어도 사람들이 익숙해지고 있는 형태로는 그렇지 않을 것이다. 모델 라우팅, 토큰 예산, 사용량 연동 가격 책정, 추론 비용, 어떤 작업에 어떤 모델이 허용되는지를 둘러싼 거버넌스, 이 모든 것은 기업이 가벼운 보조에서 본격적인 에이전트형 작업으로 이동하면서 더 명시적이 될 것이다.
이것을 비용 공포 이야기로 만들고 싶지는 않다. “임대한 지능”을 생각하는 가장 재미없는 방식이기 때문이다. 질문은 추상적으로 토큰 지출을 최소화하는 방법이 아니다. 소프트웨어 전달의 질문이 결코 키 입력 수를 최소화하는 방법이 아니었던 것과 마찬가지다.
하지만 청구서는 더 나은 질문을 강제할 것이다. 우리가 그 토큰을 써서 무엇이 달라졌는가?
제발, 부탁이니 pull request를 세지 말자. 더 나은 질문은 이렇다. 어떤 루프가 더 빨리 닫혔는가? 어떤 결정이 더 좋아졌는가? 어떤 근본 원인 분석이 더 날카로워졌는가? 어떤 리뷰가 더 많이 잡아냈는가? 어떤 팀이 재사용 가능한 패턴을 배웠는가? 어떤 제품 아이디어는 프로토타입이 약점을 분명하게 드러내서 더 일찍 폐기되었는가? 어디에서 AI가 학습을 만들어냈고, 어디에서는 그저 더 많은 산출물만 만들었는가?
토큰 대 산출물은 옛 측정 반사작용이 새 옷을 입은 것에 불과하다. 토큰 대 학습이야말로 중요한 것에 더 가깝다.
나는 계속해서 회사가 이 지저분한 중간 단계에서 필요로 하게 될 세 가지 역량으로 돌아오게 된다.
바로 여기서 플랫폼에 대한 질문이 흥미로워진다. 누가 이런 역량을 소유하는가? 한 팀에서 발견된 유용한 에이전트 스킬은 어떻게 죽은 템플릿이 되지 않으면서 다른 팀에게도 제공될 수 있는가? 개발자의 하니스는 제품 담당자의 하니스, 지원팀의 백그라운드 에이전트, 또는 컴플라이언스 워크플로와 어떻게 다르게 풍부해져야 하는가? 어떤 역량은 팀 가까이에 있어야 하고, 어떤 역량은 플랫폼 계층에 속하며, 어떤 역량은 로컬 맥락 자체가 전부이기 때문에 절대로 일반화되어서는 안 되는가?
이 셋 중 하나가 다른 것 없이 존재하면 금방 이상해진다. Agent Operations만 있고 Loop Intelligence가 없으면 통제 관료제가 된다. Loop Intelligence만 있고 Agent Capabilities가 없으면 유용한 패턴을 발견하지만 그것을 다시 작업으로 되돌려 보낼 방법이 없는 분석 계층이 된다. Operations와 Loop Intelligence 없이 Agent Capabilities만 있으면 브랜딩만 더 나아진 도구 난립이 된다. 이제는 우리 모두 멋진 차트를 가질 수 있으니, 더 이상 IT 부서에 대시보드를 만들어 달라고 부탁할 필요는 없지 않은가?
통제 경로, 학습 경로, 역량 경로는 어딘가에서 만나야 한다.
내가 내부적으로 그것을 피드백 하니스라고 불러온 이유가 바로 여기에 있다. 고객에게는 이 용어가 마음에 드는지 잘 모르겠다. 너무 아키텍처 다이어그램에나 나올 법한 무언가처럼 들리고, 고객은 메커니즘이 우아하다고 해서 하니스를 사지는 않기 때문이다. 비록 그것이 올해의 물건이라 해도 말이다. 고객이 사는 것은 자신감, 더 나은 결정, 더 빠른 학습, 더 적은 낭비, 더 안전한 위임이다.
그래서 고객을 향한 더 유용한 개념은 아마도 Loop Intelligence Hub일 것이다.
피드백 하니스는 실제 작업 루프에 귀를 기울인다. 과제, 프롬프트, 명세, 리뷰, 시나리오, 채택된 가설과 거부된 가설, 운영 신호, 재작업, 인간의 결정과 개입 같은 것들 말이다. 사람을 감시하기 위해서가 아니라, 루프를 이해하기 위해서다. 첫 번째 버전이 거대한 플랫폼일 필요는 없다. 몇 가지 실제 워크플로를 고르고, 의도, 에이전트 작업, 검증, 인간의 결정이 이미 흔적을 남기고 있는 지점을 계측하고, 루프가 왜 작동했거나 실패했는지를 이해할 만큼 충분한 질적 피드백을 수집하고, 그것을 반복 가능한 학습 산출물로 바꾸면 된다.
Loop Intelligence Hub는 그런 신호를 조직이 행동으로 옮길 수 있는 무언가로 바꾼다. 활성화 백로그, 역량 레이더, 투자 브리프, 거버넌스 공백, 재사용 가능한 워크플로, 교육 필요, 평가 우선순위 같은 것이다. 모두에게 맞는 단일 대시보드는 아니다. 관련 있는 것에 맞게 조정된다. 어차피 흥미로운 산출물은 대시보드가 아니다. 그 뒤따르는 결정이다. 이 팀은 더 많은 위임을 하기 전에 더 나은 역압이 필요하다(루프를 늘려야 한다), 이 제품 그룹은 좁은 범주의 컴포넌트에 대해 반복 가능한 암흑 공장 패턴을 갖고 있다, 이 컴플라이언스 워크플로는 통제된 도구 경계가 필요하다, 이 스킬은 다섯 팀이 형편없이 재발명했으므로 플랫폼으로 옮겨야 한다.
하니스는 수집하고 허브는 조직이 결정하도록 돕는다. 역량 계층은 그 학습을 다시 작업 속으로 되돌려 보낸다.
이 모든 것은 직원 점수화로 바뀌는 순간 끝장난다.
사람들이 조직이 자신이 AI를 충분히 사용했는지를 측정한다고 믿게 되면, 그들은 신호를 조작할 것이다. 모든 실험이 생산성 기대치가 된다고 믿게 되면, 그들은 실험을 숨길 것이다. 자신들의 최고의 워크플로가 단지 새로운 기본 업무량이 될 뿐이라고 믿게 되면, 그들은 그것을 비공개로 둘 것이다. 회사는 도입의 최악의 버전을 얻게 된다. 눈에 보이는 준수와 눈에 보이지 않는 학습 말이다.
그래서 여기서는 솔직한 의도(그저 포장만이 아니라)가 정말 중요하다. 유용한 질문은 “누가 AI를 충분히 사용하는가?”가 될 수 없다. 대신 이런 질문이어야 한다. AI가 일을 조직이 배울 수 있는 방식으로 어디에서 바꾸었는가? 어떤 루프가 더 건강해졌는가? 어떤 팀은 더 많은 위임을 하기 전에 더 나은 역압이 필요한가? 어떤 제품 팀은 프로토타입이 실제 소프트웨어가 되고 있기 때문에 다른 환경이 필요한가?
이것에 대한 정책을 쓸 수 있고, 아마 그래야 할 것이다. 하지만 거버넌스도 학습과 마찬가지로 사용을 통해서만 현실이 된다. 에이전트가 운영에 인접한 작업을 건드리기 시작하면, 제품 담당자가 명세 대신 프로토타이핑을 시작하면, 개발자가 근본 원인 분석을 위임하기 시작하면, 토큰 지출이 경영진이 답을 원할 만큼 커지면, 그때 조직은 자신이 학습 시스템을 구축했는지 아니면 그냥 많은 좌석만 산 것인지 알게 된다.
AI 도입의 첫 단계는 접근에 관한 것이었다. 누가 도구를 얻는가, 누가 허가를 가지는가, 누가 계약을 협상하는가, 누가 구매 요청 티켓을 올리지 않고도 최신 모델을 시험해볼 수 있는가 같은 것들 말이다. 그 단계는 여전히 중요하지만, 오래 차별점이 되지는 않을 것이다. 최첨단 지능에 대한 접근은 임대할 수 있다. 운영 통제와 조직 학습은 같은 방식으로 임대할 수 없다.
다음 경쟁 우위는 학습 속도다.
누가 진짜 패턴을 더 빨리 발견하는가? 누가 발견을 개인에서 팀으로, 다시 조직의 역량으로 옮기는가? 누가 에이전트형 루프에 역압을 심어 에이전트가 멋대로 퍼져나가지 못하게 하는가? 누가 유용한 에이전트 역량을 모두에게 맞지 않는 거대한 엔터프라이즈 에이전트로 만들어버리지 않으면서 분배하는가? 누가 마침내 에이전트형 엔지니어링을 이용해 애자일을 진짜로 만들고, 그저 오래된 의식 위에 AI를 덧씌우는 데 그치지 않는가?
아직 아무도 이걸 완전히 해결하지 못했다. 물론 나도 그렇지 않다. 나는 몇 달째 탄성 루프를 반복적으로 다듬고 있고, 모든 고객 대화, 모든 내부 토론, 실제 작업에서 나온 모든 이상한 사례가 그것을 또다시 바꿔놓는다. 바로 그게 핵심이다! 우리는 벤더, 컨설턴트, 또는 AI 연구소가 내놓는 결정판 도입 플레이북을 기다린다고 해서 이 변화를 이해하게 되지 않을 것이다. 우리는 작업을 계측하고, 지저분한 학습을 공유하고, 다른 사람들이 그 허점을 찌르게 하고, 열린 상태에서 반복함으로써 그것을 이해하게 될 것이다.
Robert Glaser
Ghost 제공
매주 혁신을 맥락 속에서 정리합니다: 중요한 돌파구, 실용적 적용, 관점을 담은 기술적 평가.
구독 이메일이 전송되었습니다
