바운더리 그래프: 그래프 렌즈로 IPL 탐험하기

시즌 전 시즌

ICC T20 월드컵이 2월부터 3월 첫째 주까지 한창일 때는 국가대표팀, 경기 방식, 그리고 세계 무대에서 녹아웃 스테이지에 대한 관심이 집중되죠. 그리고 자연스럽게, 이 관심은 곧바로 프랜차이즈에 대한 충성심으로 이어져요. 스쿼드 구성 마감일이 다가오고, 단톡방에서는 누가 오프닝을 맡고 어떤 선수가 임팩트 플레이어가 될지에 대한 토론이 활발해지면서, 이런 질문이 다시 떠오르죠. "올해는 우리 팀이 드디어 우승 트로피를 들어올릴 수 있을까?" Indian Premier League (IPL)은 개막일 밤에 시작하는 게 아니에요. 예상보다 몇 주나 더 일찍 시작하는 거죠.

IPL 2026이 코앞으로 다가오면서, 저는 단순한 점수표나 타율을 넘어선 질문을 던지게 되었어요.

IPL을 딱딱한 숫자가 아니라 살아있는 관계로 탐색할 수 있다면 어떨까요?

이 질문은 결국 Boundary Graph라는 프로젝트로 이어졌어요. 이 프로젝트는 Neo4j를 사용해서 IPL 데이터를 탐색하기 위해 만들어졌는데, 전통적인 테이블이나 대시보드가 아니라 그래프 사고방식을 활용했죠.

왜 또 다른 IPL 프로젝트일까요?

IPL 데이터는 정말 흔하죠. 스코어카드, 순위표, 시즌 요약 같은 것들이 깔끔하게 정리되어서 끊임없이 소비되고 있어요. 하지만 이런 자료들은 대부분 "뻔한" 질문에 대한 답을 제시하는 데 집중되어 있죠.

• 누가 가장 많은 득점을 올렸나?
• 어느 팀이 가장 많은 경기에서 승리했나?
• 누가 6점을 가장 많이 쳤나?

하지만 이런 질문들은 "관계형" 질문에는 약한 모습을 보여요.

• 특정 선수가 시즌 내내 특정 투수를 꾸준히 압도하는 경우는 누가 있을까?
• 경기장은 팀 전체의 타격 패턴에 어떤 영향을 미칠까?
• 선수, 팀, 시즌, 경기 상황을 연결하면 어떤 숨겨진 관계가 드러날까?

이런 질문들은 단순한 집계가 아니라, "사이"에 대한 질문인 거죠.

바로 이럴 때 그래프가 빛을 발하는 거예요.

Boundary Graph의 의도

Boundary Graph는 명확한 의도를 가지고 만들어졌어요.

Graph Database, 특히 Neo4j가 IPL과 같은 스포츠 데이터에 얼마나 자연스럽게 잘 맞는지 보여주는 거죠.

Boundary Graph는 IPL을 행과 열로 취급하는 대신, 네트워크로 취급해요.

• 팀에 연결된 선수
• 시즌에 연결된 팀
• 경기장에 연결된 경기
• 타자, 투수, 결과를 연결하는 공 하나하나

이런 식으로 크리켓을 모델링하면 탐색이 정말 직관적이 돼요. 더 이상 데이터를 쿼리하는 게 아니라, 스토리를 탐험하는 거죠.

각 선수는 자신의 커리어 스토리를 전달하고, 각 팀은 시즌별 스토리를 전달하며, 각 경기는 수백 개의 연결된 순간으로 이루어진 독립적인 스토리가 되는 거예요.

그래프는 이런 스토리를 저장할 뿐만 아니라, 서로 어떻게 교차하는지도 보여줘요.

Neo4j 선택: 테이블 대신 그래프

전통적인 관계형 데이터베이스는 구조와 일관성을 강화하는 데 탁월하죠. 하지만 IPL 데이터는 본질적으로 "연결"되어 있고 "계속 진화"하고 있어요. 단일 경계를 생각해 볼까요?

• 시즌 중
• 팀을 위해 플레이

관계형 모델에서 이런 다양한 차원에 대한 질문에 답하려면 여러 번의 JOIN 연산, 복잡한 쿼리, 그리고 성능 튜닝이 필요하죠.

하지만 Neo4j에서는 이런 관계들이 동등한 자격을 갖는 요소가 돼요. "JOIN"하는 대신, 그냥 "그래프를 따라가는" 거죠.

이런 디자인 선택이 Boundary Graph를 근본적으로 바꿔놓은 거예요.

IPL을 그래프로 모델링하기

Boundary Graph의 핵심에는 의도적으로 단순하면서도 표현력이 풍부한 스키마가 있어요. 스코어카드에 요약된 방식이 아니라, 실제로 크리켓이 공 하나하나 어떻게 플레이되는지를 반영하는 스키마인 거죠.

모든 것을 단순하게 집계하는 대신, 이 모델은 "공 하나하나"를 동등한 자격으로 취급하고, 이를 통해 선수, 팀, 오버, 경기 간의 관계가 자연스럽게 드러나도록 만들었어요.

핵심 Node (주요 속성 포함)

• 플레이어 (Player_ID, 이름, 역할, 성별, 파업률): 시즌과 팀을 넘나들며 개별 크리켓 선수를 나타내요.
• Team (프랜차이즈_ID, 현재_이름, 기존_이름, 팀_유형): IPL 프랜차이즈, 이름 변경, 팀의 진화를 설명해요.
• 성냥 (Match ID, 날짜, 경기 유형, 승자, 결과 유형, 결과_마진): 최종 결과와 맥락을 포함하는 단일 IPL 경기 설비에요.
• 계절 (시즌, 연도): 시즌 간 분석이 가능하도록 명시적으로 모델링된 IPL 시즌이에요.
• 장소 (장소, 도시): 경기가 진행되는 경기장으로, 위치별 추세를 파악할 수 있어요.
• 이닝 (Innings_id, 이닝_번호, target_runs, target_overs): 경기에서 목표 추적 및 목표 설정 분석에 중요한 논리적 파티션이에요.
• Over (over_id, over_number, ball_per_over): 파워플레이나 데스 오버 같은 단계를 분석하기 위한 Over 레벨 그룹이에요.
• Delivery (delivery_id, delivery_number, runs_total, is_boundary, is_six, is_wicket, extras_type): 가장 작고 강력한 분석 단위, 즉 공 하나하나를 의미하죠.
• Official (name, role, review_umpire): 경기와 관련된 경기 임원과 심판을 나타내요.

주요 관계 (컨텍스트 속성 포함)

• (:Player)-[:PLAYS_FOR {season, position}]->(:Team): 특정 시즌의 선수-팀 연결과 역할을 캡처해요.
• (:Team)-[:PART_OF_SEASON]->(:Season)
• (:Match)-[:PLAYED_AT]->(:Venue)
• (:Match)-[:HAS_INNINGS]->(:Innings)
• (:Innings)-[:HAS_OVER]->(:Over)
• (:Over)-[:HAS_DELIVERY]->(:Delivery)
• (:Player)-[:BATTED {runs_batter, 4, 6, dots}]->(:Delivery)
• (:Player)-[:BOWLED {runs_conceded, wickets, economy}]->(:Delivery)
• (:Team)-[:BATTED_IN]->(:Match)
• (:Team)-[:BOWLED_IN]->(:Match)
• (:Official)-[:OFFICIATED]->(:Match)

Boundary Graph 데이터 모델

Delivery 레벨 모델링이 왜 중요할까요?

• 특정 투수를 상대로 타자의 경계 패턴을 파악할 수 있어요.
• Over나 Match 단계에 따라 득점 방식이 어떻게 변하는지 알 수 있죠.
• 여러 시즌에 걸쳐 경기장별 공격성 추세를 분석할 수 있어요.

득점, 경계 유형 (4 또는 6), 추가 득점, 결과 같은 컨텍스트는 Delivery와 해당 관계의 속성으로 저장돼요. 불필요하게 Node가 늘어나는 걸 막으면서 모델의 유연성을 유지하는 거죠.

이 구조 덕분에 과도하게 복잡해지지 않으면서도 의미가 풍부하고, 시간 흐름을 인지하며, 탐색하기 쉬운 그래프를 유지할 수 있어요.

Neo4j Browser와 Bloom 시각화는 이런 연결을 바로 보여줘서 복잡한 Join을 직관적이고 탐색 가능한 네트워크로 바꿔준답니다.

데이터 소스: 그래프는 어디서 시작될까요?

그래프는 기반이 되는 데이터만큼 유용하죠. Boundary Graph는 공개적으로 사용 가능한 IPL 공별 및 경기 레벨 데이터 세트를 사용해요. 여기에는 다음과 같은 정보가 들어있죠.

• 경기 메타데이터 (시즌, 팀, Venue)
• Delivery 레벨 세부 정보 (타자, 투수, 득점, 추가 득점)
• 결과 (경계, 아웃)

데이터 수집 과정은 이렇습니다.

1. 원시 JSON/CSV 데이터를 정리하고 정규화해요 (Cricsheet).
2. Node에 항목을 매핑해요 (Player, Team, Match).
3. 실제 크리켓 상호 작용을 반영하는 Relationship을 만들어요.
4. 상황별 속성으로 Relationship을 강화해요.

이 파이프라인을 통해 데이터가 Neo4j에 입력되면 단순히 저장된 정보가 아니라 연결된 시스템으로 즉시 쿼리할 수 있게 되는 거죠.

중요한 점은 수집 파이프라인이 증분적이고 반복 가능하도록 설계되었다는 거예요. 새로운 IPL 경기가 열리고 새로운 데이터를 사용할 수 있게 되면, 파이프라인을 다시 실행해서 기록 데이터를 재처리하지 않고도 새로운 시즌, 경기, Delivery를 기존 그래프에 매끄럽게 통합할 수 있어요. 덕분에 Boundary Graph는 미래 지향적이고 토너먼트가 진행됨에 따라 계속 발전할 수 있답니다. 데이터 가져오기 스크립트는 에서 확인해 보세요.

데이터 수집 파이프라인

Cypher로 더 나은 질문을 던져보세요

그래프가 준비되면 그래프 쿼리 언어인 Cypher가 탐험의 언어가 된답니다. 복잡한 SQL Join을 작성하는 대신, 쿼리가 자연스러운 질문에 더 가깝게 읽히는 거죠.

• 특정 팀을 상대로 꾸준히 득점하는 타자를 보여주세요.

MATCH (batter:Player)-[:BATTED]->(d:Delivery)<-[:HAS_DELIVERY]-(o:Over)
MATCH (o)<-[:HAS_OVER]-(:Innings)<-[:HAS_INNINGS]-(m:Match)
MATCH (bowlingTeam:Team)-[:BOWLED_IN]->(m)
WHERE bowlingTeam.current_name = "Mumbai Indians"
  AND d.is_boundary = true
RETURN batter.name AS batter,
       COUNT(d) AS boundary_count
ORDER BY boundary_count DESC
LIMIT 10;

• 여러 시즌에 걸쳐 공격적인 타격을 선호하는 Venue는 어디인가요?

MATCH (v:Venue)<-[:PLAYED_AT]-(m:Match)
MATCH (m)-[:HAS_INNINGS]->(:Innings)-[:HAS_OVER]->(:Over)-[:HAS_DELIVERY]->(d:Delivery)
MATCH (m)-[:PART_OF_SEASON]->(s:Season)
WHERE d.is_boundary = true
RETURN v.venue AS venue,
       s.season AS season,
       COUNT(d) AS total_boundaries
ORDER BY total_boundaries DESC;

• 팀이 바뀌면서 선수의 경계 패턴은 어떻게 발전했나요?

MATCH (p:Player)-[:PLAYS_FOR]->(t:Team)
MATCH (p)-[:BATTED]->(d:Delivery)
MATCH (d)<-[:HAS_DELIVERY]-(:Over)<-[:HAS_OVER]-(:Innings)<-[:HAS_INNINGS]-(m:Match)
WHERE d.is_boundary = true
RETURN p.name AS player,
       t.current_name AS team,
       COUNT(d) AS boundaries
ORDER BY player, boundaries DESC;

Cypher의 패턴 매칭 구문은 의도를 명시적으로 만들어줘요. 여러분은 how 테이블을 서로 연결하는지가 아니라, what을 탐색하고 싶은지를 설명하는 거죠. 이러한 명확성 덕분에 Neo4j는 탐색적 스포츠 분석에 정말 적합해요.

Graph에서 인터페이스까지

Boundary Graph는 단순한 데이터베이스 실험이 아니라 바로 사용할 수 있는 애플리케이션이에요. 프론트엔드는 다음에 중점을 두고 있죠.

• 깔끔하고 방해받지 않는 탐색
• IPL 테마의 영상
• 원시 통계보다는 통찰력 강조

백엔드는 API를 통해 그래프 기반의 쿼리를 노출해서 모든 상호 작용이 관계 중심 논리에 의해 뒷받침되도록 하고 있어요.

그 결과 통찰력이 느껴지는 경험이 탄생했는데, 이건 것이 아니라 된 거죠.

대시보드에서 대화까지: Ask BG 소개

Boundary Graph가 점점 발전하면서 한 가지 깨달음이 더 명확해졌어요. 그래프 기반 IPL 시스템은 시각적 탐색에서 끝나면 안 된다는 거죠.

대시보드는 에 적합하지만, IPL 팬덤과 스포츠 분석은 일반적으로 호기심, 논쟁, "만약에" 시나리오를 통해 성장하잖아요? 그래서 자연스럽게 프로젝트의 다음 단계로 이어지게 되었어요.

Ask BG: Natural Language에서 IPL Query로

Ask BG는 Boundary Graph를 읽기 전용 대시보드에서 대화형 쿼리 가능 어시스턴트로 바꿔줄 예정인 기능이에요.

아이디어는 간단하지만 정말 강력하죠.

만약 일반 영어로 IPL 질문을 하고 텍스트와 그래프 답변을 얻을 수 있다면 어떨까요?

Ask BG는 다음과 같은 질문들을 처리하도록 만들어졌어요.

• "Wankhede에서 왼손잡이 페이스를 상대로 가장 좋은 성적을 낸 타자는 누구야?"
• "팀을 바꾸기 전과 후 선수의 경계 패턴을 보여줘"
• "역사적으로 플레이오프에서 추격팀에게 유리한 경기장은 어디야?"

내부적으로 Ask BG는 Natural Language를 하나 이상의 Cypher Query로 변환해서 Neo4j에 대해 실행하고, 그래프로 직접 뒷받침되는 근거 있고 설명 가능한 답변을 반환해요.

이건 경험을 클릭을 통한 탐색에서 대화를 통한 탐색으로 바꿔주는 거죠.

Ask BG 기능: 곧 출시 예정

Query를 넘어서: Graph가 IPL 2026을 예측할 수 있을까요?

Graph로 모델링된 Delivery 레벨의 기록 데이터를 통해 다음 논리적인 질문은 "무슨 일이 있었나"가 아니라 "무슨 일이 일어날까"가 되는 거죠.

Ask BG는 다음과 같은 실험의 문을 열어줄 거예요.

• 과거 매치업을 기반으로 한 팀 성과 예측
• 장소에 따른 득점 기대치
• 시즌 및 역할 전반에 걸친 플레이어 영향 분석

특히 흥미롭고 의도적으로 야심 찬 아이디어 중 하나는 바로 이거예요.

Boundary Graph는 과거 Graph 패턴을 사용해서 IPL 2026 우승자를 예측할 수 있을까요?

예측을 블랙박스 Machine Learning 문제로 취급하는 대신, Graph는 다음을 가능하게 해요.

• 투명한 특징 추출 (관계, 패턴, 종속성)
• 설명 가능한 추론 경로 (팀이 선호되는 이유)
• 도메인 직관에 기반한 반복적인 가설 테스트

예측이 궁극적으로 맞는지 틀린지는 중요하지 않아요. 중요한 건 Graph 기반 시스템이 어떻게 탁월한 추론을 도출해내느냐죠.

앞으로 몇 주 안에 Ask BG 및 관련 기능을 출시하고 Boundary Graph를 정적인 시각화 도구에서 대화형 Graph 기반 추론 시스템으로 확장할 예정이니, 계속해서 업데이트를 지켜봐 주세요!

Boundary Graph는 오픈 소스이며 에서 사용할 수 있어요. Neo4j, Graph 모델링 또는 스포츠 분석에 대해 궁금하다면 여기가 시작하기에 좋은 곳일 거예요.

GitHub – sidagarwal04/boundary-graph: Boundary-Graph는 Neo4j Knowledge Graph를 기반으로 구축된 IPL 데이터용 풀스택 크리켓 분석 플랫폼이에요. Nuxt.js 대시보드, FastAPI 기반 백엔드, 공별 Graph 분석 기능을 갖추고 있어서 시즌 전반에 걸쳐 선수 성과, 팀 역학, 경계 패턴 및 일대일 통찰력을 탐색할 수 있죠.

---

• AI 에이전트
• ipl

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지