Track 2. AI Infrastructure/Financial AI Arch

[Finaitech 5대 원칙 2/5] AI Agent의 데이터 접근은 API 게이트웨이를 통하라.

Context Lab 2025. 10. 29. 23:59

'finaitech' 5대 원칙의 첫 번째 글에서, 우리는 **"똑똑한 AI보다 통제 가능한 AI가 먼저다"**라는 철학을 공유했습니다.
 
그렇다면 이 '통제'를 기술적으로 구현하는 가장 핵심적인 아키텍처는 무엇일까요? 이 질문에 답하기 위해, 먼저 '최악의 아키텍처(Anti-Pattern)'부터 살펴보겠습니다.
 
그것은 바로 **"AI Agent에게 은행 핵심 원장(DB)의 Connection String(접속 정보)을 주는 것"**입니다.
 
이는 '유능한 슈퍼 인턴(AI Agent)'에게 은행 **'금고의 마스터키'**를 주고 퇴근하는 것과 같습니다. AI가 아무리 똑똑하더라도, 이 아키텍처는 단 하나의 실수나 해킹으로도 은행 전체를 마비시킬 수 있는 재앙의 지름길입니다.
 

AI가 DB에 직접 접근할 때 벌어지는 4가지 재앙

AI Agent에게 '금고 마스터키(DB 직접 접근 권한)'를 주었을 때 발생할 수 있는 4가지 치명적인 재앙입니다.
 

1. 재앙 1: 비즈니스 로직 우회 (Bypassing Business Logic)

가장 치명적인 문제입니다. "고객의 1일 이체 한도는 1,000만 원", "VIP 고객은 수수료 면제", "대출 한도는 신용등급 기반 5천만 원" 같은 모든 금융 규정과 핵심 **'비즈니스 로직'**은 DB가 아닌 **'애플리케이션(MSA)'**에 있습니다.
AI가 DB에 직접 UPDATE 쿼리를 날린다면, 이 모든 비즈니스 규칙과 금감원 규제(Compliance)를 우회하게 됩니다. AI가 실수로 고객의 잔액을 마이너스로 만들거나, 한도를 초과하는 대출을 승인할 수도 있습니다.
 

2. 재앙 2: 시스템 마비 (The "Rogue AI" Problem)

AI Agent는 학습 과정에서 실수로, 혹은 의도적으로 비효율적인 쿼리를 날릴 수 있습니다.
(상상) 금요일 오전 9시 1분, AI Agent가 "이번 달 가장 많이 이체한 고객 패턴 분석"을 위해 SELECT * FROM [100억 건 거래 원장] WHERE ... 같은 Full Scan 쿼리를 날립니다. 그 결과, 은행의 코어뱅킹 시스템 전체가 멈추고 모든 고객의 거래가 마비됩니다. AI는 시스템 자원을 블랙홀처럼 빨아들이는 '시끄러운 이웃(Noisy Neighbor)'이 될 수 있습니다.
 

3. 재앙 3: 보안 및 감사 재앙 (Security & Audit Catastrophe)

  • 보안: AI Agent가 해킹당하면, 해커는 DB의 모든 테이블을 DROP하거나 고객 정보를 유출할 '마스터키'를 손에 쥔 것입니다.
  • 감사: 더 심각한 것은 감사가 불가능하다는 점입니다. "누가" 이 데이터를 수정했는지 DB 로그에는 agent-id가 남는 것이 아니라, JDBC-Connection-User라는 공용 ID만 남게 됩니다. 이는 **'원칙 1(감사)'**을 정면으로 위배하며, 금융사고 시 책임 추적이 불가능합니다.

 

4. 재앙 4: 아키텍처의 종속 (Tight Coupling)

AI가 DB 스키마(테이블 구조)를 직접 알게 되면, AI와 DB는 평생 묶이게 됩니다. 만약 은행이 차세대 시스템을 위해 DB 테이블명을 CUSTOMER에서 CUS_MST로 바꾸는 순간, AI Agent는 먹통이 됩니다. 이것은 '민첩성'을 저해하는 최악의 아키텍처입니다.

 

해결책: '엄격한 은행 창구'로서의 API 게이트웨이

이 모든 재앙의 해결책은 간단합니다. AI Agent는 '마스터키'를 받는 것이 아니라, **'엄격한 은행 창구(API 게이트웨이)'**에 다른 고객들처럼 줄을 서야 합니다.
 

 
AI Agent는 '은행 창구'인 **API 게이트웨이(API Gateway)**를 통해 다음과 같은 프로세스를 거칩니다.

  1. [요청] AI Agent가 창구(API-GW)에 **'업무 요청서(API Request)'**를 제출합니다. (예: "A 고객의 잔액 조회 요청")
  2. [인증] 은행원(API-GW)은 AI의 **'신분증(원칙 1, Token/Key)'**을 확인합니다.
  3. [인가] 은행원(API-GW)은 이 AI가 **'잔액 조회' 업무 권한(원칙 1, Scope)**이 있는지 확인합니다.
  4. [감사] 은행원(API-GW)은 이 요청을 **'감사 장부(원칙 1, Log)'**에 기록합니다.
  5. [실행] 은행원(API-GW)이 '직접' 금고(백엔드 MSA/DB)에 가서, **'허용된' 데이터(잔액)**만 가져옵니다.
  6. [응답] AI에게 최종 결과("10,000원")만 전달합니다.

이 구조에서 AI Agent는 금고의 위치나 구조(DB 스키마)를 전혀 알 필요가 없습니다.
 

API 게이트웨이가 제공하는 4가지 핵심 '안전장치'

API 게이트웨이는 '은행 창구'로서 다음과 같은 4가지 기술적인 '안전장치'를 제공합니다.

1. 중앙화된 인증/인가 (The Bouncer)

'원칙 1'에서 정의한 AI의 '신원'과 '권한'을 게이트웨이에서 일괄 검증합니다.
[소스코드 예시: Kong/APIM 게이트웨이의 YAML 설정 (개념)]
YAML
# "이 YAML 설정 하나로 '여신 심사 AI'는 '읽기'만 가능하고
# '마케팅 AI'는 이 API에 접근조차 못하게 막았습니다."
 
- name: /api/v1/customer-credit
  plugins:
  # 1. 신원 인증 (사원증 검사)
  - name: jwt 
    config:
      issuer: finaitech-iam
  # 2. 권한 검사 (업무 분장표)
  - name: rbac
    config:
      roles:
        - "loan-reviewer-agent" # 이 Role만 허용

 

2. 트래픽 통제 및 시스템 보호 (The Traffic Cop)

'재앙 2(Rogue AI)'를 막는 핵심 기능입니다. AI가 폭주하더라도 백엔드 핵심 시스템을 보호합니다.
[소스코드 예시: Rate Limiting 플러그인 (개념)]
YAML
# "이 설정으로 AI Agent가 폭주하더라도,
# 백엔드 코어뱅킹 시스템은 초당 100개의 요청만 받아 안전합니다."
 
- name: global-rate-limit-for-ai
  plugins:
  - name: rate-limiting
    config:
      policy: local
      second: 100 # AI Agent 그룹은 초당 100개 요청만 허용

 

3. 중앙화된 감사 로깅 (The Scribe)

'재앙 3(감사)'를 해결합니다. 모든 AI의 요청과 시스템의 응답을 게이트웨이에서 한곳으로 모아 로그를 전송합니다. "누가, 언제, 무엇을 요청했고, 무엇을 응답받았는지" 100% 추적 가능합니다.

 

4. 백엔드 추상화 및 분리 (The Translator)

'재앙 4(종속)'를 해결합니다. AI는 오직 POST /api/v2/loan이라는 API 주소만 압니다. 나중에 백엔드의 코어뱅킹이 메인프레임에서 K8s MSA로 바뀌더라도, 게이트웨이가 이 API를 유지해주는 한 AI 코드는 단 한 줄도 수정할 필요가 없습니다.
 

결론

API 게이트웨이는 단순한 '관문'이 아닙니다.
AI 시대에 **'원칙 1(통제)'**을 구현하는 **'기술적인 집행자(Technical Enforcer)'**이자, AI의 '폭주'로부터 핵심 시스템을 보호하는 **'안전장치(Safety Mechanism)'**이며, AI와 백엔드 시스템이 서로 자유롭게 진화할 수 있도록 돕는 **'번역가(Translator)'**입니다. AI Agent에게 '마스터키'가 아닌, 잘 설계된 '은행 창구(API 게이트웨이)'를 제공하는 것이 차세대 금융 아키텍처의 두 번째 원칙입니다.
 
다음 글에서는 AI의 '명령(Request)'이 아닌, 시스템이 AI에게 실시간으로 '알림(Event)'을 주는 아키텍처에 대해 이야기해 보겠습니다. "[Finaitech 5대 원칙 3/5] 실시간 데이터는 이벤트 기반 아키텍처를 고려하라" 편으로 찾아뵙겠습니다.