← 블로그 목록

AI 기능, 무조건 대형 LLM API가 답은 아니다 — 비용·데이터 주권으로 따져보는 SLM·온디바이스 도입 판단법

2026.06.228분

"일단 대형 LLM API부터 붙이자"는 관성을 의심하세요

새 서비스에 AI 기능을 넣기로 했다면, 많은 팀이 가장 먼저 떠올리는 그림은 비슷합니다. 잘 알려진 대형 LLM API에 연결하고, 프롬프트를 다듬어 결과를 받아오는 구조입니다. 빠르게 데모를 만들 수 있고 성능도 인상적이니, 이것이 사실상 '기본값'처럼 굳어졌습니다.

a computer chip with the letter a on top of it

하지만 발주자 입장에서 보면 이 선택은 데모가 아니라 운영의 문제입니다. 호출량이 늘수록 비용은 사용량에 비례해 불어나고, 사용자의 입력 데이터는 외부 서버로 빠져나갑니다. 게다가 2026년 1월 22일부터 AI 기본법이 시행되면서(Mondrian AI 등) 데이터 주권과 투명성 의무가 현실의 제약이 되었습니다. 모델 전략은 개발이 끝난 뒤가 아니라 발주 단계에서 정해야 하는 의사결정입니다.

SLM·온디바이스가 더 맞는 경우는 따로 있다

소형 언어모델(SLM)은 적은 파라미터와 간소화된 구조로 특정 도메인에 최적화된 모델입니다. CIO Korea, 디딤·카카오클라우드 등은 SLM의 핵심 이점으로 운영비용과 에너지 소비 절감, 그리고 환각(할루시네이션) 감소를 꼽습니다. 좁은 업무에 한정할수록 작은 모델이 오히려 안정적으로 동작한다는 것입니다.

국내 움직임도 구체화 단계에 들어섰습니다. 업스테이지는 LG전자와 온디바이스 AI용 SLM 개발에 협력하기로 했고(한국일보 등), 카카오는 카카오브레인 SLM을 바탕으로 카카오톡 '안 읽은 메시지 요약' 같은 기능을 실험 중이며, 네이버도 하이퍼클로바 계열의 경량화를 추진하고 있습니다(글로벌다이렉트뉴스). 대형 모델 일변도가 아니라, 용도에 맞춰 모델 크기를 고르는 흐름이 자리 잡고 있는 셈입니다.

SLM·온디바이스 쪽으로 기우는 신호

  • 처리 데이터가 민감한 경우 — 개인정보·의료·금융·사내 문서처럼 외부로 내보내기 어려운 데이터라면, 온프레미스·온디바이스 SLM이 데이터 유출과 규제 대응 측면에서 유리합니다.
  • 업무 범위가 좁고 반복적인 경우 — 분류, 요약, 정형 추출, 사내 규정 응답처럼 도메인이 명확하면 거대 범용 능력은 과잉입니다.
  • 호출량이 많고 예측 가능한 경우 — 사용량이 늘수록 API 종량 비용이 부담이 되는 구조라면, 자체 운영하는 작은 모델의 비용 곡선이 더 완만합니다.
  • 오프라인·저지연이 필요한 경우 — 네트워크가 불안정한 환경이나 단말에서 즉시 응답해야 하는 기능은 온디바이스가 자연스럽습니다.

반대로 폭넓은 지식과 복잡한 추론, 다국어 자유 대화가 핵심이거나 트래픽이 적어 종량 비용이 미미한 초기 서비스라면, 대형 LLM API가 여전히 합리적입니다. 둘은 우열이 아니라 용도 적합성의 문제입니다.

a computer circuit board with a brain on it

발주 단계에서 모델 전략을 정하는 프레임워크

외주 파트너로서 권하는 방식은, 기능 명세를 적기 전에 다음 네 가지를 먼저 합의하는 것입니다.

  • 데이터 등급 — 이 기능이 다루는 데이터가 외부로 나가도 되는지부터 정의합니다. 나가면 안 되는 데이터가 있다면 그 순간 온프레미스·온디바이스가 후보로 올라옵니다.
  • 작업의 난이도와 범위 — 좁고 정형화된 작업인지, 열린 추론이 필요한지 구분합니다. 좁다면 SLM 우선 검토 대상입니다.
  • 예상 호출량과 비용 구조 — 종량 과금이 운영 단계에서 어떻게 누적되는지 시나리오로 따져봅니다. 비용은 데모가 아니라 운영에서 드러납니다.
  • 규제·책임 — AI 기본법상 투명성·데이터 주권 의무를 누가, 어떻게 충족할지 발주 시점에 명시합니다.

실무에서는 처음부터 한쪽으로 못 박기보다 하이브리드로 설계하는 경우가 많습니다. 민감 데이터를 다루는 핵심 기능은 SLM·온디바이스로, 범용 대화 같은 보조 기능은 대형 API로 나누고, 모델 교체가 쉽도록 호출 계층을 추상화해 두는 식입니다. 다행히 낮은 비용과 적은 자원 요구 덕분에 작은 팀도 기존 모델·API 조합으로 PoC를 빠르게 구성·배포할 수 있어(디딤·카카오클라우드, KoreaTechDesk), 발주 전에 여러 전략을 가볍게 검증해 보는 부담이 크게 줄었습니다.

정리하며

대형 LLM API는 강력한 선택지이지만 '유일한 기본값'은 아닙니다. 데이터 등급, 작업 범위, 비용 구조, 규제라는 네 축으로 따져보면 SLM·온디바이스가 더 맞는 자리가 분명히 보입니다. 중요한 것은 이 판단을 개발이 끝난 뒤가 아니라 발주 단계에서 끝내는 것입니다. 모델 전략은 기술 세부사항이 아니라 서비스의 비용과 리스크를 좌우하는 경영 의사결정이며, 좋은 외주 파트너라면 첫 미팅에서 함께 짚어야 할 질문입니다.