엔터프라이즈 AI 예산 낭비: 세 가지 값비싼 실수
요약
엔터프라이즈 AI 프로젝트가 기술적 완성도에도 불구하고 낮은 채택률로 인해 예산을 낭비하는 원인을 분석합니다. 비즈니스 케이스 검증 없이 기술적 정교함에만 집중하거나, 기존 워크플로우와의 통합을 간과하는 조직적 실수를 경고합니다.
핵심 포인트
- 기술적 정교함보다 비즈니스 가치와 사용자 문제 해결이 우선되어야 함
- AI 기능을 기존 워크플로우에 자연스럽게 통합하는 것이 핵심
- 출시 여부가 아닌 실제 ROI와 운영 지표로 성공을 측정해야 함
- 모호한 AI 전략 대신 구체적인 유스케이스 식별 필요
이 기사는 원래 davidohnstad.net에 게시되었습니다. Dev.to 커뮤니티에 전달하기 위해 이곳에 교차 게시합니다.
우리가 엔터프라이즈 AI 예산을 (또 다시) 낭비하게 될 세 가지 방식
우리는 작년에 분석 플랫폼에 AI 기반 이상 탐지 (Anomaly Detection) 기능을 구축했습니다. 엔지니어링 시간, 모델 학습 인프라, 그리고 제3자 API 비용을 포함하여 340,000달러의 비용이 들었습니다. 출시 3개월 후, 사용 데이터에 따르면 활성 사용자는 11명이었으며, 그 중 8명은 제품 팀 소속이었습니다. 나머지 3명은 분기별 검토에 필요하다고 생각해서 이것저것 클릭해 보고 있었습니다.
모델은 작동했습니다. 예측은 정확했습니다. 인터페이스는 깔끔했습니다. 하지만 아무도 그것을 필요로 하지 않았습니다. 왜냐하면 우리는 그 기능이 어떤 의사결정을 바꿀 것인지, 혹은 어떤 워크플로 (Workflow)를 개선할 것인지 묻지 않았기 때문입니다. Gartner의 2024년 AI 준비도 평가 (AI Readiness Assessment)에 따르면, 지난 한 해 동안 출시된 엔터프라이즈 AI 기능의 72%가 15% 미만의 채택률을 보였습니다. 이는 기술이 실패했기 때문이 아니라, 엔지니어링 구축이 시작되기 전에 비즈니스 케이스 (Business Case)가 검증되지 않았기 때문입니다.
우리는 지금 하반기 예산 계획 주기에 진입하고 있으며, 저는 엔터프라이즈 팀들이 똑같은 실수를 슬로 모션으로 저지르는 것을 지켜보고 있습니다. 피치 덱 (Pitch Decks)은 모두 "AI 전략"을 말합니다. 로드맵에는 모두 LLM 통합과 예측 분석 (Predictive Analytics) 모듈이 포함되어 있습니다. 하지만 각 기능이 구체적으로 어떤 사용자 문제를 해결하는지 물으면, "데이터 기반 의사결정 지원" 또는 "효율성 개선"과 같은 모호한 답변만 돌아옵니다. 그것은 제품 전략이 아닙니다. 그것은 정당성을 찾고 있는 보도 자료일 뿐입니다.
엔터프라이즈 규모에서 AI 기능 선택이 실패하는 이유
실패 양상은 기술적인 것이 아니라 조직적인 것입니다. 대부분의 엔터프라이즈 AI 이니셔티브 (Enterprise AI initiatives)는 컨퍼런스에 참석해 데모를 보고 돌아와 회사가 "더 많은 AI"를 필요로 한다고 확신하게 된 CTO나 VP로부터 시작됩니다. 엔지니어링 팀은 머신러닝 (Machine Learning) 역량을 탐색하라는 명령을 받습니다. 제품 팀은 유스케이스 (Use cases)를 식별하라는 요청을 받습니다. 그리고 기술적으로 가능한 것과 비즈니스 지표 (Business metric)를 실제로 움직일 수 있는 것 사이의 연결 고리를 구축하기 위해 멈춰 서서 고민하는 사람은 아무도 없습니다.
이 격차는 세 가지 지점에서 나타납니다. 첫째, 엔지니어링 팀은 사용자 워크플로우 통합 (User workflow integration)보다는 기술적 정교함 (Technical sophistication)을 최적화합니다. 사용하기 위해 6번의 클릭과 데이터 내보내기가 필요한 추천 엔진은, 설령 머신러닝 (ML) 모델이 객관적으로 더 우수할지라도 단순한 드롭다운 필터에 매번 패배할 것입니다. 둘째, 제품 팀은 AI 기능을 대체재가 아닌 추가물로 취급합니다. 즉, AI가 어떤 수동 단계를 제거해야 하는지 묻는 대신 기존 워크플로우 위에 새로운 기능을 쌓아 올리기만 합니다. 셋째, 경영진 스폰서 (Executive sponsors)는 지속적인 사용량이나 측정 가능한 ROI (투자 대비 수익)가 아니라 출시 발표를 기준으로 성공을 측정합니다.
McKinsey의 2024년 AI 현황 보고서 (2024 State of AI Report)에 따르면, AI 투자를 특정 운영 지표 (Operational metrics)와 직접 연결하는 조직은 일반적인 "혁신" 명령을 추구하는 조직보다 채택률 (Adoption rates)이 3.2배 더 높습니다. 차이점은 모델의 품질이 아니라, 첫 번째 스프린트 (Sprint)가 시작되기 전에 성공의 모습이 무엇인지 정의한 사람이 있느냐의 여부입니다.
David Ohnstad는 여러 엔터프라이즈 소프트웨어 출시 과정에서 이 패턴이 반복되는 것을 목격해 왔으며, 경고 신호는 항상 동일합니다. 결과 (Outcomes)가 아닌 기능 (Capabilities)으로 표현된 로드맵 항목, "이것을 사용하시겠습니까?"라고 묻는 대신 "이것이 어떤 결정을 변화시킬까요?"라고 물어야 하는 사용자 조사, 그리고 워크플로우 대체가 아닌 TAM (Total Addressable Market, 총 유효 시장) 확장에 기반하여 구축된 비즈니스 케이스 (Business cases)가 그것입니다. 이 세 가지가 동시에 나타난다면, 당신은 아무도 두 번 이상 열어보지 않을 인상적인 무언가를 만드는 데 6개월을 소비하게 될 것입니다.
기능 정당화 스택: 구축 전 검증 프레임워크 (The Feature Justification Stack: A Pre-Build Validation Framework)
어떤 AI 기능이 엔지니어링 리소스를 할당받기 전에, 반드시 네 가지 검증 레이어(validation layers)를 통과해야 합니다. 이것은 우선순위를 정하는 연습이 아니라, 실행 여부를 결정하는 필터(go/no-go filter)입니다. 만약 어떤 기능이 구체적이고 문서화된 답변을 통해 네 가지 레이어를 모두 통과하지 못한다면, 그 기능은 아직 로드맵에 포함될 단계가 아닙니다. 대부분의 엔터프라이즈 팀은 기술적 타당성(technical feasibility) 단계로 곧장 건너뛰며, 왜 채택률(adoption)이 낮은지 의아해합니다. 이 프레임워크는 솔루션(solution)을 검증하기 전에 문제(problem)를 먼저 검증하도록 강제합니다.
레이어 1: 워크플로 중단 매핑 (Workflow Disruption Mapping). AI 기능이 대체하거나 제거할 정확한 수동 단계(manual steps)를 식별하십시오. '개선'이 아니라 '대체'해야 합니다. 현재의 사용자 워크플로를 구체적인 동작과 함께 그리십시오: 보고서 열기, 지역별 필터링, Excel로 내보내기, 피벗 테이블 생성, 이해관계자에게 요약 이메일 발송. 이제 AI 기능이 활성화된 상태의 워크플로를 그리십시오. 만약 새로운 워크플로에도 여전히 두 개 이상의 수동 단계가 남아 있다면, 당신은 워크플로를 중단시킨 것이 아니라 우회로를 추가한 것입니다. 이 기능은 레이어 1에서 탈락합니다.
레이어 2: 의사결정 델타 정량화 (Decision Delta Quantification). 이 기능으로 인해 변화하게 될 구체적인 의사결정을 명시하고
Layer 3: 데이터 준비성 감사 (Data Readiness Audit). 대부분의 팀이 자신들이 생각만큼 준비되지 않았음을 깨닫게 되는 지점입니다. AI 기능에 필요한 모든 데이터 입력값을 매핑하십시오: 소스 시스템 (source system), 갱신 빈도 (refresh frequency), 스키마 안정성 (schema stability), 이력 데이터의 깊이 (historical depth), 그리고 알려진 품질 문제 (known quality issues). 그런 다음
우리는 데이터 웨어하우스 (data warehouse)를 위한 자연어 질의 인터페이스 (natural language query interface)를 구축했습니다. 제안 내용은 간단했습니다. 비즈니스 사용자들이 SQL을 작성하거나 분석가의 지원을 기다리는 대신, 평이한 영어로 질문을 던질 수 있다는 것이었습니다. 엔지니어링 팀은 우리의 스키마 (schema)를 바탕으로 미세 조정된 모델 (fine-tuned model)을 학습시켰고, 깔끔한 채팅 인터페이스를 구축하여 50명의 사용자에게 베타 버전을 출시했습니다. 데모는 완벽했습니다. 경영진은 이를 매우 좋아했습니다. 우리는 3분기(Q3)에 전체 출시를 계획했습니다.
그 후 우리는 설문 조사가 아닌, 사용자가 실제로 작업하는 모습을 지켜보는 구조화된 사용자 관찰 세션을 진행했습니다. 우리가 발견한 사실은 다음과 같습니다. 사용자들은 질문을 무엇을 해야 할지 몰랐기 때문에 질문을 하지 않았습니다. 시스템을 정기적으로 사용하는 분석가들은 이미 SQL을 알고 있었으며, 쿼리가 명시적이고 검토 가능하기 때문에 SQL을 선호했습니다. SQL을 작성할 수 없는 비즈니스 사용자들 또한 모델이 유용한 결과를 반환할 수 있을 만큼 구체적인 질문을 구성하지 못했습니다. 그들은 "매출 트렌드를 보여줘"라고 입력한 뒤, 시스템이 날짜 범위, 제품 카테고리, 지역을 지정하라고 요청하면 좌절했습니다. 이 기능은 대상 사용자층에 존재하지 않는 수준의 데이터 리터러시 (data literacy)를 가정하고 있었습니다.
실패의 원인은 NLP 모델이 아니라 워크플로우 (workflow)에 대한 가정이었습니다. 우리는 장벽이 SQL 구문 (syntax)이라고 생각했습니다. 실제 장벽은 애초에 어떤 분석을 실행해야 할지 모른다는 것이었습니다. 그것은 교육의 문제이자 데이터 발견 (data discovery)의 문제이지, 자연어 인터페이스의 문제가 아니었습니다. 만약 우리가 이상적인 워크플로우가 아닌 실제 사용자 워크플로우를 매핑하는 1단계 검증 (Layer 1 validation)을 수행했다면, 사용자들이 질문으로 시작하지 않는다는 것을 알았을 것입니다. 그들은 다른 사람이 만든 보고서로 시작하여 필터를 수정하는 방식으로 작업을 시작했습니다. 우리가 구축했어야 할 AI 기능은 질의 인터페이스가 아니라, 역할과 최근 활동을 기반으로 한 보고서 추천 기능이었습니다.
우리는 출시 8개월 만에 해당 기능을 폐기했습니다. 28만 달러(약 3억 7천만 원)의 매몰 비용(Sunk cost)도 뼈아팠지만, 더 큰 비용은 Layer 1 단계에서 실패한 기능에 8개월이라는 로드맵(Roadmap) 공간을 할애했다는 점이었습니다. David Ohnstad는 제품 팀이 왜 기능 정당화 스택(Feature Justification Stack)에 기술적 타당성(Technical feasibility) 검토 이전에 워크플로 중단 매핑(Workflow disruption mapping)이 필요한지 물을 때마다 여전히 그 출시 사례를 참조 모델로 사용합니다. 만약 구체적인 단계를 포함한 전/후 워크플로(Before/after workflow)를 그려낼 수 없다면, 당신은 아직 해결책을 구축할 수 있을 만큼 문제를 충분히 이해하지 못한 것입니다.
기술적 경이로움(Technical Wow Factor)에 따른 AI 기능 우선순위 설정을 중단하라
대부분의 엔터프라이즈 로드맵은 모델의 정교함이나 경쟁적 포지셔닝을 기준으로 AI 기능의 우선순위를 정합니다. "X사가 추천 엔진을 출시했으니, 우리도 필요하다."와 같은 식입니다. 이것은 제품 전략(Product strategy)이 아니라, 기능적 동등성 연극(Feature parity theater)에 불과합니다. 채택(Adoption)과 투자 대비 수익(ROI)을 견인하는 기능은 기술적으로 가장 인상적인 기능인 경우가 드뭅니다. 대신, 가장 빈번하게 발생하는 워크플로(Workflow)에서 수동 단계를 가장 많이 제거하는 기능들입니다.
들어오는 지원 티켓(Support tickets)을 자동으로 태깅(Auto-tagging)하고 적절한 팀으로 라우팅(Routing)하는 간단한 AI 기능이, 유용한 정보를 보여주기 전까지 수동 CSV 업로드와 10분의 설정이 필요한 정교한 감성 분석(Sentiment analysis) 대시보드보다 더 측정 가능한 가치를 제공할 것입니다. 태깅 기능은 워크플로 속에 자연스럽게 녹아듭니다. 반면 대시보드는 사용자들이 분기별 검토 시 체크박스 하나를 채우기 위해 여는 탭에 머물 뿐입니다. 엔터프라이즈 소프트웨어 채택에 관한 Harvard Business Review의 2023년 분석에 따르면, 기술적 정교함과 관계없이 행동 변화가 전혀 필요 없는 기능은 새로운 습관을 요구하는 기능보다 지속적인 사용률이 4.1배 더 높게 나타났습니다.
이는 대부분의 AI 예산이 할당되는 방식과는 상반됩니다. 엔지니어링 팀은 흥미로운 문제를 해결하고 싶어 합니다. 경영진은 현재의 역량을 발표하고 싶어 합니다. 그리고 제품 관리자(Product Manager)들은 그 중간에 끼어, 왜 화려한 예측 분석(Predictive Analytics) 모듈 대신 지루한 자동화(Automation) 기능에 리소스를 투입해야 하는지 정당화하려 애씁니다. 하지만 워크플로(Workflow)를 변화시키는 것은 지루한 자동화입니다. 화려한 분석은 LinkedIn에 스크린샷을 올리기 위한 용도일 뿐입니다.
테스트 방법: 만약 내일 당장 해당 AI 기능을 제거한다면, 특정 운영 프로세스가 중단되거나 느려지겠습니까? 만약 대답이 '아니오'라면 — 즉, 사용자들이 의미 있는 마찰 없이 그냥 수동 워크플로로 돌아간다면 — 당신은 제품(Product)이 아닌 새로움(Novelty)을 만든 것입니다. 새로움은 데모용으로 쓰입니다. 제품은 아무도 의식하지 않은 채 매일 사용됩니다. David Ohnstad의 데이터 제품 관리(Data Product Management) 글은 이 차이점을 일관되게 강조합니다. 최고의 데이터 제품은 사용자가 그것이 존재한다는 사실조차 잊어버릴 정도로, 보이지 않는 인프라(Invisible Infrastructure)가 된 제품입니다.
하반기 계획 수립 시 엔터프라이즈 AI 예산이 실제로 투입되어야 할 곳
2026년 남은 기간을 위한 AI 투자를 마무리하고 있다면, 예산을 완전히 새로운 기능(Net-new features)에서 기능 통합의 깊이(Feature integration depth)로 전환하십시오. 비즈니스 지표를 움직이는 AI 역량은 새로운 대시보드나 분석 도구를 추가하는 것이 아니라, 기존 워크플로의 단계를 제거하는 역량입니다. 이는 수동 데이터 준비를 줄이고, 사용자가 이미 매주 작성하고 있는 보고서를 자동으로 생성하며, 사용자가 일상적인 업무 중에 마주하는 의사결정 지점에서 권장 사항을 제시하는 AI 기능을 우선시해야 함을 의미합니다.
탐색적 AI (exploratory AI) 이니셔티브보다 지속적으로 더 나은 성과를 내는 세 가지 투자 범주는 다음과 같습니다: 기존 제품 인터페이스 내에서의 워크플로 자동화 (새로운 독립형 AI 도구가 아님), 과거 패턴을 기반으로 한 양식 필드 또는 설정의 예측적 사전 채우기 (predictive pre-population), 그리고 데이터가 다운스트림 시스템 (downstream systems)에 진입하기 전에 잘못된 데이터를 차단하는 자동화된 품질 검사입니다. 이 중 그 어떤 것도 컨퍼런스에서 발표하기에 흥미로운 주제는 아닙니다. 하지만 이 모든 것들은 사용자에게 하루 10~30분의 시간을 절약해 주며, 오류율을 측정 가능한 수치로 감소시킵니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기