WebGPU로 브라우저 AI를 돌릴 수 있을까? 지원 여부와 로컬 처리 확인

투명 유리 프레임 뒤에 놓인 금속 방열판. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

WebGPU를 지원하는 브라우저라면 GPU 계산을 웹 애플리케이션에서 사용할 수 있습니다. 하지만 navigator.gpu가 보인다는 사실, 실제 모델이 GPU에서 실행된다는 사실, 입력 데이터가 외부로 전송되지 않는다는 사실은 서로 다른 확인 항목입니다.

브라우저 이름만 보지 말고 secure context, 어댑터·장치 확보, 모델 실행, fallback, 네트워크 전송을 따로 확인해야 합니다.

WebGPU는 모델이 아니라 계산 접점입니다

web.dev 지원 안내는 주요 브라우저의 WebGPU 지원 상황과 운영체제별 범위를 정리합니다. MDN은 WebGPU API가 secure context(HTTPS)에서만 노출되며 아직 모든 주요 브라우저에서 동작하는 Baseline 기능은 아니라고 표시합니다. WebGPU는 그래픽과 범용 GPU 계산을 위한 웹 API입니다. 어떤 모델 형식을 읽을지, 연산을 어떻게 배치할지, 토크나이저와 메모리를 어떻게 관리할지는 그 위의 런타임이 담당합니다.

web.dev의 해당 문서 스냅샷은 Chromium 계열의 Windows·macOS·ChromeOS, 일부 Android 조건과 Firefox·Safari의 OS·버전별 범위를 따로 열거합니다. 따라서 브라우저 이름만 보고 지원한다고 결론내리지 말고 실제 사용자 조합에서 확인해야 합니다.

따라서 “WebGPU 지원”만으로 특정 AI 모델의 호환성이나 속도를 보장할 수 없습니다. 같은 브라우저 버전이라도 OS, GPU, 드라이버, 전원 정책과 장치 제한이 다를 수 있습니다.

지원 여부를 네 단계로 나눕니다

1. API 노출

console.log("navigator.gpu:", Boolean(navigator.gpu));

이 값이 false면 현재 문맥에서 API를 사용할 수 없습니다. true여도 끝이 아닙니다.

2. 어댑터 확보

MDN requestAdapter 문서는 적절한 어댑터를 얻지 못하면 결과가 null일 수 있다고 설명합니다.

const adapter = navigator.gpu
  ? await navigator.gpu.requestAdapter()
  : null;
console.log(adapter ? "adapter available" : "no adapter");

3. 장치와 한도

어댑터에서 장치를 요청한 뒤 필요한 feature와 limit을 런타임 요구사항과 비교해야 합니다. requestDevice()에 지원되지 않는 requiredFeatures나 requiredLimits를 넣으면 요청이 실패할 수 있습니다. 어댑터가 fallback adapter일 수도 있어 소프트웨어 구현으로 동작하거나 성능·개인정보 조건이 달라질 수 있으므로, 필요한 경우 isFallbackAdapter도 확인합니다.

const requiredFeatures = [];
const requiredLimits = {};
const device = await adapter.requestDevice({
  requiredFeatures,
  requiredLimits,
});

device.lost.then(info => {
  console.warn("device lost:", info.reason, info.message);
});

큰 모델은 모델 파일 크기 외에도 중간 텐서와 캐시가 필요합니다. 장치를 얻었다는 것과 메모리 요구를 만족한다는 것은 다르고, 장치 손실 뒤에는 버퍼·텍스처를 다시 만들거나 명확한 fallback을 실행해야 합니다.

4. 실제 연산 경로

라이브러리가 WebGPU 초기화 실패 시 WASM·CPU로 fallback할 수 있습니다. 앱 화면에 “브라우저 AI”라고 표시돼도 개발자 도구의 로그, 런타임 backend 정보, 실행 시간을 통해 실제 backend를 확인해야 합니다.

로컬 실행과 네트워크 미사용은 같은 말이 아닙니다

모델 추론이 GPU에서 일어나더라도 처음 모델 파일을 CDN에서 받을 수 있고, 분석 로그나 오류 보고가 외부로 갈 수 있으며, 애플리케이션이 입력 일부를 별도 API로 보낼 수 있습니다.

흐름	확인할 질문
HTML·JavaScript 로드	어느 origin에서 코드를 받는가
모델 다운로드	파일 URL, 크기, 캐시 위치는 어디인가
입력 전처리	브라우저 안에서 수행되는가
추론	WebGPU, WASM, 원격 API 중 무엇인가
결과 저장	IndexedDB·메모리·서버 중 어디인가
분석·오류 보고	입력이나 결과가 포함되는가

“로컬 AI”를 주장하려면 추론 위치뿐 아니라 전체 데이터 흐름을 봐야 합니다. 개발자 도구 Network 탭에서 추론 전후 요청을 기록하고, 모델 파일 요청과 사용자 데이터 요청을 구분하는 것이 현실적인 출발점입니다.

안전한 공개 샘플로 확인합니다

민감한 문서로 첫 테스트를 하지 않습니다. 공개 가능한 짧은 텍스트와 기대 출력을 준비해 다음을 기록합니다.

1. 브라우저·OS·GPU 정보
2. adapter와 device 확보 여부
3. 선택된 backend
4. 최초 모델 다운로드와 이후 캐시 실행 차이
5. 입력 직전부터 결과 직후까지의 네트워크 요청
6. offline 모드에서 재실행 가능 여부
7. CPU fallback 때 결과와 오류 표시

offline에서 실행된다는 사실은 이전에 모델과 코드가 캐시됐다는 조건을 포함할 수 있습니다. 새 장비의 첫 실행까지 오프라인이라고 일반화하면 안 됩니다.

제품에 넣을 때 실패 화면부터 설계합니다

WebGPU가 없는 사용자를 빈 화면으로 보내면 안 됩니다. 선택지는 대략 세 가지입니다.

• 작은 모델을 WASM/CPU로 실행하되 느림을 표시
• 서버 추론으로 전환하되 전송 사실과 정책을 표시
• 기능을 비활성화하고 지원 조건을 안내

자동 fallback은 편하지만 개인정보 경계를 바꿀 수 있습니다. 로컬에서 서버로 바뀌는 fallback이라면 사용자가 알 수 있어야 합니다. 같은 이유로 GPU 메모리 부족, 탭 백그라운드 전환, 장치 손실과 모델 다운로드 실패도 각각 구분해 보여주는 편이 낫습니다.

정리

WebGPU는 브라우저가 GPU 계산을 사용할 수 있게 하는 접점이지 AI 모델이나 개인정보 보호 기능 자체가 아닙니다. API 노출, adapter, device, 실제 backend, 네트워크 흐름을 차례로 확인해야 “이 기기에서 이 모델이 로컬로 실행됐다”는 좁은 결론을 낼 수 있습니다.

자료 확인일은 2026년 9월 7일입니다. 예시는 web.dev와 MDN 문서를 바탕으로 한 확인 절차이며, 이 글에서 특정 브라우저·GPU 조합의 속도나 오프라인 동작을 실측하지 않았습니다.