|
|
|
 |
 |
| |
 |
제 목 :
[NDC 2026] 엠바크 “하루 1,000억 건 이벤트, 2초 안에 데이터화” |
 |
작성자 :
|
등록일 : 2026-06-17 오전 11:17:02 |
|
|
 |
 |
 |
넥슨 개발자 콘퍼런스(NDC) 2026 둘째 날인 6월 17일, 엠바크 스튜디오(이하 엠바크) 마티아스 안데르손 데이터 엔지니어는 경기창조경제혁신센터 지하 2층 국제회의장에서 ‘data@embark - 게임에서 발사된 모든 총알을 추적·분석하는 방법’을 주제로 발표했다. 발표는 ‘더 파이널스’와 ‘아크 레이더스’에서 발생하는 전투·이동·이벤트 데이터를 수집해 개발 조직 안에서 활용하는 체계를 다뤘다.
안데르손 엔지니어는 엠바크에서 데이터 엔지니어로 일한다. 앞서 ‘캔디 크러쉬 사가’ 개발사 킹(King)에서 기술 디렉터로 근무했고, 통계 프로그래머, 포커 분석가, 비즈니스 분석가, 프로그래머, 데이터 과학자 역할을 거쳤다. 발표 초반에는 데이터 추적 방식, 데이터 민주화, 파이프라인, 활용 사례, 회고를 차례로 소개했다.
엠바크는 팀 기반 슈터 ‘더 파이널스’와 PvPvE 익스트랙션 어드벤처 ‘아크 레이더스’를 만들었다. 두 게임은 파괴, 사격, 이동, 라운드 단위 전투가 많은 구조다. 엠바크는 총알 발사·명중, 유저 위치, 라운드 상태를 이벤트로 남긴다.
데이터 규모는 수치로도 나왔다. 엠바크 데이터 플랫폼은 1,000종 이상 이벤트 타입을 추적한다. ‘아크 레이더스’ 피크 시점에는 하루 1,000억 건 이상 이벤트와 30TB 데이터가 발생했고, 빅쿼리(BigQuery, 구글 클라우드 데이터 분석 서비스)까지 지연 시간은 2초 미만이었다.
데이터를 모으는 이유는 보안, 밸런싱, 매치메이킹이었다. 엠바크는 치트 유저를 찾기 위해 라운드 안 행동을 따라간다. 정확도와 피해량은 밸런스 조정 자료가 된다. ‘아크 레이더스’에서는 누가 먼저 사격을 시작했는지 분석해 공격 성향 유저끼리 묶는 방식도 쓴다.
이에 따라 엠바크는 데이터 민주화에 맞춰 수집과 분석을 운영해 왔다. 데이터팀이 모든 분석을 대신 맡기보다 개발자, 맵 디자이너, 게임 개발자가 직접 데이터를 보게 하는 방식이다. 내부 백오피스 애플리케이션 ‘게임 툴즈(Game Tools)’는 대시보드 접근 지점으로 쓰인다.
대표 사례는 ‘라운드 뷰어’와 ‘맵 리플레이’다. 라운드 뷰어는 매치메이킹 뒤 만들어진 라운드를 한 줄씩 보여주는 도구다. 개발자는 특정 유저가 당일 어떤 라운드를 플레이했는지, 어떤 서버가 크래시를 냈는지 빠르게 확인한다. 맵 리플레이는 한 라운드 안 이동, 사망, 체력 변화, 상호작용을 다시 보여준다.
히트맵은 여러 라운드 데이터를 합쳐 유저 이동과 교전 밀도를 시각화한다. ‘더 파이널스’ 푸시 오브젝트 모드에서는 유저가 이동 경로를 따라 몰리는 구간과 저격 지점이 함께 드러났다. 웹버전은 2D로 제공된다. 언리얼 엔진 안에서는 복셀 히트맵 형태로 맵 위 밀도를 확인할 수 있게 했다.
데이터 파이프라인 핵심은 이벤트다. 엠바크에서 이벤트는 게임, 백엔드, 백오피스 애플리케이션에서 발생한 일을 바꾸지 않는 엄격한 타입 정의로 다뤄진다. 새 이벤트를 만들면 Pub/Sub(구글 클라우드 메시지 전달 서비스) 스키마, 토픽, 구독, 데드 레터 큐(처리 실패 데이터를 따로 보관하는 대기열), 빅쿼리 테이블이 함께 생성된다. 필요하면 넥슨 로그 구독도 붙는다.
클라이언트와 백엔드는 경로가 다르다. 백오피스와 백엔드 서비스는 Pub/Sub와 빅쿼리로 직접 이벤트를 보낸다. 게임 클라이언트는 HTTPS로 고(Go) 서비스에 추적 데이터를 보내고, 게임 서버는 별도 사이드카(주 프로그램 옆에서 함께 실행되는 보조 프로그램)인 ‘이벤트 리액터’를 거친다.
이벤트 리액터는 라운드가 열린 게임 서버 옆에서 실행되는 고 애플리케이션이다. 게임 서버는 1초에 30회, 각 프레임 단위로 이벤트를 묶어 유닉스 도메인 소켓(같은 서버 안 프로그램끼리 데이터를 주고받는 통신 방식)으로 보낸다. 리액터는 유저 피해량, 접속 시간, 마지막 위치, 이동 거리, 스태미나 사용량을 실시간으로 집계한다. 라운드 종료 뒤에는 해당 라운드에서 발생한 수십만 건 이벤트가 구글 클라우드 스토리지(GCS, 구글 클라우드 파일 저장소)에 파일로 남는다.
이 구조는 게임 서버에 분석 코드를 직접 넣지 않아도 되는 장점을 냈다. 데이터팀은 게임 빌드 배포 주기에 묶이지 않고 집계 정의를 바꿀 수 있었다. 같은 계산을 빅쿼리 SQL 윈도 함수로 처리하면 세션 시작·종료 예외까지 다뤄야 해 복잡해진다. 안데르손 엔지니어는 이 점을 집계 구조 채택 배경으로 들었다.
인프라 선택에서는 비용과 단순성이 기준이었다. 엠바크는 과거 데이터플로를 썼지만, 현재는 Pub/Sub 빅쿼리 데스티네이션 구독을 활용한다. 사용량이 적을 때 비용이 거의 들지 않는 ‘스케일 투 제로(사용량이 없으면 비용도 거의 발생하지 않는 구조)’ 특성이 있다. 하루 1,000억 건 이벤트도 처리 가능한 설계다. 출시 뒤 이벤트 유입 과정에서 별도 문제는 없었다.
분석 단계에서는 ‘시맨틱 클래스’를 만들었다. 물리 테이블은 바꾸지 않는 이벤트 정의를 유지하고, 분석자는 여러 버전 이벤트를 유니언 올(여러 데이터 표를 하나로 이어 붙이는 SQL 방식) 뷰로 묶어 본다. 예를 들어 enemy_damage_3, enemy_damage_4처럼 나뉜 이벤트도 분석 화면에서는 하나로 다룬다.
대시보드 처리 과정도 자체 설계했다. 엠바크는 dbt나 데이터폼 대신 자체 스케줄러를 만들고, 집계 데이터가 일정 단위에 도달하면 빅쿼리 테이블을 파케이(Parquet, 분석용 열 기반 파일 형식) 파일로 내보낸다. 이후 파케이 파일은 덕DB(DuckDB, 가벼운 분석용 내장 데이터베이스)에 적재된다. 대시보드는 덕DB 위에서 매개변수 SQL을 실행하는 방식으로 작동한다.
발표 말미에는 도구 선택에 대한 교훈도 공유했다. 핵심은 많은 제품을 억지로 붙이는 대신 기반 기술을 고르고 필요한 접착 코드를 직접 만드는 쪽이었다.
끝으로 안데르손 엔지니어는 “기반 기술을 고르고 덜 쓰는 편이 나은데, 도구와 싸워야 할 상황에서는 직접 만들어도 된다”라며 “코드는 설정 파일보다 유연하고, 설정 파일은 UI 클릭보다 자동화에 알맞다”라고 말했다.
겜툰 박해수 기자 caostra@gamtoon.com
|
|
|
|
| 덧글쓰기 |
 |
|
|
|
|
|
|
|
|
|
|
인터뷰/업체탐방
총 3090의
게시물이 있습니다. 
