빌드 비교로 알 수 있는 것은 프레임 타임 같은 성능 지표가 얼마나 나빠졌는지까지입니다. 원인을 조사하려면 그 변화가 맵의 어디에서 관측됐는지도 알아야 합니다.
Framedash의 히트맵은 그 ‘어디서’를 대시보드의 맵 이미지 위에 표시해 왔습니다. 2026-07-24의 Unity, Unreal Engine 5, Godot (C#) SDK 업데이트부터는 같은 집계 셀을 에디터에서도 볼 수 있습니다. 레벨을 열어 둔 채 성능 데이터를 반투명 3D 복셀로 실제 레벨 구조 위에 겹칠 수 있습니다.
집계된 성능 데이터를 레벨 위에 3D로 표시하기
복셀 하나하나가 서버에서 집계된 셀입니다. 텔레메트리가 기록한 월드 좌표에 그대로 놓입니다. 에디터가 API에 XYZ 집계를 요청하기 때문에, 측정된 z를 가진 셀은 바닥에 붙은 평면이 아니라 그 높이를 중심으로 한 반투명 상자로 그려집니다.
이 차이가 이번 릴리스의 핵심입니다. 평면 격자는 위아래로 겹친 공간을 하나로 합칩니다. 예를 들어 발코니와 그 아래 아트리움에서 측정된 값이 같은 한 칸에 들어가 평균되면 눈에 띄지 않을 수 있습니다. 높이 정보가 남아 있으면 어느 층에서 값이 높았는지 구분할 수 있습니다. z가 없는 예전 API 응답은 맵 바닥 높이의 평면 셀로 지금까지처럼 표시되므로, 이행 도중에 보이던 것이 사라지지도 않습니다.
세 에디터는 파랑에서 빨강으로 가는 5단계 팔레트를 공유합니다. 색은 응답 안에서 가장 큰 셀을 기준으로 정규화되므로, 빨강은 ‘가져온 범위에서 가장 나쁜 셀’이지 고정된 임계값이 아닙니다. Unity의 오버레이 컨트롤과 Godot의 독은 범례 옆에 셀 수와 최댓값을 함께 보여 줍니다. 정말 무거운 지점인지, 조용한 맵 안의 상대적인 빨강일 뿐인지는 이 숫자로 가릅니다. 한 번의 요청으로 돌아오는 셀은 API 상한인 10,000개까지입니다.
로컬 캡처 파일을 재생하는 것이 아니라, 클라우드에서 이미 집계된 것을 가져와 그립니다.
엔진별로 여는 방법
어느 에디터든 analytics:read 스코프를 가진 읽기용 API 키와 프로젝트 ID로 데이터를 읽습니다. 게임이 이벤트 전송에 쓰는 쓰기 전용 수집 키와는 별개입니다. 에디터에는 집계 결과를 읽는 권한만 주고, 실수로 데이터를 보내 비교 기준을 오염시키지 않기 위해서입니다. 키를 프로젝트에 입력해 두기가 꺼려진다면, 에디터를 띄우기 전에 FRAMEDASH_ANALYTICS_API_KEY를 설정하세요. 세 SDK 모두 이 값을 폴백으로 읽고, 해당 에디터 프로세스 안에서만 쓰며, 저장하지 않습니다. 명시적으로 설정한 키가 있으면 그쪽이 우선합니다.
Unity: SceneView 오버레이
Window > Framedash Heatmap을 열고 읽기용 API 키와 프로젝트 ID를 설정한 뒤, 맵 목록을 새로 고쳐 맵을 고르고 Fetch를 누릅니다. Play 모드에 들어갈 필요는 없습니다.
그다음부터 SceneView에는 Show, Frame, Controls 세 동작을 가진 Framedash Heatmap 오버레이가 붙습니다. Frame은 불러온 데이터의 범위에 SceneView를 맞춰 주므로, 넓은 레벨에서 헤매지 않아도 됩니다. 컨트롤 창을 닫아도 오버레이 자체는 사라지지 않습니다. 선택한 맵과 오버레이 설정은 프로젝트마다 저장되고, 컨트롤을 열어 둔 채 스크립트가 리로드되면 맵 목록 복원과 재요청이 이어집니다. Play 모드 동안에는 표시가 멈췄다가, 끝난 뒤 토글이 켜져 있으면 돌아옵니다.
좌표는 Unity의 Vector3 값을 그대로 씁니다. 텔레메트리의 X/Y/Z가 SceneView의 X/Y/Z에 대응하고, 지면 축을 바꿔 끼우지 않습니다. Z Offset은 표시를 일부러 옮기고 싶을 때만 쓰는 값이지, 클라우드 좌표를 고쳐 쓰는 것이 아닙니다.
이 오버레이 자체는 2026-07-17의 Unity SDK 0.1.4에 평면 쿼드로 들어갔고, 2026-07-24의 0.1.7에서 복셀이 되었습니다.
Unreal Engine 5: 뷰포트별 표시 플래그
UE5 SDK 0.1.13에서는 가져오기와 표시가 나뉘어 있습니다. Window > Framedash > Framedash Heatmap이 가져오기용 패널이고, PIE 밖에서 가져옵니다. 표시는 레벨 뷰포트마다 있는 Show > Framedash Heatmap 플래그가 맡습니다. 기본값은 꺼짐이고, 뷰포트 레이아웃이 바뀌어도 서로 독립적입니다. 한쪽 뷰포트는 작업용으로 깨끗하게 두고 다른 쪽만 히트맵을 켜 두는 식으로 나눠 쓸 수 있습니다. 가져오기 패널을 닫아도 표시 중인 히트맵은 사라지지 않습니다.
에디터 씬의 메인 렌더 패스를 통해 그려지기 때문에, 일반 F9와 고해상도 뷰포트 스크린샷에 히트맵이 함께 찍힙니다. F9를 한 번 누르면 티켓에 첨부할 이미지를 만들 수 있습니다. Play In Editor 동안에는 표시가 멈추고, 플레이가 끝나면 그 전의 뷰포트 선택이 되돌아옵니다.
클라우드 복셀은 색깔별로 배치되어 차가운 색에서 뜨거운 색 순으로 그려지므로, 부하가 높은 셀이 묻히지 않습니다. 셀마다 콜리전 트레이스를 돌리지도 않습니다. API URL, 프로젝트 ID, 읽기 키, 불투명도, 정렬, Z 오프셋은 Project Settings > Plugins > Framedash Heatmap에 있습니다.
Godot (C#): 에디터 독
Godot SDK 0.1.8에서는 플러그인을 켜면 에디터에 Framedash Heatmap 독이 추가됩니다. 읽기 키, 프로젝트 ID, API 베이스 URL을 입력하고 기간과 셀 크기를 고른 뒤 Refresh Maps를 누릅니다. 맵을 골라 Fetch Heatmap을 실행하고, Show를 켠 다음 Frame Heatmap으로 3D 에디터 카메라를 데이터 쪽으로 돌립니다.
최대 10,000개의 셀은 셀마다 노드나 물리 트레이스를 만드는 대신, 캐시된 반투명 복셀 메시 하나로 그려집니다. Show와 Frame 외에 불투명도, Z 오프셋, 이벤트/기간/셀 필터, 범례, 셀 수, 최댓값 컨트롤이 있습니다. 설정은 project.godot가 아니라 프로젝트별 에디터 메타데이터(.godot/editor/editor_layout.cfg)에 저장되니, .godot/는 버전 관리에서 빼 두세요. 에디터는 읽기 키를 넘기기 전에 리다이렉트를 차단하고, 게임이 실행 중인 동안에는 오버레이를 숨겼다가 플레이가 끝나면 되돌립니다. 히트맵 코드는 전부 TOOLS로 가드되어 있어서, 읽기 키와 함께 익스포트된 게임에는 들어가지 않습니다.
이미 보내고 있는 텔레메트리로 돕니다
이걸 위해 계측을 다시 심을 필요는 없습니다. 셀의 재료는 위치가 붙은 이벤트, 즉 비어 있지 않은 map_id와 함께 보낸 이벤트입니다. 그 맵이 대시보드에 등록되어 있어야 한다는 것만 전제입니다. 자동 perf_heartbeat는 map_id가 비어 있고 위치도 없어서, 그것만으로는 공간 그리드에 올라가지 않습니다.
맵에 올릴 수 있는 지표는 FPS, 프레임 타임, GPU 시간, 메모리 사용량입니다. 메모리가 셀 단위로 보이는 것은 SDK가 메모리 계열 지표를 하트비트뿐 아니라 위치가 붙은 이벤트에도 실어 주기 때문입니다. 2026-07-17의 Unity 0.1.4가 mem.vram과 mem.heap을 더한 것이 바로 그 목적이었습니다. 카메라 회전 기록은 기본으로 켜져 있어서 각 이벤트에 요와 피치도 실리고, 셀 상세에서는 핫스팟을 ‘어느 쪽을 보고 있었는가’로 쪼개 볼 수 있습니다.
두 화면은 답하는 질문이 다릅니다. 빌드와 플랫폼을 비교할 때는 대시보드를, 성능이 저하된 위치를 레벨 구조와 대조할 때는 에디터를 사용합니다. 다만 복셀은 값이 관측된 위치를 보여 줄 뿐 원인을 단정하지 않습니다. 주변의 렌더링 부하, 스크립트, 에셋을 조사하는 출발점으로 활용하세요. 릴리스 전에도 레벨을 열어 둔 채 이번 빌드에서 변경한 범위의 히트맵을 확인할 수 있습니다.
시작하기
이미 맵 ID를 붙여 텔레메트리를 보내고 있다면, SDK를 업데이트하고 읽기용 키를 하나 만들면 됩니다. 아직이라면 SDK 통합은 5분 정도면 되고, 첫 히트맵은 Free 플랜 그대로 확인할 수 있습니다.