파편화에서 균열선으로: 에이전트 시대에 기업 뱅킹에 없는 API 표준

리테일 뱅킹은 10년 전에 API 표준을 얻었다. 기업 뱅킹은 끝내 얻지 못했고, 2026년에 그 누락은 골칫거리이기를 멈추고 균열선이 되었다. ISO 20022는 업계에 공통 문법을 주었지만, 공통의 에이전트 대응 표면은 결코 주지 못했다. 이제 호출자가 바뀌었다. 통합에 한 분기를 쏟을 개발자가 아니라, 런타임에 도구를 발견하고 정책 밴드 안에서 자금을 움직이는 모델이 호출자다. 기업 트레저러들이 20년 동안 조용히 흡수해 온 모호성이, 그것을 흡수할 수 없는 소프트웨어의 손에 곧 넘어가려 한다 — 그 아래의 데이터 계층은 은행이 원하든 아니든 구조화되도록 강제되는 와중에. 이 글은 없는 방향이 치르게 하는 비용, 에이전트가 오늘의 파편화를 단순히 비효율적인 것이 아니라 위험한 것으로 만드는 이유, 그리고 자율 트레저리가 확장되기 전에 기업 뱅킹 API 표준이 반드시 의무화해야 할 것을 다룬다.

핵심 요약

기업 뱅킹에는 문법은 있으나 표면은 없다. ISO 20022는 데이터를 표준화했고, API는 아무도 표준화하지 않았다. 인간 통합 담당자가 모호성을 흡수하는 동안에는 감당할 수 있었으나, 런타임의 모델은 그럴 수 없다.

호출자가 바뀌었다. MCP는 도구 발견을 런타임 결정으로 만들었다. M×N 통합 문제를 없애려던 에이전트가 은행 경계에서 그 문제를 다시 만난다. 그곳에서는 각 기관이 저마다의 시맨틱스를 가진 맞춤형 서버다.

이제 파편화는 기계 속도로 자금을 잘못 움직인다. 하나의 타임아웃, 세 은행, 세 개의 모순된 진실 — A에서는 중복, B에서는 멈춘 지시, C에서는 조용한 실패. 멱등성과 결정론적 오류 문법이 구조적 하중을 떠받치는 요소가 된다.

각 은행을 MCP 서버로 감싸는 것은 늪을 옮길 뿐이다. 40개의 서버, 40개의 시맨틱스, 공유된 비기능 하한선의 부재 — 그리고 결제 레일에 쓰기 권한을 가진 비결정론적 모델. 이는 명백히 SR 11-7 / DORA / EU AI Act의 문제다.

자신의 표면을 표준화하거나, 아니면 상품이 되거나. ISO 20022 네이티브의 에이전트 대응 API를 지금 공개하는 은행이 자율 트레저리의 기본 거래상대방이 되고, 나머지는 어댑터를 소유한 자에게 자신의 고객 관계를 임대한다.

두 개의 뱅킹 세계, 그중 하나는 표준화되었다

리테일을 보면 그림은 어지럽지만 항해할 수는 있다. 유럽에는 UK Open Banking과 Berlin Group의 NextGenPSD2가 있으며, 후자는 유럽 은행의 4분의 3 이상이 채택하여 실질적으로 사실상의 표준으로 취급된다. 미국에는 이제 6천만 개 이상의 소비자 계좌를 아우르는 Financial Data Exchange가 있다. 호주에는 Consumer Data Right가 있다. 이들 중 어느 것도 글로벌이 아니며, 어느 것도 글로벌이 될 가능성은 낮다 — 그러나 각각은 실재하고, 버전이 관리되며, 기계로 테스트 가능한 계약이다. 그리고 계약이 미치지 못하는 곳에서는 애그리게이터(Plaid, Tink, TrueLayer, Salt Edge)가 그 차이를 단일 인터페이스 뒤로 흡수한다. 리테일 파편화는 세금이다. 그것은 벽이 아니다.

기업 및 도매 뱅킹에는 그에 상응하는 것이 없다. 다국적 트레저리는 host-to-host 파일 파이프, 십여 개의 맞춤형 포털, 트레저리 관리 시스템, 또는 애그리게이터를 통해 자신의 은행에 도달하며 — 보통 이 넷을 한꺼번에 사용한다. 이는 허수아비 논증이 아니다. McKinsey 자신의 거래 뱅킹 연구는 수년간 동일한 유산을 목록화해 왔다. 은행이 host-to-host와 SFTP 파일 전송에 의존하는 방식을 서술하고, 파일 기반 통합의 잘 알려진 장애 양상 — 기업마다 맞춤화해야 하는 무거운 ERP 포맷, 조건부 라우팅을 처리하지 못하는 무능력 — 을 열거하며, 거래 뱅킹 임원의 85% 이상이 현금 관리 API에 투자할 의향이 있다고 보고한다. API에 대한 갈망은 의심할 여지가 없다. 없는 것은 그들이 겨냥하는 공통 계약이다.

통상의 후보들이 그것이 아니기 때문이다. ISO 20022는 흔히 없는 표준으로 오인되지만, 그것은 데이터 문법이지 API 계약이 아니다. pain.001은 신용 이체를 어떻게 표현할지는 알려주지만, 어느 엔드포인트가 그것을 생성하는지, 어떻게 인증하는지, 어떻게 페이지네이션하는지, 어떻게 실패를 알리는지는 말해주지 않는다. BIAN은 업계에 공유된 시맨틱 참조 모델을 주지만, 강제되는 인터페이스는 아니다. Swift의 Payment Initiation 및 Instant Cash Reporting API는 표준화를 향한 진정한 움직임이지만, 네트워크 중심적이고 여전히 부상 중이며, 보편적 표면은 아니다. Berlin Group의 openFinance 프레임워크는 기업 사용 사례 — 계좌 개설, 무역 금융, 동적 반복 결제 — 로 손을 뻗고 있지만, 유럽적이고, 초기이며, 협약에 따른 프리미엄 방식이다. 그 모두를 조립해도 여전히 구속력 있는 글로벌 기업 뱅킹 API 표준은 얻지 못한다. 건축 자재만 있고 설계도는 없는 셈이다.

파편화가 살아남은 이유 — 그리고 그것이 끝나가는 이유

20년 동안 이는 견딜 만했다. 통합 담당자가 인간이었고 인내심이 있었기 때문이다. 한 기업은 소수의 뱅킹 연결을 수개월, 때로는 수분기에 걸쳐 온보딩했다. 각각은 하나의 프로젝트였다. 인증서를 교환하고, 소액 테스트를 실행하고, 매핑 문서를 놓고 논쟁했다. 비용은 실재했으나 관계당 한 번만 지불되었고 이후 수년간의 결제에 걸쳐 상각되었다. 은행의 API가 불충분하게 명세되었을 때 — 은행 스스로 불평하듯 표준이 "나머지는 구현 기관에 맡겼을" 때 — 인간 엔지니어가 포털을 읽고, 의도를 추론하고, 그 틈을 메웠다. 모호성은 그것을 해소할 사람이 곁에 있었기에 견딜 만했다.

그것은 덜 자주 소리 내어 말해지는 이유들로도 살아남았다. 그 아래의 배관은 진정으로 바꾸기 어렵다. 배치 결제 창, 야간 사이클, 그리고 실시간 질문에 답하도록 설계된 적이 없는 메인프레임 코어. 그리고 파편화는 우연만은 아니다 — 그것은 조용히, 일종의 락인(lock-in)이다. 트레저러가 구축하는 모든 맞춤형 host-to-host 파이프는 기존 사업자에게 귀속되는 전환 비용이다. 통합하기 어려운 은행은, 한계적으로, 떠나기 어려운 은행이다. 이 중 어느 것도 음모론적이지 않다. 그것은 평범한 유인일 뿐이다. 그러나 이는 데이터 문법에 합의한 업계가 왜 결코 표면에 합의하지 못했는지 — 그리고 왜 표면이 마지막까지 남은 표준화되지 않은 계층인지를 설명한다. 그것이 더 이상 유지될 수 없는 이유는, 그 아래 계층이 마감 시한에 맞춰 구조화되도록 강제되고 있고, 그 위 계층이 방금 새롭고 참을성 없는 사용자를 얻었기 때문이다.

호출자가 바뀌었다

그 사용자는 18개월 만에 도착했다. Anthropic이 2024년 11월에 오픈소스로 공개하고 2025년 12월에 Block, OpenAI와 함께 Linux Foundation의 Agentic AI Foundation에 기증한 Model Context Protocol은, AI 시스템이 도구와 데이터에 도달하는 기본 방식이 되었다. 2026년 초에 이르러 그것은 월 약 9,700만 건의 SDK 다운로드를 기록하고 있었다. 연중 무렵에는, 한 방향성 있는 업계 판독에 따르면, 엔터프라이즈 AI 팀의 약 78%가 MCP 기반 에이전트를 프로덕션에서 운영하고 있었고, Fortune 500의 4분의 1 이상이 표준 OAuth 2.1 인가 계층으로 보안이 확보된 MCP 서버를 운영하고 있었다. 그것은 일상적으로, 그리고 정확하게, AI를 위한 USB-C로 묘사된다. 그것은 M×N 통합 악몽 — 모든 모델을 모든 도구에 일일이 손으로 배선하는 것 — 을 M+N으로 붕괴시킨다. 스스로에 대한 그것의 요약이 은행에 중요한 문구다. API는 프로그램을 위한 것이고, MCP는 에이전트를 위한 것이다. REST API는 호출자가 어느 엔드포인트를 어떤 매개변수로 호출할지 미리 알기를 기대한다. 에이전트는 사용 가능한 도구를 런타임에 발견하고, 그것을 어떻게 언제 사용할지 스스로 결정하기를 기대한다.

이는 트레저리에 가설이 아니다. 그 패턴은 이미 2026년 기업 및 투자 은행 트레저리 전반에서 일관되게 나타난다. 에이전트가 ISO 20022 현금 데이터를 읽고, 한정된 도구 집합을 호출하며, 그 주위를 SR 11-7, DORA, EU AI Act 통제로 감싼 채 정책 밴드 안에서 유동성을 재조정한다. 데이터 문법은 그에 준비되어 있다. API 표면은 그렇지 않다.

불일치를, 정확히

에이전트가 뱅킹 거래상대방으로부터 실제로 필요로 하는 것으로 벗겨내면, 그 목록은 짧고 가차 없다.

기계가 발견 가능한 계약 — 인간이 한 번 읽는 PDF가 아니라, 에이전트가 런타임에 읽을 수 있는 OpenAPI 서술이나 도구 매니페스트.
하나의 인증 모델 — 은행마다 다른 핸드셰이크가 아니라, 금융 등급의 OAuth2/mTLS 프로파일(FAPI가 명백한 기준점).
보증으로서의 멱등성 — 재시도된 결제를 no-op으로 만드는 고유한 지시 참조. 에이전트는 반드시 재시도할 것이기 때문이다.
결정론적 오류 문법 — 동일한 실패가 어디서나 동일한 것을 의미하여, 모델이 그것에 대해 추론할 수 있게 하는 것.
시맨틱 버저닝과 역량 발견 — 인간의 릴리스 노트 없이도 에이전트가 거래상대방이 이번 분기에 무엇을 할 수 있는지 알 수 있게 하는 것.
구조화된 ISO 20022 페이로드, 동의와 권한, 그리고 변조 방지 감사 추적 — 실체, 허가, 그리고 증거.

그것을 현존하는 기업 뱅킹에 대비시키면 모든 항목이 N개의 방언 — 은행마다 하나씩 — 으로 쪼개진다. M×N 문제를 없애기로 했던 에이전트가 은행 경계에서 그것을 다시 만난다. 각 기관이 사실상 "잔액"에 대한 저마다의 문법, "결제 상태"에 대한 저마다의 개념, 저마다의 인증 절차, 그리고 오류가 무엇인지에 대한 저마다의 생각을 가진 맞춤형 서버이기 때문이다. 프로토콜은 전선의 에이전트 쪽을 표준화했다. 은행 쪽은 아무도 표준화하지 않았다.

장애 양상을, 구체적으로

구체적으로 만들자. 추상화가 실제로 무는 곳이 여기이기 때문이다. 각 계좌를 목표 밴드 안에 유지하기 위해 세 은행에 걸쳐 현금을 스윕(sweep)하도록 인가된 유동성 에이전트를 그려 보라. 그것은 거의 동일한 세 개의 지시를 발사하고, 네트워크가 늘 그렇듯이, 각각에서 타임아웃을 만난다.

Bank A는 그 타임아웃을 알 수 없음 — 재시도 안전으로 취급하므로, 에이전트가 재시도하고, 원래 지시도 결제된다. 중복 결제다. Bank B는 동일한 타임아웃을 제출됨 — 재시도 금지로 취급하지만, 에이전트가 파싱할 수 있는 확인을 결코 노출하지 않으므로, 지시는 미결 상태에 놓이고, 성공을 보지 못한 에이전트는 이를 에스컬레이션하거나 재라우팅한다. 멈춘 결제와 이중 계상된 포지션이다. Bank C는 페이로드 본문 안에 거절이 묻힌 채로 명랑한 HTTP 200을 반환한다. 에이전트는 상태 코드를 읽고, 스윕을 완료로 표시하고, 넘어간다. 다음 날 아침에야 아무도 설명할 수 없는 대사(reconciliation) 불일치로 드러나는 조용한 실패다.

세 은행, 하나의 조건, 세 개의 모순된 진실 — A에서는 자금이 중복으로 빠져나가고, B에서는 지시가 얼어붙고, C에서는 유령 같은 성공. 인간 트레저러라면 세 명의 관계 담당자에게 전화를 걸어 점심 전에 정리했을 것이다. 에이전트는 누구에게도 전화할 수 없다. 이것이 바로 "보증으로서의 멱등성"과 "결정론적 오류 문법"이 건축상의 장식이 아닌 이유다. 그것들이 없으면, 예전에는 단지 인간의 시간만 소모하던 동일한 파편화가 이제 기계 속도로, 모든 거래상대방에 걸쳐 동시에, 실제 자금을 잘못 움직인다.

"모든 은행을 MCP 서버로 감싸기"가 해법이 아닌 이유

반사적인 답은 각 은행에 MCP 서버를 하나씩 주고 끝내는 것이다. 그것은 성립하지 않는다. 파편화를 제거하는 것이 아니라 이전시키기 때문이다. 40개의 은행은 40개의 시맨틱스, 40개의 인증 흐름, 그리고 공유된 의미의 부재를 가진 40개의 서버가 된다 — 그리고 결정적으로, 공유된 비기능 하한선의 부재다. 공통의 지연 예산도, 합의된 가용성 등급도, 비교 가능한 멱등성 보증도 없다. 위의 장애 양상은 래퍼(wrapper)를 온전히 통과해 살아남는다. 더 나쁘게도, 호출자는 이제 결제 레일에 쓰기 권한을 가진 비결정론적 모델이며, 이는 단순한 통합 문제가 아니라 SR 11-7, DORA, EU AI Act에 정면으로 걸리는 모델 리스크 및 운영 복원력 문제다. MCP의 인간 개입(human-in-the-loop) 프리미티브 — 확인을 위한 elicitation, 추론을 위한 sampling — 는 필요하고 환영할 만하지만, 확인 대화상자가 예측 가능하게 행동하는 거래상대방을 대체하지는 못한다. 균일하게 서술할 수 없는 것을 대규모로 거버넌스할 수는 없다. 수천 개의 맞춤형 서버는 표준이 아니다. 그것은 JSON-RPC 겉치장을 두른 동일한 늪이다.

두 개의 미래, 그리고 전략적 선택

누가 이것을 해소하느냐가 향후 10년 동안 누가 기업 관계를 소유하느냐를 결정하며, 후보는 둘뿐이다.

첫째, 은행이 자신의 표면을 표준화한다. 그들은 에이전트 대응 API를 공개하고, 트레저러와의 직접 연결을 유지하며, 에이전트가 발견하고 호출하는 거래상대방으로 남는다. 둘째, 애그리게이터가 그것을 대신 표준화한다. 소수의 플랫폼이 사실상의 에이전트 계약을 정의하고, 은행은 그 뒤의 교체 가능한 엔드포인트가 된다 — 타인의 추상화를 통해서만 도달 가능하다. 이는 억측이 아니다. 리테일 이야기가 한 세그먼트 앞으로 진행되는 것이다. McKinsey 자신의 2025년 거래 뱅킹 연구는 Kyriba, GTreasury 같은 트레저리 관리 플랫폼과 Bill.com 같은 CFO 오피스 플랫폼이, 고객과 은행 사이에서 은행 중립적인 단일 포지션 뷰를 가지고 자리 잡는 모습을 서술한다. 그것은 정확히, 리테일에서 Plaid와 Tink 뒤로 롱테일을 조용히 사라지게 한 바로 그 계층이다. 동일한 연구는 이제 기업 트레저러가 자신의 은행을 소비자 앱의 기준으로 재단하며, 온보딩, 권한, API 통합이 실망시키면 이탈할 것이라고 지적한다.

선택의 전략적 내용은 무디게 직설적이다. 애그리게이터의 에이전트 계약 뒤의 엔드포인트가 되는 은행은 세 가지를 한꺼번에 내준다. 마진 — 그 서비스가 타인의 인터페이스를 통해 상품화되고 가격 우선으로 비교되기 때문이다. 고객 소유권 — 관계, 맥락, 전환 비용이 플랫폼으로 이전하기 때문이다. 그리고 데이터 및 분석 역량 — 한때 전 구간을 보던 흐름이 이제 은행보다 고객을 더 많이 보는 중개자에 의해 매개되기 때문이다. 자신의 표면을 표준화하는 것은 기술적 위생 프로젝트가 아니다. 그것은 거래상대방이 되느냐와 상품이 되느냐의 차이다.

표준이 반드시 의무화해야 할 것

없는 방향은 이색적이지 않다. 모든 구성 요소가 이미 공개적으로 존재한다 — 데이터에는 ISO 20022, 참조 운영에는 Swift의 Payment Initiation 및 Instant Cash Reporting API, 시맨틱스에는 BIAN, 동의-및-카탈로그 패턴에는 Berlin Group의 openFinance, 금융 등급 인증에는 FAPI, 도구 노출에는 MCP, 에이전트 간 오케스트레이션에는 A2A. 부재한 것은 그것들을 기업 영역을 위한 구속력 있는 계약으로 조립하는 행위 — 그리고 하나가 아닌 두 개의 하한선을 명세하는 규율이다. McKinsey를 포함한 기존 B2B-API 문헌은 API를 대체로 성장과 경험의 기회로 다룬다. 그것은 결정론, 런타임 역량 발견, 표준화된 비기능 요소 — 정확히 에이전트가 용인할 수 없는 누락 — 에 대해서는 거의 말하지 않는다. 그러므로 표준은 인터페이스가 무엇인지와 그것이 거버넌스 아래에서 어떻게 행동하는지 양쪽 모두에 대해 명시적이어야 한다.

기술적 하한선

거기서 생성된 정규(canonical) MCP 도구 매니페스트를 갖춘 OpenAPI 우선 계약 — 그것 옆에 손으로 작성한 것이 아니라, 에이전트가 보는 도구가 은행이 운영하는 API로부터 결코 벗어날 수 없도록.
FAPI 등급의 인증과 동의 — 표면 전체에 걸친 단일 핸드셰이크로서.
멱등성과 결정론적 오류 분류 체계 — 안정적인 코드, 실패마다 하나의 의미, 계약 자체에 문서화됨.
ISO 20022 네이티브 페이로드 — 구조화되고 하이브리드 주소 대응 준비가 된.
런타임 역량 발견을 갖춘 시맨틱 버저닝 — 에이전트가 이 거래상대방이 오늘 무엇을 할 수 있는지 물어 기계 응답을 받을 수 있도록.

거버넌스 및 복원력 하한선

공개되고 강제되는 비기능 SLO — 지연, 가용성, 처리량, STP(straight-through-processing), 인적 노력 — 마케팅 언어가 아니라 실제 시간-동작 수치로 표현됨.
실행 경로에 결속된 권한, 동의, 변조 방지 감사 추적 — 대역 외 포털에 떠 있는 것이 아니라.
SR 11-7, DORA, EU AI Act에 정렬된 모델 리스크 및 운영 복원력 통제 — 에이전트의 호출이 이색적인 엣지 케이스가 아니라 소유자가 있는 거버넌스된 이벤트가 되도록.

여기 리테일 경험에 묻힌 뼈아픈 교훈이 있다. 기계가 실행하는 표준은 인간 통합 담당자가 조용히 수리할 수 있는 표준보다 더 정밀해야 한다. 불충분한 명세는 더 이상 개발자 시간으로 치르는 부드러운 비용이 아니라, 잘못 보내진 결제로 치르는 단단한 장애 양상이다. 업계에서 가장 권위 있는 조화(harmonisation) 노력 — CPMI와 PMPG의 조화된 ISO 20022 데이터 요구사항으로, 정확히 이 파편화와 싸우기 위해 G20 국경 간 결제 프로그램 아래에서 전 세계 결제 시스템이 2027년 말까지 채택하도록 촉구받고 있다 — 이 스스로의 서술에 따르면 규제도 API 표준도 아니라는 점은 시사적이다. 그것은 데이터를 조화시킨다. 인터페이스는 여전히 누구의 몫도 아니다.

목표 그림

구축은 진단보다 덜 벅차다. 그것은 프로그램이 아니라 세 개의 계층이기 때문이다. 정규 기업 뱅킹 API가 REST와 OpenAPI 위로 결제와 현금 보고를 노출하며, ISO 20022 네이티브 페이로드와 FAPI 등급 인증을 갖춘다 — 하나의 계약, 하나의 문법, 하나의 핸드셰이크. MCP 브리지가 그 위에 앉아, 에이전트 대면 도구 매니페스트를 그 OpenAPI 계약에서 직접 생성하므로, 발견, 스키마, 권한이 표면과 병렬로 유지되는 것이 아니라 표면으로부터 파생된다. 그리고 정책 및 복원력 계층이 모든 에이전트 호출을 자율성을 안전하게 만드는 통제로 감싼다. 거래 및 거래상대방 한도, 세분화, 인간 개입 트리거(고위험 행동에 대한 elicitation), 실시간 SLO 모니터링, 그리고 단단한 킬 스위치. 요점을 파악하는 데 도표는 필요 없다 — 표준은 새로운 레일이 아니라, 이미 존재하는 레일들의 규율 있는 배치이며, 사건 이후에 볼트로 덧붙이는 것이 아니라 첫 커밋부터 에이전트 경로와 거버넌스 경로가 내장된 것이다.

신뢰할 만한 은행이 향후 24개월 안에 하는 일

호출자가 바뀌었다는 것을 받아들이면, 작업은 구체적이며 다섯 개의 트랙으로 나뉜다.

ISO 20022 네이티브의 OpenAPI 우선 표면을 공개하라. 고가치 코리도 하나 — 통상 국경 간 결제와 현금 보고 — 를 택해, 다섯 번째로 발명된 문법이 아니라 기존 CBPR+ 스키마에 정렬된 ISO 20022 페이로드를 갖춘 단일 버전 관리 OpenAPI 정의를 통해 노출하라. 그것을 샌드박스와 함께 고객과 내부 에이전트에게 공개하고, 변경을 제품 릴리스로 취급하라. 1년 차의 성공은 전면 커버리지가 아니다. 그것은 하나의 코리도가 전 구간에 걸쳐 에이전트가 주소 지정 가능하도록 만들어질 수 있음을 입증하는 것이다.
그 전체에 걸쳐 인증과 멱등성을 표준화하라. 하나의 FAPI 등급 프로파일을 유일한 핸드셰이크로 채택하고, 모든 쓰기에 멱등성 키를 의무화하며, "동일한 지시를 재시도한다"를 계약에 문서화된 보증으로 만들어 — "에이전트는 재시도할 것이다"를 리스크에서 안전한 가정으로 바꾸라.
결정론적 오류 문법과 역량 발견을 정의하라. 모든 실패에 안정적인 코드와 일관된 시맨틱스를 부여하고, 시맨틱 버저닝을 추가하며, 부분 지원, 폐기 예정, "아직 사용 불가"에 대한 명시적 플래그와 함께 에이전트가 런타임에 질의할 수 있는 역량 카탈로그를 노출하라.
권한, 동의, 감사를 동일한 표면에 부착하라. 동의와 승인 흐름을 API 경로로 옮기고, 모든 에이전트 개시 지시에 대해 변조 방지 추적 — 누가, 무엇을, 언제, 어느 정책 밴드 아래에서 — 을 방출하며, 두 번째 방어선(second line)이 이를 승인할 수 있도록 SR 11-7, DORA, EU AI Act에 명시적으로 정렬하라.
비기능 하한선을 공개한 뒤, 감독되는 에이전트 파일럿을 운영하라. 그 코리도에 대한 지연, 가용성, 처리량, STP 목표를 약속하고 계측하라. 그런 다음 오직 이 표면만 사용하는 감독되는 유동성 또는 현금 스위핑 에이전트를, 단단한 한도, 인간 개입 체크포인트, 완전한 감사와 함께 6개월에서 12개월 동안 세워라. 이것이 당신 스스로 통제하는 강제 함수(forcing function)다 — 그것은 표면이 예측 가능할 때 에이전트가 정책 밴드 안에서 안전하게 자금을 움직일 수 있음을 입증하고, 당신의 표준이 여전히 사실이 아니라 열망에 머무는 곳이 어디인지를 빠르게 알려준다.

강제 함수

업계는 방금 무언가가 강제할 때 움직일 수 있음을 입증했다. 2026년 11월 Swift의 구조화 주소 전환 — 그 이후로 국경 간 결제의 비구조화 주소는 비상 변환 없이 단순히 거절된다 — 은 마지못한 시장을 고정된 날짜에 구조화된 ISO 20022 데이터로 끌고 갔으며, G20 결제 프로그램 전반에 걸친 조화된 데이터 요구사항을 위한 CPMI의 2027년 말 압박으로 보강되었다. 두 노력이 무엇을 표준화하는지 주목하라. 인터페이스가 아니라 데이터다. 문법은 깨끗하게 강제되고 있다. 표면은 각 은행의 재량에 맡겨졌다 — 그것이 바로 에이전트가 다룰 수 없는 재량이다. 에이전트에게 그것은, 페이로드는 마침내 일관될 것이나 그 뒤의 행동은 여전히 발산할 것임을 의미한다 — 기계가 실제로 필요로 하는 것, 즉 예측 가능한 행동이 먼저이고 깨끗한 데이터가 그다음인 것의, 뒤집힘이다.

그러니 이것이 피해야 할 자책골이다. 행동하기 전에 글로벌 위원회가 기업 뱅킹 API 표준을 축복하기를 기다리는 것. ISO 20022 네이티브의 에이전트 대응 표면을 지금 공개하는 은행 — OpenAPI 계약, 거기서 생성된 MCP 매니페스트, 금융 등급 인증, 그리고 실제로 뒷받침할 비기능 하한선 — 은 자율 트레저리의 기본 거래상대방이 될 것이다. 그들의 도구가 에이전트가 인간의 개입 없이 발견하고, 신뢰하고, 호출할 수 있는 도구가 될 것이다. 기다리는 은행은 애그리게이터의 추상화를 통해서만 도달 가능해져, 어댑터를 소유한 자에게 자신의 고객 관계를 임대하게 될 것이다.

방향 없는 문법은 표준이 아니다. ISO 20022는 기업 뱅킹에 어떻게 말할지를 알려주었다. 그것은 어디로 가야 할지는 결코 알려주지 않았다. 에이전트가 도착했다. 유창하고 참을성 없이. 그런데 지도는 여전히 그곳에 없다. 그것을 그리는 일이 이제 거래 뱅킹에서 가장 중대한 인프라 작업이다 — 그리고, 모처럼, 마감 시한은 규제 당국이 아니라 이미 인터페이스에서 기다리고 있는 기계들이 설정하고 있다.

자주 묻는 질문

ISO 20022가 없는 표준 아닌가? 아니다. ISO 20022는 데이터 문법이지 API 계약이 아니다. pain.001은 시스템에 신용 이체를 어떻게 표현할지는 알려주지만, 어느 엔드포인트가 그것을 생성하는지, 어떻게 인증하는지, 어떻게 페이지네이션하는지, 어떻게 실패를 보고하는지는 말하지 않는다. 문법은 에이전트에 준비되어 있다. 표면 — 에이전트가 실제로 호출하는, 기계가 발견 가능하고 균일하게 행동하는 인터페이스 — 은 그렇지 않다.

그냥 모든 은행을 MCP 서버로 감싸면 안 되나? 파편화를 제거하는 것이 아니라 이전시키기 때문이다. 40개의 은행은 40개의 시맨틱스, 40개의 인증 흐름, 그리고 — 결정적으로 — 공유된 비기능 하한선의 부재를 가진 40개의 서버가 된다. 공통의 지연 예산도, 합의된 가용성 등급도, 비교 가능한 멱등성 보증도 없다. 호출자는 이제 결제 레일에 쓰기 권한을 가진 비결정론적 모델이며, 이는 SR 11-7, DORA, EU AI Act 아래의 모델 리스크 및 운영 복원력 문제다. 수천 개의 맞춤형 서버는 표준이 아니다.

은행에게 가장 유용한 단 하나의 첫 수는 무엇인가? ISO 20022 네이티브의 OpenAPI 우선 코리도 하나 — 통상 국경 간 결제와 현금 보고 — 를 FAPI 등급 핸드셰이크, 문서화된 보증으로서의 멱등성, 그리고 결정론적 오류 문법과 함께 공개하는 것이다. 그런 다음 오직 그 표면만을 상대로, 단단한 한도, 인간 개입 체크포인트, 완전한 감사와 함께 감독되는 에이전트 파일럿을 운영하라. 하나의 코리도를 전 구간에 걸쳐 입증하는 것이, 모든 것을 커버하면서 아무것도 의무화하지 않는 로드맵을 이긴다.

은행이 하지 않으면 누가 이것을 해소하나? 애그리게이터다. 소수의 트레저리 및 CFO 오피스 플랫폼이 사실상의 에이전트 계약을 정의하고, 은행은 그 뒤의 교체 가능한 엔드포인트가 되어 — 마진, 고객 소유권, 전 구간 데이터를 한꺼번에 내준다. 그것은 Plaid와 Tink가 롱테일을 흡수한 리테일 이야기가, 기업 뱅킹으로 한 세그먼트 앞으로 진행되는 것이다.

참고 문헌

Model Context Protocol — 공식 문서 ⧉. [MCP는 2024년 11월에 오픈소스로 공개되어 2025년 12월에 Block, OpenAI와 함께 Linux Foundation의 Agentic AI Foundation에 기증되었다. 분석이 기반으로 삼는 런타임 도구 발견 계층. 본문의 채택 수치는 방향성 있는 업계 판독이며 그렇게 명시되어 있다.]
Berlin Group — NextGenPSD2와 openFinance ⧉. [사실상의 유럽 리테일 API 표준과 기업 사용 사례로의 확장 — 동의-및-카탈로그 패턴 및 리테일 대 기업 대비를 위해 인용됨.]
Financial Data Exchange (FDX) ⧉. [미국 리테일 데이터 공유 표준으로, 기업 뱅킹에 상응하는 것이 없는 표준화된 리테일 계약의 규모를 위해 인용됨.]
McKinsey & Company — 금융 서비스 인사이트 ⧉. [거래 뱅킹 API 연구: host-to-host / SFTP 유산, ~85% 현금 관리 API 투자 의향, 그리고 트레저리 플랫폼 중개. 시장 진단을 위해 인용됨. 여기서의 틀 짓기와 결론은 저자 자신의 것이다.]
국제결제은행(BIS) CPMI — 조화된 ISO 20022 데이터 요구사항 ⧉. [결제 데이터를 조화시키려는 2027년 말 압박으로 — 스스로의 서술에 따르면 규제도 API 표준도 아니며 — "표면 없는 문법" 논점을 위해 인용됨.]
Swift — 금융 기관을 위한 ISO 20022 ⧉. [CBPR+와 2026년 11월 구조화 주소 이정표. Payment Initiation 및 Instant Cash Reporting API는 보편적 표면이 아니라 참조 운영으로 인용됨.]

최종 검토 2026년 7월. 독자적 분석이며, 출처는 인용되었을 뿐 재현되지 않았다. 채택 및 시장 수치는 방향성 있는 업계 판독이므로 재발행 전에 1차 출처와 대조하여 검증할 것. CC-BY-4.0 라이선스 하에 배포됨.

최종 검토 2026-07-08.

이 기사 재게시

파편화에서 균열선으로: 에이전트 시대에 기업 뱅킹에 없는 API 표준 — Sebastien Rousseau

리테일 뱅킹은 10년 전에 API 표준을 얻었다. 기업 뱅킹은 끝내 얻지 못했고, 이제 AI 에이전트와 Model Context Protocol이 통합을 런타임 결정으로 바꾸면서 그 공백은 균열선이 되었다.

이 기사의 라이선스는 Creative Commons Attribution 4.0 International. 재게시 시 정규 URL 출처 표시가 필요합니다.

파편화에서 균열선으로: 에이전트 시대에 기업 뱅킹에 없는 API 표준 — Sebastien Rousseau

리테일 뱅킹은 10년 전에 API 표준을 얻었다. 기업 뱅킹은 끝내 얻지 못했고, 이제 AI 에이전트와 Model Context Protocol이 통합을 런타임 결정으로 바꾸면서 그 공백은 균열선이 되었다.

Originally published at https://sebastienrousseau.com/ko/2026-07-07-corporate-banking-api-standard-agentic-mcp-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER