주제 탐구 · 2026-10-26 · 기초 · 작성자 bombong
소형 언어 모델(SLM)과 온디바이스 AI: 주머니 속에서 도는 AI
소형 언어 모델(SLM)은 업무 범위를 좁히고 양자화로 크기를 줄여서, 데이터를 서버로 보내지 않고 휴대폰이나 노트북 안에서 바로 돌게 만든 언어 모델입니다. 넓은 지식과 안정성을 일부 내주는 대신 프라이버시, 오프라인 동작, 빠른 응답을 얻습니다. 그래서 출력 검증, 안전장치, 다국어 점검을 함께 설계해야 합니다.
목차
- 작은 모델이라도 한 가지 업무에 맞춰 학습하면, 그 업무에서는 몇 배 큰 범용 모델과 겨룰 수 있습니다.
- 온디바이스 AI는 '작게 학습 → 양자화로 압축 → 기기 메모리·전력 안에서 실행 → 바깥 안전장치'로 이어지는 하나의 공정입니다.
- 양자화는 크기만 줄이는 데서 끝나지 않고 안전성도 바꿀 수 있습니다. 그래서 압축한 뒤에는 가드레일과 재평가가 필요합니다.
- 제품에 넣을 때는 모델에게 맡기는 책임을 줄이고, 실패하면 정해진 결과로 돌아가는 폴백을 두는 구조가 효과적이었습니다.
- 메모리·효율 수치는 대개 영어로 잰 값이라, 다른 문자를 쓰는 언어에서는 토크나이저 때문에 쓸 수 있는 문맥이 크게 줄어들 수 있습니다.
왜 작은 모델이 필요했나
대규모 언어 모델(LLM)은 대개 거대한 데이터센터에서 돌고, 사용자는 인터넷으로 질문을 보내 답을 받습니다. 성능은 좋지만 비용이 따릅니다. 정신건강 예측 모델 Menta논문 연구는 LLM의 크기와 연산량이 실제 배포를 가로막는다고 지적했습니다. 인도 법률 모델 Quecto-V1논문 연구는 최신 법률 AI가 대부분 70억(7B) 개 이상의 파라미터와 클라우드 추론(인퍼런스)에 기대고 있어, 자원이 부족한 현장에서는 쓰기 어렵고 데이터 주권 위험도 생긴다고 했습니다.
온디바이스 AI는 이 계산을 서버가 아니라 사용자의 기기 안에서 하는 방식입니다. 모바일 게임에 SLM을 넣은 사례 연구논문는 그 장점을 '클라우드에 기대지 않고 데이터가 기기를 떠나지 않는, 완전히 오프라인인 비공개 AI'로 요약했습니다. 온디바이스 가드레일 LiteLMGuard논문 연구도 프라이버시 강화, 지연 감소, 서버 없이 동작한다는 점을 장점으로 꼽았습니다.
문제는 휴대폰의 메모리, 배터리, 칩 성능이 데이터센터와 비교가 안 된다는 점입니다. 그래서 기기에 들어갈 만큼 작은 모델, 곧 소형 언어 모델(SLM)이 필요해졌습니다. '작다'에 정해진 기준은 없습니다. 이 글에서 다루는 연구에도 1억 2천만 개 수준부터 수십억 개, 소비자용 GPU에서 도는 300억 개 모델까지 함께 나옵니다. 크기보다 '목표 기기에서 돌아가는가'가 기준이라고 보면 됩니다.
핵심 아이디어: 만능 백과사전 대신 업무 전담 비서
비유하면 클라우드 LLM은 모든 과가 있는 대형 종합병원이고, 온디바이스 SLM은 주머니에 들어가는 한 분야 전담 비서입니다. 전담 비서는 세상 모든 질문에 답하지는 못하지만, 맡은 일은 빠르고 조용하게 처리합니다. 서류를 밖으로 들고 나가지도 않습니다.
핵심은 '범위를 좁히면 작은 모델도 충분히 잘할 수 있다'는 데 있습니다. Menta논문는 SNS 글로 우울, 스트레스, 자살 위험 같은 6가지 분류 과제를 함께 학습했습니다. 그 결과 파인튜닝하지 않은 SLM 가운데 가장 나은 모델보다 과제 평균 15.2% 좋아졌습니다. 우울과 스트레스 분류에서는 약 3.25배 큰 130억(13B) 파라미터 LLM보다 정확도가 높았습니다. Quecto-V1논문은 넓은 세상 지식 대신 법률 영역의 '어휘 밀도'를 최대로 높이는 쪽을 택했고, 법 조문 정확 일치 과제에서 범용 SLM을 앞섰습니다.
대신 맞바꾼 것도 분명합니다. 넓은 일반 지식, 길고 복잡한 다단계 추론, 형식을 정확히 지키는 안정성은 큰 모델보다 약합니다. 그래서 온디바이스 AI 설계는 '모델을 얼마나 키울까'보다 '모델에게 무엇을 맡기고 무엇은 맡기지 않을까'를 정하는 일에 가깝습니다.
클라우드 LLM 대 온디바이스 SLM
클라우드 LLM서버에서 큰 모델
- 넓은 일반 지식
- 복잡한 추론에 강함
- 데이터가 서버로 나감
- 네트워크가 필요함
온디바이스 SLM기기 안의 작은 모델
- 데이터가 기기에 남음
- 오프라인으로 동작
- 좁은 업무에 특화
- 형식 위반·안전성 보완 필요
공통 둘 다 언어 모델로 업무를 돕고, 어떤 업무를 맡기느냐에 따라 고릅니다.
어떻게 작동하나
1) 업무를 좁히고 모델을 고릅니다. 기존 모델을 가져다 쓸 수도 있고 처음부터 만들 수도 있습니다. Quecto-V1논문은 GPT-2 구조로 1억 2,400만 파라미터 모델을 만들고, 인도 법령 자료만으로 처음부터 학습했습니다.
2) 업무에 맞게 학습합니다. 흔한 방법은 LoRA입니다. 원래 모델의 가중치는 대부분 그대로 두고, 작은 추가 행렬만 학습해 적은 비용으로 모델을 맞춤화합니다. Menta논문는 LoRA 기반 틀에 여러 데이터셋을 섞는 전략을 쓰고, 클래스 불균형을 고려한 손실 함수로 학습했습니다. 함수 호출 같은 에이전트 업무를 다룬 TinyLLM논문은 SFT(지도 미세조정), 파라미터 효율 파인튜닝, 강화학습, DPO(직접 선호 최적화), 그리고 이들을 섞은 하이브리드 방법을 비교했습니다.
3) 양자화로 압축합니다. 양자화는 가중치 숫자를 더 적은 비트로 표현해 파일과 메모리를 줄이는 기법입니다. Quecto-V1은 학습 뒤 8비트 양자화를 적용해 GGUF 파일로 만들었습니다. 모델 크기가 74% 줄어 150MB 미만이 됐고, 일반 CPU에서 완전히 오프라인으로 돕니다.
4) 기기의 메모리와 전력 안에서 실행합니다. Menta는 iPhone 15 Pro Max에서 약 3GB RAM으로 실시간 동작함을 보였습니다. 전력 문제는 따로 다뤄야 합니다. DVFSLM논문은 칩의 전압과 클럭을 상황에 맞춰 조절하는 DVFS(동적 전압·주파수 조절)를 SLM에 맞게 다시 설계했습니다. 토큰을 하나씩 이어 만드는 자기회귀 생성 과정에서는 주파수, 전력, 지연이 복잡하게 얽힙니다. GPU, CPU, 메모리 컨트롤러(EMC)가 각각 전력과 지연에 얼마나 기여하는지도 바깥에서는 보이지 않습니다. 이 때문에 기존 방식으로는 에너지가 새거나 응답이 느려졌다고 설명했습니다.
5) 모델 바깥에 안전장치를 둡니다. 입력 단계에서는 위험한 질문을 거르는 가드레일을, 출력 단계에서는 형식 검사와 실패 시 폴백을 둡니다. 이 부분은 뒤의 한계 절에서 자세히 다룹니다.
발전 흐름: 쓸모 증명에서 운영과 안전으로
출발점 연구들은 모두 2025~2026년에 나왔습니다. 그래서 긴 역사적 계보라기보다는, 같은 시기에 세 방향이 함께 채워지는 흐름으로 보는 편이 정확합니다.
첫째는 '작아도 쓸모 있다'는 증명입니다. Menta논문와 Quecto-V1논문은 정신건강과 법률이라는 좁은 영역에서 작은 모델의 가치를 보였습니다. TinyLLM논문은 도구·API 호출 같은 에이전트 업무로 범위를 넓혔습니다. 버클리 함수 호출 리더보드(BFCL)로 TinyAgent, TinyLlama, Qwen, xLAM 등을 평가했더니 10억~30억(1~3B) 파라미터 모델이 10억 미만 초소형 모델보다 뚜렷이 나았습니다. 하이브리드 최적화를 쓰면 전체 정확도는 최대 65.74%, 여러 턴 정확도는 55.62%였습니다.
둘째는 '실제로 돌리는 문제'입니다. DVFSLM논문은 에너지를 다뤘습니다. 모바일 게임 사례 연구논문는 Gemma 4 E2B(2.6B)와 Qwen3 0.6B를 안드로이드 단어 게임 Palabrita에 넣으며 5일 동안 204개 커밋(그중 약 90개가 AI 관련)을 쌓았습니다. 그 과정에서 처음 설계를 크게 고쳤습니다.
셋째는 '안전과 프라이버시'입니다. LiteLMGuard논문는 양자화한 SLM 앞에 붙이는 가벼운 질문 필터를 제안했습니다. 개인정보 대체 연구논문는 개인정보를 [PERSON] 같은 자리표시로 지우는 대신 같은 종류의 가짜 값으로 바꾸는 과정을 전부 기기 안에서 처리했습니다. 15억 파라미터 MoE 분류기가 개인정보 구간을 찾고, 1비트 Bonsai-1.7B가 이름·주소·날짜의 대체 값을 제안하고, 규칙 기반 생성기가 형식이 정해진 항목을 맡습니다.
요즘 어디로 가고 있나
하나는 '작다'의 기준이 기기 성능을 따라 올라가는 흐름입니다. Muse Glimmer논문는 300억(30B) 파라미터 모델을 약 4비트로 양자화해 GPU 한 장으로 추론하게 만들었습니다. 텍스트와 이미지를 입력받고, 여러 단계 추론, 도구 사용, 실패 복구를 한 모델에 담아 소비자 기기에서 클라우드 없이 돌아가는 에이전트 모델로 내놓았습니다. Apache 2.0 라이선스로 공개됐습니다. 휴대폰용 1~3B 모델과 데스크톱용 수십 B 모델이 같은 '로컬 실행' 흐름 안에 있습니다.
다른 하나는 모델 구조보다 학습 데이터와 평가를 설계하는 쪽에 무게가 실리는 흐름입니다. 통화 대신 받기 연구논문는 주인이 없을 때 휴대폰이 통화 내용을 밖으로 보내지 않고 대신 응대하는 상황을 다뤘습니다. 기존 소형 모델은 평범한 발신자에게도 괜한 경고를 띄웠고, 요약에서는 중요한 조건을 빠뜨리거나 발신자의 주장을 사실처럼 적었습니다. 실제 통화에는 정답 응답이 없어서, 연구진은 정보 경계를 나눠 합성 통화를 만들었습니다. 발신자 역할 작성자는 비공개 시나리오만, 응답 작성자는 현재 턴까지의 대화만, 요약 작성자는 끝난 대화 전체만 봅니다. 이렇게 3,395건의 통화와 15,102개의 학습 목표를 만들었습니다. 0.6~4B 모델 6개에 LoRA 어댑터 하나를 학습시키자 응답 합격률은 21~54%에서 94~97%로, 요약 합격률은 0~6%에서 43~72%로 올랐습니다.
두 흐름을 합치면 이렇습니다. 기기에서 돌릴 수 있는 모델의 크기 상한은 하드웨어가 정합니다. 그 안에서 실제 품질을 가르는 것은 업무에 맞는 데이터를 어떻게 만들고 무엇을 '합격'으로 볼지 정하는 일입니다.
한계와 쟁점
양자화는 안전성까지 바꿀 수 있습니다. LiteLMGuard논문는 압축 과정에서 공정성, 윤리, 프라이버시 위험이 함께 생기고, 양자화한 SLM이 탈옥 같은 공격 없이도 해로운 질문에 그대로 답할 수 있다고 경고했습니다. 이 연구의 대응은 모델 앞단에서 질문을 거르는 것입니다. ELECTRA 기반 분류기가 '답해도 되는 질문인가'를 97.75% 정확도로 판별합니다. 기기 안에서 평균 약 135ms 만에 걸러 내고, 해로운 질문 방어율은 85%를 넘었습니다.
작은 모델은 형식과 지시를 자주 어깁니다. 모바일 게임 사례논문는 실패를 다섯 가지로 나눴습니다. 출력 형식 위반, 제약 조건 위반, 문맥 품질 저하, 지연 시간 불일치, 모델 선택 불안정입니다. 처음에는 단어, 분류, 난이도, 힌트 다섯 개를 담은 JSON 퍼즐 전체를 모델이 만들게 했습니다. 최종 구조에서는 단어는 미리 고른 목록에서 가져오고, 모델은 짧은 힌트 세 개만 만들며, 실패하면 정해진 결과로 돌아갑니다. 함께 쓴 기법은 여러 겹의 방어적 파싱, 실패 내용을 알려 주는 재시도, 세션 교체, 점점 엄격해지는 프롬프트, 모델 책임 줄이기였습니다.
예시를 그대로 베끼기도 합니다. 개인정보 대체 연구논문에서는 고정된 예시 세 개를 주자 1비트 SLM이 입력과 상관없이 예시의 답을 그대로 내놓았습니다. 1.58비트 모델에서도 똑같이 실패해 양자화 탓은 아니었습니다. 언어권에 맞는 예시 묶음에서 입력마다 예시를 바꿔 뽑게 하자 482건 호출이 모두 성공했습니다. 다만 작은 예시 묶음에서 값을 베끼는 경향은 남았다고 밝혔습니다.
효율 수치가 언어마다 다릅니다. 토크나이저 범위 연구논문에 따르면 TinyLlama-1.1B의 토크나이저는 라틴 문자 단어 하나를 평균 1.34개 토큰으로 나누지만, 칸나다어 단어는 22.60개로 쪼갰습니다. 어휘에 그 문자가 거의 없어 바이트 단위로 쪼개는데도 '모르는 토큰' 표시가 나오지 않아 겉으로는 드러나지 않습니다. 그 결과 2048 토큰 컨텍스트 윈도에 영어 사용자는 1,528단어를 담을 수 있지만 칸나다어 사용자는 91단어만 담습니다. 연구진은 파라미터 수보다 어휘가 진짜 제약이라고 결론 내렸습니다.
영어로 잰 효율의 함정
실무에서 고를 때 따질 점
온디바이스 SLM이 맞는 경우는 이렇습니다. 데이터가 기기 밖으로 나가면 안 될 때(정신건강, 통화 내용, 개인정보), 네트워크 없이 돌아야 할 때(법률 현장, 자원이 부족한 환경), 업무가 좁고 반복적일 때(분류, 짧은 생성, 정해진 도구 호출)입니다. 반대로 넓은 지식이 필요한 자유 질의응답이나 길고 복잡한 계획 수립이 핵심이라면, 큰 모델을 쓰거나 일부를 클라우드에 맡기는 구성이 더 현실적입니다. 에이전트 업무라면 TinyLLM논문의 결과처럼 10억 미만 모델은 성능이 크게 떨어질 수 있으니 1~3B부터 검토하는 편이 안전합니다.
흔한 실수는 네 가지입니다. 첫째, 처음부터 모델에게 결과 전체를 맡깁니다. 사례 연구논문처럼 정해진 부분은 코드와 데이터가 맡고, 모델은 작은 조각만 만들게 하는 편이 안정적입니다. 둘째, 영어로 잰 메모리·속도 수치만 보고 다국어 서비스를 결정합니다. 대상 언어로 단어당 토큰 수부터 재 봐야 합니다. 셋째, 양자화한 뒤 안전성 평가를 다시 하지 않습니다. 넷째, 고정된 few-shot 예시를 그대로 둡니다. 출력이 예시를 베끼는지 확인해야 합니다.
배터리와 발열도 기능 요구 사항으로 다뤄야 합니다. DVFSLM논문이 지적했듯 작은 모델도 에너지를 많이 쓰며, 이는 앱 품질과 기기 신뢰성에 영향을 줍니다. 정확도뿐 아니라 응답 한 번에 드는 시간과 전력을 함께 재는 습관이 필요합니다.
온디바이스 SLM 도입 점검
설계
- 모델에 맡긴 일이 충분히 좁은가
- 실패하면 돌아갈 폴백이 있는가
- 에이전트 업무라면 모델 크기가 충분한가
품질
- 출력 형식을 여러 겹으로 검사하는가
- few-shot 예시를 베끼지 않는가
- 대상 언어로 단어당 토큰 수를 쟀는가
안전·자원
- 양자화한 뒤 안전성을 다시 평가했는가
- 입력 가드레일을 두었는가
- 응답당 지연·전력을 측정했는가
더 공부하려면
처음이라면 Menta논문와 Quecto-V1논문부터 읽기를 권합니다. 'LoRA 파인튜닝 → 양자화 → 기기 실행'이라는 기본 공정과, 좁은 업무에서 작은 모델이 큰 모델과 겨루는 모습을 짧은 사례로 볼 수 있습니다.
제품을 만들 계획이라면 모바일 게임 사례 연구논문가 가장 실용적입니다. 실패 다섯 유형과 대응 기법을 정리해 두어 설계 점검표로 쓰기 좋습니다. 에이전트 기능을 생각한다면 TinyLLM논문으로 모델 크기와 학습 방법에 따른 차이를 확인하세요.
안전과 다국어가 걱정된다면 LiteLMGuard논문, 개인정보 대체 연구논문, 토크나이저 범위 연구논문를 이어서 읽어 보세요. 최근 방향은 Muse Glimmer논문와 통화 대신 받기 연구논문가 잘 보여 줍니다. 에너지에 관심이 있다면 DVFSLM논문을 보면 됩니다.
관련 용어
참고 문헌
핵심 논문
- Menta: A Small Language Model for On-Device Mental Health Prediction (2025)
- Quecto-V1: Empirical Analysis of 8-bit Quantized Small Language Models for On-Device Legal Retrieval (2026)
- TinyLLM: Evaluation and Optimization of Small Language Models for Agentic Tasks on Edge Devices (2025)
- DVFS for Small Language Model Inference on Mobile Edge Devices (2026)
- Less Is More: Engineering Challenges of On-Device Small Language Model Integration in a Mobile Application (2026)
- LiteLMGuard: Seamless and Lightweight On-Device Prompt Filtering for Safeguarding Small Language Models against Quantization-induced Risks and Vulnerabilities (2025)
- Locale-Conditioned Few-Shot Prompting Mitigates Demonstration Regurgitation in On-Device PII Substitution with Small Language Models (2026)
최근 연구
AI가 참고 문헌을 바탕으로 작성하고 검수를 거친 해설입니다. 정확한 내용은 원문을 확인해 주세요.