Originally published at twarx.com - 해당 사이트에서 전체 인터랙티브 버전을 읽어보세요.

최종 업데이트: 2026년 7월 16일

AI 기술 (AI technology) 분야가 올해 Goldman Sachs가 46,000명의 직원에게 GS AI Assistant를 배포하고 자율형 뱅킹 에이전트(autonomous banking agents)를 시범 운영하기 시작하면서 변곡점에 도달했습니다. 주목할 점은 그들이 시장에서 가장 큰 모델을 구매하지 않았다는 것입니다. 그들은 소규모의 도메인 튜닝된 모델(domain-tuned models)이 물량의 80%를 처리하고, 프런티어 LLM (frontier LLM)이 나머지를 처리하는 계층형 스택(tiered stack)을 구축했습니다. 대부분의 금융 서비스 기업들은 그 결정의 잘못된 절반만을 모방하고 있으며, 이 실수는 비용이 많이 듭니다.

대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다. '맞춤형 소규모 언어 모델 (custom Small Language Model, SLM)인가, 아니면 기성 LLM (off-the-shelf LLM)인가?'라는 질문은 OpenAI의 GPT-4o 가격 책정, Anthropic의 Claude 엔터프라이즈 티어, 그리고 이제는 몇 천 달러면 미세 조정(fine-tune)이 가능한 Llama 및 Mistral과 같은 오픈 웨이트 모델 (open-weight models)에 의해 주도되는, 은행 및 핀테크 이사회의 지배적인 질문이자 시급한 과제입니다. 이 글의 끝에 도달할 때쯤 여러분은 리스크 위원회(risk committee)에 가져갈 수 있는 의사결정 프레임워크, 실제 비용 계산법, 그리고 참조 아키텍처 (reference architecture)를 갖게 될 것입니다.

맞춤형 SLM이 대량의 분류 작업을 처리하고 프런티어 LLM이 복잡한 추론을 처리하는 계층적 배포 — 규제 대상 금융(regulated finance)에서의 AI 조정 격차(The AI Coordination Gap) 이면에 있는 아키텍처 패턴입니다.

개요: 왜 SLM vs LLM 질문이 잘못된 시작점인가

대부분의 금융 서비스 조직이 가진 본능은 이를 이분법적인 조달 결정으로 취급하는 것입니다. 즉, GPT-4o나 Claude와 같은 호스팅된 프론티어 모델 (Frontier Model)의 라이선스를 구매할 것인지, 아니면 자체 데이터로 미세 조정 (Fine-tuning)된 맞춤형 소형 언어 모델 (SLM)을 구축할 것인지의 문제입니다. 그런 방식으로 접근한다면 거의 확실히 잘못된 선택을 하게 될 것입니다. 왜냐하면 모든 AI 기술 스택의 실제 비용, 리스크, 성능 동인은 모델 자체가 아니라 모델 '사이'의 계층에 존재하기 때문입니다.

SLM은 대략 1B~15B 파라미터 (Parameter) 범위의 언어 모델을 의미합니다. Microsoft의 Phi-3, Mistral 7B, Llama 3.1 8B, 또는 Gemma 2를 생각하면 됩니다. 이 모델들은 단일 GPU 또는 CPU에서도 실행될 수 있을 만큼 충분히 작고, 도메인 데이터로 미세 조정하기에 충분히 저렴하며, 자체 VPC 내에 배포할 수 있을 만큼 충분히 프라이빗 (Private)합니다. 반면, 기성 LLM은 API를 통해 접근하는 호스팅된 프론티어 모델입니다. OpenAI의 GPT-4o, Anthropic의 Claude 3.5, 또는 Google의 Gemini가 이에 해당하며, 가장 높은 토큰당 비용과 가장 낮은 제어권을 가지는 대신 가장 깊은 추론 (Reasoning) 능력을 제공합니다.

왜 지금일까요? 2025년에 경제적 논리가 뒤집혔기 때문입니다. 은행의 문서 코퍼스 (Corpus)를 사용하여 오픈 웨이트 (Open-weight) 8B 모델을 미세 조정하는 비용이 10,000달러 미만으로 떨어졌습니다. 자체 호스팅된 SLM의 추론 (Inference) 비용은 프론티어 API의 1,000 토큰당 2~5센트와 비교했을 때 이제 1센트의 아주 작은 부분에 불과합니다. 또한 SEC부터 유럽 은행 감독청 (European Banking Authority)에 이르기까지 규제 기관들은 모델 설명 가능성 (Explainability) 및 데이터 레지던시 (Data Residency)에 관한 명시적인 지침을 발행하기 시작했으며, 이는 호스팅 전용 전략으로는 충족하기 어려운 부분입니다. 연방준비제도 (Federal Reserve)와 통화감독청 (Office of the Comptroller of the Currency) 모두 모델 리스크 관리 (Model-risk-management) 기대치(SR 11-7 계보)가 이제 생성형 시스템까지 확장된다는 신호를 보냈습니다.

여기 직관에 반하는 진실이 있습니다. 금융 분야에서 AI 기술로 승리하고 있는 기업들은 '올바른' 모델을 선택한 기업들이 아닙니다. 그들은 모델, 시스템, 그리고 인간 사이의 인계(handoff) 문제를 해결한 기업들입니다. JPMorgan의 컴플라이언스(compliance) 워크플로우는 단 하나의 모델을 사용하지 않습니다. 분류용 SLM(Small Language Model), 검색 레이어(retrieval layer), 추론용 LLM(Large Language Model), 그리고 인간 참여형 게이트(human-in-the-loop gate)를 사용합니다. 그리고 가치 혹은 재앙은 이들이 어떻게 서로를 인계하느냐에 달려 있습니다.

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차(AI Coordination Gap)란 단일 모델 내부가 아니라, 모델, 데이터 시스템, 그리고 인간 검토자 사이의 인계 과정에서 발생하는 신뢰성, 비용 효율성 및 컴플라이언스(compliance)의 측정 가능한 손실을 의미합니다. 이는 개별적으로는 정확한 컴포넌트들의 스택(stack)이 왜 신뢰할 수 없는 시스템을 만들어내는지에 대한 이유입니다.

이 글은 그 격차를 매핑합니다. 우리는 의사결정 과정을 별도의 레이어(layer)를 가진 명명된 프레임워크로 분해하고, 실제 금융 서비스 배포 환경에서 각 레이어가 어떻게 작동하는지 보여주며, ROI(투자 대비 수익)를 정량화하고, 참조 아키텍처(reference architecture)를 살펴볼 것입니다. 이 글을 다 읽을 때쯤이면, 여러분은 단순히 모델을 선택하는 것이 아니라 스택을 설계할 수 있게 될 것입니다. 이것이 어디에 위치하는지에 대한 더 넓은 맥락은 당사의 기업용 AI (enterprise AI) 배포 패턴 개요를 참조하십시오.

금융 서비스에서 돈을 잃는 이유는 3%의 확률로 틀리는 모델 때문이 아닙니다. 아무도 설계하지 않은 인계 과정 때문에 돈을 잃게 됩니다. 97% 정확도의 분류기(classifier)가 97% 정확도의 추출기(extractor)로 데이터를 넘길 때, 여러분의 엔드 투 엔드(end-to-end) 신뢰성은 조용히 83%로 떨어집니다.

$97B
2027년까지 금융 서비스 기업들의 예상 연간 AI 지출액
[IMF Global Financial Stability Report, 2024](https://www.imf.org/en/Publications)
...

커스텀 SLM이란 무엇이며, 언제 프런티어 LLM(Frontier LLM)을 이기는가?

커스텀 SLM은 더 약한 LLM이 아닙니다. 그것은 특화된 (specialized) 모델입니다. 귀사의 10년 치 KYC(Know Your Customer, 고객 알기 제도) 문서, 대출 메모, 컴플라이언스(compliance, 준법 감시) 신고 서류를 바탕으로 Llama 3.1 8B를 미세 조정(fine-tune)하면, 범용 프런티어 모델(frontier model)이 기본적으로 보유하지 못한 고밀도의 도메인 지식(domain knowledge)을 개발하게 됩니다. Microsoft의 Phi-3 연구는 선별된 데이터로 학습된 3.8B 파라미터 모델이 특정 벤치마크(benchmark)에서 자기보다 10배 더 큰 모델들과 대등한 성능을 보였음을 입증했습니다.

금융 서비스의 경우, SLM의 이점은 추론당 비용(cost per inference), 지연 시간(latency), 데이터 거주성(data residency), 그리고 감사 가능성(auditability)이라는 네 가지 축을 통해 복리로 작용합니다. 거래 분류(transaction-classification) 질의에 응답하는 셀프 호스팅(self-hosted) 8B 모델은 1센트의 아주 적은 비용이 들며, 귀사의 VPC(Virtual Private Cloud) 내부에서 200ms 미만으로 응답합니다. 이와 동일한 GPT-4o 호출은 20~60배 더 많은 비용이 들고, 네트워크 지연 시간을 추가하며, 귀사의 데이터를 제3자에게 전송합니다. 이는 많은 규제 대상 워크로드(regulated workloads)에서 허용될 수 없는 사항입니다.

월 5,000만 건의 요청에 대해 문서 분류를 처리하는 미세 조정된 8B SLM은 컴퓨팅 비용이 4,000달러 미만일 수 있습니다. GPT-4o로 동일한 볼륨을 처리하면 120,000달러를 초과할 것입니다. SLM은 단순히 '충분히 좋은' 수준이 아닙니다. 분류 작업에 있어서는 종종 더 낫습니다. 왜냐하면 외부 세계의 정보에 의해 주의가 분산되지 않기 때문입니다.

하지만 SLM은 프런티어 LLM이 빛을 발하는 지점, 즉 모호한 입력값에 대한 새롭고 다단계적인 추론(multi-step reasoning)에서는 실패합니다. 8B 모델에게 복잡한 파생상품 구조화 질문이나 이전에 본 적 없는 특이한 사기 패턴에 대해 추론하도록 요청하면, 모델은 환각(confabulate)을 일으킬 것입니다. 이것이 정답이 거의 항상 'SLM이냐 LLM이냐'가 아니라, '어느 것이 무엇을 처리할지 결정하는 라우팅 레이어(routing layer)를 갖춘 SLM 및 LLM'인 이유입니다. 복잡한 인프라 구축 과정을 생략하고 싶다면, 미리 구축된 계층형 라우팅 청사진을 위해 저희의 AI 에이전트 라이브러리를 탐색해 보세요.

| 미세 조정 (Fine-tune) 비용 | $2K–$10K$$$ 또는 사용 불가 | |
| 감사 가능성 (Auditability) | 가중치(Weights), 로그를 직접 소유 | 벤더(Vendor)에 의존적 |
| 최적 용도 | 분류 (Classification), 추출 (Extraction), 라우팅 (Routing) | 복잡한 추론 (Complex reasoning), 예외 사례 (Edge cases) |

요청량이 많아질수록, 자체 호스팅되는 SLM과 프런티어(Frontier) LLM API 사이의 비용 곡선은 극적으로 갈라집니다. 이는 금융 서비스 분야에서 AI 총소유비용 (TCO)을 결정하는 가장 큰 요인입니다.

AI 조정 격차 (AI Coordination Gap) 프레임워크의 5가지 계층

모델을 보는 것을 멈추십시오. 조정 표면 (Coordination surface)을 보기 시작하십시오. 모든 실제 금융 서비스 AI 기술 시스템은 5개의 계층으로 구성되며, 전체 시스템의 신뢰성, 비용 및 규정 준수 여부는 이 계층들이 서로 얼마나 깔끔하게 인수인계(Hand off)를 수행하느냐에 따라 결정됩니다. 이것이 바로 배포의 성패가 갈리는 지점입니다.

명명된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차는 멀티 모델 파이프라인 내의 구성 요소들 사이에서 발생하는 시스템적 신뢰성 손실을 의미합니다. 이는 SLM 대 LLM의 문제를 재정의합니다. 즉, 여러분은 단순히 모델을 선택하는 것이 아니라, 모델, 검색 (Retrieval), 그리고 인간이 연결되는 이음새 (Seams)를 설계하는 것입니다.

계층 1: 라우팅 계층 (The Routing Layer)

라우팅 계층은 어떤 모델이 각 요청을 처리할지 결정합니다. 저렴한 SLM 분류기 (Classifier)가 들어오는 쿼리를 읽고 — '이것이 일상적인 거래 분류인가, 아니면 새로운 컴플라이언스 판단인가?' — 그에 따라 라우팅합니다. 여기서 실수를 하면 사소한 작업에 프런티어 모델 비용을 낭비하거나, 높은 이해도가 필요한 추론 작업을 환각 (Hallucination)을 일으킬 모델로 보내게 됩니다.

실제로는, 파이프라인의 가장자리(edge)에서 실행되는 소규모 미세 조정(fine-tuned) 모델(종종 SLM 자체이거나 전용 1–3B 분류기)이 이 역할을 수행합니다. 여기서 지연 시간(Latency)은 매우 중요한데, 모든 요청의 앞단에 위치하기 때문입니다. LangChain 라우터(router)나 LangGraph 상태 머신(state machine)과 같은 도구는 라우팅을 명시적이고 감사 가능(auditable)하게 만들어 줍니다. 이는 규제 기관이 "왜 이 요청이 자율 에이전트(autonomous agent)로 전달되었습니까?"라고 물을 때 매우 결정적인 요소가 됩니다.

Layer 2: 검색 계층 (Retrieval Layer, RAG)

검색 증강 생성 (Retrieval-Augmented Generation, RAG)은 모델을 귀사의 실제 데이터에 기반하도록 만듭니다. 모델의 고정된 학습 지식에 의존하는 대신, 검색 계층은 Pinecone과 같은 벡터 데이터베이스(vector database)에서 규제 신고서, 계좌 내역, 정책 문서와 같은 관련 문서를 가져와 프롬프트(prompt)에 주입합니다. 이는 금융 분야에서 환각 (Hallucination)을 줄이기 위한 가장 중요한 계층입니다.

여기서 발생하는 조정의 격차(coordination gap)는 매우 치명적입니다. 훌륭한 모델에 훌륭한 검색 시스템을 연결하더라도, 청킹 (chunking) 전략이 잘못되었거나, 임베딩 (embeddings)이 오래되었거나, 검색된 컨텍스트 (context)가 서로 모순된다면 여전히 실패합니다. 저는 팀들이 실제로는 검색 오류(잘못된 청킹, 일치하지 않는 임베딩 모델, 몇 주 동안 갱신되지 않은 인덱스 등)임에도 불구하고 '모델 오류'를 디버깅하는 데 수개월을 허비하는 것을 보았습니다. 은행 업무에서 발생하는 '모델이 틀렸다'는 사고의 대부분은 사실 '검색 계층이 잘못된 컨텍스트를 제공했다'는 것입니다. RAG 파이프라인 (RAG pipelines)에 대한 당사의 심층 가이드에서는 이러한 문제를 방지하기 위한 청킹 및 임베딩 갱신 패턴을 다룹니다.

Layer 3: 추론 계층 (Reasoning Layer)

이곳이 바로 SLM 대 LLM의 결정이 전역적으로가 아닌, 작업별로 실제로 내려지는 지점입니다. 일상적인 추출 및 분류 작업은 SLM에 머무릅니다. 복잡한 다단계 추론 (multi-step reasoning)은 프런티어 LLM으로 에스컬레이션됩니다. 추론 계층은 프런티어 모델 예산을 정말로 필요한 15~20%의 작업에 의도적으로 사용하는 곳입니다.

Layer 4: 오케스트레이션 계층 (Orchestration Layer)

오케스트레이션 (Orchestration)은 시퀀싱 로직 (sequencing logic)입니다. 즉, '먼저 분류하고, 그 다음 검색하고, 그 다음 추론하고, 그 다음 검증한 뒤, 신뢰도가 낮으면 사람에게 전달하라'고 명령하는 코드입니다. 이곳이 바로 멀티 에이전트 시스템 (multi-agent systems)이 존재하는 곳입니다. LangGraph, AutoGen, 그리고 CrewAI와 같은 프레임워크는 이러한 흐름을 명시적인 상태 (state), 재시도 (retries), 그리고 폴백 (fallbacks)을 가진 그래프 (graphs)로 정의합니다.

각 단계의 신뢰도가 97%인 6단계 금융 파이프라인의 경우, 엔드 투 엔드 (end-to-end) 신뢰도는 83%에 불과합니다 (0.97^6). 대부분의 은행은 이를 제품을 출시한 후에야 깨닫게 됩니다. 오케스트레이션 계층은 더 나은 모델을 사용하는 것이 아니라, 검증 게이트 (validation gates)를 통해 그 신뢰도를 다시 확보하는 곳입니다.

Layer 5: 휴먼 인 더 루프 게이트 (The Human-in-the-Loop Gate)

규제가 엄격한 금융 분야에서는 리스크 임계값 (risk threshold)을 초과하는 어떠한 자율적 의사결정도 인간의 게이트 (human gate) 없이는 실행될 수 없습니다. 이 계층은 신뢰도 임계값 (confidence thresholds), 에스컬레이션 경로 (escalation paths), 그리고 감사 로그 (audit logging)를 정의합니다. 이것은 단순한 폴백 (fallback)이 아니라 준수 사항 (compliance requirement)입니다. 설계상의 핵심 질문은 게이트가 '어디에' 위치하며 '무엇이' 이를 트리거하느냐 하는 것입니다. 왜냐하면 모든 요청마다 작동하는 게이트는 투자 대비 수익률 (ROI)을 파괴하고, 전혀 작동하지 않는 게이트는 은행을 파괴하기 때문입니다.