Morgan Stanley Wealth Semantic Layer: 고객 관계 데이터 위에 경계 정한 에이전트를 올린 방법

Morgan Stanley 자산관리 부문은 에이전트를 붙이기 전에 데이터를 계좌 단위가 아니라 고객 관계 단위로 다시 묶었습니다. 지금은 그 위에 에이전트가 읽을 시맨틱 레이어를 얹으면서 에이전트마다 볼 데이터와 할 수 있는 행동, 사람이 넘겨받을 시점을 미리 정해 둡니다. 우리 회사에 옮기려면 모델보다 먼저 고객 단위 데이터 키와 업무 용어 정의, 에이전트별 권한 표를 만들어야 합니다.

요약

CIO Dive의 Makenzie Holland 기자는 2026년 10월 26일, Morgan Stanley 자산관리 부문의 기술 CIO인 Hina Shamsi를 인터뷰해 이 부문의 AI 추진 방식을 전했습니다. 출발점은 약 8년 전의 데이터 전환입니다. 이 부문은 원래 데이터를 계좌 단위로 봤습니다. 그런데 고객은 계좌 하나가 아니라 회사와의 관계 전체를 기준으로 서비스를 원했습니다. 그래서 부문은 데이터를 고객 관계 중심으로 다시 짰습니다. 이 기반 위에서 next-best action(어드바이저에게 다음에 할 일을 추천하는 머신러닝 기능) 같은 기능이 나왔습니다. 이후 AI 활용은 개별 작업을 돕는 대화형 도구에서 여러 사내 플랫폼에 걸친 업무를 이어서 처리하는 orchestrated agentic workflow(여러 단계와 시스템을 묶어 실행하는 에이전트 워크플로)로 옮겨 가고 있습니다.

데이터 기반을 먼저 바꾼 뒤 그 위에 ML, 대화형 도구, 에이전트 워크플로가 차례로 올라갔습니다.

지금 부문이 공들이는 곳은 데이터 플랫폼과 context(에이전트가 판단에 쓰는 배경 정보), 그리고 시맨틱 레이어(데이터에 업무 의미를 붙여 생성형 AI와 에이전트가 이해하게 하는 계층)입니다. Shamsi는 에이전트의 품질이 결국 가진 맥락과 데이터를 넘지 못한다고 봅니다. 에이전트는 세 영역에서 움직입니다. 고객이 직접 쓰는 client assist agent, 고객 서비스 직원을 돕는 service assist agent, 어드바이저의 일상 업무를 맡는 adviser assist agent입니다. 서비스 영역에서는 생산성이 오르고 있다고 밝혔지만 수치는 공개하지 않았습니다. 대신 통제를 강조했습니다. 에이전트마다 접근할 데이터, 접근 방식, 실행할 행동, 사람이 개입할 시점의 경계를 정해 둡니다. 아래에서는 관계 중심 데이터, 시맨틱 레이어, 워크플로 오케스트레이션, 세 에이전트, 경계 네 축을 차례로 풀고 우리 조직에 옮길 때 정할 것을 덧붙였습니다.

세 영역 에이전트를 사용자와 하는 일로 나눈 표. 상태 칸은 기사에 나온 내용만 적었습니다.

핵심 메커니즘

Relationship-centric Data: 계좌가 아니라 고객 관계로 묶은 데이터

관계 중심 데이터는 한 고객이 가진 여러 계좌와 상품, 거래 이력을 고객(또는 관계) 하나의 키 아래로 모은 구조입니다. 계좌 중심 구조에서는 계좌마다 따로 데이터를 읽어야 해서 고객 전체 그림이 나오지 않습니다. 관계 중심으로 묶으면 한 번의 조회로 고객의 전체 포트폴리오가 보입니다. Morgan Stanley는 이 전환을 약 8년 전에 했습니다. 기사는 그 덕분에 넓은 포트폴리오 데이터를 보고 어드바이저에게 다음 행동을 추천하는 next-best action이 가능해졌다고 전합니다.

이 구조는 한 고객이 여러 상품·계약을 가진 업종에 맞습니다. 금융, 보험, B2B 제조사의 고객사 관리가 그렇습니다. 고객 한 명이 한 계약만 갖는 업종에서는 효과가 작습니다. 가상 예시로, B2B 부품 회사가 고객사 한 곳의 공장 세 곳 주문을 각각 다른 거래처 코드로 관리하면 에이전트는 이 고객사의 연간 거래 규모를 답하지 못합니다. 세 코드를 고객사 하나로 묶는 일이 이 메커니즘에 해당합니다.

같은 고객을 계좌 단위로 보느냐, 관계 하나로 보느냐의 차이. 에이전트가 고객 전체를 이해하려면 오른쪽이 필요합니다.

Semantic Layer: 에이전트가 읽는 업무 의미 계층

시맨틱 레이어는 원천 데이터 위에 업무 용어와 정의를 얹어, 사람과 AI가 같은 뜻으로 데이터를 읽게 하는 계층입니다. 예를 들어 ‘관계’, ‘가용 현금’, ‘수익자’가 어느 테이블의 어떤 필드를 어떤 규칙으로 계산한 값인지를 한곳에 정의합니다. 에이전트는 테이블 구조를 추측하지 않고 이 정의를 따라 데이터를 부릅니다. 기사는 시맨틱 레이어를 생성형 AI와 에이전트 워크플로가 이해하는 계층으로 설명하고 데이터 플랫폼·맥락과 함께 기술 리더가 계속 투자할 핵심으로 꼽습니다.

이 계층은 같은 용어가 부서마다 다르게 계산될 때 가장 필요합니다. 데이터가 한 시스템에만 있고 정의가 하나뿐이면 얇게 시작해도 됩니다. 기사는 시맨틱 레이어의 구체 구조를 밝히지 않았습니다. 아래 기술 디테일에 용어 사전 필드 예시를 붙였습니다.

에이전트는 원천 테이블을 직접 해석하지 않고 정의된 용어를 따라 데이터를 읽습니다.

Orchestrated Agentic Workflow: 여러 시스템에 걸친 일을 이어서 처리하는 에이전트

오케스트레이션 워크플로는 하나의 요청을 여러 단계로 나누고 단계마다 필요한 시스템을 불러 끝까지 처리하는 방식입니다. 대화형 도구는 질문 하나에 답 하나를 냅니다. 오케스트레이션 워크플로는 조회, 확인, 실행을 이어서 하고 그 사이 결과를 다음 단계로 넘깁니다. 기사에 따르면 부문의 목표는 에이전트가 어드바이저나 지원 인력을 대신해 여러 시스템에 걸친 일을 실행하되, 감독과 결정은 사람이 계속 쥐는 것입니다.

이 방식은 한 업무가 서너 개 이상의 애플리케이션을 거칠 때 효과가 큽니다. Shamsi는 서비스 업무가 여러 애플리케이션과 플랫폼에 걸쳐 있다고 말했습니다. 한 화면에서 끝나는 업무라면 대화형 도구로 충분합니다. 가상 예시로, 고객이 수익자를 바꿔 달라고 요청하면 에이전트는 고객 확인, 현재 수익자 조회, 변경 서류 작성 순서로 진행하고 마지막 반영 전에 직원의 확인을 받습니다.

가상 예시 흐름. 에이전트가 여러 시스템을 이어 처리하고 실행 앞에서 사람이 확인합니다.

Three Assist Agents: 고객, 서비스 직원, 어드바이저를 맡는 세 에이전트

부문은 에이전트를 사용자별로 셋으로 나눴습니다. client assist agent는 이미 나와 있습니다. 고객이 쉬운 말로 묻고 흔한 업무를 처리하게 하는 가상 비서의 첫 버전이고 앞으로 계좌별 맞춤 지원과 더 풍부한 맥락을 더할 계획입니다. service assist agent는 고객 서비스 직원(client service associate) 곁에서 일하는 동료 역할입니다. 정보를 찾고 송금, 계좌 개설, 수익자 변경 같은 행동을 실행합니다. adviser assist agent는 어드바이저의 일상 업무를 맡아, 어드바이저가 모든 수작업을 직접 하지 않고 일을 지시하게 합니다.

사용자별로 나누면 에이전트마다 볼 데이터와 할 수 있는 행동이 달라지고 권한 경계를 짜기 쉬워집니다. 고객용 에이전트는 본인 정보만 보고 직원용 에이전트는 담당 고객 범위에서 거래를 준비합니다. 한 에이전트에 모든 사용자를 태우면 권한 표가 복잡해집니다.

데이터 범위 칸은 이 노트의 설계 예시이고 행동 칸은 기사 내용입니다.

Defined Boundaries: 에이전트 권한을 가르는 네 축

경계는 에이전트의 자율을 무한정 두지 않으려고 미리 그어 둔 선입니다. Shamsi는 에이전트 능력이 커질수록 통제가 더 중요해진다고 보고 네 축으로 경계를 정합니다. 어떤 정보에 접근하나, 어떻게 접근하나, 어떤 행동을 할 수 있나, 언제 사람이 개입해야 하나입니다. 그는 가드레일, 권한, 모니터링, 사람의 감독을 아무리 강조해도 지나치지 않다고 말했습니다.

네 축은 서로 다른 장치로 구현됩니다. 정보 범위는 데이터 권한으로, 접근 방식은 허용된 도구(API)로, 행동은 실행 가능한 작업 목록으로, 개입 시점은 승인 규칙으로 막습니다. 프롬프트에 “하지 말 것”을 적는 것만으로는 이 네 축을 지킬 수 없습니다. 실제 막는 곳은 에이전트가 시스템을 부르는 관문입니다.

네 축은 기사 내용, 구현 장치 칸은 이 노트가 덧붙인 설계 예시입니다.

통념과 다른 주장

흔히 이렇게 봅니다에이전트 도입은 좋은 모델과 도구를 고르는 데서 시작한다고 봅니다.

저자는 이렇게 봅니다Shamsi는 에이전트가 가진 맥락과 데이터 수준을 넘지 못한다고 봅니다. 그래서 투자의 중심을 데이터 플랫폼과 시맨틱 레이어에 둡니다.

근거부문은 약 8년 전 데이터를 관계 중심으로 바꿨고 그 기반이 next-best action 같은 ML 기능을 먼저 가능하게 했습니다. 에이전트는 그 위에 올라가는 다음 단계입니다.

모델보다 데이터 정의가 먼저라는 순서. 왼쪽은 흔한 출발점을 일반화한 것입니다.

흔히 이렇게 봅니다에이전트가 똑똑해지면 사람 확인 단계를 줄여 가면 된다고 봅니다.

저자는 이렇게 봅니다능력이 커질수록 통제가 더 중요해집니다. 에이전트가 여러 시스템에서 일을 실행해도 감독과 결정은 사람이 쥡니다.

근거service assist agent는 송금·계좌 개설·수익자 변경처럼 되돌리기 어려운 행동을 다룹니다. 부문은 이런 에이전트에 접근·행동·개입 시점의 경계를 둡니다.

실행 범위가 넓어질수록 경계를 더 분명히 긋는다는 원칙.

저자가 든 사례

사례. Morgan Stanley 자산관리 부문의 에이전트 전환

구분	내용
상황	데이터가 계좌 중심이라 고객 관계 전체를 보지 못했습니다. AI 활용은 개별 작업용 대화형 도구에 머물러 있었습니다.
한 일	약 8년 전 데이터를 관계 중심으로 바꿨습니다. 지금은 데이터 플랫폼·맥락·시맨틱 레이어에 투자하고 고객·서비스·어드바이저 세 영역 에이전트를 경계 안에서 운영합니다.
결과	next-best action 같은 ML 기능이 가능해졌습니다. client assist agent는 출시됐고 service assist agent는 생산성을 높이고 있다고 밝혔습니다. 구체 수치는 원문에서 밝히지 않았습니다.
연결	Relationship-centric Data, Semantic Layer, Orchestrated Agentic Workflow, Defined Boundaries 네 메커니즘이 한 회사 안에서 차례로 쌓인 사례입니다.

결과 칸의 생산성 향상은 기사에 수치 없이 언급됐습니다.

기술 디테일: 우리 데이터 위에 에이전트를 올리려면

아래는 기사의 원칙을 실제로 돌릴 때 필요한 설계입니다. 필드명과 숫자는 모두 가상 예시입니다.

관계 중심 데이터를 에이전트가 쓰게 하려면(Relationship-centric Data) 먼저 고객 하나를 가리키는 키를 정합니다. relationship_id 하나 아래 account_id, household_member_id, product_id를 연결 테이블로 묶습니다. 시스템마다 다른 고객 코드는 이름·생년월일·사업자번호 같은 기준으로 매칭하고 매칭 신뢰도가 낮은 건(예: 0.9 미만)은 사람이 확인합니다. 파일럿 전에 상위 고객 500곳의 매칭률을 재 보고 95%에 못 미치면 에이전트보다 매칭부터 고칩니다.

시맨틱 레이어를 만들려면(Semantic Layer) 업무 용어를 하나씩 정의한 사전부터 씁니다. 에이전트는 SQL을 직접 짜지 않고 이 사전에 등록된 용어만 조회 도구로 부릅니다. 처음에는 서비스 요청 상위 20개에 나오는 용어 40~60개면 충분합니다.

{
  "term": "available_cash",
  "label_ko": "가용 현금",
  "definition": "결제 대기분을 뺀 즉시 이체 가능 금액",
  "source": "ledger.balances.cash - ledger.pending.settlement",
  "grain": "account",
  "rollup_to": "relationship_id",
  "owner": "자산관리 운영팀",
  "pii_level": "confidential",
  "allowed_agents": ["service_assist", "adviser_assist"],
  "updated_at": "2026-10-20"
}

여러 시스템을 잇는 행동을 묶으려면(Orchestrated Agentic Workflow, service assist agent) 행동마다 도구를 하나씩 만들고 세 등급으로 나눕니다. 조회(get_relationship_summary)는 바로 실행합니다. 준비(draft_transfer, draft_beneficiary_change)는 변경안만 만들어 화면에 띄웁니다. 실행(submit_transfer)은 직원이 승인해 발급된 approval_id가 있어야 호출됩니다. 송금처럼 두 번 실행되면 안 되는 행동에는 idempotency_key(같은 요청을 한 번만 처리하게 하는 키)를 붙입니다. 모델 출력은 JSON 스키마로 고정하고 temperature는 0~0.2로 둡니다.

경계 네 축을 코드로 지키려면(Defined Boundaries) 프롬프트가 아니라 도구 관문에 정책 표를 둡니다. 관문은 호출마다 에이전트 ID, 사용자 ID, 데이터 범위, 행동 등급을 확인하고 어긋나면 거부합니다. 모든 호출은 agent_id, user_id, tool, data_scope, action_tier, approval_id, result를 남겨 감사 기록으로 씁니다. 모니터링 지표는 도구 거부율, 사람 이관률, 승인 후 반려율입니다.

가상 예시. 등급은 도구 관문에서 확인하고 실행 등급은 사람 승인 없이는 호출되지 않습니다.

평가와 실패 대응(모든 메커니즘) 지난 분기 실제 서비스 요청 200건을 비식별 처리해 시험셋을 만듭니다. 요청마다 같은 입력을 3회 돌려 고른 도구와 채운 필드가 같은지 봅니다. 세 번 중 한 번이라도 다르면 그 요청 유형은 준비 등급에 묶어 둡니다. 실패는 세 가지로 나눠 대응합니다. 사전에 없는 용어가 나오면 답을 지어내지 말고 “정의 없음”으로 직원에게 넘깁니다. 정의가 두 개 충돌하면 owner에게 알림을 보냅니다. 고객 매칭이 불확실하면 실행 등급 도구를 잠급니다.

가상 예시. 실패할 때 에이전트가 추측하지 않고 멈추거나 사람에게 넘기게 합니다.

현업 실행 디테일: 누가, 언제, 무엇을

service assist agent 패턴을 우리 조직의 고객 서비스 업무에 6주 파일럿으로 옮긴다고 가정한 예시입니다.

역할	담당	하는 일
업무 스폰서	고객 서비스 본부장	대상 업무 선정, 진행 판정
데이터 오너	고객 데이터 담당	고객 키 매칭, 용어 정의 승인
서비스 리더	서비스팀 파트장 1명	요청 유형 정리, 승인 규칙 작성, 파일럿 직원 5~8명 운영
플랫폼 엔지니어	AX 추진팀 2명	도구 관문, 정책 표, 로그 구축
통제 담당	컴플라이언스·보안	행동 등급과 한도 검토, 감사 기록 확인

시작 전 준비물은 지난 분기 서비스 요청 로그, 요청 유형 상위 20개 목록, 업무마다 거치는 시스템 목록, 현재 처리 시간 기준값입니다.

주차	할 일	산출물
1주	요청 유형 상위 20개와 거치는 시스템 정리	업무 지도
2주	상위 고객 매칭률 측정, 용어 40~60개 정의	고객 키 매칭표, 용어 사전 v1
3주	조회·준비 도구 구축, 정책 표 작성	도구 목록, 권한 표
4주	시험셋 200건 3회 반복 평가	평가 결과표
5~6주	직원 5~8명 실사용(조회·준비 등급만)	처리 시간·이관률 비교

가상 예시 일정. 실행 등급 도구는 6주 안에 열지 않습니다.

확인 질문은 다섯 가지입니다. 이 업무는 몇 개의 시스템을 거치나? 같은 고객이 시스템마다 다른 코드로 있나? 이 용어의 정의를 누가 승인하나? 되돌리기 어려운 행동은 무엇이고 한도는 얼마인가? 에이전트가 멈췄을 때 누가 넘겨받나?

**진행 판정 기준(예시)**은 다음과 같습니다. 고객 키 매칭률 95% 이상, 시험셋 3회 반복 일치율 90% 이상, 권한 밖 호출이 관문에서 100% 차단, 실사용 기간 처리 시간 20% 이상 단축입니다. 넷을 모두 넘으면 실행 등급 도구를 한 종류(예: 주소 변경처럼 금액이 없는 변경)부터 엽니다. 하나라도 못 넘으면 원인을 데이터·정의·도구 중 어디에 있는지 가려 2주 더 돌립니다.

적용 순서는 데이터부터입니다. 국내 금융사라면 고객 단위 통합 키가 이미 있는 곳이 많으니 바로 시맨틱 레이어 작업으로 들어갈 수 있습니다. 제조사라면 고객사·납품처 코드가 영업·물류·회계 시스템마다 갈라져 있는 경우가 많아 매칭이 먼저입니다. 첫 에이전트는 고객용보다 직원 곁에서 일하는 service assist 형태로 고르는 편이 안전합니다. 사람이 결과를 바로 확인하고 고칠 수 있기 때문입니다. 스폰서는 IT가 아니라 서비스 업무 책임자로 세우고 용어 사전의 owner를 현업 부서로 지정해야 정의가 계속 관리됩니다.

가상 예시 적용 순서. 데이터 키와 정의를 먼저, 실행 권한은 마지막에 엽니다.

원문 사례

항목	내용
매체·저자	CIO Dive, Makenzie Holland, 2026년 10월 26일
인터뷰 대상	Hina Shamsi, Morgan Stanley 자산관리 기술 CIO
데이터 기반	약 8년 전 계좌 중심에서 관계 중심으로 전환, next-best action 등 ML 기능 가능
현재 투자	데이터 플랫폼, 맥락, 시맨틱 레이어
AI 활용 변화	개별 작업용 대화형 도구에서 여러 플랫폼에 걸친 오케스트레이션 워크플로로
client assist agent	출시. 쉬운 말 질문과 흔한 업무, 가상 비서 첫 버전. 계좌별 지원 추가 예정
service assist agent	서비스 직원 동료. 조회, 송금, 계좌 개설, 수익자 변경. 생산성 향상(수치 비공개)
adviser assist agent	어드바이저 일상 업무 처리, 어드바이저는 지시
통제	접근 정보, 접근 방식, 행동, 사람 개입 시점의 경계. 가드레일·권한·모니터링·사람 감독 강조

핵심 개념

next-best action: 고객 데이터를 보고 담당자에게 다음에 할 일을 추천하는 머신러닝 기능.
context: 에이전트가 판단할 때 함께 받는 배경 정보. 고객 이력, 정의, 규칙이 여기에 든다.
client service associate: 고객 요청을 처리하는 서비스 직원. service assist agent의 사용자.
financial advisor: 고객 자산을 맡아 조언하는 어드바이저. adviser assist agent의 사용자.
guardrails: 에이전트가 넘지 말아야 할 선을 시스템으로 막는 장치.
idempotency key: 같은 요청이 두 번 들어와도 한 번만 처리하게 하는 고유 키. 송금 같은 행동에 붙인다.

내 메모

TODO: 내 생각 추가

원문: Makenzie Holland, “A look inside the AI playbook at Morgan Stanley’s wealth division”(CIO Dive, 2026.10.26). 요약·핵심 메커니즘의 원문 내용·통념과 다른 주장·사례·원문 사례 표는 기사에 나온 Hina Shamsi의 설명을 AX Review가 다시 정리했습니다. 기사는 생산성 수치와 시맨틱 레이어의 구체 구조를 공개하지 않았습니다. 기술·현업 디테일, 필드명, 권한 표, 일정·판정 기준, 적용 제언, 인포그래픽은 새로 작성했으며 숫자는 모두 가상 예시입니다. 원문 전체는 CIO Dive에서 볼 수 있습니다.