Chiko IT
AI 코딩 도구

Ferrari + IBM이 AI로 F1 슈퍼팬 만드는 법 — 개인화 프로젝트 회고

Chiko
9min read

목차

Ferrari가 IBM과 다년간 파트너십(2024-11-13 공식 발표, 출처: Ferrari Press Release)을 맺으면서 팬 인게이지먼트 영역에 watsonx를 본격적으로 도입했다. 같은 시기에 팀에서 굴리던 스포츠 콘텐츠 앱에도 LLM 기반 개인화 모듈을 붙였고, 3개월 동안 부딪힌 결과가 정리됐다. 두 작업은 규모가 비교 자체가 안 되지만, 의사결정 구조와 깨지는 지점은 닮아 있었다.

변경 전과 변경 후 — 운영 구조가 어떻게 바뀌었나

Ferrari 발표 자료와 IBM Consulting이 공개한 데모(2025년 1분기 기준)를 종합하면, 변경 전후의 구조 차이는 다음과 같다. 우측 컬럼은 watsonx 도입 시점의 그림이고, 실제 시즌 성과 수치는 Ferrari가 공개해야 알 수 있다.

항목 기존 방식 watsonx 도입 후
콘텐츠 생성 마케팅팀이 언어별 수동 작성 LLM이 세그먼트별 변주, 사람 검수
개인화 단위 국가/언어 관심 드라이버, 시청 시간대, 굿즈 이력
푸시 트리거 일정·일반 뉴스 레이스 중 실시간 이벤트(추월, 피트, 세이프티카)
다국어 처리 8개 언어 인간 번역 watsonx 자동 생성 + 사람 검수
게시 지연 콘텐츠 게시까지 수십 분 라이브 이벤트 후 수십 초 단위

핵심은 수치가 아니라 구조의 이동이다. "사람이 콘텐츠를 다 만드는 구조"에서 "사람이 가드레일을 잡고 LLM이 변주하는 구조"로 옮긴 게 본질이다. 가드레일을 누가 어떻게 잡느냐가 도입의 성패를 가르는 것으로 보인다.

Ferrari + IBM 파트너십이 노린 것

특히, IBM은 이번 파트너십에서 두 가지 역할을 동시에 맡는다. 하이브리드 클라우드 인프라 공급자와 팬 인게이지먼트용 AI 플랫폼(watsonx) 공급자다. Ferrari 입장에서는 "글로벌 팬"이라는 자산을 데이터로 묶고, 다국어 콘텐츠 생산 비용을 낮추는 게 1차 목표로 보인다.

그러나, 여기서 눈에 띄는 건 IBM이 "Official Fan Engagement Partner"라는 호칭을 받았다는 점이다. 통상적인 IT 스폰서십과 결이 다르다. 머신에 로고를 박는 수준이 아니라, 팬 앱과 디지털 채널 운영 자체에 watsonx와 IBM Consulting이 들어간다.

이처럼, 기술 스택은 watsonx.ai(생성), watsonx.data(통합), watsonx.governance(거버넌스)의 세 축으로 구성되어 있다(출처: IBM Newsroom 2024-11-13). 모델은 IBM Granite 계열과 외부 모델을 혼합해서 쓰는 것으로 알려져 있다. 거버넌스가 별도 축으로 빠진 점은 흥미롭다. F1처럼 노출이 큰 도메인에서 톤이나 팩트가 어긋나면 그게 곧 브랜드 리스크가 되기 때문이다.

비슷한 시기, 비슷한 결정을 했다

그러나, 규모는 비교가 안 되지만 같은 시기에 팀에서도 결정을 내려야 했다. 스포츠/엔터테인먼트 도메인의 콘텐츠 앱이고, 이벤트 기반 푸시와 다국어 콘텐츠가 발목을 잡고 있었다. 푸시 오픈율이 한 자릿수 초반에서 안 올라가니, 마케팅 쪽이 먼저 LLM 도입 이야기를 꺼냈다.

즉, 5년차 입장에서 처음 든 생각은 "잘 굴러가는 룰베이스를 굳이 갈아엎어야 하나"였다. 잘 되면 안 건드린다는 원칙이 몸에 배어 있다. 그래서 의사결정 전에 세 가지를 확인했다. 룰베이스 한계가 진짜 룰의 한계인지 콘텐츠 다양성의 한계인지, LLM 비용이 현재 마케팅 인력 비용보다 낮을 수 있는지, 운영팀이 프롬프트와 가드레일을 관리할 수 있는 수준인지.

한편, 세 질문 다 "절반쯤 그렇다"였다. 그래서 전체 교체가 아니라 푸시 트리거 변주와 다국어 콘텐츠 자동 생성, 두 지점에만 LLM을 붙이기로 했다. Ferrari + IBM 케이스와 비슷한 방향이다. 콘텐츠 생산 전체를 뒤집지 않고, 변주 레이어와 다국어 레이어만 LLM에 맡긴다.

모델 선택은 보수적으로

모델은 Claude 3.5 Sonnet(2024-10 릴리스)을 메인으로 두고, 다국어 검수 비교 출력에는 GPT-4o-mini를 보조로 깔았다. Granite도 검토했지만 같은 비용대에서 우리 도메인 한국어 품질이 더 안정적인 쪽으로 골랐다. 도메인과 언어에 따라 결과가 다를 수 있으니 일반화하긴 어렵다.

결국, RAG 구조는 pgvector(PostgreSQL 16 + pgvector 0.7)로 잡았다. 기존 PostgreSQL을 그대로 쓸 수 있다는 게 컸다. 벡터 전용 DB를 새로 들이는 건 운영 부담이 너무 크다고 봤다. 새 기술 하나가 들어오면 모니터링, 백업, 권한 관리가 줄줄이 따라온다.

중간에 터진 것들

이처럼, 3개월 중 두 번 크게 흔들렸다. 둘 다 LLM 자체 문제가 아니라 주변부 문제였다.

한편, 첫 번째는 데이터 정합성이었다. 팬 프로필을 LLM 컨텍스트로 넣어 개인화 푸시를 만드는 구조였는데, 회원 정보 변경이 즉시 반영되지 않으니 "이미 응원하지 않는 선수" 기반 푸시가 나갔다. 알림 받은 사용자한테는 그냥 오작동이다. 프로필 변경 이벤트에 캐시 무효화를 붙여서 해결했다. 평범한 분산 시스템 문제인데 LLM이 끼니까 디버깅이 한 단계 더 꼬였다. 원인이 모델인지 데이터인지 매번 갈라봐야 했다.

두 번째는 비용. 예상치의 1.4배가 나왔다. 원인은 컨텍스트 길이였다. 팬 한 명에 대한 컨텍스트를 매번 다시 조립해서 넣고 있었는데, 프롬프트 캐싱(Anthropic API prompt caching, 2024-08 GA)을 적용한 뒤 토큰 비용이 약 40% 떨어졌다. 진작 적용했어야 하는 부분이었고, 시간을 한 번 돌린 비용이다.

게다가, Ferrari + IBM 케이스에서도 비용 관리는 핵심 이슈로 보인다. watsonx 자체가 비용 통제와 거버넌스를 강조하는 플랫폼이라는 점이 우연이 아니다. 다국어 콘텐츠를 LLM으로 통째로 돌리면 토큰이 폭발한다. 글로벌 팬 단위로 가면 자릿수가 한 단계 더 올라간다.

운영팀 교육이 가장 오래 걸렸다

기술보다 사람 쪽이 시간을 더 먹었다. 마케팅 운영팀이 프롬프트를 직접 수정할 수 있어야 했다. "코드로 관리하면 안 되냐"는 의견도 있었지만, 콘텐츠 톤은 마케팅이 결정해야 한다는 게 맞다고 본다. 노션에 프롬프트 라이브러리를 두고, 변경 시 PR을 거는 간소한 워크플로를 만들었다.

그러나, 이 부분이 Ferrari + IBM 케이스에서 가장 궁금한 영역이다. IBM Consulting이 들어간다는 건 결국 이 운영 워크플로 설계까지 묶여 있다는 의미다. 기술 도입보다 이쪽 비용이 훨씬 클 가능성이 높다(개인적으로 컨설팅 비중이 라이선스 비중보다 큰 계약일 것 같다).

결국 어떻게 됐나

또한, 3개월이 지나고 보면 결과는 양면적이다.

푸시 오픈율은 체감상 2배 중반 정도로 올랐다(내부 측정치, 외부 일반화 금지). 다국어 콘텐츠 제작 리드타임은 평균 3일에서 4시간 수준으로 줄었다. 마케팅팀의 잔업이 줄었다는 게 가장 체감되는 변화다. 콘텐츠 다양성은 LLM 변주 덕에 명백히 좋아졌다.

반면 운영 부담은 늘었다. 프롬프트 회귀 테스트, 톤 일관성 검수, 비용 모니터링 같은 작업이 새로 생겼다. 인프라 비용은 월 단위로 보면 마케팅 인건비 절감분보다 적지만, 사람 작업이 줄어든 자리에 다른 모양의 사람 작업이 들어왔다는 게 정확한 표현이다.

반면, Ferrari + IBM 케이스는 시즌이 끝나봐야 평가가 된다. F1 캘린더 특성상 시즌 중반 성적과 팬 반응이 같이 움직이기 때문에, 인게이지먼트 지표만으로 AI 효과를 분리하기 어렵다. 외부에서 평가 가능한 시점은 시즌 데이터가 정리된 후라고 봐야 한다.

언제 이 방식이 맞고, 언제 안 맞나

즉, 3개월 굴려보고 내린 판단 기준은 다음과 같다. Ferrari 같은 대형 케이스와 중소 규모 모두에 적용 가능한 선이다.

이 방식이 맞는 상황은 세 가지다. 콘텐츠 다양성이 인게이지먼트의 병목이라는 데이터가 있을 때. 단순 클릭률 하락이 아니라 "같은 푸시를 N번 받았을 때 반응이 떨어지는 패턴"이 보이면 변주 레이어가 효과를 본다. 다국어 콘텐츠를 운영 중이고 언어별 인력 비용이 부담스러울 때. 자동 생성 후 사람 검수 워크플로가 ROI가 가장 좋다. 운영팀에 프롬프트와 가드레일을 다룰 수 있는 사람이 한 명이라도 있을 때. 이게 없으면 도입 자체를 미루는 게 맞다.

반대로 이 방식이 안 맞는 상황도 분명하다. 콘텐츠 양 자체가 적다면 사람이 쓰는 게 더 빠르고 정확하다. 한 달 푸시 수십 건 수준이면 LLM 도입 비용을 회수할 수 없다. 톤이 매우 보수적이어야 하는 도메인(금융, 의료)에서는 변주 자체가 리스크다. 데이터 정합성 인프라가 약한 팀이라면 LLM이 오작동을 증폭시킨다. 우리가 캐시 무효화에서 한 번 맞은 것과 같은 일이 자주 일어난다.

또한, 당장 적용 가능한 액션은 세 가지로 좁힌다. 첫째, 현재 푸시 데이터를 세그먼트별로 N+1회 노출 시 반응률 변화로 그려본다. 변주 도입 근거를 데이터로 잡는 단계다. 둘째, 프롬프트 캐싱이 가능한 모델인지 확인하고 컨텍스트 구조를 캐시 가능한 형태로 먼저 설계한다. 도입 후 적용하면 토큰 폭발을 한 번 맞는다. 셋째, 운영팀이 프롬프트를 직접 편집할 수 있는 워크플로를 먼저 설계한다. 기술 PoC보다 이쪽이 도입 성공률을 좌우한다.

특히, Ferrari + IBM 케이스는 규모가 다르지만 본질적으로 같은 의사결정을 했다. 변주와 다국어 레이어에 LLM을 붙이고, 콘텐츠 톤은 사람이 관리한다. 큰 조직이든 작은 팀이든 ROI가 가장 명확한 두 레이어가 결국 같은 모양으로 수렴한다는 점이 흥미롭다. 보수적으로 두 레이어부터 시작하는 게 현재까지의 결론이다.

관련 글

More posts