Track 2. AI Infrastructure/Financial AI Arch

[Finaitech 5대 원칙 5/5] 견고하고 탄력적인 플랫폼은 이제 기본이다.

Context Lab 2025. 10. 30. 00:14

'finaitech' 5대 원칙 시리즈의 마지막 글입니다.
 
지금까지 우리는 '원칙 1(통제)'이라는 AI의 윤리, '원칙 2/3(API/EDA)'라는 '신경망', 그리고 '원칙 4(통합 뷰)'라는 '뇌'를 설계했습니다. 이로써 AI Agent는 똑똑하고, 통제 가능하며, 데이터에 기반해 사고할 수 있게 되었습니다.
 
하지만 이 완벽한 AI의 뇌와 신경망이, 낡고 불안정한 '몸(플랫폼)' 위에 올라간다면 어떻게 될까요?
 
AI Agent는 결국 24시간 365일 작동해야 하는 핵심 '소프트웨어'입니다. 'AI 금융 비서'가 "새벽 3시에는 디스크 장애로 멈추고", "오전 9시에는 사람이 몰려 다운"된다면, 우리가 설계한 모든 것은 무용지물이 됩니다.
 

안티-패턴: '전통 서버'에 AI Agent를 올릴 때

'왜' 새로운 플랫폼이 '기본'인지 설득하기 위해, '기존' 방식이 AI 시대에 왜 실패하는지부터 보겠습니다.
시나리오 1 (견고함 / Resilience 없음):

  • 상황: 새벽 3시, 'AI FDS(이상거래탐지) Agent'가 실행 중이던 VM(가상서버)의 물리적 디스크가 깨졌습니다.
  • 결과 (최악): 'AI FDS'가 멈춥니다. 은행은 (1) 모든 거래를 중단시키거나 (2) 혹은 더 위험하게, 모든 사기 거래를 그대로 통과시켜야 합니다. 엔지니어가 출근하여 수동으로 복구할 때까지 속수무책입니다.

시나리오 2 (탄력성 / Elasticity 없음):

  • 상황: 아침 9시 1분, 1천만 고객이 'AI 금융 비서'를 동시에 호출했습니다.
  • 결과 (최악): 'AI 비서'가 올라간 8코어(Core) VM은 즉시 CPU 100%를 기록합니다. AI의 응답 시간은 1초에서 30초로 늘어납니다. 사실상 서비스가 마비됩니다.

 

해결책: '클라우드 네이티브'가 AI를 구원하는 법

이 두 가지 재앙을 해결하는 현대적인 플랫폼 원칙이 바로 **'클라우드 네이티브(Cloud-Native)'**이며, 이를 구현하는 표준 기술이 '쿠버네티스(Kubernetes, K8s)' 기반의 PaaS입니다.
 
K8s는 AI Agent에게 '견고함'과 '탄력성'이라는 두 가지 핵심 능력을 부여합니다.

1. 견고함(Resilience)은 '자동 복구(Self-Healing)'로 완성됩니다.

  • 비유: K8s는 24시간 AI Agent의 '심박(Health Check)'을 체크하는 **'중환자실(ICU) 의사'**입니다.
  • 작동 방식: '디스크가 깨져' AI Agent의 심박(Liveness Probe)이 멈추는 순간, K8s는 즉시 '사망 선고'를 내리고, 단 5초 만에 건강한 다른 서버에 AI Agent를 **'자동으로 재시작'**시킵니다.
  • 결과: 엔지니어의 수동 개입 없이, 'AI FDS'는 5시간이 아닌 5초 만에 복구됩니다.

2. 탄력성(Elasticity)은 '수평적 확장(Elastic Scaling)'으로 완성됩니다.

  • 비유: K8s는 '대형 레스토랑의 지배인(HPA)'입니다.
  • 작동 방식: 아침 9시 '손님(트래픽)'이 몰려드는 것을 '지배인(HPA, Horizontal Pod Autoscaler)'이 감지합니다. 즉시 주방(Server)에 'AI 비서(Pod)'를 1개에서 50개로 자동 증설합니다.
  • 결과: 1천만 고객이 동시 접속해도 AI 비서는 여전히 1초의 응답속도를 유지합니다.

 

특히 'AI 플랫폼'이 더 어려운 이유: "GPU"

여기서 'AI 플랫폼'은 일반 PaaS보다 한 단계 더 나아갑니다.
 
AI, 특히 LLM과 RAG는 CPU/Memory뿐만 아니라 'GPU'라는 특수하고 값비싼 자원을 필요로 합니다.
 
기존의 PaaS는 CPU/Memory만 관리했다면, AI PaaS는 이 비싼 GPU 자원을 어떻게 격리하고, 나눠 쓰며(Time-Slicing, MIG), 낭비 없이 스케줄링할 것인가라는 훨씬 더 어려운 숙제를 안고 있습니다. (이는 'AI 플랫폼 엔지니어링' 카테고리에서 자세히 다룰 주제입니다.)
 

최종 결론: 5대 원칙의 완성

'원칙 5'는 단순히 인프라에 대한 이야기가 아닙니다. 이것은 우리가 앞서 설계한 **네 가지 원칙을 완성시키는 '대지(Foundation)'**입니다.

  • 이 플랫폼(P5)은 **'원칙 1(통제)'**을 K8s의 NetworkPolicy나 ServiceAccount를 통해 기술적으로 강제하는 **'집행 도구(Enforcer)'**입니다.
  • 이 플랫폼(P5)은 **'원칙 2(API-GW)'**와 '원칙 3(EDA)' 같은 핵심 컴포넌트들이 24시간 죽지 않고 돌아가게 하는 **'생명유지장치'**입니다.
  • 이 플랫폼(P5)은 **'원칙 4(통합 뷰)'**가 수천만 건의 쿼리를 처리할 수 있도록 '탄력적으로' 확장하는 기반입니다.

'뇌(P4)'와 '신경망(P2, P3)'이 아무리 완벽해도, 그것을 지탱할 **'견고한 척추(P5)'**가 없다면 AI는 즉시 무너집니다.
 
AI 아키텍트는 'AI 모델'을 설계하는 사람이 아니라, 이 모든 원칙이 유기적으로 작동하는 **'살아있는 시스템'**을 설계하는 사람입니다. '견고하고 탄력적인 플랫폼'은 그 설계를 위한 선택이 아닌, '기본'입니다.
 
이상으로 [finaitech 5대 원칙] 시리즈를 마칩니다. 5대 원칙이 '지도'였다면, 이제는 이 지도를 바탕으로 실제 '건축 설계도'를 그릴 차례입니다. 이 '청사진' 시리즈는 5대 원칙을 어떻게 유기적으로 엮어 실제 금융 서비스에 적용하는지 보여줄 예정입니다.