API 키 없이 AI를 쓰는 시대가 열렸다
Chrome 148부터 Gemini Nano가 브라우저에 내장되고, Prompt API가 웹 페이지에 정식 공개됐다. 이게 단순한 신기능 추가처럼 들릴 수 있지만, 프론트엔드 개발자 입장에서는 꽤 근본적인 전환점이다. 지금까지 '언어 모델이 필요한 기능'은 곧 'API 키 관리 + 토큰 비용 + 서버 프록시 구축'을 의미했다. 작은 사이드 프로젝트나 무료 공개 도구라면 그 비용 구조 자체가 기획을 죽이는 경우가 많았다. dev.to의 실전 사례 글에 따르면, Gemini Nano는 모델 자체가 Chrome과 함께 배포되기 때문에 추론 서버도, API 청구서도, 네트워크 요청도 없다. 프롬프트와 응답이 물리적으로 사용자 기기 밖을 벗어나지 않는다.
온디바이스 AI의 실제 작동 방식
코드는 놀라울 정도로 단순하다. LanguageModel.availability()로 상태를 확인하고, LanguageModel.create()로 세션을 만들고, session.prompt()로 호출하면 끝이다. 문제는 이 단순함이 '언제나 쓸 수 있다'는 착각을 만든다는 것이다. 현실은 다르다. Chrome이 모델을 처음 다운로드할 때 수 기가바이트의 데이터가 필요하고, GPU 메모리 4GB 이상과 약 22GB의 여유 디스크 공간이라는 하드웨어 조건도 붙는다. availability()가 반환하는 네 가지 상태—unavailable, downloadable, downloading, available—는 이 현실을 그대로 반영한다. 즉 이 API를 제대로 쓰려면 '가능한 환경에서만 동작하는 점진적 기능'으로 설계해야 한다는 뜻이다.
프로그레시브 인핸스먼트: 기능이 아니라 철학의 문제
이 지점이 UX 설계의 핵심 분기점이다. Gemini Nano 기반 기능을 앱의 전제로 깔면 안 된다. 모델이 사용 불가능한 환경에서도 앱의 핵심 가치는 온전히 동작해야 하고, AI 기능은 그 위에 얹히는 인핸스먼트여야 한다. dev.to 사례에서 소개된 Mermaid 에디터가 좋은 모델이다. 다이어그램 편집, 미리보기, 내보내기, 공유—이 모든 기능은 어느 브라우저에서나 동작한다. '텍스트로 설명하면 Mermaid 코드를 생성해준다'는 AI 기능은 available 상태일 때만 UI에 등장한다. 사용자는 기능이 없다는 사실을 인지하지 못한 채 핵심 가치를 소비한다. 이것이 프로그레시브 인핸스먼트가 사용자 경험 안에서 실현되는 방식이다.
모델을 신뢰하지 말고, 검증기를 신뢰하라
Gemini Nano는 작은 모델이다. 코드를 생성하면 마크다운 코드 펜스가 덧붙거나, 문법 오류가 섞이거나, 불필요한 서문이 들어오기도 한다. 이 출력을 그대로 렌더링하면 다섯 번에 한 번꼴로 앱이 깨지는 경험을 사용자에게 준다. 해법은 모델의 자신감을 믿는 것이 아니라 도메인 검증기를 권위자로 세우는 것이다. Mermaid의 자체 파서를 실제 파싱 성공 여부의 판단 기준으로 삼고, 실패하면 에러 메시지를 다시 모델에 넘겨 딱 한 번의 자기 수정 기회를 준다. 두 번 연속 실패하면 에디터를 건드리지 않고 친절한 안내 메시지만 보여준다. '모델은 빠른 초안 작성자, 파서는 진짜 심판'이라는 역할 분리가 데모와 실제 도구의 차이를 만든다. 구조화된 출력이 필요한 경우라면 responseConstraint에 JSON Schema를 넘겨 모델 출력 형태 자체를 강제하는 방법도 있다.
Server Action과의 조합: 브라우저 안팎의 AI 흐름 설계
온디바이스 AI가 클라이언트 레이어를 담당한다면, 서버 레이어는 어떻게 연결될까. Next.js App Router의 Server Action은 이 흐름의 서버 쪽 파트너가 된다. velog의 Server Action 실전 패턴 글이 짚어주는 핵심 함정들이 바로 이 접합부에서 생긴다. revalidatePath는 서버 컴포넌트 캐시만 무효화하지, 클라이언트 컴포넌트의 useState 값은 건드리지 못한다. redirect()는 NEXT_REDIRECT 에러를 throw하는 방식으로 동작하기 때문에 try/catch 안에 넣으면 Next.js 런타임이 받지 못하고 그냥 삼켜진다. 브라우저에서 온디바이스 AI가 텍스트를 처리하고, 그 결과를 Server Action으로 서버에 전달하고, revalidatePath로 목록을 갱신하는 흐름을 설계할 때—각 레이어의 상태 경계가 어디서 끊기는지를 정확히 이해하지 않으면 UX가 조용히 깨진다. useOptimistic으로 서버 응답 전에 UI를 먼저 반영하고, 실패 시 롤백하는 패턴은 이 흐름에서 체감 반응속도를 끌어올리는 실질적인 도구다.
AI가 UI 코드를 직접 쓰는 경쟁이 시작됐다
한편 모델이 브라우저 안에 들어오는 흐름과 별개로, AI가 UI 코드 자체를 얼마나 잘 생성하느냐의 경쟁도 빠르게 심화되고 있다. 중국 지푸AI의 GLM-5.2가 크라우드소싱 벤치마크 Design Arena의 단일 라운드 HTML 웹디자인 리더보드에서 1위를 차지하며 Anthropic의 Claude Fable 5를 넘어섰다. 실제 제작자들의 블라인드 투표로 결과가 매겨지는 이 벤치마크에서 GLM-5.2는 깔끔한 레이아웃, 적절한 타이포그래피, 시각적 위계, 미세 애니메이션 측면에서 높은 평가를 받았다. 눈에 띄는 점은 GLM-5.2가 생성하는 디자인의 91%에서 Tailwind CSS를 사용했다는 것인데, 이는 '현대적인 웹 UI에서 Tailwind가 사실상 표준이 됐다'는 신호를 AI가 학습 데이터 수준에서 흡수했다는 방증이기도 하다.
가격과 개방성이라는 두 번째 변수
GLM-5.2의 경쟁력은 디자인 품질만이 아니다. 입력 토큰 100만 개당 약 1.40달러, 출력 4.40달러라는 가격은 Claude Fable 5의 입력 10달러, 출력 50달러와 비교하면 압도적으로 낮다. MIT 라이선스 기반 오픈 웨이트 모델이라 로컬 구동도 가능하고, 100만 토큰 컨텍스트 윈도우로 대형 프로젝트도 처리할 수 있다. v0.dev나 Cursor 같은 도구에서 UI 생성 백엔드로 어떤 모델을 선택하느냐의 기준이 '성능 대 비용'의 실용적 계산으로 빠르게 재편되고 있다는 의미다. 프론트엔드 개발자가 AI 도구를 고를 때 모델 벤치마크 숫자만 보던 시대는 지나가고 있다.
설계의 무게중심이 이동하고 있다
세 흐름을 겹쳐 보면 하나의 방향이 보인다. AI는 외부 API 호출 대상에서 UI 레이어의 내장 기능으로, 코드 보조 도구에서 UI 생성의 직접 주체로, 고비용 독점 서비스에서 저비용 오픈 경쟁 생태계로 이동하고 있다. 프론트엔드 개발자에게 이 변화가 요구하는 것은 'AI API를 어떻게 호출하느냐'보다 'AI 기능이 실패했을 때 경험이 어떻게 유지되느냐', '브라우저와 서버 사이 상태 경계는 어디서 끊기느냐', '생성된 코드의 신뢰를 누가 보증하느냐'를 먼저 설계하는 능력이다. 온디바이스 AI가 모든 환경에서 동작하지 않는다는 사실은 제약이 아니라 설계 원칙을 세울 기회다. AI가 브라우저 안으로 들어올수록, 설계의 무게는 코드 생성에서 경험 보증으로 이동한다.