카페에서 누군가 주민등록증을 무료 PDF 도구에 업로드하는 장면을 상상해보자. 파일을 올리고, 결과를 받고, 탭을 닫는다. 그 사람의 이름·주소·생년월일은 자신이 전혀 모르는 서버를 통과했다. 보관 기간은? 접근 주체는? 어느 나라 개인정보법의 적용을 받는가? 아무도 모른다. Dev.to에 공개된 한 개발자의 회고처럼, 이것은 예외적인 상황이 아니다. 하루에도 수억 명이 반복하는 일상이다.
흥미로운 건 이 문제의 해법이 이미 브라우저 안에 있다는 사실이다. 2025년의 브라우저는 단순한 문서 뷰어가 아니다. WebAssembly와 ONNX Runtime Web, WebGPU 가속이 결합되면, 3년 전 클라우드 서버에서나 돌리던 AI 추론 파이프라인이 브라우저 탭 안에서 그대로 실행된다. 배경 제거에 쓰이는 BiRefNet 같은 SOTA 모델이 MIT 라이선스로 클라이언트에서 돌아가고, PDF 병합·압축·텍스트 추출이 파일을 서버에 한 바이트도 보내지 않은 채 완료된다. "1시간 후 삭제"라는 문구는 약속이지만, '받은 적 없는 파일'은 삭제할 것 자체가 없다. 아키텍처가 다르다.
물론 트레이드오프는 있다. BiRefNet 라이트 모델은 첫 로드에 약 150MB를 다운로드한다. 이를 해결하는 방식이 흥미롭다—UI를 즉시 렌더링하고, 모델은 Web Worker에서 백그라운드 로딩한다. 이후 방문부터는 디바이스 로컬 캐시에서 2초 이내에 불러온다. 추론 역시 Web Worker에서 실행되므로 메인 스레드가 블로킹되지 않는다. Next.js 15 + TypeScript + Tailwind + Hugging Face Transformers.js + pdf-lib 스택이 이 흐름을 받쳐준다. PDF 처리의 경우 업로드·다운로드 왕복이 없으니 오히려 클라우드보다 빠른 경우도 있다.
이 클라이언트 사이드 AI 처리 흐름은 더 큰 패러다임 전환과 맞닿아 있다. Dev.to의 Gemma 4 관련 분석이 포착한 핵심은 이렇다—AI는 더 이상 '방문하는 곳'이 아니라 '내장되는 것'으로 바뀌고 있다. Gemma, Llama, Mistral, Phi 같은 오픈 모델이 중요한 이유는 클라우드 AI를 대체해서가 아니다. AI가 존재할 수 있는 위치를 확장하기 때문이다. 폰, 엣지 디바이스, 로컬 개발 환경, 오프라인 워크플로우—브라우저는 그 진입점 중 하나였을 뿐이다. 'intelligence-per-parameter'라는 표현이 의미심장하다. 가장 강력한 단일 시스템을 만드는 것과, 얼마나 많은 능력을 일상적인 환경에 집어넣을 수 있는가는 전혀 다른 경쟁이다.
클라이언트에서 AI 처리가 자리를 잡으면, 자연스럽게 다음 질문이 따라온다. 이 로컬 AI를 외부 에이전트나 도구 체계와 어떻게 연결할 것인가? 여기서 MCP(Model Context Protocol) 도구 설계가 등장한다. Dev.to에서 공유된 MCP 설계 원칙은 단순하지만 간과하기 쉬운 통찰을 담고 있다—모델은 구현 코드를 보지 못한다. 모델이 판단하는 건 도구 이름, 설명, 입력 스키마 세 가지뿐이다. process_request(data) 같은 모호한 설계는 모델이 혼란을 일으키는 직접적 원인이고, get_user_orders(user_id, limit) / cancel_order(order_id) / search_products(query) 처럼 단일 책임, 명확한 동사+명사 구조로 쪼개야 모델이 올바른 선택을 내릴 수 있다.
이 세 층위를 연결하면 하나의 아키텍처 그림이 완성된다. ① 브라우저에서 WebAssembly + ONNX로 AI 추론을 로컬 실행하고, ② Web Worker로 UI 블로킹 없이 처리하며, ③ 필요한 경우 MCP 도구 설계 원칙에 따라 명확한 단일 책임 인터페이스로 에이전트와 연동한다. 서버는 선택지가 되고, 프라이버시는 아키텍처 기본값이 된다. 프론트엔드가 단순히 API를 호출하는 레이어가 아니라, AI 추론 자체를 품는 런타임으로 진화하는 순간이다.
실무적으로 이 전환이 프론트엔드 개발자에게 요구하는 것은 명확하다. 첫째, 어떤 AI 처리를 클라이언트에 내릴 수 있는지 판단하는 기준—모델 크기, 추론 지연, 캐시 전략. 둘째, Web Worker + Transferable Objects 같은 브라우저 병렬 처리 설계. 셋째, 에이전트 연동을 고려한다면 MCP 도구의 단일 책임 원칙과 명시적 입력 스키마. 이 세 가지를 묶어 설계할 수 있는 개발자는 '서버 의존을 기본으로 보는' 관성에서 벗어나 진짜 다른 아키텍처를 만들 수 있다.
브라우저가 AI 런타임이 된다는 말은 과장이 아니다. 오히려 지금 이 전환의 초입에 있다는 것이 더 정확하다. 클라우드가 사라지는 게 아니라, 클라이언트가 더 많은 것을 자급자족하게 된다. 프론트엔드의 무게중심이 이동하고 있다—화면을 그리는 일에서, 화면 안에서 추론하는 일로.