브라우저가 단순한 렌더링 엔진을 넘어 AI 추론 환경으로 진화하는 흐름이 2026년을 기점으로 뚜렷해지고 있다. Google I/O 2026에서 발표된 WebMCP와 Built-in AI, 그리고 ONNX Runtime Web을 활용한 클라이언트사이드 AI 처리 아키텍처는 각각 다른 레이어에서 같은 방향을 가리킨다. 브라우저 탭이 AI의 실행 단위가 된다는 것. 이 변화는 기술 뉴스로 소비하고 끝낼 이야기가 아니다. 프론트엔드 개발자가 실제로 설계 결정을 바꿔야 할 타이밍이 온 것이다.
두 가지 흐름이 교차하는 지점
첫 번째 흐름은 웹 표준 레이어다. Chrome 개발자 데브렐팀이 Google I/O 2026에서 공개한 WebMCP는 HTML 폼과 JavaScript 함수를 AI 에이전트가 사용할 수 있는 도구로 노출하는 제안 명세다. navigator.modelContext.registerTool API로 사이트가 "여기서 검색이 되고, 장바구니에 담을 수 있다"는 능력을 에이전트에게 직접 알려주는 구조다. 핵심 차별점은 별도 MCP 서버 없이 현재 브라우저 탭이 도구 목록을 직접 공유한다는 점이다. 로그인 상태, 쿠키, 로컬 스토리지가 그대로 유지된 맥락에서 에이전트가 동작할 수 있어, 외부 서버 방식으로는 재현하기 어려운 사용자 컨텍스트를 온전히 살릴 수 있다.
두 번째 흐름은 구현 레이어다. 한 오픈소스 개발자가 최근 공개한 브라우저 기반 AI 배경 제거 도구는 이 방향의 현재를 가장 직접적으로 보여준다. @imgly/background-removal 라이브러리를 CDN으로 불러와 ONNX 세그멘테이션 모델을 WebAssembly 백엔드로 실행하고, Canvas API로 마스크를 추출해 편집 가능한 투명 PNG를 만들어낸다. 파이프라인은 Upload → ONNX 모델 로드 → WebAssembly 추론 → 마스크 생성 → Canvas 합성, 다섯 단계 모두 클라이언트에서 완결된다. 이미지가 서버로 나가지 않는다. 사용자 데이터가 누군가의 인프라에 머무르지 않는다.
프론트엔드 설계가 달라지는 세 가지
첫째, 데이터 흐름 설계에서 프라이버시가 아키텍처 결정이 된다. 기존에는 이미지나 문서를 서버로 올려 처리하는 것이 기본값이었다. 클라이언트사이드 AI 처리는 이 기본값을 뒤집는다. 약 40MB의 모델 웨이트를 최초 1회 다운로드하면 이후 처리는 캐시에서 즉시 실행된다. 서버 왕복이 없으므로 레이턴시가 제거되고, 데이터 보관 의무가 사라진다. 개발자 입장에서 이는 단순한 기술 선택이 아니라, "사용자 데이터를 어디서 처리할 것인가"라는 설계 원칙의 문제다. 특히 의료, 법률, 금융처럼 민감한 도메인에서 클라이언트사이드 AI 처리는 규제 대응 전략이 될 수 있다.
둘째, AI 결과물을 사용자가 수정할 수 있는 인터페이스 설계가 필수가 된다. ONNX 추론 결과는 완성품이 아니라 시작점이다. 앞서 언급한 배경 제거 도구는 AI 출력에서 알파 채널을 추출해 별도의 편집 가능한 그레이스케일 마스크 캔버스로 분리하고, 브러시와 지우개로 실시간 수정이 가능하게 설계됐다. 마스크의 R 채널이 출력 이미지의 알파 채널이 되는 구조다. 이 설계가 시사하는 바는 명확하다. AI가 처리한 결과를 그대로 노출하는 것이 아니라, 사용자가 개입하고 수정할 수 있는 레이어를 UI에 내장해야 한다는 것이다. "AI가 틀릴 수 있다"는 전제를 UX 설계에 구조적으로 반영하는 것이 이제 기본이 되어야 한다.
셋째, 에이전트가 탐색할 수 있는 시맨틱 구조가 새로운 기술 부채가 된다. WebMCP가 Chrome 149 Origin Trial로 열리면, 에이전트가 사이트의 기능을 이해하려면 기능이 명시적으로 노출되어 있어야 한다. 접근성 트리, 시맨틱 HTML, registerTool로 등록된 기능 목록—이것들이 에이전트에게는 사이트의 API 문서가 된다. 시맨틱하지 않은 마크업, 의미 없는 div 중첩, 접근성이 빠진 컴포넌트는 사람 사용자뿐 아니라 에이전트에게도 불투명한 블랙박스가 된다. Google I/O 발표에서 "시맨틱 HTML과 접근성, Baseline 같은 기본기에 충실할수록 에이전트 시대에 유리하다"고 반복 강조한 이유가 여기 있다.
성능 트레이드오프를 솔직하게 보면
클라이언트사이드 AI가 모든 상황의 답은 아니다. ONNX Runtime Web 추론은 일반 노트북 기준 2~5초, 모바일에서 8~15초가 걸린다. 고해상도 이미지 처리 시 세 개의 풀 해상도 캔버스가 메모리에 올라가 4000×3000 이미지라면 약 144MB를 차지한다. RAM이 4GB 미만인 모바일 기기에서는 실질적인 제약이 된다. 개발자는 "이 기능을 클라이언트에서 처리할 것인가, 서버에서 처리할 것인가"를 사용자 기기 프로파일, 데이터 민감도, 허용 가능한 응답 시간이라는 세 축으로 판단해야 한다. 하나의 정답이 있는 것이 아니라, 맥락에 따라 다른 아키텍처 결정이 필요하다.
지금 준비해야 할 것
2026년 하반기를 기점으로 WebMCP Origin Trial, Built-in AI의 멀티모달 확장, Gemma 모델 패밀리의 네이티브 함수 호출 지원이 순차적으로 풀린다. 이 타이밍에 프론트엔드 개발자가 지금 시작할 수 있는 것들이 있다. 기존 컴포넌트의 접근성 감사, 시맨틱 마크업 점검, navigator.modelContext API 실험, 그리고 ONNX Runtime Web으로 가벼운 클라이언트사이드 추론 프로토타입 하나를 직접 만들어보는 것. Modern Web Guidance(npx modern-web-guidance install)는 이 과정에서 AI 코딩 도구가 낡은 패턴을 제안하는 것을 막아주는 현실적인 보조 수단이 된다.
브라우저가 AI 실행 환경이 되는 흐름은 이미 시작됐다. 에이전트는 사이트를 탐색하고, 모델은 탭 안에서 추론하고, 사용자 데이터는 디바이스 밖으로 나가지 않는다. 이 새로운 레이어 위에서 프론트엔드 설계는 렌더링 최적화 너머의 질문들을 마주하게 된다. 기능을 에이전트에게 어떻게 노출할 것인가, AI 결과물을 사용자가 어떻게 수정할 수 있게 할 것인가, 추론을 어느 레이어에서 실행할 것인가. 이 질문들이 곧 일상적인 설계 결정이 될 것이다.