예측과 행동 사이의 빈틈을 설계하는 법

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Salesforce는 약 12,000개의 seller dashboard와 20개가 넘는 애플리케이션이 정확한 prediction과 alert를 제공해도 사용자가 다음 행동을 결정하지 못하는 문제를 겪었습니다. 글은 risk score 같은 모델 출력을 답이 아닌 signal로 보고, signal·business logic·contextual knowledge를 Next Best Action 계층에서 결합해 대상 account와 행동, 판단 근거, 예상 impact를 담은 recommendation으로 바꾸는 구조를 제안합니다. Model Context Protocol (MCP)은 agent가 필요한 capability를 실행 시점에 호출하고 결과 부재를 정직하게 처리하도록 recommendation 계층과의 계약을 마련합니다. 최종 recommendation은 새로운 dashboard가 아니라 seller가 이미 사용하는 Slack 대화 안에서 요청할 때 제공되어, 예측과 행동 사이의 해석 부담과 attention problem을 함께 줄입니다.

섹션별 상세

01

Salesforce는 2025년 초 약 12,000개의 seller dashboard와 20개가 넘는 애플리케이션이 예측·alert·score·recommendation을 쏟아내지만 사용자가 다음 행동을 결정하지 못하는 문제를 겪었습니다. 시스템의 모델과 pipeline이 기술적으로 정상이어도 사용자가 신호의 의미와 우선순위를 다시 해석해야 한다면 실제 업무 결과로 이어지지 않습니다. 따라서 핵심 실패 지점은 예측 정확도가 아니라 예측과 행동 사이에 해석 계층이 비어 있다는 데 있습니다.

02

churn model이 반환한 risk score 0.83은 계정이 위험하다는 신호일 뿐, 행동 기준과 원인, 다른 renewal과의 우선순위, seller가 취할 조치를 알려주지 않습니다. XGBoost와 gradient boosting을 활용한 모델도 seller performance, pipeline health, skill gap, attrition risk 같은 현상을 평가할 수 있지만 출력이 점수에서 끝나면 사용자가 다시 맥락을 붙여야 합니다. 모델 출력만으로 결정을 내릴 수 없다면 아무리 정확해도 답이 아니라 signal로 취급해야 한다는 기준이 마련됩니다.

03

신호를 행동으로 바꾸려면 AI·machine learning model의 signal, 임계값과 우선순위를 담은 business logic, 조직과 현장의 경험인 knowledge를 함께 연결해야 합니다. 세 입력을 Next Best Action 계층에서 결합하면 특정 account에 어떤 행동을 해야 하는지, 왜 필요한지, 어떤 효과를 기대하는지를 담은 단일 recommendation이 만들어집니다. 이 구조의 핵심은 특정 계층의 이름이 아니라 assessment와 action을 분리해 모델 뒤에 필요한 기능을 명시하는 데 있습니다.

AI·ML model의 signal, business rules, institutional knowledge, field insights를 Next Best Action MCP에 입력하고 recommendation을 agent를 통해 전달하는 구조입니다. — Diagram도표는 prediction을 실행 가능한 recommendation으로 바꾸는 세 가지 핵심 입력과 전달 경로를 한 흐름으로 묶습니다. 특히 MCP 계층이 여러 입력을 하나의 recommendation으로 결합하고 seller의 업무 흐름에 전달한다는 글의 구현 패턴을 보완합니다.

04

여러 renewal이 동시에 위험 신호를 받으면 business rule만으로는 어느 고객에게 먼저 연락할지, 겉으로 드러난 blocker가 실제 원인인지, 고객의 발언에 맞춰 discovery call을 어떻게 바꿀지 결정하기 어렵습니다. 정보는 common sense, 문서화된 content, 실무 know-how, 맥락 의존적인 tacit knowledge로 이어지는 spectrum을 이루며 뒤쪽으로 갈수록 경험과 상황 판단의 비중이 커집니다. signal은 저렴하게 확장되지만 knowledge는 사람에게 오랜 기간 축적되고 일반적인 best practice로 평탄화할 때 가치가 줄어들 수 있어, 병목이 prediction이 아니라 knowledge인지 먼저 확인해야 합니다.

정보 spectrum을 common sense, content, know-how, knowledge로 나누고 오른쪽의 희소하고 암묵적인 knowledge 영역을 핵심 초점으로 표시한 도표입니다. — Diagram도표는 예측 신호를 해석하는 데 필요한 정보가 일반 상식에서 맥락 의존적인 전문 판단으로 이동할수록 희소해진다는 글의 논지를 시각화합니다. Salesforce가 recommendation 계층에서 특히 capture하기 어려운 contextual knowledge에 주목한 이유와 직접 연결됩니다.

common sense와 content, know-how, knowledge를 종 모양 분포의 구간으로 배치하고 지식이 희소한 오른쪽 꼬리를 초점 영역으로 표시한 도표입니다. — Diagram이미지의 오른쪽 꼬리는 일반화하기 어려운 tacit·contextual judgment가 recommendation 품질의 병목이 될 수 있다는 설명을 시각적으로 나타냅니다. 모델의 prediction 정확도를 높이는 것만으로는 고객별 대응 판단을 채우기 어렵다는 글의 핵심과 연결됩니다.

05

Salesforce는 agent와 recommendation 계층 사이의 계약으로 Model Context Protocol (MCP)을 사용했습니다. MCP는 callable tool의 입력 schema와 return type을 노출해 agent가 요청에 따라 Next Best Action record와 KPI history 같은 기능을 실행 시점에 선택하게 하며, 결과가 없으면 빈 상태를 인식하고 기능 자체가 없으면 추측 대신 거절할 수 있게 합니다. 중요한 설계 판단은 MCP라는 특정 표준보다 agent가 무엇을 가져올 수 있고 각 capability가 무엇을 반환하며 부재를 어떻게 표현하는지 명시적인 계약을 갖추는 데 있습니다.

06

여러 도메인의 capability를 중앙 MCP 계층에 모을지 각 도메인 팀이 직접 소유할지는 데이터 governance와 책임 범위에 따라 결정해야 합니다. 중앙화 topology는 하나의 통합 계약을 제공하고 분산 topology는 도메인 팀이 기능과 계약을 유지하게 하므로, 누가 데이터를 보유하고 capability와 계약을 관리할 수 있는지 먼저 매핑하는 접근이 필요합니다. 아키텍처를 완벽하게 구성해도 사용자가 새로운 애플리케이션을 찾아가야 한다면 dashboard를 하나 더 만든 것과 같아져 기존의 attention problem을 되풀이하게 됩니다.

07

seller가 이미 deal conversation과 follow-up을 진행하는 Slack에서 “Plan my day”를 요청하면 agent는 우선순위가 높은 account, 그 순위를 만든 signal, 잠재적 impact, 관련 knowledge를 대화 안에서 반환합니다. 이 pull 방식은 별도의 broadcast, 아침 digest, unsolicited notification을 강제하지 않고 사용자가 필요할 때 recommendation을 받게 합니다. 최종 점검 기준은 intelligence를 개선한 뒤 사용자를 또 다른 destination으로 보내는지 여부이며, 목표는 insight를 모아둔 장소를 만드는 것이 아니라 사람이 signal을 decision으로 바꾸기 위해 이동해야 하는 단계를 없애는 데 있습니다.

약 12,000개의 dashboard와 20개가 넘는 애플리케이션에서 생성되는 신호를 하나의 Next Best Action으로 압축해 seller 대화 화면에 전달하는 흐름을 나타낸 도표입니다. — Diagram왼쪽의 다수 dashboard와 신호가 오른쪽의 seller용 대화형 recommendation으로 좁혀지는 구조는 정보 과잉을 행동 중심 출력으로 바꾸는 문제를 보여줍니다. 글에서 언급한 “Plan my day” 요청과 Slack 안에서 우선순위 account와 다음 행동을 받는 방식에 대응합니다.

수많은 dashboard와 신호가 중앙의 화살표를 거쳐 seller가 사용하는 단일 대화형 recommendation 화면으로 전달되는 모습을 보여주는 도표입니다. — Diagram다수의 정보원을 한 화면의 우선순위 recommendation으로 바꾸는 시각적 흐름이 글의 문제 정의와 해결 방향을 압축합니다. 별도 dashboard를 추가하는 대신 사용자가 이미 대화 중인 공간에서 필요한 행동을 요청하도록 설계한 점을 뒷받침합니다.

용어 해설

Model Context Protocol (MCP): — AI agent와 외부 기능 사이의 연결 계약을 정의하는 개방형 표준입니다. 호출 가능한 도구의 입력 스키마와 반환 형식을 정해 agent가 실행 시점에 필요한 기능을 선택하게 하며, 결과가 없거나 기능이 없을 때 추측하지 않고 부재를 처리하도록 만듭니다.
Next Best Action 계층(Next Best Action): — AI·머신러닝 신호를 business logic과 업무 지식에 결합해 실행 가능한 권고로 바꾸는 계층입니다. 단순 위험 점수 대신 대상 계정, 권고 행동, 판단 근거, 예상 효과를 함께 반환해 예측과 실제 의사결정 사이의 공백을 줄입니다.
비즈니스 로직(Business Logic): — 모델 출력의 해석과 우선순위를 결정하는 업무 규칙입니다. 임계값, 우선순위, 운영 규칙, 현재 business motion을 사용해 어떤 신호에 어떻게 대응할지 정하며, 신호 자체가 행동을 결정하지 못하는 문제를 보완합니다.
맥락 지식(Contextual Knowledge): — 특정 상황에서 무엇이 효과적인지 판단하는 조직 내부와 현장 경험 기반의 지식입니다. 문서화된 절차보다 고객의 조직적 특성이나 실제 장애 요인을 해석하는 데 가깝고, 사람에게 축적되기 때문에 신호처럼 저렴하게 확장하기 어렵습니다.
Agent 아키텍처(Agent Architecture): — AI agent가 여러 도메인의 데이터와 기능을 어떤 구조로 이용할지 정하는 설계입니다. 중앙화 topology는 통합 계약을 제공하고 분산 topology는 도메인 팀이 기능을 소유하게 하며, 최종 선택은 데이터와 계약의 소유권 및 governance에 좌우됩니다.

기술

XGBoost
gradient boosting
Model Context Protocol (MCP)
MCP
Slack

활용 사례

seller의 renewal 우선순위 결정
pipeline health와 stalled opportunity 대응
seller performance 및 skill gap 관리
attrition risk와 product adoption 대응
AI agent를 통한 업무 recommendation 제공