예전에는 웹 브라우저가 단순히 정보를 보여주는 창이라고 생각했다. 주소창에 링크를 넣으면 문서가 열리고, 쇼핑·검색·뉴스·영상 등이 표시되는 수준이었다. 하지만 지금 웹 브라우저는 ‘보여주는 프로그램’을 넘어 ‘직접 계산하고, 직접 실행하고, AI를 구동하는 플랫폼’으로 변하고 있다. 웹어셈블리(WebAssembly, WASM), 웹GPU(WebGPU), 웹NN(WebNN)이라는 기술 덕분이다. 이름은 어렵지만 핵심은 단순하다. 웹 브라우저가 스마트폰이나 컴퓨터처럼 능동적으로 일을 처리하는 주체가 되었다는 것이다. 이 변화가 웹 AI 확산의 토대가 되었으며, 앞으로 AI 서비스의 무게 중심까지 바꿀 흐름이다.

이 특별 기고는 AI 강국을 꿈꾸는 한국과 한국 독자들을 위해 구글 웹 AI의 리더 제이슨 메이즈(Jason Mayes)와 MediaPipe Web 창시자 타일러 멀린(Tyler Mullen)이 직접 작성했다.

웹 브라우저가 여전히 중요한 이유

웹 브라우저는 웹사이트에 접속하는 프로그램이다. 크롬(Chrome), 사파리(Safari), 엣지(Edge), 파이어폭스(Firefox) 같은 대표적인 브라우저들은 수억 명, 심지어 수십억 명의 사용자를 보유하고 있다. 크롬만 해도 전 세계에서 약 30억 명이 사용한다. 물론 스마트폰이나 노트북에서 웹 브라우저를 쓰는 것만이 온라인에 접속하는 유일한 방법은 아니다. 실제로 점점 더 많은 기기와 센서가 ‘스마트’해지면서 서로 연결되고 인터넷에 접속하고 있다. 이런 흐름을 흔히 ‘사물인터넷(IoT, Internet of Things)’이라고 부른다.

그럼에도 웹 브라우저가 여전히 새로운 웹 기술 개발의 최전선에 있는 이유는 명확하다. 첫째, 사용자 수가 압도적으로 많다. 둘째, 브라우저는 영상·음성·텍스트·게임 등 ‘인터넷에 존재하는 모든 것’을 처리할 수 있어야 하기 때문에 다른 앱보다 훨씬 넓은 범위의 기능을 감당해야 한다. 셋째, 브라우저는 여전히 인터넷과의 첫 접점이다. 검색엔진에 질문을 입력하거나, 다른 앱이 인터넷 관련 작업을 브라우저에 위임할 때(웹뷰를 통해) 브라우저가 작동한다. 넷째, 여러 플랫폼에 걸쳐 막대한 소프트웨어 엔지니어링 투자가 이뤄지고 있다.

웹 브라우저 개발에서 특히 중요한 것은 웹 표준이다. 웹은 일종의 무법지대 같은 곳이어서, 브라우저와 웹 콘텐츠 간에 정렬을 강제하는 것은 사실상 없다. 브라우저는 원하는 실험적 기술을 구현할 수 있고, 웹사이트는 원하는 대로 형식을 바꿀 수 있다. 따라서 어떤 형태의 합의 없이는 둘 다 쓸모가 제한적이다. 이 때문에 W3C(World Wide Web Consortium) 같은 단체들이 만들어져 표준과 모범 사례를 논의하고 합의한다. 특정 표준에 참여하고 동의하는 조직, 웹 콘텐츠 제작자, 브라우저가 많을수록 그 표준은 웹의 현실이 된다.

즉, 웹과 브라우저는 일종의 집단으로서 진화한다. 기술 개발자와 소비자가 서로 협력하며 성장하는 것이다. 이는 한 회사가 일방적으로 결정을 내릴 수 있는 다른 플랫폼에 비해 변화가 더디고 어려울 수 있다. 하지만 광범위한 변화가 필요할 때는 다양한 기기와 사용자를 자연스럽게 고려해야 하고, 프라이버시와 보안 같은 사용자 관심사를 염두에 두고 설계된 통합 크로스 플랫폼을 만들어내야 한다.

웹어셈블리, 브라우저에 ‘계산할 권한’을 부여하다

이제 웹 브라우저에서는 동영상 편집, 포토샵처럼 사진 필터 처리, MRI·CT 같은 의료 영상 분석이 가능하다. 이는 웹어셈블리라는 기술 덕분이다. 

웹 브라우저는 오랫동안 자바스크립트로 작성된 코드를 실행해왔다. 자바스크립트는 배우기 쉽고 유연하다. 그러나 속도가 느리다. 특히 머신러닝 엔진처럼 복잡한 프로그램을 돌리기에는 역부족이다.

반면 우리가 컴퓨터나 스마트폰에 설치하는 앱은 다르게 작동한다. 이런 앱들은 C++ 같은 언어로 작성된 후, 컴파일러라는 도구를 거친다. 컴파일러는 사람이 작성한 코드를 컴퓨터가 직접 이해하는 기계어로 번역한다. 이렇게 번역된 형태를 ‘바이너리’라고 부르는데, 바이너리는 컴퓨터 CPU가 바로 읽고 실행할 수 있어서 훨씬 빠르다.

더 빠른 실행을 위해 ‘어셈블리 언어’를 직접 사용하기도 하며, CPU가 이해하는 명령어에 가장 가까운 프로그래밍 언어다. CPU가 실제로 실행하는 것이 바로 이 어셈블리 코드이기 때문에 이를 직접 작성하면 프로그램을 가장 효율적으로 만들 수 있다.

웹에 컴파일러나 어셈블리 코드 같은 것을 만들면 앱의 성능을 크게 개선할 수 있고, 웹 스크립팅과 비웹 컴파일 기반 엔지니어링 간의 격차를 메우는 데도 도움이 될 수 있다. 하지만 웹 브라우저는 다양한 기기(따라서 다양한 기기 아키텍처)를 지원해야 하므로, 이를 보편적으로 설계하는 것은 매우 까다롭다.

초기 시도는 마이크로소프트의 액티브X(ActiveX), 구글의 네이티브 클라이언트(Native Client), asm.js 같은 기술이다. 그러나 이들은 모두 실패했다. 보안 문제가 있거나 특정 플랫폼에만 작동했거나 성능이 충분하지 않았다.

그러나 이들은 모두 웹어셈블리로 대체됐다. 웹어셈블리는 웹을 위해 특별히 설계된 새로운 어셈블리 언어다. 개발자는 이제 엠스크립튼(Emscripten) 같은 툴체인을 사용해 C++이나 러스트(Rust) 같은 비웹 코드를 웹어셈블리로 변환할 수 있다.

웹어셈블리를 안전하게 실행하기 위해 웹 브라우저는 가상 머신을 가동하는데, 브라우저 안에 새로운 미니어처 ‘기기’를 만드는 것이다. 이는 다른 웹 구조와는 상당히 다른 접근이며, 활발한 기능 개발이 이뤄지는 분야로 업데이트가 전체 성능에 큰 영향을 미친다. 예를 들어 여러 데이터를 동시에 처리하는 명령어인 SIMD 인트린식( intrinsics) 도입한 경우, 엑스엔엔팩(XNNPACK) 같은 CPU 기반 AI 추론 엔진이 대부분의 모델에서 두 배 이상 빠르게 작동하도록 만들다.

웹어셈블리 이전 브라우저는 기본적으로 계산을 할 수 없는 구조였다. 동영상 편집, 포토샵의 필터 처리, 게임 엔진의 물리 연산, 의료 영상 분석 같은 무거운 연산은 모두 별도의 앱이나 서버에서 수행될 수밖에 없었고, 웹은 그 결과를 화면에 보여주는 역할에 머물렀다. 웹이 약해서가 아니라 웹에 애초에 계산할 권한 자체가 없었기 때문이다. 웹어셈블리는 이 전제를 깨버렸다. C++·러스트(Rust) 같은 네이티브 언어로 만들어진 고성능 엔진을 브라우저 안에서 그대로 실행할 수 있도록 설계해, 웹 자체가 계산을 직접 수행할 수 있는 권한을 갖도록 만든 기술이다.

웹 워커의 등장과 공유 메모리 탄생

웹 멀티스레딩의 가장 중요한 혁신은 웹 워커(Web Workers)다. 웹 워커는 백그라운드에서 별도의 프로세스를 실행할 수 있게 해준다. 그러나 안전을 위해 새로운 프로세스는 설계상 다른 모든 요소로부터 완전히 격리된다. 워커와의 통신은 제한된 메시지 전달 시스템을 통해서만 가능하다.

이는 비웹 멀티스레딩과 매우 다르다. 비웹 환경에서는 작업 간에 무엇이든 쉽고 즉시 공유할 수 있다. 이 차이가 오랫동안 주요 효율성 병목을 야기했다. 시간이 지나면서 여러 확장 기능이 이 공유 문제를 해결해 다. 트랜스퍼러블(Transferables)로 통신 메커니즘을 더 효율적으로 만들거나, 쉐어드워커(SharedWorkers)로 워커 동작을 확장하는 방식이었다.

그러나 비웹 프로그램과 동일한 방식으로 공유하려면, 여러 웹어셈블리 모듈이 동일한 공간에서 협업할 수 있으려면 공유 가능한 메모리가 필요했다. 그것이 쉐어드어레이버퍼(SharedArrayBuffer)다. 웹 브라우저는 외부 세계와 사용자 기기 사이의 안전한 포털 역할을 해야 한다. 쉐어드어레이버퍼는 이것이 얼마나 어려운지 보여주는 훌륭한 사례다.

이 기능은 2018년 큰 찬사를 받으며 처음 도입됐다. 그러나 업계 전반에 걸친 중대한 하드웨어 취약점이 발견되면서 모든 주요 브라우저에서 제거됐다. 고해상도 타이밍 기능도 함께 제거됐다. 수년이 지난 후에야 쉐어드어레이버퍼가 다시 도입될 수 있었다. 웹 페이지와 브라우저가 선택적으로 적용할 수 있는 완전히 새로운 보안 모드 덕분이었다.

웹GL의 등장, 웹에서 GPU를 직접 쓰다

현대 기기에는 CPU 외에도 GPU(Graphics Processing Unit)를 사용한다. GPU는 원래 그래픽 전용으로 설계됐다. 화면에 이미지를 빠르게 그리기 위한 장치다. CPU와 GPU는 각자 다른 일에 특화되어 있다. CPU는 소수의 복잡한 작업을 순차적으로 처리하는 데 적합하다. 컴퓨터 프로그램을 실행하는 것처럼 말이다. 반면 GPU는 다수의 단순 작업을 병렬로 처리하는 데 적합하다. 이미지 내 모든 픽셀을 동시에 처리하는 것처럼 말이다.

이 때문에 GPU는 이미지 처리에 이상적이다. 브라우저들도 오랫동안 GPU를 활용해 사진과 동영상을 효율적으로 표시해 왔다. 하지만 초기에는 웹 개발자들에게 이 성능의 극히 일부만 노출됐다. 저수준 GPU API는 학습 곡선이 가파르고 플랫폼에 특화되어 있어서 광범위한 지원을 얻기 어려웠다. 대신 HTMLImageElement나 HTMLVideoElement 같은 래퍼가 선호됐다.

웹GL(WebGL)의 등장은 기존 관행을 깼다. 저수준 GPU 프로그래밍을 웹 개발자에게 직접 노출시킨 것이다. 웹GL은 2D 도형과 곡선 그리기에 주로 사용되는 HTMLCanvasElement 인터페이스에 새로운 모드로 추가됐다. 개발자에게 이미 어느 정도 익숙한 접근점이었다.

웹GL은 당시 가장 이식성이 뛰어난 그래픽 API 중 하나인 OpenGL ES 2.0을 직접 모델로 삼았다. 이 API는 이미 수많은 기기와 플랫폼에서 지원되고 있었기에, 웹GL을 보편적으로 실행하려는 브라우저들에게 유리한 출발점을 제공했다.
웹GL의 성공은 웹GL2(2017년, GLES 3.0 기반)로 이어졌다. 지난 10년 동안 웹GL과 웹GL2는 유니티(Unity) 같은 게임 엔진부터 구글 어스(Google Earth) 같은 맞춤형 디스플레이까지 고급 웹 그래픽의 기반이 됐다. 많은 머신러닝 작업은 이미지 처리와 유사하게 한 번에 많은 숫자에 대해 비교적 간단한 절차를 수행한다. 따라서 웹 AI도 GPU 사용으로 큰 이점을 얻는다.

그러나 문제가 있었다. AI가 필요로 하는 것과 웹GL이 제공하는 것이 달랐다. AI 모델이 처리하는 것은 색이나 이미지가 아니라 행렬이라는 거대한 숫자 표다. 수백만, 수억 개의 숫자를 격자 형태로 배열한 데이터 구조다.
대부분의 현대 GPU API가 지원하는 기능이 웹GL에는 빠져 있었다. 바로 컴퓨트 셰이더(compute shaders)다. 컴퓨트 셰이더는 GPU에게 그래픽이 아닌 순수 계산 작업을 지시하는 프로그램이다. 컴퓨트 셰이더를 사용하면 GPU를 순수한 수치 계산 목적으로 활용할 수 있어 효율성을 크게 높일 수 있다.

현재 버전의 OpenGL은 컴퓨트 셰이더를 지원한다. 최신 GPU API들(OpenCL, Metal, Direct3D 12, Vulkan)도 모두 이를 주요 사용 사례로 삼아 설계됐다. 따라서 웹도 다시 한번 현대화가 필요했다. 저수준 렌더링에서 더 저수준의 범용 GPU 사용으로 초점을 전환하기 위해서였다

웹GPU, 웹이 주도하는 GPU 혁신

그것이 웹GPU다. 애플, 구글, 모질라 등 웹 분야에 깊이 관여하는 기업들이 W3C 작업 그룹 “웹을 위한 GPU(GPU for the Web)” 아래 모여 웹에서의 GPU 활용 미래에 대한 공동 비전을 만들었다. 웹GPU는 이미 웹 AI 세계에서 상당한 파장을 일으켰다. 오늘날 거의 모든 로컬 생성형 AI 데모가 이를 기반으로 한다. 더 중요한 점은 웹GL과 달리 이번에는 웹이 주도권을 잡았다는 사실이다.

웹GL이 등장했을 때는 브라우저들이 모바일 트렌드를 따라가는 입장이었다. 하지만 웹GPU는 다르다. 웹GPU의 ‘웹’은 이제 잘못된 명칭이 됐다. Dawn이나 wgpu 같은 웹GPU 구현체들이 웹 외부의 GPU 프로그래밍에서 점점 더 인기를 얻고 있기 때문이다. 안드로이드 앱 같은 네이티브 환경에서도 웹GPU 기술을 채택하고 있다.

이는 컴퓨팅 분야 전반에 걸쳐 더 깊고(저수준) 더 넓은(크로스플랫폼) 기술 스택 통합을 주도하는 웹의 영향력이 커지고 있음을 강력히 입증한다. 웹GPU는 GPU를 그래픽 장치에서 AI·수학·데이터 연산 장치로 재정의한 기술이다. 브라우저는 이 기술을 통해 단순한 화면 출력 도구에서 대규모 AI 모델을 직접 실행하는 플랫폼으로 진화했다.

웹NN, 브라우저가 고성능 연산까지 처리하는 ‘완전한 실행 플랫폼’으로 진화한 이유

생성형 AI가 기술 기업의 주류로 급부상하면서 일부 브라우저가 웹 AI 특화 기능을 내장하기 시작했다.

크롬의 빌트인 AI(Built-in AI)는 구글의 LLM인 제미나이 나노(Gemini Nano)를 일상적인 사용 사례에 쉽게 적용할 수 있게 만든다. 제미나이 나노는 구글이 개발한 대화형 AI 모델 중 소형 버전으로, 일반 컴퓨터나 스마트폰에서도 작동할 수 있도록 최적화됐다. 개발자가 복잡한 설정 없이 브라우저에 내장된 AI를 바로 쓸 수 있다.

또한 새롭게 등장한 웹NN(Web Neural Network, 웹 신경망 네트워크) 표준은 머신러닝 추론을 통합하고 가속화하는 더 일반적인 접근 방식을 제공한다. 브라우저 자체가 AI 실행 환경을 제공하고 적절한 하드웨어에 연산을 위임하는 방식이다.

웹NN은 브라우저가 기기의 다양한 하드웨어 중 최적의 것을 자동으로 선택해 AI를 실행하도록 만든다. CPU, GPU, NPU(Neural Processing Unit, 신경망 처리 전용 칩) 중에서 선택한다. NPU는 최근 노트북과 스마트폰에 탑재되기 시작한 AI 전용 칩으로, AI 연산을 더 빠르고 전력 효율적으로 처리한다.

네트워크 상태, 배터리 잔량, 오프라인 여부 등 상황에 따라 실행 방식을 스스로 조율한다. 예를 들어 배터리가 부족하면 전력 소모가 적은 NPU를 사용하고, 네트워크가 끊어지면 기기 내에서 모든 처리를 완료한다.

계산 능력이 있어도 실제 문제에 적용할 수 없다면 무용지물이다. 브라우저는 미디어와 기기 입출력에 대한 개발자의 접근성과 처리 능력을 계속 개선해 왔다. 기기에 자이로스코프, GPS, 블루투스 같은 추가 기능과 센서가 탑재되면서 웹도 이에 맞춘 인터페이스를 추가했다. 하지만 여전히 가장 대중적인 미디어는 시청각 콘텐츠다. 이미지, 동영상, 오디오의 효율적인 공유 및 처리는 수많은 강력한 새 API 개발의 공통된 동력이 됐다.

영상은 초당 30프레임으로 재생해도 인간의 눈에는 선명하게 보일 수 있다. 하지만 음성은 비슷한 수준의 수용성을 유지하려면 초당 100프레임에 가깝게 재생되어야 한다. 따라서 다른 처리 과정의 간섭 없이 이러한 낮은 지연 시간을 지원하기 위해 오디오워클릿(AudioWorklets)이라는 특수한 격리된 백그라운드 작업자가 웹 오디오 API에 추가됐다.

지속적인 상태 유지와 사용자의 로컬 파일과의 상호작용 능력은 많은 대규모 애플리케이션의 핵심 요구사항이다. 따라서 보안을 유지하면서도 개선된 파일 시스템 상호작용과 로컬 캐싱 메커니즘이 중요하다.
이는 생성형 AI와 대규모 언어 모델(LLM)의 경우 두 배로 중요하다. 이러한 모델들은 일반적으로 기가바이트 단위로 측정되며, 기존 웹 AI 자산의 규모를 압도한다. 이로 인해 최근 등장한 오리진 프라이빗 파일 시스템(origin-private file system) 같은 기능이 특히 매력적이다.

10년 간의 진화, 뷰어에서 AI 플랫폼으로

지난 10년 동안 웹은 기능을 확장하며 단순히 문서나 정보를 보여주는 뷰어에서 소프트웨어를 실행하고 데이터를 처리하는 주체로 변했다. 웹어셈블리가 ‘웹은 성능이 부족하다’는 전제를 깨고 브라우저가 계산을 직접 수행할 수 있게 만들었고, 웹GPU가 GPU를 그래픽 장치가 아닌 대규모 병렬 연산 장치로 활용해 고부하 AI·시뮬레이션·영상 변환까지 웹에서 처리할 수 있는 기반을 마련했으며, 웹NN이 CPU·GPU·NPU 중 최적의 장치를 자동 선택하고 네트워크·배터리·오프라인 등 상황에 따라 실행 방식을 스스로 조율하도록 만들었다.

아마도 미래에는 브라우저 내 머신러닝 실험(WebNN, 크롬의 Gemini)이 AI를 브라우저의 핵심 기능으로 자리매김하려 시도함에 따라, 우리가 직접 이를 수행할 필요조차 없어질지도 모른다. 웹 AI 사용은 지난 몇 년간 기하급수적으로 성장했다. 그러나 파이썬(Python) 기반의 더 성숙한 머신러닝 생태계에 비하면 여전히 여정의 시작 단계다.

AI가 진화하면서 더 강력한 소형 모델이, 하드웨어가 진화하면서 NPU·TPU·ANE 같은 맞춤형 AI 가속기가, 웹이 진화하면서 더 쉬운 실행 환경이 만들어질 것이다. 이 세 가지가 맞물리면서 웹 AI는 미래의 AI PC에서 네이티브 앱 수준의 속도와 성능으로 수렴할 것이다. 그리고 AI가 웹 브라우저로 진화한 것처럼 웹사이트와 인터넷 자체로도 진화할 것이다. 웹사이트가 자신의 기능을 AI 에이전트에게 노출하면, 사람들은 단절된 API·프로그램·웹사이트를 넘나들며 복잡한 문제를 쉽게 해결할 수 있다. 이 미래의 웹을 ‘Web 4.0’이라고 부른다. 인간과 AI 에이전트가 인터넷에서 공존하며, 웹 페이지는 둘 다를 위해 최적화될 것이다.

이미 구글의 젬마2(20억 파라미터)를 사용해 완전히 클라이언트 측에서 실행되는 가상의 항공편 검색 페이지를 프로토타입으로 만든 사례도 있다. 브라우저에 내장된 에이전트에게 “사진을 자르고 구글 슬라이드에 넣어줘”라고 요청하면, 에이전트가 알아서 사이트를 찾아 작업을 수행하고 프레젠테이션을 만든다. “아마존에서 세제 주문해줘”라고 하면 가격만 확인하고 원클릭으로 주문이 완료된다. 현재 우리가 사용하는 컴퓨팅 파워의 3분의 2는 웹에서 소비된다. 브라우저가 이미 하고 있는 모든 일을 더 빠르고 자연스럽게 수행하는 관문이 되는 것은 당연하다. 물론 더 많은 작업과 보안 검토가 필요하지만, 데스크톱 우선 웹에서 모바일 우선 웹으로 진행한 것처럼, AI 우선 웹으로의 진행이 시작될 것이다.