Multi-Agent Orchestration: 금융사 59%가 쓰지만 전사로 조율한 곳은 10%

금융사의 59%가 멀티에이전트를 시험하거나 배포하고 있지만, 전사로 조율한 곳은 10%이고 절반가량은 투자 수익을 꾸준히 입증하지 못합니다. 따라 하려면 모델 라우팅으로 토큰 비용을 먼저 통제하고, 에이전트가 데이터에 접근하고 행동하는 길을 한 실행 기반에서 기록하며, AI 예산을 업무 성과 지표에 묶어야 합니다.

요약

CIO Dive의 Makenzie Holland 기자는 2026년 11월 5일 Capgemini Research Institute의 금융업 조사를 다뤘습니다. 보고서 이름은 World Cloud Report for Financial Services 2027입니다. Capgemini는 2026년 6~7월 14개 시장의 금융사 경영진 1,100명에게 설문했습니다. 응답자는 소매은행, 자산관리, 결제, 기업·투자은행, 손해보험, 생명보험, 건강보험의 7개 업권에 고르게 나뉩니다. 6~9월에는 같은 시장의 금융사와 하이퍼스케일러(대형 클라우드 사업자) 임원을 따로 인터뷰했습니다. 조사의 중심은 은행·보험 핵심 업무에 들어가는 멀티에이전트 시스템입니다. 여러 AI 에이전트가 일을 나눠 맡고 결과를 서로 넘기는 구조를 말합니다.

결과는 도입과 성과 사이에 거리가 있음을 보여 줍니다. 59%가 멀티에이전트를 시험하거나 배포하고 있지만, 에이전트를 전사에서 조율해 스스로 돌게 만든 곳(enterprise-wide orchestration)은 10%였습니다. 응답 기업의 절반가량은 에이전트 AI의 투자 수익을 꾸준히 입증하지 못했고, 계속 투자할지 판단할 틀도 없었습니다. Capgemini의 금융 서비스 클라우드 글로벌 책임자 Ravi Khokhar는 “adoption alone does not create value”라고 말했습니다. 금융사들은 비용과 성능을 다잡는 쪽으로 움직였습니다. 90%가 모델 라우팅을 쓰거나 도입할 계획이고, 클라우드를 에이전트의 공통 실행 기반으로 다시 보며, AI 예산의 근거를 운영 효율에서 사업 성과로 옮기고 있습니다. 아래에서는 이 흐름을 개념별로 풀고, 실제로 돌릴 때 필요한 설계와 일정을 덧붙였습니다.

핵심 메커니즘

Orchestration Gap: 에이전트를 쓰는 곳과 전사로 조율한 곳의 거리

Khokhar는 금융사가 12개월 만에 개별 업무를 맡는 에이전트 실험을 지나, 사업 부문 전체에서 행동을 조율하는 멀티에이전트로 넘어가고 있다고 봤습니다. 에이전트 하나는 정해진 일 하나만 합니다. 멀티에이전트에서는 접수, 서류 확인, 심사, 고객 안내를 여러 에이전트가 나눠 맡고 결과를 다음 에이전트에 넘깁니다. 전사 조율은 이 넘김이 부서와 시스템의 경계를 건너서도 사람 손을 덜 거치고 이어지는 상태입니다. 조사에서 시험·배포는 59%, 전사 조율은 10%, 이 역량을 전사 규모의 체계로 굳힌 곳은 5%였습니다. 시범 과제 수로 성숙도를 재면 회사가 실제보다 앞서 있다고 착각하기 쉽습니다. 넘김이 몇 개 부서를 건너는지, 그 넘김을 누가 기록하고 통제하는지를 함께 봐야 위치가 보입니다. 가상 예시로, 대출 접수 에이전트가 영업점 안에서만 돌면 시험 단계이고, 심사와 사후관리 부서의 에이전트까지 같은 기록을 이어받으면 조율 단계입니다.

Intelligent Model Routing: 질의마다 감당할 수 있는 가장 싼 모델로 보내는 장치

모델 라우팅은 들어온 질의를 품질 기준을 맞추는 모델 가운데 가장 비용 효율적인 모델로 보내는 장치입니다. 응답 기업의 90%가 이미 쓰거나 도입할 계획이고, 대부분은 1년 안에 갖출 것으로 봤습니다. 토큰 지출이 늘자 비용과 성능을 함께 다잡으려는 움직임입니다. 작동 순서는 단순합니다. 질의가 들어오면 작은 분류 모델이 유형과 난이도를 판단합니다. 라우터는 그 판단으로 소형 모델, 자체 모델, frontier 모델(가장 성능이 높은 최신 범용 모델) 가운데 하나를 고릅니다. 기사는 Bank of America가 소형 분류 모델로 모델을 고르는 라우팅 계층 Orchestra를 쓰고 있다고 전했습니다. 에이전트가 여러 개면 에이전트끼리 주고받는 호출마다 이 판단이 붙으므로 효과가 커집니다. 반대로 신용 결정처럼 규제상 판단 근거를 설명해야 하는 일은 모델이 바뀌면 결과 일관성이 흔들릴 수 있어, 라우팅에서 빼고 고정 경로로 두는 편이 안전합니다.

Cloud as Execution Layer: 에이전트의 접근·결정·행동을 한곳에서 다스리는 기반

Capgemini는 금융사가 클라우드를 에이전트가 정보에 접근하고, 결정하고, 행동하는 방식을 조율하는 공통 운영 계층으로 보기 시작했다고 정리했습니다. 이유는 금융업의 요구 조건에 있습니다. 규제 승인, 데이터 레지던시(데이터를 정해진 국가나 지역에 두는 요건) 인증, 보안과 ID 통제, 대규모 감사 가능성을 모두 갖춰야 합니다. 그래서 52%가 멀티에이전트 거버넌스를 맡길 클라우드 파트너로 하이퍼스케일러를 선호했습니다. 경영진 10명 중 8명은 현대화의 우선 과제로 기술 부채 축소를 꼽았습니다. 오래된 시스템이 남아 있으면 에이전트가 데이터를 읽고 행동할 길이 좁아진다고 읽을 수 있습니다. Khokhar는 앞서는 소수가 클라우드를 범용 상품이 아니라 에이전트 전략의 기반으로 다룬다고 말했습니다. 이미 클라우드로 옮긴 회사라도, 에이전트별 권한과 행동 기록이 한곳에 모이는지는 따로 확인해야 합니다.

Outcome-Based Funding: AI 예산의 근거를 효율에서 사업 성과로 옮기기

AI 예산을 정당화하는 근거가 바뀌고 있습니다. Capgemini는 2028년까지 사업 성과를 AI 투자 판단의 주된 기준으로 드는 경영진이 141% 늘고, 효율을 주된 기준으로 드는 경영진은 42% 줄 것으로 내다봤습니다. 두 숫자는 응답자 비중의 변화율이며 금액이 아닙니다. 작동 방식으로 보면, 예산 심사에서 묻는 질문이 “몇 시간을 아꼈나”에서 “어떤 사업 지표가 얼마나 움직였나”로 바뀝니다. 절반가량이 수익을 꾸준히 입증하지 못한 이유도 여기서 읽힙니다. 절약한 시간은 쉽게 세지만, 그 시간이 매출이나 손실률로 이어졌는지는 업무별 지표를 미리 정해 두지 않으면 보이지 않습니다. 상위 5%가 다른 세 가지 가운데 하나도 AI 지출을 측정 가능한 재무 성과에 연결한 것이었습니다.

Hybrid Sourcing: 만들 것, 살 것, 빌릴 것을 나누는 조달 방식

hybrid sourcing(혼합 조달)은 에이전트 역량을 한 가지 방식으로만 마련하지 않고 셋을 섞는 방식입니다. 차별화가 필요한 역량은 직접 만들고, 빨리 배포할 곳은 패키지 솔루션을 사고, 전문성과 기술의 폭이 필요하면 파트너와 손잡습니다. Capgemini는 3년 안에 3분의 2 이상의 금융사에서 이 방식이 주류가 될 것으로 봤습니다. 실제로는 업무마다 고르는 기준을 정해 두는 일이 핵심 결정입니다. 예를 들어 고객 데이터와 심사 노하우가 경쟁력인 업무는 자체 개발 쪽에, 내부 IT 지원처럼 어느 회사나 비슷한 업무는 패키지 쪽에 둡니다. Travelers가 자체 모델을 만든 것도 비용을 낮추려고 일부를 직접 짓는 선택으로 볼 수 있습니다.

Agents in Customer Engagement: 에이전트가 먼저 들어갈 고객 접점

응답자 4분의 3은 3년 안에 AI 에이전트가 고객 접점의 핵심이 된다고 봤습니다. 먼저 꼽힌 곳은 계좌 관리, 대출 실행과 인수 심사, 금융상품 추천입니다. 셋 다 요청이 많고 절차가 정해져 있으며 여러 부서를 거치는 업무입니다. 그래서 멀티에이전트와 전사 조율이 가장 먼저 시험받는 자리이기도 합니다. 고객 접점에 에이전트를 넣는 회사라면 이 셋 중 하나를 골라 넘김 기록과 성과 지표를 먼저 갖춰 보는 것이 순서입니다.

통념과 다른 주장

저자가 든 사례

Bank of America: 라우팅 계층 Orchestra

항목	내용
상황	질의가 늘면서 모델 사용 비용을 통제해야 함 (기사의 맥락)
한 일	소형 분류 모델이 가장 비용 효율적인 모델을 고르는 라우팅 계층 Orchestra 도입
결과	원문에서 밝히지 않음
연결	Intelligent Model Routing

Travelers: 자체 모델 TravelersLLM

항목	내용
상황	frontier 모델로 모든 질의를 처리하면 비용이 큼 (기사의 맥락)
한 일	질의를 frontier 모델보다 싸게 처리하려고 자체 LLM인 TravelersLLM 구축
결과	원문에서 밝히지 않음
연결	Intelligent Model Routing, Hybrid Sourcing

상위 5%: 에이전트 AI를 전사 규모로 체계화한 그룹

항목	내용
상황	대부분이 시험·배포 단계에 머물고 절반가량은 수익 입증에 어려움
한 일	사업·기술 조직을 가로지른 에이전트 조율, 자율 실행을 위한 신뢰할 수 있는 클라우드 환경, AI 지출과 재무 성과의 연결
결과	전사 규모로 에이전트 AI를 운영할 역량을 갖춤 (응답 기업의 5%)
연결	Orchestration Gap, Cloud as Execution Layer, Outcome-Based Funding

기술 디테일: 라우팅, 조율 기록, 비용 귀속을 실제로 돌리려면

아래 등급, 필드명, 기준값은 실행 제안이며 Capgemini나 기사 속 기업이 밝힌 방법이 아닙니다.

Intelligent Model Routing을 돌리려면 모델을 3개 등급으로 나누고, 등급마다 맡길 일과 검증 방식을 정합니다. 분류는 작은 모델 하나가 맡습니다. 입력은 질의 원문과 호출한 에이전트 ID이고, 출력은 아래 JSON 하나입니다. 분류 모델은 temperature 0으로 두고, 같은 질의를 3번 돌려 판정이 갈리면 한 등급 위로 보냅니다. confidence가 0.7 미만이어도 위로 올립니다. 신용 결정이나 보험금 지급 판단처럼 결과를 설명해야 하는 업무는 fixed_route로 묶어 라우팅에서 뺍니다.

{
  "request_id": "req-20261112-0041",
  "agent_id": "loan-intake-03",
  "workflow_id": "LOAN-ORIGINATION",
  "task_type": "document_extraction",
  "complexity": "low",
  "risk_class": "standard",
  "fixed_route": false,
  "route": "tier-S",
  "confidence": 0.86,
  "escalated": false,
  "tokens_in": 1840,
  "tokens_out": 220,
  "cost_usd": 0.0009,
  "quality_check": "schema_pass",
  "router_version": "router-v0.4",
  "logged_at": "2026-11-12T09:14:03+09:00"
}

품질은 골든셋으로 지킵니다. 업무별 실제 질의 300건에 정답이나 합격 기준을 붙여 두고, 라우터나 모델을 바꿀 때마다 등급별 합격률을 다시 잽니다. tier-S의 합격률이 tier-L보다 3%p 넘게 낮은 업무는 tier-M 이상으로 올립니다. 비용 절감은 같은 질의를 모두 tier-L로 보냈을 때의 추정 비용과 실제 비용의 차이로 셉니다.

막히는 경우	증상	대응
분류 오판	어려운 질의가 소형 모델로 감	3회 판정 불일치·confidence 0.7 미만은 상향
품질 저하를 늦게 앎	고객 불만이 쌓인 뒤 발견	등급별 합격률 주간 점검
규제 업무가 섞임	같은 판단이 모델마다 다름	fixed_route로 고정 경로 지정
절감액 과장	기준 비용이 매번 다름	전량 tier-L 가정 비용을 기준으로 고정

Orchestration Gap을 좁히려면 에이전트 등록부와 넘김(handoff) 로그부터 만듭니다. 등록부에는 agent_id, 담당 부서와 담당자, 읽을 수 있는 데이터, 할 수 있는 행동, 넘길 수 있는 에이전트, 사람 승인이 필요한 행동을 적습니다. 에이전트가 다른 에이전트에 일을 넘길 때마다 from_agent, to_agent, workflow_id, 넘긴 데이터 요약, 근거 문서 ID, 시각을 남깁니다. 이 로그가 있으면 넘김이 몇 개 부서를 건너는지, 어디서 사람이 개입하는지가 숫자로 드러납니다. 등록부에 없는 에이전트는 실행 기반에서 호출하지 못하게 막아야 감사 요구에 답할 수 있습니다. 넘김 한 건은 아래처럼 남깁니다.

{
  "handoff_id": "ho-20261112-0193",
  "workflow_id": "LOAN-ORIGINATION",
  "from_agent": "loan-intake-03",
  "from_dept": "영업점",
  "to_agent": "credit-review-01",
  "to_dept": "여신심사부",
  "payload_summary": "신청서 추출 결과 12개 필드",
  "evidence_ids": ["doc-88213", "doc-88214"],
  "human_approval": "not_required",
  "registry_check": "pass",
  "at": "2026-11-12T09:15:40+09:00"
}

from_dept와 to_dept가 다른 넘김의 비율을 업무별로 세면 전사 조율이 어디까지 왔는지 업무별로 나옵니다. registry_check가 fail인 건은 실행하지 않고 AX 추진 조직에 알립니다.

Outcome-Based Funding으로 예산을 심사하려면 AI 비용을 업무 단위로 귀속합니다. 라우팅 로그의 workflow_id로 토큰 비용을 모으고, 인프라 비용은 호출 수 비율로 나눕니다. 업무마다 성과 지표를 2~3개로 정합니다. 대출 실행이라면 신청에서 승인까지 일수, 건당 처리 비용, 사후 부실 전이율 같은 것입니다. 분기마다 지표 변화와 귀속 비용을 한 줄에 놓고 확대, 유지, 중단을 정합니다. 절약 시간은 참고 지표로만 두고 예산 판단에는 쓰지 않습니다.

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

역할	맡는 일
CIO·CTO	실행 기반과 등록부 원칙 승인, 하이퍼스케일러 계약 검토
CFO·재무 컨트롤러	업무별 성과 지표와 비용 귀속 기준 확정
AX 추진 조직	에이전트 목록 관리, 주간 진행 보고, 판정 회의 준비
플랫폼 엔지니어	라우터, 골든셋 평가, 넘김 로그 구현
업무 담당 현업 리더	골든셋 정답 확인, 고정 경로 업무 지정
리스크·컴플라이언스	사람 승인 행동과 감사 항목 검토

준비물. 운영 중이거나 시험 중인 에이전트 목록과 담당자, 에이전트별 지난 3개월 모델 호출량과 비용, 업무별 실제 질의 표본, 규제상 설명이 필요한 업무 목록, 재무팀이 인정하는 업무별 성과 지표 후보가 필요합니다.

기간	할 일	산출물
1주	에이전트·모델 호출 현황 조사, 업무별 비용 집계	에이전트 목록, 비용 현황표
2~3주	업무별 골든셋 300건 구축, 등급표 작성	골든셋, 라우팅 등급표
3~4주	라우터를 한 업무에 붙여 그림자 운영(결과는 기존 경로로 응답)	등급별 합격률, 절감 추정액
2~4주	등록부 작성, 넘김 로그 수집 시작	에이전트 등록부, 넘김 지도
4~5주	재무팀과 업무별 성과 지표 2~3개 합의	성과 지표 정의서
6주	확대·유지·중단 판정 회의	다음 분기 예산안, 확대 대상 목록

현업에 물을 것.

1. 이 에이전트가 처리한 결과는 다음에 누구에게, 어떤 시스템으로 넘어가나요?
2. 그 넘김에서 사람이 확인하는 단계가 있나요? 건당 몇 분이 걸리나요?
3. 같은 질의를 더 싼 모델이 처리해도 되는지 판단할 정답 사례를 줄 수 있나요?
4. 결과가 모델마다 달라지면 안 되는 판단은 무엇인가요?
5. 이 업무가 잘되면 재무 보고서의 어느 숫자가 움직이나요?

진행 판정 기준(예시). 그림자 운영에서 tier-S·M의 합격률이 tier-L 대비 3%p 이내이고 비용이 30% 이상 줄면 라우터를 실제 응답에 붙입니다. 넘김 로그에서 등록부에 없는 에이전트 호출이 나오면 확대를 멈추고 등록부부터 채웁니다. 성과 지표가 합의되지 않은 업무는 다음 분기 예산을 늘리지 않습니다.

AX 적용 제언. 금융사나 규제 업종 고객이라면 에이전트 수를 늘리는 계획보다 세 가지 장부를 먼저 세우는 편이 빠릅니다. 모델 라우팅 로그로 토큰 비용을 업무 단위로 보이게 하고, 에이전트 등록부와 넘김 로그로 전사 조율의 범위를 숫자로 보이게 하며, 재무팀과 합의한 성과 지표로 예산 심사를 바꿉니다. 첫 대상은 고객 접점 세 영역 가운데 넘김이 가장 많은 대출 실행·심사가 알맞습니다. 이미 클라우드 계약이 있다면 새 플랫폼을 사기 전에 그 안에서 권한·로그·감사 기능을 등록부와 묶을 수 있는지부터 확인합니다. 만들 것, 살 것, 빌릴 것은 이 장부가 생긴 뒤 업무별 비용과 성과를 보고 정해도 늦지 않습니다.

원문 사례

항목	내용
기사	CIO Dive, Makenzie Holland 기자, 2026.11.5
1차 자료	Capgemini Research Institute, World Cloud Report for Financial Services 2027 (보도자료 2026.11.5, 파리)
조사	2026 Global Financial Services Executive Survey, 14개 시장 1,100명, 2026.6~7, 7개 업권
인터뷰	금융사·하이퍼스케일러 임원, 2026.6~9
도입	멀티에이전트 시험·배포 59%, 전사 조율 10%, 전사 규모 체계화 5%
수익	절반가량이 에이전트 AI 투자 수익을 꾸준히 입증하지 못함
비용	모델 라우팅 사용·계획 90%, 대부분 1년 안에 도입 예상
클라우드	하이퍼스케일러를 거버넌스 파트너로 선호 52%, 기술 부채 축소 우선 10명 중 8명
예산 근거	2028년까지 성과 중시 경영진 +141%, 효율 중시 -42% (전망)
조달	3년 안에 3분의 2 이상에서 hybrid sourcing이 주류 (전망)
고객 접점	4분의 3이 3년 안에 에이전트가 핵심이 된다고 응답, 계좌 관리·대출 실행과 심사·상품 추천
기업 사례	Bank of America Orchestra(소형 분류 모델 라우팅), Travelers TravelersLLM(자체 모델)
발언	Ravi Khokhar(Capgemini 금융 서비스 클라우드 글로벌 책임자)

핵심 개념

multi-agent system

여러 AI 에이전트가 한 업무의 단계를 나눠 맡고 결과를 서로 넘기는 구조입니다.

enterprise-wide orchestration

에이전트 사이의 넘김이 부서와 시스템을 건너 전사에서 이어지도록 조율한 상태입니다.

token cost

모델이 읽고 쓴 글자 단위(토큰)만큼 내는 사용료입니다. 에이전트 호출이 늘수록 커집니다.

hyperscaler

전 세계 규모로 클라우드 인프라를 운영하는 대형 사업자입니다.

tech debt

미뤄 둔 시스템 정비가 쌓여 새 기능을 붙이기 어렵게 만드는 부담입니다.

shadow mode

새 시스템을 실제 응답에는 쓰지 않고 기존 경로와 나란히 돌려 결과만 비교하는 시험 방식입니다.

내 메모

TODO: 내 생각 추가

원문은 CIO Dive에 실린 Makenzie Holland 기자의 기사 “Finance firms lean into multiagent systems, model routing”(2026.11.5)이며, Capgemini Research Institute의 World Cloud Report for Financial Services 2027을 다룹니다. 조사 방법, 7개 업권, 52%, 기술 부채, hybrid sourcing, 고객 접점, 상위 5%의 특징은 Capgemini 보도자료(2026.11.5)에서 확인했습니다. 보고서 전문 PDF는 열지 못했습니다. 요약, 핵심 메커니즘의 조사 내용, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 기사와 보도자료의 내용을 AX Review가 다시 정리한 것입니다. 사례의 ‘상황’은 기사 맥락을 바탕으로 재구성했습니다. 기술·현업 실행 디테일, 등급표, JSON 예시, 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 기사 전문은 원문 페이지에서 볼 수 있습니다.