스포츠 팀의 데이터 및 AI 활용 사례: Databricks의 야구팀 실시간 의사결정 지원

스포츠 팀은 데이터와 AI를 경기 전 준비부터 실시간 의사결정, 그리고 장기 로스터 전략에 이르기까지 폭넓게 활용하고 있습니다. 야구를 예로 들면, 투구 하나, 타자 하나, 결정 하나로 정의되는 빠른 경기입니다. 타격 코치는 AI 어시스턴트로 당일 선발 투수의 구종 경향을 분석해 타자 미팅을 준비하고, 투수 코치는 멀티 에이전트 시스템으로 불펜 교체 시나리오를 경기 전에 미리 시뮬레이션합니다. Vector Search를 활용한 유사 투수 매칭으로 직접 데이터가 부족한 상대 선발에 대한 스카우팅 보고서를 생성하고, GM은 같은 레이크하우스 플랫폼에서 트레이드 대상 분석과 로스터 의사결정을 처리합니다.

경기 당일 오후 2시

Genie와 Unity Catalog를 활용한 타자 미팅

타자들이 비디오룸으로 들어섭니다. 코치는 30페이지 분량의 인쇄물을 원하지 않고, 오늘 선발 투수에 대한 명확한 계획을 원합니다.

그날 일찍, 분석가는 노트북 앞에 앉아 Unity Catalog 위에 구축된 Genie를 열었습니다. 이곳에는 일관된 스키마, 권한 및 계보를 가진 Statcast 및 팀 자체 테이블이 저장되어 있습니다. 분석가는 다음과 같이 질문했습니다.

“오늘 선발 투수의 첫 번째 투구 유형과 구종을 지난 두 시즌 동안 우리 우타자 및 좌타자들을 상대로 분석해 줘. 주자가 있을 때의 경향을 강조해 줘.”

Genie는 Unity Catalog 내의 관리되는 Delta 테이블에서 답변을 컴파일했습니다. 이 작업의 일환으로 분석가는 향후 계획 및 자동화된 에이전트에서 재사용할 수 있도록 카운트, 타자 성향, 주자 유무에 따른 경향과 같은 핵심 쿼리를 캡슐화하는 Unity Catalog SQL 함수 세트를 등록했습니다.

분석가는 결과를 간단한 한 페이지 보고서로 내보내 직원들이 인쇄하거나 타자 바인더에 포함할 수 있도록 했습니다. 주요 내용은 다음과 같습니다.

• 우타자: 초반, 특히 주자가 없을 때 높은 커터와 포심 패스트볼을 많이 던짐.
• 좌타자: 2루에 주자가 있을 때 체인지업과 싱커를 더 많이 던짐.
• 투 스트라이크: 대부분의 삼진 상황에서 슬라이더가 낮고 바깥쪽으로 형성됨.

타격 코치는 세 가지 명확한 논점으로 회의에 들어섭니다. 선수들이 타격 연습을 하러 갈 때쯤, 첫 두 번의 타석은 추측이 아니라 오늘 선발 투수가 실제로 어떻게 던지는지에 대한 공유된 관점에 기반합니다.

시리즈 전 불펜 준비

Agent Framework 및 Model Serving을 이용한 투구 교체 스크립팅

코칭 스태프는 대부분의 경기에서 선발 투수가 100구에 가까워지고 중심 타선이 나올 시점이 올 것이라는 것을 알고 있습니다. 싱커볼러와 슬라이더 우선 우완 투수 사이의 선택은 순간적으로 직감에 의존하는 것처럼 느껴질 수 있지만, 작업은 더 일찍 이루어집니다.

시리즈 전 라커룸에서 분석가는 Agent Bricks로 구축되고 Model Serving에 배포된 Multi-Agent Supervisor를 사용하여 코칭 스태프가 중요하게 생각하는 상황을 시뮬레이션합니다. 예를 들어 6회 중심 타선, 7회 하위 타선, 후반 이닝의 좌타자 집중 타석 등입니다.

각 결정에 대해 에이전트는 다음과 같은 작업을 수행합니다.

1. Unity Catalog의 조회 함수를 사용하여 관련 타자의 이름을 ID로 변환합니다.
2. 카운트, 타자 성향, 주자 유무에 따른 투구 유형 및 결과 계산 UC SQL 함수를 호출합니다.
3. 각 구원 투수의 구종을 해당 타자 그룹과 비교하고 어떤 프로필이 가장 효과적인지, 그리고 그 이유를 일반적인 야구 용어로 설명합니다.

분석가는 이를 짧은 불펜 카드로 만듭니다. 예를 들어:

• “이 세 타자가 나올 차례이고 선발 투수가 지쳐 있다면, 슬라이더 우선 우완 투수가 유리합니다. 그의 구종이 유사한 상황에서 어떻게 작용했는지 보여줍니다.”
• “하위 타선이 나올 차례라면, 싱커볼러의 땅볼 유도 능력이 더 자주 승리합니다. 이에 대한 증거를 제시합니다.”

코칭 스태프는 이 카드를 함께 검토합니다. 실제 6회 상황이 경기 중에 발생했을 때, 아무도 Databricks에 로그인하지 않습니다. 투수 코치는 몇 시간 전에 에이전트와 함께 압박 테스트를 거친 의사 결정 트리를 따릅니다.

후반 이닝 공격

동일한 에이전트 및 도구를 사용한 대타 결정 계획

8회 대타 결정도 같은 방식으로 연습됩니다.

경기 전 준비의 일환으로 분석가는 Databricks 에이전트에게 다음과 같이 요청합니다.

“이번 시리즈에서 만날 가능성이 있는 후반 이닝 구원 투수들에 대해, 예상 결과별로 우리 벤치 타자들의 순위를 매기고 각 타자가 더 나은 선택이 되는 경우를 설명해 줘.”

에이전트는 동일한 UC 함수와 Unity Catalog의 Delta 테이블을 호출하여 다음을 수행합니다.

• 각 구원 투수의 사용 패턴과 각 벤치 타자의 투구 유형, 구종, 카운트별 결과를 결합합니다.
• 1루와 2루에 주자가 있고 아웃카운트 1개이며 싱커를 주로 던지는 우완 구원 투수를 상대하는 등 가능한 후반 경기 시나리오를 시뮬레이션합니다.
• “X 구원 투수에 대해, 주자가 있을 때는 A 타자가 더 나은 프로필을 보이지만, 싱커를 주로 던질 때 주자가 없는 상황에서는 B 타자가 더 적합합니다.”와 같은 명확한 지침을 생성합니다.

분석가는 이러한 권장 사항을 감독의 경기 카드 또는 사전에 검토할 수 있는 작은 한 페이지 분량의 “대타 그리드”에 넣습니다. 경기가 시작되면 이 카드가 참조점이 됩니다. 감독은 이미 검토한 옵션 중에서 선택하며, 데이터는 경기장 내 장치 사용에 관한 리그 규정을 존중하는 형식으로 요약됩니다.

이동일

Vector Search 및 Unity Catalog를 이용한 사전 정찰

시리즈 사이의 휴식일에는 분석가가 단일 경기 전술에서 다음 경기로 전환합니다. 다가오는 두 선발 투수는 상대 타선과 직접적인 경험이 제한적입니다.

Genie로 돌아가서 분석가는 다음과 같이 질문합니다.

“우리 다가오는 선발 투수들의 구종 및 움직임 프로필과 가장 유사한 투수들을 찾고, 우리 타선이 해당 유사 투수들을 상대로 어떻게 타격했는지 보여줘.”

여기서 Genie는 작업의 일부를 Databricks Vector Search에 맡깁니다. 이전 처리에서 Unity Catalog에 저장된 투수 및 타자 임베딩은 인덱싱되어 시스템이 눈으로 추측하지 않고 “유사한 투수”를 찾을 수 있습니다.

워크플로우는 다음과 같습니다.

1. Genie는 Unity Catalog 테이블에서 새로운 선발 투수들의 투구 유형 및 움직임을 분석합니다.
2. Vector Search는 유사한 투구 프로필을 가진 투수를 찾습니다.
3. UC SQL 함수는 해당 유사 투수들을 상대로 타선 결과를 계산합니다.
4. Genie는 패턴을 타격 코치가 사용할 수 있는 스카우팅 보고서로 요약합니다.

직접적인 Statcast 기록이 부족할 때, Vector Search와 Genie의 조합은 코칭 스태프에게 “이런 유형의 투수들을 상대로 우리가 어떻게 타격했는지 보여준다”고 말하고 이를 시리즈 계획에 반영할 수 있는 방법을 제공합니다. 이러한 통찰력은 다음 원정 경기 회의를 위해 준비된 사전 보고서로 내보내집니다.

프런트 오피스 업무

Genie, Lakehouse 및 Lakebase를 활용한 GM 및 분석가

승리하는 시즌은 한 경기 이상으로 만들어집니다. GM과 분석가는 동일한 플랫폼을 사용하여 가치, 적합성 및 위험에 대한 결정을 내립니다.

Genie에서 그들은 다음과 같은 질문을 탐색합니다.

“우리 3선발 투수의 프로필이 우리 디비전의 상위 타선들을 상대로 카운트와 타자 성향별로 어떻게 작용하는지 보여줘. 그의 가치는 어디에서 오고, 우리는 어디에 노출되어 있나?”

“리그 전반의 좌타자들에 대해, 우리 디비전에서 후반 이닝에 투구되는 방식과 강점이 일치하는 선수들을 식별해 줘.”

이러한 질문은 Unity Catalog의 레이크하우스에서 직접 답변됩니다. 투구 수준 데이터, 임베딩 및 파생된 특징은 모두 한 곳에서 관리됩니다. Genie는 이를 자연어 답변으로 전환하지만, 내부적으로는 재사용 가능한 UC SQL 함수 로직이 여전히 사용됩니다.

한편, 코치, 스카우트 및 프런트 오피스가 사용하는 야구 운영 앱은 Lakebase Postgres를 기반으로 합니다. 이 앱에서는 다음이 수행됩니다.

• 스카우트가 잠재적인 트레이드 대상에 대한 보고서를 입력합니다.
• 코치가 경기 후 “6회에 중심 타선을 상대로 슬라이더 우선으로 갔다”와 같은 상위 수준의 결정을 태그합니다.
• GM이 트레이드, 연장 계약 및 로스터 변경에 대한 최종 결정을 기록합니다.

Lakebase Postgres가 Databricks 플랫폼의 일부이므로 앱 상태는 원본 데이터에 가깝게 유지됩니다.

• 앱 쓰기(보고서, 태그, 결정)는 Lakebase Postgres로 들어가 즉시 액세스 권한이 있는 분석가 및 에이전트에게 제공됩니다.
• 예약된 작업 또는 파이프라인은 Unity Catalog 테이블의 큐레이션된 슬라이스를 Lakebase Postgres로 게시하여 앱 UI가 수동 CSV 내보내기 없이 항상 최신 통계 및 기능을 갖도록 합니다.

결과는 공유된 기억입니다. 무슨 일이 일어났는지, 왜 일어났는지, 그리고 어떻게 정당화되었는지가 타임스탬프와 사용자 신원과 함께 한 곳에 저장됩니다.

이것이 경기를 승리로 이끄는 이유

• 더 현명한 로스터 베팅: 선수 이동이 리그, 특히 디비전 및 포스트시즌에서의 투구 방식과 일치합니다.
• 더 높은 품질의 타석: 타자는 일반적인 투구 방식이 아닌, 그 순간 투수가 실제로 던지는 것에 집중합니다.
• 더 명확한 불펜 매치업: 각 구원 투수의 최적 상황이 몇 초 안에 명확해져 시간 압박 속에서의 추측을 줄입니다.
• 중요한 순간의 낭비되는 투구 감소: 타자 및 카운트별 결정구 투구를 알면 깊은 카운트와 볼넷을 줄입니다.
• 더 나은 첫 번째 투구 결과: 예상 선택을 뒤집는 공격 계획은 팀의 조건에 따라 조기 타구를 만들어냅니다.

이 모든 것은 숫자가 정확할 때만 의미가 있습니다. 분산된 일회성 도구 대신 단일 거버넌스 레이크하우스에서 이러한 에이전트와 앱을 실행함으로써 클럽은 로직이 이미 수행 중인 작업과 일치함을 확인하고 중요한 부분에 이를 활용할 수 있습니다. 데이터가 특정 경기나 움직임을 가리킬 때, 블랙박스가 아닌 게임 계획의 확장처럼 느껴집니다.

Databricks Sports에 대해 자세히 알아보거나 데모를 요청하여 조직이 경쟁력 있는 인사이트를 어떻게 얻을 수 있는지 확인해 보세요.

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