Data Lab

Game Data Project #13 - 게임별 공식 패치 소스를 하나의 파이프라인으로 통합하기

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

Game Data Project #12 - Steam News에서 패치노트 감지하기

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

Game Data Project #11 - Steam News 수집과 중복 방지

이번에는 기존의 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..

Day 8에서는 지금까지 만든 FastAPI 애플리케이션을 Docker로 실행하고, PostgreSQL까지 Docker Compose로 묶어 하나의 개발 환경으로 구성했다.지금까지 프로젝트는 WSL 환경에서 직접 실행하고 있었다.WSL├── Python├── uv├── FastAPI├── SQLAlchemy├── Alembic├── pytest└── PostgreSQL내 컴퓨터에서는 잘 실행되지만 다른 PC나 서버에서 같은 프로젝트를 실행하려면 Python 버전부터 각종 패키지와 DB 환경까지 다시 맞춰야 한다.Docker를 사용하면 애플리케이션의 실행 환경을 코드로 정의하고, 비교적 동일한 환경을 반복해서 만들어낼 수 있다.이번 Day 8에서는 단순히 Docker 명령어를 사용하는 데 그치지 않고 다음..

Day 7에서는 지금까지 만든 FastAPI API를 사람이 직접 호출해서 확인하는 방식에서 벗어나, pytest를 이용해 자동으로 검증하는 테스트 코드를 작성했다.이번 단계의 목표는 단순히 테스트 몇 개를 만드는 것이 아니라 다음 개념을 직접 사용해보는 것이었다.pytest 기본 사용법assert를 이용한 결과 검증FastAPI TestClientpytest fixturemonkeypatch와 fake datavalidation 테스트Unit Test와 Integration Test의 차이pytest marker를 이용한 테스트 분리1. pytest 설치pytest는 개발 환경에서만 필요한 패키지이기 때문에 dev dependency로 추가했다.uv add --dev pytest가장 먼저 pytest ..

오늘 한 일지난 작업에서는 FastAPI를 사용해 PostgreSQL에 저장된 게임 데이터를 REST API로 조회할 수 있도록 만들었다.당시 DB 접근은 psycopg를 사용해 SQL을 직접 작성하는 방식이었다.FastAPI ↓storage.py ↓직접 작성한 SQL ↓psycopg ↓PostgreSQL이번에는 여기에 SQLAlchemy ORM을 적용해 DB 테이블을 Python 모델로 표현하고, 기존 조회 로직을 ORM 방식으로 변경했다.또한 Alembic을 추가해 DB 스키마 변경 이력을 코드로 관리할 수 있도록 구성했다.최종적으로 구조는 다음과 같이 바뀌었다.FastAPI ↓SQLAlchemy ORM ↓Session ↓Engine ↓psycopg ↓PostgreSQ..

오늘 한 일지난 글에서는 REST API를 어떻게 설계할지 정리했다.이번에는 그때 문서로 설계했던 API를 실제 FastAPI 코드로 구현했다.기존 프로젝트는 Steam API에서 데이터를 가져와 PostgreSQL에 저장하는 흐름까지 만들어둔 상태였다.Steam API ↓Python 수집 코드 ↓PostgreSQL이번 작업을 통해 반대 방향의 흐름도 추가했다.PostgreSQL ↓FastAPI ↓Client즉, 지금까지는 데이터를 수집해서 저장하는 것에 집중했다면 이번에는 저장된 데이터를 외부에서 조회할 수 있도록 API로 제공하는 단계까지 확장했다.FastAPI와 Uvicorn 설치먼저 FastAPI와 Uvicorn을 프로젝트 의존성으로 추가했다.uv add fastapi "uv..