AI를 고객 기기에서 돌리면 뭐가 달라질까?
서버 없이 기기에서 도는 작은 모델이 늘고 있다. 작은 팀이 어디까지 내릴 수 있을까?
AI 기능을 붙이면 트래픽이 늘 때마다 청구서도 같이 늘어난다.
작은 팀이 진짜 무서워하는 건 모델 성능이 아니라 이 구조다.
지난주 나온 소식 하나가 이 계산을 흔들었다.
9월 8일 유럽의 AI 랩 Desert Ant Labs가 스텔스에서 나오며 오디오·비전·텍스트용 작은 모델 18개를 공개했다.
핵심은 크기가 아니라 실행 위치다.
이 모델들은 휴대폰, 노트북, 브라우저 탭 안에서 전부 돌아가고, 서버도 토큰당 과금도 없으며 사용자 데이터가 기기를 떠나지 않는다.
Swift·Kotlin·JavaScript용 SDK 하나로 붙일 수 있고, 가중치는 이미 Hugging Face에 올라와 있다.
받아쓰기, 개인정보 마스킹, 언어 판별처럼 한 가지 일만 하는 모델이라는 점도 눈에 띈다.
기기에서 돌리는 AI, 왜 지금 현실적인 선택이 됐을까?
모델이 작아지는 속도가 기기가 좋아지는 속도를 앞질렀기 때문이다.
이제 작은 모델을 기기에 넣는 건 타협이 아니라, 특정 작업에서는 더 나은 설계다.
서버 비용과 개인정보 처리 부담을 동시에 덜 수 있는 선택지가 생긴 셈이다.
구글은 양자화 인식 학습으로 Gemma 3 4B를 BF16 8GB에서 int4 2.6GB로, 1B는 2GB에서 0.5GB로 줄였다.
6월에 공개된 Gemma 4 QAT는 E2B를 텍스트 전용 기준 1GB 미만으로 내렸다.
알리바바 Qwen3의 0.6B~8B 계열은 함수 호출을 기본 지원해, 작은 모델도 도구를 부를 수 있다.
애플은 아이폰 카메라와 센서로 몸 상태를 점검하는 기능을 2026년 안에 내놓겠다고 하면서 영상은 기록·저장·공유하지 않는다고 못 박았다.
프라이버시가 홍보 문구가 아니라 기능 설계의 출발점이 된 것이다.
우리 제품에서 어디를 기기로 내릴 수 있을까?
짧고, 반복되고, 판단이 단순한 구간부터다.
긴 추론과 최신 지식은 클라우드에 남겨두고 입구와 출구만 기기로 옮기면, 원가와 체감 속도가 함께 좋아진다.
- 받아쓰기: 상담 녹음을 서버로 올리지 않고 기기에서 텍스트로 바꾼 뒤, 요약만 클라우드 모델에 보낸다.
- 업로드 전 마스킹: 신분증 사진에서 번호와 얼굴을 기기에서 가린 다음 남은 정보만 전송한다.
- 분류와 라우팅: 문의 언어 판별, 스팸 여부, 담당자 배정처럼 호출은 많고 난도는 낮은 일.
- 오프라인 구간: 현장 실측, 지하 창고 재고 확인, 비행기 안 작업처럼 연결이 끊기는 곳.
- 즉각 반응 UI: 자동완성, 검색어 추천, 사진 자동 정리처럼 왕복 지연이 그대로 체감되는 기능.
반대로 기기로 내리면 안 되는 것도 분명하다.
최신 정보가 필요한 답변, 여러 문서를 놓고 비교하는 추론, 브랜드 톤을 맞춘 장문 작성은 여전히 큰 모델의 일이다.
기기용 모델은 한 가지만 잘하는 담당자라고 보고 업무를 쪼개 맡기는 편이 낫다.
예를 들어 상담 기록 앱을 만드는 1인 빌더라면, 녹음 파일을 서버에 올리는 순간 보안 심사와 보관 정책이라는 짐이 생긴다.
받아쓰기를 기기로 내리면 '녹음은 기기를 떠나지 않습니다'라는 한 줄이 제품 소개와 계약서에 동시에 들어간다.
이건 비용 절감이 아니라 영업 무기다.
이번 주에 뭘 해보면 될까?
전부 옮기려 하지 말고 한 기능만 시험한다.
브라우저에서 도는 데모를 하루 안에 만들어 저사양 기기에서 재보는 것이 가장 빠른 검증이다.
- 지난 한 달 AI 청구서에서 호출 수가 가장 많은 기능 세 개를 뽑는다.
- 그중 출력이 짧고 규칙이 분명한 하나를 고른다.
요약·작문보다 판별·추출이 낫다. - Hugging Face에서 그 용도의 작은 모델을 받아 JavaScript SDK로 한 페이지에 붙인다.
- 3~4년 전 보급형 휴대폰에서 최초 로딩 시간, 응답 시간, 배터리 소모를 직접 잰다.
- 같은 입력 100건을 기존 클라우드 결과와 나란히 놓고 틀린 건수를 센다.
차이가 업무상 무의미하면 전환한다. - 전환했다면 개인정보 처리방침과 영업 자료를 같이 고친다.
물론 공짜는 아니다.
모델 다운로드 용량은 설치 이탈로 돌아오고, 기기 성능 편차는 낮은 평점으로 돌아온다.
그래서 현실적인 답은 기기에서 먼저 시도하고 실패하면 클라우드로 넘기는 이중 구조다.
중요한 건 어떤 모델이 제일 좋은가가 아니라, 이 작업은 어디서 돌아야 하는가를 제품 설계 단계에서 한 번은 꺼내 보는 일이다.