Let's integrate AI Agents in Event-Sourced Systems — Divakar Kumar, FlyersSoft

URL: https://www.youtube.com/watch?v=o6U_2vd967Y 날짜: 2026-07-30 채널: AI Engineer (AI Engineer 컨퍼런스, 발표자 Divakar Kumar, FlyersSoft)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

기존 규칙 기반(rule-based) 엔진이나 ML 모델이 이미 돌아가고 있는 이벤트 소싱(event-sourced) 시스템에 ==AI 에이전트를 어떻게 얹어서, 기존 시스템을 대체하지 않고 "회색 지대(gray zone)"만 보완할 수 있는가==가 이 발표의 핵심 논점이다. 발표자는 실시간 사기 탐지(real-time fraud detection)를 구체적 도메인으로 삼아, bounded context 기반 아키텍처 위에 프로젝션 레이어와 시맨틱 레이어를 쌓고 그 위에 멀티 에이전트(fan-out 패턴)를 붙이는 구조를 제시한다.

• AI 에이전트의 진짜 가치는 챗봇이나 코딩 어시스턴트가 아니라 비즈니스 워크플로우에 적용될 때 나온다
• 규칙 기반 엔진과 ML 기반 엔진 모두 "명확한 경계 아래/위" 케이스는 잘 처리하지만, 그 사이의 회색 지대 거래는 여전히 불확실하게 남는다
• AI 에이전트가 비결정적(non-deterministic)이라는 우려에도 불구하고, 기존 시스템이 놓치던 실시간 컨텍스트/도메인 데이터를 충분히 공급하면 에이전트가 더 나은 판단을 내릴 수 있다

발표자는 이 문제를 5년 전부터 운영해온 규칙 기반 엔진 → 서드파티와 협업한 ML 모델 → 최근 도입한 tier1(규칙+ML)/tier2(에이전틱 AI) 이중 구조로 발전시켜온 실제 경험을 공유하며, 이벤트 소싱·CDC·프로젝션·시맨틱 레이어를 어떻게 연결해 에이전트에게 컨텍스트를 공급하는지 실제 POC 데모와 함께 설명한다.

---

1. 문제 정의: 기존 사기 탐지 시스템의 한계

기존 규칙 기반/ML 기반 엔진은 명확한 케이스는 잘 처리하지만, 애매한 "회색 지대" 거래에서 반복적으로 오탐(false positive)을 낸다.

1.1. 발표자의 개인 경험 사례

1. $3,500 노트북 구매 거절 사건

   1. 상황: 발표 한 달 전, 발표자가 발표용으로 쓰는 노트북을 $3,500에 구매하려 했으나 카드 결제가 거절됨
   2. 재시도 실패: 네트워크 문제로 생각해 재시도했지만 두 번째 시도도 실패
   3. 고객센터 확인: 세 번째 시도 전 카드사에서 본인 확인 전화가 옴. 본인이 맞다고 답했지만, 왜 거래가 차단됐는지 고객센터 상담원조차 이유를 몰랐음

2. 차단 이유가 불명확했던 근본 원인

   1. 블랙박스 판단: 규칙 기반 엔진이든 ML 기반 엔진이든 거래 이력이나 평균 임계값(average threshold)을 기준으로 판단했을 뿐, 그 근거가 사람에게 설명되지 않음
   2. 정적 규칙의 한계: 임계값을 넘으면 무조건 차단하는 정적 규칙(static rule) 방식이었기 때문에 발생한 오탐

1.2. 규칙 기반 엔진과 ML 기반 엔진 각각의 한계

1. 규칙 기반 엔진 (5년 전부터 운영)

   1. 초기엔 효과적: 여러 케이스에서 잘 작동했음
   2. 유지보수 문제: 사기범들이 계속 새로운 방식으로 시스템에 침투를 시도하기 때문에, 정적 규칙을 매일 업데이트해야 하고 이는 장기적으로 관리가 매우 어려워짐

2. ML 기반 엔진 (서드파티와 협업 도입)

   1. 도입 배경: 규칙 기반의 한계를 극복하기 위해 서드파티 제공업체와 협력해 ML 모델을 개발
   2. 작동 방식: 거래 이력과 여러 피처(feature)를 서드파티와 공유해 모델을 학습시키고, 이를 통해 위험 점수(risk score)를 산출해 승인/차단을 결정
   3. 여전한 한계: 임계값 아래/위 케이스는 잘 처리되지만, 대다수 거래 중 일부가 "회색 지대"에 속해 사기 여부를 확정하기 어려움

---

2. 시스템 아키텍처: Bounded Context와 이벤트 소싱

전체 도메인은 DDD(Domain-Driven Design) 원칙에 따라 여러 bounded context로 분리되어 있고, 이 사이의 데이터 공유 문제를 해결하기 위해 오케스트레이션 레이어와 이벤트 소싱 방식을 사용한다.

2.1. 4개의 Bounded Context 구조

1. Transaction Context

   1. 보유 정보: 거래 관련 모든 정보 — 가맹점(merchant), 거래 금액 등
   2. 정보 미보유 영역: 고객 정보, 결제 정보, 디바이스 정보는 알지 못함(다른 context의 책임)

2. Accounts Context

   1. 보유 정보: KYC(Know Your Customer) 준수 여부, 계좌 관련 고객 정보 전반

3. Device Context

   1. 보유 정보: 디바이스 핑거프린트, 브라우저 핑거프린트, 사용 OS 등
   2. 활용 가치: 실시간 사기 탐지에 특히 유용한 정보

4. Payment Context

   1. 보유 정보: 차지백(chargeback) 등 결제 관련 모든 정보

설계 원칙: 각 bounded context는 서로 데이터를 직접 공유하지 않으며, 마이크로서비스 통신에서와 마찬가지로 비동기 방식(asynchronous)으로 통신해야 한다.

2.2. 오케스트레이션 레이어와 이벤트 소싱 파이프라인

1. 오케스트레이션 레이어의 역할

   1. 사가(saga) 패턴 유사 구조: 모든 context 간 통신이 이 레이어를 거쳐 관련 서비스로 전달됨
   2. 에이전틱 AI 내장: 기존에도 오케스트레이션 레이어가 있었지만, 이제는 그 안에 에이전틱 AI가 추가로 내장됨
   3. 메시지 브로커 병행: context 간 비동기 통신은 별도의 메시지 브로커를 통해서도 이뤄짐

2. 이벤트 소싱(Event Sourcing) 메커니즘

   1. 도메인 이벤트: Transaction Context에서는 transaction created가 거래의 시작을 알리는 도메인 이벤트
   2. 통합 이벤트(integration events): transaction rejected, payment approved, payment rejected 등 다른 context에서 발생해 넘어오는 이벤트
   3. 저장소: 모든 이벤트는 NoSQL 데이터베이스인 Cosmos DB에 이벤트 스토어로 저장됨
   4. append-only 원칙: 상태를 직접 변경(mutate)하지 않고, 사용자가 명령(command)을 실행할 때마다 비즈니스 팩트(business fact)로서 이벤트를 계속 추가(append)하는 방식

3. CDC(Change Feed)와 읽기 모델(Read Model)

   1. CDC 메커니즘: Cosmos DB의 change feed를 통해 테이블에 변경/업데이트가 발생하면 알림을 받고, 이 변경사항을 여러 읽기 모델로 전파(propagate)할 수 있음
   2. 읽기 전용 최적화 이유: 실제 조회(query)/읽기 연산을 이벤트 스토어에만 전적으로 의존할 수 없기 때문에, 읽기 연산에 최적화된 별도의 읽기 모델을 구성함
   3. 실제 구성한 3종 읽기 모델: 타임라인용(timeline), 고객 정보용(customer information), 사기 지표/리스크 뷰용(fraud indicators, risk view) 읽기 모델을 각각 운영
   4. 팀 간 일관성 문제: 이벤트 소싱은 모든 팀이 따르는 공통 패턴이 아니므로, 메시지 브로커로 이벤트를 발행하고 워커 프로세스(worker process)가 이를 처리해 프로젝션 레이어(projection layer)로 전달하는 비동기 방식도 함께 사용

4. 시맨틱 레이어(Semantic Layer) 구축의 필요성

   1. 목적: 여러 bounded context의 데이터를 모아 시맨틱 레이어(=materialized view)를 구축해야, 이후 AI 에이전트가 이를 활용할 수 있음
   2. 파이프라인: 각 context → (CDC 또는 메시지 브로커) → 워커 프로세스가 메시지를 가공(massage)·처리 → 프로젝션 레이어(materialized view)에 저장 → 에이전트가 활용

---

3. AI 에이전트 통합 방식

에이전트는 언어모델·툴·메모리 3요소로 구성되며, 기존 오케스트레이션 레이어 안에 tier1(기존 시스템)과 tier2(에이전틱 AI)로 계층을 나누어 fan-out 패턴으로 통합한다.

3.1. 에이전트의 3대 구성 요소

1. 언어 모델(Language Model)

   1. 모델 종류 무관: 반드시 대형 언어모델(LLM)일 필요는 없으며, sLM(소형 언어모델)이나 오픈소스 모델도 가능
   2. 추론·사고 능력: 쿼리가 들어오면 reasoning/thinking 능력으로 태스크를 여러 청크(chunk)로 분해하고, 각 태스크가 다시 언어모델과 툴을 거쳐 처리되며 목표 달성 여부를 계속 확인하는 루프를 돎

2. 툴(Tools)

   1. 정의: 외부 API나 애플리케이션 레이어 내부에 정의된 메서드와 상호작용하는 수단

3. 메모리(Memory)

   1. 단기 메모리 채택 이유: 이 사기 탐지 유스케이스에서는 장기 메모리에 의존할 수 없음 — 거래 처리는 500ms 이내(sub 500 milliseconds) SLA를 지켜야 하기 때문에 인메모리(in-memory) 방식의 단기 메모리를 사용
   2. 무한 루프 방지: reasoning 루프를 언제 멈출지가 중요하며, 유스케이스마다 다른 메트릭 기준(threshold)을 두어 루프에서 빠져나오도록 설계해야 함(무한 루프 방지 필수)

3.2. Tier1/Tier2 이중 계층과 Fan-out 패턴

1. 계층 분리 이유

   1. 기존 시스템 유지: 기존 규칙 기반/ML 기반 시스템(tier1)을 배제하지 않고, 대부분의 거래는 여전히 tier1이 잘 처리하도록 유지
   2. 회색 지대만 tier2로: 애매한 회색 지대 케이스만 tier2(에이전틱 AI 처리)로 넘김

2. Tier2 내부의 Fan-out 패턴

   1. 두 개의 병렬 에이전트: tier2 이벤트가 도달하면 리스크 분석 에이전트(risk analyzer agent)와 행동 분석 에이전트(behavior analyzer agent) 두 개로 fan-out
   2. 리스크 분석 에이전트의 툴: 시맨틱 레이어에 저장된 사기 이력(fraud history) 조회 툴, 디바이스 신뢰도(device trust) 레이어 조회 툴, 규칙 기반 엔진에서 마이그레이션한 비즈니스 규칙 툴을 보유
   3. 행동 분석 에이전트의 툴: 두 개의 서로 다른 플러그인으로 거래 패턴(transaction pattern)을 분석하는 행동 분석 툴을 보유

3. 세 번째 에이전트: Verdict(판정) 에이전트

   1. 도입 배경: 단순히 메트릭이나 if-조건문만으로 최종 판정을 내리면 결국 기존 규칙 기반 방식과 똑같은 문제(false positive 다수 발생)로 회귀함을 발견
   2. 역할: 리스크 분석 에이전트와 행동 분석 에이전트 두 응답을 모두 분석해 최종 합의(consensus)를 도출
   3. 결과 전파: 최종 판정은 다시 이벤트로 메시지 브로커에 발행되고, 이 사가(saga) 흐름을 통해 결제 컨텍스트(payment context)로 전달되어 결제 승인이 이뤄진 뒤 다시 트랜잭션 컨텍스트로 돌아옴 — 전 과정이 오케스트레이션 레이어 안에서 완결됨

---

4. 시맨틱 레이어와 컨텍스트 수집 방식

에이전트가 판단을 내리기 위해 필요한 컨텍스트는 프로젝션 레이어에서 각 bounded context가 비정규화(denormalize)한 데이터를 시맨틱 레이어로 보내는 방식으로 공급된다.

4.1. 컨텍스트별 제공 데이터

1. Transaction Context가 제공하는 데이터

   1. 비정규화 지표: 거래 건수(counts), 평균 금액(averages), 최근 거래 내역(recent transactions) 등을 비정규화해 시맨틱 레이어로 전달

2. Device Context가 제공하는 데이터

   1. 신뢰도·위치 정보: 디바이스 신뢰 점수(device trust score), 위치 이력(location histories), IP 주소 등 관련 정보 일체

3. Accounts Context가 제공하는 데이터

   1. 계좌 상태 정보: 계좌 상태(status), KYC 상태, 계좌 개설 연차(account age) — 고객이 얼마나 오래 서비스를 이용해왔는지 등을 통해 고객 검증에 활용

4. Payment Context가 제공하는 데이터

   1. 최근 결제 이력: 시맨틱 레이어에 수집된 최근 결제(recent payments) 정보

4.2. 아키텍처의 범용성

1. 이벤트 소스에 종속되지 않는 설계
   1. DB 무관: 관계형 데이터베이스든 NoSQL이든 어떤 이벤트 소스를 쓰든 무방
   2. 핵심은 시맨틱 레이어: 결국 AI 에이전트에게 충분한 컨텍스트를 제공하기 위한 시맨틱 레이어를 만드는 것이 핵심
   3. 최종 구성 요소: 오케스트레이션 안의 에이전틱 레이어는 verdict 툴과 단기 메모리를 가지며, 그 결과가 다시 사가 오케스트레이션으로 전달되는 구조로 마무리됨

---

5. POC 데모: 합성 데이터 기반 시뮬레이션

발표자는 합성 데이터(synthetic data)로 만든 POC를 라이브로 시연하며 전체 흐름을 보여준다.

5.1. 시뮬레이션 이벤트 흐름

1. 이벤트 시뮬레이션 시작

   1. 다중 컨텍스트 이벤트 발생: 트랜잭션, 계좌(accounts), 결제(payments) 컨텍스트에서 여러 시뮬레이션 이벤트가 동시에 발생
   2. CDC를 통한 전파: 이 이벤트들이 CDC 메커니즘을 통해 프로젝션 레이어를 거쳐 시맨틱 레이어로 전파됨

2. AI 에이전트 레이어의 처리

   1. Tier1 우선 처리: ML 기반 tier1 처리가 먼저 시도됨
   2. Tier2 fan-out 결과: 서로 다른 두 개의 에이전트(리스크 분석·행동 분석)가 각자 다른 결론을 내고, 세 번째 에이전트가 최종 판정을 내리는 과정을 시연(데모 중 서버리스 DB의 응답 지연으로 다소 느리게 진행됨)
   3. 최종 이벤트 발행: 최종 판정 결과가 다시 이벤트로 메시지 브로커에 발행되고, 사가 흐름이 비즈니스 아키텍처 설계에 따라 계속 이어짐

---

주요 발언 모음

"I always believe that these AI agents are more not just for the chatbots or the coding assistance, right? So, the real value that you could bring out of these AI agents is like when you start to apply these into your business workflows."

"They didn't know because I wouldn't blame them because they didn't know like why it was blocked. It was somewhere in the system, either the rule-based engine or the ML-based engine would have taken that decision."

"Majority of the transaction... goes under the gray zone area, and this is the area where it is really uncertain for those systems to really come to a conclusion whether it is a fraudulent transaction or a legitimate [one]."

"Our thought process is not to exclude the systems that we already had. We are just trying to handle few of the areas — that is the gray zone areas — with the help of agentic AI processing."

"You should really know like when to stop this loop... you should be really careful on avoiding this infinite loop."

"What we seen is like if we are using just the metrics, it is again going back to the same criteria like where we had this rule-based mechanism. There are many false positive cases that we faced. So we are trying to use a third agent in this verdict layer, which analyzes both the agents' responses and comes to a conclusion."

핵심 데이터 & 수치

• $3,500: 발표자가 발표 한 달 전 구매하려다 카드 결제가 거절당한 노트북(발표용 노트북) 가격 — 발표의 도입 사례
• 500ms(sub 500 milliseconds): 거래 처리에 요구되는 SLA 기준 — 이 때문에 장기 메모리 대신 인메모리 단기 메모리를 채택한 근거
• 규칙 기반 엔진 운영 기간 약 5년: 최초 도입한 사기 탐지 방식으로, 유지보수 부담이 누적되어 ML 모델 도입의 계기가 됨
• 에이전트 3개 구조: risk analyzer agent + behavior analyzer agent(병렬 fan-out) + verdict agent(최종 합의) — tier2 에이전틱 AI 계층의 핵심 구성
• 읽기 모델 3종: timeline / customer information / fraud indicators(risk view) — Transaction Context 내 프로젝션 레이어 구성
• Bounded Context 4개: Transaction / Accounts / Device / Payment
• 저장소: Cosmos DB(NoSQL)를 이벤트 스토어로 사용, CDC(change feed) 방식으로 프로젝션 레이어에 전파

결론 및 시사점

1. AI 에이전트는 기존 시스템의 대체재가 아니라 보완재로 설계하라: 이미 잘 작동하는 규칙 기반/ML 시스템을 걷어내지 말고, 판단이 불확실한 "회색 지대"에만 에이전틱 AI를 선택적으로 투입하는 tier1/tier2 이중 구조가 실용적이다.
2. 에이전트의 성능은 결국 컨텍스트 품질에 달려 있다: 비결정적이라는 우려보다 중요한 것은, 여러 bounded context에 흩어진 실시간 도메인 데이터를 얼마나 잘 모아 시맨틱 레이어(materialized view)로 제공하느냐이다.
3. 이벤트 소싱 + CDC + 프로젝션 레이어는 에이전트 컨텍스트 공급의 표준 파이프라인이 될 수 있다: 특정 DB나 이벤트 소스에 종속되지 않고, "각 context → CDC/메시지 브로커 → 워커 프로세스 → 프로젝션(시맨틱) 레이어 → 에이전트 툴"이라는 패턴은 다른 도메인에도 그대로 이식 가능하다.
4. 단일 에이전트의 판정을 그대로 신뢰하지 마라: 두 개 이상의 독립적인 관점(리스크 분석·행동 분석)으로 병렬 판단시킨 뒤, 별도의 verdict 에이전트가 이를 종합하는 구조가 단순 메트릭/if-조건문 방식보다 오탐(false positive)을 줄이는 데 효과적이었다.
5. 레이턴시 SLA가 있는 실시간 시스템에서는 장기 메모리 대신 인메모리 단기 메모리와 명확한 루프 종료 조건(threshold)을 설계해야 한다: 500ms 이내 응답이 필요한 도메인에서는 reasoning 루프의 무한 반복을 막는 것이 안정성의 핵심이다.