SLM 우선 에이전트: 왜 2026년 최고의 에이전트 시스템은 소형 모델(Small Models)로 구동되는가

2024년과 2025년 대부분의 기간 동안, "이 에이전트에는 어떤 모델을 사용해야 하는가?"라는 질문에 대한 기본적 아키텍처 답변은 "예산이 허용하는 가장 큰 프론티어 모델(Frontier Model)"이었습니다. 2026년에는 이러한 기본 설정이 깨지고 있습니다. Phi-4-mini, Qwen3.5-4B, SmolLM3-3B, Gemma-4-E2B, Mistral-7B와 같은 소형 언어 모델(Small Language Models, SLM)의 물결이 실제 운영 환경의 에이전트 워크로드(Agentic Workloads)를 조용히 점유하고 있습니다. 이들이 승리하는 이유는 MMLU에서 프론티어 모델을 이기기 때문이 아닙니다. 실제 에이전트가 수행하는 좁은 범위의, 스키마(Schema)로 제약된, 도구 호출(Tool-calling) 중심의 작업에 있어서 잘 미세 조정된(Fine-tuned) 3B–7B 모델이 더 빠르고, 저렴하며, 예측 가능하고, 평가하기 쉽기 때문입니다.

흥미로운 결과이자 대부분의 팀이 과소평가하는 부분은, 이러한 변화가 엔지니어링 문제를 모델 자체에서 데이터로 이동시킨다는 점입니다. 만약 당신이 중요한 워크플로우에 4B 모델을 배포하려 한다면, 당신의 학습 및 평가 데이터는 과거에 프론티어 모델이 압도적인 규모(Scale)만으로 대신해주었던 역할을 수행해야 합니다. 이것이 바로 2026년 SLM의 진정한 이야기입니다.

에이전트 워크로드가 소형 모델에 유독 적합한 이유

운영 환경에서 에이전트가 실행되는 것을 관찰하면 세 가지 패턴이 지배적입니다. 모델은 고정된 JSON 스키마(Schema)에 따라 도구 호출(Tool call)을 생성합니다. 모델은 작고 알려진 다음 단계 세트 중에서 하나를 선택합니다. 모델은 구조화된 입력(Structured input)의 덩어리를 요약하거나 변환하여 구조화된 출력(Structured output)으로 만듭니다. 에이전트가 수행하는 작업 중 200B 파라미터 규모의 범용 모델(Generalist)이 가진 광범위한 능력을 필요로 하는 것은 거의 없습니다. 에이전트에게 필요한 것은 좁은 분포(Narrow distribution)에서의 신뢰성입니다.

좁은 분포는 소형 모델이 빛을 발하는 영역입니다. 에이전트 배포에 관한 최근 조사에 따르면, 목표가 스키마 및 API로 제약된 워크로드의 경우 1–12B 범위의 모델로도 충분하며, 종종 더 우수하다는 것이 밝혀졌습니다. 프론티어 모델의 추가적인 파라미터들은 대부분 에이전트가 전혀 사용하지 않는 능력들, 즉 오픈 도메인 상식, 희귀 언어 번역, 창의적 글쓰기 등을 위해 비용을 지불하는 것입니다. 당신은 즉시 버려지게 될 용량(Capacity)을 위해 프론티어 모델의 가격을 지불하고 있는 셈입니다.

지연 시간(Latency)은 두 번째 강제 요인(Forcing function)입니다. 5번의 도구 호출(Tool calls)이 포함된 에이전트 루프(Agentic loop)는 모델의 지연 시간을 5배로 증폭시킵니다. 로컬 환경이나 단일 H100에서 실행되는 4B 모델은 한 단계를 50200ms 내에 완료할 수 있지만, API를 통한 프론티어 모델(Frontier model)은 단계당 6001500ms를 넘기기 어렵습니다. 10단계로 구성된 루프의 경우, 이는 4초짜리 에이전트와 15초짜리 에이전트의 차이를 만듭니다. 그리고 제품 팀은 15초라는 시간을 즉각적으로 체감합니다.

세 번째 이유는 운영(Operational) 측면입니다. 소형 모델은 감사(Auditable)가 가능합니다. 모든 커밋(Commit)에 대해 결정론적 평가 스위트(Deterministic eval suite)를 실행할 수 있고, 몇 주가 아닌 몇 시간 만에 미세 조정(Fine-tuning)을 할 수 있으며, 데이터를 프론티어 API로 전송하는 것이 불가능한 환경(에어갭(Air-gapped), 규제 환경, 온디바이스(On-device))에 배포할 수 있습니다. 마지막 포인트는 과거보다 훨씬 더 중요해졌습니다. 특히 의료, 금융, ADAS(첨단 운전자 보조 시스템) 팀들은 데이터가 외부로 유출될 수 없기 때문에 지난 1년 동안 SLM 스택을 구축하는 데 집중해 왔습니다.

SLM 우선(SLM-first)으로 전환할 때 변하는 것들

여기에 함정이 있습니다. 4B 모델이 귀하의 워크로드에서 높은 성능을 보이는 이유는 모델 그 자체 때문이 아닙니다. 바로 사후 학습(Post-training) 때문입니다. Phi-4의 결과는 유용한 증거가 됩니다. Microsoft는 약 5T 토큰으로 이를 학습시켰지만, 핵심은 그 데이터가 추론 밀도가 높은 합성 콘텐츠(Synthetic content), 신중하게 필터링된 웹 자료, 그리고 구조화된 교육용 텍스트였다는 점입니다. 모델은 작지만, 데이터는 방대하고 정교하게 큐레이션되었습니다.

SLM 우선 에이전트를 출시하면, 세 가지 데이터 문제가 OpenAI나 Anthropic의 문제가 아닌 귀하의 문제가 됩니다.

1. 도구 호출 추적(Tool-call trace) 품질. 올바른 인자(Arguments), 올바른 스키마(Schema), 현실적인 문맥(Context)을 갖춘 깨끗한 도구 호출 코퍼스(Corpus)로 미세 조정된 4B 모델은, 동일한 작업에 제로샷(Zero-shot)으로 사용된 프론티어 모델보다 더 뛰어난 성능을 보일 것입니다. 반면 지저분한 코퍼스로 미세 조정된 4B 모델은 인자를 환각(Hallucinate)하거나, 필수 필드를 누락하거나, 검증은 간신히 통과할 정도의 JSON을 조용히 생성할 것입니다. 이 두 결과 사이의 격차는 전적으로 학습 추적(Training traces)이 어떻게 수집, 라벨링 및 검증되었는지에 달려 있습니다.

2. 선호도 및 궤적 교정 (Preference and trajectory correction). 도구 호출 (Tool calling)은 쉬운 부분입니다. 더 어려운 부분은 도구가 예상치 못한 결과 — 에러, 부분적인 결과, 누락된 레코드 — 를 반환했을 때 에이전트가 어떻게 행동하느냐 하는 것입니다. Frontier models는 수십억 개의 인간 교정 상호작용을 흡수했기 때문에 우아하게 복구합니다. 하지만 여러분의 SLM은 그렇지 않습니다. 동일한 복구 동작을 얻으려면 에이전트 궤적 (Agent trajectories)에 대한 RLHF 방식의 선호도 데이터가 필요합니다. 즉, 해당 도메인을 실제로 이해하는 사람들이 라벨링한 "모델이 수행한 것"과 "모델이 수행했어야 하는 것"의 쌍이 필요합니다. 일반적인 크라우드 소싱 라벨러들은 이를 수행할 수 없습니다. SyncSoft.AI의 추론 및 인간 피드백 데이터 서비스와 같은 제공업체들이 전문으로 하는 이중 언어 SME (Subject Matter Expert, 분야 전문가) 중심의 팀이 이러한 종류의 교정 데이터를 대규모로 확보할 수 있는 실질적인 방법입니다.

3. 도메인 기반 평가 (Domain-grounded evaluation). MMLU와 HumanEval의 성능만 믿고 SLM을 규제 대상 워크플로우에 배포할 수는 없습니다. 실제 파이프라인에서 발생하는 실제 실패 모드 (Failure modes)를 기반으로 구축되고, 여러분이 중요하게 생각하는 상황에 대한 적대적 사례 (Adversarial cases)를 포함하는 도메인 특화 벤치마크가 필요합니다. 2026년의 프로덕션 팀들은 하나의 패턴으로 수렴하고 있습니다. 바로 도구 호출, 다단계 추론 (Multi-step reasoning), 거부 동작 (Refusal behavior), 그리고 복구를 테스트할 수 있도록 정교하게 구성된 수백 개의 프롬프트 홀드아웃 세트 (Held-out set)를 만들고, 이를 프로그래밍 방식의 체크와 인간의 검토를 결합하여 점수를 매기는 방식입니다. 이 벤치마크는 모든 모델 업데이트의 관문이 됩니다.

실제로 작동하는 구체적인 패턴

SLM 우선 에이전트를 성공적으로 출시하는 팀들은 유사한 파이프라인으로 수렴하는 경향이 있습니다. 이 단계들은 화려하지 않고 투자가 소홀해지기 쉽기 때문에 구체적으로 설명할 가치가 있습니다.

이미 강력한 도구 호출 (tool-calling) 동작을 갖춘 베이스 모델 (base model)로 시작하십시오. 현재는 Qwen3.5-4B와 Phi-4-mini가 기본값이며, 두 모델 모두 Apache-2.0 또는 MIT 라이선스를 따릅니다. 대상 워크플로 (workflow)가 올바르게 완료되는 수천 개의 트레이스 (traces)를 수집하십시오. 이는 인간의 시연 (human demonstrations), 교사 (teacher)로 사용된 프런티어 모델 (frontier model)의 트레이스, 또는 가장 흔하게는 이들의 혼합 형태가 될 수 있습니다. 도메인 전문가들이 해당 트레이스의 유의미한 비율을 검토하고 수정하도록 하십시오. 이것이 지도 미세 조정 (supervised fine-tuning, SFT) 코퍼스 (corpus)가 됩니다.

베이스 모델에 대해 SFT를 실행하십시오. 도메인 벤치마크 (benchmark)를 통해 평가합니다. 첫 번째 라운드가 기준을 통과하는 경우는 거의 없습니다. 흥미로운 질문은 "통과했는가"가 아니라 "어떤 종류의 실수를 저질렀는가"입니다. 거의 모든 실수는 세 가지 범주 중 하나에 속할 것입니다: 스키마 위반 (schema violations, 스키마의 엣지 케이스 (edge cases)를 다루는 더 많은 SFT 예시로 해결), 잘못된 도구 선택 (wrong tool selection, 모호한 프롬프트에 대해 올바른 도구와 잘못된 도구를 대조하는 선호도 쌍 (preference pairs)으로 해결), 그리고 잘못된 복구 (bad recovery, 도구 오류를 처리하는 방법을 보여주는 궤적 데이터 (trajectory data)로 해결).

반복하십시오. 실제 현장에서 적절한 주기는 주 단위입니다. 지난주의 운영 실패 사례를 수집하고, 어노테이터 (annotators)가 이를 수정하게 한 뒤, 다음 학습 실행에 혼합하십시오. 3~4번의 사이클을 거치면 워크플로에 대한 모델의 동작이 극적으로 정교해집니다. 10번 정도 반복하면, 제로샷 (zero-shot)으로 사용된 프런티어 모델보다 귀하의 특정 작업에서 더 신뢰할 수 있는 경향을 보입니다. 왜냐하면 프런티어 모델은 귀하의 스키마, 도구, 또는 오류 모드 (error modes)를 본 적이 없지만, 귀하의 모델은 그 외에는 거의 본 적이 없기 때문입니다.

이 루프 (loop)의 병목 현상은 거의 항상 컴퓨팅 자원 (compute)의 문제입니다. 병목은 데이터 작업의 속도와 품질, 특히 도메인과 에이전트 패턴 (agentic pattern)을 모두 이해하는 사람이 수행해야 하는 궤적 수정 (trajectory correction) 작업입니다. 일반 라벨러 (labelers)를 통해 이를 크라우드소싱하려는 팀은 정체되는 경향이 있는 반면, SME (Subject Matter Expert, 전문 지식 보유자)가 주도하는 어노테이션 파트너와 협력하는 팀 — 예를 들어 SyncSoft.AI의 멀티모달 데이터 어노테이션 서비스를 통하는 경우 — 은 주기를 계속 유지하는 경향이 있습니다.

이것이 귀하의 기술 스택(Stack)에 의미하는 바

만약 귀하가 2026년에 에이전트 시스템(Agentic systems)을 구축하고 있다면, 질문은 더 이상 "어떤 프론티어 모델(Frontier model)이 가장 좋은가?"가 아닙니다. 질문은 "내 특정 작업에 소형 모델(Small model)이 능숙해지도록 만들 데이터 파이프라인(Data pipeline)을 갖추고 있는가?"가 되어야 합니다. 세 가지 실질적인 시사점은 다음과 같습니다.

연산(Compute)뿐만 아니라 데이터 작업에 예산을 할당하십시오. 비용 비율이 변화하고 있습니다. 전형적인 SLM 우선 에이전트 프로젝트는 GPU 사용 시간보다 라벨링된 궤적 데이터(Labeled trajectory data)에 2~4배 더 많은 비용을 지출합니다. 그것이 올바른 비율입니다.

모델을 만들기 전에 평가 벤치마크(Evaluation benchmark)를 구축하십시오. 평가(Eval)를 먼저 구축하는 팀은 더 빠르게 제품을 출시하게 됩니다. 왜냐하면 그들은 "이것이 더 나은가"에 대한 명확한 신호(Signal)를 가지고 있기 때문입니다. 모델을 먼저 구축하는 팀은 변경 사항이 실제 개선인지에 대해 논쟁하며 수개월을 허비합니다.

데이터 파트너를 모델 팀의 일부로 취급하십시오. 주석 달기(Annotation) 기능을 내부적으로 구축하든 전문 업체와 협력하든, 도구 호출 추적(Tool-call traces)과 선호 데이터(Preference data)를 생성하는 사람들은 기능적으로 귀하의 ML 엔지니어링 조직의 일부입니다. "데이터 파트너"와 "학습 팀(Training team)" 사이의 인수인계 과정에서 대부분의 프로젝트가 수개월을 낭비합니다. 실제 QA(품질 보증)를 거친 검토된 추적 데이터를 주간 단위로 전달할 수 있는 내부 또는 외부 파트너를 선택하십시오. 3단계 QA 파이프라인(Triple-pass QA pipelines)은 오버헤드가 아닙니다. 그것은 SFT(지도 미세 조정) 코퍼스(Corpus)를 유용할 만큼 깨끗하게 유지할 수 있는 유일한 방법입니다.

모델 군비 경쟁은 계속될 것이며, 프론티어 모델은 연구용, 원샷(One-shot) 복합 추론용, 그리고 아직 도메인 데이터가 존재하지 않는 새로운 작업용으로서 그 자리를 유지할 것입니다. 하지만 제품 내부에서 조용히 실행되며 매일 가치를 전달하는 시스템의 경우, 아키텍처는 우리 아래에서 변화하고 있습니다. 응용 AI(Applied AI) 분야에서 향후 2년 동안의 경쟁 우위는 가장 큰 모델에 비용을 지불하는 팀이 아니라, 소형 미세 조정 모델(Small, fine-tuned model)을 중심으로 데이터 플라이휠(Data flywheel)을 제대로 구축하는 팀에 의해 결정될 것입니다.

저자는 SyncSoft.AI에서 근무하고 있으며, 이곳에서 우리는 AI 팀이 소형 모델을 프로덕션 단계에서 사용할 수 있도록 만드는 데이터 파이프라인 — SFT 코퍼스 (SFT corpora), RLHF 선호도 세트 (RLHF preference sets), 에이전트 궤적 수정 (agent trajectory corrections), 그리고 도메인 기반 평가 (domain-grounded evaluations) — 을 구축하도록 지원합니다. 만약 여러분이 위에서 언급한 패턴들 중 하나라도 씨름하고 있다면, 기꺼이 서로의 경험을 공유하고 논의하고 싶습니다.