Unity User Reporting 뜯어보기 — 무엇을 주고 무엇을 안 주나

버그 리포터를 직접 만들기 전에 "이미 있는 걸 쓰면 안 되나"를 먼저 확인하는 게 순서입니다. Unity 는 User Reporting 이라는 공식 패키지를 제공합니다. 이 글은 그 패키지가 실제로 주는 것과 안 주는 것을, 공식 문서에서 확인된 범위 안에서만 정리합니다.

User Reporting이 주는 것

개발 중인 게임에 붙여서 플레이어로부터 버그 리포트와 피드백을 수집하는 서비스입니다. 리포트 하나에 담기는 항목은 다음과 같습니다.

UserReportingService.Instance.AddMetadata 로 커스텀 메타데이터를, LogEvent 로 이벤트를 얹는 구조입니다. 씬 드래그앤드롭으로 붙이는 리포트 폼 예제 프리팹도 함께 제공됩니다. 알림은 슬랙·이메일·Jira 등으로 연동할 수 있다고 문서에 나와 있습니다. 예를 들어 레벨을 클리어할 때마다 LogEvent 로 진행 지점을 남겨 두면, 나중에 리포트 하나가 들어왔을 때 그 플레이어가 어디까지 진행한 뒤였는지를 별도 질문 없이 이벤트 로그만으로 되짚을 수 있습니다.

성능 영향은 문서상 "대부분 무시할 수 있는 수준"이며, 예외는 스크린샷입니다. 스크린샷 캡처와 전송에는 데이터 사용량이 붙습니다. 리포터가 유휴 상태일 때는 별도 리소스를 점유하지 않습니다.

User Reporting이 안 주는 것

가장 중요한 한 줄부터 씁니다. 영상 캡처는 없습니다. 공식 문서 어디에도 영상 녹화 기능은 언급되지 않고, 캡처 항목은 스크린샷까지입니다. "버그 직전 몇 초"를 보려는 목적이라면 이 패키지 하나로는 도달하지 못합니다. 타이밍이나 물리처럼 프레임 사이의 인과관계가 중요한 버그는 그 순간 앞뒤 몇 초를 봐야 원인이 잡히는 경우가 많은데, 스크린샷 한 장에는 그 앞뒤가 애초에 담기지 않습니다.

로그 링 버퍼처럼 최근 N줄의 콘솔 로그를 자동으로 리포트에 실어주는 기능도 문서에서 확인되지 않습니다. LogEvent 는 개발자가 직접 호출해서 쌓는 분석 이벤트에 가깝고, Application.logMessageReceived 를 자동으로 후킹해 주는 것과는 다른 층위입니다.

전환 중이라는 사실을 알아야 합니다

User Reporting 이 속한 상위 서비스 Cloud Diagnostics 자체가 deprecated 상태이고, 향후 버전에서 단계적으로 폐지됩니다. Crash and Exception Reporting 은 Unity 6.2 이상의 내장 Diagnostics 서비스로 이전되었고, User Reporting 은 별도 패키지로 분리되었습니다 — 현재 패키지 식별자는 com.unity.services.user-reporting 이고, 오래된 자료에 나오는 com.unity.cloud.userreporting 은 레거시 이름입니다. 기존 Cloud Diagnostics 데이터는 플랜에 따라 7일 또는 90일만 보관되므로, 이 서비스를 신규로 붙일 계획이라면 어떤 버전 기준으로 세팅할지부터 확인해야 합니다.

언제 이걸로 충분하고, 언제 부족해지나

표를 관통하는 기준은 하나입니다 — 텍스트 설명과 스크린샷 한 장으로 재현 조건을 전부 전달할 수 있는 버그인가입니다. 전달이 가능하면 User Reporting 만으로 충분하고, 순간의 타이밍까지 봐야 설명이 되는 버그라면 이 패키지의 캡처 범위를 이미 넘어선 것입니다.

정리

Unity User Reporting 은 메타데이터·이벤트·스크린샷·첨부파일까지는 공짜로 해결해 줍니다. 여기서 멈추는 이유는 게으름이 아니라 영상이 원래 범위 밖이기 때문입니다. 영상까지 필요해지면 게임플레이 녹화 방법 비교에서 다음 선택지를 확인하시고, 로그·상태를 직접 붙이는 최소 구현은 최소 구현 가이드에 정리했습니다. 버그 리포터를 만드는 결정 전체 지도는 1편에 있습니다.

저희 Rekon은 User Reporting 이 멈추는 지점 — 영상과 같은 시간축의 로그·상태 — 에서 시작하는 선택지입니다. 공식 패키지로 충분한 프로젝트라면 그대로 쓰시는 걸 권합니다.