Bake It Tight의 코어 시스템을 정리하면서, 본격적인 테스트에 들어가기 전에 애널리틱스를 붙이기로 했다. 플레이어가 게임을 어떻게 했는지 놓치지 않도록 무엇을 기록하고 어떻게 읽을지 미리 정하는 과정이었다.
Google Analytics, Game Analytics, PostHog 사이에서 고민했다. Google Analytics는 예전에 사용했을 때 자유도가 낮다고 느껴 이번에는 제외했고, 비교적 자유롭게 데이터를 다룰 수 있는 PostHog를 최종적으로 선택했다.
어떤 지표를 왜 붙였는지, 그 지표를 보고 어떻게 행동할 것인지 정리해보려 한다.
왜 테스트 전에 붙였나
플레이테스트를 하면 보통 “어디가 어려웠다”, “재미있었다”, “뭘 해야 할지 몰랐다” 같은 피드백을 받는다. 직접 옆에서 플레이를 보거나 영상을 돌려볼 수도 있다. 둘 다 중요하지만 이것만으로는 전체 흐름을 기억하기 어렵다.
예를 들어 테스터가 6일차에 게임오버됐다고 해보자. 인터뷰에서는 주문이 어려웠다고 말할 수 있다. 하지만 실제로는 필요한 기계를 받지 못했거나, 기계는 있어도 놓을 공간이 없었을 수 있다. 확장 직후 레일을 다시 까느라 납품하지 못했을 가능성도 있다. 시간이 지나 테스터가 당시 상황을 정확히 기억하지 못할 수도 있고, 한 판만 봐서는 우연인지 반복되는 문제인지 판단하기도 어렵다.
애널리틱스를 붙인 이유는 이런 질문에 곧바로 답을 내리기 위해서가 아니다. 문제가 생긴 구간과 다시 봐야 할 플레이를 좁히기 위해서다. 테스터의 이야기와 지표를 함께 보면서 문제 지점을 더 정확히 찾고, 수정할 순서를 정하고 싶었다.
또 하나는 계측 자체를 미리 검증하기 위해서다. 실제 테스터가 들어온 뒤에 이벤트 누락이나 잘못된 정의를 발견하면 그 이전 데이터는 다시 얻을 수 없다. 지금은 데이터가 적으니 게임을 판단할 때가 아니라, 시작과 종료가 제대로 연결되는지, 개발용 데이터가 섞이지 않는지부터 확인하고 있다.
어떤 데이터를 기록했나
이벤트가 많다고 분석이 쉬워지는 건 아니다. 무엇을 알고 싶은지 먼저 정하고, 그 질문에 필요한 이벤트를 찍는 편이 더 중요하다. 현재 이벤트는 총 8종이며, 실제 플레이 흐름에 따라 네 묶음으로 나눴다.
1. 데이터 건강 및 플레이 현황
가장 먼저 확인할 것은 데이터가 제대로 쌓이고 있는지다. 이 대시보드에서는 날짜별 플레이어 수와 시작한 런 수, 종료된 런 수, 완결률을 확인한다. 실제 테스트 데이터만 보기 위해 release 빌드를 기준으로 집계하고, 개발 과정에서 만든 스모크 데이터는 제외했다.
시작한 런에 비해 종료된 런이 지나치게 적다면 게임의 난이도를 판단하기 전에 계측부터 살펴봐야 한다. 다만 창이나 탭을 닫거나 강제로 종료한 경우에는 game_ended가 남지 않으므로 완결률이 100%일 필요는 없다. 특정 버전부터 수치가 갑자기 달라졌는지, 이벤트가 빠진 종료 경로는 없는지 확인한 뒤 나머지 차트를 본다.
2. 튜토리얼 및 진입
튜토리얼은 tutorial_step을 기록한다. 각 스텝의 진입 수와 다음 스텝 진입 여부를 비교하면 큰 이탈이 생긴 챕터와 세부 스텝을 찾을 수 있다. 이탈이 많은 스텝을 찾으면 스텝의 문구 및 완료 조건을 확인하고 고칠 수 있다.
튜토리얼이 끝나고 본 게임으로 넘어가면 game_started로 한 판의 시작을 기록하고, first_line_completed로 첫 생산 라인을 완성한 순간을 남긴다. 이 둘을 비교하면 본편에 들어온 사람이 실제 영업 시작까지 도달했는지 알 수 있다.
첫 라인 도달률이 낮다면 난도를 바로 낮추기보다 시작 상태를 먼저 확인한다. 튜토리얼에서 배운 내용이 본편으로 이어지지 않았는지, 첫 주문이 불분명한지, 연결 피드백이 약한지 플레이 영상에서 확인할 생각이다. 도달률은 높지만 준비 시간이 길다면 규칙을 모르는 문제보다 시작 배치나 조작 비용이 큰 쪽을 의심한다.
3. 인게임 성장 데이터
게임은 하루 단위로 구성되어 있고, 하루가 끝날 때마다 day_end를 보낸다. 여기에는 그날 납품한 쿠키와 완료한 주문, 누적 생산량, 기계·모듈·레일 수, 조작 횟수, 받은 보상, 보드 배치 상태 등의 데이터가 들어간다.
이 이벤트로 보고 싶은 것은 단순한 점수 순위가 아니다. 어느 day부터 납품량이 떨어지는지, 그때 조작은 늘었는지, 공장은 실제로 커지고 있는지 같이 본다.
- 조작량은 증가했는데 납품량이 감소했다: 플레이어가 기존 라인을 뜯어고치는 중일 수 있다.
- 조작량은 줄었는데 납품량이 늘었다: 자동화가 안정된 상태일 수 있다.
어느 한쪽이 계속 이어진다면 좋은 신호는 아니다. 두 흐름이 적절히 반복되는지 살펴보고, 한쪽으로 치우쳤다면 다른 지표와 함께 원인을 확인해야 한다.
그 밖에도 보상이 제대로 지급되는지, 맵별 평균 확장 타이밍은 언제인지, 납품 곡선이 잘 올라가는지 등 플레이 흐름을 확인하는 지표가 있다.
expansion_applied는 보드 확장이 실제로 적용된 순간의 day, 누적 쿠키, 기계 수를 남긴다. 이전에는 하루가 끝난 뒤 보드 크기가 달라진 것을 보고 확장 시점을 추정해야 했는데, 이제는 적용 순간을 직접 볼 수 있다.
확장 직후 납품이 급격히 떨어지고 조작량이 늘어난다면, 확장이 보상이라기보다 대공사로 느껴지는 것일 수 있다. 확장이 지나치게 늦다면 조건이나 보상 속도를 살펴보고, 확장 후 생존율이 급격히 떨어진다면 확장 이후 난도 변화를 점검한다.
마지막으로 맵별 평균 도달 day를 비교해 난이도가 적절한지도 살펴본다.
4. 게임 종료 및 재도전
한 판이 끝나면 game_ended에 종료 이유와 생존 day, 최종 점수, 완료 주문 수를 기록한다. 게임오버라면 어떤 주문 때문에 죽었는지, 얼마나 납품했는지, 사망 순간 그 주문을 처리할 라인이 있었는지도 남긴다.
이 데이터가 있으면 같은 게임오버라도 나눠서 볼 수 있다. 라인 자체가 없었다면 기계·공간·레일·주문 인지 문제를 먼저 보고, 라인은 있었지만 진행률이 낮다면 생산 속도나 공정 길이를 본다. 80% 이상 납품하고 죽는 경우가 반복된다면 제한 시간이나 만료 전조를 확인한다. 다만 이 분류만으로 원인을 확정하지는 않는다. 마지막에 잠시 라인을 끊었을 수도 있으므로 실제 장면을 함께 봐야 한다.
재도전은 game_ended 다음에 나온 game_started까지의 간격으로 계산한다. 튜토리얼을 마치면 본편 fresh 런이 자동으로 시작되는데, 이것은 재도전이 아니므로 계산에서 제외한다.
즉시 다시 시작한 사람이 많다면 적어도 한 번 더 해볼 의향은 있었다고 볼 수 있다. 하지만 그것만으로 재미있었다고 결론 내릴 수는 없다. 억울해서 다시 했을 수도 있기 때문이다. 반대로 다음 기록이 없다고 바로 이탈로 보기도 어렵다. 한 판을 충분히 하고 만족해서 끝냈을 수 있다.
그래서 재도전 간격은 런 길이와 종료 이유를 함께 본다. 다음 날 다시 접속했는지는 D1 리텐션으로 따로 본다. 즉시 재도전은 높은데 D1이 낮다면 코어 한 판은 다시 해볼 만하지만 다음 날 돌아올 목표가 약한지 살펴볼 수 있다. 둘 다 낮다면 메타 요소보다 첫 경험과 코어 루프를 먼저 점검해야 한다.
숫자를 보고 어떻게 행동할 것인가
대시보드를 열면 먼저 데이터 건강을 확인한다. 플레이어와 런 수가 얼마인지, 시작 대비 종료 이벤트가 비정상적으로 적지 않은지 본다. 여기서 문제가 있으면 게임을 고치지 않고 계측부터 확인한다.
데이터가 정상이라면 가장 큰 증상 하나만 고른다.
- 튜토리얼 이탈이 크면 챕터 퍼널에서 범위를 찾고, 스텝 표에서 위치를 좁힌 다음 해당 플레이 영상을 본다.
- 특정 day에서 생존율이 떨어지면 그 day의 납품 분포, 조작량, 보상, 확장 여부, 사망 주문을 함께 본다.
- 공장이 잘 성장하지 않으면 런 중 추가된 기계 수, 보상 목록, 보드 공간, 납품량과 조작량의 변화를 함께 본다.
- 재도전이 적으면 종료 이유와 런 길이를 먼저 보고, D1까지 낮은지 나눠 본다.
여기까지 해도 데이터가 알려주는 것은 “어디를 조사할 것인가”에 가깝다. 원인은 테스터와의 인터뷰로 확인한다. 원인이 확인되면 여러 규칙을 동시에 바꾸지 않고 한 가지 가설만 수정한다. 예를 들어 6일차에 비활성 라인 사망이 많고, 영상을 보니 신규 주문을 알아채지 못한 경우가 가장 많았다면 다음 빌드에서는 주문 연출을 강화한다. 이후 같은 차트에서 6일차 사망이 줄었는지, 다른 사망 유형이 늘지는 않았는지 다시 본다.
결국 내가 만들고 싶은 흐름은 아래와 같다.
데이터로 이상 구간 찾기 → 실제 플레이로 이유 확인하기 → 한 가지 수정하기 → 다음 빌드에서 같은 지표 다시 보기
해석할 때 주의할 점
초기 플레이테스트에서는 작은 표본의 퍼센트도 그럴듯하게 보이기 쉽다. 그래서 비율만 보지 않고 실제 인원을 함께 확인할 예정이다. 후반 day 데이터에는 그때까지 살아남은 플레이어만 남기 때문에, 중앙값을 사용해도 생존자 편향은 사라지지 않는다. 생존 곡선과 표본 수를 같이 봐야 한다.
종료 이벤트에도 한계가 있다. 게임오버와 ESC를 통한 홈 이탈은 game_ended로 남지만, 창 닫기·탭 닫기·강제 종료·크래시는 기록되지 않는다. 따라서 시작한 런이 모두 종료 이벤트로 이어질 것이라고 기대하면 안 된다.
웹 빌드의 D1도 실제보다 낮게 잡힐 수 있다. 익명 식별자가 브라우저 저장소에 있기 때문에 다른 브라우저나 시크릿 창으로 접속하면 새 플레이어가 된다. 또 fixture_count와 expansion_applied는 이번에 추가한 값이라 다음 배포 데이터부터 제대로 쌓인다. 이전 데이터와 섞어서 해석하지 않아야 한다.
마지막으로 현재 데이터는 동의한 플레이어의 기록만 포함한다. 데이터 수집을 거부한 사람이 어떻게 플레이했는지는 알 수 없다. PostHog에는 Steam ID나 기기명 같은 개인정보를 보내지 않고, 익명 식별자와 게임 안에서 일어난 행동만 기록하도록 했다.
이제 실제 테스트에서 확인할 차례다
대시보드와 이벤트 정의는 일단 맞춰두었다. 다음 웹 빌드를 배포하면 새로 추가한 확장 시점과 고정물 구분 데이터도 쌓이기 시작한다.
당장은 숫자에서 큰 결론을 내리지 않을 생각이다. 실제 플레이테스트가 시작되면 먼저 데이터가 빠짐없이 쌓이는지 확인하고, 표본이 모이면 가장 큰 문제 하나를 골라 영상과 함께 볼 예정이다. 애널리틱스를 붙인 목적도 결국 여기에 있다. 플레이어의 말을 숫자로 대신하는 것이 아니라, 플레이어가 실제로 무엇을 했는지 놓치지 않고 다음 수정의 순서를 정하기 위해서다.
