[AI] 가성비 좋은 소형 모델(SLM)의 부상: 특정 도메인에서의 반란

처음에는 다들 큰 모델부터 붙여보려고 합니다. 그런데 특정 도메인 업무에서는 모델이 클수록 무조건 좋은 결과가 나오는 게 아니더군요. 오히려 분류, 태깅, 요약, FAQ 응답처럼 문제 범위가 좁은 작업은 SLM이 더 다루기 편한 경우가 많습니다. 원문도 그런 문제의식에서 출발하고 있었는데, 중간부터 운영 이야기와 구현 예시가 너무 길어지면서 정작 주제인 SLM과 LLM 비교가 흐려졌습니다.

SLM, LLM 비교에서 먼저 봐야 하는 것은 모델 크기가 아니다

SLM과 LLM을 비교할 때 많은 팀이 먼저 보는 것은 파라미터 수나 벤치마크 점수입니다. 그런데 실무에서는 그보다 먼저 확인해야 할 것이 있습니다. 우리 서비스가 정말 범용 추론이 필요한지, 아니면 범위가 좁은 도메인 작업인지입니다.

예를 들어 고객 문의 분류, 상품 속성 정규화, 로그 이벤트 라벨링, FAQ 매칭, 내부 문서 요약처럼 입력과 출력의 형태가 어느 정도 고정된 문제라면 꼭 큰 LLM이 필요하지 않은 경우가 많습니다. 이런 작업은 질문 패턴도 반복되고, 정답 형식도 제한적입니다. 

 

이 글에서 비교해야 하는 핵심

이 주제의 핵심은 단순합니다. SLM이 LLM보다 무조건 좋다는 이야기도 아니고, LLM이 시대를 끝냈다는 이야기도 아닙니다. 특정 도메인 업무에서 어디까지 SLM으로 충분한지, 그리고 어떤 구간부터는 여전히 LLM이 필요한지를 구분하는 것이 핵심입니다.

SLM vs LLM, 실제 Pain Point는 모델 성능보다 과한 선택에서 나온다

운영 현장에서 자주 보는 문제는 성능 부족보다 과한 선택입니다. 질문 범위가 좁고 출력 형식도 정해져 있는데, 처음부터 큰 LLM 하나로 전부 해결하려고 하면 시스템이 무거워집니다. 반대로 복합 추론이 필요한 작업인데 작은 모델에 너무 많은 기대를 걸면 정확도와 안정성이 흔들립니다.

즉 문제는 SLM이냐 LLM이냐 자체가 아니라, 업무 성격에 맞지 않는 모델을 선택하는 데서 나옵니다. 생각보다 자주 발생합니다. 모델이 크다고 다 잘하는 것도 아니고, 작다고 다 못하는 것도 아닙니다.

도메인 작업 예시 - 고객 문의 카테고리 분류 - 티켓 우선순위 태깅 - 상품 메타데이터 정리 - FAQ 후보 검색 - 짧은 문서 요약 

위와 같은 문제는 범용 추론 능력보다 일관된 출력과 빠른 처리, 통제 가능한 동작이 더 중요합니다. 그래서 이런 영역에서는 SLM이 충분히 경쟁력이 있습니다.

 

SLM이 잘 맞는 작업, LLM이 필요한 작업은 다르다

주제를 분명히 하려면 이 구분을 먼저 해야 합니다. SLM은 보통 문제 범위가 좁고 반복 패턴이 분명한 작업에서 강합니다. 반대로 LLM은 긴 문맥 이해, 복합 추론, 예외 대응, 자유도가 높은 생성 작업에서 강점을 보입니다.

SLM이 잘 맞는 경우

입력이 짧고 출력 형식이 정해져 있을수록 SLM이 유리합니다. 예를 들면 문의 분류, 요약 라벨링, 금칙어 탐지 보조, 검색 relevance 판단, 속성 추출 같은 작업입니다. 이런 문제는 정답 범위가 좁기 때문에 큰 모델의 범용성이 꼭 필요하지 않습니다.

또 도메인 데이터가 충분히 있고 평가셋을 만들기 쉬운 경우에도 SLM이 강해집니다. 좁은 문제에서는 작은 모델이 훨씬 빠르게 튜닝 포인트를 찾을 수 있기 때문입니다. 

 

LLM이 필요한 경우

반대로 문맥이 길고, 질문 형태가 다양하고, 답변 방식이 정해져 있지 않은 작업은 아직도 LLM이 유리한 경우가 많습니다. 정책 문서를 여러 장 읽고 종합 답변을 해야 하거나, 다양한 예외를 고려한 생성이 필요한 경우가 그렇습니다.

즉 LLM의 장점은 범용성입니다. 이 범용성이 비즈니스에서 바로 가치가 되는 작업이라면 작은 모델만으로 버티는 것은 오히려 손해일 수 있습니다.

 

SLM, LLM 선택 과정에서 실제로 비교해야 하는 두 가지 방법

실무에서는 결국 두 가지 접근이 부딪힙니다. 하나는 범용 LLM 하나로 최대한 많은 문제를 덮는 방식이고, 다른 하나는 SLM 중심으로 업무를 쪼개고 필요한 곳만 LLM을 쓰는 방식입니다. 

방법 A: 범용 LLM 하나로 통합

장점은 빠른 출발입니다. 프롬프트 몇 개만 잘 설계하면 요약, 분류, 질의응답, 초안 생성까지 한 모델로 묶을 수 있습니다. PoC 단계에서는 이 방식이 가장 빨리 결과를 보여줍니다.

하지만 단점도 분명합니다. 작업별 요구사항이 다른데 하나의 모델에 모두 몰아넣다 보면 프롬프트가 길어지고, 제어가 어려워집니다. 나중에는 문제를 세밀하게 분리하기보다 큰 모델에 계속 의존하게 됩니다. 

 

방법 B: SLM 중심으로 작업 분리

이 방식은 도메인 업무를 쪼개서 보는 접근입니다. 분류는 SLM, 규칙 기반으로 처리 가능한 것은 룰 엔진, 긴 문맥 검색은 RAG, 그리고 정말 어려운 경우만 LLM으로 올리는 식입니다.

장점은 명확합니다. 각 작업의 성격에 맞게 도구를 나눌 수 있습니다. 특정 단계가 흔들려도 전체 시스템이 다 흔들리는 것이 아니라, 어느 부분이 문제인지 비교적 선명하게 보입니다. 체감상 특정 도메인에서는 이 구조가 더 오래 갑니다.

물론 단점도 있습니다. 모델 하나만 붙이는 것보다 구조가 복잡해집니다. 라우팅 기준, 평가셋, fallback 규칙, 프롬프트 관리 같은 부수 요소가 늘어납니다. 그래도 이 복잡도는 납득 가능한 복잡도입니다.

 

제가 보는 최종 선택 기준

특정 도메인 업무라면 기본은 SLM, 예외는 LLM이 더 맞는 경우가 많습니다. 반대로 처음부터 문제 범위가 넓고 추론 깊이가 깊다면 LLM 중심으로 가는 것이 낫습니다. 결국 이 주제의 답은 어느 모델이 더 우월하냐가 아니라, 어떤 작업을 누구에게 맡길 것이냐입니다.

SLM, LLM 비교에서 진짜 중요한 것은 평가셋이다

이 주제에서 빠지면 안 되는 부분이 평가셋입니다. SLM과 LLM을 비교한다고 하면서 추상적인 장단점만 말하면 글이 붕 뜹니다. 결국은 우리 서비스에서 자주 들어오는 질문으로 비교해야 합니다.

예를 들어 고객 문의 분류라면 정상 케이스 500건, 헷갈리는 경계 케이스 200건, 절대 틀리면 안 되는 민감 케이스 100건처럼 나눠서 봐야 합니다. FAQ 매칭이라면 짧은 질문, 오타 포함 질문, 애매한 표현이 섞인 질문을 따로 봐야 합니다. 생각보다 자주 빠지는 부분인데, 이걸 안 하면 모델 비교가 아니라 감상문이 됩니다.

평가 기준 예시 1) 정답률 / F1 2) 응답 일관성 3) 출력 형식 준수율 4) 예외 질문 대응 품질 5) 오분류 발생 시 복구 난이도 

여기서 중요한 것은 모델 스펙이 아니라 실패 패턴입니다. 어떤 질문에서 작은 모델이 무너지는지, 어떤 상황에서 큰 모델이 과한 선택이 되는지를 봐야 합니다.

 

Practical Implementation도 주제를 벗어나면 안 된다

원문에는 Spring Boot, Redis, timeout, fallback, 캐시 같은 구현 요소가 길게 들어가 있었는데, 이 주제에서는 구현의 초점이 조금 달라야 합니다. 핵심은 인프라 튜닝이 아니라 모델 선택 기준과 역할 분리입니다.

구현 예시를 넣더라도 너무 깊게 들어가기보다, 어떤 업무를 어떤 모델에 태우는지가 보여야 합니다. 그래야 글이 SLM과 LLM 비교라는 주제를 놓치지 않습니다.

ai: routing: classification-model: slm-domain-classifier summarization-model: slm-domain-summarizer complex-qa-model: llm-general fallback-enabled: true 

이 정도면 충분합니다. 이 주제에서 중요한 것은 Redis TTL보다도 왜 분류는 SLM이고, 왜 복합 질의응답은 LLM인지 설명하는 것입니다. 

 

특정 도메인에서 SLM, LLM 성능이 갈리는 지점

특정 도메인이라고 해서 무조건 SLM이 이기는 것은 아닙니다. 도메인이 좁아도 규칙이 자주 바뀌고 예외가 많으면 작은 모델이 불안정할 수 있습니다. 반대로 범용처럼 보이는 문제도 실제로는 패턴이 단순해서 SLM이 충분한 경우가 있습니다.

그래서 중요한 질문은 이것입니다. 우리 서비스의 문제는 좁고 반복적인가, 아니면 넓고 예외가 많은가. 입력 길이는 짧은가, 긴가. 출력은 정형인가, 자유 생성인가. 이 질문에 답이 나오면 SLM과 LLM의 경계도 보이기 시작합니다.

 

Cold Truth: SLM이 LLM을 끝내는 것도 아니고, LLM이 항상 답도 아니다

특정 도메인 업무에서는 SLM이 충분히 강합니다. 특히 분류, 태깅, 정형 출력, 짧은 요약처럼 범위가 좁은 작업에서는 큰 모델이 오히려 과한 선택일 수 있습니다.

하지만 SLM이 모든 것을 대체하는 것은 아닙니다. 문맥이 길고, 예외가 많고, 답변 자유도가 높은 문제는 여전히 LLM이 유리한 구간이 있습니다. 반대로 LLM이 강력하다고 해서 모든 도메인 업무에 무조건 넣는 것도 좋은 선택은 아닙니다.

저는 이렇게 정리합니다. 특정 도메인 업무라면 먼저 SLM으로 문제를 정의해보고, 그다음 정말 필요한 구간에만 LLM을 올리는 편이 좋습니다. 모델 크기보다 문제 구조를 먼저 보는 팀이 결국 더 오래 안정적으로 갑니다.