새 서비스에 AI 기능을 넣기로 했다면, 많은 팀이 가장 먼저 떠올리는 그림은 비슷합니다. 잘 알려진 대형 LLM API에 연결하고, 프롬프트를 다듬어 결과를 받아오는 구조입니다. 빠르게 데모를 만들 수 있고 성능도 인상적이니, 이것이 사실상 '기본값'처럼 굳어졌습니다.
하지만 발주자 입장에서 보면 이 선택은 데모가 아니라 운영의 문제입니다. 호출량이 늘수록 비용은 사용량에 비례해 불어나고, 사용자의 입력 데이터는 외부 서버로 빠져나갑니다. 게다가 2026년 1월 22일부터 AI 기본법이 시행되면서(Mondrian AI 등) 데이터 주권과 투명성 의무가 현실의 제약이 되었습니다. 모델 전략은 개발이 끝난 뒤가 아니라 발주 단계에서 정해야 하는 의사결정입니다.
소형 언어모델(SLM)은 적은 파라미터와 간소화된 구조로 특정 도메인에 최적화된 모델입니다. CIO Korea, 디딤·카카오클라우드 등은 SLM의 핵심 이점으로 운영비용과 에너지 소비 절감, 그리고 환각(할루시네이션) 감소를 꼽습니다. 좁은 업무에 한정할수록 작은 모델이 오히려 안정적으로 동작한다는 것입니다.
국내 움직임도 구체화 단계에 들어섰습니다. 업스테이지는 LG전자와 온디바이스 AI용 SLM 개발에 협력하기로 했고(한국일보 등), 카카오는 카카오브레인 SLM을 바탕으로 카카오톡 '안 읽은 메시지 요약' 같은 기능을 실험 중이며, 네이버도 하이퍼클로바 계열의 경량화를 추진하고 있습니다(글로벌다이렉트뉴스). 대형 모델 일변도가 아니라, 용도에 맞춰 모델 크기를 고르는 흐름이 자리 잡고 있는 셈입니다.
반대로 폭넓은 지식과 복잡한 추론, 다국어 자유 대화가 핵심이거나 트래픽이 적어 종량 비용이 미미한 초기 서비스라면, 대형 LLM API가 여전히 합리적입니다. 둘은 우열이 아니라 용도 적합성의 문제입니다.
외주 파트너로서 권하는 방식은, 기능 명세를 적기 전에 다음 네 가지를 먼저 합의하는 것입니다.
실무에서는 처음부터 한쪽으로 못 박기보다 하이브리드로 설계하는 경우가 많습니다. 민감 데이터를 다루는 핵심 기능은 SLM·온디바이스로, 범용 대화 같은 보조 기능은 대형 API로 나누고, 모델 교체가 쉽도록 호출 계층을 추상화해 두는 식입니다. 다행히 낮은 비용과 적은 자원 요구 덕분에 작은 팀도 기존 모델·API 조합으로 PoC를 빠르게 구성·배포할 수 있어(디딤·카카오클라우드, KoreaTechDesk), 발주 전에 여러 전략을 가볍게 검증해 보는 부담이 크게 줄었습니다.
대형 LLM API는 강력한 선택지이지만 '유일한 기본값'은 아닙니다. 데이터 등급, 작업 범위, 비용 구조, 규제라는 네 축으로 따져보면 SLM·온디바이스가 더 맞는 자리가 분명히 보입니다. 중요한 것은 이 판단을 개발이 끝난 뒤가 아니라 발주 단계에서 끝내는 것입니다. 모델 전략은 기술 세부사항이 아니라 서비스의 비용과 리스크를 좌우하는 경영 의사결정이며, 좋은 외주 파트너라면 첫 미팅에서 함께 짚어야 할 질문입니다.