서론
데이터 엔지니어링을 학습하기로 하고, 항상 기술 관련 공부는 프로젝트를 진행하면서 많이 배웠기 때문에 사이드 프로젝트를 진행하자고 생각했다. 학습과 병행하려면 시간이 좀 걸리겠지만 나름의 기준을 가지고 선택하고자 했다.
프로젝트 목표
Steam에서 서비스 중인 온라인 게임 중 `이터널 리턴`이라는 게임이 있다. 3인이 1팀으로 배틀로얄 게임을 진행하는 게임으로 전반적인 플레이 및 스킬이 MOBA 장르에서 가져왔고, 팀이 어떤 전략을 취하냐가 게임에서 중요한 요소가 된다.

MOBA 장르에서 기반한 것이 많다보니 캐릭터별 상성이 존재하고, 상성을 팀으로 어떻게 극복하냐가 중요해진다. 특히 3인이라는 적은 인원으로 팀을 구성하는 만큼 캐릭터를 조합하여 강한 팀을 만들어야 1등 할 가능성이 높아지는 게임이다.
그래서 내가 하는 주로 선택하는 캐릭터나 친구와 조합을 이룰 경우 어떤 캐릭터 간의 시너지를 낼 수 있는지 파악하는 것이 중요하다. 이것을 데이터를 통해 실제로 플레이 하는 게임에 어떤 조합이 유리한지, 현재 어떤 조합이 유행하는지 파악하는 서비스를 목표로 진행하고자 한다.
프로젝트 선정 이유
데이터 도메인 이해도
데이터로 프로젝트 결과를 낼 수 있을 정도면 어느 정도 데이터에 대한 이해가 있어야 한다고 생각했다. 그래서 나랑 친구랑 했던 게임 중에서 고르며, 어느 정도 즐기며 이해도가 있고 결과를 도출하고 확인할 수 있는 주제를 선정하고자 했다.
그리고 학습와 병행하며 진행해야 하기 때문에 동시에 분석 등에 대한 결과에 확신을 가질 수 없었다. 그래서 데이터에서 분석 결과를 도출하였을 때, 그 결과를 이해할 수 있을지 판단할 필요가 있었다. 결과적으로 프로젝트가 성공적인지 판단할 수 있는 주제를 찾았다.
데이터 수집 편의성
데이터와 관련해서 어느 정도 수집의 편의성을 추구하고자 했다. 크롤링을 기반으로도 데이터 수집이 충분히 가능하지만, 이미 백엔드 프로젝트를 진행하면서 크롤링을 몇 번 진행했다. 그래서 학습을 목표로 크롤링에 비용면에서 큰 공을 들이기보단 데이터 엔지니어링이라는 새로운 분야에 학습을 목표로 진행하고 싶었다.
이런 면에서 이터널 리턴은 별도로 개발자 API를 제공하고 있으며, 생각보다 게임 결과에서 다양한 내용에 대해 데이터를 제공해줬다. 수집할 수 있는 데이터의 양이 상세한 만큼 처음엔 간단하게 구성할지라도 추가적으로 다양한 기능을 추가하는 방향으로 나아갈 수 있을 것이라고 생각했다.
운영 중인 서비스
이터널 리턴 개발자 API에서 주목한 점은 실제로 운영 중인 서비스에서 다양한 데이터를 제공하고 있다는 점이다. 매일 유저들이 게임을 하면서 데이터가 추가되고, 주 단위에서 시즌 단위로 패치가 진행되면서 환경 변화가 진행된다는 점은 데이터를 지속적으로 수집하기 좋다고 생각했다. 서비스 기간을 길게 잡을수록 환경 변화 및 데이터 변화에 따른 결과 추이를 지켜볼 수 있다고 생각했다.
프로젝트 세부 기획
제 1 목표는 결국 데이터를 수집, 변환, 적재의 3단계를 완성하는 것으로 두고 있다.
- 캐릭터 선택에 따라 다른 캐릭터 간의 승률을 제공한다. 총 3명의 팀을 이루는 만큼 선택하는 선택한 캐릭터 수에 따라 각각 다른 조합 추천을 진행한다.
- 각 조합 추천에 따른 1 근거로 승률을 제공한다.
추가적으로 가능하거나 프로젝트 및 서비스가 운영이 진행되면 다음 목표를 가진다.
- 수집한 데이터를 기반으로 승률 이외에 추가적인 정보를 제공한다.
- 캐릭터별로 승률 이외에 지표를 다양하게 나눠서 통계를 제공한다.
- 데이터가 쌓임에 따라 패치 및 시즌 변화에 따른 정기적인 메타나 통계를 공시한다.
예상되는 어려움
데이터 저장량
게임 결과 레코드가 상세한 데이터를 제공하는 것은 좋으나, 내가 필요로 하는 데이터만 따로 제공하진 않는다. 그리고 차후 추가 기능이 추가됨에 따라 기존 데이터 / 원본 데이터 참조가 발생할 가능성이 있다. 그래서 이에 어느 정도 사이즈의 데이터가 저장될 예정이며, 기능 추가에 따라 너무 오래되지 않은 데이터는 재참조할 수 있어 즉시 삭제가 불가능하다. 이에 비용 문제가 발생할 가능성이 크며, 이를 해결하는 것이 큰 목표 중 하나가 될 것으로 예상하고 있다.
단순 접근으로 접근할 수 없는 목표 데이터
목표를 선정하면서 수집할 수 있는 API를 살펴보았는데, 목표로 하는 게임 데이터를 단순히 취득하긴 힘들어 보인다. 특히 지표가 시간, 순위, 점수 반영 여부 등 단순 게임 데이터를 취득해서 나올 수 있는 것은 아니라고 본다. 그리고 단순히 ID 값 입력을 통해 얻기에는 실제로 사용하지 않을 데이터를 수집하는데 비용을 쓰기 어렵다. 그렇기에 이에 대한 고민이 필요할 것 같다.
API Call 제한
게임 API는 과부하 방지를 위해 요청에 대한 제한을 두고 있다. 개인 Key의 경우 RPM을 1개로 제한하고 있고 이는 곧 서비스가 중단되는 시간 1초 1초가 데이터를 늦게 끌어온다는 의미가 된다. Prod Key를 가져오는 것도 방법이지만 당장 프로젝트가 어느 정도의 결과물이 나오기 전까진 개인 Key를 활용해야 할 것으로 보인다. 그래서 특히 앞선 문제였던 목표 데이터 접근도 횟수 제한 내에서 충분히 원하는 결과를 얻을 수 있도록 고민이 필요하다.
차후 학습 목표
우선 데이터 수집이 이뤄져야 한다고 생각하기 때문에 전체적인 아키텍처와 데이터 수집을 목표로 진행할 예정이다. 생각 중인 내용으론 아래와 같은 학습을 선행으로 생각 중에 있다.
1. AWS S3 / AWS EC2
1초가 곧 데이터 1개가 될 가능성이 있으므로, 상시로 동작할 인스턴스를 구상할 필요가 있다. 데이터 저장의 경우 생각보다 큰 데이터 용량이 필요하기 때문에 오브젝트 스토리지로 진행할 예정이고, 이에 대한 학습을 고려중에 있다.
2. Iceberg
단순 S3 데이터를 저장해도 무방하나, 생각보다 데이터가 커서 이를 관리할 방법으로 고려중에 있다.
3. Airflow
전체적인 작업을 오케스트레이션하기 위해 들어갈 예정이었는데, 결국 수집 Workflow부터 관리해야 하기 때문에 Airflow도 우선적으로 학습 및 도입을 진행할 필요가 생겼다. 수집 관련 Workflow 정립 이후 변환과 적재 관련 작업에 대한 Workflow를 추가하는 방식으로 진행할 예정이다.
'이터널 리턴 조합 사이트 개발 일지' 카테고리의 다른 글
| 이터널 리턴 조합 분석 사이트 개발 - 아키텍처 설계 (0) | 2025.09.14 |
|---|