브라우저가 AI를 '호출'하는 게 아니라 AI를 '내장'하는 시대가 현실로 다가왔다. Chrome 138이 오리진 트라이얼로 공개한 Prompt API는 Gemini Nano를 브라우저 네이티브 API로 노출한다. prompt()로 단발성 응답을, promptStreaming()으로 ReadableStream 기반 스트리밍을 선택할 수 있고, 세션 클론과 AbortSignal로 섬세한 흐름 제어까지 가능하다. 텍스트를 넘어 HTMLImageElement·AudioBuffer 같은 멀티모달 입력도 지원한다. 겉으로는 또 하나의 API처럼 보이지만, 이 변화의 핵심은 서버 왕복 없이 브라우저 자체가 추론 런타임이 된다는 데 있다.
이 흐름이 흥미로운 건 기술적 신기함 때문만이 아니다. Chrome의 Built-in AI PM이 Hacker News에서 직접 언급했듯, 온디바이스 추론이 진짜 힘을 발휘하는 영역은 '무한 스크롤 피드 전체를 실시간으로 변환하는 것'처럼 클라우드 API로는 토큰 비용이 감당되지 않는 고빈도 작업이다. 프라이버시 민감한 DM이나 개인 피드를 제3자 서버로 보내지 않아도 되는 점도 마찬가지다. 비용·지연·프라이버시라는 세 제약을 동시에 풀 수 있는 구조—이게 브라우저 내장 AI가 만드는 진짜 설계 공간이다.
물론 현실적인 마찰도 있다. 모델 다운로드 크기가 브라우저 본체보다 몇 자릿수 크고, 첫 토큰 전에 그 과정을 마쳐야 한다. 브라우저마다 뒤에 붙는 모델이 다르면—Chrome은 Gemini Nano, Edge는 아마 Phi4—프롬프트 튜닝의 파편화 문제가 생긴다. WebGL처럼 능력을 탐지해 분기할 방법도 아직 없다. responseConstraint로 JSON 스키마를 강제하거나 initialPrompts로 컨텍스트를 주입하는 정교한 기능이 있어도, 모델 품질 불일치를 숨긴 채 기능을 출시하는 건 사용자가 설치한 사전에 결과가 좌우되는 소프트웨어를 내놓는 것과 같다는 지적은 새겨들을 만하다.
한편, MCP(Model Context Protocol)는 다른 방향에서 프론트엔드의 풍경을 바꾸고 있다. 개발자 evan-moon이 자산 관리 도구를 CLI 30개·MCP 도구 50개로 구현하며 정리한 통찰은 단순한 구현기가 아니다. 그가 발견한 핵심은 MCP 도구 설계에서 가장 오래 붙잡고 있어야 했던 건 코드가 아니라 함수의 '설명'이었다는 것이다. 시그니처는 함수가 무엇을 받는지는 말하지만, 언제 불려야 하는지는 말하지 못한다. LLM 호출자에게는 그 '언제'가 전부다.
이 발견은 MCP가 RPC와 결정적으로 갈라지는 지점을 드러낸다. RPC는 호출자가 대상을 신뢰하는 구조지만, MCP는 도구를 만드는 쪽이 호출자(LLM)를 신뢰해야 한다. 신뢰의 방향이 뒤집힌다. 그래서 add_txn에 "Use this when... Do NOT use this for..." 형태로 호출 시점과 경계를 명시해야 비로소 LLM 호출이 안정된다. 도널드 노먼이 말한 어포던스—형태가 사용 방법을 시사하는 것—가 MCP에서는 description이 그 역할을 맡는 셈이다. 시그니처는 선언이고, 설명은 부탁. 인터페이스 설계에 '설득의 언어'가 들어온 것이다.
단일 책임 원칙(SRP)으로 get_holdings, get_prices, get_pnl을 잘게 나누면 LLM이 사용자의 "내 포트폴리오 어때?" 한 마디에 다섯 번 이상 도구를 호출해야 한다. 응답은 느려지고 어긋날 여지가 커진다. 반면 show_portfolio를 보유 종목·평균 매수가·평가금액·손익을 한 번에 반환하는 '무거운 도구'로 설계하면 LLM은 의도에 직접 닿는다. SRP는 함수를 만드는 사람의 미덕이고, 어포던스는 도구를 쓰는 사람의 미덕—호출자가 LLM으로 바뀌면 이 미덕의 무게가 역전된다.
이 흐름은 이미 시장에서도 확인된다. 웹빌더·커머스 플랫폼 식스샵은 MCP 기능을 무료 플랜까지 전면 개방했다. Claude, Cursor, ChatGPT, Gemini CLI 등 주요 AI 도구로 식스샵을 직접 제어하고, Figma·Google Stitch와 연동해 디자인 결과물을 바로 웹사이트로 배포하는 것이 목표다. 자연어로 블록을 생성하고 기획부터 배포까지 자동화하는 것—MCP가 단순한 개발자 도구가 아니라 비개발자를 포함한 넓은 사용자층의 워크플로우 인프라로 확장되고 있다는 신호다.
두 흐름이 교차하는 지점에서 프론트엔드 개발자에게 의미 있는 질문이 생긴다. 브라우저 내장 AI는 '서버 없이 AI 기능을 넣는' 선택지를 현실화하고, MCP는 '표준 인터페이스로 AI 도구를 연결하는' 문법을 만든다. 이 두 레이어가 결합하면—브라우저가 MCP 클라이언트로 동작하며 온디바이스 모델을 호출하는 시나리오—'백엔드 없이, 표준 인터페이스로, 프라이버시를 지키며 AI 기능을 제공하는 프론트엔드'가 가능해진다. 아직 그 조합이 완성된 건 아니지만, 방향은 이미 선명하다.
프론트엔드 개발자로서 지금 이 시점에 체크해야 할 것은 두 가지다. 첫째, Prompt API 오리진 트라이얼을 직접 써보면서 어떤 사용자 문제를 서버 없이 풀 수 있는지 탐색할 것. 비용과 지연이 문제였던 고빈도 클라이언트사이드 AI 작업이 1순위 후보다. 둘째, MCP 도구를 설계한다면 '시그니처'보다 'description'에 더 많은 시간을 쓸 각오를 할 것. 함수 이름이 아니라 호출 시점과 경계를 설득하는 언어—그게 LLM 호출자를 위한 인터페이스 설계의 새로운 핵심이다. 인터페이스 설계의 무게중심이 강제에서 설득으로 이동하는 것, 이건 일시적인 변화가 아니라 프론트엔드가 다루는 '호출자'의 범위 자체가 넓어지는 구조적 전환이다.