AI 모델이 기업 환경에서 실패하는 이유: 89%의 문제

이 기사는 원래 davidohnstad.net에 게시되었습니다. Dev.to 커뮤니티에 전달하기 위해 이곳에 교차 게시합니다.

아무도 사용하지 않는 AI 기반 벤더 리스크 도구를 만들었습니다

우리는 14개월 동안 AI 기반 벤더 리스크 평가 (vendor risk assessment) 시스템을 구축하는 데 시간을 보냈습니다. 엔지니어링 팀은 모델의 재현율 (recall rates)에 자부심을 느꼈습니다. 보안 리더십은 이를 이사회에 경쟁 차별화 요소로 제시했습니다. 구매 부서는 새로운 워크플로 (workflow)에 대한 교육을 받았습니다. 그러고 나서 출시 6개월 후 사용성 분석 (usage analytics)을 실행했습니다. 벤더 평가 중 실제로 AI 점수 (AI scoring)를 사용한 비율은 11%에 불과했습니다. 나머지 89%는 우리가 폐기하기로 약속했던 수동 체크리스트 (manual checklist)로 돌아갔습니다. Gartner의 2024년 기업 AI 도입 조사 (Enterprise AI Adoption Survey)에 따르면, 우리는 예외적인 사례가 아니었습니다. 기업용 컴플라이언스 (compliance) 도구에 출시된 AI 기능의 72%가 출시 첫해 내에 30% 미만의 채택률을 보였습니다.

문제는 모델이 아니었습니다. 정밀도 (precision)는 괜찮았습니다. 인터페이스 (interface)도 깔끔했습니다. 문제는 우리가 자동화하려는 결정에 AI가 적합한 도구인지 한 번도 묻지 않았다는 점입니다. 우리는 벤더 리스크에 AI를 사용할 수 있기 때문에, 사용해야 한다고 가정했습니다. 그 가정으로 인해 우리는 1년 치의 로드맵 대역폭 (roadmap bandwidth)을 허비했고, 구매 팀이 의도적으로 우회하는 제품 기능(product feature)을 만들게 되었습니다.

David Ohnstad는 기업용 소프트웨어 구현 과정에서 이러한 패턴이 반복되는 것을 목격해 왔습니다. 팀들이 비즈니스 프로세스 (business process)가 요구하기 때문이 아니라, 단지 기술이 존재한다는 이유로 AI 기능을 출시하는 것입니다. 격차는 기술적 역량의 문제가 아니라 의사결정 구조 (decision architecture)의 문제입니다. 대부분의 벤더 리스크 워크플로는 확률적 점수 산정 (probabilistic scoring)을 필요로 하지 않습니다. 그들에게 필요한 것은 알려진 규칙의 일관된 적용, 감사 추적 (audit trails), 그리고 명확한 에스컬레이션 경로 (escalation paths)입니다. AI는 확실성이 전체 가치 제안 (value proposition)인 프로세스에 불확실성을 도입합니다.

AI 정당화 프레임워크 (The AI Justification Framework): 구축 전 통과해야 할 다섯 가지 관문

이것은 기업의 워크플로우 (workflow)가 AI 도입을 정당화할 수 있는지, 아니면 규칙 기반 로직 (rule-based logic)이 더 나은 비즈니스 가치를 제공하는지를 결정하기 위한 5단계 의사결정 프레임워크 (decision framework)입니다. 각 관문은 진행 여부 (go/no-go)를 결정하는 단계입니다. 만약 특정 관문을 명확하게 통과할 수 없다면, 정답은 다음과 같습니다: 먼저 더 단순한 시스템을 구축하고, 이를 철저히 측정 (instrument)한 뒤, 복잡성을 정당화할 수 있는 사용 데이터 (usage data)가 확보되었을 때 AI를 다시 검토하십시오.

관문 1: 규모의 정당성 (Volume Justification). 이 워크플로우가 수동 실행 시 측정 가능한 병목 현상 (bottleneck)을 일으킬 만큼 충분한 월간 트랜잭션 (transaction)을 처리합니까? 이 임계값은 임의적인 것이 아닙니다. 수동 검토 시간의 비용에 트랜잭션 규모를 곱하여 계산하십시오. 만약 단순한 규칙으로 자동화했을 때 구현 비용의 20%만으로 시간 절감 효과의 80%를 달성할 수 있다면, AI는 이 관문을 통과하지 못합니다. 공급업체 리스크 (vendor risk)의 경우, 대부분의 중견 기업은 연간 40~80개의 새로운 공급업체를 평가합니다. 평가당 2시간이 소요된다면 연간 160시간입니다. 규칙 기반 시스템은 이 정도 규모를 쉽게 처리할 수 있습니다. AI를 도입하면 제거하려는 수동 비용을 초과하는 모델 유지 관리 오버헤드 (model maintenance overhead, 재학습, 드리프트 모니터링, 설명 가능성 도구 등)가 발생합니다. David Ohnstad는 분기당 60건의 계약을 처리하기 위해 AI 계약 검토 시스템을 구축한 한 SaaS 기업과 협업했습니다. 해당 모델을 유지 관리하기 위해서는 전담 ML 엔지니어 (ML engineer)가 필요했습니다. 계약을 수동으로 검토하는 법률 보조원 (paralegal)을 고용하는 것이 비용도 적게 들고 정확도도 더 높았을 것입니다.

Gate 2: 불확실성 허용 범위 (Uncertainty Tolerance). 비즈니스 프로세스가 확률적 출력 (probabilistic outputs)을 허용합니까, 아니면 완전한 감사 가능성 (auditability)을 갖춘 결정론적 결과 (deterministic results)를 요구합니까? 공급업체 리스크 결정은 이진적 (binary)입니다: 승인, 거절, 또는 에스컬레이션 (escalated). 구매 팀은 73%의 리스크 점수를 바탕으로 행동하지 않습니다. 그들은 문서화된 근거가 포함된 예/아니오 (yes/no) 권장 사항이 필요합니다. AI 모델은 확실성 (certainties)이 아닌 신뢰 구간 (confidence intervals)을 생성합니다. 이는 수천 건의 거래를 점수화하고 리스크 점수 상위 2%를 조사하는 사기 탐지 (fraud detection) 분야에서는 가치가 있습니다. 하지만 모든 결정에 어차피 인간의 승인이 필요한 공급업체 온보딩 (vendor onboarding) 과정에서는 마찰을 일으킵니다. 만약 귀하의 워크플로에 이미 출력물의 100%를 검토하는 인간 참여형 (human-in-the-loop) 게이트가 있다면, AI는 병목 현상을 제거하는 것이 아니라 결정 로직을 모호하게 만드는 전처리 단계 (pre-processing step)를 추가하는 것에 불과합니다. 규칙 기반 시스템 (Rule-based systems)은 감사 가능한 결정 트리 (decision trees)를 생성합니다: "SOC 2 보고서가 90일 이상 만료되었으므로 공급업체 거절." 반면 AI 시스템은 다음과 같이 생성합니다: "140개의 입력 변수에 걸친 가중치 적용 특성 중요도 (weighted feature importances)로 인해 공급업체가 리스크 지수에서 0.68점을 기록함." 두 번째 설명은 컴플라이언스 감사 (compliance audit)를 통과할 수 없습니다.

Gate 3: 데이터 충분성 (Data Sufficiency). 휴리스틱 (heuristics)보다 뛰어난 성능을 보이는 모델을 구축할 만큼 충분한 레이블이 지정된 학습 데이터 (labeled training data)를 보유하고 있습니까? 그리고 영웅적인 수동 작업 없이도 해당 데이터셋을 지속적으로 갱신할 수 있습니까? 바로 이 지점에서 대부분의 기업용 AI 프로젝트가 조용히 실패합니다. 모델을 학습시키기 위해서는 수천 개의 레이블이 지정된 예시가 필요하며, 공급업체 리스크 패턴이 진화함에 따라 (새로운 컴플라이언스 프레임워크, 변화하는 지정학적 리스크, 새롭게 등장하는 위협 벡터 등) 재학습을 위한 지속적인 레이블 데이터가 필요합니다. 만약 귀하의 "학습 데이터"가 지난 3년 동안 수동으로 평가된 200개의 공급업체뿐이고, 보안 팀이 분기당 50개의 새로운 예시에 레이블을 달 여력이 없다면, 귀하는 세상의 얼어붙은 스냅샷 (frozen snapshot)을 기반으로 모델을 구축하고 있는 것입니다. 모델은 드리프트 (drift)될 것입니다. 아주 빠르게 말이죠. McKinsey의 2023년 AI 현황 보고서 (State of AI Report)에 따르면, 기업용 머신러닝 (ML) 모델의 67%가 데이터 드리프트 (data drift)로 인해 18개월 이내에 상당한 성능 저하를 경험하며, 자동화된 재학습 파이프라인 (automated retraining pipelines)을 갖춘 조직은 40% 미만입니다. 규칙 기반 시스템 (Rule-based systems)은 드리프트되지 않습니다. 규제가 변경될 때 규칙을 업데이트하면 되며, 로직은 투명하게 유지됩니다.

Gate 4: 실패 비용의 비대칭성 (Failure Cost Asymmetry). 시스템이 틀렸을 때 어떤 일이 발생합니까? 만약 오탐 (False Positives)의 비용이 미탐 (False Negatives)의 비용보다 크거나 그 반대인 경우, 그리고 배포 후 결정 임계값 (Decision Threshold)을 쉽게 조정할 수 없다면, AI는 관리 불가능한 리스크를 초래합니다. 공급업체 리스크 관리에서 미탐 (False Negatives)은 재앙적입니다. 나중에 데이터 유출, 규제 위반 또는 공급망 중단을 일으킬 공급업체를 승인하게 되기 때문입니다. 반면 오탐 (False Positives)은 번거롭긴 하지만 회복 가능합니다. 저위험 공급업체를 거절했다면, 그들이 이의를 제기할 때 승인으로 변경하면 됩니다. AI 모델은 비대칭적인 실패 비용이 아니라 전반적인 정확도 (Accuracy)를 최적화합니다. 결정 임계값을 조정할 수는 있지만, 이를 위해서는 지속적인 모니터링, A/B 테스트, 그리고 각 임계값 변경에 대한 경영진의 승인이 필요합니다. 규칙 기반 시스템 (Rule-based systems)은 귀사의 리스크 허용 범위 (Risk Tolerance)를 직접 인코딩합니다: "SOC 2가 누락되었거나, 데이터 처리 부속서 (Data Processing Addendum)에 서명되지 않았거나, 금수 조치 대상 관할 구역에 본사를 둔 경우 자동 거절." 모델 튜닝이 필요하지 않습니다. 규칙은 실제 리스크 성향 (Risk Appetite)과 일치하며, 성향이 변할 때 규칙도 변경하면 됩니다.

Gate 5: 설명 가능성 요구사항 (Explainability Requirement). 시스템이 왜 그러한 결론에 도달했는지 설명하지 않고 사용자에게 결정을 전달할 수 있습니까, 아니면 모든 출력에 추적 가능한 근거가 필요합니까? 구매 팀, 법률 고문, 그리고 컴플라이언스 담당자(Compliance Officers)는 블랙박스 (Black-box) 점수를 신뢰하지 않습니다. 그들은 감사인, 경영진, 그리고 때로는 거절에 이의를 제기하는 공급업체에게 공급업체 결정의 정당성을 입증해야 합니다. "저희 AI 모델이 귀사를 고위험군으로 분류했습니다"는 방어 가능한 설명이 아닙니다. 반면 "귀사는 저희의 5가지 공급업체 보안 요구사항 중 3가지를 충족하지 못했습니다: SOC 2 Type II 보고서 없음, 사이버 책임 보험 없음, 그리고 데이터 처리 부속서가 GDPR 표준을 충족하지 않음"은 방어 가능한 설명입니다. 만약 사용자층이 설명할 수 없는 권고 사항에 따라 행동하지 않는다면, AI는 이 관문을 통과하지 못합니다. 설명 가능한 AI (Explainable AI; SHAP values, LIME, Attention weights)가 도움이 되지만, 이는 도구 도입, 사용자 교육, 그리고 지속적인 유지보수라는 또 다른 계층을 추가합니다.

Enterprise AI pilots proof of concept 구현 사례들은 설명 가능성 (Explainability) 도구가 사용자 워크플로 (Workflow)에 얼마나 많은 마찰을 추가하는지를 자주 과소평가합니다.

벤더 리스크의 실수: 우리가 잘못된 도구를 만든 이유

David Ohnstad의 팀은 단 한 줄의 코드도 작성하기 전에 Gate 2와 Gate 5에서 실패했습니다. 벤더 리스크 (Vendor risk) 워크플로는 완전한 감사 가능성 (Auditability)을 갖춘 결정론적 출력 (Deterministic outputs)을 요구했습니다. 이는 규칙 기반 시스템 (Rule-based systems)이 탁월한 성능을 발휘하는 바로 그 시나리오이며, AI는 불필요한 복잡성을 도입하는 상황이었습니다. 하지만 제품 로드맵 (Product roadmap)에는 경쟁 압력과 회사의 AI 전략에 대한 이사회 차원의 관심으로 인해 'AI 기반 리스크 평가'가 두 분기 동안 확정된 기능으로 포함되어 있었습니다. 팀은 워크플로가 그것을 정당화해서가 아니라, 로드맵에 있었기 때문에 해당 기능을 구축했습니다.

기술적 구현은 작동했습니다. 모델은 벤더 설문지, 보안 문서, 재무 데이터, 그리고 제3자 위협 인텔리전스 피드 (Third-party threat intelligence feeds)를 입력받았습니다. 그리고 합리적인 정밀도로 0에서 1 사이의 리스크 점수를 출력했습니다. 문제는 사용자 수용 테스트 (User acceptance testing) 중에 드러났습니다. 조달 팀은 왜 특정 벤더의 점수가 0.68이 아닌 0.72가 나왔는지 설명할 수 없었으며, 보안 리더십에 보고하지 않고는 점수를 무시(Override)할 수도 없었습니다. 기존의 체크리스트 방식은 명확한 문서 기록과 함께 15분 만에 저위험 벤더를 승인할 수 있게 해주었습니다. 반면 AI 시스템은 30분의 데이터 입력이 필요했고, 신뢰할 수 없는 점수를 생성했으며, 과거에 규칙으로 자동 처리되었던 예외 케이스(Edge cases)들에 대해 강제적인 에스컬레이션 (Escalation)을 요구했습니다.

출시 6개월 후, 구매 부서는 89%의 평가에 대해 비공식적으로 수동 체크리스트(Manual checklist)를 다시 도입했습니다. 그들은 자동 에스컬레이션 플래그(Automatic escalation flags)가 트리거되는 벤더(높은 거래량, 민감한 데이터에 대한 접근 권한, 지리적으로 분산된 인프라 등)에 대해서만 AI 시스템을 사용했습니다. 표준 SaaS 벤더, 마케팅 대행사, 저위험 계약업체의 경우 체크리스트를 사용하는 것이 더 빠르고 투명하며 교육도 덜 필요했습니다. AI 기능은 규제 준수 연극(Compliance theater)을 위한 체크박스로 전락했습니다. 즉, RFP(제안 요청서) 응답을 위해 "네, 저희는 AI 기반의 벤더 리스크 플랫폼을 보유하고 있습니다"라고 말하기 위한 용도일 뿐, 실제 운영 시스템은 아니었습니다.

David Ohnstad라면 무엇을 다르게 했을까요? 규칙 기반 시스템(Rule-based system)을 먼저 출시하십시오. 그리고 이를 철저하게 계측(Instrument)하십시오. 어떤 규칙이 가장 자주 트리거되는지, 사용자가 어디에서 오버라이드(Override)를 요청하는지, 예외 케이스(Edge cases)가 수동 검토를 요구하는 빈도는 어느 정도인지, 그리고 어떤 벤더 카테고리가 가장 많은 평가 시간을 소비하는지를 추적하십시오. 12~18개월간의 실제 운영 사용 후, 당신이 가설적으로 존재한다고 가정했던 병목 현상이 아니라, 실제로 측정한 특정한 병목 현상을 AI가 개선할 수 있는지 분석하십시오. 만약 80%의 평가가 6개의 결정론적 규칙(Deterministic rules)으로 깔끔하게 해결되고, 15%는 정성적 요소에 대한 인간의 판단을 필요로 하며, 5%가 수십 개의 변수에 걸친 복잡한 리스크 모델링을 포함한다면... 당신은 AI가 가치를 더할 수 있는 지점(그 5%)을 식별한 것이며, AI가 마찰을 일으키는 나머지 95%를 위해 시스템을 구축하는 실수를 피한 것입니다. 이 접근 방식은 또한 필요한 라벨링된 학습 데이터셋(Labeled training dataset)을 구축해 줍니다. 수동으로 검토된 모든 벤더는 학습 사례(Training example)가 되며, 합성 시나리오(Synthetic scenarios)가 아닌 실제로 중요한 실제 예외 케이스에 대한 데이터를 수집하게 됩니다.

AI를 기능(Feature)으로 취급하는 것을 멈추고 비용 센터(Cost Center)로 취급하기 시작하십시오

대부분의 제품 로드맵(Product roadmap)은 AI 기능(AI features)을 UI 개선이나 API 확장과 동일한 방식으로 나열합니다. 즉, 사용자 가치를 전달하는 개별적인 기능(discrete capabilities)으로 취급합니다. 하지만 엔터프라이즈 소프트웨어(Enterprise software) 관점에서 이러한 프레임워크는 잘못되었습니다. AI는 기능이 아니라, 시간이 지남에 따라 복리로 쌓이는 영구적인 운영 비용(Operational expense)입니다. 출시하는 모든 AI 모델은 지속적인 모니터링(Monitoring), 재학습(Retraining), 드리프트 탐지(Drift detection), 설명 가능성 도구(Explainability tooling), 그리고 예측이 잘못되었을 때를 대비한 사고 대응(Incident response)을 필요로 합니다. Forrester의 2024 AI 운영 설문조사(AI Operations Survey)에 따르면, 기업들은 운영 중인 ML 모델 하나당 유지보수, 모니터링 및 재학습 인프라를 위해 연간 평균 180,000달러를 지출하며, 이 수치에는 초기 개발 비용은 포함되지 않았습니다.

규칙 기반 시스템(Rule-based systems)은 초기 복잡성(규칙 정의, 예외 케이스 처리, 오버라이드 워크플로우 구축)이 존재하지만, 일단 배포되면 한계 유지보수 비용(Marginal maintenance cost)이 거의 제로에 가깝습니다. 반면 AI 시스템은 복잡성이 후반부에 집중됩니다. 구축할 때는 흥미롭고 데모(Demo)도 잘 되지만, 데이터 분포가 변화하고 모델 성능이 저하됨에 따라 몇 달에 걸쳐 서서히 실패합니다. 만약 향후 3년 동안 모델을 유지 관리할 ML 엔지니어(ML engineer)와 데이터 분석가(Data analyst)를 배치할 준비가 되어 있지 않다면, 당신은 AI 기능을 출시할 준비가 된 것이 아니라, 상환할 수 없는 기술 부채(Technical debt)를 쌓고 있는 것입니다. 기업용 AI 예산 ROI 채택 실패는 종종 이러한 오해에서 비롯됩니다. 즉, 팀들이 모델 개발을 위한 예산은 책정하지만, 모델을 유용하게 유지하는 데 필요한 운영 오버헤드(Operational overhead)에 대해서는 예산을 책정하지 않는다는 점입니다.