브라우저는 오랫동안 '렌더링 엔진'이었다. HTML을 파싱하고, CSS를 계산하고, JavaScript를 실행하는—그 역할이 전부였다. 그런데 2025~2026년을 지나며 브라우저는 조용히 다른 무언가가 되고 있다. Chrome은 수 기가바이트짜리 언어 모델을 사용자 디스크에 내려받고, CSS는 JavaScript 없이도 복잡한 UI 포지셔닝을 처리한다. 이 두 가지 변화는 표면적으로 달라 보이지만, 같은 방향을 가리킨다. 브라우저 자체가 AI와 현대 UI의 실행 환경으로 진화하고 있다.
핵심 이슈 1: 브라우저가 AI를 내장했다—그것도 동의 없이
Chrome 138(2025년 5월)부터 데스크톱 Chrome은 Gemini Nano를 로컬에 탑재한다. chrome://on-device-internals를 열면 버전 번호와 파일 사이즈와 함께 모델이 디스크에 올라와 있는 걸 직접 확인할 수 있다. RAM 16GB 이상, VRAM 4GB 이상, 여유 디스크 22GB 이상인 기기라면 사용자가 모르는 사이에 이미 다운로드가 완료됐을 가능성이 높다.
dev.to의 분석 시리즈 Not in the Brief가 지적한 핵심은 권한 프롬프트의 부재다. 마이크, 카메라, 위치 정보—브라우저가 민감한 기능을 노출할 때마다 사용자 동의를 구하는 다이얼로그가 떴다. 그런데 Prompt API(LanguageModel.create())는 다르다. 웹페이지가 JavaScript 한 줄로 로컬 LLM 세션을 열 수 있고, 브라우저는 아무것도 묻지 않는다. 더 나아가 LanguageModel.availability()를 호출하면 방문자가 모델 탑재 기기인지 아닌지를 즉시 알 수 있다. 이는 사실상 허가 없는 하드웨어 클래스 탐지이며, 지문 추적(fingerprinting) 벡터가 하나 더 늘어난 셈이다.
물론 온디바이스 추론이라는 사실 자체는 긍정적이다. 데이터가 서버로 나가지 않으니 프라이버시 측면에서는 클라우드 LLM 호출보다 낫다. 하지만 '로컬에서 실행된다'는 것이 '사용자가 인지하고 동의했다'는 뜻은 아니다. CPU·GPU·배터리를 소모하는 주체는 사용자인데, 그 비용 결정권이 웹사이트에 있다는 구조는 기존 브라우저 보안 철학과 충돌한다.
핵심 이슈 2: CSS가 JavaScript의 자리를 빼앗고 있다
한편 CSS 진영에서도 조용한 혁명이 진행 중이다. 툴팁은 오랫동안 프론트엔드 개발의 '과잉 공학' 아이콘이었다. 디자이너가 Figma에 말풍선 하나 그려놓으면, 개발자는 npm install tippy.js를 치거나 getBoundingClientRect()와 씨름하는 JavaScript를 짰다. 뷰포트 끝에서 잘리고, overflow: hidden인 부모에 가려지고, z-index 지옥에 빠지는 건 늘 있는 일이었다.
2026년 기준으로 이 문제는 Popover API + CSS Anchor Positioning 조합으로 순수 CSS에서 해결된다. Popover API는 툴팁을 브라우저의 'top layer'로 올려 z-index와 overflow 문제를 원천 차단한다. CSS Anchor Positioning의 anchor() 함수는 특정 요소를 기준점으로 삼아 다른 요소를 정확히 붙여놓는다—스크롤이 일어나도, 창 크기가 바뀌어도 브라우저가 직접 계산한다. dev.to에 공개된 구현 예시를 보면 anchor-name과 position-anchor 속성 몇 줄, :hover + .tooltip 셀렉터 하나로 JavaScript 없는 툴팁이 완성된다.
다만 이 지점에서 접근성 함정을 짚어야 한다. :hover만으로 트리거를 구성하면 키보드 사용자는 툴팁을 볼 수 없다. :focus 혹은 :focus-within을 함께 선언하고, aria-describedby로 툴팁을 버튼에 연결하는 것은 선택이 아니라 필수다. CSS가 JavaScript를 대체한다고 해서 접근성 책임까지 없어지지는 않는다.
맥락 해석: 두 변화가 가리키는 하나의 방향
여기에 세 번째 사례를 겹쳐보면 패턴이 선명해진다. 인도의 한 고등학생은 Gemini와 Firebase만으로 실시간 주식 시뮬레이션, 3D 렌더링, 소셜 피드를 갖춘 풀스택 웹앱을 직접 배포했다. 그가 쓴 표현이 정확하다. "내 역할은 for 루프를 쓰는 게 아니라 데이터 구조를 정의하고 컴포넌트 상태를 설계하는 것이었다."
세 이야기는 서로 다른 레이어에서 같은 이야기를 한다. 브라우저는 AI 추론 엔진을 내장하고, CSS는 JavaScript가 하던 레이아웃 계산을 흡수하고, AI 도구는 코드 생성을 추상화한다. 플랫폼이 더 많은 것을 처리할수록, 개발자가 직접 작성해야 하는 코드의 성격이 달라진다. 반복적인 포지셔닝 로직이나 보일러플레이트 API 호출이 아니라, '이 경험이 사용자에게 진짜 필요한가', '이 데이터 흐름이 올바른가'를 판단하는 쪽으로.
시사점: 설계의 무게중심이 이동한다
1. 브라우저 AI API는 '사용할 것인가'보다 '어떻게 통제할 것인가'가 먼저다. Prompt API를 제품에 통합할 때 고려해야 할 것은 단순히 기능 구현이 아니다. 간접 프롬프트 인젝션(OWASP 2024 감사에서 73%의 프로덕션 AI 배포에서 발견된 취약점)은 온디바이스 모델에서도 유효한 위협이다. 웹 콘텐츠가 모델에 들어가고, 모델 출력이 UI에 반영되는 구조라면 공격 표면은 존재한다.
2. 네이티브 CSS API는 라이브러리 의존을 재검토할 기회다. Popover API와 Anchor Positioning의 브라우저 지원이 안정화되는 지금, 팀 단위로 "우리가 쓰는 UI 라이브러리 중 브라우저가 이미 해결한 문제를 풀고 있는 건 무엇인가"를 점검할 시점이다. 번들 사이즈와 메인 스레드 부하를 줄이면서 Core Web Vitals 지표도 개선할 수 있다.
3. AI 활용 개발에서 '아키텍트 역할'은 선택이 아니다. JEE-Verse 사례가 보여주듯, AI가 코드를 생성할수록 버전 관리, 컨텍스트 유지, 데이터 구조 설계의 책임은 사람에게 남는다. AI는 문맥을 잃어버리고, 이전 피처를 조용히 삭제하고, 애매한 지시에 애매한 코드로 응답한다. 명확한 시스템 설계와 엄격한 검증 루프가 없으면 속도는 올라가도 품질은 무너진다.
전망: 브라우저를 다시 정의하는 시간
브라우저가 AI를 내장한다는 건 단순히 기능이 하나 추가된 게 아니다. 웹이라는 플랫폼의 '실행 가능한 것의 범위'가 넓어졌다는 신호다. 동시에 CSS가 JavaScript 영역을 잠식하고, AI가 코드 생성을 추상화하면서 프론트엔드 개발자의 핵심 역량은 '구현 속도'에서 '판단의 정확성'으로 이동하고 있다. 어떤 API를 쓸지, 어떤 라이브러리를 걷어낼지, 어떤 사용자 문제를 먼저 풀지—이 질문들이 코드를 얼마나 빠르게 치는가보다 중요해지는 시대가 이미 시작됐다.