WebGPU가 브라우저 AI의 문턱을 낮추고 있다. dev.to에 공개된 Grimhollow 사례는 그 가능성을 구체적으로 보여준다. 서버를 거치지 않고, 프롬프트가 브라우저 밖으로 나가지 않으며, 모델이 캐시되면 오프라인에서도 동작하는 AI 던전 마스터. 기술적으로는 꽤 설득력 있는 데모다. WebGPU가 행렬 연산을 GPU에 위임하면서 토큰 생성 속도가 실용 수준에 도달했고, 양자화 모델 덕분에 브라우저 메모리 안에서도 추론이 돌아간다.
하지만 이 흥분을 잠시 내려놓고 싶다. 기술이 가능해졌다는 것과, 그 기술을 내 제품에 올려도 된다는 것은 전혀 다른 이야기다. Grimhollow 자체도 솔직하게 고백하고 있다. 전용 GPU가 없는 구형 하드웨어에서는 응답 지연이 발생하고, 모델 초기 다운로드는 2~4GB다. 이 숫자들은 단순한 스펙이 아니라 사용자 경험의 진입 장벽이다. '기술적으로 작동한다'와 '사용자가 실제로 쓴다' 사이의 간극은 여전히 크다.
같은 날 눈에 띈 또 다른 글이 이 간극을 더 선명하게 보여준다. 한 개발자가 결제 플랫폼 Creem 위에 '운명이 결정하는 가격'이라는 개성 있는 동적 결제 메커니즘을 설계했다. 천간지지(天干地支)로 서버 타임스탬프를 변환해 1~99 사이의 금액을 산출하는 아이디어였다. 아이디어 자체는 제품의 세계관과 완벽하게 맞아떨어졌고, 구현 논리도 깔끔하게 완성됐다. 문제는 단 하나—Creem의 결제 API가 동적 금액을 지원하지 않는다는 사실을 코드를 짜기 전까지 한 번도 확인하지 않았다는 것이다.
이 두 사례가 함께 가리키는 지점이 있다. 설계가 내부적으로 얼마나 정교하게 맞물려 있든, 외부 환경이 그 전제를 받쳐주지 않으면 전체가 무너진다. Grimhollow의 WebGPU 아키텍처는 탄탄하다. 하지만 그 아키텍처가 빛을 발하려면 사용자의 기기가 WebGPU를 지원해야 하고, GPU 성능이 충분해야 하며, 수 기가바이트의 초기 다운로드를 감수할 의사가 있어야 한다. 이것들은 코드 바깥의 전제들이다. 결제 API 사례처럼, 코드를 짜기 전에 먼저 확인해야 할 것들이다.
프론트엔드 개발자 입장에서 브라우저 AI가 매력적인 이유는 분명하다. 서버 비용 없이 AI 기능을 추가할 수 있고, 사용자 데이터가 클라이언트를 벗어나지 않으며, 오프라인에서도 동작한다는 세 가지 약속이 동시에 실현된다. 하지만 이 약속들을 실제 제품에 이식하기 전에, 검증해야 할 전제 목록이 있다. 내 타깃 사용자의 기기가 WebGPU를 지원하는가? 브라우저별 호환성 현황은 어디까지 왔는가? 초기 모델 다운로드가 이탈로 이어지지는 않는가? 오프라인 캐시 전략은 어떻게 설계할 것인가? 이 질문들은 AI 기능을 붙이기 전에 답해야 할 것들이지, 붙이고 나서 발견해야 할 것들이 아니다.
빠른 프로토타이핑을 중시하는 흐름에서 이 검증 단계는 종종 '나중에'로 밀린다. AI 도구가 코드 생성 속도를 끌어올릴수록 이 유혹은 더 강해진다. Cursor로 컴포넌트를 뚝딱 만들고, v0로 화면을 빠르게 잡고, WebGPU 기반 추론 엔진을 붙이는 데 걸리는 시간이 짧아질수록, 검증 없이 전진하는 것이 더 자연스럽게 느껴진다. 하지만 결제 API 사례의 교훈은 정확히 그 반대 방향을 가리킨다. 설계가 내부적으로 매끄러울수록 외부 전제를 확인하지 않는 맹점이 생긴다.
실용적인 접근은 간단하다. 브라우저 AI를 프로덕트에 올리기로 결정했다면, 구현보다 먼저 '이 설계가 의존하는 외부 전제 목록'을 한 장에 정리하라. WebGPU 브라우저 지원율, 타깃 사용자 기기 스펙 분포, 모델 다운로드 크기와 이탈 임계값의 관계, 오프라인 지원 범위, 캐시 무효화 전략. 이 목록이 짧더라도, 하나라도 빠지면 그 위에 쌓은 모든 추론이 허공에 뜬다. 결제 API 개발자가 'Creem이 동적 금액을 지원하는가'라는 단 하나의 질문을 먼저 확인했다면, 두 번의 설계 사이클을 아낄 수 있었다.
브라우저 AI는 분명 방향이다. WebGPU 기반 온디바이스 추론이 가능해진 것은 프론트엔드 개발의 실질적인 지형 변화다. 클라우드 API에 의존하지 않는 프라이빗 AI, 오프라인 추론, 엣지에서의 실시간 응답—이것들은 특정 제품군에서 진짜 차별점이 될 수 있다. 다만 그 가능성을 제품으로 전환하는 과정에서, 기술의 흥분이 검증을 앞질러서는 안 된다. 작동하는 데모와 동작하는 제품 사이의 거리를 좁히는 것은 여전히 프로덕트 사고의 몫이다—AI가 코드를 얼마나 빨리 짜주든 관계없이.