제품에 AI 기능을 붙일 때 흔히 마주치는 질문은 "어떤 모델을 쓸까"가 아니라 "이 기능을 클라우드 API로 처리하는 게 맞는가"다. GPT-4급 프론티어 모델은 복잡한 추론에 강하지만, 사용자 입력을 카테고리로 분류하거나 문장에서 날짜를 뽑아내는 작업까지 전부 클라우드로 보내면 API 비용과 네트워크 왕복 지연이 함수 수만큼 누적된다.
최근 WebGPU 기반 브라우저 실행 환경과 4비트 양자화(Q4) 기술의 조합은 선택지 하나를 더 꺼내놨다. 25M~360M 파라미터 수준의 초소형 언어 모델(Small Language Model, SLM)을 별도 서버 없이 사용자 기기에서 직접 실행하는 방식이다. 이 글은 그 선택지가 실제로 어떤 조건에서 의미가 있고, 어떤 조건에서는 여전히 클라우드가 맞는지를 정리한다.
초소형 LLM의 실제 작동 조건부터 확인해야 한다
"브라우저에서 LLM을 실행한다"는 말이 균일하게 작동하지 않는다. WebGPU가 활성화된 환경에서는 Apple Silicon, DirectX 12, Vulkan 등 기기 GPU를 직접 활용해 100~300 토큰/초 수준의 속도가 나온다. 반면 WebGPU를 지원하지 않거나 하드웨어 가속이 꺼진 환경에서는 WASM CPU 폴백으로 떨어지고 속도는 8~20 토큰/초로 내려간다. 같은 모델이라도 실행 환경에 따라 성능 격차가 10~20배 벌어진다.
4비트 양자화는 모델 가중치를 16비트 부동소수점에서 4비트로 압축해 메모리 사용량을 약 75% 줄인다. SmolLM2 135M 기준으로 약 80MB, SmolLM2 360M 기준으로 약 216MB 수준이다. 이 정도면 브라우저 IndexedDB에 캐싱해두고 재사용할 수 있다. 최초 로드 비용은 있지만 이후에는 네트워크 요청 없이 실행된다.
여기서 판단의 전제가 만들어진다. 이 방식은 사용자 기기가 충분히 현대적인 GPU를 갖추고 있고, Chrome 113 이상이나 Edge 113 이상처럼 WebGPU를 기본 지원하는 브라우저를 쓰고 있을 때 의미 있는 성능을 낸다. 기업 내부 도구처럼 환경을 통제할 수 있는 맥락과, 일반 소비자 대상 서비스처럼 기기 다양성이 높은 맥락은 다르게 봐야 한다.
브라우저 처리가 유리한 작업의 공통 조건
초소형 LLM이 클라우드 LLM보다 유리한 자리는 답의 범위가 좁고, 틀려도 즉시 감지되고, 호출 빈도가 높은 작업이다. 구체적으로 세 가지 유형이 여기에 해당한다.
분류와 라우팅. 사용자 입력이 어느 카테고리에 속하는지, 혹은 클라우드 LLM을 호출할 만큼 복잡한 질문인지를 먼저 판단하는 용도다. 예컨대 고객 문의가 단순 FAQ 범주인지, 계정 관련인지, 에스컬레이션이 필요한지를 분류하는 일은 360M 이하 모델로도 충분히 처리할 수 있는 구조적 판단이다. 이 판단을 브라우저에서 먼저 끝내면, 정말 복잡한 요청만 클라우드로 올라간다.
의도 추출과 필드 파싱. 자유 입력 문장에서 날짜, 장소, 수량 같은 정형 값을 뽑아내는 작업이다. 검색창 자동완성, 폼 입력 보조, 필터 조건 추출 등이 여기에 속한다. 정확도가 95% 이상 필요한 고위험 필드라면 클라우드 검증을 한 번 더 거쳐야 하지만, 사용자에게 즉각 피드백을 주는 UI 보조 용도라면 브라우저 처리가 더 자연스러운 UX를 만든다.
스팸·어뷰징 1차 필터. 명백하게 비정상적인 입력을 걸러내는 첫 번째 관문으로 쓸 수 있다. 이 단계의 목적은 완벽한 탐지가 아니라 클라우드로 보내지 않아도 되는 트래픽을 줄이는 것이므로, 재현율(recall)을 높이고 정밀도(precision)를 어느 정도 희생하는 설정이 어울린다.
세 유형의 공통점은 하나다. 결과가 맞냐 틀리냐를 비교적 객관적으로 검증할 수 있고, 한 번의 판단이 치명적 결과로 이어지지 않는다.
클라우드 LLM을 유지해야 하는 작업의 기준
초소형 모델은 파라미터 수 자체가 저장할 수 있는 지식의 한계다. 복잡한 다단계 추론, 긴 문맥 전반의 일관성 유지, 창의적 생성, 도메인 전문 지식이 필요한 작업에서는 360M 이하 모델이 구조적으로 불리하다. 벤치마크 환경에서 135M 모델이 수학 문제나 복합 판단 항목을 틀리는 것은 모델의 결함이 아니라 파라미터 범위의 현실이다.
결과를 사람이 다시 검토하지 않고 직접 서비스에 반영하는 작업, 오류 하나가 법적·금전적 결과로 이어지는 작업, 또는 사용자가 결과의 신뢰성을 근거로 중요한 행동을 결정하는 작업은 클라우드 LLM을 유지하는 편이 맞다. 계약서 검토, 의료 정보 요약, 재무 분석 같은 영역이 대표적이다.
여기서 한 가지 주의할 점이 있다. "초소형 LLM이 틀릴 수 있다"는 사실은 이미 알지만, 클라우드 LLM도 틀린다. 판단 기준은 절대적 정확도가 아니라 오류의 영향 범위와 감지 가능성이다. 초소형 LLM의 오류가 다음 단계에서 쉽게 감지되고 수정된다면, 그 자리에서는 속도와 비용이 우선 기준이 된다.
두 계층을 어떻게 나눌지, 실무 설계 관점
브라우저 LLM과 클라우드 LLM을 함께 쓰는 아키텍처는 "먼저 로컬에서 판단하고, 필요하면 클라우드로 올린다"는 흐름으로 단순화할 수 있다. 이 흐름에서 핵심 설계 결정은 세 곳에서 생긴다.
라우팅 임계값을 어디에 둘 것인가. 로컬 모델이 분류 신뢰도를 점수로 반환할 수 있다면, 그 점수가 일정 기준 이하일 때만 클라우드로 보내는 조건을 설정할 수 있다. 임계값이 너무 낮으면 로컬 처리 비율이 줄고, 너무 높으면 오분류가 클라우드로 넘어가지 않고 제품에 그대로 반영된다. 이 임계값은 초기에 보수적으로 잡고 실제 오류 분포를 보면서 조정하는 게 현실적이다.
WebGPU 미지원 환경을 어떻게 처리할 것인가. 제품 사용자의 기기·브라우저 분포를 먼저 확인해야 한다. WebGPU 미지원 환경에서도 로컬 처리를 강제하면 WASM 폴백으로 실행되며 속도가 현저히 떨어진다. 이 경우 UX가 오히려 나빠질 수 있으므로, WebGPU 지원 여부를 감지해 지원 환경에서만 로컬 처리를 활성화하고 나머지는 클라우드로 바로 보내는 분기가 필요하다.
모델 크기와 초기 로드 비용을 감안할 것인가. IndexedDB 캐싱으로 재방문 시 추가 다운로드는 없지만, 첫 로드에서 80~216MB를 브라우저가 받아야 한다. 이 비용이 언제 발생하는지, 사용자 경험 흐름 어느 지점에서 로드를 트리거할지를 미리 설계해야 한다. 세션 시작 전 백그라운드 프리로드, 특정 기능 진입 시 온디맨드 로드 등 몇 가지 패턴이 있고, 선택은 기능의 사용 빈도와 첫 인터랙션까지의 허용 대기 시간에 달려 있다.
탐색 단계에서 먼저 확인해야 할 것
초소형 LLM 도입을 검토하는 단계라면, 모델 성능 벤치마크보다 먼저 확인해야 할 것이 있다.
자사 제품에서 가장 호출 빈도가 높은 AI 기능 상위 3~5개를 꺼내고, 각각에 대해 두 가지를 따져본다. 첫째, 그 기능의 출력이 후속 단계에서 검증 가능한가. 둘째, 오류 하나의 영향이 사용자 단에서 즉시 수정될 수 있는 수준인가. 두 질문에 모두 예라고 답할 수 있는 기능이 브라우저 LLM 적용 후보다.
그다음은 실제로 해당 태스크를 초소형 모델로 돌려보고 오류 패턴을 확인하는 작업이다. 벤치마크 점수보다 실제 제품 데이터에서 틀리는 유형이 어디인지가 설계 결정에 훨씬 직접적인 입력이 된다. 공개된 실험 환경에서 모델을 직접 로드하고 프롬프트를 테스트해보면, 성능 수치보다 오류의 성격을 먼저 파악할 수 있다.
비용 절감 기대치는 계산보다 측정이 정확하다. "API 호출 X%를 줄이면 월 비용이 얼마 감소한다"는 추정은 실제 라우팅 임계값과 오분류 처리 비용을 포함하지 않은 경우가 많다. 파일럿 범위에서 실제 호출 분포를 측정한 뒤 추산하는 편이 낫다.
