"The Blueprint"의 첫 번째 설계 여정에 오신 것을 환영합니다.
지난 [0/7]에서 우리는 'A 은행'의 비전과 세 가지 '현실의 지옥'을 정의했습니다. 이제 이 난제들을 해결하기 위한 5대 원칙을 실제 아키텍처로 구현하는 설계를 시작합니다 .
우리의 첫 번째 설계 대상은 **[원칙 5: 견고하고 탄력적인 플랫폼]**입니다 . AI 에이전트와 모든 서비스가 24시간 365일 살아갈 '대지(Land)'를 먼저 튼튼하게 다져야 하기 때문입니다 .
원칙 5: 왜 "대지"가 필요한가?
AI Agent는 결국 '소프트웨어'입니다 . 특정 서버가 다운됐다고 수백 개의 Agent가 함께 멈추는 상황은 금융 서비스에서 재앙이 될 수 있습니다 .
따라서 '원칙 5'는 AI Agent 역시 현대적인 플랫폼 위에서 운영되어야 함을 의미합니다 . 이 플랫폼은 '클라우드 네이티브' 원칙에 기반하여, 장애가 발생하면 **'자동 복구(Self-Healing)'**되고 트래픽에 따라 **'탄력적으로 확장(Elastic Scaling)'**되어야 합니다 .
이것이 우리가 설계할 '대지'의 핵심 요구사항입니다.
현실의 챌린지: 쪼개진 "대지"
우리는 [0/7]에서 '하이브리드 지옥'이라는 첫 번째 제약 조건을 정의했습니다 . 'A 은행'의 '대지'는 하나가 아니라 둘로 쪼개져 있습니다.
- 영역 1 (Private): 핵심 뱅킹 앱은 보안과 규제 준수를 위해 사내 **프라이빗 PaaS(On-prem K8s)**로 이전해야 합니다 .
- 영역 2 (Public): '디지털 지갑' 같은 신규 서비스는 빠른 확장을 위해 **퍼블릭 클라우드(예: AWS EKS, Azure AKS)**에 구축되고 있습니다 .
이 두 영역은 물리적으로 분리되어 있습니다. 이것이 이번 설계의 핵심 이슈입니다.
[설계 이슈 1] 어떻게 프라이빗 클라우드(On-prem K8s)와 퍼블릭 클라우드(Public Cloud K8s)를 **'하나의 논리적 플랫폼'**으로 묶어낼 수 있을까요?
해결 전략: "대지"를 연결하는 두 가지 접근법
이 '쪼개진 대지'를 하나의 플랫폼처럼 관리하고 연결하기 위해, 우리는 두 가지 핵심 전략을 검토하고 설계에 반영해야 합니다.
1. 솔루션 1: 네트워크 레벨 연결 (CMP)
첫 번째는 '멀티 클라우드 관리 플랫폼(CMP)'을 도입하는 것입니다 .
- What: Anthos, Rancher와 같은 솔루션입니다 .
- How: 이는 여러 K8s 클러스터(프라이빗/퍼블릭)를 하나의 중앙화된 '관리 콘솔'에서 배포하고 제어할 수 있게 돕습니다. 이는 주로 네트워크 및 인프라 관리 차원에서의 통합을 제공합니다.
2. 솔루션 2: 서비스 레벨 연결 (Service Mesh)
두 번째는 '멀티 클러스터 서비스 메시(Service Mesh)'를 구축하는 것입니다 .
- What: Istio와 같은 솔루션입니다 .
- How: 이는 개별 서비스(마이크로서비스)들이 서로 다른 클러스터에 존재하더라도, 마치 '하나의 K8s' 안에 있는 것처럼 서로를 발견하고 통신할 수 있게 만듭니다 . CMP가 '관리'의 통합이라면, 서비스 메시는 '서비스 간 통신'의 논리적 통합을 제공합니다.
"대지"와 "통제"의 연결
우리가 K8s를 '대지'로 선택하는 데는 단순한 확장성 외에 더 중요한 이유가 있습니다 . 바로 K8s가 **[원칙 1: 통제]**를 구현하는 핵심 '기술적 기반'이 되기 때문입니다 .
- K8s의 **'ServiceAccount'**는 AI Agent에게 **'신원(Identity)'**을 부여하는 기반이 됩니다 .
- K8s의 **'NetworkPolicy'**는 AI Agent가 접근할 수 있는 범위를 제한하는 **'권한(Permission)'**의 기술적 기반이 됩니다 .
'대지'를 잘 설계하는 것은 단순히 서버를 띄우는 것이 아니라, 시스템 전체의 '보안'과 '통제'의 첫 단추를 끼우는 일입니다.
다음 이야기: "정문"을 설계합니다
지금까지 우리는 AI Agent가 살아갈 견고하고 탄력적인 '대지(P5)'를 설계했습니다 . 또한 하이브리드 환경을 연결하는 전략도 수립했습니다 .
하지만 이 '대지'에 외부 사용자와 AI가 접근하려면 잘 통제된 '입구'가 필요합니다.
다음 [The Blueprint 2/7]에서는 **[원칙 2: API 게이트웨이]**를 기반으로 , 이 하이브리드 플랫폼의 유일한 '정문(Front Door)'을 설계합니다 .
api.bank.com이라는 단일 진입점으로 , 어떻게 프라이빗과 퍼블릭 클라우드에 흩어진 서비스들을 '하나의 API'처럼 보이게 하고 통제할 수 있을지 , 그 '연합 게이트웨이' 전략을 탐험해 보겠습니다 .
'Track 2. AI Infrastructure > Financial AI Arch' 카테고리의 다른 글
| [The Blueprint - AI 금융 아키텍처 설계 (3/7)] "신경망" 설계: 하이브리드 EDA와 이벤트 브릿징 (2) | 2025.11.14 |
|---|---|
| [The Blueprint - AI 금융 아키텍처 설계 (2/7)] "정문" 설계: 연합 API 게이트웨이 (0) | 2025.11.03 |
| [The Blueprint - AI 금융 아키텍처 설계 (0/7)] : "Agentic AI" 비전과 현실의 제약 (0) | 2025.11.02 |
| [Finaitech 5대 원칙 5/5] 견고하고 탄력적인 플랫폼은 이제 기본이다. (0) | 2025.10.30 |
| [Finaitech 5대 원칙 4/5] 분산 데이터를 하나의 통합 뷰로 제공하라. (0) | 2025.10.30 |