Data Lab

Game Data Project #19 - Steam URL로 게임을 등록하고 기존 수집 파이프라인에 연결하기

#18까지 Game Dashboard에서 동접자, 가격, 가격 이력, 최근 패치를 확인할 수 있게 되었다.하지만 한 가지 큰 제약이 있었다.지금까지 Dashboard에서 볼 수 있는 게임은 모두 미리 games 테이블에 등록해둔 게임이었다.즉 새로운 게임을 추가하려면 DB에 직접 데이터를 넣어야 했다.이번 작업에서는 이 구조를 바꿨다.사용자가 Web에서 Steam Store URL 전체를 입력하면:Steam Store URL 입력 ↓Steam App ID 추출 ↓Steam 게임 정보 확인 ↓게임 미리보기 ↓게임 등록 ↓games 테이블 ↓기존 Collector 자동 포함 ↓Game Dashboard까지 이어지는 흐름을..

Service Layer와 Business Logic은 왜 분리할까?

FastAPI로 API를 만들기 시작하면 처음에는 구조가 단순하다.Route→ DB 조회→ Response예를 들어 특정 게임 정보를 조회하는 API라면 다음 정도로도 충분하다.@router.get("/games/{game_id}")def game_detail(game_id: int): game = get_game(game_id) if game is None: raise HTTPException(status_code=404,detail="Game not found",) return game여기서 get_game()은 DB를 조회하고, Route는 HTTP 요청을 처리한다.구조도 이해하기 쉽다.하지만 서비스가 커지면서 하나의 요청이 여러 작업을 수..

Game Data Project #18 - Game Dashboard에 가격/할인/가격 이력 붙이기

#17에서 Steam 가격 수집 파이프라인을 만들었다.Steam Store API에서 가격을 가져오고, 현재 가격과 가격 변경 이력을 PostgreSQL에 저장할 수 있게 되었지만 데이터가 DB에 쌓이는 것만으로는 사용자가 체감할 수 있는 기능이 되지는 않는다.이번 작업에서는 저장된 가격 데이터를 Game Dashboard에 연결했다.최종적으로 게임 상세 화면에서 다음 정보를 확인할 수 있게 되었다.현재 가격과 할인 여부무료 게임 여부가격을 조회할 수 없는 게임의 상태가격 변경 이력 차트이번 작업에서 특히 중요했던 부분은 단순히 숫자를 화면에 표시하는 것이 아니라 가격이라는 데이터를 어떤 상태로 해석해서 보여줄 것인가였다.1. 가격 데이터는 단순한 숫자가 아니다처음에는 현재 가격만 가져오면 다음처럼 표시..

지난 #17에서는 Steam 가격 데이터를 수집하고, 게임 목록을 코드에 하드코딩하지 않고 DB의 games 테이블을 기준으로 수집하는 구조로 확장했다.이번에는 새로운 데이터 종류를 추가하기보다 기존 패치 파이프라인을 실제로 운영하기 편한 형태로 다듬었다.기존 패치 시스템은 이미 다음 단계까지 구현되어 있었다.공식 패치 소스 수집→ 패치 감지→ game_patches 정규화→ LLM 기반 번역→ LLM 기반 요약→ Web Viewer각 단계는 동작하고 있었지만 중요한 문제가 하나 있었다.패치 수집과 번역·요약 처리가 서로 분리되어 있었다.새로운 패치가 들어오더라도 별도로 번역·요약 Processor를 실행해야 했다.이번 작업에서는 이 흐름을 하나로 연결하고, Web Viewer에서 특정 패치를 직접 다시..

이번 작업의 시작점은 단순했다.게임별 가격과 할인 정보를 수집해서 저장하고, 이후 대시보드와 가격 알림에서 사용할 수 있도록 만드는 것이 목표였다.하지만 실제로 가격 수집 기능을 추가하다 보니 한 가지 구조적인 문제가 드러났다.기존 프로젝트에서는 일부 수집기가 코드 안에 정의된 게임 목록을 기준으로 동작하고 있었다.GAMES = [ ...]초기에는 관리하는 게임 수가 적었기 때문에 큰 문제가 없었다.하지만 앞으로 Web에서 사용자가 원하는 게임을 직접 등록할 수 있게 만들려면 이야기가 달라진다.게임 하나를 추가할 때마다 다음을 수정해야 한다면 확장 가능한 구조라고 보기 어렵다.게임 등록→ 가격 수집 코드 수정→ 동접자 수집 코드 수정→ Airflow DAG 수정→ Steam News 수집 코드 수정..

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

백엔드 코드를 처음 작성할 때는 요청을 받고, 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 =..

지난 #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 ..