페라리가 AI로 F1 팬을 만드는 방법

왜 결제·정산 팀이 이 사례를 봐야 하는가

페라리와 IBM이 함께 만든 AI 팬 경험 플랫폼은 표면적으로 스포츠 마케팅 이야기다. IBM의 AI는 각 팬의 시청 이력, 응원하는 드라이버, F1 용어 이해 수준을 실시간으로 추적해 개인화된 해설과 콘텐츠를 제공한다. 전 세계 수백만 팬 개개인에게 '지금 이 사람에게 맞는 설명'을 자동으로 붙이는 구조다. 겉에서 보면 팬덤 관리지만, 안을 들여다보면 전혀 다른 문제를 풀고 있다: 서로 다른 수백만 명에게 각자의 맥락에 맞게 실시간으로 정보를 전달하는 시스템을 어떻게 만드는가.

이 질문은 우리가 결제·정산·자동화 플랫폼을 운영하면서 매일 마주하는 것과 구조적으로 같다. F1 입문자가 DRS·언더컷·버추얼 세이프티카(VSC)를 한 번에 설명 들으면 다음 레이스를 안 본다. 새로 온보딩된 가맹점이 정산 대시보드 첫 화면에서 '미정산 금액', 'PG 수수료 차감 내역', '배치 정산 주기'를 동시에 마주하면 절반은 CS 문의를 넣거나 아예 기능을 외면한다. 두 경우 모두 정보의 양이 문제가 아니다. 타이밍과 순서가 틀린 것이다.

온보딩 자동화: F1 입문자와 신규 가맹점은 같은 문제를 겪는다

IBM이 페라리에 구축한 시스템의 핵심 메커니즘은 세 단계 루프다. 첫째, 시청 이력과 클릭 패턴으로 팬의 '현재 이해 수준'을 추정한다. 둘째, 레이스 중 발생하는 이벤트(오버테이킹, 피트스톱, 페널티)에 맞춰 그 팬에게 필요한 해설을 실시간으로 생성한다. 셋째, 팬이 해설을 소비하는 방식(클릭·스킵·재시청)을 다시 피드백으로 넣어 다음 해설의 복잡도를 조정한다. 이 루프가 수백만 명을 동시에 각각 다른 속도로 F1 슈퍼팬으로 밀어올리는 경로다.

우리 팀의 가맹점 온보딩에 이 구조를 대입하면 현재 시스템의 공백이 선명하게 보인다. 현재는 가맹점 업종·거래 규모·정산 주기 설정 여부와 무관하게 동일한 대시보드와 동일한 가이드를 제공한다. 가맹점 A가 '정산 내역' 탭을 하루 7회 반복 조회해도, '자동화 규칙 설정' 메뉴를 3일 동안 한 번도 열지 않아도, 시스템은 이 신호를 포착하지 않는다. 페라리-IBM 구조에서 가져올 핵심은 '이해 수준 추정 레이어'다. 사용자가 무엇을 반복하고 무엇을 회피하는지—그 행동 이벤트 자체가 맥락이다.

수치로 보는 개인화의 비용과 숨겨진 트레이드오프

개인화 시스템을 도입할 때 흔히 과소평가하는 비용이 두 가지 있다. **지연(latency)**과 **유지보수 부채(maintenance debt)**다.

실시간 맥락 감지는 사용자 이벤트가 발생할 때마다 추론 파이프라인을 돌린다. 페이지 로드 시 콘텐츠를 개인화하려면 이 추론이 100~~200ms 안에 끝나야 한다. IBM의 엔터프라이즈 인프라는 이걸 맞추지만, LLM API를 직접 붙이면 첫 응답 지연이 500ms~~2s를 쉽게 넘긴다. 결제 UX 연구에서 반복적으로 나오는 수치가 있다: 페이지 로드 100ms 증가당 전환율 약 1% 감소. 개인화의 이득이 지연의 손실을 초과하는지를 측정하지 않고 도입하면 순효과가 마이너스가 될 수 있다.

유지보수 부채는 더 조용하게 쌓인다. 가맹점 유형 5개 × 정산 주기 3개 × 이해 수준 3단계만 조합해도 45가지 경로가 생긴다. 제품이 바뀔 때마다 45가지를 모두 검증해야 한다. 페라리-IBM은 이 문제를 LLM 기반 생성으로 우회했다—규칙 기반 분기 대신 모델이 맥락을 보고 직접 생성한다. 유지보수는 쉬워지지만 출력의 예측 가능성이 낮아진다. 정산 알림이나 이상 탐지 메시지에서 '예측 불가능한 출력'은 허용 범위가 매우 좁다. 규칙 기반과 생성 기반 중 어느 쪽을 어느 영역에 쓸지를 미리 분리해야 한다.

HEDVION 시나리오: 우리라면 어떻게 설계하는가

IBM 없이 이 구조의 핵심만 가져오는 실제 구현 경로를 하나 구체화해보자. 신규 가맹점 A가 온보딩 후 첫 72시간 동안 대시보드에서 보이는 행동을 기반으로 세 단계 개입을 설계한다.

1단계 — 감지: 이벤트 스트림에서 '정산 내역 탭 하루 5회 이상 조회'를 트리거로 등록한다. 이 시점에 해당 가맹점의 최근 정산 패턴(건수, 금액 분포, 미정산 잔액)을 자동 요약해 대시보드 상단에 노출한다. LLM 불필요—템플릿 기반 요약이면 충분하고, 지연도 없다. 2단계 — 추천: '자동화 규칙 미설정' 상태가 3일 이상 지속되면 해당 가맹점의 업종과 거래 규모를 기반으로 추천 규칙 한 가지를 한 줄 설명과 함께 제안한다. 예: "하루 평균 거래 건수가 30건을 넘습니다. 일별 자동 정산을 켜면 주 1회 수동 확인을 없앨 수 있습니다." 3단계 — 피드백 루프: 추천을 수락했는지, 무시했는지, 설명을 클릭했는지를 기록해 다음 추천의 노출 시점과 복잡도를 조정한다.

이 구조는 Kafka 수준의 이벤트 스트리밍, 간단한 조건 분기, 템플릿 엔진으로 구현된다. 중요한 건 IBM 수준의 AI가 아니라 '맥락 감지 → 개입 시점 결정 → 개인화된 메시지 전달'이라는 구조 자체를 시스템으로 만드는 것이다. 정산 이상 탐지 알림에도 같은 로직이 적용된다. 처음 이상 알림을 받는 가맹점에게는 '이게 무슨 의미인지'를 포함한 설명이 필요하고, 이미 수십 번 받아본 가맹점에게는 '이번엔 뭐가 다른지'만 보여주면 된다. 이 차이 하나가 CS 문의 건수를 체감할 수 있는 수준으로 줄인다.

개인화의 천장 효과: 놓치기 쉬운 리스크

페라리-IBM 사례에서 잘 보이지 않는 위험이 하나 있다. 개인화 시스템이 사용자의 현재 이해 수준에 맞는 콘텐츠만 반복 제공하면, 사용자는 편안한 수준에 머문다. 더 복잡한 기능으로 자연스럽게 넘어가는 경로를 명시적으로 설계하지 않으면 개인화가 성장을 막는 천장이 된다. F1으로 치면 입문자 해설만 계속 받다가 결국 깊은 팬이 못 되는 상황이다.

결제·정산 플랫폼에서 이 문제는 더 직접적인 비용을 만든다. 가맹점이 기본 정산 기능에만 익숙해진 채 자동화 규칙이나 이상 탐지 기능을 학습하지 않으면, 기능 의존도가 낮은 상태에서 이탈 결정이 쉬워진다. 기능을 많이 쓸수록 전환 비용이 높아져 이탈이 어려워지는데, 개인화가 그 경로 자체를 막아버리면 역효과다. 따라서 맥락 기반 개입을 설계할 때는 반드시 '현재 수준 유지' 트리거와 '다음 단계 유도' 트리거를 구분해서 넣어야 한다.

지금 바로 써먹을 수 있는 실행 시사점

페라리-IBM 사례를 HEDVION 맥락에서 분해했을 때 나오는 즉시 실행 가능한 네 가지 액션이다.

① 이벤트 스트림 목록화부터 시작하라. 개인화 시스템의 전제는 행동 데이터다. 현재 대시보드에서 수집되는 이벤트(클릭, 조회, 오류, 이탈)를 목록화하고, 온보딩 관련 이벤트가 충분히 쌓이는지 먼저 확인한다. LLM·ML 도입은 그 이후 단계다.

② CS 문의 상위 3개 패턴을 찾아라. 신규 가맹점 CS 문의의 상위 항목은 대부분 같은 시점, 같은 이해 부족에서 반복 발생한다. 이 세 시점에 맥락 기반 인라인 가이드를 삽입하는 것만으로 CS 건수를 20~30% 줄이는 것은 현실적인 목표다. 개인화의 시작점은 AI가 아니라 이 패턴 분석이다.

③ LLM 도입 전 p95 지연을 먼저 측정하라. 결제 플로우에 인접한 UI에 실시간 개인화를 붙이려면 p95 응답 지연의 허용 임계값(예: 200ms)을 사전에 정해야 한다. 초과하면 비동기 처리(페이지 로드 후 삽입)로 전환하거나 규칙 기반 로직으로 대체한다. 임계값 없이 붙이면 전환율 데이터로 나중에 후회한다.

④ '레벨업 트리거'를 별도로 설계하라. 가맹점이 기능 A를 n회 이상 사용했을 때 기능 B를 소개하는 단계적 유도 트리거를 현재 수준 유지 트리거와 분리해 넣어야 한다. 이 트리거 없이는 개인화가 고착화 도구가 되고, 플랫폼 의존도는 제자리다.

페라리가 AI로 F1 슈퍼팬을 만드는 방식과 우리가 결제 플랫폼 위에서 가맹점의 자립도를 높이는 방식은 기술 스택이 다르지만 문제의 형태가 같다. 차이는 규모와 예산이다. 그 격차를 좁히는 건 구조를 먼저 이해하고 작게 실험하는 팀이다.

원문: Ferrari is using AI to create F1 superfans — TechCrunch, 2026-05-23