12. 인브라우저 LLM과 AI 브라우저의 미래

2026-04-18Views 22약 11분

인브라우저 LLM과 AI 브라우저의 미래

브라우저 자동화의 첫 시대가 "웹페이지를 대신 눌러주는 손"이었다면, 다음 시대는 "브라우저 안에서 생각하고 판단하는 머리"의 시대다. 이제 AI는 브라우저 바깥 서버에서 명령만 내리는 존재가 아니라, 탭 안에서 직접 문맥을 읽고, 로컬 데이터와 결합하고, 심지어 네트워크가 끊겨도 일부 작업을 이어가는 방향으로 움직이고 있다.

이 변화의 중심에는 두 가지가 있다. 하나는 WebGPU를 이용해 브라우저 안에서 LLM을 직접 돌리는 흐름이고, 다른 하나는 브라우저 자체가 단순한 앱 실행기가 아니라 AI의 작업 공간이자 정책 경계, 나아가 운영체제에 가까운 층으로 바뀌는 흐름이다. 말하자면 브라우저는 더 이상 "인터넷을 보는 창"이 아니라, "AI가 일하는 책상"이 되어가고 있다.

인브라우저 LLM과 AI 브라우저의 미래

탭 안에 들어온 모델: 인브라우저 LLM의 의미

인브라우저 LLM은 말 그대로 언어 모델이 사용자의 브라우저 안에서 직접 추론하는 방식이다. 대표적인 예가 WebLLM이다. WebLLM은 WebGPU를 활용해 브라우저에서 하드웨어 가속 추론을 수행하고, OpenAI 스타일의 API와 스트리밍, JSON 모드, 워커 기반 실행까지 제공한다.¹ 개발자 입장에서는 "브라우저 안의 로컬 모델"을 다루는데도 익숙한 서버 API처럼 사용할 수 있다는 뜻이다.

이 접근이 흥미로운 이유는 단순히 신기해서가 아니다. 구조 자체가 달라지기 때문이다. 기존에는 브라우저가 화면을 보여주고, 진짜 사고는 클라우드가 맡았다. 이제는 일부 사고가 탭 안으로 내려온다. 그러면 네트워크 왕복 지연이 줄고, 민감한 데이터가 기기 밖으로 나가지 않으며, 사용자별 개인화도 더 쉬워진다. 예를 들어 메모 앱이 사용자의 로컬 문서와 브라우징 문맥을 바탕으로 요약을 해주더라도, 그 내용이 서버로 전송되지 않을 수 있다.

물론 브라우저는 본래 LLM용 런타임이 아니었다. 그래서 이 세계는 독특한 조합으로 굴러간다. GPU 계산은 WebGPU가 맡고, CPU 쪽의 성능 민감한 부분은 WebAssembly가 받쳐주며, UI가 멈추지 않도록 Web Worker나 Service Worker에 작업을 분리한다.¹² 이 구조는 꽤 영리하다. 사용자는 그냥 웹앱을 열었을 뿐인데, 뒤에서는 작은 추론 엔진이 백그라운드에서 돌아간다.

더 놀라운 점은 성능이다. WebLLM 논문은 같은 기기에서 네이티브 대비 최대 약 80% 수준의 디코딩 성능을 유지할 수 있다고 보고한다.² 완전히 같은 성능은 아니더라도, "브라우저라서 너무 느릴 것"이라는 오래된 편견은 이미 깨지고 있는 셈이다. 여기에 소형 공개 모델, 양자화, 소비자 기기의 GPU 성능 향상이 더해지면서 브라우저 내 추론은 실험용 장난감이 아니라 실제 제품 설계 옵션이 되었다.

다만 조건은 분명하다. 첫 로딩은 무겁고, 기기 성능 차이가 크며, 모바일에서는 아직 제약이 많다. 다시 말해 인브라우저 LLM은 모든 것을 대체하는 만능 해법이 아니라, 아주 강력한 새 선택지다. 하지만 선택지가 생기는 순간, 아키텍처는 바뀐다. "무조건 서버로 보낸다"에서 "무엇을 로컬에 남기고, 무엇을 클라우드에 보낼까"로 설계 질문이 달라진다.

로컬 퍼스트 에이전트가 주는 새로운 감각

브라우저 안에서 모델이 돈다는 말의 진짜 의미는 단순한 오프라인 추론이 아니다. 더 중요한 것은 에이전트의 무게중심이 사용자 기기로 이동한다는 점이다. 이것이 바로 로컬 퍼스트 에이전트의 출발점이다.

로컬 퍼스트는 "클라우드를 쓰지 않는다"가 아니라 "기본값이 로컬이다"에 가깝다. 우선 로컬에서 관찰하고, 로컬에서 기억하고, 가능하면 로컬에서 판단한다. 꼭 필요할 때만 바깥 자원을 쓴다. 이 철학을 따르면 브라우저 자동화도 성격이 달라진다. 사용자의 세션, 쿠키, 탭 상태, 로컬 문서, 최근 상호작용 같은 정보가 에이전트의 즉각적인 작업 메모리가 된다. 그리고 이 메모리는 브라우저가 원래 잘하던 저장 메커니즘, 예를 들어 Cache API나 IndexedDB, 워커, 서비스 워커 같은 기술과 자연스럽게 맞물린다.¹³

실제로 로컬 퍼스트 브라우저 에이전트를 표방하는 도구들은 이미 등장하고 있다. OmniBrowser Agent는 DOM 관찰, 반성 기반 계획, 안전 등급 분류, 인간 승인 모드를 브라우저 내부 흐름으로 묶고, WebLLM을 연결해 계획 모델도 로컬에서 돌리는 방향을 보여준다.⁴ 이 구조의 핵심은 멋진 자율성보다도 통제감이다. 에이전트가 다음 행동을 하기 전에 "무엇을 보았는지, 무엇을 기억하는지, 다음 목표가 무엇인지"를 드러낼 수 있고, 중요한 액션은 사람 승인을 거치게 만들 수 있다.

LocalMode 같은 프로젝트는 한 걸음 더 나아가 임베딩, 벡터 검색, LLM 채팅, 구조화 출력, 심지어 에이전트 기능까지 브라우저 내부에서 조합하는 방향을 보여준다.⁵ 이것이 시사하는 바는 분명하다. 미래의 웹앱은 단순히 서버 API를 호출하는 얇은 클라이언트가 아니라, 자체적인 AI 실행 환경을 갖춘 두꺼운 클라이언트가 될 가능성이 크다.

이 흐름이 특히 강한 곳은 개인정보와 맥락이 중요한 작업이다. 개인 메일 초안, 로컬 문서 요약, 사내 페이지 보조, 개인 CRM 보완, 브라우저 기반 연구 도우미 같은 일은 사용자의 현재 탭과 데이터가 곧 문맥이다. 이런 문맥을 매번 서버로 보내는 것은 느리고, 불편하고, 때로는 위험하다. 로컬 퍼스트 에이전트는 이 문제를 정면으로 해결하려 한다.

클라우드 브라우저와 로컬 브라우저는 결국 분업한다

그렇다면 미래는 완전한 로컬일까? 아마 그렇지는 않다. 브라우저 에이전트의 다음 단계는 로컬과 클라우드의 승자독식이 아니라, 둘의 분업에 가깝다.

로컬 에이전트의 장점은 분명하다. 프라이버시가 좋고, 반복 비용이 낮고, 사용자의 현재 세션과 잘 맞물린다. 반면 클라우드 브라우저는 대규모 병렬 실행, 프록시 관리, 안티봇 대응, 강한 모델 사용, 중앙 관제에서 강하다. TinyFish와 Browser Use를 비교한 글에서도 이런 차이가 잘 드러난다. 로컬 또는 자체 호스팅 방식은 비용과 제어권에서 유리하고, 관리형 클라우드 방식은 병렬성, 인프라, 안티봇 처리에서 유리하다.⁶ Browser Use 역시 브라우저를 대규모 웹 에이전트 실행 환경으로 보는 흐름을 강하게 밀고 있다.⁷

현실적인 미래 아키텍처는 오히려 하이브리드일 가능성이 높다. 예를 들면 이런 식이다.

민감한 데이터 정리와 전처리는 로컬에서 한다.
무거운 다단계 탐색이나 대규모 수집은 클라우드 브라우저가 맡는다.
최종 검토와 개인화된 요약은 다시 로컬 모델이 처리한다.

이런 분업은 이미 기술적으로도 자연스럽다. WebLLM 논문 역시 로컬과 클라우드가 공존하는 분할 실행 패턴의 가능성을 언급한다.² 결국 중요한 것은 "어디서 돌리느냐"보다 "어떤 문맥과 어떤 책임을 어디에 둘 것이냐"다. 개인성, 민감성, 즉시성이 높을수록 로컬 쪽으로 기울고, 확장성, 병렬성, 외부 우회 능력이 중요할수록 클라우드 쪽으로 기운다.

차세대 AI 브라우저는 사이드바가 아니라 워크플로 엔진이 된다

초기의 AI 브라우저는 대개 요약 버튼, 채팅 사이드바, 페이지 질의응답 같은 형태로 등장했다. 하지만 이건 시작에 가깝다. 진짜 변화는 채팅 오버레이에서 워크플로 자동화로 넘어갈 때 일어난다.⁸

앞으로의 AI 브라우저는 "이 페이지를 설명해줘"에서 멈추지 않는다. "이메일에서 일정 후보를 찾고, 캘린더를 열어 가능한 시간을 고르고, 회의 초안을 작성해 보내줘"처럼 여러 탭과 웹앱을 넘나드는 흐름 전체를 다루려 할 것이다. 즉, 페이지 이해 기능이 실행 기능과 결합된다. 요약은 행동의 전단계가 되고, 브라우징은 곧 작업 수행이 된다.

이 지점에서 중요한 차이는 통합 깊이다. AI 브라우저 관련 정리 글들을 보면 현재 시장은 대략 다섯 갈래로 나뉜다. CDP 자동화 래퍼, Electron/Tauri 기반 앱, 브라우저 확장, 강화된 Chromium, 그리고 더 깊은 시스템 수준의 브라우저 통합이다.⁹ 얕은 통합은 빠르게 만들 수 있지만 로그인 안정성, 속도, 모바일 일관성, 안티봇 대응에서 한계가 생기기 쉽다. 반대로 깊은 통합은 만들기 어렵지만, 브라우저 자체를 AI 친화적으로 바꿀 여지가 커진다.

이 차이는 사용성에서 바로 드러난다. 진짜 AI 브라우저는 단순한 "자동 클릭 도구"보다 더 많은 것을 기본 기능으로 가져야 한다. 예를 들어 탭 간 문맥 공유, 현재 세션에 대한 권한 모델, 고위험 행동에 대한 확인 절차, 작업 기록과 되돌리기, 기업 정책 반영, 로컬 모델과 클라우드 모델의 유연한 전환 같은 것들이다. 이제 브라우저는 보기 도구가 아니라, 작업을 조율하는 엔진이 되어야 한다.

브라우저와 운영체제의 경계가 흐려진다

왜 자꾸 브라우저가 운영체제처럼 보이기 시작할까? 이유는 간단하다. 우리가 실제로 일하는 대부분의 공간이 이미 브라우저 안에 있기 때문이다. 이메일, 캘린더, 문서, CRM, 디자인 툴, 개발 도구, 재무 시스템까지 점점 더 많은 업무가 SaaS와 웹앱 위에서 이뤄진다. 이런 상황에서 AI가 개입하는 가장 자연스러운 자리도 역시 브라우저다.¹⁰

그래서 최근에는 "브라우저가 새로운 운영체제"라는 표현이 과장이 아니라 구조 설명으로 쓰인다.¹⁰¹¹ 운영체제의 역할을 떠올려보자. 권한을 나누고, 프로세스를 격리하고, 저장소를 다루고, 사용자 입력을 받고, 백그라운드 작업을 관리한다. 놀랍게도 현대 브라우저는 이 기능들을 이미 상당 부분 갖고 있다. 탭과 프로세스 격리, 권한 승인, 로컬 저장소, 서비스 워커, 알림, 확장, 인증 세션, 그리고 이제는 AI 실행까지 들어오고 있다.

여기에 에이전트가 결합되면 브라우저는 단순한 렌더러를 넘어서 정책 경계가 된다. 어떤 탭의 내용을 읽을 수 있는가, 어떤 계정으로 어떤 행동을 할 수 있는가, 결제나 전송 같은 고위험 동작은 어떤 승인을 거쳐야 하는가, AI 프롬프트에 민감 정보가 입력되면 어떻게 마스킹할 것인가 같은 문제들이 모두 브라우저 층에서 결정되기 시작한다.¹⁰¹¹

즉, 미래의 브라우저 경쟁은 검색창 디자인이나 탭 모양만의 싸움이 아닐 가능성이 크다. 누가 더 잘 읽느냐보다, 누가 더 안전하게 기억하고, 더 분명한 권한 체계를 제공하며, 더 믿을 만하게 행동하느냐의 싸움이 된다. AI 브라우저의 핵심은 똑똑함만이 아니라 통치 능력이다.

WebGPU 다음에 오는 것들

현재 인브라우저 LLM의 주역은 WebGPU다. 하지만 장기적으로는 WebGPU 하나만 기억해서는 부족하다. 브라우저 AI 스택은 점점 다층적으로 변하고 있다.

먼저 WebAssembly는 여전히 중요하다. 모든 연산을 GPU에만 맡길 수 없고, 브라우저 환경에서 재사용 가능한 고성능 저수준 코드를 담는 그릇 역할을 한다.² Web Worker와 Service Worker도 중요성이 커진다. 모델 로딩과 추론을 메인 스레드 밖으로 빼야 UI가 멈추지 않고, 서비스 워커나 오프스크린 문서 구조는 확장 프로그램이나 지속형 세션에서 특히 유용하다.¹

여기에 WebNN 같은 흐름도 눈여겨볼 필요가 있다. Intel의 가이드는 브라우저 AI를 떠받치는 층으로 WebGPU, WebAssembly와 함께 WebNN을 언급한다.³ WebNN은 브라우저가 CPU, GPU, NPU 같은 하드웨어 추론 자원을 좀 더 추상화해 활용하게 해주는 방향이다. AI PC와 NPU가 확산될수록, 미래 브라우저는 단순히 그래픽 카드만 보는 것이 아니라 "이 기기에서 어떤 추론 자원이 가장 적합한가"를 더 똑똑하게 판단하게 될 가능성이 크다.

모델 자체도 달라질 것이다. 거대한 범용 모델 하나가 모든 일을 떠맡는 구조보다, 작은 계획 모델, 빠른 분류 모델, 경량 비전 모델, 로컬 임베딩 모델이 역할을 나눠 맡는 쪽이 브라우저 환경에 더 잘 맞는다. 쉽게 말해 미래의 브라우저는 거대한 두뇌 하나보다, 손발 빠른 작은 전문가 팀에 가까워질 수 있다.

앞으로 2~3년, 무엇을 배우면 좋은가

브라우저 자동화가 어디로 가는지 이해했다면, 다음 질문은 자연스럽다. 그래서 무엇을 공부해야 할까?

가장 좋은 답은 "브라우저를 AI 런타임으로 보는 관점"을 익히는 것이다. 자동화 기술만 알아도 부족하고, LLM만 알아도 부족하다. 둘이 만나는 지점을 배워야 한다.

인브라우저 추론 기초를 익혀야 한다. WebGPU, WebAssembly, WebLLM, Workers, Cache API가 어떻게 연결되는지 이해하면 앞으로 나올 대부분의 로컬 AI 브라우저 구조가 읽힌다.
소형 모델과 양자화 감각이 필요하다. 1B, 3B, 7B 모델의 차이, q4 같은 양자화가 속도와 품질에 어떤 영향을 주는지 알아야 현실적인 제품 판단이 가능하다.
브라우저 확장과 서비스 워커 구조를 배워야 한다. 차세대 AI 브라우저 기능 상당수는 웹앱만이 아니라 확장 프로그램, 오프스크린 문서, 브라우저 권한 모델과 맞닿아 있다.
로컬 기억 계층을 설계할 줄 알아야 한다. IndexedDB, 로컬 벡터 검색, 세션 상태, 작업 이력, 사용자 승인 로그는 에이전트의 장기 기억과 감사 가능성을 만든다.
안전 장치 설계를 익혀야 한다. 사람 승인, 고위험 액션 분류, 프롬프트 인젝션 방어, 데이터 마스킹, 계정 경계는 앞으로 기능보다 더 중요한 경쟁력이 된다.
하이브리드 아키텍처를 고민해야 한다. 로컬과 클라우드를 어떻게 나눌지, 어떤 단계에서 어떤 모델을 쓸지, 실패 시 어디로 폴백할지 설계하는 능력이 중요해진다.

이 여섯 가지를 묶어 말하면 결국 하나다. 앞으로의 브라우저 에이전트 개발자는 "웹 자동화 엔지니어"이면서 동시에 "엣지 AI 설계자"가 되어야 한다. 브라우저를 클릭하는 법만 아는 것으로는 부족하고, 브라우저 안에서 사고를 배치하는 법까지 알아야 한다.

결국 미래의 질문은 하나다

미래를 가르는 질문은 "AI가 브라우저를 사용할 수 있는가?"가 아니다. 그 질문은 이미 상당 부분 해결되고 있다. 더 중요한 질문은 이것이다.

AI는 브라우저 안에서 얼마나 많이 생각하고, 얼마나 안전하게 행동하며, 얼마나 자연스럽게 사용자 대신 일할 수 있는가?

인브라우저 LLM은 이 질문에 대한 첫 번째 기술적 대답이다. 로컬 퍼스트 에이전트는 두 번째 대답이고, AI 브라우저는 세 번째 대답이다. 그리고 브라우저와 운영체제의 경계가 흐려진다는 말은 그 세 가지 대답이 결국 하나의 제품 경험으로 합쳐질 것이라는 뜻이다.

몇 년 뒤 우리가 쓰게 될 브라우저는 아마 지금보다 훨씬 덜 "브라우저"처럼 느껴질 것이다. 탭을 넘기는 도구라기보다, 나와 함께 일하는 작업 환경에 가까울 것이다. 그때 중요한 것은 더 화려한 데모가 아니라, 로컬에서 얼마나 잘 보호하고, 클라우드와 얼마나 현명하게 협력하고, 사람의 의도를 얼마나 또렷하게 실행하느냐다.

브라우저 자동화의 미래는 클릭 속도 경쟁이 아니다. 브라우저를 AI의 거주지로 바꾸는 경쟁이다.