AI 에이전트 이상거래 탐지: 이벤트 소싱 시스템에 에이전트를 붙이는 실전 아키텍처

핵심 메시지

• AI 에이전트의 진짜 가치는 챗봇이나 코딩 보조가 아니라, 회사가 수년간 투자해 온 기존 업무 워크플로에 붙일 때 나온다.
• 규칙 기반·머신러닝 엔진은 대부분의 거래를 잘 처리하지만, 임계값 사이의 '회색지대'에서는 결론을 내리지 못한다. 이 구간만 에이전트에게 넘긴다.
• 기존 시스템을 걷어내지 않고 1차 계층(규칙·ML)과 2차 계층(에이전트)을 나눠 두는 것이 핵심 설계 원칙이다.
• 분리된 바운디드 컨텍스트에 흩어진 데이터를 이벤트 소싱과 변경 데이터 캡처로 모아 '의미 계층'을 만들어야 에이전트가 판단할 맥락이 생긴다.
• 에이전트 두 개를 동시에 돌리고 세 번째 에이전트가 두 결론을 종합해 최종 판정을 내리는 구조로 오탐을 줄였다.

쉽게 이해하기

발표자는 자신이 겪은 결제 거절 경험으로 이야기를 시작한다. 3,500달러짜리 노트북을 사려다 두 번 연속 거래가 막혔고, 고객센터에 왜 막혔는지 물었지만 상담원도 답을 알지 못했다. 판단은 시스템 안쪽의 규칙 엔진이나 머신러닝 모델이 내렸고, 거래 이력이나 평균 임계값 같은 정적인 기준이 작동했을 뿐이었다.

5년 전에는 정적 규칙만으로도 충분했지만, 침입 수법이 계속 바뀌니 규칙을 매일 갱신해야 하는 유지보수 부담이 커졌다. 그래서 외부 업체와 함께 거래 이력과 특성값으로 머신러닝 모델을 학습시켜 위험 점수를 받는 방식으로 옮겨갔다. 그래도 남는 문제는 같았다. 임계값 아래는 승인, 위는 차단으로 정리되지만 그 사이의 회색지대에서는 정상 거래인지 사기인지 판정이 어렵다.

여기서 발표자는 '비결정적인 AI 에이전트를 왜 불확실한 영역에 넣느냐'는 반문을 스스로 꺼낸다. 그의 답은 기존 엔진에 맥락과 실시간 데이터가 부족했다는 것이다. 회사 도메인 곳곳에 흩어진 데이터를 끌어모아 주면 에이전트가 판단할 근거가 생긴다는 논리다. 그래서 1차 계층은 그대로 두고, 회색지대만 처리하는 2차 에이전트 계층을 덧붙였다.

문제는 아키텍처였다. 거래 컨텍스트는 가맹점과 금액만 알고 고객 정보나 기기 정보는 모른다. 계정 컨텍스트가 신원 확인 상태를, 기기 컨텍스트가 기기·브라우저 지문과 운영체제를, 결제 컨텍스트가 지불 거절 이력을 각각 들고 있다. 바운디드 컨텍스트끼리는 데이터를 직접 공유하지 않고 비동기로만 통신하기 때문에, 에이전트가 볼 통합된 그림이 애초에 존재하지 않았다.

해결책은 이벤트를 한곳으로 모으는 것이었다. 거래는 상태를 덮어쓰지 않고 사실(이벤트)을 계속 덧붙이는 이벤트 소싱 방식으로 NoSQL 이벤트 저장소에 쌓이고, 변경 피드(CDC)나 메시지 브로커를 통해 워커 프로세스로 흘러 프로젝션 계층에 반영된다. 이렇게 만든 구체화 뷰가 곧 에이전트가 조회하는 의미 계층이다. 오케스트레이션 계층은 사가 패턴처럼 흐름을 조율하고, 그 안에서 위험 분석 에이전트와 행동 분석 에이전트에게 팬아웃으로 일을 뿌린다.

주요 인사이트

• 에이전트를 얹을 자리를 고를 때 '전부'가 아니라 '기존 시스템이 결론을 못 내는 구간'으로 좁힌 점이 실용적이다. 잘 돌아가는 규칙과 모델을 유지하면서 위험 구간만 보강하는 방식이라 도입 위험이 작다.
• 발표자는 최종 판정을 단순 지표나 if 조건으로 처리했을 때 오탐이 많았다고 말한다. 그래서 두 에이전트의 응답을 함께 읽는 세 번째 에이전트를 판정 계층에 넣었는데, 이는 규칙으로 돌아가지 않으려는 선택이었다.
• 거래는 500밀리초 안에 끝내야 한다는 서비스 수준 약속이 있어 장기 기억을 쓸 수 없었고, 인메모리 단기 기억만 사용했다. 실시간 업무에 에이전트를 넣을 때 응답 시간이 메모리 설계를 결정한다는 뜻이다.
• 에이전트는 목표에 도달했는지 확인하며 작업을 쪼개고 반복하는데, 언제 멈출지 기준이 없으면 무한 루프에 빠진다. 발표자는 자기 사례에 맞는 정량 기준을 두고 루프를 끊는다고 밝혔다.
• 에이전트의 언어 모델이 반드시 대형 모델일 필요는 없다는 점도 강조된다. 소형 모델이나 오픈소스 모델로도 충분하며, 중요한 것은 도구와 맥락이 제대로 갖춰졌는지다.

자주 묻는 질문

관련 AI 소식