Stripe Radar는 자신이 하는 일에 탁월합니다. 바로 돈이 움직이는 순간 거래를 평가하는 일이죠. 하지만 우리의 문제는 정확히 돈이 움직이지 않는 순간에 있었습니다.
우리는 7일 무료 체험을 운영합니다. 체험을 시작하려면 사용자가 카드를 등록하지만 요금이 청구되지는 않습니다. 내부적으로 보면 이는 결제가 아니라 Stripe의 SetupIntent입니다. 청구가 없다는 것은 청구 시점 이벤트가 없다는 뜻이고, 결국 Radar의 가장 강력한 규칙들은 가장 중요한 순간, 즉 사기 계정이 생성되어 체험 크레딧을 소진하기 시작하는 바로 그 순간에 평가할 대상이 아무것도 없게 됩니다.
이 글은 우리가 일회성 대화에서 사기를 진화하던 방식에서 벗어나, 우리 자체 제품인 Zero 위에 분 단위로 작동하는 자동화된 사기 방어 계층을 구축하기까지의 이야기입니다.
Radar는 훌륭합니다. 다만 "훌륭함"이 "완벽함"은 아닙니다.
Stripe Radar는 정말로 일을 잘합니다. 연간 1조 달러가 넘는 결제 규모로 학습된 이 모델은 이전에 본 적 있는 카드를 92% 확률로 알아보며, Stripe에 따르면 Radar를 사용하는 기업의 사기를 평균 32% 감소시킨다고 합니다.
하지만 그 수치를 다시 읽어보세요. 감소시킨다는 것이지 없앤다는 것이 아닙니다. 평균 32%를 깎아내는 것은 분명 큰 성과지만, 이는 곧 상당량의 사기 압박이 여전히 문 앞까지 도달하고 있다는 뜻입니다. 그리고 Stripe는 그 이유에 대해 놀라울 만큼 솔직합니다. 그들의 표현을 그대로 빌리자면, *"오탐을 줄이면 진짜 사기가 틈새로 빠져나갈 가능성이 높아지는 경우가 많다"*는 것이죠. 누수는 모델의 버그가 아닙니다. 진짜 고객을 차단하지 않기 위해 의도적으로 치르는 비용입니다. 모든 사기 대응팀은 얼마만큼을 통과시킬지를 일부러 선택하고 있는 셈입니다.
체험 중심 제품에서는 그 누수가 표면적인 수치가 시사하는 것보다 더 큽니다. Radar의 가장 강력한 부분이 아예 작동조차 하지 않기 때문입니다.
게이트는 왜 줄이는 것만 가능한가
청구 시점 엔진이 사기를 줄일 수 있어도 결코 끝낼 수 없는 더 근본적인 이유가 있습니다. 그것은 Stripe의 모델 문제가 아니라 타이밍과 정보의 문제입니다. 카드가 등록되는 그 순간, 고객은 아직 아무 행동도 하지 않았습니다. 로그인 기록도, 제품 사용 행동도, 학습할 사용 패턴도 없습니다. 그저 카드 한 장과 몇 가지 네트워크 신호뿐이죠. Radar는 가장 얇은 증거 조각만으로, 그것도 가장 정보가 부족한 단 한 순간에 최선의 판단을 내려야 합니다.
이것이 진짜 한계입니다. 게이트를 아무리 정교하게 조정해도, 아직 존재하지 않는 데이터를 줄 수는 없습니다. 사기꾼과 고객을 실제로 구분해 주는 정보는 대부분 게이트가 이미 결정을 내려야 했던 이후에 생성됩니다.
1단계: 채팅 창에서의 진화 작업
우리의 첫 대응은 완전히 수작업이었습니다. 사기 물결이 밀려오면 누군가 우리 에이전트와 대화를 열고 실시간으로 사건을 처리했습니다. 최근 가입자를 끌어와 카드를 살펴보고, 패턴을 찾아내고, 계정을 일일이 손으로 차단했죠.
효과는 있었지만 확장되지는 않았습니다. 모든 사건이 매번 처음부터 시작됐습니다. 이 사기 조직은 어떻게 생겼는지, 어떤 신호가 믿을 만한지 같은 지식은 한 사람의 머릿속과 하나의 채팅 스레드에만 존재했고, 창을 닫는 순간 증발해 버렸습니다.
우리는 퍼널의 좋은 쪽에서도 값비싼 교훈을 얻었습니다. 결제를 중도 포기한 진짜 사용자를 되찾으려 할 때, 부주의하게 사기 주소로 보낸 재방문 유도 이메일은 실제로 해를 끼칩니다. 그 주소가 살아 있음을 확인시켜 주기 때문이죠. 우리가 만드는 어떤 자동화든 진짜 잠재 고객과 심어둔 가짜를 구별할 수 있어야 했습니다.
2단계: Radar로 정문 강화하기
다음 수순은 가능한 모든 것을 Radar 쪽으로 끌어올리는 것이었습니다. 카드 등록 단계에서 차단 목록과 속도 규칙을 우리가 겪던 압박에 맞춰 조정했죠. 옳은 첫 수였고, 가장 조잡한 공격들은 막아냈습니다.
하지만 두 가지 한계가 금세 드러났습니다. 첫 번째는 Stripe 스스로 지적한 것입니다. 청구 시점 엔진은 벽이 아니라 트레이드오프 다이얼입니다. 강하게 올리면 진짜 고객을 막고, 낮추면 더 많은 사기가 빠져나갑니다. 두 번째는 구조적인 것이며 체험에 특화된 문제입니다. 그 32%는 청구 시점에 얻어지는 수치인데, SetupIntent 기반 체험에는 평가할 청구 자체가 없습니다. 저장된 결제 수단에 대해 Radar를 명시적으로 활성화하지 않는 한 엔진은 아예 작동하지 않으며, 작동하더라도 SetupIntent에는 Block, Allow, 3DS 규칙만 적용됩니다. 사람에게 한 번 더 들여다볼 시간을 벌어주는 "Review" 액션은 결코 발동하지 않습니다.
그래서 전체 스택에서 가장 성능이 좋은 단일 계층이, 기본 설정상 우리가 가장 필요로 하던 바로 그 순간에 쉬고 있었던 것입니다. Radar는 정문의 게이트입니다. 우리에게는 그 뒤를 도는 순찰대가 필요했습니다.
3단계: Zero 위에 구축한 두 번째 계층
가입 이후에는 정보 구도가 뒤집힙니다. 계정이 흔적을 남기기 시작하는데, 그 흔적 중 가장 풍부한 부분은 결제 처리 업체가 결코 볼 수 없는 시스템, 즉 우리의 신원 제공자인 Clerk 안에 있습니다.
그래서 우리는 Zero에게 그것에 대한 접근 권한을 주었습니다. Clerk는 Stripe가 알 수 없는 것들을 알고 있습니다. 계정이 어떻게 생성됐는지, 가입 방식과 이메일, 그 뒤에 있는 세션과 기기 행동, 그리고 그날의 다른 모든 가입과 비교한 정확한 시점 말이죠. Stripe는 카드를 압니다. 어느 시스템도 단독으로는 전체 그림을 말해주지 못하지만, 에이전트는 양쪽을 모두 읽고 그 사이를 상호 연관 지을 수 있습니다. 게이트에서는 보이지 않던 사기가 나란히 놓고 보면 명확해집니다. 로그인 신원이 청구 신원과 맞지 않는 갓 만들어진 계정이, 비슷하게 생긴 무리와 거의 같은 시각에 생성된 것이죠. 그러한 시스템 간 결합은 청구 시점 게이트가 결코 만들어낼 수 없는 것이자, 두 시스템 위에 올라앉은 에이전트가 정확히 할 수 있는 일입니다.
이 더 풍부한 증거 기반 위에서, 우리는 몇 분마다 실시간 가입 및 청구 데이터에 대해 일련의 예약된 Zero 작업을 실행합니다. 이를 형성하는 세 가지 원칙이 있습니다.
1. 게이트만 세우지 말고 순찰하라. 에이전트는 한 순간을 평가하는 대신, 짧은 루프로 최근의 모든 가입을 훑으며 계정 데이터와 결제 메타데이터를 상호 연관 지어 정문을 빠져나간 계정들을 드러냅니다.
2. 확신도에 따라 대응을 차등화하라. 모든 신호가 같은 조치를 받아야 하는 것은 아닙니다. 확신도가 높은 패턴은 자동으로 처리됩니다. 조치가 되돌릴 수 있고 기다림의 대가가 실재하기 때문에, 계정을 즉시 정지시키고 체험을 취소합니다. 확신도가 낮은 신호는 결코 자동 조치되지 않으며, 사람이 검토할 보고서로 수집됩니다. 안전한 곳에서는 단호하게, 그렇지 않은 곳에서는 신중하게.
3. 사람이 검토할 수 있는 감사 추적을 남겨라. 모든 자동 조치는 그것을 촉발한 정확한 신호를 기록하므로, 몇 초 만에 검토하고 되돌릴 수 있습니다. 감사할 수 없는 자동화는 신뢰할 수 없는 자동화입니다.
우리는 퍼널의 우호적인 쪽에도 같은 엄격함을 적용했습니다. 별도의 작업이 진짜 결제 중도 포기 사용자를 찾아내 사람이 승인할 재방문 유도 이메일을 초안으로 작성합니다. 의도적으로 강력한 사기 필터 뒤에서 작동하므로, 우리는 결코 나쁜 주소를 검증해 주지 않습니다. 같은 엔진, 정반대의 목표인 셈입니다.
경제성에 미친 영향
순찰대가 가동되자 수치는 즉시 움직였습니다. 90번째 백분위수 가입, 즉 실제 피해를 입힌 무거운 계정들을 보세요. 그중 하나가 첫 몇 시간 동안 소진한 체험 컴퓨팅 비용이 약 4달러에서 약 0.25달러로, 94% 떨어졌습니다. 같은 기간 동안의 모든 신규 가입을 평균 내면 계정당 손실은 약 85% 감소했습니다.
변화의 형태가 핵심을 말해줍니다. 대부분의 가입은 우리에게 아무 비용도 들지 않았습니다. 손실은 언제나 오직 체험 크레딧을 빨아먹기 위해 존재하는 길고 무거운 꼬리 부분의 계정에 집중되어 있었죠. 순찰대는 퍼널을 줄인 것이 아니라 그 꼬리를 잘라낸 것입니다. 가입이 줄어든 게 아니라, 더 깨끗해진 것입니다.
왜 스크립트가 아니라 에이전트인가
크론 작업을 짤 수도 있었습니다. 우리가 그러지 않은 데는 한 가지 이유가 있습니다. 위협은 릴리스 주기보다 빠르게 변하기 때문입니다. 공격자가 전술을 바꾸면, 우리는 평이한 언어로 작업의 지시문을 업데이트하고, 새로운 로직은 다음 실행에서 바로 적용됩니다. 배포도, 스키마 마이그레이션도, 티켓도 필요 없습니다. "규칙"이 곧 프롬프트이고, 그 프롬프트는 공격자만큼이나 빠르게 바꿀 수 있습니다.
이것이 진짜 교훈입니다. Radar는 청구 시점 위험에 알맞은 도구이고, 우리는 그것에 강하게 의지합니다. 하지만 체험 중심 비즈니스에는 어떤 청구 시점 도구로도 메울 수 없는 구조적 사각지대가 있으며, 그 해법은 더 큰 규칙 엔진이 아닙니다. 위협의 속도에 맞춰 재프로그래밍할 수 있는, 빠르고 감사 가능하며 항상 켜져 있는 두 번째 계층입니다.
체험 중심 팀을 위한 정리
- 청구 없는 순간을 지도화하라. 사용자가 결제 평가 이전에 가치를 얻는 모든 지점은 청구 시점 도구가 볼 수 없는 틈입니다.
- 대체하지 말고 계층화하라. Radar는 정문에 두세요. 그 뒤에 가입 이후의 지속적인 순찰을 더하세요.
- 시스템 간을 결합하라. 결제 처리 업체와 신원 제공자는 각각 그림의 절반씩을 쥐고 있습니다. 사기는 그 겹치는 부분에서 보입니다.
- 확신도에 따라 조치를 차등화하고, 하나하나 기록하라. 조치가 되돌릴 수 있고 신호가 강할 때만 자동 조치하고, 나머지는 사람에게 넘기세요.
- 적응 속도를 최적화하라. 사기에서는 규칙을 가장 빠르게 바꿀 수 있는 팀이 이깁니다.
항상 켜져 있는 에이전트가 당신의 스택에서 무엇을 자동화할 수 있을지 궁금하신가요? Zero 살펴보기.
참고: Radar 수치는 Stripe가 직접 공개한 수치입니다(stripe.com/radar; "A primer on machine learning for fraud detection"). 손실 수치는 등록 후 첫 몇 시간 동안 신규 가입당 발생한 컴퓨팅 비용을 반영하며, 출시 전후의 매칭된 기간에 걸쳐 측정되었고 내부 계정은 제외되었습니다. 출시 후 표본은 아직 초기 단계이며 시간이 지나면서 더 안정될 것입니다.