해외 게임의 이름과 제품 정보

해외 오락실을 추가할 때는 주소만 입력하면 끝나는 것이 아니다. 같은 게임도 국가에 따라 이름이 달라지고, 제조사나 버전의 분류 방식도 맞춰야 한다. 2025년 하반기부터 해외로 확장하면서 이런 차이가 공통 검색과 필터에 영향을 주기 시작했다. 공식 페이지의 이름을 그대로 복사하면 같은 대상을 다른 제품처럼 다룰 수 있기 때문이다.

초기 자료를 모두 손으로 넣는 대신 제조사와 기체의 공식 사이트에서 필요한 정보를 읽는 Python 수집기를 만들었다. 수집기는 이름 등의 필드를 추출하고, 서비스가 쓰는 형식으로 정리한 뒤 백엔드에 넣는다. 이렇게 여러 자료를 공통 형식으로 맞추는 과정을 정규화라고 한다. 공식 자료를 모으는 일과 서비스 안에서 같은 제품을 식별하는 일을 함께 준비한 것이다.

flowchart TD
    accTitle: 공식 자료에서 참조 데이터까지
    accDescr: 공식 기체·제조사 페이지의 필요한 필드를 추출하고 정규화한 뒤 참조 테이블에 적재한다.
    S[공식 기체와 제조사 페이지] --> E[필요한 필드 추출]
    E --> N[공통 구조로 정규화]
    N --> I[별도 적재]
    I --> R[제조사와 시리즈 및 버전]

수집 자료와 공통 참조 데이터

제조사와 시리즈 및 버전은 한 오락실만의 정보가 아니다. 여러 장소가 같은 항목을 가리키는 참조 데이터다. 이를 화면의 조건문에 넣어 두면 이름을 고칠 때 프로그램도 바꿔야 하므로, 별도 적재 단계에서 game_manufacturer, game_series, game_series_version으로 연결했다.

국가별 이름과 글로벌 또는 지역 한정 노출 여부도 이때 저장한다. 예를 들어 지역마다 표시명이 달라도 같은 제품이면 공통 관계를 유지하고 국가에 맞는 이름을 선택한다. 화면이 공식 원문을 매번 해석하거나, 이름 차이만으로 시리즈를 중복 생성할 필요가 없도록 한 것이다.

flowchart TD
    accTitle: 공통 정체성과 지역 표시의 연결
    accDescr: 공통 제품과 버전은 국가별 이름 및 노출 범위를 가지며 국가별 조회가 이를 사용한다.
    P[공통 제품과 버전] --> N[국가별 표시 이름]
    P --> V[글로벌과 지역 노출 범위]
    N --> Q[국가별 조회와 화면]
    V --> Q

정규화와 반복 가능한 적재

수집기는 원본 페이지에서 필요한 항목만 골라 제품과 버전 구조에 맞춘다. 원문을 보존하면 출처의 표현은 남길 수 있지만, 그 자료만으로 서비스의 필드와 관계가 완성되지는 않는다. 이름과 버전을 어느 항목에 연결할지 정하는 정규화가 필요한 이유다.

같은 자료를 다시 수집해 넣을 때 항목이 중복되지 않도록 적재는 멱등 방식으로 처리한다. 멱등은 같은 입력을 반복해도 같은 결과를 만드는 성질이다. 자료를 다시 준비하는 작업을 조회 로직과 따로 실행할 수 있지만, 반복 결과가 일정하다고 원본 정보의 정확성까지 증명되는 것은 아니다.

flowchart TD
    accTitle: 반복 적재와 현장 사실의 구분
    accDescr: 같은 입력의 반복 적재는 같은 참조 결과를 만들고 실제 오락실의 설치 여부는 별도 확인한다.
    S[같은 공식 자료] --> I[멱등 적재]
    I --> R[같은 참조 데이터]
    R --> A[오락실 설치 연결의 후보]
    A --> C[현장 설치 여부 별도 확인]

초기 자료의 활용과 설치 확인

이 과정으로 해외 기체와 버전의 초기 자료를 수작업에만 의존하지 않고 마련할 수 있게 됐다. 국가별 표시와 참조 관계를 이용해 설치 게임을 연결하고, 당시 동남아시아 약 300~400개 오락실의 초기 자료를 준비할 기반도 얻었다. 이 숫자는 그 시기의 초기 수집 범위를 가리킨다.

공식 사이트에서 게임 버전을 찾았다고 어느 오락실에 설치됐는지까지 알 수는 없다. 실제 설치와 영업 상태는 현장 자료로 확인해야 한다. 수집기는 제품을 연결할 출발 자료를 만들고, 이후 이용자가 현황을 확인해 고칠 수 있도록 제공한다.

참고: 엔지니어링 기록.