폰과 브라우저 안에서 돌리기: WebGPU, WASM, WebNN, Core ML 과 무엇을 어디서 할까

상태: 초안 (2026-10-16), 대부분 문서 기준. 폰·브라우저 안에서 우리 모델을 돌린 측정은 없습니다(미실측). 표준과 브라우저 지원은 W3C·브라우저 공급사 공식 글을 2026-10-16 에 열어 확인했습니다. JPEG 크기와 모델 파라미터 수는 이 시리즈의 서버 실측에서 가져왔습니다. 시리즈 「비전 모델 읽기 3」 7편. 모델을 들고 다니는 형식(ONNX)은 3편에 있습니다.

목차

• 1. 직관: 어디서 계산할까
• 2. 브라우저에서 계산하는 길
  • WebGL → WebGPU
  • WebAssembly(WASM): CPU 를 제대로
  • WebNN: 기기의 신경망 가속기
  • ONNX Runtime Web: 하나의 파일, 여러 백엔드
• 3. 앱에서: Core ML
• 4. 폰에서 이미 도는 모델들
• 5. 우리 모델을 폰으로 옮긴다면: 크기와 대역
• 6. 한계
• 7. 우리 프로젝트와의 연결
• 참고 문헌

1. 직관: 어디서 계산할까

카메라는 폰에 있습니다. 결과(점수판)도 폰 화면에 나옵니다. 그 사이의 모델만 서버에 있다면, 매 프레임 폰 → 서버 → 폰 왕복이 생깁니다. 모델을 폰으로 옮기면 왕복이 사라집니다. 하지만 폰은 GPU 가 작고, 오래 돌리면 뜨거워지고, 기종마다 성능이 열 배씩 다릅니다.

2. 브라우저에서 계산하는 길

WebGL → WebGPU

TensorFlow.js(Smilkov 외, 2019)는 브라우저의 그래픽 API(WebGL)로 신경망을 돌렸습니다. 텐서를 텍스처에 담고, 출력 원소마다 그래픽 셰이더를 한 번씩 돌리는 우회로였습니다. 그래도 차이가 컸습니다.

WebGPU 는 그래픽 API 를 빌리지 않고 GPU 계산을 직접 부르는 새 표준입니다. 셰이더 언어는 WGSL 입니다. 2026-10-16 기준 W3C 에서 WebGPU 와 WGSL 모두 「후보 권고 초안(Candidate Recommendation Draft)」 단계입니다(각각 2026-09-15, 2026-09-21 판). 브라우저 공급사 공식 글로 확인한 출시는 이렇습니다.

MDN 은 아직 「제한적 사용 가능(Limited availability)」 으로 표시하고, HTTPS 같은 보안 문맥에서만 쓸 수 있습니다. 16비트 부동소수(f16)는 Chrome 120 부터 셰이더 기능이 있는 기기에서 씁니다. 2편의 FP16 이 브라우저에서도 가능해진 셈입니다.

WebAssembly(WASM): CPU 를 제대로

GPU 로 보내는 데는 고정 비용이 있어서, 작은 모델은 CPU 가 이길 수 있습니다. 브라우저에서 CPU 를 빠르게 쓰는 길이 WebAssembly 이고, SIMD(한 명령으로 여러 수)와 스레드를 켜면 크게 달라집니다. TensorFlow.js 공식 저장소의 WASM 백엔드 표(Chrome 79, 2020년 무렵 기기라 오래된 수치)입니다.

같은 문서는 곱셈-덧셈 2천만–6천만 번짜리 가벼운 모델은 WASM 이 WebGL 과 비슷하고, 1억–5억 번이면 WASM 이 몇 배 느리다고 적었습니다. 3편에서 본 「부르기 비용 대 계산」 의 저울질이 브라우저에서도 그대로입니다.

WebNN: 기기의 신경망 가속기

요즘 폰과 노트북에는 신경망 전용 가속기(NPU)가 있습니다. WebGPU 로는 이것을 쓸 수 없습니다. WebNN 은 「합성곱」·「행렬곱」 같은 신경망 연산 단위로 그래프를 넘기면 브라우저가 CPU·GPU·NPU 중 알맞은 곳에서 돌리게 하는 W3C 표준입니다. 2026-10-10 판이 후보 권고 초안이고, 현재 판에서는 개발자가 장치를 직접 고르지 않고 「저전력」·「고성능」 같은 선호만 줍니다. 브라우저별 기본 출시 여부는 1차 자료로 확인하지 못했습니다.

ONNX Runtime Web: 하나의 파일, 여러 백엔드

3편의 ONNX 파일을 브라우저에서 돌리는 런타임입니다. 실행 공급자로 wasm(CPU)·webgpu·webgl·webnn 이 있고, 모든 연산자를 지원하는 것은 WASM 뿐이라 다른 공급자가 못 하는 연산은 WASM 으로 넘어갑니다. WebGL 공급자는 유지보수만 하고 성능은 WebGPU 를 권합니다(공식 문서). 이 문서의 브라우저 지원 표는 위 공급사 글보다 낡아 보였습니다 — 「런타임이 그 브라우저에서 시험했다」 와 「브라우저가 WebGPU 를 출시했다」 는 다른 이야기입니다.

3. 앱에서: Core ML

애플 기기의 Core ML 은 CPU·GPU·Neural Engine 을 함께 씁니다. computeUnits 를 「전부」 로 두면 운영체제가 장치를 고르고, 개발자가 CPU 만·CPU+GPU·CPU+Neural Engine 으로 좁힐 수 있습니다. 모델 압축 도구(coremltools)는 가중치 팔레트화(1·2·3·4·6·8비트 룩업 표), 가중치 INT4·INT8 과 활성값 INT8 선형 양자화, 가지치기를 줍니다. 문서는 압축이 크기는 확실히 줄이지만 지연 이득은 보장하지 않는다(어떤 백엔드는 가중치를 다시 풀어 계산한다)고 적고, 자기 모델·자기 기기에서 재 보라고 권합니다. 2편·4편과 같은 결론입니다.

4. 폰에서 이미 도는 모델들

• BlazePose(Bazarevsky 외, 2020): 사람 관절 33개를 2017년 휴대폰 CPU 코어 하나에서 Lite 모델로 약 30 FPS. 검출기는 첫 프레임과 놓쳤을 때만, 나머지는 이전 관절로 자른 영역에서 추적(5편).
• EfficientTAM(Xiong 외, 2024): 2023년 상위 휴대폰에서 1024×1024 입력 프레임당 261–1,011ms, 512×512 입력 80.6ms(논문 표 1·5, 정밀도 미기재).
• MobileNetV2(2018): 휴대폰 CPU 큰 코어 하나에서 75ms(4편).

공통점은 작은 모델 + 덜 자주 돌리기 입니다. 폰에서의 실시간은 모델 하나를 빠르게 하는 것보다 파이프라인을 설계하는 문제에 가깝습니다.

5. 우리 모델을 폰으로 옮긴다면: 크기와 대역

(파라미터 수 × 4·2·1바이트. 실제 파일에는 구조 정보가 더 붙습니다.)

공 모델은 웹 페이지와 함께 받아도 부담이 없는 크기입니다. 문제는 계산입니다. 이 모델은 512×288 해상도를 끝까지 유지하므로, 서버 쪽 노트북급 GPU 에서도 FP16 창 하나에 약 10ms 였습니다(1편). 폰 GPU 에서 30fps 를 낼 수 있을지는 재지 않았습니다(미실측). 탁구대 찾기는 경기 시작 때 한 번이면 되므로 폰에서 수백 ms 여도 괜찮지만, 34–136MB 를 받아야 합니다.

반대로 지금처럼 서버에서 돌리면 프레임을 올려 보내야 합니다. 이 시리즈의 서버 실측에서 같은 경기 화면의 JPEG 크기는 이랬습니다.

(서버 CPU 의 OpenCV 인코더 기준. 브라우저의 JPEG 인코더는 같은 품질 숫자에서 크기가 다를 수 있습니다 — 운영 설계 문서는 경기 영상에서 12–18KB 로 쟀습니다.) 512×288 로 줄여 보내는 것만으로 대역이 4분의 1 이 됩니다. 업로드가 느린 탁구장 와이파이에서 이 차이가 「되느냐 마느냐」 를 가릅니다.

6. 한계

• 폰·브라우저에서 우리 모델을 돌린 측정은 없습니다. 이 글의 폰 쪽 판단은 문서와 다른 모델의 공개 수치에 기댑니다.
• 브라우저 지원은 빠르게 바뀝니다. 위 표는 2026-10-16 에 연 공급사 글 기준이고, Firefox 의 다른 운영체제 출시 여부와 WebNN 의 기본 출시 여부는 확인하지 못했습니다.
• 공개 벤치마크 수치(TensorFlow.js 표들)는 여러 해 전 기기·브라우저의 값입니다. 방향(백엔드에 따라 수십 배)만 가져오고, 절대값은 옮기지 않아야 합니다.

7. 우리 프로젝트와의 연결

• 지금의 나눔: 폰(브라우저)은 카메라를 잡아 512×288 로 가운데 맞춤해 줄이고, JPEG(품질 0.7)로 30fps 까지 보내고, 돌아온 공 위치와 판정을 그립니다. 서버는 JPEG 풀기, 공 모델, 바운드·심판 규칙, 탁구대 찾기를 합니다. 모델과 규칙을 한곳에서 고치고 모두에게 같은 판정을 주기 위해서입니다.
• 폰에서 먼저 옮길 후보는 탁구대 찾기입니다. 경기 시작 때 한 번이라 지연이 덜 중요하고, 성공하면 「탁구대를 찾는 동안의 서버 왕복」 이 사라집니다. 공 모델은 매 프레임이라 폰 GPU 의 실측이 먼저입니다.
• 옮기려면 3편의 ONNX 내보내기와 2편의 정밀도 확인(FP16 에서 공 위치가 같은가)을 거쳐야 합니다. 그 실측은 다음 과제로 남겨 둡니다.

다음 글은 이 시리즈의 모든 조각을 TT Score 실시간 경로 하나에 올려 놓은 실제 예산표입니다.

티티 한마디. 제 공 모델은 6MB 라 폰에 쏙 들어가요. 그런데 폰 안에서 1초에 30번 생각할 수 있을지는 아직 아무도 안 재 봤어요. 재기 전엔 「된다」 고 말하지 않을래요!

참고 문헌

• Smilkov, D. et al. (2019). TensorFlow.js: Machine Learning for the Web and Beyond. SysML 2019. https://arxiv.org/abs/1901.05350
• TensorFlow.js WASM 백엔드 README. https://github.com/tensorflow/tfjs/blob/master/tfjs-backend-wasm/README.md
• W3C WebGPU. https://www.w3.org/TR/webgpu/ · WGSL. https://www.w3.org/TR/WGSL/ · WebNN. https://www.w3.org/TR/webnn/
• Chrome 개발자 블로그 — WebGPU 출시(113), Android(121), f16(120). https://developer.chrome.com/blog/webgpu-release
• WebKit 블로그 — Safari 26.0. https://webkit.org/blog/17333/webkit-features-in-safari-26-0/
• Mozilla Gfx 블로그 — Firefox 141 WebGPU. https://mozillagfx.wordpress.com/2025/07/15/shipping-webgpu-on-windows-in-firefox-141/
• MDN WebGPU API. https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API
• ONNX Runtime Web. https://onnxruntime.ai/docs/tutorials/web/
• Apple Core ML(MLComputeUnits), coremltools 압축 안내. https://developer.apple.com/documentation/coreml · https://apple.github.io/coremltools/docs-guides/source/opt-overview.html
• Bazarevsky, V. et al. (2020). BlazePose. CVPR Workshop. https://arxiv.org/abs/2006.10204
• Xiong, Y. et al. (2024). Efficient Track Anything. arXiv. https://arxiv.org/abs/2411.18933