[The Blueprint - AI 금융 아키텍처 설계 (2/7)] "정문" 설계: 연합 API 게이트웨이

"The Blueprint"의 두 번째 설계 여정에 오신 것을 환영합니다 .

 

지난 [1/7]에서는 AI Agent와 모든 서비스가 살아갈 견고하고 탄력적인 '대지(P5, 플랫폼)'를 설계했습니다 . 하지만 '대지'가 아무리 튼튼해도, 외부와 소통하는 통로가 무질서하다면 아무 소용이 없습니다.

 

이번 장에서는 **[원칙 2: AI Agent의 데이터 접근은 API 게이트웨이를 통하라]**는 원칙을 기반으로 , 이 하이브리드 플랫폼의 유일한 '정문(Front Door)'을 설계합니다 . 우리의 목표는 AI Agent가 사용할 '도구 상자(Toolbelt)'로 들어가는 입구를 설계하는 것입니다 .

원칙 2: 왜 "정문"이 필요한가?

AI Agent가 은행의 핵심 원장(DB)에 직접 접근하도록 허용하는 것은, 회계 장부가 보관된 금고를 누구나 열람하도록 두는 것과 유사한 위험을 가집니다 .

 

'원칙 2'는 모든 데이터와 거래는 **'API 게이트웨이(API Gateway)'**라는 잘 통제된 아키텍처 패턴을 통해서만 접근해야 함을 의미합니다 .

• 역할: AI Agent의 모든 동기식(Synchronous) '명령/조회' (예: POST /api/loan, GET /customer)는 오직 이 게이트웨이를 통합니다 .
• 이유: 이는 AI의 모든 활동을 중앙에서 모니터링하고 , 금융사의 가장 민감한 핵심 시스템을 보호하는 중요한 '안전장치(Safety Mechanism)' 역할을 합니다 .

 

현실의 챌린지: 흩어진 "정문"

 

[0/7]에서 정의했듯, 우리는 '하이브리드 지옥'에 처해 있습니다 . '핵심 뱅킹 앱'은 프라이빗 클라우드(On-prem K8s)에, '디지털 지갑' 서비스는 퍼블릭 클라우드(Public K8s)에 있습니다 .

 

만약 각 영역이 api.private.bank.com과 api.public.bank.com처럼 각자의 '정문'을 사용한다면, AI Agent는 두 개의 서로 다른 주소를 모두 알고 관리해야 하는 복잡성이 생깁니다.

 

[설계 이슈 2] 어떻게 api.bank.com이라는 **단일 진입점(Single Entrypoint)**으로 , 하이브리드 환경(프라이빗/퍼블릭)에 흩어진 모든 API를 '하나의 API'처럼 보이게 하고, 올바른 위치로 라우팅하며, 통제할 수 있을까요?

 

해결 전략: "연합(Federation)"

이 복잡한 이슈를 해결하는 핵심 키워드는 '연합(Federation)'입니다. 우리는 '정문'을 설계하기 위해 두 가지 연합 전략을 수립해야 합니다.

 

1. 솔루션 1: 연합 게이트웨이 (Federated Gateway)

첫 번째는 '라우팅(Routing)'의 연합입니다.

• What: 이는 api.bank.com이라는 단일 진입점을 통해, 요청의 종류에 따라 트래픽을 올바른 클라우드로 중계하는 '글로벌 라우팅' 전략입니다 .
• How: 기술적으로는 Kong, Apigee, Spring Cloud Gateway 같은 솔루션들을 '연합 게이트웨이' 패턴으로 구성합니다 .
• Example:
  - api.bank.com/core/loan (핵심 뱅킹) → 프라이빗 클라우드(On-prem K8s)로 라우팅
  - api.bank.com/digital-wallet/charge (디지털 지갑) → 퍼블릭 클라우드(Public Cloud)로 라우팅
  

AI Agent(혹은 사용자)는 서비스가 물리적으로 어디에 있는지 알 필요 없이, 단일 '정문' 주소만 알면 됩니다.

 

2. 솔루션 2: 연합 신원 (Federated Identity)

 

두 번째는 '보안(Security)'의 연합입니다. '정문'은 단순한 길 안내자가 아니라, **[원칙 1: 통제]**를 수행하는 '집행자'여야 합니다 .

• What: 이는 프라이빗이든 퍼블릭이든 상관없이, api.bank.com에 접근하는 모든 AI Agent의 '신원'을 단일한 기준으로 검증하고 '권한'을 강제하는 '중앙 인증/인가(Unified AuthN/AuthZ)' 설계입니다 .
• How: 게이트웨이는 AI Agent가 제시한 **JWT 토큰(신원)**을 검증합니다 .
• Example:
  - Agent A가 scope: [loan:read] (대출 조회) 권한만 가졌는지 확인합니다 .
  - 만약 이 Agent가 POST /core/loan (대출 실행) API를 호출하려 하면, '정문'은 이 토큰에 loan:execute 스코프가 없음을 확인하고 즉시 호출을 차단합니다 .
  

 

다음 이야기: "신경망"을 설계합니다

 

지금까지 우리는 '정문(P2)'을 설계하여, AI Agent가 시스템에 '명령'하고 '조회'하는 동기식(Synchronous) 통로를 구축했습니다 .

하지만 진정한 'Agentic AI'는 명령을 기다리는 것이 아니라, '상황을 인지'하고 선제적으로 행동해야 합니다 . 고객의 '잔액 부족' 이벤트를 실시간으로 알아채야 합니다. 이를 위해서는 '실시간 신경망'이 필요합니다 .

 

다음 [The Blueprint 3/7]에서는 **[원칙 3: EDA]**를 기반으로 , AI Agent가 실시간 이벤트를 구독할 수 있는 비동기식(Asynchronous) '신경망'을 설계합니다 .

 

특히, '하이브리드 지옥' 속에서 , 퍼블릭 클라우드('디지털 지갑')의 이벤트를 프라이빗 클라우드('AI 비서')가 어떻게 '안전하게' 수신할 수 있는지 , 그 '이벤트 브릿징' 전략을 탐험해 보겠습니다 .