Bumblebee를 만나보세요: Agentic AI가 90초 이내에 위험한 상인들을 표시

Source: Dev.to

만약 결제 회사를 잘 알고 있다면, 그 흐름을 알게 될 것입니다. 위험 담당자들은 매달 수천 개의 가맹점 웹사이트를 수동으로 검토하면서 빨간 깃발을 찾습니다: 수상한 개인정보 보호정책, 맞지 않는 가격 정책, 의심스러운 소셜 미디어 존재, 의심스러운 도메인 등록 패턴 등.

Razorpay에서는 위험 운영 팀이 매달 10,00012,000개의 웹사이트를 수동으로 검토했으며, 각 검토는 대략 4분 정도의 인간 주의를 필요로 했습니다. 이는 매달 700800시간의 인간 작업 시간이 소모된다는 의미이며, 서로 다른 담당자들이 같은 신호를 다르게 해석하기 때문에 품질이 일관되지 않았습니다.

전통적인 사기 탐지 접근 방식은 인력을 투입하거나 사기꾼이 전술을 바꾸는 순간 깨지는 경직된 규칙 엔진을 구축하는 것이었습니다. 우리는 거래량에 맞춰 확장하면서 시간이 지날수록 실제로 더 똑똑해질 수 있는 무언가가 필요했습니다.

그래서 우리는 Agentic Risk라 부르는 다중‑에이전트 AI 시스템을 구축했습니다. 이 시스템은 인간 전문 지식이 필요했던 섬세한 판단을 유지하면서 가맹점 웹사이트 평가를 처음부터 끝까지 자동화합니다.

초기 n8n 프로토타입에서 AI 에이전트, 그리고 현재의 다중‑에이전트 아키텍처에 이르기까지의 여정은 대규모로 신뢰할 수 있는 AI 시스템을 구축하는 데 있어 근본적인 진실을 보여줍니다.

The Business Problem: When Manual Review Can’t Keep Up

자동화 이전에 위험 운영이 어떻게 이루어졌는지 그림을 그려보겠습니다. 새로운 가맹점이 Razorpay에 가입하거나 기존 가맹점이 사기 탐지 시스템에 의해 플래그가 되면, 케이스가 우리 Risk Case Manager 시스템에 들어갑니다. 인간 담당자가 그 케이스를 잡고 조사 과정을 시작합니다.

이 과정은 모든 것이 순조롭게 진행될 때 4분이 걸리지만, 실제로는 드물죠. 웹사이트는 구조가 다르고, 정책 페이지는 이상한 곳에 숨겨져 있으며, 도메인 정보 서비스마다 인터페이스가 다르고, 소셜 미디어 핸들이 항상 명확하지도 않습니다. 가장 큰 문제는 시간이 아니라 일관성 부족입니다. 한 담당자는 일반적인 개인정보 보호정책 때문에 가맹점을 플래그하지만, 다른 담당자는 같은 정책을 허용 가능한 것으로 판단합니다.

우리는 또한 매달 수천 달러를 제3자 명시적 콘텐츠 스크리닝 서비스에 지불했으며, 이 서비스는 월 50건 정도의 알림을 생성했지만 정확도는 10 % 미만이었습니다. 게다가 이 서비스는 우리가 관심을 두는 수십 가지 다른 사기 지표를 무시하고 한 종류의 위험만을 포착했습니다.

근본적인 문제는 관측 가능성 도구, 구조화된 데이터 시스템, 경험 많은 위험 분석가들은 있었지만, 이 모든 구성 요소를 연결하는 조직이 인간 노동이라는 점이었습니다. 규모를 키우려면 더 많은 담당자를 고용해야 했고, 이는 일관성 감소, 비용 상승, 탐지 속도·정확도 향상 없음으로 이어졌습니다.

Phase 1: The n8n Prototype - When Visual Orchestration Hits Its Limits

우리는 n8n이라는 시각적 워크플로 자동화 플랫폼을 사용해 가설을 빠르게 프로토타이핑하고 검증했습니다. 몇 주 만에 웹훅 수신, 가맹점 메타데이터 가져오기, 멀티모달 AI를 통한 웹사이트 콘텐츠 검토, 도메인 조회, GST 보강, 사기 메트릭, LLM 기반 위험 분석을 통합한 작업 증명을 만들었습니다.

프로토타입은 자동화가 가능함을 입증했고, 필요한 전체 데이터 포인트를 파악하는 데 도움을 주었습니다. 하지만 n8n은 곧 근본적인 한계를 드러냈습니다:

• Branch explosion – 엣지 케이스를 처리하면서 중복 로직이 있는 40노드 워크플로가 유지보수 불가능해졌습니다.
• Observability gaps – 거친 로그만으로 실패한 노드를 디버깅하는 것이 고통스러웠습니다.
• Platform instability – HTTP와 merge 작업에서 비결정적 동작이 발생했습니다.

n8n 프로토타입을 통해 우리는 프로덕션 급 위험 자동화가 적절한 관측 가능성과 Python 라이브러리를 직접 사용할 수 있는 코드‑first 접근 방식을 필요로 한다는 것을 배웠습니다.

Phase 2: Python + ReAct Agent - Better Control, New Bottlenecks

우리는 API 프론트엔드와 작업 워커를 갖춘 Python 웹 애플리케이션으로 재구성했습니다. 이는 즉시 Phase 1의 여러 문제를 해결했습니다: 네이티브 Python 라이브러리, trace ID가 포함된 구조화 로그, 재시도 로직이 있는 적절한 예외 처리, 복잡한 NLP 전처리 기능 등.

핵심은 ReAct‑style 에이전트 하나였으며, 이 에이전트는 어떤 도구를 호출할지 반복적으로 판단하고 실행한 뒤 결과를 통합해 구조화된 위험 평가를 생성했습니다. Phase 2는 완전한 관측 가능성, 쉬운 도구 추가, 그리고 부서진 조건 로직을 대체하는 동적 행동을 제공했습니다.

하지만 새로운 병목 현상이 나타났습니다:

• Token bloat – 에이전트가 50 KB 이상의 HTML 콘텐츠, 도메인 데이터, 사기 메트릭을 컨텍스트 창에 축적하면서 토큰 한도에 자주 도달했습니다.
• Sequential execution – 도구 호출이 서로 의존성이 없더라도 순차적으로 진행돼 도구 수에 비례해 선형적으로 확장되었습니다.
• Temperature conflation – 탐색(도구 선택)과 활용(최종 점수) 모두에 동일한 temperature 설정을 사용하면 최적이 아니었습니다.

Phase 2는 에이전트 기반 오케스트레이션이 옳다는 것을 증명했지만, 단일‑에이전트 아키텍처는 수천 개의 동시 평가를 감당할 수 없었습니다.

Phase 3: Multi‑Agent Architecture - When Specialization Wins

우리는 사기 탐지를 하나의 AI 작업으로 보던 방식을 버리고 다중‑에이전트 협업 시스템을 구축하면서 돌파구를 찾았습니다. 하나의 에이전트가 모든 일을 하는 대신, 우리는 Planner, Fetchers, Analyzer와 같이 특정 역할에 최적화된 전문 에이전트들로 책임을 분산했습니다.

Planner Agent는 가맹점 케이스를 받아 사용 가능한 도구를 검토하고 시스템 상태와 API 할당량을 확인한 뒤 실행 계획을 생성합니다. 이는 고정된 스크립트가 아니라, 어떤 정보를 수집할지, 우선순위, 타임아웃, 토큰 예산, 기대 스키마 등을 명시한 구조화된 사양입니다. Planner는 비즈니스 규칙을 결정적으로 적용합니다(예: 인도 외 가맹점은 GST 검증을 건너뛰고, B2B 가맹점은 소셜 미디어 검사를 낮은 우선순위로 둠). 이를 통해 불필요한 API 호출을 줄이고 고신호 검증에 자원을 집중할 수 있습니다.

Data Fetcher Agents는 병렬로 실행되며, 각각 하나의 데이터 소스 또는 도구(웹사이트 스크래핑, WHOIS 조회, 사기 데이터베이스 쿼리, 소셜 미디어 메트릭, 가격 비교, 정책 검증)를 담당합니다. 특히, fetcher들은 local data pruning을 수행해 결과를 반환하기 전에 토큰 사용량을 최소화합니다. 이렇게 하면 다운스트림 Analyzer가 원시 데이터를 다루는 대신 종합에 집중할 수 있습니다.