웹 AI 플랫폼 고르기: 클라이언트, 서버, 하이브리드

두 축, 네 가지 선택지

AI 기능을 어디에 올릴지는 속도·비용·확장성·신뢰를 함께 정한다. 선택지는 두 축으로 나뉜다.

어디서 도나: 사용자 기기의 브라우저(클라이언트) / 클라우드(서버)
얼마나 고칠 수 있나: 모델 가중치(model weights)에 손댈 수 있으면 행동을 요구 사항에 맞게 바꿀 수 있다. 가중치는 정보의 중요도를 나타내는 숫자이고 학습 중 계속 갱신된다. Gemma 같은 오픈 모델은 가중치를 고칠 수 있다.

	고칠 수 없음	고칠 수 있음
클라이언트	브라우저 내장 AI (Chrome의 Gemini Nano 등)	커스텀 모델 + 라이브러리 (Transformers.js, MediaPipe 등)
서버	관리형 서비스 (Gemini, GPT 같은 API)	자체 호스팅 오픈 웨이트 모델 (Gemma, Llama를 자체 인프라·Google Cloud Gemini Enterprise Agent Platform(구 Vertex AI)·Hugging Face Inference에)

클라이언트 사이드 AI

추론이 사용자 기기에서 일어난다. 추론 서버 비용이 없고, 데이터가 기기를 떠나지 않고, 네트워크 지연이 없다. 대신 모델이 작아서 독성 탐지·감성 분석처럼 출력 공간이 좁고 잘 정의된 과제에 맞는다.

내장 AI: 브라우저가 모델을 들고 있고 자바스크립트로 부른다. 설정·호스팅이 필요 없고, 모델을 한 번 받으면 그 API를 쓰는 모든 사이트가 함께 쓴다.
커스텀 모델: 가중치를 통제할 수 있지만, 사이트를 쓰는 모든 사용자가 모델을 내려받아야 한다. 가장 작은 모델도 웹 페이지 기준으로는 크다.

자세한 API·라이브러리·런타임은 클라이언트 사이드 웹 AI에 있다.

서버 사이드 AI

앱이 API로 입력을 보내고 출력을 받는다. 크고 복잡한 모델을 쓸 수 있고 사용자 하드웨어와 무관하다.

관리형 서비스: 최신 대형 모델을 최소 설정으로 쓴다. 빠른 프로토타입, 열린 대화, 범용 추론에 맞지만 규모가 커지면 비싸다.
자체 호스팅: 모델 제작자의 사전 학습을 이어받으면서 모델·파인튜닝 데이터·성능을 직접 통제한다.

서버 AI의 프라이버시 약점을 줄이는 기술도 나오고 있다. Google의 Private AI Compute가 그 예다.

비교표

1(낮음)~5(높음) 상대 평가다. 실제 값은 기기, 모델, 사용 빈도에 따라 달라진다. 모델 성능·맞춤성·정확도는 모델의 속성이지만, 모델이 플랫폼을 제한하고 플랫폼이 모델을 제한하므로 함께 본다.

기준	내장 AI	커스텀 클라이언트	관리형 서비스	자체 호스팅
모델 성능	2	3	4	4
맞춤성	1 (프롬프트만)	5	1 (프롬프트·컨텍스트만)	5
정확도	2	3	5	4
네트워크 지연	5	5	2	2
프라이버시	5	5	2	3
고정비 (높을수록 쌈)	5	5	5 (사용량 과금)	2
요청당 비용 (높을수록 쌈)	5	5	2	3
호환성	2 (브라우저·기기별)	1 (하드웨어·런타임 의존)	5	5
사용자 편의	3 (첫 다운로드)	2 (다운로드·미지원 기기)	4	4
개발자 편의	5	2	4	1
유지 보수 (높을수록 쉬움)	4	2	5	2

요구 사항에서 플랫폼 고르기

쇼핑몰의 야간 고객 상담 비서(주문·반품·상품 질문)를 예로 든다. 유스케이스 요구와 비즈니스·팀 제약 두 렌즈로 나눠 기준을 뽑는다.

요구·제약	분석	기준	결론
정확도·다양성	질문이 복잡하고 다양하다	모델 성능, 정확도	LLM이 필요하다
데이터 특수성	회사 상품·정책을 알아야 한다	맞춤성	파인튜닝이 아니라 RAG로 데이터를 넣는다
사용자 규모	수십만 명	확장성, 호환성	높은 트래픽을 안정적으로
출시 후	팀이 v1 뒤 다른 일로 옮긴다	유지 보수	손이 덜 가야 한다
팀 역량	웹 개발은 강하고 ML 경험은 적다	개발자 편의	전문 지식 없이 붙일 수 있어야 한다

우선순위 기준을 비교표에 대 보면 서버 쪽, 그중 관리형 서비스가 이긴다. 맞춤성은 낮지만 ML 경험이 적은 웹 팀에게는 감수할 만한 교환이고, 회사 데이터는 검색 증강 생성(RAG)으로 추론 시점에 넣는다.

flowchart LR
  req["요청"] -->|"기기·브라우저가 클라이언트 AI를 못 돌린다"| s1["서버 (호환성 기반 대체)"]
  req -->|"클라이언트 분류 모델: #quot;드문·복잡한 질문#quot;<br/>예: 다른 통화로 환불받기"| s2["서버 (능력 기반 승격)"]
  req -->|"흔한 질문"| cl["클라이언트에서 답한다"]

호환성 대체만 필요하다면 양쪽에 같은 모델을 두는 편이 경험이 일관되고 유지 보수가 줄어든다.

유연성의 대가

늘어나는 일	내용
오케스트레이션	라우팅·재시도·대체 로직
버전 관리	같은 모델을 쓰면 두 환경에서 호환을 유지해야 한다
프롬프트·컨텍스트 엔지니어링	모델이 다르면 프롬프트도 각각 다듬어야 한다
모니터링	로그·지표가 둘로 갈라져 합치는 수고가 든다
보안	공격 면이 둘이다. 로컬과 클라우드 엔드포인트 모두 단단히

팀이 작거나 핵심 기능이 아니면 이 복잡도를 들이지 않는 편이 낫다.

오픈소스로 쌓는 서버 AI 스택

자체 호스팅을 고르면 관리형 API가 대신해 주던 계층을 직접 채워야 한다. 계층마다 오픈소스 선택지가 있다.

flowchart TB
  fe["프론트엔드<br/>채팅·검색 UI"] --- be["백엔드·오케스트레이션<br/>API 서버, 프롬프트·도구 호출·RAG 흐름 조립"]
  be --- ms["모델 접근·서빙"]
  be --- rag["임베딩·RAG"]
  rag --> store["데이터·검색 저장소"]
  ms --- llm["LLM (공개 가중치)"]

계층	하는 일	예
프론트엔드	대화·스트리밍 UI, 배포	Next.js, Streamlit(파이썬으로 빠른 데모)
백엔드 · 오케스트레이션	API, 프롬프트 체인, 도구 호출, 워크플로	FastAPI, LangChain, LlamaIndex
모델 접근 · 서빙	모델 내려받기, 로컬 실행, 고성능 추론 서버	Hugging Face(모델 허브), Ollama(로컬 실행), vLLM(서빙)
임베딩 · RAG	문서를 벡터로 바꾸고 관련 조각을 찾아 프롬프트에 넣는다	오픈 임베딩 모델(Nomic, Jina 등)
데이터 · 검색	원본과 벡터를 저장하고 근접 이웃을 찾는다	Postgres + pgvector, Milvus, Weaviate, FAISS(라이브러리)
LLM	생성	Llama, Mistral, Qwen, Gemma, Phi 같은 공개 가중치 모델

모델 순위는 빠르게 바뀌므로 특정 모델에 묶이지 않게 모델 접근 계층을 추상화한다. Ollama·vLLM 모두 OpenAI 호환 API를 제공해 교체가 쉽다.
벡터 저장소는 이미 Postgres를 쓰면 pgvector부터 시작하고, 규모가 커질 때 전용 벡터 DB를 검토한다.
「오픈소스」라도 모델 가중치의 라이선스(상업적 이용 조건)는 모델마다 다르다.

정리

선택지는 어디서 도나 × 가중치를 고칠 수 있나로 네 가지다.
클라이언트는 빠르고 싸고 사적이지만 작고 호환성이 약하다. 서버는 강하고 어디서나 되지만 지연·비용·데이터 노출이 있다.
플랫폼은 유스케이스 요구 + 팀·비즈니스 제약으로 기준을 뽑아 비교표에 대 보고 고른다.
실사용 데이터가 쌓이면 클라이언트 기본 + 서버 승격·대체의 하이브리드로 비용과 지연을 줄인다. 다만 그만큼 운영할 것이 늘어난다.

플랫폼 선택은 한 번에 끝나지 않는다. 제품과 팀의 AI 성숙도에 맞춰 계속 바꿀 수 있게 만든다.

버그 제보