매주 기업들이 AI 이니셔티브(AI initiative)를 발표합니다. 그리고 매주 또 다른 기업들이 조용히 사라집니다. 일반적인 설명은 기술이 아직 준비되지 않았다는 것입니다.

저는 그것을 믿지 않습니다. 모델은 대부분의 조직이 흡수할 수 있는 속도보다 더 빠르게 발전합니다. 엔지니어링 팀은 예전에 몇 주가 걸렸던 일을 몇 시간 만에 프로토타입(prototype)으로 만들어냅니다. 인프라(infrastructure)는 성숙해졌고 툴링(tooling)은 풍부합니다. 그럼에도 프로젝트는 여전히 실패합니다.

프로젝트가 실패하는 데에는 AI와 전혀 상관없는 이유가 있으며, 이를 정확히 이해하는 것은 가치가 있습니다. 왜냐하면 이 이유는 당신이 이 글을 읽을 때 사용되는 어떤 모델보다 더 오래 지속될 것이기 때문입니다.

이 패턴은 AI보다 오래되었습니다

우리는 전에도 이런 상황을 겪은 적이 있습니다. 클라이언트-서버(Client-server), 웹(Web), ERP, 모바일(Mobile), 클라우드(Cloud). 각각은 동일한 이야기와 함께 등장했습니다. 파일럿(pilot)의 물결, 열광의 물결, 그리고 소수의 기업만이 선두로 치고 나가는 동안 생산(production) 단계에 도달하지 못한 채 길게 늘어진 이니셔티브들의 잔해 말입니다.

공통된 실마리는 기술의 성숙도가 아니었습니다. 그것은 바로 이것이었습니다: 구축(building) 비용이 결정(deciding) 비용보다 더 빠르게 하락할 때, 조직이 병목(bottleneck)이 된다는 것입니다.

이것이 전체 논지입니다. AI는 우리가 목격한 것 중 이 현상의 가장 극단적인 버전일 뿐입니다. 구축 비용의 하락 폭이 매우 가파르기 때문입니다. 과거에 엔지니어링 노력의 4분의 1을 정당화했을 역량이 이제는 오후 한나절이면 충분한 비용이 듭니다. 반면, 자금 승인(funding approval)은 2015년에 걸렸던 것과 똑같이 6주가 소요됩니다.

AI가 그 격차를 만든 것이 아닙니다. AI는 그 격차를 무시하는 것을 불가능하게 만들었을 뿐입니다.

왜 아무도 '예'라고 말하지 않는가

모든 이니셔티브는 결국 자금, 데이터 접근 권한, 조달(procurement), 또는 생산 배포(production deployment)를 승인해야 하는 누군가에게 도달합니다. 보통 그곳에서 추진력이 죽으며, 개인의 소심함을 탓하고 싶은 유혹에 빠지기도 합니다. 하지만 그것은 잘못된 진단입니다.

솔직한 설명은 인센티브(incentives)가 비대칭적이라는 것입니다. 만약 당신이 무언가를 승인했는데 그것이 실패한다면, 그 실패에는 당신의 이름이 붙습니다. 하지만 만약 성공했을 수도 있는 무언가를 거절한다면, 당신에게는 아무 일도 일어나지 않습니다. 반사실(counterfactual)은 보이지 않으며, 발생하지 않은 비용에 대해 누구도 책임을 지지 않기 때문입니다.

그러한 조건 하에서, "아직은 아니다"라는 태도는 개인에게는 합리적인 선택이지만 기업에게는 서서히 다가오는 재앙입니다. 격려를 하거나 대담해지자는 전사 회의(all-hands)를 한 번 더 연다고 해서 이 문제를 해결할 수는 없습니다. 이 문제는 결정에 따르는 비용을 바꿈으로써 해결해야 하며, 이를 위한 레버(lever)는 단 두 가지뿐입니다.

첫째, 승인하는 것이 커리어에 결정적인 영향을 미치지 않을 정도로 베팅 규모를 줄이십시오. 아무도 승인을 받을 필요가 없는 지출 및 영향 범위(blast-radius)의 상한선을 설정하십시오. 이는 문서로 명시되어야 하며, 설정한 사람이 직접 방어할 수 있는 실제적인 숫자여야 합니다. 대부분의 승인 요청은 애초에 승인을 요청할 만큼 크지도 않은 일들에 대해 허락을 구하는 과정에서 발생합니다.

둘째, 지연을 가시화하십시오. 모든 보류 중인 결정에는 세 가지 항목을 부여합니다: 무엇을 요청하는지, 답변의 책임자(owner)는 누구인지, 그리고 요청된 날짜입니다. 이 목록을 리더십 팀이 매주 확인할 수 있는 곳에 두십시오. 이는 누군가를 망신 주려는 것이 아닙니다. 아무도 그 상황을 볼 수 없기 때문에 거절에 따른 비용이 발생하지 않는 상황을 끝내려는 것입니다.

조직들은 지난 10년 동안 엔지니어링을 가속화하는 데 시간을 보냈습니다. 하지만 경영(management)을 가속화하기 위해 무언가를 한 조직은 거의 없습니다.

승리의 모습이 무엇인지 아무도 합의하지 않았다

두 번째 살인자는 첫 번째보다 조용하며, 제 경험상 더 흔하게 발생합니다.

파일럿(pilot) 프로젝트가 구축됩니다. 그 프로젝트는 그럴듯한 결과물을 내놓고 데모가 잘 된다는 점에서 작동하는 것처럼 보입니다. 그러다 누군가 이 프로젝트에 제대로 된 자금을 지원해야 하는지 묻게 되면, 성공이 무엇을 의미하는지 아무도 기록해 두지 않았고, 자동화하기 전에 프로세스를 측정한 적도 없으며, 비교할 기준점(baseline)조차 없다는 사실이 드러납니다. 팀은 증거를 바탕으로 논쟁해야 할 바로 그 순간에, 일화(anecdote)와 느낌(vibes)에 의존해 논쟁하는 처지에 놓이게 됩니다.

이것은 모델링(modelling)의 문제가 아닙니다. 이는 규율(discipline)의 문제이며, 전적으로 예방 가능합니다. 파일럿 프로젝트를 시작하기 전에 누군가는 다음 세 가지 질문에 답할 수 있어야 합니다: 무엇이 구체적으로 더 빨라지거나, 저렴해지거나, 좋아지는가; 우리가 그것을 어떻게 알 수 있는가; 그리고 어떤 수치가 나타나면 우리가 중단할 것인가. 시작 단계에서 단 15분만 투자하면 됩니다. 이것이 성공적으로 졸업하는 파일럿과, 아무도 방어할 수 없어 조용히 자금 지원이 끊기는 파일럿 사이의 차이를 만듭니다.

결과(Outcomes)보다 소유권(Ownership)이 더 중요해지는 순간

여기에 가장 새롭고, 제가 가장 흥게로 느끼는 문제가 있습니다.

엔지니어링 분야 외부의 사람들도 이제 스스로 진정으로 정교한 것들을 만들어낼 수 있습니다. 이는 좋은 일입니다. 이 기술이 주는 진정한 선물 중 하나죠. 하지만 그러한 결과물들이 제품(Products)으로 전환되어야 할 때 상황은 복잡해집니다.

작동하는 프로토타입(Prototype)은 누군가의 개인 프로젝트가 되는 경향이 있습니다. 종종 그들에게 가장 자랑스러운 작업물이 되며, 때로는 그들이 수년 동안 만든 것 중 가장 눈에 띄는 결과물이 되기도 합니다. 엔지니어링 팀이 적절한 아키텍처 (Architecture), 보안 (Security), 테스트 (Testing), 그리고 관찰 가능성 (Observability)을 갖추어 이를 재구축하자고 제안하면, 대화는 더 이상 기술적인 영역에 머물지 않습니다. 질문은 조용히 _회사를 위해 무엇이 최선인가_에서 _이것의 주인은 누구인가_로 옮겨갑니다.

기술적인 부분은 어려운 경우가 거의 없습니다. 일단 결과(Outcome)가 증명되면, 이를 제대로 재현하는 것은 대개 간단합니다. 어려운 부분은 내려놓는 것입니다. 조직들은 해결되지 않은 단 하나의 감정 때문에 얼마나 많은 인도 능력 (Delivery capacity)을 상실하는지 지속적으로 과소평가합니다.

해결책은 사람들에게 자존심(Ego)에 대해 훈계하는 것이 아닙니다. 무언가를 넘겨주는 과정이 몰수(Confiscation)가 아닌 승진(Promotion)처럼 느껴지게 만드는 것입니다. 최초 제작자의 이름을 공개적이고 영구적으로 명시하세요. 엔지니어링 팀이 구축을 맡는 동안, 그들을 제품의 소유자나 주제 전문가 (Subject-matter lead)로서 제품에 계속 연결해 두세요. 재구축 과정을 명확한 경로가 정의된 공식적인 졸업(Graduation)으로 만들어, 아무도 이에 당황하지 않게 하세요. 유용한 것을 만든 유일한 보상이 그것을 빼앗기는 것이라면, 사람들은 자신이 만든 것을 당신에게 보여주지 않는 법을 배울 것이며, 당신은 애초에 프로토타입을 가능하게 했던 바로 그 요소를 잃게 될 것입니다.

기다리는 것이 실제로 옳을 때

여기서 주의를 기울이고 싶습니다. 제가 하고 있는 주장은 게으른 버전의 논리가 존재하며, 저는 그런 식의 주장을 하고 싶지 않기 때문입니다.

때로는 "기다려보자"는 판단이 옳을 때가 있습니다. 만약 아직 따라잡지 못한 규제 하에서 운영 중이거나, 실패 모드 (failure mode)가 데이터 유출 또는 고객에게 대규모로 잘못된 답변을 제공하는 것이거나, 정직한 기대 가치 (expected value)가 음수라면 — 진행하지 않는 것은 회피가 아니라 하나의 결정입니다. 거버넌스 (Governance)는 관료주의 (bureaucracy)와는 다릅니다. 거버넌스의 일부는 누군가가 한 번 피해를 입었고 그 비용이 막대했기 때문에 존재합니다.

차이점은 기다림이 이성적인지(reasoned) 아니면 반사적인지(reflexive)에 있습니다. 이성적인 기다림은 기다리고 있는 구체적인 조건과 그것을 재검토할 날짜를 명시합니다. 반사적인 기다림은 아무것도 명시하지 않고, 아무것도 재검토하지 않으며, 스스로를 신중함이라 부르면서 무한히 반복합니다.

테스트는 간단합니다. 한 달 동안 멈춰 있는 모든 결정에 대해 다음과 같이 적용해 보십시오: 이것이 '예(yes)'가 되기 위해 구체적으로 무엇이 사실이어야 하며, 누가 이를 확인하고 있는가? 만약 아무도 대답할 수 없다면, 그것은 주의 깊은 행동이 아닙니다. 그것은 아무도 책임을 지지 않은 채 내려진 결정입니다.

테스트가 실패했을 때, 상부에 보고하거나 불평하지 마십시오. 직접 답을 작성하십시오. 한 페이지 분량으로: 이것을 '예'로 만들 조건, 재검토를 제안하는 날짜, 그리고 귀하의 조직이 실제로 중요하게 여기는 단위로 계산한 지연 비용을 적으십시오. 이를 결정권을 가진 사람에게 보내고 수정을 요청하십시오. 그들이 귀하의 버전을 받아들여 업무의 병목을 해결해주거나, 아니면 서면으로 거절할 것입니다. 거절 또한 하나의 답변이며, 침묵보다 훨씬 더 유용한 답변입니다. 정체된 대부분의 이니셔티브 (initiatives)는 거절당한 적이 없습니다. 단지 거절할 수 있을 만큼 구체화되지 않았을 뿐입니다.

지속 가능한 조직이 하는 일

앞서 나가는 기업들은 더 나은 모델을 구매하는 기업들이 아닙니다. 모든 이가 거의 동일한 분기 내에, 거의 동일한 가격으로 동일한 모델에 접근할 수 있습니다. 모델에 대한 접근성은 결코 차별화 요소가 된 적이 없으며, 앞으로도 그럴 것입니다.

대신 그들이 가진 것은 지루하고, 구체적이며, 지속 가능한 메커니즘 (mechanisms)입니다:

고정된 의사결정 마감 기한 (A standing decision deadline). 자금 지원, 접근 권한, 또는 배포에 대한 모든 요청은 정해진 기간 내에 답변을 받습니다. 기간을 하나 정해서 공표하십시오. 반드시 '예'라는 답변일 필요는 없습니다. 답변을 받는 것이 중요합니다. 기간이 지났음에도 답변되지 않은 모든 사항은 요청자가 직접 상급자에게 보고할 필요 없이 자동으로 다음 단계로 에스컬레이션 (escalate) 됩니다. 마지막 구절이 바로 메커니즘의 핵심입니다. 이 구절이 없다면 그것은 단지 희망 사항일 뿐입니다.

사전 승인된 샌드박스 (A pre-authorized sandbox). 지정된 예산, 지정된 데이터 세트, 그리고 명문화된 가드레일 (guardrails)을 설정하여, 그 안에서는 누구도 무엇인가를 하기 위해 허가를 구할 필요가 없도록 합니다. 상급자 한 명이 이를 소유하고 방어합니다. 누군가 새로운 시도를 하고 싶어 할 때마다 검토하는 대신, 일 년에 두 번 상한선을 검토하십시오.

실험과 운영의 분리 (A separation between experimentation and production). 두 가지 표준 세트를 각각 한 페이지씩 작성하십시오. 프로토타입 (prototype)은 운영 수준의 기준을 적용받아서는 안 되며, 운영 환경이 프로토타입의 기준을 물려받아서도 안 됩니다. "이 정도면 충분한가"에 대한 대부분의 논쟁은 사실 어떤 페이지의 기준을 적용할지에 대한 논쟁입니다.

명문화된 졸업 경로 (A written graduation path). 어떤 파일럿 (pilot) 프로젝트가 시작되기 전에, 그것이 성공했을 때 어떤 일이 일어날지 모두가 알고 있어야 합니다. 누가 소유권을 갖는지, 무엇을 다시 구축해야 하는지, 원작자는 무엇을 유지하는지, 그리고 인수인계가 대략 얼마나 걸리는지를 정의하십시오. 성공의 한복판에서 이러한 사항들을 협상해서는 안 됩니다.

미소유 항목에 대한 기본 소유자 (A default owner for anything unclaimed). 정해진 기간 내에 아무도 맡지 않은 이니셔티브 (initiative)를 승계할 사람을 지정하십시오. 팀이나 위원회가 아닌, '개인'을 지정해야 합니다. 대부분의 이니셔티브는 반대에 부딪혀 죽는 것이 아닙니다. 그것이 누구의 업무인지에 대한 모호함 때문에 죽습니다. 기본 소유자는 그 모호함을 실행 또는 중단에 대한 명시적인 결정으로 전환합니다.

이 중 그 어느 것도 당신이 어떤 모델을 사용하는지와는 무관합니다. 바로 그렇기 때문에 이 방식이 지속 가능한 것입니다.

만약 이 중 당신이 바꿀 수 있는 것이 없다면

이 글을 읽는 대부분의 사람들은 의사결정 마감 기한을 설치하거나 샌드박스를 승인할 권한이 없을 것입니다. 그렇다고 해서 당신에게 움직일 수 있는 수단이 없는 것은 아닙니다. 단지 사용할 수 있는 수단이 달라질 뿐입니다.

이미 가지고 있는 권한 안에서 구축하십시오. 모든 역할에는 누구의 승인도 필요하지 않은 경계가 있으며, 대부분의 사람들은 자신이 누릴 수 있는 권한보다 훨씬 적은 부분만을 사용합니다. 가치를 먼저 입증하십시오. 그다음, 실제로 작동하는 무언가를 손에 쥔 상태에서 요청하십시오.

자동화하기 전에 측정하십시오. 기존 프로세스가 여전히 작동하고 있을 때 기준점 (baseline)을 포착하십시오. 일단 프로세스를 교체하고 나면 비교 대상이 사라지며, 당신의 주장은 단순한 일화 (anecdote)가 되어버리기 때문입니다. 이는 단 한 시간의 비용이 들지만, 개별 기여자 (individual contributor)가 할 수 있는 가장 레버리지 (leverage)가 높은 일입니다.

앞서 언급한 것처럼, 지연된 결정들을 날짜가 포함된 서면 제안서로 전환하십시오. 이를 일관되게 수행하면 당신은 추진력을 가진 사람이 될 것이며, 이는 그 자체로 하나의 권위가 됩니다.

공로를 공격적으로 나누십시오. 만약 다른 사람의 프로토타입 (prototype)이 프로덕션 (production) 단계에 도달하기를 원한다면, 최초 제안자를 돋보이게 만든 사람이 되십시오. 공로를 가로채는 평판을 가진 사람에게는 아무도 업무를 넘겨주지 않습니다.

그리고 기다림이 어떤 비용을 치르게 했는지 기록하십시오. 어떤 실험이 연기되었는지, 그리고 그 후에 어떤 일이 일어났는지 말입니다. 이는 불만을 토로하기 위함이 아닙니다. 누군가가 마침내 '왜 경쟁사가 먼저 도착했는가?'라고 물을 때 제시할 증거로서 기록하는 것입니다.

진짜 격차

사람들은 AI가 비즈니스를 변화시킬 것인지 묻습니다. 이미 변화는 시작되었습니다. 다만 그 변화가 균등하게 배분되지 않았을 뿐이며, 가장 좋은 기술을 가진 사람에 따라 배분되는 것도 아닙니다.

남은 질문은 기술이 능력이 있느냐가 아닙니다. 조직이 의사결정을 내리고, 소유권 (ownership)을 할당하며, 결과를 측정하고, 무언가를 내려놓는 방식을 바꿀 의지가 있느냐 하는 것입니다.

AI는 기술적 격차를 드러내는 것이 아닙니다. AI는 관리의 격차 (management gap)를 드러내고 있습니다. 이를 조기에 인식하는 기업들이 승리하는 이유는 더 나은 AI를 가졌기 때문이 아닙니다. 그들이 더 나은 조직이 되었기 때문입니다. 그리고 그 우위는 개별 모델의 출시가 더 이상 중요하지 않게 된 이후에도 오랫동안 복리로 쌓여갈 것입니다.