은행업에는 프로토콜 문제가 있습니다.

1금융권 은행의 리스크 분석가가 신용 결정 요청을 제출합니다. 이 답변을 위해서는 코어 뱅킹 시스템(core banking system)에 쿼리를 날리고, 데이터 웨어하우스(data warehouse)에서 거래 내역을 가져오며, 제재 데이터베이스(sanctions database)를 확인하고, 고객의 KYC(Know Your Customer) 문서를 검색하며, 신용 점수 모델(credit scoring model)을 실행하고, 규제 자본 요건(regulatory capital requirements)을 교차 참조하며, 결정이 정책 범위 내에 있는지 확인하기 위해 컴플라이언스 에이전트(compliance agent)와 협력해야 합니다.

8개의 시스템. 다수의 AI 에이전트. 수십 개의 맞춤형 API 통합 — 각각 별도로 구축되고, 각각 별도로 유지 관리되며, 실패가 법적 결과를 초래하는 규제 환경에서 각각이 장애 지점(point of failure)이 됩니다.

이것이 현재 대부분의 BFSI AI 이니셔티브가 매몰되어 있는 통합 부채(integration debt)입니다. 그리고 이것이 바로 MCP와 A2A가 애플리케이션 레벨이 아닌 프로토콜 레벨에서 해결하기 위해 구축된 것입니다.

이 가이드는 아키텍처 근거부터 컴플라이언스 고려 사항, 규제 금융 환경에서 작동하는 특정 패턴에 이르기까지, 프로덕션 BFSI 에이전트 시스템에 MCP 및 A2A를 배포하기 위한 완전한 구현 가이드입니다.

목차

1. BFSI에 프로토콜 레벨 표준이 필요한 이유
2. BFSI에서의 MCP: 에이전트를 금융 시스템에 연결하기
3. BFSI에서의 A2A: 에이전트 간 연결하기
4. 규제 레이어: DORA, EU AI Act, 그리고 Basel III
5. BFSI 아키텍처: 완전한 참조 스택(Reference Stack)
6. 구현 패턴 1: 신용 결정 자동화
7. 구현 패턴 2: 사기 탐지 및 대응
8. 구현 패턴 3: 규제 보고
9. 구현 패턴 4: 자산 관리 자문
10. 금융 에이전트 네트워크를 위한 보안 아키텍처
11. 관측성(Observability) 및 감사 요구 사항
12. 구현 로드맵 및 의사 결정 프레임워크

1. BFSI에 프로토콜 레벨 표준이 필요한 이유

IMF는 2026년 4월, 에이전트 기반 AI (Agentic AI)가 결제 시스템을 어떻게 재편할 것인지에 대한 공식 노트를 발표했습니다. 핵심적인 기술적 발견은 다음과 같습니다: MCP는 에이전트의 외부 데이터 및 도구에 대한 접근을 표준화하는 반면, A2A 프로토콜은 서로 다른 벤더가 개발한 에이전트 간의 상호 운용성 (Interoperability) 및 조율 (Coordination)을 가능하게 합니다. x402 표준은 HTTP 402를 기반으로 하며, 에이전트가 HTTP 요청 내에 결제 요구 사항을 직접 포함할 수 있도록 하여 유료 서비스에 대한 자동 협상을 가능하게 합니다.

도구 연결을 위한 MCP, 에이전트 조율을 위한 A2A, 결제 협상을 위한 x402로 구성된 이 삼중 스택 (Tripartite stack)은 단순한 학술적 제안이 아닙니다. 이는 IMF에 의해 문서화되고, PayPal 및 주요 결제 네트워크가 채택하였으며, Linux Foundation의 Agentic AI Foundation을 통해 모든 주요 AI 제공업체가 지원하는 2026년 금융 서비스 자동화의 신흥 인프라입니다.

규모의 맥락: BCG 연구에 따르면 은행 및 핀테크는 AI 리더들이 가장 집중되어 있는 산업으로 식별되었습니다. 금융 기관의 거의 절반이 이미 고급 AI 시스템을 정기적으로 사용하고 있다고 보고하고 있습니다. 기관들이 대규모 자동화를 통해 차별화를 추구함에 따라 에이전트 기반 아키텍처 (Agentic architectures)의 도입이 가속화되고 있습니다.

프로토콜 표준이 없다면, 금융 기관은 세 가지 복합적인 문제에 직면하게 됩니다.

첫 번째는 N x M 통합 문제입니다. 15개의 AI 에이전트와 40개의 금융 데이터 소스를 보유한 은행은 600개의 맞춤형 통합이 필요합니다. 어느 한 쪽이 업데이트될 때마다 각각의 통합은 깨지게 됩니다. 또한 각각은 독립적으로 감사되어야 하는 컴플라이언스 영역 (Compliance surface)을 나타냅니다. MCP는 이를 55개의 연결(15개의 에이전트와 40개의 MCP 서버)로 줄여주며, 각 서버는 단 한 번만 구축되고 감사되면 됩니다.

두 번째는 벤더 간 에이전트 조정(cross-vendor agent coordination) 문제입니다. 신용 결정 워크플로우(credit decisioning workflow)에는 Anthropic의 LLM, 전문 벤더의 리스크 스코어링 모델(risk scoring model), 컴플라이언스 기술 제공업체의 KYC 검증 에이전트, 그리고 내부 부정 탐지 시스템이 포함될 수 있습니다. A2A가 없다면, 이러한 시스템들을 조정하기 위해 취약하고, 감사인에게 불투명하며, 전체를 다시 작성하지 않고서는 교체할 수 없는 맞춤형 오케스트레이션(orchestration) 코드가 필요합니다. A2A는 조정 계층(coordination layer)을 다시 작성하지 않고도 각 에이전트를 교체할 수 있게 해줍니다.

세 번째는 감사 가능성(auditability) 문제입니다. 2025년 1월 17일부터 시행되는 DORA는 EU 금융 기관이 경영진 수준의 책임을 지고 ICT 시스템을 지속적으로 모니터링하고 제어할 것을 요구합니다. 고객, 거래 또는 규제 대상 결과에 영향을 미치는 AI 에이전트의 결정은 반드시 기록되고, 분류되며, 보고 가능해야 합니다. 프로토콜 수준의 표준화는 이를 실행 가능하게 만듭니다. 모든 에이전트 상호작용이 정의된 와이어 포맷(wire format)을 따를 때, 감사 로그(audit logging)는 각 애플리케이션에 개별적으로 덧붙이는 방식이 아니라 프로토콜 계층에서 수행될 수 있습니다.

2. BFSI에서의 MCP: 에이전트를 금융 시스템에 연결하기

MCP는 수직 계층(vertical layer)입니다. 이는 각 AI 에이전트를 하단의 도구, 데이터 소스 및 상호작용이 필요한 시스템에 연결합니다. BFSI에서 이러한 시스템은 거의 다른 어떤 산업보다 더 많고, 더 민감하며, 더 엄격하게 규제됩니다.

MCP는 2025년 말까지 월간 SDK 다운로드 수 9,700만 회를 달성했으며, Anthropic, OpenAI, Google, Microsoft, Amazon 등 모든 주요 AI 제공업체에 의해 채택되었습니다. 2026년 4월의 변화는 생태계가 이제 실제 인프라처럼 작동하고 있다는 점입니다. 레지스트리(registries), 워킹 그룹(working groups), 인증(auth), 작업 수명 주기(task lifecycle), 그리고 엔터프라이즈 배포(enterprise rollout)가 프로토콜에 대한 과열된 관심보다 더 진지한 주목을 받고 있습니다. 도구를 위한 MCP, 에이전트를 위한 A2A, 웹 접속을 위한 WebMCP로 구성된 3계층 AI 프로토콜 스택은 엔터프라이즈 배포를 위한 합의된 아키텍처(consensus architecture)가 되어가고 있습니다.

BFSI MCP 서버 분류 체계

모든 금융 데이터 소스 또는 시스템 기능은 MCP 서버가 됩니다. 전형적인 2차 은행(tier-two bank) 구현을 위한 분류 체계는 다음과 같습니다:

Core Banking MCP Server는 계좌 잔액, 거래 내역, 보유 상품 및 고객 관계 데이터를 노출합니다. 이는 스택 내에서 가장 민감한 서버이며 가장 엄격한 액세스 제어(access control)를 필요로 합니다. 즉, 각 에이전트가 자신의 작업 권한이 부여된 고객 기록만 볼 수 있도록 보장하는 행 단위 보안(row-level security)이 적용되어야 합니다.

Credit Intelligence MCP Server는 신용 정보 기관(credit bureau) 데이터, 내부 신용 점수, 총부채상환비율(DTI) 계산 및 신용 한도 권장 사항을 노출합니다. 이 서버는 EU AI Act에 따라 고위험 AI 활용 사례(high-risk AI use case)로 분류되어야 하며, 추가적인 투명성 및 인간의 감독(human oversight) 메커니즘이 필요합니다.

Sanctions and AML MCP Server는 실시간 제재 스크리닝(sanctions screening), 정치적 주요 인물(PEP) 확인, 부정적 미디어 모니터링 및 자금세탁방지(AML) 경고 큐를 노출합니다. 이 서버에 대한 모든 호출은 변경 불가능한 타임스탬프(immutable timestamps)와 함께 기록되어야 합니다. 이는 선택적인 관찰성(observability)의 문제가 아니라 규제 준수(regulatory compliance) 요건입니다.

Market Data MCP Server는 실시간 및 과거 가격 데이터, 변동성 표면(volatility surfaces), 수익률 곡선(yield curves) 및 벤치마크 금리를 노출합니다. 이 서버의 지연 시간(latency) 요구 사항은 다른 서버보다 현저히 엄격하며, 트레이딩 애플리케이션의 경우 100ms 미만이어야 합니다.

Document Intelligence MCP Server는 문서 파싱(parsing), OCR, 금융 문서에서의 엔티티 추출(entity extraction) 및 고객 확인 제도(KYC) 문서 검증을 노출합니다. 이 서버는 은행의 문서 관리 시스템을 래핑(wrap)하며, 다른 서버들이 다루지 않는 비정형 데이터(unstructured data) 레이어를 처리합니다.

Regulatory Capital MCP Server는 바젤 III/IV(Basel III/IV) 자본 적정성 계산, 위험가중자산(RWA) 데이터, 유동성커버리지비율(LCR) 및 순안정자금조달비율(NSFR) 지표, 규제 한도 모니터링을 노출합니다. 이 서버는 읽기 집약적(read-heavy)입니다. 에이전트는 제안된 결정이 실행되기 전 자본 제약 조건을 준수하는지 확인하기 위해 이 서버에 쿼리를 보냅니다.

Communication MCP Server는 이메일, SMS, 보안 메시징과 같은 고객 통신 채널을 노출하며, 전달 추적(delivery tracking), 동의 확인(consent verification), 통신 기본 설정 확인(communication preference checking)을 처리합니다. 어떤 에이전트도 이 서버를 거치지 않고 고객 통신을 보낼 수 없습니다.

BFSI 컨텍스트에서의 MCP 와이어 포맷 (Wire Format)

MCP를 통해 고객 거래 내역을 조회하는 신용 결정 에이전트(credit decisioning agent):

{
  "jsonrpc": "2.0",
  "method": "tool.call",
...

authorization_context 필드는 기본 MCP 사양(spec)에는 포함되어 있지 않습니다. 이는 모든 도구 호출(tool call)을 해당 호출을 승인한 특정 워크플로(workflow) 및 규제 목적과 연결하는 BFSI 확장 기능입니다. 이러한 연결은 감사 추적(audit trail)을 일관되게 만드는 핵심 요소입니다. 감사 로그를 검토하는 컴플라이언스 담당자(compliance officer)는 모든 데이터 접근을 이를 정당화한 특정 고객 상호작용 및 비즈니스 결정까지 추적할 수 있습니다.

BFSI 특화 MCP 보안 요구사항

표준 MCP 보안은 금융 서비스에 충분하지 않습니다. 운영 환경에서는 세 가지 추가 계층이 필요합니다.

모든 MCP 연결에 대한 상호 TLS (mTLS). 낮은 민감도의 애플리케이션에는 베어러 토큰(bearer tokens)을 사용하는 표준 HTTP가 허용될 수 있습니다. 하지만 BFSI에서는 MCP 클라이언트와 MCP 서버 간의 모든 연결에 mTLS를 사용해야 합니다. 즉, 양측 모두 인증서를 제시하고 양측 모두 검증되어야 합니다. 이는 규제 대상 금융 데이터에 접근하는 연결을 위한 최소 표준입니다.

MCP 서버 수준의 역할 기반 도구 권한 부여 (Role-based tool authorization). 모든 에이전트가 모든 MCP 서버의 모든 도구에 접근할 수 있어서는 안 됩니다. 고객 서비스 에이전트는 계좌 잔액을 읽을 수는 있어야 하지만 이체를 시작할 수는 없어야 합니다. 이상 거래 탐지 에이전트(fraud detection agent)는 거래 패턴을 읽을 수는 있어야 하지만 신용 한도를 수정할 수는 없어야 합니다. MCP 서버 수준의 RBAC(Role-Based Access Control, 역할 기반 액세스 제어)는 호출하는 에이전트가 무엇을 요청하든 관계없이 이를 강제합니다. 즉, 서버는 호출하는 에이전트의 역할이 허용하지 않는 도구 호출을 거부합니다.

도구 응답에서의 데이터 최소화 (Data minimization). MCP 서버는 도구의 명시된 목적에 필요한 최소한의 데이터만을 반환해야 합니다. 신용 평가 쿼리는 고객의 전체 거래 내역을 반환해서는 안 되며, 신용 모델에 필요한 요약된 소득 및 채무 데이터만을 반환해야 합니다. 과도한 데이터를 반환하는 것은 불필요한 노출을 초래하고 GDPR 준수를 복잡하게 만듭니다.

3. BFSI에서의 A2A: 에이전트 간의 연결

A2A는 수평 계층 (horizontal layer)으로, AI 에이전트를 다른 AI 에이전트와 연결합니다. BFSI 분야에서 이곳은 가장 복잡하고 가치가 높은 자동화가 이루어지는 영역입니다. 금융 워크플로우는 본질적으로 멀티 에이전트 (multi-agent) 방식이기 때문입니다. 예를 들어, 신용 결정은 리스크, 컴플라이언스(Compliance), 고객 에이전트를 동시에 수반하며, 이상 거래 대응은 탐지, 조사, 조치 에이전트가 순차적으로 관여하고, 규제 보고는 데이터 수집, 검증, 제출 에이전트가 통제된 파이프라인 내에서 작동합니다.

A2A는 2025년 4월, Salesforce, PayPal, Atlassian을 포함한 50개 이상의 지원 기업과 Accenture, BCG, Deloitte, McKinsey, PwC를 포함한 주요 컨설팅 기업들과 함께 출시되었습니다. IBM의 에이전트 통신 프로토콜 (Agent Communication Protocol)은 2025년 8월 A2A로 통합되었습니다. A2A v1.0.0은 2026년 4월에 출시되어 기업 도입을 위한 사양을 안정화했습니다.

BFSI에서의 A2A 에이전트 카드 (Agent Card)

A2A를 준수하는 모든 에이전트는 잘 알려진 엔드포인트(endpoint)에 에이전트 카드 (Agent Card)를 게시합니다. BFSI에서 에이전트 카드는 기본 사양을 넘어 추가적인 메타데이터를 포함합니다:

{
  "name": "Credit Decision Agent",
  "version": "2.3.1",
...

regulatory_classification 블록은 BFSI A2A 구현에 있어 필수적입니다. 이 에이전트 카드를 소비하는 모든 오케스트레이션 에이전트 (orchestrating agent)는 해당 에이전트가 EU AI Act에 따른 고위험 AI 시스템이라는 점, 50,000 GBP 이상의 결정에 대해서는 인간의 감독 (human oversight)이 필요하다는 점, 그리고 특정 FCA 등록 하에 운영된다는 점을 즉시 알 수 있습니다. 이러한 제약 조건은 기계 판독이 가능(machine-readable)하므로, 오케스트레이터는 구현 수준의 가드레일 (guardrails)에 의존하는 대신 프로그래밍 방식으로 이를 강제할 수 있습니다.

금융 워크플로우에서의 A2A 작업 생명주기 (Task Lifecycle)

A2A 작업은 제출됨 (submitted), 작업 중 (working), 입력 필요 (input-required), 완료됨 (completed), 취소됨 (canceled), 실패함 (failed)과 같이 정의된 상태를 거쳐 진행됩니다. 특히 BFSI에서 '입력 필요 (input-required)' 상태는 매우 중요합니다. 이는 인간 참여형 (human-in-the-loop) 감독을 프로토콜 수준에서 구현한 것입니다. 신용 결정 에이전트 (credit decision agent)가 자신의 자율적 권한을 초과하는 경계 조건 (boundary condition)에 직면하면, 작업을 '입력 필요' 상태로 전환하고 정의된 인터페이스를 통해 결정 맥락 (decision context)을 인간 검토자에게 노출합니다. 검토자가 응답하면 작업은 정확히 그 상태에서부터 재개됩니다.

이는 임시방편 (workaround)이 아닙니다. 이는 금융 서비스 분야의 고위험 AI 시스템이 정의된 결정 지점에서 반드시 인간의 감독을 지원해야 한다는 규제 요구 사항을 정확히 충족하기 위해 설계된 일급 프로토콜 기능 (first-class protocol feature)입니다.

4. 규제 계층: DORA, EU AI Act, 그리고 Basel III

BFSI에서 에이전트 기반 시스템을 구현하기 전에, 세 가지 규제 프레임워크가 타협 불가능한 제약 조건을 정의합니다.

DORA — 디지털 운영 탄력성법 (Digital Operational Resilience Act)

2025년 1월 17일부터 시행되는 DORA는 모든 EU 금융 기관에 적용되며, AI를 포함한 ICT 시스템에 대한 엄격한 요구 사항을 설정합니다. 은행은 AI 실패가 서비스 가용성, 데이터 무결성, 기밀성, 진본성, 고객 또는 핵심 기능에 영향을 미치는 경우, 자체 사고 분류 프로세스에 따라 이를 평가해야 합니다. 에이전트 기반 워크플로우 (agentic workflows)는 문서화된 폴백 절차 (fallback procedures), 복구 목표 (recovery objectives), 그리고 제3자 탈출 계획 (third-party exit plans)을 갖추어야 합니다. 특히 단일 LLM, 클라우드 제공업체 또는 오케스트레이션 벤더에 의존하는 경우 더욱 그러합니다.