Screen Test Pro 점수 계산 방식
여기는 방법론 페이지입니다. 마케팅을 위해 단순하게 다듬은 곳은 없습니다. 코드와 이 페이지가 어긋난다면 그건 버그이니 알려 주시면 고맙겠습니다. (작성 시점의 벤치마크 버전: 2.2.0)
어떤 값을 찾는 테스트인가요?
일반적인 그래픽 벤치마크는 부하를 고정하고 FPS를 측정합니다. 여기서는 프레임 시간 기준을 고정하고 그 기준을 유지할 수 있는 가장 큰 부하를 찾습니다. 장면별 최대 안정 부하가 840,000개의 성운 입자로 측정됐다면 그 값을 점수 계산에 사용합니다.
빠른 기기에서는 고정 부하의 FPS가 화면 주사율에 막혀 여유 성능을 구분하기 어렵습니다. 부하를 늘리는 방식은 같은 장면으로 오래된 스마트폰부터 데스크톱 GPU까지 비교할 수 있는 범위를 넓혀 줍니다.
실행하는 장면
표준 프로필은 시그니처 5개와 대조 장면 1개로 구성되며 서로 다른 작업에 부하를 줍니다.
| 장면 | 부하 단위 | 주로 측정하는 작업 |
|---|---|---|
| 성운 드리프트 | GPU 입자 | 셰이더 입자 갱신과 픽셀 처리 |
| 네온 메트로폴리스 | 인스턴스 | 인스턴스 지오메트리 처리 |
| 리퀴드 크롬 | 내부 해상도 | 레이마칭과 프래그먼트 연산 |
| 별똥별 폭포 | CPU 입자 | JavaScript 물리 연산과 버퍼 전송 |
| 하이퍼노바 | 폭발 입자 | 여러 종류의 그래픽 부하 |
| Canvas 2D 기본 원 | 2D 원 | WebGL을 사용하지 않는 대조 작업 |
픽셀 비율은 최대 1.5×로 제한하며 내부 렌더링 크기에도 상한을 둡니다. 5K 화면과 1080p 노트북이 지나치게 다른 픽셀 수를 처리하지 않도록 하기 위해서입니다. 난수 시드와 시뮬레이션 시간 간격도 고정해 같은 버전의 작업 조건을 맞춥니다.
안정성 판단 기준
엔진은 fps 카운터를 읽지 않습니다. 브라우저의 애니메이션 시계에서 프레임 시간을 약 0.7~1.6초 길이의 창으로 모은 뒤, 각 창에 두 가지를 요구합니다.
- 통과 기준을 넘는 프레임은 5% 이하여야 합니다 — 가변 주사율 화면에서는 17.5 ms, 고정 주사율 화면에서는 예산 안의 작업이 결코 도달할 수 없는 첫 수직동기 자리(60 Hz에서 25.0 ms, 120 Hz에서 20.8 ms);
- 절사 평균 — 가장 나쁜 2%의 프레임을 뺀 값 — 이 16.67 ms × 1.15 안에 머물러야 합니다.
초과분을 평균 내지 않고 세면, 가비지 컬렉션이 한 번 멈춘 것은 창 전체의 실패가 아니라 나쁜 프레임 한 장으로 끝납니다. 절사 평균은 그 뒤를 받치는 안전장치로, 드물지만 아주 큰 초과가 개수만으로 통과하는 것을 막습니다.
기준이 화면을 따지는 이유: 고정 60 Hz 모니터는 프레임을 16.7 ms나 33.3 ms에만 내보낼 수 있고 그 사이는 없습니다. 반면 가변 주사율 노트북 패널은 18 ms 프레임을 18 ms 그대로 돌려줍니다. 2.1.0의 평균·P95 허용치에서는 이 차이 때문에 가변 패널이 55 fps로도 통과했고, 60 Hz 모니터는 진짜 60을 지켜야 했습니다. 같은 GPU가 책상 위에서 노트북 화면보다 낮은 점수를 받은 것입니다. 그래서 첫 장면 전에 약 600 ms의 박자 측정이 화면이 프레임을 어떻게 돌려주는지 살피고, ‘60 fps를 유지한다’가 어떤 화면 종류에서도 같은 주장이 되도록 기준을 맞춥니다. 측정에서 화면이 약 50 Hz 아래로 묶여 있다고 나오면 — 저전력 모드, 30 Hz 케이블 — 실행은 시작을 거부합니다. 30 Hz 빨대 너머로 GPU를 채점하지는 않습니다.
16.67 ms라는 예산 자체는 주사율에 따라 달라지지 않습니다. 120 Hz 화면은 여유가 있을 때 8.3 ms 간격으로 프레임을 내놓지만, 통과에 필요한 것은 초당 60장 예산 안에 머무는 것뿐입니다. 높은 주사율의 하드웨어는 같은 조건에서 측정되며, 프레임을 더 보여 준다고 해서 손해를 보지 않습니다.
부하 탐색 과정
각 장면은 상태 기계를 따라갑니다: preflight → baseline → warmup → ramp → bracket → confirm → anchor.
- Baseline은 알려진 가벼운 부하를 재고, 이 값이 발열의 기준이 됩니다.
- Ramp는 창을 하나 통과할 때마다 부하를 약 1.5×씩 올리다가 어느 창이 실패하면 멈춥니다.
- Bracket은 마지막으로 통과한 부하와 처음 실패한 부하 사이를 이분 탐색해 범위를 약 6%까지 좁힙니다.
- Confirm은 후보 부하에서 연속 세 번의 통과 창을, 네 번의 예산 안에서 요구합니다. 초반의 나쁜 창 하나는 만회할 수 있지만, 연속 두 번 실패하거나 세 번 연속을 못 채운 채 예산을 다 쓰면 그 단계를 물리고 후보를 한 칸 내립니다.
- Anchor는 기준 부하를 다시 실행합니다. 처음보다 15% 넘게 느려졌다면 측정 중에 기기 쪽이 달라진 것이고 — 거의 언제나 발열 제한입니다 — 아무 일 없었던 척하는 대신 그 장면에 드리프트 표시를 붙입니다. 느려진 정도도 사실만이 아니라 함께 기록합니다.
부하가 바뀐 직후의 프레임 몇 장은 통계를 이어가기 전에 버립니다. 부하를 바꾸면 GPU 버퍼와 렌더 타깃을 다시 할당하고, 브라우저는 그것을 아주 긴 프레임 하나로 계산하기 때문입니다. 그 덜컥거림은 전환에 속하지 작업 부하가 아닙니다. 2.1.0은 그것을 세었고, 단마다 렌더 타깃 크기를 바꾸는 장면에서는 하드웨어가 실제로 버티는 수준보다 훨씬 아래에서 탐색을 멈추게 했습니다.
모든 단계에는 엄격한 시간 제한이 있습니다(장면당 30초, 실행당 200초). 탭을 뒤로 보내면 측정이 멈추고 진행 중인 창은 무효가 됩니다. 크기를 바꾸면 장면을 다시 만들고 예열도 다시 합니다. 상태 기계 안에 멈춘 채로 남는 경로는 없습니다.
부하를 점수로 바꾸기
점수 계산은 기록된 결과에 대한 순수 함수입니다. 손으로도 다시 계산할 수 있습니다.
- 각 장면의 최대 안정 부하를 그 장면의 기준 부하(버전마다 얼려 둔 보정 상수로, 대략 2025년의 튼튼한 데스크톱이 1.0 근처에 옵니다)로 나눕니다.
- 비율은 아래로 0.05에서 막고, 위로는 그 장면 자신의 사다리 천장 — 그 장면이 물리적으로 세울 수 있는 가장 무거운 부하로, 지금까지 측정한 가장 빠른 하드웨어보다 약 10배 위에 둡니다 — 에서 자릅니다. 그래야 점수가 측정 자체가 끝나는 곳에서만 멈출 수 있습니다. (2.1.0은 모든 장면을 일률적인 20×에서 잘랐습니다. M4 Max는 두 장면을 그 상한에, 세 번째를 측정 천장에 밀어붙였고, 서로 무관한 애플 최상위 기기들이 거의 같은 총점을 계속 보고한 이유가 그것입니다.)
- 잘린 비율들은 가중 기하 평균으로 묶입니다. 다섯 개의 Signature 장면이 대부분의 가중치를 지고, Canvas 2D 대조군이 10%입니다. 기하 평균인 것은 균형에 상을 주기 때문입니다. 모든 것을 고르게 잘하는 기기가 하나만 전설적이고 다른 하나는 형편없는 기기를 이깁니다.
- 1000을 곱하고 안정성 감점을 적용합니다 — 표시가 붙은 장면마다 3%씩, 그 표시가 드리프트든 확인되지 않은 단계든 같으며, 합쳐서 최대 10%입니다 — 그리고 반올림합니다.
등급은 버전마다 고정된 기준선이고, 점수가 기준 기기의 1000배이므로 각 등급은 사실상 그 배수입니다. 입문은 1000 미만, 균형은 2999까지, 빠름은 8999까지, 최상은 그 위 — 즉 1× 미만, 3×까지, 9×까지, 그리고 그 너머입니다. 숫자에 손잡이를 달아 주려고 있는 것이고, 진짜 정보는 장면별 점수입니다.
비교할 때 지켜야 할 조건
- 다른 벤치마크 버전끼리는 절대 비교하지 않습니다. 셰이더 하나만 바꿔도 작업 부하가 달라집니다. 결과지에 적힌 버전 문자열은 점수의 일부입니다.
- 호환 실행(WebGL2 없음)은 Classic 장면만 쓰고 자기만의 공간에서 점수가 매겨지며, 그렇게 표시됩니다.
- 발열 제한 실행 — 모든 장면을 측정하고 확인했지만 기기가 더워져 느려진 경우 — 은 지속 성능에 대한 진짜 측정이므로 정상적으로 점수가 매겨지고, 줄에 표시를 단 채 상위 점수 순위표에 오릅니다. 스마트폰 실행은 대부분 여기에 들어옵니다. 그건 물리이지 결함이 아닙니다.
- 저하된 실행 — 쓸 만한 결과를 내지 못한 장면이 있거나, 탐색이 끝내 확인하지 못한 단계가 있는 경우 — 은 정점이 아니라 바닥값이므로 순위표에서 빠집니다. 그래도 보관되고, 집계 중앙값에는 계속 반영되며, 결과지가 어느 장면에서 왜 그랬는지 알려 줍니다.
- 두 표시 모두 실행과 함께 익명 데이터셋으로 들어가므로, 공개되는 어떤 수치든 둘을 나눠 볼 수 있습니다.
반복 실행의 편차
전원을 연결하고 아무것도 하지 않는 기기에서는 이어지는 실행이 보통 몇 퍼센트 안에 들어옵니다. 그 안정성을 사 주는 것이 확인 단계의 ‘연속된 창’ 요구입니다. 배터리로 쓰거나 절전 모드이거나 본체가 따뜻할 때는 더 큰 편차와, 십중팔구 발열 제한 표시를 예상하세요. 벤치마크가 변덕스러운 게 아니라, 기기가 정말로 그만큼만 내주고 있다는 뜻입니다. 실행 전에 식히고 전원을 연결하는 것이 대표성 있는 숫자를 얻는 가장 효과적인 한 가지입니다. 브라우저 벤치마크가 잴 수 있는 것과 없는 것에서 그 숫자를 어떻게 다룰지 다룹니다.