gwanhun1
임베딩(embedding)을 쓰려면 지금까진 사실상 하나의 공식을 따랐다. OpenAI나 Cohere 같은 API에 텍스트를 보내고, 벡터를 받아오는 것. 그런데 최근 공개된 Ternlight는 그 전제를 통째로 부순다. 한 줄 소개는 이렇다 — 7MB짜리 임베딩 모델을, 브라우저 CPU에서, API 호출 없이.
npm install @ternlight/base 하고 세 줄이면 시맨틱 검색이 된다. 서버를 단 한 번도 부르지 않는다.
1 2 3 4import { embed, similar } from '@ternlight/base'; similar('easy weeknight dinner ideas', recipes, { topK: 3 }); // → ranked matches · ~5ms · zero network
무슨 일이 벌어지고 있는 걸까. 그리고 이게 우리가 AI 기능을 만드는 방식과 무슨 상관일까.
1. 임베딩이 'API'에서 'npm 패키지'가 됐다
방금 말한 '문장 보내고 → 벡터 받아오는' 방식에는 네트워크 왕복, 사용량 요금, API 키 관리, 그리고 벡터 DB까지 늘 따라붙었다.
Ternlight는 이 그림을 뒤집는다. 모델 가중치 자체(7MB, mini 변형은 5MB)를 npm 패키지로 배포한다. 브라우저 안에서 CPU만으로, GPU 없이, 임베딩 한 번에 약 5ms. 별도 모델 다운로드 단계도, 서버도 없다.
2. 흥미로운 건 '사라지는 것들'이다
작은 모델 하나가 클라이언트로 내려오면서 네 가지가 통째로 사라진다.
- 네트워크 왕복 — 임베딩이 로컬에서 일어나니 레이턴시가 밀리초 단위고, 오프라인에서도 돈다.
- 서버 비용 — 임베딩 API 청구서가 0이 된다. 트래픽이 늘어도 내 서버 부담이 아니라 사용자 브라우저가 계산한다.
- 프라이버시 — 검색어와 문서가 브라우저를 떠나지 않는다. 사내 문서, 개인 메모, 헬스·금융 데이터처럼 밖으로 보내기 꺼려지는 텍스트에 특히 크다.
- 인프라 복잡도 — 벡터 DB도, 임베딩 서버도 없이 클라이언트에서 바로 topK를 뽑는다.
3. 큰 그림 — AI 추론이 서버에서 클라이언트로 내려오고 있다
이건 Ternlight 하나의 이야기가 아니다. transformers.js, WebLLM, WebGPU, 그리고 점점 작아지는 소형 모델(SLM)까지, 흐름은 한 방향을 가리킨다. 거대 모델과 거대 서버라는 공식이 모든 작업에 필요한 건 아니다.
임베딩, 분류, 유사도 검색 같은 작업은 사실 초대형 모델이 필요 없다. 작은 모델이 충분히 좋아지는 순간, 그걸 굳이 서버에 둘 이유가 하나씩 사라진다. 클라우드가 당연하던 것들이 엣지로 내려온 역사가 그대로 반복되는 셈이다.
물론 트레이드오프는 정직하게 봐야 한다. 7MB 모델이 대형 임베딩 모델만큼 정확하진 않다. 하지만 충분히 정확하고, 공짜이고, 즉시라는 조합이 정확도 몇 퍼센트보다 더 중요한 영역은 생각보다 넓다.
4. 그래서 언제 쓰나
잘 맞는 곳
- 클라이언트 사이드 검색: 문서·도움말·명령 팔레트(Cmd+K) 안에서의 시맨틱 검색
- 프라이버시가 중요한 데이터
- 오프라인·엣지 환경
- 서버 없이 바로 붙이는 프로토타입
안 맞는 곳
- 최고 정확도가 필요한 대규모 RAG
- 수백만 문서 규모(브라우저 메모리 한계)
핵심은 이거다. AI 기능은 곧 백엔드와 API 키와 벡터 DB라는 공식이 더 이상 유일한 정답이 아니다. 기능의 성격에 따라, 클라이언트가 정답일 수 있다.
마무리 — 더 커지는 AI, 그리고 더 가까워지는 AI
AI의 다음 라운드는 더 큰 모델만의 이야기가 아니다. 더 작아져서 더 가까이 오는 모델의 이야기이기도 하다. 7MB가 브라우저에서 도는 걸 보고 나면, 매달 나가는 임베딩 API 청구서를 다시 들여다보게 된다.
모든 AI가 서버에 있어야 한다는 가정은, 모든 것이 클라우드에 있어야 한다는 가정만큼 빠르게 낡아가고 있다.
참고 자료