[Finaitech 5대 원칙 3/5] 실시간 데이터는 이벤트 기반 아키텍처를 고려하라.
지난 [원칙 2]에서 우리는 AI Agent가 '명령'하거나 '조회'할 때 API 게이트웨이라는 '은행 창구'를 이용해야 한다고 말했습니다. 이것은 AI가 '능동적으로(Actively)' 데이터를 가져오는(Pull) 방식입니다.
여기서 한 가지 중요한 질문이 생깁니다.
AI가 요청하지 않은, "지금 이 순간" 시스템에서 발생한 일을 AI는 어떻게 알 수 있을까요? 예를 들어, '고객이 방금 이체를 완료'했다는 사실이나 '이상한 로그인 시도'가 발생했다는 것을 AI가 어떻게 즉시 인지할 수 있을까요?
최악의 안티-패턴: 'AI의 폴링 지옥(Polling Hell)'
만약 우리에게 '원칙 2(API 게이트웨이)'만 있다면, AI가 실시간 데이터를 얻는 유일한 방법은 1초에 한 번씩 API 게이트웨이를 **'폴링(Polling)'**하는 것뿐입니다.
- AI Agent 1 (FDS): "혹시 이상한 거래 있었어? (1초 뒤) 지금은? (1초 뒤) 지금은?"
- AI Agent 2 (마케팅): "혹시 고객이 로그인했어? (1초 뒤) 지금은? (1초 뒤) 지금은?"
이 '폴링 지옥'은 상상만 해도 끔찍한 재앙을 초래합니다.
- 시스템 부하: 수천 개의 AI Agent가 수천 개의 API를 1초마다 폴링하면, API 게이트웨이와 백엔드 시스템은 대부분 '변화 없음'이라는 응답을 처리하느라 자원을 낭비하고 결국 마비될 것입니다.
- '진짜 실시간'이 아님: 1초의 폴링 간격(Interval) 사이에 발생하는 이벤트는 즉시 감지할 수 없습니다.
- 복잡성: 새로운 '실시간' 요구사항이 생길 때마다 이 복잡한 폴링 로직을 또 개발해야 합니다.
해결책: AI의 '실시간 신경망(EDA)'
이 '폴링 지옥'의 완벽한 해결책이 바로 **'이벤트 기반 아키텍처(Event-Driven Architecture, EDA)'**입니다.
AI Agent가 스스로 데이터를 가지러 가는(Pull) 것이 아니라, 이벤트가 발생하면 시스템이 AI에게 데이터를 '밀어주는(Push)' 방식입니다. 이는 AI에게 **'실시간 신경망'**을 이식하는 것과 같습니다.
[도식화: EDA의 Publish/Subscribe(발행/구독) 모델]
이 신경망은 3가지 요소로 작동합니다.
- 신경 말단 (Producer/Publisher):
- 척수 (Event Broker - e.g., Kafka):
- 뇌 (Consumer/Subscriber):
금융 시나리오: EDA가 AI를 '선제적'으로 만드는 법
그렇다면 이 '신경망'으로 우리는 무엇을 할 수 있을까요?
시나리오 1: AI FDS (이상거래탐지)
- (As-Is - Batch) 밤 12시 배치 작업으로 "어제 발생한" 사기 거래를 찾아냅니다. (이미 늦었습니다.)
- (To-Be - EDA)
시나리오 2: 초개인화 마케팅 (AI 컨텍스트 엔진)
- (As-Is - API Pull) 고객이 '상품' 메뉴를 눌러야만(Pull), AI가 API를 호출해 상품을 추천합니다.
- (To-Be - EDA Push)
결론
AI 시대의 아키텍처는 하나만 선택하는 것이 아닙니다.
**API 게이트웨이(원칙 2)**가 AI의 '명령(Command)'을 처리하는 **'팔다리'**라면, **EDA(원칙 3)**는 AI의 '인지(Perception)'를 담당하는 **'실시간 신경망'**입니다.
성숙한 AI 아키텍처는 이 둘을 모두 사용합니다. (예: AI가 EDA로 '이벤트'를 인지한 뒤, API-GW를 통해 '명령'을 실행합니다.)
이제 우리는 API(P2)로 데이터를 '가져오고', EDA(P3)로 데이터를 '받을' 수 있게 되었습니다. 하지만 AI가 '이체 내역(Core DB)'과 '로그인 내역(Event Stream)'과 '국민지갑(AWS)'의 데이터를 어떻게 하나로 합쳐서(Combine) 볼 수 있을까요?
이것이 바로 'finaitech'의 네 번째 원칙입니다.
"[Finaitech 5대 원칙 4/5] 분산 데이터를 하나의 통합 뷰로 제공하라" 편으로 찾아뵙겠습니다.