Data Lab

Game Data Project #16 - 게임 중심 Web Dashboard로 데이터 연결하기

패치노트 수집과 번역·요약 기능을 만들면서 프로젝트에는 점점 여러 종류의 데이터가 쌓이기 시작했다.지금까지 확보한 데이터는 크게 다음과 같았다.게임 기본 정보동접자 시계열공식 패치노트패치 번역패치 요약각 기능은 개별적으로 동작하고 있었지만, 데이터를 실제로 확인하려면 각각의 API나 DB를 따로 살펴봐야 했다.그래서 이번 단계에서는 새로운 수집 기능을 추가하기보다, 지금까지 쌓인 데이터를 게임 단위로 한 화면에서 확인할 수 있는 Web Dashboard를 만드는 데 집중했다.이번 작업의 목표는 공개 서비스 수준의 웹사이트를 만드는 것이 아니다.현재 프로젝트에서 필요한 것은 다음과 같은 운영용 Viewer에 가깝다.게임 선택 ↓게임 상세 ├─ 현재 동접자 ├─ 최근 동접자 추이 └─ ..

Route → Service → Repository - 왜 백엔드 코드를 굳이 나눌까?

백엔드 코드를 처음 작성할 때는 요청을 받고, DB를 조회하고, 값을 수정하고, 결과를 반환하는 모든 과정을 하나의 함수 안에 작성하는 것이 가장 자연스럽다.예를 들어 내부 Admin에서 어떤 항목의 이름을 수정하는 기능을 만든다고 해보자.@app.post("/items/update")def update_item(): item_id = request.form["item_id"] item_name = request.form["item_name"] conn = get_connection() cursor = conn.cursor() cursor.execute( """ UPDATE items SET name = %s WHERE id =..

Game Data Project #15 - 패치노트 Web Viewer와 PUBG 공식 소스 연동

지난 #14에서는 game_patches에 모인 패치노트를 대상으로 LLM 기반 번역과 요약 파이프라인을 구축했다.데이터는 이미 다음 단계까지 준비되어 있었다. 패치 수집→ game_patches 정규화→ 번역→ 요약→ game_patch_processing 저장 하지만 결과를 확인하려면 여전히 DB를 직접 조회해야 했다.이번 단계의 첫 번째 목표는 이 데이터를 사람이 실제로 읽을 수 있는 패치노트 Web Viewer로 만드는 것이었다.개발 과정에서 PUBG의 Steam 패치 공지가 실제 본문이 아니라 공식 홈페이지 링크만 제공한다는 문제도 발견했다. 이를 해결하면서 게임별 패치 소스에 맞는 수집 구조를 추가했고, Patch Detector의 오탐 문제도 함께 수정했다.마지막에는 개발 환경을 실행할 때..

앞선 단계까지 게임별 공식 패치 소스를 하나의 공통 game_patches 구조로 정규화했다.Steam News에서 감지한 패치와 공식 홈페이지에서 직접 수집한 패치가 서로 다른 형태를 가지고 있었지만, 이제는 이후 단계에서 원본 출처를 신경 쓰지 않고 하나의 패치 데이터처럼 다룰 수 있다.이번 단계에서는 이 공통 Patch Layer 위에 LLM 기반 처리 계층을 추가했다.목표는 두 가지다.영문 패치노트를 한국어로 번역한다.한국어 패치노트에서 실제 플레이어에게 중요한 변경점을 짧게 요약한다.단순히 API에 문자열을 보내고 결과를 저장하는 것에서 끝내지 않고, 같은 패치를 반복 처리하지 않는 방법, 원문이 수정되었을 때 다시 처리하는 방법, LLM 호출이 실패했을 때 전체 파이프라인이 멈추지 않도록 하는..

이전 단계에서는 Steam News에서 실제 패치노트를 자동으로 식별하는 Patch Detector를 구현했다.하지만 패치 데이터를 계속 확인하면서 한 가지 문제가 생겼다.Steam에 등록된 게임이라고 해서 모든 게임이 Steam News에 패치노트를 올리는 것은 아니었다.특히 내가 주로 플레이하는 Overwatch의 경우 Steam News보다 Blizzard의 공식 패치노트 페이지가 실제 패치 정보를 확인하기에 더 적합했다.따라서 이번 작업에서는 단일 Steam 데이터 소스에 의존하지 않고, 게임별 공식 패치 소스를 추가할 수 있는 구조로 프로젝트를 확장했다.1. Steam만으로는 모든 게임을 처리할 수 없었다기존 구조는 다음과 같았다.Steam News ↓steam_news ↓Patch ..

지난 작업에서는 Steam News API를 이용해 게임별 뉴스를 수집하고 PostgreSQL에 저장하는 기능을 구현했다.하지만 Steam News에는 실제 게임 패치노트뿐만 아니라 이벤트, e스포츠 경기, 운영 공지, 외부 게임 기사 등 다양한 종류의 글이 함께 포함되어 있다.이번에는 수집된 Steam News 중에서 실제 게임 패치나 업데이트 내용을 다루는 글만 자동으로 식별하는 기능을 구현했다.1. 패치 감지가 필요한 이유최종적으로 만들고 싶은 흐름은 다음과 같다.Steam News 수집 ↓패치 여부 판별 ↓패치노트 번역 ↓내용 요약 ↓Discord 알림모든 Steam News를 번역하고 요약할 필요는 없다.예를 들어 다음과 같은 글까지 LLM에 전달한다면 불필요한 API 호출..

이번에는 기존의 Steam 동접자 수집에서 한 단계 더 나아가 Steam News 데이터를 수집해서 PostgreSQL에 저장하는 기능을 만들었다.이전까지 프로젝트의 주요 데이터는 게임별 동접자 수였다.Steam API ↓Player Count Collector ↓PostgreSQL이번에는 새로운 데이터 흐름을 하나 추가했다.Steam News API ↓News Collector ↓중복 확인 ↓PostgreSQL앞으로 패치 감지나 알림 기능을 만들기 위한 기반이 되는 데이터다.1. Steam News API 확인먼저 코드를 작성하기 전에 Steam News API가 실제로 어떤 데이터를 반환하는지 직접 확인했다.Counter-Strike 2의 Steam App ID인 7..

데이터 수집 프로그램을 만들다 보면 자연스럽게 이런 문제가 생긴다. "이 Python 파일을 매시간 자동으로 실행하고 싶은데, cron이면 충분한 걸까? 아니면 Airflow까지 써야 할까?" 처음에는 두 도구가 비슷해 보인다.둘 다 결국 정해진 시간에 프로그램을 실행할 수 있기 때문이다.하지만 프로젝트가 커지기 시작하면 두 도구의 역할은 꽤 달라진다.이번 Game Data Project에서도 처음에는 Python Collector 하나만 실행하면 됐지만, 게임별 실패와 Retry를 다루기 시작하면서 Airflow를 사용하는 이유가 조금씩 명확해졌다. 1. cron은 무엇인가?cron은 Linux에서 정해진 시간에 명령어를 실행할 수 있도록 해주는 스케줄러다.예를 들어 매시간 Python Collect..

1. 이번 단계의 목표지금까지 Game Data Project에서는 Steam API에서 게임의 현재 동접자 수를 가져와 PostgreSQL에 저장하고, FastAPI를 통해 저장된 데이터를 조회할 수 있도록 만들었다.하지만 데이터 수집 자체는 여전히 사람이 직접 실행해야 했다.기존 구조는 대략 다음과 같았다.사람 ↓Python Collector 실행 ↓Steam API ↓PostgreSQL이번 단계의 목표는 이 수집 작업을 사람이 직접 실행하는 대신 Airflow가 정해진 시간마다 자동으로 실행하도록 만드는 것이었다.최종적으로 만들고 싶은 구조는 다음과 같다.Airflow Scheduler ↓Player Count DAG ↓게임별 Task ↓Steam API ..

Day 9에서는 FastAPI에 Redis를 붙이고, 최신 플레이어 수 조회 API에 캐시를 적용했다.이번 목표는 단순히 Redis를 실행하는 것이 아니라 다음 흐름을 직접 구현해보는 것이었다.Client ↓FastAPI ↓Redis ├─ HIT → 바로 응답 └─ MISS ↓ PostgreSQL ↓ Redis 저장 ↓ 응답Redis가 왜 필요한지, Cache Hit/Miss가 무엇인지, TTL은 왜 필요한지, 그리고 Redis 장애가 발생했을 때 API는 어떻게 동작해야 하는지까지 확인했다.Redis를 Docker Compose에 추가기존 Docker Compose 환경에는 FastAPI와 PostgreSQL이 있었고, 여기에 Redis 서비스를 추가했다.servi..