기업용 AI 파일럿이 실패하는 이유: PoC에서 프로덕션까지

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

왜 대부분의 기업용 AI 파일럿은 개념 증명(PoC) 단계를 벗어나지 못하는가

우리는 고객 상태 모니터링 대시보드를 위해 AI 기반 이상 탐지 (Anomaly Detection) 기능을 구축했습니다. 세 번의 엔지니어링 스프린트(Engineering Sprints), 한 명의 PhI 레벨 데이터 사이언티스트가 투입되었습니다. 출시 2주 후, 사용 지표를 확인해보니 계정 소유자의 89%가 첫 로그인 세션 내에서 해당 기능을 비활성화했습니다. 피드백은 정확도에 관한 것이 아니었습니다. 모델은 제대로 작동했습니다. 문제는 우리가 사용자들이 확률적인 설명이 아닌 빠른 분류 (Triage) 결정을 필요로 하는 워크플로우에 정교한 예측 엔진을 삽입했다는 점이었습니다. Gartner의 2024년 AI 현황 보고서에 따르면, 이러한 패턴은 업계 전반에 걸쳐 나타납니다. 기업용 소프트웨어의 AI 기능 중 54%가 배포 후 90일 이내에 비활성화되거나 무시되는데, 이는 AI가 기술적으로 실패해서가 아니라 해당 기능이 실제 사용자의 의사 결정 지점과 연결되지 않았기 때문입니다.

이 기사는 어떤 AI 역량이 실제로 기업용 소프트웨어 로드맵에 포함되어야 하는지를 평가하기 위한 실무자 프레임워크를 소개합니다. 현재의 과제는 AI에 투자할 것인가의 여부가 아닙니다. 대부분의 조직은 이미 1분기 예산 사이클 동안 그 결정을 내렸습니다. 진짜 과제는 백로그(Backlog)에 15개의 상충하는 "AI 강화" 기능 요청이 쌓여 있고, 제품 팀이 각 기능의 ROI(투자 대비 효과)를 증명해야 하는 3분기에 어떤 AI 역량을 우선시할 것인지 파악하는 것입니다. 이것은 David Ohnstad가 단순히 출시되는 것이 아니라 실제로 채택될 AI 기능 아이디어를 걸러내기 위해 사용하는 단계별 의사 결정 모델입니다.

리스크: AI 투자가 제품 가치가 아닌 기술 부채가 될 때

잘못된 AI 기능을 출시하는 비용은 단순히 이를 구축하는 데 소비된 엔지니어링 시간만이 아닙니다. 그것은 사용자들이 귀하의 제품에서 "AI 기반 (AI-powered)"라고 표시된 모든 것을 무시하는 법을 배우게 될 때 상실되는 조직적 신뢰도입니다. David가 협업했던 한 SaaS 기업은 18개월 동안 세 개의 별도 AI 기능을 출시했습니다. 각각의 기능은 기술적으로는 결함이 없었습니다. 하지만 각각은 아무도 우선순위를 두지 않았던 문제를 해결하려 했습니다. 세 번째 출시 시점에 실시된 내부 채택 설문 조사에 따르면, 고객 성공 (Customer Success) 팀은 신규 사용자들에게 플랫폼의 AI 섹션이 "더 유용해질 때까지" 건너뛰라고 적극적으로 조언하고 있었습니다. 이것은 제품 속도 (Product Velocity)의 문제가 아니라 제품 신뢰 (Product Trust)의 문제이며, 이는 복리로 쌓여 악화됩니다.

McKinsey의 2025년 기업용 소프트웨어 내 AI (AI in Enterprise Software) 연구에 따르면, 활용도가 낮은 AI 기능이 3개 이상인 조직은 더 적고 더 타겟팅된 AI 역량을 출시한 기업에 비해 이후 AI 출시 기능의 채택률이 31% 하락한 것으로 나타났습니다. 여기서 얻을 수 있는 교훈은 다음과 같습니다. 사용자는 개별 출시 건이 아니라 누적된 실적을 바탕으로 귀하의 AI 기능이 시간을 들일 가치가 있는지에 대한 기대를 형성한다는 것입니다. 목표를 벗어난 AI 기능을 두 번 출시하면, 세 번째 기능은 설령 그것이 진정으로 가치 있더라도 신뢰도 결핍을 안고 시작하게 됩니다.

전형적인 실패 패턴은 다음과 같습니다: 제품 팀이 머신러닝 (Machine Learning)이 이론적으로 가치를 더할 수 있는 영역을 식별하고, 엔지니어링 리소스를 확보하며, 기능을 구축하고, 내부적인 환호 속에 출시하지만, 이후 8주 이내에 사용량이 정체되는 것을 지켜보는 것입니다. 사후 분석 (Post-mortems)에서는 보통 "변화 관리 (Change Management)"나 "사용자 교육의 공백"을 원인으로 꼽지만, 이러한 설명들은 진짜 문제를 놓치고 있습니다. 해당 기능은 사용자가 이미 내리려고 노력 중인 의사결정을 중심으로 설계되지 않았습니다. 기존 워크플로우 (Workflow)에서 마찰을 제거하지 않은 채 새로운 기능만을 도입한 것입니다. David Ohnstad의 데이터 제품 관리 글은 이 원칙을 일관되게 강조합니다: 기능을 수용하기 위해 사용자가 자신의 행동을 바꿔야 하는 AI 기능은 출시와 동시에 실패한 것이나 다름없습니다. 기능은 사용자의 기존 의사결정 프로세스 (Decision Process)에 맞춰져야 합니다.

의사결정 우선 AI 기능 스택 (The Decision-First AI Capability Stack)

이것은 이해관계자가 기업용 소프트웨어 기능에 AI를 추가하자고 제안할 때 David Ohnstad가 사용하는 4계층 평가 모델입니다. 이 명칭은 핵심 원칙을 담고 있습니다: 기술이 아니라 의사결정에서 시작해야 한다는 것입니다. 모든 AI 기능은 사용자가 이미 내리고 있는 특정 의사결정에 매핑되어야 하며, 그 의사결정을 더 빠르고, 더 확신 있게, 또는 오류가 적게 내릴 수 있도록 만들어야 합니다. 만약 그 의사결정을 한 문장으로 정의할 수 없다면, 해당 AI 기능은 아직 로드맵에 올릴 준비가 되지 않은 것입니다.

Layer 1: 의사결정 매핑 (Decision Mapping)—AI 기능이 개입하게 될 정확한 의사결정 지점(decision point)을 식별하십시오. 일반적인 워크플로우가 아닙니다. 사용자가 옵션 A와 옵션 B 사이에서 선택해야 하거나, 행동할지 기다릴지를 결정해야 하는 바로 그 구체적인 순간을 찾아야 합니다. 앞서 언급한 이상 탐지 (anomaly detection) 기능의 경우, 의사결정 지점은 "고객 상태 트렌드를 이해하는 것"이 아니라 "이 계정을 오늘 시니어 CSM에게 에스컬레이션해야 하는가, 아니면 일주일 더 기다려야 하는가?"였습니다. 의사결정을 그토록 구체적으로 명명하고 나면, AI의 출력값이 그 결정에 부합하는지 테스트할 수 있습니다. 이 사례의 경우, 부합하지 않았습니다. 모델은 신뢰도 점수 (confidence scores)와 기여 요인을 제공했지만, 사용자들에게는 매니저에게 전달할 수 있는 근거가 포함된 이진 권장 사항 (binary recommendation)이 필요했습니다. 모델의 출력값과 의사결정 구조 사이의 불일치가 도입 (adoption)을 가로막았습니다.

Layer 2: 데이터 준비도 감사 (Data Readiness Audit)—AI 모델을 학습시키고 실행하는 데 필요한 데이터가 이미 시스템 내에서 수집, 정제 및 구조화되어 있는지 확인하십시오. 이는 많은 팀이 엔지니어링의 영역이라고 생각하여 제품 우선순위 설정 (product prioritization) 단계에서 건너뛰는 단계입니다. 하지만 데이터 준비도는 출시까지 남은 시간이 6주인지 6개월인지를 결정합니다. David는 추천 엔진 (recommendation engine) 기능이 1분기에 승인되었으나, 2기에 들어서야 모델 학습에 필요한 이벤트 트래킹 (event tracking)이 제품에 아직 구현되지 않았음을 발견한 사례를 목격했습니다. 데이터 파이프라인 (data pipeline)이 구축되고 최소 기능 모델 (minimally viable model)을 학습시킬 만큼 충분한 과거 데이터를 수집할 때쯤에는, 출시 시점이 두 분기나 밀려버렸습니다. 해당 기능은 예산이 책정되었던 회계 연도를 놓치게 되었습니다. 교훈은 다음과 같습니다: 데이터가 이미 흐르고 있지 않다면, 그 AI 기능은 다음 계획 주기 (planning cycle)를 맞출 준비가 되지 않은 것입니다.

Layer 3: 출력 통합 테스트 (Output Integration Test)—AI 출력이 사용자 인터페이스 (UI)에서 어떻게 나타나는지 목업 (mockup)을 설계하고, 사용자가 문맥 전환 (context-switch)을 할 필요 없이 기존 워크플로 (workflow)에 통합되는지 테스트하십시오. 여기서 "사이드바로서의 AI (AI as a sidebar)"라는 실수가 발생합니다. 팀들은 정교한 모델을 구축한 뒤, 사용자가 의도적으로 찾아가야 하는 별도의 패널이나 모달 (modal)에 출력을 표시합니다. 만약 AI 통찰 (insight)을 확인하기 위해 추가적인 클릭이나 탭 전환이 필요하다면, 채택률 (adoption)은 수치상으로 급격히 떨어집니다. 통합 테스트는 다음과 같이 질문합니다: 사용자가 현재 머물고 있는 화면을 떠나지 않고도 이 AI 출력에 따라 행동할 수 있는가? David Ohnstad Minnesota 기반의 엔터프라이즈 팀들에게 이는 종종 사용자가 확인해야 할 것을 기억해야 하는 새로운 "AI 통찰 (AI Insights)" 섹션을 만드는 것이 아니라, AI 권장 사항을 테이블, 대시보드, 또는 알림 스트림 (notification streams)에 직접 임베딩 (embedding)하는 것을 의미합니다.

Layer 4: 가역성 및 투명성 설계 (Reversibility and Transparency Design)—사용자가 AI가 왜 해당 권장 사항을 내놓았는지 확인하고, 마찰 없이 이를 무효화 (override)할 수 있는 기능을 구축하십시오. 이는 직관에 반하는 단계입니다. 대부분의 AI 제품 팀은 95% 정확도의 모델이 사용자의 신뢰를 얻을 것이라고 가정하며, 정확도 (accuracy)와 신뢰도 점수 (confidence scores)에 집중합니다. 하지만 엔터프라이즈 사용자들이 AI 기능을 채택하는 이유는 모델이 정확하기 때문이 아니라, 추론 과정을 검증할 수 있고 필요할 경우 결정을 되돌릴 수 있기 때문입니다. David가 협업했던 한 조달 소프트웨어 기업은 모든 AI 생성 공급업체 리스크 점수에 "이유 보기 (Show me why)" 버튼을 추가했습니다. 기반 모델이 변경되지 않았음에도 불구하고, 해당 버튼이 추가된 후 첫 달에 AI 기능 사용량이 40% 급증했습니다. 투명성 기능은 사용자들이 블랙박스 (black box)를 맹목적으로 신뢰하는 것이 아니라는 확신을 주었으며, 이는 사용자들이 낮은 이해관계 (lower-stakes)의 결정에 대해 AI 출력을 더 기꺼이 신뢰하게 만들었습니다.

AI를 플랫폼 역량으로 취급하는 조직에서 이 접근 방식이 실패하는 이유

Decision-First AI Capability Stack은 제품 개발(Product Development)과 분리된 전담 머신러닝 (ML) 팀에 AI 개발을 중앙 집중화하는 기업에서 무너집니다. 구조적인 문제는 ML 팀이 해당 기능의 채택 여부가 아니라, 일반적으로 모델 성능(정확도 (Accuracy), 정밀도 (Precision), 재현율 (Recall))을 기준으로 평가받는다는 점입니다. 이는 ML 팀이 잘못된 성공 지표를 위해 최적화하게 되는 불일치(Misalignment)를 초래합니다. David는 한 기업에서 이러한 상황이 벌어지는 것을 목격했습니다. 해당 ML 팀은 92%의 정확도를 가진 이탈 예측 모델을 구축한 뒤

여기 반전되는 주장이 있습니다. 미드마켓 (Mid-market) 및 중소기업 (SMB) 세그먼트의 기업용 소프트웨어 구매자들은 아직 AI 기능이 포함된 제품에 대해 더 높은 지불 의사 (Willingness-to-pay)를 할당하지 않으며, 기능 목록에 "AI 기반 (AI-powered)"를 추가한다고 해서 경쟁 평가에서의 승률이 높아지지도 않는다는 것입니다. Forrester의 2024 B2B 소프트웨어 구매자 행동 보고서 (2024 B2B Software Buyer Behavior Report)에 따르면, SaaS 플랫폼을 비교할 때 AI 역량을 상위 3대 평가 기준 중 하나로 꼽은 미드마켓 구매자는 18%에 불과했으며, SMB 구매자의 경우 그 수치는 11%로 떨어졌습니다. 현재 제품 전략의 통념은 경쟁력을 유지하기 위해 AI 기능이 필요하다는 것입니다. 하지만 데이터는—적어도 지금은—그와 다르게 말하고 있습니다. 구매자가 신경 쓰는 것은 귀하의 제품이 대안보다 그들의 워크플로우 (Workflow) 문제를 더 빠르게 해결하느냐 하는 것입니다. 만약 AI 기능이 결과 도출 시간 (Time-to-outcome)을 눈에 띄게 단축하지 못한다면, 그것은 경쟁의 판도를 바꾸지 못합니다.

이것이 AI를 무시해야 한다는 뜻은 아닙니다. AI 기능을 차별화 요소 (Differentiation plays)로 우선순위에 두는 것을 멈추고, 워크플로우 최적화 (Workflow optimization) 투자로 취급하기 시작해야 한다는 의미입니다. AI 기능에 대한 ROI (투자 대비 수익) 사례는 "경쟁적 포지셔닝"이나 "혁신 서사"가 아니라, 사용자당 주당 절약된 시간(분)으로 측정되어야 합니다. David가 자문을 제공했던 한 금융 서비스 소프트웨어 기업은 두 경쟁사가 유사한 기능을 출시했기 때문에 자신들의 플랫폼에 AI 기반 문서 분류 기능을 추가하고 싶어 했습니다. 50명의 사용자를 대상으로 파일럿 (Pilot)을 실시했을 때, 절약된 시간은 문서당 평균 90초였습니다. 하지만 사용자들은 하루 평균 3개의 문서만 처리했습니다. 사용자당 주당 총 절약 시간은 7.5분이었습니다. 이 기능을 구축하는 데는 8개월의 엔지니어링 공수가 들었습니다. 이 계산은 성립하지 않습니다. 해당 기업은 그 기능을 보류하고 엔지니어링 역량을 사용자들이 2년 동안 요청해 온 대량 문서 업로드 기능으로 재배치했습니다. 그 기능은 다음 NPS (순추천지수) 조사에서 사용자 만족도 점수를 22점 높였습니다. 지루한 인프라 작업이 화려한 AI 기능을 이겼는데, 그 이유는 그것이 더 큰 워크플로우 마찰 지점 (Workflow friction point)을 해결했기 때문입니다.

시니어 제품 리더가 3분기 계획 주기(Q3 Planning Cycles)에서 감사(Audit)해야 할 사항