원문은 twarx.com에서 처음 게시되었습니다 - 전체 인터랙티브 버전은 그곳에서 읽어보세요.

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

금융 서비스의 대부분의 AI 기술 워크플로우는 완전히 잘못된 문제를 해결하고 있습니다.

맞춤형 소형 언어 모델 (SLM, Small Language Models)과 GPT-4o 또는 Claude 3.7과 같은 기성 LLM (Large Language Models) 사이의 논쟁이 현재 규제 대상 금융권의 이사회에서 지배적인 화두가 되고 있습니다. 이는 McKinsey가 최근 발표한 '은행업에서의 효과적인 AI 전략의 5가지 특징'에 의해 더욱 가속화되었습니다. 하지만 가장 영리한 팀들은 AI 기술 결정이 실제로는 모델에 관한 것이 아니라는 점을 깨달았습니다. 이것은 근본적으로 모델 선택의 문제가 아니라 조정 (Coordination)의 문제입니다. 사용되는 도구들은 실재합니다: Anthropic 기반의 미세 조정된 (fine-tuned) SLM 및 오픈 웨이트 (open-weight) Llama 파생 모델, 벡터 데이터베이스 상의 RAG (Retrieval-Augmented Generation) 파이프라인, 그리고 LangGraph 오케스트레이션 (orchestration) 레이어입니다.

이 글을 마칠 때쯤 여러분은 무엇을 배포해야 하는지, 비용은 얼마인지, 그리고 어디에서 문제가 발생하는지를 정확히 알려주는 의사결정 프레임워크인 'AI 조정 격차 (AI Coordination Gap)'를 갖게 될 것입니다.

미세 조정된 SLM과 기성 LLM이 각각 어디에 위치하는지를 보여주는 실제 금융 서비스 스택 — 그리고 왜 이들 사이의 핸드오프 (handoff)가 실제 리스크 표면 (risk surface)인지 보여줍니다. 이것이 AI 조정 격차의 핵심입니다.

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

은행업의 고위 운영진들이 이제야 비로소 내재화하고 있는 직관에 반하는 진실은 다음과 같습니다: 모델은 병목 현상 (bottleneck)이 아닙니다. 조정 (Coordination)이 병목입니다.

예를 들어, Tier-1 은행이 거래 분쟁 분류 (transaction dispute triage) 작업을 위해 미세 조정된 (fine-tuned) 7B 파라미터 SLM을 GPT-4o와 벤치마킹할 때, 범위가 잘 정의된 작업에서는 정확도 차이 (accuracy delta)가 종종 4% 포인트 미만으로 나타납니다. 하지만 총 소유 비용 (total cost of ownership), 지연 시간 프로필 (latency profile), 데이터 거주성 태세 (data-residency posture), 그리고 결정적으로 — 각 모델이 파이프라인 내의 다른 6개 시스템과 조정 (coordinate)하는 방식은 한 자릿수(order of magnitude) 차이가 납니다. 바로 이 지점에서 프로젝트가 실패합니다.

각 단계의 신뢰도가 97%인 6단계 파이프라인은 엔드 투 엔드 (end-to-end) 기준으로 단 83%의 신뢰도만을 가집니다. 대부분의 금융 기관은 파일럿을 출시하고, 리스크 위원회에 녹색 지표 (green metrics)를 제시한 후, 운영 시스템이 인계 (handoff) 과정에서 조용히 오류를 유출하는 것을 목격한 뒤에야 이 사실을 깨닫습니다. 개별 모델은 괜찮았습니다. 모델 간의 조정 (coordination)이 설계되지 않았던 것입니다. 이러한 복합 오류 (compounding-error) 역학은 신뢰성 공학 (reliability engineering) 분야에 잘 기록되어 있습니다. arXiv의 광범위한 분석과 O'Reilly의 프로덕션 AI 문헌에서의 실무자 논의를 참조하십시오.

새롭게 정의된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차 (AI Coordination Gap)란 단일 모델 내부가 아니라, AI 모델, 검색 시스템 (retrieval systems), 그리고 다운스트림 비즈니스 시스템 간의 인계 (handoff) 과정에서 발생하는 복합적인 신뢰성 및 컴플라이언스 (compliance) 손실을 의미합니다. 이는 왜 규제 대상인 운영 환경에서 '더 나은 모델'을 선택하는 결정이 거의 실질적인 변화를 만들어내지 못하는지를 설명합니다.

McKinsey가 제시한 다섯 가지 특징 — 명확한 전략, 재구상된 기술 백본 (technology backbone), 인재, 운영 모델, 그리고 리스크 통제 — 은 모두 본질적으로 조정 (coordination) 문제입니다. 이 중 그 어느 것도 더 큰 모델을 선택한다고 해서 해결되지 않습니다. 이를 이해하는 금융 서비스 리더들은 'GPT-4o를 쓸 것인가, 아니면 커스텀 SLM을 쓸 것인가?'라는 질문을 멈추고, '내 컴포넌트들 사이의 어디에서 신뢰성이 유출되는가, 그리고 어떤 모델이 각 접점 (seam)에서 그 유출을 최소화하는가?'라고 묻기 시작합니다.

이 글은 의사결정 과정을 6개 계층의 프레임워크 (framework)로 나눕니다. 각 계층에 대해 실제 운영 환경 (production)에서 어떤 일이 발생하는지, 비용은 얼마나 드는지, 그리고 어떤 배포 패턴 — 맞춤형 SLM (custom SLM), 기성 LLM (off-the-shelf LLM), 또는 하이브리드 (hybrid) — 이 승리하는지를 보여드릴 것입니다. 그런 다음 JPMorgan, Morgan Stanley, Klarna의 실제 명명된 배포 사례를 살펴보고, 에이전트형 AI (agentic AI), 멀티 에이전트 오케스트레이션 (multi-agent orchestration), RAG vs 미세 조정 (fine-tuning), LangGraph, MCP, 그리고 교훈을 얻어야 할 가장 큰 실패 사례들을 다루는 운영자 FAQ로 마무리하겠습니다.

83%
각 단계의 신뢰도가 97%인 6단계 파이프라인 (pipeline)의 엔드 투 엔드 (end-to-end) 신뢰도
[복합 오류 분석 (Compounding error analysis), arXiv 2025](https://arxiv.org/)
...

규제 대상인 금융 분야에서 승리하는 AI 팀은 최고의 모델을 가진 팀이 아닙니다. 그들은 아무도 설계하지 않은 핸드오프 (handoffs) 문제를 해결한 팀입니다.

맞춤형 SLM이란 무엇이며, 언제 기성 LLM을 이기는가?

소형 언어 모델 (SLM, Small Language Model)은 일반적으로 1B에서 13B 사이의 파라미터 (parameters)를 가진 언어 모델로, 단일 GPU 또는 온프레미스 (on-premise) CPU 추론 (inference)에서도 실행될 수 있을 만큼 범위가 좁으며, 귀하의 도메인 데이터 (domain data)로 미세 조정 (fine-tuned)된 모델입니다. 금융 서비스에서 그 도메인 데이터는 금과 같습니다. 수십 년간의 판결된 분쟁, KYC 결정, 신용 메모, 그리고 규제 관련 서신 등이 포함됩니다. 이는 귀하의 소유입니다. 귀하는 시간과 컴플라이언스 (compliance) 오버헤드를 통해 그 대가를 치렀습니다. SLM은 귀하가 실제로 그 데이터를 사용할 수 있게 해줍니다.

기성 LLM (off-the-shelf LLM) — GPT-4o, Claude 3.7 Sonnet, Gemini 2.5 — 은 API를 통해 접근하는 프런티어 범용 모델 (frontier general model)입니다. 새로운 상황에 대한 추론 (reasoning) 능력이 탁월합니다. 하지만 토큰 (token)당 비용이 비싸고, 데이터 거주성 (data-residency) 요구 사항을 맞추기 어려우며, 귀하가 제어할 수 없는 움직이는 목표 (moving target)이기도 합니다. 마지막 부분은 대부분의 팀이 인정하는 것보다 더 중요하며, 조용한 모델 업데이트가 새벽 2시에 그들의 평가 (evals)를 망가뜨리기 전까지는 간과되곤 합니다. 오픈 웨이트 (open-weight) 대안 — Meta의 Llama 제품군 및 Hugging Face에 기록된 유사한 출시 모델들 — 은 애초에 셀프 호스팅 (self-hosted) SLM을 실행 가능하게 만드는 핵심 요소입니다.

미세 조정(fine-tuned)된 7B SLM이 표준화된 분쟁 분류(dispute-triage) 물량의 90%를 처리하고, 기성(off-the-shelf) LLM이 나머지 10%의 예외 사례(edge cases)를 처리하도록 구성하면, 모든 요청을 GPT-4o로 라우팅하는 것과 비교했을 때 추론 비용(inference cost)을 통상 60-80% 절감하면서도 일반적인 사례에 대한 정확도는 오히려 향상시킵니다.

실제로 중요한 의사결정 변수들

벤치마크 리더보드는 잊으십시오. 규제 대상인 은행에서는 다음 다섯 가지 변수에 따라 배포 결정이 내려집니다:

• 작업 변동성 (Task variance): 변동성이 낮고 물량이 많은 작업(분쟁 분류, 명세서 분류, KYC 문서 추출)은 SLM에 유리합니다. 변동성이 높은 추론 작업(새로운 사기 시나리오, 복잡한 고객 자문)은 LLM에 유리합니다.

• 데이터 거주성 (Data residency): 워크로드가 VPC 또는 특정 리전을 벗어날 수 없는 경우, 직접 호스팅하는 오픈 웨이트(open-weight) SLM이 기본적으로 승리하는 경우가 많습니다. 이는 SLM이 더 똑똑해서가 아니라, 법무팀이 승인할 수 있는 유일한 옵션이기 때문입니다.

• 지연 시간 예산 (Latency budget): 200ms 미만의 대화형 경험을 구현하려면, 프런티어 API(frontier API)로 네트워크 왕복을 하는 것보다 로컬에 배치된(co-located) SLM이 유리합니다.

• 감사 가능성 (Auditability): 고정된(frozen) SLM 가중치는 모델 리스크 관리(MRM) 승인을 위한 재현 가능하고 버전이 관리되는 모델을 제공합니다. 조용히 업데이트되는 벤더 LLM은 그렇지 못합니다. 저는 정확히 이 문제 때문에 MRM 검토가 몇 달 동안 지연되는 것을 목격했습니다.

• 물량 경제성 (Volume economics): 하루 약 100만 토큰 미만인 경우에는 API LLM을 사용하는 것이 총비용 측면에서 더 저렴합니다. 이 임계값을 넘어서면 셀프 호스팅(self-hosted) SLM이 본격적인 비용 절감 효과를 내기 시작합니다.

차원 (Dimension)	맞춤형 미세 조정 SLM (Custom Fine-Tuned SLM)	기성 LLM (API) (Off-the-Shelf LLM)	하이브리드 (라우터) (Hybrid (Router))
규모에 따른 작업당 비용	가장 낮음 (10-30배 저렴)	가장 높음	낮음
새로운 추론에 대한 정확도	중간	가장 높음	가장 높음
데이터 거주성 제어	완전함 (셀프 호스팅)	제한적	구성 가능
MRM / 감사 재현성	강력함 (고정된 가중치)	약함 (벤더 업데이트)	중간
첫 배포까지의 시간	8-16주	1-3주	10-18주
지연 시간 (대화형)	<200ms (로컬 배치)	300-900ms	가변적
지속적인 운영 부담	높음	낮음	높음

(https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F6xmk7wkl4114km4ytg6g.jpg)

배포 결정은 이분법적이지 않습니다. 성공적인 대부분의 금융 서비스 아키텍처는 변동성이 낮은 볼륨은 SLM으로 보내고, 예외적인 케이스(edge cases)는 프론티어 LLM(frontier LLM)으로 보내는 하이브리드 라우터(hybrid router) 형태를 취하며, 설계 단계부터 AI 조정 격차(AI Coordination Gap)를 해소합니다.

AI 조정 격차 프레임워크의 6가지 계층

AI 조정 격차(AI Coordination Gap) 프레임워크는 모든 금융 서비스 AI 시스템을 6가지 조정 계층으로 분해합니다. 모델의 선택 — SLM 대 LLM — 은 그중 하나일 뿐입니다. 나머지 5개 계층이 실제로 프로젝트의 성패를 결정짓는 핵심 요소입니다.

고안된 프레임워크

AI 조정 격차 (The AI Coordination Gap)

AI 조정 격차는 신뢰성을 구성 요소 자체가 아닌, 구성 요소 사이의 이음새(seams)의 속성으로 다룹니다. 은행의 경우, 97% 정확도의 추출(extraction) 모델이 96% 정확도의 분류기(classifier)로 전달되고, 이것이 다시 98% 정확도의 정책 점검(policy check) 모델로 전달될 때, 이 결합된 결과값이 컴플라이언스(compliance) 감사를 조용히 통과하지 못하는 지점이 바로 격차입니다.

계층 1 — 검색 계층 (Retrieval Layer, RAG)

모델이 추론하기 전에 적절한 컨텍스트(context)가 필요합니다. 금융 분야에서 이는 고객의 실제 거래 내역, 규정의 최신 버전, 또는 제품의 정확한 약관을 검색하는 것을 의미합니다. 이것이 검색 증강 생성 (RAG, Retrieval-Augmented Generation)이며, 일반적으로 Pinecone이나 오픈 소스 대안과 같은 벡터 데이터베이스(vector database)를 기반으로 구축됩니다.

여기서 발생하는 조정 실패는 미묘하며, 저는 이것이 팀들을 반복적으로 실패하게 만드는 것을 목격해 왔습니다. 바로 '그럴듯하지만 오래된(plausible but stale)' 문서를 반환하는 검색입니다. 지난 분기의 수수료 일정에 근거한 모델은 컴플라이언스를 준수하는 것처럼 들리지만 실제로는 틀린 답을 자신 있게 내놓을 것입니다. 규제 환경에서 최신성 필터링(recency filtering)과 소스 버전 메타데이터(source-version metadata)는 선택 사항이 아닙니다. 대부분의 벡터 데이터베이스 문서는 이 점을 충분히 강조하지 않습니다. 저희의 전체 RAG 설계 가이드에서는 버전 메타데이터 패턴을 심도 있게 다룹니다.

Layer 2 — 추론 계층 (Reasoning Layer) (SLM 또는 LLM)

이 계층은 모든 사람이 집착하는 부분이지만, 대개 가장 오류가 적은 부분입니다. 검색된 컨텍스트(context)가 주어졌을 때, 추론(reasoning)이 미세 조정된(fine-tuned) SLM에서 일어날까요, 아니면 프런티어 LLM(frontier LLM)에서 일어날까요? 범위가 잘 정해진 대량의 작업의 경우, 5,000~50,000개의 레이블이 지정된 예시(labeled examples)로 미세 조정된 SLM은 비용을 훨씬 절감하면서도 일반적으로 LLM과 몇 포인트 차이 내로 성능이 일치합니다. 이러한 요소들이 더 넓은 멀티 에이전트 시스템 (multi-agent systems)에 어떻게 부합하는지 자세히 알아보세요.

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

오케스트레이션(Orchestration)은 어떤 모델을 언제 실행할지, 단계 간에 상태(state)가 어떻게 전달될지, 그리고 실패 시 어떤 일이 발생할지를 결정합니다. LangGraph (프로덕션 준비 완료, 그래프 기반 상태 머신), AutoGen (Microsoft, 대화 우선 방식), 그리고 CrewAI (역할 기반, 프로토타입 제작은 빠르지만 상당한 강화 작업 없이는 규제 대상 워크플로우에서 신뢰하기 어려움)가 주요 프레임워크입니다. 이 계층에는 대량의 요청은 SLM으로, 예외 케이스(edge cases)는 LLM으로 보내는 라우터(router)가 존재합니다.

Layer 4 — 도구/액션 계층 (Tool/Action Layer) (MCP)

실시간 잔액 조회, 분쟁 제기, 거래 플래그 지정과 같이 행동(act)할 수 없다면 추론은 무용지물입니다. Anthropic이 도입한 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 모델과 기업 시스템 사이의 표준 인터페이스로 빠르게 자리 잡고 있습니다. 이는 취약하고 맞춤화된(bespoke) 통합 방식을 관리 가능하고 발견 가능한(discoverable) 도구 계층으로 전환합니다. 이것이 오케스트레이션 (orchestration) 패턴과 어떻게 연결되는지 살펴보세요.

Layer 5 — 가드레일 및 컴플라이언스 계층 (Guardrail & Compliance Layer)

이 계층은 데모(demo)와 규제 대상 배포(regulated deployment)를 구분하는 계층입니다. 정책에 따라 출력을 검증하고, 개인정보(PII)를 삭제하며, 금지된 조언 여부를 확인하고, 감사 추적(audit trail)을 생성합니다. 고객에게 닿는 모든 모델 출력 뒤에는 반드시 결정론적 게이트(deterministic gate)가 있어야 합니다. 이 계층은 타협할 수 없는 필수 사항이며, 대부분의 벤더 파일럿(vendor pilots)이 데모 마감 기한을 맞추기 위해 조용히 편법을 쓰는 지점이기도 합니다. NIST AI Risk Management Framework와 같은 규제 지침은 점점 더 정확히 이러한 종류의 결정론적 제어를 요구하고 있습니다.

Layer 6 — 관측성 및 평가 계층 (The Observability & Evaluation Layer)

AI 조정 격차(AI Coordination Gap)를 볼 수 없다면 관리할 수 없습니다. 이 계층은 이전 5개 계층 전체에 걸쳐 모든 요청을 추적하고, 각 접합부(per-seam)의 신뢰성을 측정하며, 평가 하네스(evaluation harness)에 데이터를 공급합니다. 이 계층이 없다면 운영 환경에서의 실패를 예측하는 정확한 지표를 알지 못한 채 눈을 감고 비행하는 것과 같습니다. 당사의 enterprise AI 관측성 가이드를 참조하세요.