[Finaitech 5대 원칙 4/5] 분산 데이터를 하나의 통합 뷰로 제공하라.

지난 [원칙 2]와 [원칙 3]에서, 우리는 AI Agent가 데이터를 '요청(Pull)'하는 API 게이트웨이와 데이터를 '수신(Push)'하는 **EDA(이벤트 기반 아키텍처)**를 이야기했습니다. 이제 우리의 AI는 시스템의 데이터에 '접근'할 수 있게 되었습니다.
 
하지만 바로 여기서, 우리는 더 복잡하고 근본적인 문제에 부딪힙니다.
 
AI가 '초개인화된 맞춤형 홈'을 고객에게 제공해야 한다고 상상해 봅시다. 이 AI는 다음 정보를 '하나로 합쳐서' 봐야 합니다.

1. [계정계 DB] 고객의 현재 잔액
2. [AWS] 지갑의 포인트 잔액
3. [로그 서버] 고객의 최근 앱 접속 시간
4. [EDA Stream] 방금 발생한 '카드 결제' 이벤트

AI Agent가 이 모든 시스템의 IP 주소, ID/PW, DB 스키마, API 명세를 전부 알고 있어야 할까요?
 

최악의 안티-패턴: '모든 것을 아는(Know-it-All)' AI Agent

만약 '원칙 4'가 없다면, AI Agent의 코드는 다음과 같은 **'데이터 통합 스파게티 코드'**가 될 것입니다.
[소스코드 예시: AI Agent의 스파게티 코드 (개념적 Python)]
Python
# 최악의 안티-패턴 예시
def get_customer_profile(customer_id):
    
    # 1. 계정계 DB에 SQL로 직접 연결 (P2 위반!)
    balance = oracle_db.query(f"SELECT BAL FROM ACCT WHERE CUST_ID='{customer_id}'") 
    
    # 2. 지갑 API 호출 (P2 준수... 하지만 Agent가 직접?)
    points = requests.get(f"https://aws.kbstar.com/api/wallet/{customer_id}").json()
    
    # 3. 로그 서버에 Mongo 쿼리 (P2 위반!)
    recent_login = mongo_db.query(f"{{'cust_id': '{customer_id}'}}").sort('time', -1).limit(1)
    
    # 4. (가장 복잡) 이 모든 데이터를 AI Agent 메모리에서 직접 Join
    profile = join(balance, points, recent_login) 
    return profile
 
이 아키텍처는 끔찍한 재앙을 초래합니다.

1. 극심한 복잡성/취약성: AI가 '데이터 통합 전문가'가 되어버립니다. 만약 계정계 DB팀이 CUST_ID 컬럼명을 CI_NO로 바꾸는 순간, AI Agent는 먹통이 됩니다.
2. 성능 저하: AI Agent가 5개의 서로 다른 시스템을 순차적으로 호출하고, 이 모든 데이터를 자신의 메모리 위에서 조인(Join)해야 합니다. 이는 매우 느리고 비효율적입니다.
3. 보안/거버넌스 재앙: AI Agent가 모든 핵심 DB의 '접근 자격증명(Credential)'을 가지게 됩니다. 이는 **'원칙 1(통제)'**과 **'원칙 2(API-GW)'**를 정면으로 위배합니다.

 

해결책: AI를 위한 '준비된 팬트리(Pantry)'

AI Agent는 "최고급 요리사(Chef)"입니다. 우리는 요리사에게 농장(계정계 DB), 바다(로그 서버), 시장(AWS)에 직접 가서 재료를 구해오라고 시키지 않습니다.
아키텍트인 우리의 역할은, 이 모든 재료가 완벽하게 손질되어 준비된 **"준비된 팬트리(Prepared Pantry)"**를 제공하는 것입니다. 이 '팬트리'가 바로 **'하나의 통합된 뷰(A single, unified view)'**입니다.
AI 요리사는 이 '팬트리'에 "고객 프로필 1인분 줘" (GET /unified-view/customer_profile/123) 라고 단 한 번만 요청하면 됩니다.
 

'통합 뷰'를 구현하는 2가지 핵심 전략

이 '팬트리'를 구축하는 대표적인 아키텍처 전략은 두 가지입니다.
[도식화: 데이터 가상화(왼쪽)와 데이터 메시(오른쪽) 개념 비교]

전략 1: 데이터 가상화 (Data Virtualization) - "만능 통역기"

• 작동 방식: Trino(Presto)나 Denodo 같은 '가상화 엔진'을 모든 DB/API 위에 배치합니다. AI는 이 엔진에 표준 SQL로 "고객 프로필 줘"라고 쿼리합니다.
• 엔진이 '만능 통역기'처럼 AI의 쿼리를 받아, (1) Oracle, (2) MongoDB, (3) API를 대신 호출하고, 결과를 합쳐서 AI에게 돌려줍니다.
• 장점: AI 입장에서는 모든 데이터가 '하나의 거대한 SQL DB'처럼 보여 매우 편리합니다.
• 단점: 실시간성이 떨어질 수 있고, 이 '통역기 엔진'이 새로운 병목 지점(Bottleneck)이 될 수 있습니다.

전략 2: 데이터 메시 (Data Mesh) - "데이터를 상품(Product)으로"

• 작동 방식: 기술이 아닌, **'조직/문화'**의 전환입니다. 중앙에서 통합하는 대신, 각 데이터를 소유한 '현업팀(도메인팀)'이 자신의 데이터를 직접 '상품'으로 만들어 제공합니다.
• 장점: 데이터 품질과 소유권이 명확해지고(Data as a Product), 확장성이 뛰어납니다. (PM님의 Context.dev 철학과도 일치합니다.)
• 단점: 은행 같은 전통 조직에서 구현하기까지 엄청난 문화적 변화와 시간이 필요합니다.

[finaitech의 제안] 금융권의 현실적인 접근은 **'하이브리드'**입니다. (1) 데이터 가상화로 레거시 시스템에 대한 빠른 승리(Quick-Win)를 달성하고, (2) 데이터 메시를 장기적인 전략으로 삼아 '계좌', '상품' 등 핵심 도메인부터 '데이터 상품'으로 만들어 나가야 합니다.
 

시나리오: '초개인화 홈'은 이렇게 완성된다

'원칙 4'가 적용된 아키텍처에서 AI Agent는 다음과 같이 작동합니다.

1. AI Agent는 GET /unified-view/customer_profile/KB-Pin-12345 라는 단 하나의 API만 호출합니다. (원칙 2 준수)
2. '통합 뷰(가상화 엔진 또는 메시 레이어)'가 이 요청을 받아,
3. 이 모든 것을 **'하나의 JSON'**으로 조합하여 AI Agent에게 전달합니다.

이제 AI Agent는 '데이터 통합'이라는 지저분한 일이 아닌, "이 고객에게 지금 무엇을 제안할까?"라는 **'본질적인 추론'**에만 집중할 수 있습니다.
 

결론: AI의 '뇌'가 완성되다

'원칙 1(통제)'이라는 윤리 안에서, '원칙 2(API)'와 '원칙 3(EDA)'로 데이터를 '접근'하고, '원칙 4(통합 뷰)'로 데이터를 '이해'하게 되었습니다.
 
이제 AI의 '뇌'와 '신경망'은 모두 설계되었습니다.
 
하지만 이 완벽한 뇌와 신경망은 어디에 두어야 할까요? 어떻게 이 AI가 24시간 365일 잠들지 않고, 수천만 명의 요청에도 끄떡없이 작동하도록 만들 수 있을까요?
 
이것이 바로 'finaitech'의 마지막 원칙이자, 이 모든 것을 떠받치는 가장 거대한 기반입니다.
 
"[Finaitech 5대 원칙 5/5] 견고하고 탄력적인 플랫폼은 이제 기본이다" 편으로 찾아뵙겠습니다.