[플레이데이터 SK네트웍스 Family AI 캠프 36기] 2nd 프로젝트 - 1일차 (2026.09.28)

Об этом предложении

[플레이데이터 SK네트웍스 Family AI 캠프 36기] 단위 2차 팀 프로젝트 1일차 (2026.09.28) 팀 프로젝트 1일차 📖 오늘 학습 내용 프로젝트 주제 선정 (League of Legends 플레이어 이탈 위험 예측) 시장조사 (국내 게임산업, League of Legends 영향력) 기존 서비스 조사 (OP.GG, FOW.KR, YOUR.GG) 문제 정의와 이탈(Churn) 정의 프로젝트 입력/출력 구조 GitHub 협업 구조 설계 프로젝트 첫날에는 바로 모델을 만드는 게 아니라 무엇을 예측할 것인지, 왜 이 프로젝트가 필요한지, 어떤 데이터를 사용할지 를 먼저 정의했다. 프로젝트 주제 선정 → 시장조사 → 기존 서비스 조사 → 문제 정의 → 이탈 기준 정의 → 프로젝트 요구사항 정리 → 팀원 역할 분담 → GitHub 협업 구조 설계 1. 프로젝트 주제 — League of Legends 플레이어 이탈 위험 예측 프로젝트의 핵심 목적은 League of Legends 사용자의 과거 경기 기록을 분석해서 앞으로 일정 기간 동안 게임 활동이 중단될 가능성이 높은 사용자를 미리 찾아내는 것이다. 사용자 A: 최근에도 계속 게임함 → 위험 낮음 사용자 B: 최근 게임 횟수 감소, 경기 간격 증가, 최근 활동일 감소 → 위험 증가 사용자 C: 마지막 경기 이후 오랜 시간 경과 → 위험 높음 즉 사용자의 과거 경기 행동을 이용해서 "이 사용자가 앞으로 게임을 하지 않을 가능성이 높은가?"를 예측한다. 왜 이런 프로젝트를 하는가 : 게임 운영 담당자가 사용자 10명 정도는 직접 확인할 수 있지만, 1,000명/10,000명/100,000명이 되면 모든 사람을 직접 살펴보기 어렵다. 그래서 모델이 위험도가 높은 사용자부터 낮은 사용자 순으로 정렬해주는 것이다. 프로젝트에서 제공하려는 결과 : 단순히 "이탈 O/X"만 보여주는 게 아니라, 사용자 → 이탈 위험 Score → 위험 Ranking → 주요 영향 Feature → 운영자가 우선 확인하는 흐름으로 이어진다. "누구를 먼저 봐야 하는가"와 "왜 이 사용자가 위험하다고 판단되었는가"를 함께 제공하는 게 목표다. 2. 시장조사 프로젝트의 필요성을 확인하기 위해 국내 게임시장과 League of Legends의 영향력을 조사했다. 국내 게임산업 : 조사 자료 기준 2024년 국내 게임산업 매출은 23조 8,515억 원이고, 이 중 PC 게임 시장은 6조 94억 원 규모다. PC 게임은 여전히 상당한 규모를 가지고 있다. League of Legends : 조사 시점 기준 LoL의 국내 PC방 사용시간 점유율은 34.37%로 전체 1위였다. 쉽게 생각하면 조사된 PC방 게임 이용시간 중 약 3시간 중 1시간 정도를 LoL이 차지한다고 볼 수 있다. 주의할 점 : "PC방 점유율 34.37%"가 "한국인의 34.37%가 LoL을 한다"는 뜻은 아니다. 정확히는 조사된 PC방 전체 게임 사용시간 중 LoL이 차지하는 비율 이다. PC방 점유율 ≠ 전체 이용자 비율 ≠ 월간 활성 사용자 수 ≠ LoL 전체 사용자 수라는 점을 명확히 구분해야 한다. 왜 LoL을 분석 대상으로 선택했는가 : LoL은 장기간 서비스되고 있는 게임이라 신규 사용자 확보뿐 아니라 기존 사용자 유지, 휴면 사용자 관리, 재활성화도 중요할 수 있다. 또한 Riot API를 이용하면 경기 횟수, 경기 시각, 승패, KDA, 챔피언, 게임 모드, 게임 시간, Gold, CS, Damage, Vision 같은 실제 경기 데이터를 수집할 수 있어서, 단순 설문조사가 아니라 실제 게임 플레이 기록을 기반으로 사용자의 행동 변화를 분석 할 수 있다. 3. 기존 서비스 조사 대표적인 LoL 서비스로 OP.GG, FOW.KR, YOUR.GG 등이 있다. 이런 서비스는 주로 전적, 승률, KDA, 챔피언 통계, 아이템 Build, Rune, Tier, 경기력, 플레이 스타일 등을 보여준다. 질문으로 바꾸면 "이 사용자가 지금까지 게임을 어떻게 했는가?"를 설명하는 서비스다. 우리 프로젝트의 질문은 조금 다르다 — "이 사용자가 앞으로 게임을 하지 않을 가능성이 높은가?" 기존 전적 서비스 우리 프로젝트 최근 경기 결과 최근 경기 수 변화 현재 승률 승률 변화 KDA 평균 KDA 및 변화 챔피언 통계 챔피언 다양성 현재 상태 미래 활동 가능성 경기력 분석 이탈 위험 분석 개인 실력 개선 위험 사용자 선별 4. 프로젝트 문제 정의 운영 담당자의 문제를 다음과 같이 가정했다. 사용자가 많음 → 모든 사용자의 여러 지표를 사람이 직접 확인하기 어려움 → 누구를 먼저 관리해야 할지 우선순위 결정 필요 → Machine Learning Model → Risk Score → 위험 사용자 Ranking 이탈이란? : 이 프로젝트에서 가장 중요한 부분이다. 일반적으로 이탈이라고 하면 회원 탈퇴, 게임 삭제, 계정 삭제 같은 걸 떠올리지만, Riot API에서는 이런 정보를 직접 확인할 수 없다. 그래서 게임 경기 기록을 이용해 이탈을 정의 했다. 초기 이탈 정의 : 프로젝트 초기에는 "과거 30일 경기 기록 → 향후 14일 동안 경기 없음 → 이탈"이라는 기준도 검토했지만, 진행하면서 최종 기준을 다시 정의했다. 최종 이탈 정의 : 기준일 이후 30일 동안 분석 대상 게임 모드에서 경기 기록이 없는 상태 를 이탈로 정의했다. 기준일 T 과거 │ 미래 ───────────────────●──────────────────── │ 이후 30일 확인 │ ┌────────┴─────────┐ ↓ ↓ 경기 0회 경기 1회 이상 churn = 1 churn = 0 여기서 매우 중요한 점 : 우리 프로젝트에서 쓰는 churn 은 계정 탈퇴, 회원 탈퇴, 게임 완전 삭제, 로그인 중단, 영구적인 게임 중단이 아니다 . 정확히는 "기준일 이후 30일 동안 대상 게임의 경기 기록이 없음"이라는 의미다. 그래서 발표할 때도 "30일 무경기 상태" 또는 "게임 활동 휴면 위험"처럼 설명하는 게 더 정확하다. 5. 프로젝트 입력과 출력 입력 : 사용자의 과거 경기 기록으로부터 만든 행동 Feature를 사용한다 — 최근 7일 경기 수, 최근 30일 경기 수, 마지막 경기 이후 경과일, 평균 경기 간격, 승률, KDA, 연패, 게임 모드, 챔피언 다양성 등. 출력 : 사용자별 Risk Score, 위험 Ranking, High Risk 사용자, 주요 영향 Feature를 제공한다. 프로젝트 전체 구조 : Riot Games API → Player/Match Data → 전처리 → Feature Engineering → Machine Learning → Risk Score → 위험 사용자 Ranking → Dashboard 6. GitHub 협업 구조 설계 여러 명이 하나의 프로젝트를 동시에 수정하면 문제가 생길 수 있다. A가 collector.py를 수정하고 B도 collector.py를 수정하고 C가 dashboard를 수정하는 작업을 모두 main 에서 하면 충돌 위험이 커진다. 그래서 기능별 Branch를 사용했다. main └── develop ├── feature/data-collection ├── feature/data-analysis ├── feature/churn-model └── feature/dashboard Branch 역할 main 최종 발표·배포 가능한 버전 develop 각 기능을 합쳐 검증 feature/data-collection Riot API 및 데이터 수집 feature/data-analysis 전처리, EDA, Feature 생성 feature/churn-model 모델 학습 및 평가 feature/dashboard Web / Dashboard 왜 사람 이름으로 Branch를 만들지 않았는가 : feature/hyowon , feature/minsu 처럼 사람 이름이 아니라 feature/data-analysis , feature/churn-model 처럼 기능 기준으로 나눴다. 담당자가 바뀌더라도 이 Branch가 무슨 일을 하는지 알 수 있기 때문이다. Git 작업 순서 : # 작업 시작 git switch feature/담당브랜치 git pull origin feature/담당브랜치 # 작업 후 git status git add . git commit -m "feat: 작업 내용" git push origin feature/담당브랜치 기능 완료 흐름: feature Branch → Pull Request → develop → 통합 Test → Pull Request → main GitHub 협업 원칙 : main에 바로 Push하지 않기 develop에서 개인 작업하지 않기 담당 Feature Branch에서 개발 작업 전 Pull 의미 있는 단위로 Commit 기능 완료 후 PR develop에서 통합 확인 최종적으로 main 반영 핵심 정리 [시장조사] 국내 게임시장과 LoL의 영향력 확인 ↓ [문제 발견] 많은 사용자를 운영자가 직접 관리하기 어려움 ↓ [프로젝트 목표] 향후 게임 활동을 하지 않을 가능성이 높은 사용자 탐지 ↓ [최종 이탈 정의] 기준일 이후 30일 동안 경기 기록 0회 ↓ [결과] Risk Score, 위험 Ranking, 영향 Feature ↓ [개발 방식] 기능별 Git Branch를 이용한 팀 협업