MIT Project NANDA 연구진이 2025년 발표한 The GenAI Divide: State of AI in Business 2025에는 꽤 강한 숫자가 등장한다.
300개 이상의 공개 AI 사례 분석, 52개 조직 인터뷰와 153명의 senior leader 설문을 바탕으로 한 이 예비 연구에서, 연구진은 대다수 기업의 GenAI 도입이 아직 측정 가능한 P&L impact로 이어지지 못했으며, 실제 의미 있는 가치를 만들어낸 통합형 AI pilot은 약 5%에 불과했다고 보고했다.
이 결과는 흔히 “GenAI 프로젝트의 95%가 실패한다”는 식으로 소개된다.
나는 그 표현에는 조금 조심스러운 편이다.
누군가가 AI를 이용해 하루 한 시간을 절약했다고 해서 그것이 바로 P&L에 잡히는 것은 아니다. 반대로 멋진 데모가 만들어졌다고 해서 실제 비즈니스 가치가 생겼다고 말하기도 어렵다.
내게 더 흥미로운 것은 95%라는 숫자 자체보다 그 뒤에 있는 질문이다.
왜 이렇게 좋은 모델을 가지고도 기업은 실제 업무의 변화를 만들어내기 어려운가?
돌이켜보면 이 질문은 내가 AI를 공부하면서 처음 갖게 된 것이 아니다.
그보다 훨씬 전, 영업사원으로 일할 때부터 계속 보고 있었던 문제에 가깝다.
나는 개발자가 아니라 영업사원으로 직장 생활을 시작했다
나는 대기업 B2B 제조업의 영업 조직에서 직장 생활을 시작했다.
Automotive 산업에서 약 10년 동안 영업을 경험했다. 부품 대리점부터 완성차 고객까지 상대했고, 국내뿐 아니라 중국, 유럽, 미주 시장을 오갔다.
업무의 형태도 다양했다.
이미 거래가 안정화된 제품의 repeat order부터 여러 조직이 수년간 움직여야 하는 long-term project까지 경험했다.
시장과 고객이 달라지면 영업의 모습도 달라진다.
대리점 영업에서는 거래 관계와 수요 변화에 빠르게 대응하는 것이 중요했고, 완성차 프로젝트에서는 개발·품질·구매·생산 등 여러 이해관계자와 긴 시간 동안 정보를 맞춰가야 했다.
그러면서 자연스럽게 알게 된 것이 하나 있다.
B2B 영업이라는 일은 생각보다 훨씬 많은 Context 위에서 돌아간다.
고객사가 어디인지 아는 것만으로는 부족하다.
지금 어떤 프로젝트가 진행되고 있는지, 이전 회의에서 무엇을 이야기했는지, 견적이 왜 바뀌었는지, 고객 조직에서 누가 실제 의사결정에 영향을 주는지, 사내에서는 누가 무엇을 약속했는지, 과거 비슷한 프로젝트에서 어떤 문제가 있었는지까지 연결되어야 한다.
그런데 그 정보는 한 곳에 있지 않았다.
CRM에 일부가 있고, 이메일에도 있고, 회의록에도 있고, 제안서와 보고서에도 있고, 때로는 누군가의 머릿속에만 있었다.
정보가 아예 없어서 일을 못 하는 경우도 있었지만, 실제로 더 답답했던 것은 정보는 존재하는데 필요한 순간에 연결되지 않는 경우였다.
고객을 만나는 시간보다 사내에서 과거 자료를 찾고, 관련자에게 확인하고, 흩어진 맥락을 다시 조립하는 데 더 많은 시간이 들어갈 때도 있었다.
영업 현장에 오래 있다 보니 이런 문제를 굳이 별도의 ‘Pain Point 조사’라는 이름으로 수집할 필요가 없었다.
내가 매일 직접 겪고 있었기 때문이다.
그래서 처음에는 나도 ‘좋은 챗봇’을 생각했다
LLM을 처음 업무 시스템에 적용한다고 생각하면 굉장히 매력적인 그림이 나온다.
CRM과 사내 문서를 연결해놓고 영업사원이 이렇게 물어보는 것이다.
“이 고객과 관련해서 지금 내가 알아야 할 내용을 정리해줘.”
또는,
“이 Opportunity의 가장 큰 리스크가 뭐야?”
“다음 고객 미팅에서 무엇을 확인해야 해?”
모델이 충분히 똑똑하고 데이터만 잘 연결되어 있다면 상당히 많은 일을 해낼 수 있다.
실제로 지금의 LLM은 검색하고, 분류하고, 요약하고, 여러 정보를 종합하고, 필요한 Tool을 선택하는 일까지 상당히 잘한다.
그래서 한동안은 나도 더 많은 데이터를 연결하고 더 좋은 Agent를 만들면 문제를 해결할 수 있을 것이라고 생각했다.
그런데 실제 Enterprise 시스템을 설계할수록 생각이 조금씩 달라졌다.
문제는 AI가 충분히 똑똑하지 않아서가 아니었다.
오히려 더 어려운 질문은 이것이었다.
AI에게 무엇을 판단하게 해야 하는가?
자연어로 할 수 있다는 것과, 자연어로 해야 한다는 것은 다르다
Salesforce 같은 업무 시스템에는 이미 수많은 결정적인 사실이 존재한다.
어떤 사용자가 어떤 고객 정보를 볼 수 있는지.
현재 Opportunity가 어떤 Stage인지.
어떤 데이터가 최신인지.
누가 어떤 레코드를 변경할 수 있는지.
승인을 받기 위해 어떤 조건을 충족해야 하는지.
이런 것들은 이미 데이터와 업무 규칙이 알고 있다.
물론 기술적으로는 이것까지 LLM에게 물어볼 수 있다.
하지만 굳이 그럴 이유가 없는 경우가 많다.
이미 시스템이 정확히 알고 있는 사실까지 매번 LLM에게 다시 판단시키면 시스템은 더 똑똑해지는 것이 아니라 오히려 불필요하게 확률적이 된다.
응답 시간이 늘어나고, 호출 비용이 생긴다. 동일한 입력에서도 결과가 달라질 가능성이 생기고, 문제가 발생했을 때 원인을 추적하기도 어려워진다.
무엇보다 구조적으로 이상하다.
데이터베이스와 업무 규칙이 이미 정확히 알고 있는 사실을 확률적인 모델에게 다시 추론하게 만드는 셈이기 때문이다.
그래서 나는 AI 기능을 설계할 때 점점 질문을 바꾸게 됐다.
“여기에 AI를 어떻게 넣을까?”보다 먼저,
“이 업무에서 정말 판단이 필요한 순간은 어디인가?”
를 찾는다.
나는 이런 지점을 ‘Agentic Moment’라고 부르고 있다
예를 들어 고객의 이메일이 들어오면 Salesforce Case의 문의 유형을 자동으로 분류한다고 해보자.
가장 단순하게 만들면 이런 구조다.
Inbound Email
↓
LLM
↓
Category
↓
Case Update
하지만 실제 이메일 업무는 그렇게 깨끗하지 않다.
하나의 Case 안에서도 여러 차례 이메일이 오가고, 대화 도중 문의의 성격이 달라질 수 있다. 이전 이메일을 Forward하면서 이미 처리했던 내용이 다시 붙기도 한다. 실제 문제의 원인은 직전 이메일이 아니라 몇 턴 전 고객의 설명에 들어 있을 수도 있다.
그렇다고 매번 전체 Thread를 LLM에게 넘기는 것도 좋은 방법은 아니다.
내가 선호하는 구조는 역할을 분리하는 것이다.
어떤 Case에 연결해야 하는지, 이미 처리한 이메일이 무엇인지, 어떤 데이터를 사용할 수 있는지는 애플리케이션이 결정한다.
그리고 여러 대화의 맥락을 보고 현재 문의가 무엇인지 판단하는 순간에 LLM을 사용한다.
나는 이런 순간을 일종의 Agentic Moment라고 생각한다.
시스템 전체를 Agent로 만드는 것이 아니라, 추론이 실제로 가치를 만드는 순간에 AI의 능력을 사용하는 것이다.
RAG를 설계하면서도 똑같은 문제를 만났다
RAG도 처음에는 비교적 단순하게 보인다.
문서를 Chunking해서 Vector DB에 넣고, 질문이 오면 Semantic Search를 하고, 관련 Chunk를 LLM에게 전달한다.
데모에서는 꽤 잘 된다.
하지만 실제 기업 데이터로 들어가면 질문마다 적합한 접근 방식이 다르다.
“이 고객의 현재 매출은 얼마인가?”라는 질문은 Vector Search보다 정형 데이터 조회가 정확하다.
“지난 제안에서 고객이 요구한 보안 조건은 무엇인가?”라면 특정 문서를 대상으로 한 Retrieval이 필요하다.
반면 “이 제안서 전체를 검토하고 빠진 논리를 찾아달라”는 요청을 Top-K Chunk 몇 개만 뽑아 해결하려는 것은 애초에 문제 정의가 맞지 않는다.
그래서 모든 질문을 하나의 RAG Pipeline에 밀어 넣는 방식도 점점 선호하지 않게 됐다.
정형 데이터 질문
→ Structured Query
특정 근거 검색
→ Targeted Retrieval
대규모 문서 내부 탐색
→ Hierarchical Retrieval
문서 전체 맥락이 필요한 검토
→ Full-document / Long-context Analysis
여러 데이터에 걸친 복합 판단
→ Source Selection + Reasoning
여기에서도 LLM이 해야 할 일과 애플리케이션이 해야 할 일은 다르다.
LLM은 질문을 이해하고, 정보를 비교하고, 불완전한 맥락 속에서 판단하는 데 강하다.
반면 접근 권한, 데이터 범위, 실행 가능한 행위, 비용 한도, 결과 형식 같은 것은 시스템이 통제하는 편이 훨씬 안전하다.
외부 연구에서도 비슷한 패턴이 보인다
McKinsey의 2025년 글로벌 AI 조사에서도 비슷한 결과가 있었다.
GenAI의 EBIT impact와 관련된 25개 조직 특성을 분석했을 때, 가장 큰 영향을 보인 요인은 모델의 종류나 AI 조직 규모가 아니라 Workflow Redesign이었다.
그런데 GenAI를 사용한다고 응답한 조직 중 실제로 일부 Workflow를 근본적으로 재설계했다고 답한 비율은 21%에 불과했다.
나는 이 결과를 꽤 중요하게 본다.
기업이 AI를 도입한다고 하면서 실제 업무 흐름은 그대로 둔 채,
기존 업무 + Chatbot
만 붙이는 경우가 많기 때문이다.
하지만 실제 비즈니스 가치를 만들려면 질문이 달라져야 한다.
현재 이 업무는 왜 이렇게 진행되는가?
사람이 반드시 판단해야 하는 부분은 무엇인가?
시스템이 이미 알고 있는 것은 무엇인가?
AI가 들어오면 어떤 단계를 없앨 수 있는가?
어떤 판단은 자동화하고, 어떤 결정은 사람이 승인해야 하는가?
결국 AI Transformation은 새로운 UI 하나를 얹는 문제보다 기존 업무를 다시 설계하는 문제에 더 가깝다고 생각한다.
그래서 나는 Chat-first보다 Context-first에 가깝다
영업사원으로 일했던 경험 때문에 이 부분에는 특히 확신이 있다.
현장의 영업사원이 정말 원하는 것이 항상 빈 채팅창인지는 생각해볼 필요가 있다.
Opportunity 화면을 보고 있는 사람에게
“무엇이든 질문하세요.”
라고 말하는 것보다, 시스템이 이미 현재 고객과 Deal의 Context를 알고 있다면 다음과 같은 정보를 먼저 보여주는 것이 더 가치 있을 수 있다.
- 지금 단계에서 놓치고 있는 리스크
- 비슷한 과거 Deal의 승패 요인
- 최근 고객 접점에서 새롭게 등장한 이슈
- 다음 미팅 전에 확인해야 할 사항
물론 Chat은 중요하다.
사람은 시스템이 예상하지 못한 질문을 한다. 탐색적인 문제에서는 자연어 인터페이스가 매우 강력하다.
하지만 모든 AI 기능을 Chat으로 일반화할 이유는 없다.
내가 생각하는 Enterprise AX의 중요한 경쟁력은 Chat UI보다 그 뒤에 있는 Enterprise Context다.
고객, Opportunity, 사람, 활동, 문서, 권한, 조직의 지식과 과거 이력을 시스템이 얼마나 잘 연결하고 있는가.
그리고 그 Context 위에서 필요한 순간에 AI가 얼마나 정확하게 움직이는가.
그렇다고 모든 것을 결정론적으로 만들자는 이야기도 아니다
반대쪽 극단도 있다.
가능한 모든 경우의 수를 미리 정의해서 거대한 Workflow를 만드는 방식이다.
데이터와 질문이 늘어날수록 이런 구조는 빠르게 복잡해진다.
특히,
“이 고객에게 지금 가장 중요한 문제가 무엇인가?”
같은 질문은 모든 판단 경로를 개발자가 미리 작성하기 어렵다.
이런 영역에서는 Agent가 상황을 보고 필요한 Source를 선택하고, 추가 정보를 찾고, 여러 근거를 종합하는 편이 자연스럽다.
그래서 지금 내가 선호하는 방식은 Deterministic Workflow냐 Agent냐 중 하나를 선택하는 것이 아니다.
Permission, Policy, State, Budget, Validation처럼 시스템이 정확하게 통제해야 하는 실행 경계는 애플리케이션에 남겨두고, 그 안에서 해석·검색·비교·추론·생성이 필요한 부분에 Agent의 자율성을 허용하는 구조에 가깝다.
애플리케이션이 경계를 정하고, AI는 그 경계 안에서 판단한다.
내게는 이 구조가 현재 Enterprise AI를 만드는 가장 현실적인 방법으로 보인다.
95%라는 숫자를 다시 보면
그래서 MIT의 95%라는 숫자를 보고도 나는 “AI가 아직 쓸모없다”는 결론을 내리지 않는다.
오히려 반대로 읽는다.
모델의 성능이 빠르게 좋아졌는데도 비즈니스 성과가 그만큼 따라오지 않는다면, 이제 병목은 점점 모델 밖으로 이동하고 있다는 의미일 수 있다.
데이터가 어떻게 연결되는지.
기존 Workflow에 어떻게 들어가는지.
누가 사용할 것인지.
AI의 판단 결과가 실제 업무의 다음 단계로 어떻게 이어지는지.
그리고 그 결과를 어떻게 측정할 것인지.
결국 PoC가 멋지게 동작하는 것과 실제 업무가 바뀌는 것은 다른 문제다.
이 차이가 내가 요즘 Enterprise AX를 볼 때 가장 관심 있게 보는 지점이다.
Peter’s Stack에서 쓰고 싶은 이야기
나는 AI 연구자로 직장 생활을 시작한 사람도, 개발자로 시작한 사람도 아니다.
10년 동안 B2B 제조업의 영업 현장에 있었고, 이후 Enterprise CRM과 AX를 설계하면서 이전에는 단순한 업무의 불편함으로 느꼈던 문제들을 기술의 관점에서 다시 보기 시작했다.
그래서 Peter’s Stack에서는 단순히
“n8n으로 AI Agent 만드는 법”
이나
“요즘 가장 좋은 LLM은 무엇인가”
만 이야기하고 싶지는 않다.
그보다는 실제 업무에 기술을 적용하면서 생기는 질문을 다뤄보고 싶다.
왜 이 부분은 Agent로 만들었는지.
왜 어떤 부분은 오히려 일반 코드로 되돌렸는지.
RAG를 만들었는데 왜 Full Document Context가 다시 필요했는지.
왜 모든 데이터를 Vector DB에 넣지 않았는지.
왜 Chat UI보다 먼저 데이터와 Context를 설계했는지.
그리고 무엇보다,
AI가 할 수 있는 것과 AI에게 맡겨야 하는 것은 왜 다른가.
성공한 설계뿐 아니라 처음에는 좋은 아이디어처럼 보였지만 실제로는 복잡도와 비용만 늘렸던 선택도 함께 기록하려 한다.
지금까지 내가 경험한 AX는 모델 하나를 붙이는 프로젝트가 아니었다.
기존 업무에서 결정적으로 처리해야 할 것과, AI의 비결정적인 판단이 실제로 가치를 만드는 순간 사이의 경계를 다시 그리는 작업에 더 가까웠다.
그 경계를 잘 찾는 것.
아마 그것이 좋은 Enterprise AI와 멋진 데모를 가르는 가장 중요한 차이 중 하나일 것이다.