소형 언어모델 · sLM
Small Language Model
소형 언어모델이란?
- 작고 가벼운 언어모델
- 저비용·빠름·온디바이스
- 특정 용도에 파인튜닝
sLM이 실제로 바꾸는 건 모델 성능표가 아니라 AI 도입의 결재선입니다. 거대 모델은 호출 건당 비용이 붙고 데이터가 사외로 나가기 때문에 법무·보안 검토가 먼저 걸립니다. 반면 몇 GB짜리 모델은 사내 서버나 업무용 노트북에 얹어 돌릴 수 있어, 대형 계약 없이도 팀 단위로 먼저 시험해 볼 여지가 생깁니다. '되는지 해보고 판단하는' 순서가 가능해진다는 게 현장에서 체감되는 가장 큰 차이입니다.
규모 감각을 잡아두면 판단이 쉬워집니다. 통상 1B~10B 파라미터대를 sLM으로 부르고, FP16 기준 7B 모델은 약 14GB 메모리를 먹지만 INT4로 양자화하면 4GB대까지 내려가 노트북이나 최신 스마트폰에서도 돕니다. 여기서 핵심은 크기가 아니라 역할 분담입니다. 사내 문서를 찾아 읽고 정해진 양식으로 정리하는 일은 sLM과 RAG 조합으로 충분하고, 여러 단계를 거슬러 올라가는 원인 분석이나 장문 기획처럼 모델의 '머리'가 필요한 일은 여전히 거대 모델 몫입니다.
sLM이 잘 먹히는 업무에는 공통점이 있습니다. 입력 형태가 일정하고, 정답 범위가 좁고, 하루에도 수백 번씩 반복된다는 점입니다. 고객 문의 분류, 상담 녹취 요약, 코드 자동완성, 설비 에러코드 안내가 여기 해당합니다. 반대로 질문이 매번 달라지는 일은 작은 모델이 금세 바닥을 드러냅니다. 도입 판단 기준은 단순합니다 — 같은 유형의 질문이 월 1,000건을 넘는가, 그리고 그 답을 우리 문서로 검증할 수 있는가입니다.
가장 흔한 오해는 '작으니까 싸다'입니다. 모델 값은 싸도 파인튜닝 데이터를 만들고 관리하는 사람 값은 그대로 듭니다. QA 수천 쌍을 만드는 데 현업 인력이 몇 주 붙고, 제품이나 사내 규정이 바뀌면 재학습을 다시 돌려야 합니다. 더 위험한 건 평가셋 없이 모델을 교체하는 일입니다. sLM은 모르는 걸 모른다고 말하는 능력이 약해서 틀린 답도 그럴듯한 문장으로 내놓습니다. 고정 문항 200~300개짜리 채점표를 먼저 만들어 두지 않으면, 품질이 떨어진 사실을 고객 클레임으로 알게 됩니다.
거대 모델의 비용·속도·프라이버시 한계에 대한 대안으로 부상했으며, 경량화 기술(증류·양자화)의 발전과 함께 주목받고 있습니다.
가상의 사례로 살펴보겠습니다. 자동차 부품을 만드는 A사는 임직원 380명, 연매출 950억 원 규모입니다. 공장 내부망은 외부 인터넷이 차단돼 있어, 현장 작업자가 설비 에러를 만나면 종이 매뉴얼을 뒤지거나 생산기술팀에 전화를 거는 수밖에 없었습니다. 설비 한 대가 멈추면 평균 14분이 그대로 날아갔습니다.
- 생산기술팀 김 팀장이 3주간 현장 질문 1,840건을 모아보니 78%가 에러코드 해석과 부품 교체 주기 같은 반복 질의였습니다.
- 정보보안팀장이 "공정 도면이 외부로 나가는 건 결재 못 올린다"고 못을 박아, 7B 모델을 INT4로 양자화해 공장 서버 한 대에 올리기로 방향을 틀었습니다.
- 설비 매뉴얼 2,300쪽과 6년치 보전 이력을 정리해 QA 4,000쌍을 만들고 2주간 파인튜닝했지만, 첫 정답률은 61%에 그쳤습니다.
- 현장 반장 12명이 2주간 써보며 오답 340건을 표시했고, 이걸 재학습에 넣자 정답률이 61%에서 88%로 올라갔습니다.
- "이 불량의 근본 원인을 분석해 달라" 같은 추론 질문은 계속 헛소리를 해서, 월 40~50건인 이 유형만 보안 검토를 거친 외부 LLM으로 넘기는 2단 구조로 나눴습니다.
- 6개월 뒤 설비 문의 대기 시간은 14분에서 3분으로 줄었고, 클라우드 API로 전량 처리했을 때의 추정 비용 월 1,900만 원 대신 서버 감가 포함 월 210만 원으로 돌아가고 있습니다.
- 특정 용도로 파인튜닝할 때
- 비용·속도·프라이버시가 중요
- 온디바이스로 돌려야 할 때
- 다양·복잡한 범용 작업
- 최고 성능이 최우선일 때
- 용도가 자주 바뀌는 경우