Databricks에서 축구 코칭 앱 구축하기

트래킹 데이터는 이제 스포츠에서 가장 풍부한 신호가 되었지만, 진짜 과제는 이 데이터를 감독이 실제로 사용할 수 있는 정보로 전환하는 것입니다.

현대의 경기 방식은 19개의 개별 피드로부터 초당 25프레임(fps)으로 캡처됩니다. 모든 선수, 공, 그리고 모든 이벤트가 매초 여러 번 기록됩니다. 단 하나의 토너먼트만 해도 339개의 경기와 5,100만 행의 트래킹 데이터가 생성됩니다. 하지만 정작 이 데이터가 가장 필요한 사람에게는 거의 무용지물입니다. 벤치에 앉아 있는 감독이 5,100만 행짜리 테이블을 읽을 수는 없기 때문입니다. Coach's Corner는 단 하나의 플랫폼에서 이 격차를 완전히 해소합니다.

문제는 단순히 규모뿐만 아니라 타이밍과 인지력입니다. 감독은 몇 분이 아니라 몇 초 만에 결정을 내려야 하지만, 기존의 분석 워크플로는 그 반대(배치 처리, 오프라인 대시보드, 경기 후 검토)를 가정합니다. 인사이트가 존재하더라도 분석가가 이를 해석하고 전달해야 하는 도구 뒤에 숨겨져 있는 경우가 많습니다. 이로 인해 데이터는 풍부하고 모델은 정교하지만, 정작 중요한 순간에 의사 결정권자는 눈을 감고 있는 것과 다름없는 구조적 병목 현상이 발생합니다.

Coach’s Corner, “La Pizarra”를 소개합니다

La Pizarra(“칠판”)는 Databricks App으로 실행되는 국가대표팀 기술 벤치 솔루션입니다. 감독은 경기를 선택해 2D 또는 3D로 다시 보면서, 카메라를 방송 중계 각도에서 탑다운 전술 뷰로 전환하고 최대 8배속으로 탐색(scrubbing)할 수 있습니다. 리플레이 화면 위에는 슈팅 및 xG 맵, 패스 네트워크, 히트맵, 세트피스, 팀 대형, 피치 컨트롤, 볼 궤적, 선수 이동 경로 등 중요한 분석 데이터가 레이어로 표시됩니다. 리플레이 기능과 함께 종합 순위 보기, 이벤트 기반 분석, 모든 팀을 평가할 수 있는 독특한 Scout 스타일 시그니처, 다음 상대 팀에 대한 맞춤형 분석 보고서를 즉시 생성할 수 있는 Tactical Agent 등 여러 고급 도구가 통합되어 있습니다.

벤치 뷰는 경기 전체를 감독의 손안에 쥐어주며, 방송 중계 화면과 전술적 탑다운 뷰 사이를 매끄럽게 전환할 수 있도록 지원합니다. 8배속 탐색 기능과 패스 경로 및 히트맵 자동 오버레이를 통해 피치 컨트롤, 팀 대형과 같은 전술적 요소가 멀게만 느껴지는 지표가 아닌 경기장 위의 실질적인 패턴으로 시각화됩니다.

Coach's Corner의 기술적 기반은 단 하나의 핵심 원칙에 따라 설계되었습니다. 바로 인터페이스가 복잡한 분석 도구가 아니라 감독의 자연스러운 직관의 연장선으로 작동해야 한다는 점이었습니다. 이를 위해 상호작용 오버헤드를 줄이고, 전통적인 그래프 대신 공간적 맥락을 우선시하며, 모든 지표를 경기의 역동적인 요소로 표현하는 디자인이 필요했습니다. 인사이트를 경기장에 직접 연결함으로써, 이 애플리케이션은 수동으로 데이터를 해석할 필요를 없애고 가장 필요한 순간에 정확하게 핵심 분석을 제공합니다.

단 하나의 플랫폼에서 모든 단계를 처리

핵심 데이터 엔지니어링은 보이지 않는 곳에서 이루어집니다. 원시 트래킹 피드는 Unity Catalog Volume에 NDJSON 형식으로 저장되며, 여기서 Auto Loader가 Lakeflow Connect 패턴을 사용하여 데이터를 증분 방식으로 수집합니다. 거기서부터 Spark Declarative Pipelines가 브론즈, 실버, 골드 티어를 통해 데이터를 처리하며, Photon 상에서 완전한 서버리스로 실행되고 46개의 지정된 데이터 품질 기대치를 강제 적용합니다. 5,100만 행의 프레임 테이블을 포함한 최종 골드 테이블은 리퀴드 클러스터링(liquid clustering)을 활용하여 소형 웨어하우스에서 실행되는 DBSQL을 통해 1~3초의 빠른 쿼리 응답 시간을 제공합니다. 모든 볼륨, 테이블, 모델, 인덱스를 단일 Unity Catalog로 통합함으로써, 이 아키텍처는 벤더사 간의 연동 코드(glue code)와 보조 거버넌스 시스템의 필요성을 없앱니다.

이 아키텍처는 특화된 마이크로서비스로의 전환을 지양함으로써 의도적으로 파편화를 방지했습니다. 수집, 변환, 서빙, AI 오케스트레이션을 격리되고 로컬에 최적화된 개별 스택으로 나누는 대신, 시스템을 단일 플랫폼으로 통합하여 유지했습니다. 모든 것을 Databricks 내부에 유지함으로써 이론적인 유연성을 일부 양보하는 대신 운영의 일관성(단일 거버넌스 레이어, 일관된 리니지, 시스템 간의 임피던스 불일치 해소)을 확보했습니다. 이는 AI를 도입할 때 특히 중요해집니다. 거버넌스가 없거나 일관되지 않은 데이터로 인해 발생하는 비용이 빠르게 누적되기 때문입니다.

Spark Declarative Pipelines는 명령형 모델에서 명시적 모델로 전환함으로써 안정성을 재정의합니다. 가정이 내장된 경직된 작업에 의존하는 대신, 시스템은 공식적인 기대치를 적용하여 데이터 품질을 최우선 과제로 취급합니다. 이 46개의 기대치 세트는 파이프라인을 실시간으로 보호하는 동시에 리플레이, 분석, AI 에이전트를 포함한 다운스트림 소비자를 위한 데이터의 "정확성"을 확립하는 이중 목적을 수행합니다.

아래 다이어그램은 벤치 뷰를 구동하는 아키텍처입니다. 상단에는 감독이 직접 접하는 경험인 리플레이, 분석, 스카우트, 순위, 에이전트가 위치합니다. 중간에는 이러한 각 경험을 지원하는 거버넌스 레이어(데이터 및 모델을 위한 Unity Catalog, 분석 및 트랜잭션 서빙을 위한 Lakehouse 및 Lakebase, 유사도 검색을 위한 Vector Search)가 있습니다. 하단에는 이 모든 것이 시작되는 원시 데이터인 25 fps 트래킹 피드, 경기 이벤트, 선수 프로필, 라인업이 오픈 레이크로 수집되는 실제 환경이 자리 잡고 있습니다.

속도와 확장성을 위해 최적화된 서빙 경로

최상의 성능을 보장하기 위해, 이 애플리케이션은 데이터 검색을 위해 두 가지 고유한 아키텍처 경로를 활용합니다. 고속 트래킹 리플레이는 Lakebase를 통해 구동되며, 이는 골드 테이블을 Postgres와 동기화하여 밀리초 단위의 윈도우 프레임 읽기를 가능하게 합니다. 브라우저 클록이 전체 경기를 스캔하는 대신 필수 프레임만 가져오도록 함으로써, 시스템은 매끄럽고 인터랙티브한 경험을 유지합니다. 반대로 무거운 이벤트 분석은 Statement Execution API를 통해 SQL 웨어하우스로 라우팅되어, 고부하 연산 쿼리를 반응성이 중요한 3D 리플레이와 분리하여 유지합니다.

Lakebase와 DBSQL 간의 이러한 의도적인 이원화는 단순히 원시 속도뿐만 아니라 서로 다른 액세스 패턴을 해결합니다. 리플레이 기능은 특정 데이터 세그먼트에 대해 지연 시간에 민감한 순차적 읽기를 요구하는 반면, 분석 워크로드는 대개 탐색적이며 광범위한 데이터 세트 스캔이 필요합니다. 이러한 경로를 격리함으로써 각 워크로드는 이상적인 환경에서 작동하며, 분석 작업의 급증으로 인해 리플레이 경험이 저하되거나 불필요한 오버프로비저닝이 발생하는 것을 방지합니다.

Lakebase와 DBSQL의 분리는 단순히 성능의 문제가 아니라 액세스 패턴의 문제입니다. 리플레이 워크로드는 매우 순차적이고 지연 시간에 민감하므로, 좁은 데이터 슬라이스에 대해 예측 가능한 밀리초 단위의 읽기가 필요합니다. 반면에 분석 쿼리는 일시적으로 급증하고 탐색적인 성격을 띠며, 데이터 세트의 더 큰 부분을 스캔하는 경우가 많습니다. 이를 단일 서빙 레이어로 통합하려고 하면 리플레이 속도가 느려지거나 분석 환경을 과도하게 프로비저닝해야 합니다. 경로를 분리하면 타협 없이 각 워크로드가 이상적인 환경에서 작동할 수 있습니다.

거버넌스가 적용된 데이터에 기반한 AI 스카우팅 레이어

인텔리전스는 거버넌스가 적용된 데이터와 별개로 존재하는 것이 아니라, 동일한 데이터 위에서 작동합니다. Scout 채팅은 감독의 자연어 질문을 거버넌스가 적용된 SQL로 변환하는 실제 Genie 공간을 기반으로 합니다. Vector Search는 선수 프로필 인덱스를 기반으로 "유사한 선수" 검색 기능을 제공합니다. 상대 팀 분석 보고서는 하나의 에이전트입니다. Agent Bricks 감독자가 Genie, Vector Search, 그리고 Unity Catalog에 등록된 xG 모델을 오케스트레이션하고, 거버넌스가 적용되고 관찰 가능한 LLM 호출을 위해 Unity AI Gateway를 통해 Model Serving의 Claude를 호출합니다. 모든 단계는 MLflow에서 추적되며, 에이전트는 항상 결정론적인 스크립트 폴백(fallback)을 가지고 있어 청중 앞에서 작동이 완전히 중단되는 일이 없습니다. 감독이 보드에서 보는 것과 동일한 카탈로그를 읽기 때문에, 답변은 항상 데이터와 일관성을 유지합니다.

아래의 스카우트 뷰에서 감독은 쿼리를 작성하는 것이 아니라 락커룸에서 질문하듯이 자연스럽게 질문을 던집니다. Genie는 "xG 대 xBA에 대해 질문하기"를 입력받아 벤치를 구동하는 것과 동일한 트래킹 및 이벤트 데이터를 사용하여 이를 거버넌스가 적용된 SQL로 조용히 변환합니다. 답변은 일반적인 LLM의 응답이 아닙니다. Unity Catalog에 등록된 정확한 테이블과 모델을 기반으로 하므로, 스카우트의 설명은 분석가가 보게 될 숫자와 정확히 일치합니다.

응용 AI에서 가장 어려운 문제 중 하나는 답변을 생성하는 것이 아니라, 그 답변을 추적하고 입증할 수 있도록 보장하는 것입니다. 코칭 환경에서 잘못되거나 검증할 수 없는 인사이트는 인사이트가 전혀 없는 것보다 더 나쁩니다. 모든 AI 상호작용의 기반을 Unity Catalog에 두고 모든 모델 호출을 Unity AI Gateway를 통해 라우팅함으로써, 모든 응답은 거버넌스가 적용된 데이터 및 관찰 가능한 실행 경로와 연결됩니다. 이를 통해 감독과 분석가는 결과물뿐만 아니라 그 이면의 프로세스까지 신뢰할 수 있게 됩니다.

에이전트 아키텍처 역시 결정론(determinism)을 지향하는 경향을 반영합니다. LLM이 요약과 설명을 제공하는 동안, 데이터 검색, 지표 계산, 유사도 검색과 같은 중요한 단계는 Genie 및 Vector Search와 같은 구조화된 시스템에 의해 처리됩니다. 이러한 하이브리드 접근 방식은 완전한 생성형 시스템의 취약성을 피하면서도 유연하고 자연스러운 상호작용을 가능하게 합니다.

이것이 중요한 이유

Coach’s Corner는 스포츠에 뿌리를 두고 있지만, 그 아키텍처는 고주파(high-frequency) 데이터의 "사용성 격차"라는 보편적인 과제를 해결합니다. 대부분의 조직은 방대한 양의 데이터를 보유하고 있지만, 원시 입력을 즉각적인 의사 결정으로 변환하는 시스템이 부족하여 운영 측면에서 제대로 활용하지 못하고 있습니다. 이 프로젝트는 단일 거버넌스 프레임워크 내에서 수집, 변환, AI를 통합함으로써 데이터와 행동 사이의 마찰을 없앨 수 있음을 증명합니다.

이는 단순히 대시보드가 빨라지는 것만을 의미하는 것이 아니라, 의사 결정 방식의 변화를 뜻합니다. 동일한 시스템 내에서 단 몇 초 만에 인사이트를 생성, 검증 및 전달할 수 있게 되면, 데이터의 역할은 사후 분석에서 의사 결정에 대한 적극적인 참여로 진화합니다. 이것이 바로 경기를 관찰하는 것과 경기에 영향을 미치는 것의 차이입니다.

아래의 에이전트 뷰는 이러한 패턴이 온전히 구현된 모습입니다. 추적 데이터와 경기 이벤트에서 시작하여, 감독(supervisor) 에이전트가 팀의 스타일 시그니처를 가져오고, 유사한 경기를 검색하고, xG 모델을 호출한 다음, LLM에 이 모든 것을 종합하여 보고서로 작성하도록 요청합니다. 코치는 이러한 오케스트레이션 과정을 전혀 볼 필요가 없습니다. 코치에게는 "브라질 보고서 생성"이라는 라벨이 붙은 버튼, 원할 때 검토할 수 있는 추론 추적(reasoning trace), 그리고 경기 계획의 일부가 되는 저장된 보고서만 보입니다.

처음에 스포츠 중심의 애플리케이션으로 구상되었던 Coach’s Corner는 라이브 엔터테인먼트 부문 내 현대적인 데이터 및 AI 시스템을 위한 확실한 청사진으로 발전했습니다. 원시 데이터를 한 번 로드한 후 안정적인 파이프라인을 통해 정제함으로써, 시스템은 각 특정 워크로드에 최적의 경로로 정보가 제공되도록 보장합니다. 이 프로세스는 원시 입력을 의사 결정이 필요한 바로 그 순간에 활용할 수 있는 거버넌스가 확보된, 실행 가능한 인텔리전스로 변환합니다. 이 이니셔티브의 가장 중요한 시사점은 명확합니다. 데이터 관리, 서빙 및 AI가 단일 플랫폼에 통합되면 인사이트가 즉각적인 행동으로 전환된다는 것입니다.

이와 같은 것을 구축하고 싶으신가요? Databricks Apps 문서를 탐색하여 자체 풀스택 데이터 앱을 배포하고, Lakebase가 레이크하우스에 밀리초 단위의 Postgres 서빙을 제공하는 방법을 확인하고, Genie와 Agent Bricks가 어떻게 하나의 Unity Catalog 아래에서 데이터에 거버넌스가 확보된 자연어 인텔리전스를 추가하는지 알아보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)