당신의 three.js 장면에 블룸(bloom, 밝은 곳이 번져 빛나는 효과)이나 윤곽선·필름 그레인 같은 후처리(postprocessing)를 얹었더니, 개발 노트북 외장 모니터에서는 60fps 인데 Retina 맥북이나 고해상도 폰에서는 20fps 대로 떨어진다. 화면이 눈에 띄게 느려짐을 느낀다. 그래서 모델의 삼각형을 줄이고, 입자를 걷어 내고, 드로우 콜(draw call)을 합친다. 그런데 fps 가 그대로다. 제품 소개 페이지의 3D 히어로든, 사내 대시보드의 지도 시각화든, 웹 게임이든 같은 일이 생긴다.
후처리가 있는 장면에서 프레임 시간을 정하는 것은 무엇인가
전체 화면 후처리가 있는 장면의 프레임 시간은 장면의 복잡도가 아니라 "화면 픽셀 수 × 패스마다 픽셀 하나에 하는 일"이 정한다. 후처리 패스는 화면을 덮는 사각형 하나를 그리면서 모든 픽셀에서 셰이더를 한 번씩 돈다. 패스가 다섯이면 화면을 다섯 번 칠한다. 이렇게 픽셀을 칠하는 속도가 상한이 되는 상태를 필레이트 병목(fill-rate bottleneck)이라 부른다. 이 상태에서는 삼각형이 두 배여도, 입자가 0개여도 프레임 시간이 거의 안 움직인다.
그래서 기기의 장치 픽셀 비율(devicePixelRatio)이 1 에서 2 로 오르면 픽셀이 네 배가 되고, 후처리 비용도 그대로 네 배가 된다. 같은 코드가 외장 모니터에서는 빠르고 Retina 에서 느린 이유가 이것이다.
내 장면이 픽셀 수에 묶였는지 어떻게 아나
두 가지만 해 보면 된다.
- 창을 절반 크기로 줄여 본다. 픽셀이 ¼ 이 됐을 때 프레임 시간이 크게 줄면 픽셀에 묶인 것이다.
- 장면 쪽을 줄여 본다. 삼각형·입자·드로우 콜을 크게 줄였는데 프레임 시간이 측정 오차 안이면, 장면이 아니라 화면을 칠하는 일이 비싼 것이다.
둘 다 그렇다면 장면 최적화는 멈추고 아래 순서로 간다.
어디부터 줄이나 — 다섯 단계
- 패스를 하나씩 꺼 가며 잰다. 짐작으로 고르지 않는다. 후처리 셰이더에서 비싼 것은 흔히 텍스처를 읽는 횟수가 아니라 셰이더 안에서 계산하는 절차적 노이즈(procedural noise)다. 샘플 수부터 줄이면 엉뚱한 곳을 깎는다.
- 원래 흐린 패스는 해상도를 낮춘다. 블룸·번짐·안개처럼 결과가 뿌연 효과는 절반 해상도로 돌려도 눈에 거의 안 띈다. 렌더 해상도 전체를 낮추는 것(
setPixelRatio)과 비슷한 이득을 선명도 손실 없이 얻는다. 둘을 함께 써도 된다. - 매 프레임 안 바뀌는 계산은 한 번 굽는다. 종이 결·필름 그레인처럼 화면 좌표만의 함수인 노이즈는 카메라·시간·장면과 무관하다. 창 크기가 바뀔 때 한 번 렌더 타깃(render target)에 구워 두고 매 프레임 텍스처로 읽는다. 1~4픽셀짜리 고운 결은 원본 해상도에 최근접 필터(NearestFilter)로, 수십 픽셀짜리 거친 결은 ¼ 해상도로 나누면 메모리도 아낀다.
- 다음 패스가 덮을 일은 앞에서 하지 않는다. 후처리가 윤곽선을 새로 긋거나 번짐을 넣는다면, 장면 패스의 MSAA(다중 샘플 안티에일리어싱)는 거의 보이지 않으면서 픽셀마다 샘플 수만큼 메모리와 해소(resolve) 비용을 낸다. 꺼 보고 화면 차이를 픽셀로 잰다.
- 셰이더 노드 언어라면 식이 몇 번 펼쳐지는지 본다. three.js 의 TSL(셰이딩 언어 노드) 노드는 변수가 아니라 식이라서, 루프 안에서 여러 번 참조하는 노드에
.toVar()를 붙이지 않으면 참조할 때마다 계산이 다시 펼쳐진다. "최적화"한다고 루프로 묶었다가 더 느려질 수 있다.
후처리 성능 점검 순서
1. 창을 절반으로 줄여 프레임 시간이 크게 줄면 → 픽셀(필레이트) 병목
2. 패스를 하나씩 끄고 ms 를 적는다 (가장 비싼 패스부터)
3. 뿌연 패스(블룸·번짐) → 절반 해상도
4. 화면 좌표만의 계산(노이즈·종이 결) → 리사이즈 때 한 번 굽기
5. 뒤 패스가 다시 그리는 것(MSAA 등) → 끄고 픽셀 차이 측정
6. 바꾼 뒤 "그림이 안 바뀌었다"는 눈 대신 전후 픽셀 차이로 확인
우리가 겪은 일
- 블룸 장면이 Retina 에서 22fps. 삼각형 +29%, 입자 14,000 → 0 은 둘 다 측정 오차 안이었고, 비용은 픽셀 1,000개당 약 4µs 로 픽셀 수에 비례했다. 블룸 패스를 절반 해상도로(+17%) 렌더 배율을 1.5 로(+20%) 낮추자 프레임이 30.6ms → 18.0ms 가 됐다.
- 4× MSAA 를 끄자 프레임 10~12ms → 8.3ms. 후처리가 선을 새로 긋는 렌더러라 화면 차이는 실루엣 픽셀의 0.7% 뿐이었다. 두 장의 16비트 실수 버퍼와 깊이에 4샘플이면 픽셀당 80바이트, 290만 픽셀에서 232MB 였다.
- 화면 좌표만의 노이즈를 리사이즈 때 한 번 굽자 24.6ms → 8.4ms(336만 픽셀 기준, 추가 메모리 약 12MB).
- 루프로 묶은 노이즈가 오히려 느려졌다.
.toVar()없이 8번 도는 루프에서 노이즈가 16번 펼쳐져 24.6ms → 33.3ms 가 됐다.
주의할 것
- 해상도가 이미 화면 주사율 상한(vsync)에 닿는 작은 캔버스에서는 무엇을 켜고 꺼도 같은 숫자가 나온다. 차이는 큰 캔버스·높은 배율에서 잰다.
- 자동화 브라우저나 백그라운드 탭에서 잰 fps 는 실제 사용자 환경과 다를 수 있다. 숫자는 포커스된 실제 브라우저에서 확인한다.
- 이 글의 TSL 동작은 2026-10 기준 three.js r186 에서 확인한 것이다.