기업들은 왜 초거대 AI 대신 sLLM을 검토할까

업계 전망에 따르면 2027년까지 기업의 sLLM 사용량은 현재 대비 약 3배 증가할 것으로 예상됩니다. 배경은 두 가지입니다. 첫째는 비용입니다. 초거대 모델 API를 전사적으로 사용하면 호출량에 비례해 비용이 빠르게 늘어나지만, sLLM은 특정 업무에 맞춰 가볍게 운영할 수 있어 총소유비용(TCO)이 낮습니다.

둘째는 보안입니다. 금융·공공기관처럼 데이터를 외부로 보내기 어려운 조직은 자체 서버에 설치하는 온프레미스 AI 형태의 sLLM을 대안으로 검토하고 있습니다.

sLLM 단독 도입 시 부딪히는 한계

sLLM은 파라미터 규모가 작아 특정 업무에는 강하지만, 학습 시점 이후의 최신 정보나 회사 고유 데이터는 알지 못합니다. 아래는 초거대 모델과 sLLM 단독 운영을 비교한 기준입니다.

결국 sLLM의 비용·보안 이점을 살리면서 한계를 메우려면, 최신 데이터를 검색해 답변에 반영하는 RAG(검색 증강 생성)와 여러 모델·툴을 상황에 맞게 연결하는 오케스트레이션 구조가 함께 필요합니다.

실제로 기업들은 sLLM을 어디에 쓰고 있을까

sLLM은 하나의 모델이 모든 걸 처리하기보다, 업무 단위로 쪼개서 투입하는 방식으로 쓰입니다. 사내 문의를 1차로 응대하는 고객 상담 챗봇, 계약서·보고서 초안을 요약하는 문서 처리, 코드 리뷰를 보조하는 개발 도구 등이 대표적인 적용 영역입니다. 업무마다 정확도 요구 수준이 다르기 때문에, 하나의 초거대 모델보다는 업무별로 특화된 여러 개의 작은 모델을 나눠 쓰는 편이 비용 대비 효율이 높다는 평가를 받습니다.

실제로 국내외에는 LG의 EXAONE, 업스테이지의 Solar Mini, 구글의 Gemma, 마이크로소프트의 Phi 시리즈처럼 경량화에 초점을 맞춘 모델들이 이미 출시돼 있습니다. 이런 모델들은 파라미터 수가 초거대 모델의 수십 분의 1 수준이면서도, 특정 언어·업무에서는 비슷하거나 더 나은 정확도를 보이는 경우가 많습니다.

다만 어떤 sLLM을 쓰더라도 학습 시점 이후의 최신 데이터는 알지 못한다는 한계는 동일합니다. 그래서 실제 도입 단계에서는 모델 선택 자체보다, 이 모델에 최신 사내 데이터를 어떻게 연결할지가 더 중요한 과제로 다뤄집니다.

RAG·MCP 오케스트레이션으로 sLLM의 한계를 보완하는 RAToRu

I-ON Communications의 RAToRu는 MCP(Model Context Protocol) 기반으로 설계된 엔터프라이즈 AI 솔루션입니다. RAG 기능을 맡는 RAGo와 여러 모델·툴을 연결하는 ToolHUB를 통해, sLLM처럼 가벼운 모델을 쓰더라도 사내 최신 데이터에 근거한 답변을 받을 수 있도록 표준화된 구조로 제공합니다.