원문은 twarx.com에서 처음 게시되었습니다 - 전체 대화형 버전은 그곳에서 읽어보세요.

최종 업데이트: 2026년 8월 2일

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. 사람들은 미세 조정된 소형 언어 모델 (SLM)을 사용할지, 아니면 프런티어 LLM (Frontier LLM)을 사용할지에 집착하지만, 실제 AI 기술 스택의 실패는 아무도 설계하지 않은 시스템 사이의 틈새에서 발생합니다. 이 가이드는 실제 운영 환경을 망가뜨리는 레이어를 중심으로 구축(Build) 대 구매(Buy) 결정 전체를 재구성합니다.

현재 급증하고 있는 '최고의 AI 에이전트 플랫폼 2026' 검색과 Unisys 실적 발표에서 언급된 엔터프라이즈 AI 기술 모멘텀은 모두 동일한 결정, 즉 맞춤형 SLM을 구축할 것인가 아니면 기성 LLM을 구매할 것인가로 귀결됩니다. LangGraph, CrewAI, n8n, MCP와 같은 도구들은 두 가지 경로 모두 실행 가능하게 만들었으며, 바로 이 점 때문에 팀들이 계속해서 잘못된 선택을 하고 있습니다.

이 글을 끝까지 읽으면 무엇을 배포해야 하는지, 비용은 얼마나 드는지, 그리고 실제 운영 시스템을 망가뜨리는 격차를 어떻게 메울 수 있는지 알게 될 것입니다.

Enterprise architecture diagram comparing custom small language model against off-the-shelf large language model deployment paths

B2B SaaS 팀이 평가하는 두 가지 배포 경로 — 미세 조정된 맞춤형 SLM 대 오케스트레이션된 기성 LLM — 그리고 그 사이에서 발생하는 AI 조정 격차 (AI Coordination Gap).

구축 vs 구매 질문이 잘못 설정되었는가?

대부분의 운영 리더들이 파일럿 프로젝트 실패 후에야 깨닫게 되는 직관에 반하는 사실이 있습니다. 바로 모델이 병목 현상의 원인인 경우는 드물다는 점입니다. OpenAI나 Anthropic의 프런티어 LLM (Frontier LLM)은 지난 분기에 미세 조정 (Fine-tuning)한 3B 파라미터 규모의 맞춤형 SLM (Small Language Model)보다 거의 모든 벤치마크에서 더 높은 점수를 기록할 것입니다. 그럼에도 불구하고 실제 운영 환경에서는 SLM 배포가 승리하는 경우가 빈번합니다. 이는 SLM이 더 똑똑해서가 아니라, 실행 비용이 더 저렴하고, 응답 속도가 더 빠르며, 거버넌스 (Governance)를 구축하기가 더 쉽기 때문입니다.

진정한 결정 사항은 '어떤 모델이 가장 좋은가'가 아닙니다. '어떤 모델에 어떤 조정 레이어 (Coordination layer)를 결합해야 나의 특정 워크플로 (Workflow)를 위해 신뢰할 수 있고, 감사 가능하며, 저렴한 결과를 만들어낼 수 있는가'입니다. 이것은 모델의 문제가 아니라 시스템의 문제입니다.

월 200만 건의 고객 지원 관련 추론 (Inference)을 처리하는 B2B SaaS 기업은 5,000건의 중대한 계약 분석을 수행하는 에이전시와는 완전히 다른 계산법을 가집니다. 전자는 SLM이 빛을 발하는 비용 및 지연 시간 (Latency)의 문제이며, 후자는 프런티어 LLM이 그 프리미엄 가치를 증명하는 추론 깊이 (Reasoning-depth)의 문제입니다. 워크플로를 매핑하기도 전에 모델을 선택하는 것은 기업들이 잘못된 스택 (Stack)에 6자리 수의 예산을 낭비하게 만드는 방식입니다.

저는 한 핀테크 운영 팀이 이를 혹독하게 배우는 과정을 지켜보았습니다. 그들은 2주마다 변하는 사기 검토 지식 베이스를 바탕으로 맞춤형 SLM을 미세 조정하는 데 약 22만 달러의 예산을 투입했습니다. 8주가 지났을 때 모델은 이미 구식이 되어 있었고, 단 4일 만에 구축할 수 있었던 RAG (Retrieval-Augmented Generation) 파이프라인이 실제 문제를 해결할 수 있었을 것입니다. 문제는 모델이 아니었습니다. 워크플로 매핑이 문제였습니다.

40%
비용 상승과 불분명한 비즈니스 가치로 인해 2027년 말까지 기업용 에이전틱 AI (Agentic AI) 프로젝트의 40%가 취소될 것이라고 Gartner는 예측합니다.
Gartner, 2025

3–15x
대규모 운영 시 자체 호스팅 SLM과 프런티어 LLM API 간의 토큰당 비용 차이
arXiv, 2024

83%
각 단계의 신뢰도가 97%인 6단계 파이프라인의 엔드투엔드 (End-to-end) 신뢰도
arXiv, 2023

여기서부터 프레임워크가 시작됩니다. 당신의 AI 배포를 망치는 것은 모델 선택이 아닙니다. 그것은 선택들 사이에 존재하는 보이지 않는 계층입니다.

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)란 단일 모델 내부가 아니라, 모델, 도구, 그리고 시스템 간의 인계 (handoff) 과정에서 발생하는 신뢰성, 비용, 그리고 책임의 손실을 의미합니다. 이는 개별적으로는 매우 뛰어난 구성 요소들로 구축된 스택이 왜 엔드투엔드 (end-to-end) 측면에서는 여전히 실패하는지를 설명합니다.

SLM이든 LLM이든 모든 모델은 그래프 상의 하나의 노드 (node)일 뿐입니다. 격차는 그 외 모든 곳에 존재합니다. 오래된 컨텍스트를 반환하는 검색 (retrieval) 단계, 타임아웃이 발생하는 도구 호출 (tool call), JSON 스키마 (schema)가 조용히 어긋나는 인계 과정, 그리고 결코 실행되지 않는 폴백 (fallback) 등이 그것입니다. 아래에서는 실제 중요한 워크플로를 기준으로 구축(build) 대 구매(buy)를 평가할 수 있도록 의사결정을 6개의 계층으로 나눕니다.

모델이 병목 현상 (bottleneck)인 경우는 드뭅니다. 인계 과정이 병목입니다.

모든 B2B AI 배포가 결정해야 할 6가지 계층은 무엇인가?

'SLM인가 LLM인가?'라고 묻는 것을 멈추고, 대신 배포를 6개의 계층으로 분해하십시오. 각 계층은 고유의 구축 대 구매에 대한 해답을 가지고 있으며, 모델 계층은 그중 하나일 뿐입니다. 이것은 제가 단 한 줄의 프로덕션 코드를 배포하기 전에 스택을 감사 (audit)할 때 사용하는 프레임워크입니다.

B2B AI 배포를 위한 6계층 조정 스택 (The Six-Layer Coordination Stack)

1

인테이크 및 라우팅 계층 (Intake & Routing Layer) (n8n / API gateway)

들어오는 작업을 분류하고 적절한 모델로 라우팅 (routing)합니다. 저렴한 SLM 분류기가 작업에 프런티어 LLM이 실제로 필요한지 여부를 결정하여, 값비싼 호출이 발생하기 전에 60~70%를 절감합니다. 지연 시간 (Latency) 예산: 200ms 미만.

↓

2

컨텍스트 계층 (Context Layer) (RAG + vector DB — Pinecone)

근거 데이터 (grounding data)를 검색합니다. 파인튜닝 (fine-tuning)이 필요한지 여부를 결정합니다. SLM 기반의 잘 구축된 RAG는 종종 근거가 빈약한 프런티어 LLM보다 성능이 뛰어납니다. 실패 모드: 오래된 임베딩 (embeddings)이 확신에 찬 어조로 잘못된 컨텍스트를 반환함.

↓

3

모델 계층 (Model Layer) (맞춤형 SLM vs 기성품 LLM)

실제 추론 (Inference) 단계입니다. 대량의 좁은 범위 작업(narrow tasks)에는 SLM (Phi, Llama 3.x 8B, Mistral)을 선택하고, 개방형 추론 (open-ended reasoning)에는 LLM (GPT-4급, Claude)을 선택하십시오. 이것은 하나의 노드일 뿐이며, 시스템 전체는 아닙니다.

↓

4

도구 및 액션 계층 (Tool & Action Layer) (MCP + function calling)

모델이 귀사의 CRM, 데이터베이스 또는 결제 시스템과 접촉하는 지점입니다. 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 이러한 연결을 표준화합니다. 가장 높은 '조용한 실패 (silent failure)'의 원천이며, 스키마 드리프트 (schema drift)와 처리되지 않은 도구 오류 (unhandled tool errors)가 발생하는 곳입니다.

↓

5

오케스트레이션 계층 (Orchestration Layer) (LangGraph / CrewAI / AutoGen)

다단계 상태 (multi-step state), 재시도 (retries), 그리고 에이전트 핸드오프 (agent handoffs)를 관리합니다. 상태가 없는 (stateless) 모델을 신뢰할 수 있는 워크플로 (workflow)로 전환합니다. 명시적인 상태 관리 (state management)가 없다면, 이 계층은 83%의 신뢰성 문제가 심화되는 지점이 됩니다.

↓

6

거버넌스 및 관측 가능성 계층 (Governance & Observability Layer) (evals + tracing)

모든 단계를 기록하고, 출력을 점수화하며, 드리프트 (drift)를 포착합니다. 기업들이 건너뛰기 쉬운 계층이지만, 건너뛰는 순간 에이전트가 왜 고객에게 비용을 두 번 청구했는지 설명할 수 없게 됩니다. 규제가 있는 B2B 환경에서는 타협할 수 없는 필수 요소입니다.

신뢰성은 하류(downstream)로 갈수록 복리로 쌓이기 때문에 이 순서가 중요합니다. 취약한 조정 계층 (coordination layer)은 귀사가 선택한 어떤 모델의 이점도 상쇄시켜 버립니다.

계층 1: 인테이크 및 라우팅 (Intake & Routing) — SLM이 조용히 승리하는 지점

대부분의 B2B AI 스택에서 단일 항목 중 가장 높은 ROI를 내는 움직임은 모델을 업그레이드하는 것이 아닙니다. 비싼 모델 앞에 작고 저렴한 분류기 (classifier)를 배치하는 것입니다. 미세 조정된 (fine-tuned) SLM 또는 증류된 (distilled) 모델은 작업이 사소한지 (SLM으로 라우팅), 복잡한지 (프런티어 LLM으로 라우팅), 또는 아예 AI를 거칠 필요가 없는지 (결정론적 규칙으로 라우팅)를 밀리초 단위로 결정할 수 있습니다.

월간 40만 건의 고객 메시지를 처리하는 이커머스 운영자에게 '내 주문 어디 있나요?'와 같은 질문에 GPT-4급의 추론은 필요하지 않습니다. 그것은 단순 조회 (lookup)입니다. 전체 물량의 70%를 SLM으로 라우팅하고 프런티어 모델을 진정한 예외 사례 (edge cases)를 위해 남겨두는 것이, 중요한 사례의 품질을 건드리지 않으면서 추론 비용을 절반으로 줄이는 방법입니다.

분류당 0.0001달러의 비용이 드는 라우팅 SLM (routing SLM)을 사용하면, 호출당 0.01달러가 드는 프런티어 LLM (frontier LLM) 트래픽의 60~70%를 제거할 수 있습니다. 월간 작업량이 200만 건일 경우, 이는 월간 추론 비용이 2만 달러에서 7천 달러로 차이 나는 결과로 이어집니다.

레이어 2: 컨텍스트(Context) — RAG가 미세 조정(Fine-Tuning)을 이기는 경우가 많음

대부분의 기업이 맞춤형 모델에 대해 오해하는 점은 다음과 같습니다. 바로 '맞춤형'이 '미세 조정 (fine-tuned)'을 의미한다고 가정하는 것입니다. 실제로 검색 증강 생성 (Retrieval-Augmented Generation, RAG)을 사용하면 재학습 비용을 전혀 들이지 않고도 개인화 이점의 80%를 얻을 수 있습니다. 만약 가격, 재고, 정책과 같이 데이터가 매주 변경된다면, 미세 조정은 끝이 없는 쳇바퀴와 같습니다. Pinecone 벡터 데이터베이스 (vector database)를 활용한 RAG를 사용하면 재학습이 아닌 재인덱싱 (re-indexing)을 통해 지식을 업데이트할 수 있습니다. 저는 어떤 팀이 제품 카탈로그 데이터를 기반으로 8주 동안 모델을 미세 조정했지만, 바로 다음 달에 그 데이터가 바뀌는 것을 본 적이 있습니다. 그렇게 하지 마십시오.

Andrew Ng는 그 근본적인 원칙을 직설적으로 표현했습니다. "올해는 AI 에이전트 워크플로 (AI agentic workflows)가 엄청난 AI 발전을 이끌 것이라고 생각합니다. 아마도 차세대 파운데이션 모델 (foundation models)보다 더 큰 동력이 될 수도 있습니다." — DeepLearning.AI의 설립자, Andrew Ng.
이 교훈은 컨텍스트 레이어에서도 유효합니다. 어떤 모델을 선택했느냐보다 모델을 어떻게 그라운딩 (grounding)하고 라우팅 (route)하느냐가 더 중요합니다.

톤(tone), 구조화된 출력 (structured output), 특정 도메인에 특화된 추론 패턴과 같이 _행동이나 형식 (behaviour or format)_을 변경해야 할 때는 미세 조정을 합니다. 반면 _지식 (knowledge)_을 변경해야 할 때는 RAG를 사용합니다. 대부분의 B2B 유스케이스는 미세 조정이라는 가면을 쓰고 있는 지식 문제입니다.

RAG pipeline showing vector database retrieval feeding grounded context into a small language model for B2B SaaS queries

맞춤형 SLM을 그라운딩하는 RAG 파이프라인 — 지식 집약적인 B2B 워크플로를 위해 프런티어 LLM을 미세 조정하는 것보다 종종 더 정확하며 유지 관리 비용도 훨씬 저렴합니다.

레이어 3: 모델 레이어 — 실제 SLM vs LLM 결정

이제 적절한 위치에서 핵심적인 질문을 던져보겠습니다. 총 6개의 레이어 중 하나입니다. 맞춤형 SLM(Small Language Model) — Microsoft Phi-3, Llama 3.x 8B, 또는 특정 도메인에 맞춰 미세 조정(fine-tuned)된 Mistral 7B를 생각해보세요 — 은 입력 분포를 제어할 수 있는 좁고(narrow), 대량이며(high-volume), 지연 시간(latency)에 민감한 작업에서 탁월한 성능을 발휘합니다. 반면, 기성(off-the-shelf) LLM은 전문성보다 폭넓은 지식이 중요한 개방형(open-ended), 소량(low-volume), 고위험(high-stakes) 추론 작업에서 탁월합니다. 이들은 서로 다른 작업에 쓰이는 진정으로 다른 도구입니다.

| 차원 | 맞춤형 SLM (자체 호스팅) | 기성 LLM (API) |
| :--- | :--- | : |
| 최적 용도 | 대량의 좁은 범위 작업 | 개방형 추론 |
| 월 200만 회 호출 시 비용 | $3K–8K (인프라) | $15K–40K (API) |
| 지연 시간 (Latency) | 50–300ms | 500ms–3s |
| 데이터 프라이버시 | 완전한 제어, 온프레미스 (on-prem) | 벤더(Vendor) 의존적 |
| 배포 시간 | 4–12주 | 수일 |
| 추론 깊이 | 좁고 작업 특화됨 | 넓고 최첨단(frontier-grade) 수준 |
| 유지 관리 부담 | 높음 (직접 관리) | 낮음 (벤더가 업데이트) |
| 컴플라이언스 적합성 | 우수 (감사 가능) | 벤더의 DPA(데이터 처리 합의) 필요 |

맞춤형 SLM은 더 저렴한 LLM이 아닙니다. 완전히 다른 도구입니다.

2026년의 가장 정교한 B2B 스택은 하나를 선택하지 않습니다. 이들은 '포트폴리오'를 운영합니다. 즉, 일반적인 70%의 경로에는 SLM을 사용하고, 그것이 필요한 나머지 30%에는 최첨단(frontier) LLM을 사용하며, 이를 실시간으로 결정하는 라우팅 레이어(routing layer)가 조정합니다. 이것이 실제로 프로덕션 단계에 도달하는 대부분의 멀티 에이전트 시스템 (multi-agent systems)의 배후에서 발견되는 패턴입니다.

레이어 4: 도구 및 액션(Tool & Action) — MCP가 모든 것을 바꾸는 지점

Anthropic이 2024년 말에 도입하여 현재 널리 채택된 Model Context Protocol (MCP)은 모델이 여러분의 도구 — CRM, 데이터베이스, 결제 시스템 등 — 에 연결되는 방식을 표준화합니다. MCP 이전에는 모든 모델-도구 연결이 맞춤형 글루 코드(glue code)로 작성되어야 했으며, 이 글루 코드는 제가 감사한 모든 스택에서 '조정 격차(Coordination Gap)'를 일으키는 가장 큰 원인이었습니다. MCP는 이러한 연결을 재사용 가능하고, 타입이 지정되었으며(typed), 발견 가능한(discoverable) 인터페이스로 전환합니다.

이것은 MCP가 모델 불가지론적(model-agnostic)이기 때문에 구축할 것인지 구매할 것인지에 대한 결정(build-vs-buy decision)에 있어 매우 중요합니다. 통합(integration) 구조를 다시 설계할 필요 없이, 동일한 도구 계층(tool layer) 뒤에서 SLM을 LLM으로 교체할 수 있습니다. 이러한 디커플링(decoupling, 분리) 덕분에 처음에는 워크플로우를 검증하기 위해 프런티어 LLM(frontier LLM)으로 시작한 다음, 트래픽을 파악한 후에는 재구축 없이도 트래픽이 많은 경로를 더 저렴한 SLM으로 마이그레이션(migrate)할 수 있습니다. Model Context Protocol에 대한 당사의 심층 분석에서는 프로덕션 설정(production configs)을 자세히 살펴봅니다.