저는 하나의 패턴이라고 부를 수 있을 만큼 반복적으로 발생하는 현상에 대해 설명하고자 합니다. 한 조직이 철저한 AI 조달 프로세스를 거칩니다. 그들은 데모(demo)를 보고, 레퍼런스 콜(reference calls)을 진행하며, 계약 조건을 협상합니다. 그리고 서명하고, 배포합니다. 하지만 6개월에서 12개월이 지나면, 제품을 사용하는 경험은 평가 단계에서 예상했던 것과 의미 있는 수준으로 달라져 있습니다.

이것은 사기가 아닙니다. 벤더들이 어떤 직접적인 의미에서 거짓말을 하는 것도 아닙니다. 평가된 내용과 실제 배포된 내용 사이의 간극은 개별적인 허위 진술의 연속이 아니라, 기업의 AI 조달 방식이 작동하는 구조적 특징입니다.

이 간극이 왜 존재하는지 이해하는 것은 그로 인해 좌절하는 것보다 더 유용합니다. 왜냐하면 이를 이해하면 현재 대부분의 조달 프로세스가 수행하지 못하는 방식으로 무엇을 살펴보고 무엇을 검증해야 하는지 알 수 있기 때문입니다.

데모 환경은 운영 환경(production environment)이 아니다

기업용 AI 벤더들은 데모 환경에 상당한 엔지니어링 노력을 기울입니다. 데이터는 큐레이션(curated)되어 있습니다. 예외 사례(edge cases)는 처리되어 있습니다. 응답 시간은 데모가 실행되는 하드웨어에 최적화되어 있습니다. 쿼리(queries)는 팀이 이전에 본 적이 있고 좋은 결과를 낸다는 것을 알고 있는 것들입니다.

이 중 어느 것도 그 자체로 기만적인 것은 아닙니다. 문제는 구매자들이 데모 성능을 예상되는 운영 성능으로 변환할 프레임워크를 갖추지 못한 경우가 많다는 점입니다. 그들은 최적의 조건에서 진정으로 달성 가능한 결과를 보고, 그 결과를 동일한 방식으로 최적화되어 있지 않은 자신들의 맥락에 적용합니다.

제가 가장 자주 목격하는 구체적인 변환 실패 사례는 다음과 같습니다:

데모 데이터는 깨끗하지만, 구매자의 데이터는 그렇지 않습니다. 거의 모든 기업의 지식 베이스(knowledge base)에는 오래된 문서, 중복된 콘텐츠, 일관되지 않은 형식의 파일, 그리고 AI가 알 방법이 없는 조직적 맥락이 담긴 문서들이 포함되어 있습니다. 데모에서의 검색 품질(retrieval quality)은 이를 고려하지 않습니다. 운영 환경에서의 검색 품질은 이를 고려하게 될 것입니다.

데모용 쿼리(queries)는 제대로 작동하는 것들입니다. AI 시스템은 특정 쿼리 유형에서 나타나는 특정한 실패 모드(failure modes)를 가지고 있습니다. 벤더(Vendors)는 이러한 실패 모드를 피하도록 데모를 구성합니다. 구매자가 이를 구체적으로 조사하지 않는 한, 평가 과정에서 이러한 문제들은 나타나지 않을 것입니다.

데모 사용자는 전문가입니다. 데모를 실행하는 사람은 좋은 결과를 얻기 위해 쿼리를 어떻게 표현해야 하는지 알고 있습니다. 하지만 실제 운영 환경에서 도구를 사용할 직원들은 그렇지 않습니다. 효과적으로 프롬프트(prompt)를 작성할 줄 아는 사람의 쿼리와 그렇지 않은 사람의 쿼리 사이의 품질 차이는 현재 대부분의 AI 도구에서 매우 상당합니다.

레퍼런스 고객(Reference customers)은 대표성을 띠지 않습니다

벤더가 제공하는 레퍼런스 고객들은 이유가 있어서 선정된 것입니다. 이들은 경험이 긍정적이었고, 그 경험에 대해 기꺼이 이야기할 의사가 있는 고객들입니다. 이들은 고객 기반의 무작위 표본이 아닙니다.

평범한 경험을 했거나, 배포(deployment)에 어려움을 겪었거나, 데모에서는 나타나지 않았던 제품의 한계에 부딪혔던 고객들은 레퍼런스 목록에 포함되지 않습니다. 이들이 접근 불가능한 것은 아니며, 단지 벤더가 내세우는 대상이 아닐 뿐입니다.

저는 중요한 AI 조달(procurement) 결정을 내릴 때, 최소한 한 명 이상의 비레퍼런스(non-reference) 고객을 찾는 것을 원칙으로 삼습니다. LinkedIn을 이용하면 이를 달성할 수 있습니다. 해당 회사의 관련 직무에서 근무하는 직원들을 찾고, 그들이 누구와 연결되어 있는지 확인하며, 벤더의 사례 연구(case studies)나 보도 자료에 언급된 고객을 식별한 뒤, 레퍼런스로 제공되지 않은 해당 조직의 사람들에게 연락을 취하십시오.

대화 내용은 보통 레퍼런스 콜(reference calls)보다 더 솔직합니다. 왜냐하면 당신이 대화하고 있는 사람은 레퍼런스 관계를 위해 자원한 것이 아니기 때문입니다. 그들은 경험을 긍정적으로 제시해야 할 동기가 적습니다. 그들이 배포 경험, 시간이 흐름에 따른 벤더와의 관계, 그리고 평가 과정에서 들었던 내용의 정확성에 대해 말해주는 것들은, 선별된 레퍼런스들이 말하는 것보다 당신의 실제 경험을 더 잘 예측해 줍니다.

갱신 시점의 가격은 계약 시점의 가격이 아닙니다

AI 소프트웨어의 가격 책정 역학은 제가 조직들이 반복적으로 빠지는 것을 목격해 온 특정한 함정을 만들어냅니다. 초기 가격은 구매 결정을 내리기 쉽게 설정됩니다. 하지만 도구가 배포 및 통합되고, 사용자들이 이를 중심으로 워크플로우 (workflow)를 구축한 후의 갱신 가격은 다른 상업적 현실을 반영합니다.

이는 AI 소프트웨어에만 국한된 현상은 아니지만, 몇 가지 이유로 AI 소프트웨어에서 더욱 심각하게 나타납니다.

통합의 깊이는 전환 비용 (switching costs)을 가중시킵니다. 귀하의 데이터 소스에 연결되어 있고, 조직의 컨텍스트 (context)를 학습하며, 팀의 일상적인 워크플로우에 내재된 AI 도구는 애플리케이션 계층 (application layer)에 머무는 도구보다 교체하기가 훨씬 더 어렵습니다. 전환 비용은 시간과 통합의 깊이에 따라 증가하며, 벤더 (vendor)들은 이 사실을 알고 있습니다.

시장은 매우 빠르게 움직이고 있기 때문에, 갱신 시점의 경쟁 대안은 계약 시점의 대안과 다를 수 있습니다. 현실적인 대체재로 보였던 일부 도구들은 인수되거나, 사업 방향을 전환(pivot)하거나, 가격이 범위를 벗어날 정도로 높아졌을 수 있습니다. 다른 도구들이 새롭게 등장했을 수도 있지만, 귀하가 빠르게 수행할 수 없는 통합 작업을 요구할 것입니다. 계약 시점에 가졌던 선택권 (optionality)은 갱신 시점에 감소합니다.

가격 모델의 변경은 흔한 일입니다. 많은 AI 벤더들은 고객의 첫 번째 계약과 두 번째 계약 사이에 가격 구조를 변경합니다. 반드시 가격을 올리는 것이 아니라, 총 청구 금액에 영향을 미치는 방식으로 가격 책정의 기준을 변경합니다. 사용자 수 기반 (seat-based)에서 사용량 기반 (usage-based) 가격 책정으로 전환하거나, 귀하의 워크플로우가 의존하는 새로운 기능 티어 (feature tier)를 추가하거나, 과금 단위 (billable unit)의 정의를 변경하는 식입니다. 이 각각의 사례는 기술적으로는 가격 인상이 아닐지라도 실질적인 비용을 상당히 증가시킬 수 있습니다.

완화 방법은 간단하지만, 조달 프로세스가 AI 분야에 특별히 적용하기 어려운 수준의 규율(discipline)을 요구합니다. 즉, 계약 체결 전에 사용량 증가, 잠재적인 가격 구조 변경, 전환 비용(switching costs)에 대한 구체적인 가정을 바탕으로 갱신 시나리오를 명시적으로 모델링해야 합니다. 해당 모델링을 통해 도출된 수치는 귀사가 어느 정도의 통합 깊이(integration depth)를 구축할 용의가 있는지, 그리고 어떤 계약적 보호 장치를 협상할지를 결정하는 근거가 되어야 합니다.

평가 단계에는 없었으나, 실제 운영(go-live) 후에 변화하는 것들

평가 단계에서는 단순히 드러낼 수 없는 경험의 범주가 존재하는데, 이는 시간이 흐름에 따라 발생하는 것들이기 때문입니다. 벤더가 모든 고객에게 동시에 배포하는 대규모 업데이트 이후의 제품 동작, 복잡한 문제가 발생했을 때 담당 어카운트 매니저(account manager)가 교체된 후의 지원 품질, 실제 출시된 기능 및 시점과 제품 로드맵(product roadmap) 사이의 정확성, 그리고 파일럿 단계로부터 사용량이 크게 확장되었을 때의 제품 동작 등이 이에 해당합니다.

이 중 그 어느 것도 3개월간의 평가 과정에서는 나타나지 않습니다. 하지만 이 모든 요소가 3년이라는 기간 동안 제품과의 관계가 좋은 관계인지를 결정합니다.

계약 체결 전에 접근 가능한 이러한 특성들에 대한 가장 좋은 대리 지표(proxy)는, 도입한 지 최소 2년이 지난 고객들과 심도 있는 대화를 나누는 것입니다. 단순히 30분짜리 레퍼런스 콜(reference call)을 하는 것이 아닙니다. 경험의 전체 궤적에 대한 진정한 대화를 나누어야 합니다. 즉, 1년 차와 2년 차의 모습은 어떠했는지, 제품과 벤더와의 관계에서 무엇이 변했는지, 그리고 계약 당시 알았더라면 좋았을 현재의 정보는 무엇인지에 대해 말입니다.

이러한 대화를 준비하는 데는 시간이 걸리며, 벤더가 제공하는 레퍼런스 리스트 외의 고객을 찾아내야 합니다. 이는 기업의 AI 조달 프로세스에서 가장 가치 있는 활동임에도 불구하고, 대부분의 조직이 수행하지 못하고 있는 부분입니다.

표준 조달 프로세스에서 내가 바꾸고 싶은 점

표준적인 기업용 AI 조달 프로세스 (procurement process)는 역량을 평가하고 상업적 조건을 협상하도록 설계되어 있습니다. 시간이 흐름에 따른 신뢰성, 벤더 관계의 품질, 또는 평가 기간 동안 듣게 되는 정보의 정확성을 평가하도록 잘 설계되어 있지 않습니다.

표준 프로세스에 세 가지 구체적인 활동을 추가하면 이러한 간극의 대부분을 해결할 수 있습니다. 데모 데이터가 아닌, 여러분의 실제 지저분한 데이터 (messy data)로 테스트하십시오. 도입한 지 2년 이상 된, 레퍼런스 고객 (reference customer)이 아닌 고객을 찾아 대화하십시오. 가격 책정 및 전환 비용 (switching costs)에 대한 비관적인 가정을 바탕으로 갱신 시나리오를 명시적으로 모델링하십시오.

이러한 활동들은 조달 일정에 2주에서 4주를 추가합니다. 하지만 이는 이 포스트의 서두에서 설명한 간극이 발생할 확률을 상당한 수준으로 낮춰줍니다. 사후 수정, 재협상, 그리고 때로는 성급한 마이그레이션 (migration)에 소비되는 시간과 비용으로 측정되는 그 간극의 비용은, 추가적인 평가 시간에 드는 비용을 지속적으로 상회합니다.

이러한 더 철저한 평가 하에서도 좋은 성과를 보이는 벤더들은 자신들이 구축한 것과 고객을 대하는 방식에 자신감이 있는 곳들입니다. 연장된 일정이나 레퍼런스 고객에 대한 접근을 거부하는 벤더들은, 왜 자신들이 빠르게 진행하고 싶어 하는지에 대해 여러분에게 무언가를 말해주고 있는 것입니다.