macOS·iOS·iPadOS·visionOS의 WebGPU 도입 가이드

macOS·iOS·iPadOS·visionOS에서 WebGPU를 도입하는 법

WebGPU는 웹 애플리케이션이 GPU에서 그래픽과 계산 작업을 수행하도록 하는 웹 표준 API다. WebGL을 한 번에 “교체”하는 버튼이라기보다, 렌더링 파이프라인과 리소스 관리 방식을 현대 GPU에 맞춰 다시 생각하게 하는 기반이다. WebKit은 2025년 Safari 26 beta 발표에서 macOS, iOS, iPadOS, visionOS에 WebGPU 지원을 소개했고 새 웹사이트·웹 앱에서 WebGL보다 우선 검토할 수 있다고 밝혔다. 이후의 실제 지원 여부와 세부 기능은 브라우저·OS·기기 조합에 따라 달라질 수 있으니 배포 전 최신 릴리스 노트와 실기기 테스트가 필요하다.

WebGPU가 달라지는 지점

WebGL은 OpenGL 계열의 웹 그래픽 API다. WebGPU는 GPU 어댑터와 디바이스를 얻고, 버퍼·텍스처·파이프라인을 명시적으로 만들며, 명령을 인코딩해 제출하는 모델을 사용한다. 셰이더는 WGSL로 작성한다. 이런 모델은 3D 장면뿐 아니라 이미지 처리, 물리·행렬 계산, 머신러닝 전·후처리처럼 컴퓨트 셰이더가 유용한 작업까지 다룰 수 있다.

그러나 API의 표현력이 곧바로 체감 성능을 보장하지는 않는다. GPU로 보내는 데이터량, 텍스처 크기, 파이프라인 생성 시점, 셰이더 분기, 화면 해상도, 전력·발열 제한이 결과를 좌우한다. 특히 모바일에서는 데스크톱에서 매끄럽던 장면이 메모리 압박이나 열 상태에 따라 달라질 수 있다. “WebGPU이므로 빠르다” 대신, 구체적인 사용자 흐름과 목표 기기에서 프레임 시간·메모리·배터리 영향을 측정해야 한다.

기능 감지와 폴백

기본 진입점은 navigator.gpu지만, 존재 확인만으로 준비가 끝나지 않는다. requestAdapter()가 값을 주지 않거나 requestDevice()가 실패할 수 있고, 장치 손실도 처리해야 한다. 원하는 텍스처 포맷과 한도도 가정하지 말고 요청과 오류 처리를 설계한다. 아래처럼 초기화 실패를 정상적인 분기로 다루는 것이 좋다.

if (!navigator.gpu) {
  showFallback();
} else {
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) showFallback();
  else {
    try {
      const device = await adapter.requestDevice();
      device.lost.then(() => recoverOrFallback());
      startRenderer(device);
    } catch {
      showFallback();
    }
  }
}

폴백은 실패 화면일 필요가 없다. 지도 서비스라면 단순한 2D 지도, 제품 뷰어라면 이미지 갤러리, 데이터 분석이라면 CPU 기반 요약과 다운로드를 제공할 수 있다. 접근성 관점에서 복잡한 3D 조작만으로 정보를 전달하지 않는 것도 중요하다. 키보드와 보조기술 사용자가 동일한 핵심 과업을 끝낼 수 있어야 한다.

Apple 플랫폼에서의 테스트 전략

Safari의 WebGPU 지원은 같은 브랜드의 기기라도 동일한 GPU 특성을 뜻하지 않는다. macOS Safari, iPhone Safari, iPad Safari, visionOS Safari를 실제 대상별로 나누어 테스트한다. 개발 중에는 어댑터 정보에 의존해 지원 여부를 예측하기보다, 필요한 기능을 최소 단위로 검증하고 원격 측정은 개인정보를 최소화한 형태로 수집한다. 장시간 실행, 탭 백그라운드 전환, 메모리 경합, 회전과 창 크기 변경도 점검 항목이다.

WebKit은 Safari 26.2에서 visionOS의 WebXR가 WebGPU를 사용할 수 있게 된 사실도 별도로 알렸다. 이는 WebGPU 일반 지원과 WebXR 결합 지원을 같은 것으로 취급하면 안 된다는 좋은 예다. 필요한 API 조합을 하나의 호환성 주장으로 묶지 말고, 기능 단위로 문서와 테스트를 관리하자.

도입 판단

WebGPU가 적합한 경우는 대량 병렬 계산, 높은 빈도의 시각화, 현대 3D 파이프라인처럼 GPU 작업 자체가 제품 가치인 때다. 반대로 정적 페이지나 작은 상호작용에는 더 단순한 웹 기술이 유지보수와 접근성 면에서 낫다. 프레임워크를 사용한다면 해당 프레임워크의 Safari/WebGPU 경로도 별도로 확인한다. 최종 목표는 최신 API 사용이 아니라, 지원 기기에서는 더 나은 경험을 제공하면서 지원하지 않는 환경에서도 완성된 과업을 제공하는 것이다.

대표 출처

https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/
https://www.w3.org/TR/webgpu/

관련 글

koen