AI 에이전트는 서버에서 태어났지만 브라우저에서 산다

AI 오케스트레이션 파이프라인을 처음 설계할 때면 십중팔구 터미널에 커서를 깜빡이며 같은 그림을 그리고 있다. Node.js 서버가 요청을 받고, LLM API를 호출하고, 응답을 가공해서 클라이언트로 되돌려보내는 중앙집중식 배관 공사 말이다. 이 그림은 너무나 익숙해서 마치 유일한 정답처럼 느껴진다. 하지만 그 파이프라인이 하루 수백만 건의 요청을 받기 시작하고, 사용자가 브라우저 탭에서 개인 캘린더와 이메일을 에이전트에 연결하려는 순간, 바로 그 서버 중심 모델이 삐걱대기 시작한다.

서버에서 모든 것을 처리한다는 발상은 지난 2년간 AI 에이전트 생태계의 기본값이었다. LangChain이든 AutoGPT든, 무거운 오케스트레이션 로직은 언제나 누군가의 클라우드 인스턴스 위에서 돌았다. 그럴 만한 이유도 있었다. GPT-4 같은 모델은 브라우저에서 실행할 엄두조차 낼 수 없었고, 벡터 데이터베이스와 함수 호출 체인은 서버 메모리와 파일 시스템을 당연한 전제로 삼았다. 그런데 지금, 이 전제들이 하나씩 무너지고 있다.

WebLLM이 브라우저 탭 하나에서 Llama 3와 Phi-3를 20토큰 이상으로 추론하기 시작했고, WebGPU는 자바스크립트가 GPU 메모리에 직접 접근해 매트릭스 연산을 쏟아붓는 시대를 열었다. 여기에 Transformers.js와 ONNX Runtime Web이 합류하면서, '브라우저는 그냥 렌더링하는 곳'이라는 낡은 구분선이 허물어지고 있다. 문제는 대부분의 팀이 이 전환을 단순한 기술 트렌드로만 바라보고, 실제 아키텍처 결정에 녹여내지 못한다는 점이다.

서버에서 태어난 정당한 이유

서버 중심 오케스트레이션이 2023년 이후 표준처럼 굳어진 데는 명백한 기술적 근거가 있었다. 첫째, 모델 추론에 필요한 연산량이다. GPT-4 한 번의 추론은 수백 기가플롭스의 텐서 연산을 요구하는데, 이걸 사용자의 저가형 노트북에서 처리하라고 할 수는 없는 노릇이었다. 둘째, API 키 관리 문제다. OpenAI나 Anthropic 같은 서드파티 모델을 호출하려면 시크릿 키가 필요한데, 이걸 클라이언트에 내려보내는 순간 보안은 무너진다. 서버에서 프록시하는 게 유일한 방법이었다.

셋째, 그리고 가장 결정적인 이유는 상태 관리다. 에이전트는 단순한 인퍼런스가 아니다. 여러 번의 LLM 호출 사이에 컨텍스트를 유지하고, 도구 호출 결과를 누적하며, 중간 추론 단계를 메모리에 저장해야 한다. 이 복잡한 상태 머신을 서버 세션에 위임하는 건 자연스러운 선택이었다. Redux가 브라우저 상태를 관리하듯, 서버의 프로세스 메모리가 에이전트의 작업 기억을 떠맡은 셈이다.

그런데 이 '자연스러운 선택'이 운영 환경에서 내뱉는 신호들은 점점 무시하기 어려워지고 있다.

서버 모델이 침묵 속에서 알리는 경보

첫 번째 신호는 지연 시간이다. 서버에서 GPT-4를 호출해 응답을 스트리밍하는 파이프라인은 네트워크 왕복 시간에 LLM 추론 시간이 더해진다. 이건 단일 요청 기준으로는 수용 가능한 수준이지만, 에이전트는 한 번의 사용자 요청에 평균 35번의 연쇄 LLM 호출을 발생시킨다. 사용자가 "이번 주 회의 일정을 정리하고 참석자들에게 요약 메일 보내줘"라고 말하는 순간, 서버는 캘린더 API 호출 → LLM 파싱 → 이메일 초안 생성 → LLM 검토 → 전송 승인 → 완료까지 최소 5회의 라운드트립을 겪는다. 각 단계마다 23초씩 소요된다면, 사용자는 10초 넘게 빈 화면을 바라본다. 웹에서 3초가 이탈률을 두 배로 만든다는 통계는 이 맥락에서 더 가혹해진다.

두 번째 신호는 비용의 기하급수적 증가다. 에이전트가 생성하는 토큰 중 상당수는 사용자에게 보여지지 않는 '내부 독백'이다. chain-of-thought, self-reflection, 도구 선택 추론 — 이 모든 중간 출력물에 대해 OpenAI는 차감되는 토큰 수만큼 과금한다. 하루 10만 건의 에이전트 요청을 처리하는 서비스라면, 내부 추론 토큰이 전체 비용의 40% 이상을 차지하는 경우도 드물지 않다. 서버는 모든 중간 생각을 대신 지불하는 회계 부서 역할을 떠안고 있는 셈이다.

세 번째, 그리고 아마도 가장 과소평가된 신호는 개인정보 경계의 침식이다. 사용자의 이메일, 캘린더, 브라우징 히스토리를 에이전트가 다루기 시작하면, 그 데이터는 필연적으로 서버 메모리를 통과한다. GDPR이나 HIPAA 환경에서는 이 통과 자체가 규제 이벤트다. "서버에서 처리 후 즉시 폐기한다"는 약속은 감사 로그 앞에서 무력해지고, 결국 데이터를 아예 서버로 가져오지 않는 아키텍처에 대한 수요가 폭발하기 시작했다.

브라우저가 단순한 렌더러를 그만둔 순간

이러한 균열 사이로 조용히 성장해온 기술이 있다. 2023년 초만 해도 브라우저에서 LLM을 돌린다는 건 기술 데모 수준의 호기심에 불과했다. WebAssembly가 계산을 가속해도, GPU 없이 트랜스포머의 어텐션 행렬을 처리하는 건 고문에 가까웠다. 그런데 2024년 들어 Chrome과 Edge가 WebGPU를 기본 활성화하고, Apple이 Safari에 WebGPU 지원을 추가하면서 상황이 달라졌다.

WebGPU는 Vulkan과 Metal, DirectX 12를 추상화한 저수준 그래픽스 API로, 자바스크립트가 컴퓨트 셰이더를 통해 GPU의 병렬 연산 유닛에 직접 명령을 내릴 수 있게 해준다. WebGL과 달리 범용 컴퓨트 파이프라인을 지원하기 때문에, 행렬 곱셈과 소프트맥스 같은 ML 기본 연산이 브라우저 내에서 GPU 가속으로 실행된다. WebLLM 프로젝트의 벤치마크에 따르면, M2 MacBook의 Chrome에서 Llama 3 8B가 토큰당 30ms 수준으로 추론된다. 읽기 속도보다 빠르다.

이쯤 되면 "8B 모델이 GPT-4를 대체할 리 없지 않느냐"는 반론이 나오는데, 그건 에이전트 아키텍처를 단일 모델 파이프라인으로 오해한 것이다. 실제 에이전트 오케스트레이션에서 무거운 추론은 여전히 서버 LLM API에 위임할 수 있다. 문제는 그 무거운 추론을 호출하기 전후로 발생하는 수많은 경량 판단들 — "이 메일은 정말 중요한가?", "이 일정은 충돌하는가?", "사용자의 현재 탭 컨텍스트에서 이 정보는 관련 있는가?" — 이걸 매번 서버 왕복으로 처리하는 낭비다.

브라우저 로컬 모델은 이 '마이크로 추론'을 즉시 처리한다. 네트워크 왕복 없이, 토큰 비용 없이, 개인 데이터가 브라우저를 떠나지 않은 채로 말이다.

두 아키텍처의 진짜 차이는 '누가 어디서 결정하는가'다

서버 중심 모델은 에이전트의 오케스트레이션 로직 전체가 단일 제어 평면에 있다. 작업 흐름 정의, 도구 선택, 컨텍스트 누적, 오류 복구가 모두 서버 프로세스의 책임이다. 이 모델의 장점은 결정론적 디버깅이 가능하다는 점, 그리고 무엇보다 현재 가장 강력한 모델들을 제약 없이 활용할 수 있다는 점이다. GPT-4o, Claude Opus, Gemini Ultra — 이 모델들이 제공하는 추론 품질은 당분간 브라우저 로컬 모델이 따라잡기 어렵다.

브라우저 네이티브 모델은 오케스트레이션을 탈중앙화한다. 에이전트의 실행 컨텍스트가 사용자의 브라우저 환경과 일치하기 때문에, DOM 상태, 로컬 스토리지, 현재 열린 탭, 심지어 브라우저 확장 기능이 제공하는 컨텍스트까지 추론에 직접 활용할 수 있다. 서버가 절대 알 수 없는 정보들이다.

이 차이는 단순한 배포 위치의 문제가 아니라 '컨텍스트 충실도'의 문제로 귀결된다. 서버 에이전트가 사용자의 캘린더를 읽으려면 OAuth 토큰을 서버로 전송하고, API 응답을 서버 메모리에 적재하고, 거기서 추론한 뒤 결과만 클라이언트에 반환해야 한다. 각 단계마다 정보 손실과 보안 표면적 증가가 누적된다. 브라우저 에이전트는 이 모든 것을 로컬에서 처리한다. 캘린더 API 호출도 브라우저에서 직접 일어나고, 민감한 일정 데이터는 자바스크립트 힙을 벗어나지 않는다.

여기서 실무자들이 자주 빠지는 함정이 있다. "그럼 브라우저에서 모든 걸 처리하면 되는 거 아닌가?"라는 이분법적 사고다. 실제로 가장 현실적인 아키텍처는 하이브리드다. 사용자의 개인 데이터가 관여된 경량 판단은 브라우저 로컬 모델이, 복잡한 다단계 추론과 고품질 텍스트 생성은 서버 LLM API가 처리하는 계층화된 설계가 실전에서 증명되고 있다.

실무에 스며드는 하이브리드 패턴

아직 초기지만, 이 하이브리드 접근을 실제 제품에 녹여낸 사례들이 등장하고 있다. 브라우저 확장 프로그램이 현재 페이지의 DOM을 로컬 모델로 분석해 핵심 엔티티만 추출하고, 그 축약된 컨텍스트만 서버로 전달해 최종 추론을 수행하는 패턴이다. 페이지 전체 HTML을 서버로 전송하는 대신 수백 바이트의 구조화된 컨텍스트만 오가므로, 개인정보 노출을 최소화하면서도 서버 LLM의 추론 품질을 그대로 활용할 수 있다.

const session = await window.ai.createTextSession({
  temperature: 0.7,
  topK: 40,
});

const context = await session.prompt(
  `Extract key meeting details from this page content as JSON:
   ${document.body.innerText.substring(0, 4000)}`
);

const { subject, date, attendees } = JSON.parse(context);

const plan = await serverLLM.generate({
  prompt: `Draft a response for meeting: ${subject}`,
  context: { date, attendees },
});

이 패턴의 매력은 서버에 전송되는 데이터를 명시적으로 통제할 수 있다는 점에 있다. 전체 페이지 텍스트를 보내는 대신 구조화된 엔티티만 추출해 전달한다. 로컬 모델은 이 추출 작업에 충분한 성능을 내고, 서버 모델은 고품질 생성을 담당한다. 관심사의 분리가 아키텍처 레벨에서 자연스럽게 구현된다.

또 다른 실제 패턴은 '로컬 가드레일'이다. 사용자가 민감한 문서를 에이전트에게 공유하려 할 때, 브라우저 로컬 모델이 먼저 문서 내용을 분석해 PII나 기밀 정보를 탐지한다. 탐지된 민감 데이터는 마스킹된 채로만 서버에 전달된다. 이 패턴은 데이터가 브라우저를 떠나기 전에 검증 계층을 두는 방식으로, 전통적인 서버 중심 아키텍처에서는 구현이 극도로 번거로웠던 요구사항이다.

제약을 직시해야 설계가 선명해진다

브라우저 로컬 추론이 만능은 결코 아니다. 가장 현실적인 제약은 모델 크기다. WebGPU 가속을 받더라도 브라우저 탭 하나가 4GB 이상의 GPU 메모리를 점유하는 7B8B 파라미터 모델이 실질적 상한선이다. 모델 양자화로 23GB까지 줄일 수 있지만, 추론 품질 저하와의 트레이드오프는 피할 수 없다.

두 번째 제약은 모델 로딩 시간이다. 사용자가 페이지를 열 때마다 수 기가바이트의 모델 가중치를 다운로드하거나 IndexedDB에서 로드하는 건 UX 관점에서 사형 선고나 다름없다. 서비스 워커를 활용한 백그라운드 캐싱, 모델 샤딩을 통한 점진적 로딩, 그리고 페이지 생애주기에 걸친 모델 인스턴스 재사용 같은 우회 전략이 필수적이다. 이 지점에서 많은 팀이 "사용자가 5초 기다리면 되지 않나?"라고 생각했다가 실제 메트릭에 직면하고 철회한다.

세 번째는 결정론적 디버깅의 상실이다. 서버에서는 모든 LLM 호출과 그 결과를 로그로 남기고, 문제가 생기면 트레이스를 따라가면 된다. 브라우저에서 실행된 로컬 추론 로그를 수집하려면 별도의 원격 측정 파이프라인을 설계해야 하고, 사용자 동의 없이는 이마저도 불가능하다. 에이전트의 동작을 추적 가능하게 만드는 책임이 서버의 중앙 로그에서 클라이언트의 분산 옵저버빌리티로 이동하는 셈이다.

이런 제약들에도 불구하고 브라우저 네이티브 오케스트레이션이 실무적 의미를 갖는 이유는, 이 제약들이 대부분 엔지니어링 가능한 문제이고 이미 해결되기 시작했다는 점이다. WebLLM의 Service Worker 캐싱 전략은 초기 로딩을 10초 미만으로 단축시켰고, ONNX Runtime Web의 WebGPU 백엔드는 모바일 브라우저에서도 7B 모델 추론을 가능하게 만들었다. 결정론적 디버깅의 문제도 OpenTelemetry의 브라우저 SDK와 WebLLM의 커스텀 로깅 훅으로 점차 해소되고 있다.

서버에서 브라우저로, 오케스트레이션의 무게중심이 이동한다

AI 에이전트가 다루는 데이터의 특성이 이 아키텍처 전환의 방향을 결정하고 있다. 초기 에이전트들은 주로 공개된 지식을 검색하고 요약하는 역할이었기에, 서버에 모든 데이터가 있어도 무방했다. 하지만 에이전트가 개인 비서 역할로 진화하면서, 다루는 데이터가 사용자의 이메일, 일정, 문서, 브라우징 맥락으로 확장되었다. 이 데이터들의 공통점은 '브라우저에 이미 존재한다'는 사실이다.

이 지점에서 기술적 가능성과 아키텍처적 필연성이 교차한다. 브라우저에 이미 존재하는 데이터를 처리하기 위해 굳이 서버로 전송하고, 토큰 비용을 지불하고, 네트워크 지연을 감수해야 하는가? 이 질문에 대한 답이 과거에는 "어쩔 수 없다"였다면, 이제는 "꼭 그럴 필요는 없다"로 바뀌고 있다.

흥미롭게도 이 전환은 클라우드에서 엣지로, 엣지에서 디바이스로 컴퓨팅이 분산되어온 지난 20년의 연장선상에 있다. CDN이 정적 에셋을 사용자 가까이 가져왔고, 엣지 함수가 API 로직을 분산시켰으며, 이제 AI 추론마저 같은 중력의 법칙을 따르기 시작했다. 데이터가 있는 곳에서 추론이 일어나는 것 — 이 원칙은 데이터베이스 설계에서만 유효한 게 아니었다.

앞으로 1~2년 안에 AI 에이전트 아키텍처는 명시적인 설계 결정 없이도 서서히 브라우저로 무게중심을 옮겨갈 가능성이 높다. 그 변화를 미리 읽고 오케스트레이션 계층을 설계하는 팀과, 기존 서버 중심 패턴을 그대로 고수하는 팀 사이의 간극은 생각보다 빠르게 벌어질 것이다. 기술 역사에서 반복되는 패턴은 이것이다. 새로운 런타임이 충분히 성숙하면, 그 위에서 돌아가는 소프트웨어의 설계 미학 자체가 바뀐다. 브라우저는 이제 그 문턱을 넘었다.

댓글

댓글을 읽어오는 중입니다.