대부분의 은행 AI 프로젝트가 실패하는 이유는 모델의 품질과는 전혀 무관합니다. 리더십 팀이 파라미터 수와 벤치마크 점수를 비교하며 수개월을 허비하는 동안, 조용한 위협이 그들이 구축한 모든 것을 갉아먹고 있습니다. 그들은 모델 크기를 승리의 조건으로 간주합니다. 하지만 그렇지 않습니다. 금융업을 지배하는 규제가 엄격한 다단계 워크플로우에서는 정확도가 곱절로 늘어나지 않습니다. 오히려 감쇄합니다. 단일 단계의 점수에만 집착한다면, 시스템 전체의 실패라는 암초에 부딪히게 될 것입니다.
진짜 문제는 모델 크기가 아닙니다
리스크 관리자들을 밤잠 설치게 만드는 산술적 계산이 여기 있습니다. 데이터 추출, 검증, 리스크 점수 산정, 컴플라이언스 체크, 문서 생성, 최종 승인이라는 6개의 뚜렷한 단계로 구성된 파이프라인을 상상해 보십시오. 각 단계가 개별적으로는 97%의 정확도를 기록하며 훌륭하게 작동한다고 가정해 봅시다. 본능적으로는 축하해야 할 일처럼 느껴집니다. 하지만 확률은 직관을 따르지 않습니다. 이 단계들을 하나로 연결하면, 엔드 투 엔드(end-to-end) 신뢰도는 약 83%로 급락합니다.
국소적 완벽함과 전역적 실패 사이의 이 간극이 바로 'AI 조정 격차(AI Coordination Gap)'입니다. 이는 에이전트, 소프트웨어 도구, 그리고 인간 검토자 사이의 업무 인수인계 과정에서 발생하는 마찰입니다. 규제 당국은 이미 바로 이 취약점을 주시하고 있습니다. 여러분의 엔지니어링 팀이 사후 분석(post-mortem)을 마치기도 전에 그들은 이를 찾아낼 것입니다.
2026년이 되면 논의의 흐름이 바뀔 것입니다. 질문은 더 이상 어떤 모델이 연구 리더보드 1위를 차지하느냐가 아닙니다. 예산 통제, 데이터 주권, 그리고 업데이트 제어에 관한 것입니다. 여러분은 자체 인프라 내에 가둘 수 있는 맞춤형 소형 언어 모델(SLM)을 선택할 것인지, 아니면 토큰 단위로 빌려 쓰는 기성 대규모 언어 모델(LLM)을 선택할 것인지 결정해야 합니다.
SLM vs LLM: 2026년에 실제로 변하는 것
GPT-4o, Claude와 같은 기성 프론티어 모델들은 개방형 추론과 소량의 분석 작업에서는 여전히 독보적입니다. 이들은 행간을 읽고 미묘한 차이를 다룹니다. 하지만 그 편리함에는 대가가 따릅니다. 여러분은 모델의 가중치(weights)를 소유하지 않습니다. 출시 일정 또한 통제할 수 없습니다. 벤더사가 주말 사이에 조용히 진행한 업데이트 하나로 인해, 여러분의 애플리케이션이 부채 상환 비율(DTI) 임계값을 해석하거나 의심스러운 거래를 탐지하는 방식이 바뀔 수 있으며, 여러분은 정확히 무엇이 변했는지에 대한 기록조차 없을 수 있습니다. 모든 결정에 감사 추적(audit trail)이 필요한 산업에서 이러한 불투명성은 막대한 비용을 초래합니다.
Llama나 Mistral과 같은 오픈 웨이트 기반의 맞춤형 SLM은 상황을 반전시킵니다. 이들은 모기지 PDF에서 필드 추출, KYC 문서 분류, 거래 메모 파싱과 같은 고강도의 대량 작업을 위해 특화되어 제작되었습니다. 직접 호스팅하기 때문에 특정 버전을 고정할 수 있고, 차분 테스트(differential testing)를 수행할 수 있으며, 3월에 작동하던 모델이 6월에도 동일하게 작동한다는 것을 감사인에게 증명할 수 있습니다. 또한 비용 면에서도 매우 효율적이어서, 클라우드 기반 모델보다 토큰당 비용이 약 10배에서 30배 정도 저렴합니다. 트레이드오프는 역량이 다소 좁다는 점입니다. SLM은 시장 트렌드에 대해 철학적인 논의를 하지는 않습니다. 하지만 기업의 기밀 데이터를 방화벽 외부로 유출하지 않고도 시간당 만 건의 송장을 처리할 수 있습니다.
이종 라우팅(Heterogeneous Routing): 80/20 법칙
앞서 나가는 은행들은 이를 '이것 아니면 저것' 식의 선택지로 보지 않습니다. 그들의 아키텍처는 이종(heterogeneous) 구조입니다. 저렴하고 미세 조정된 SLM이 문서 추출, 엔티티 태깅, 일상적인 자격 심사와 같이 예측 가능하고 구조화된 작업의 1차 처리를 담당하며 전체 물량의 약 80%를 처리합니다. 유추적 추론이나 복잡한 정책 해석이 필요한 나머지 20%의 예외 사례(edge cases)는 프론티어 LLM으로 에스컬레이션됩니다.
이는 이론적인 이야기가 아닙니다. 예를 들어, 모기지 서비스 업체는 SLM을 통해 급여 명세서에서 소득 수치를 추출하게 한 뒤, 모호한 신청서만 더 큰 모델로 전달하여 변화하는 연방 가이드라인에 따라 여러 고용 형태를 교차 참조하게 할 수 있습니다. 이렇게 하면 역량은 유지하면서 클라우드 비용을 절감할 수 있습니다.
격차를 줄이기 위한 5계층 프레임워크
조정 격차를 줄이기 위해서는 단순한 스마트 라우팅 그 이상이 필요합니다. 명확한 스택이 필요합니다. 다음은 팀이 지금 바로 도입할 수 있는 5계층 프레임워크입니다.
모델 선택. 추론(inference)을 응급 분류 간호사(triage nurse)처럼 다루십시오. 작업의 물량과 민감도에 따라 경로를 지정하십시오. 빈도가 높고 리스크가 낮은 작업은 SLM으로 보냅니다. 판단, 모호성 또는 고객 불만 해결이 포함된 케이스는 LLM으로 보냅니다. 라우팅 규칙은 프롬프트가 아닌 코드로 작성하십시오.
그라운딩. 고객과 관련된 모든 답변은 반드시 출처 문서로 연결되어야 합니다. 검색 증강 생성(RAG)을 사용하여 실제 정책 매뉴얼, 이율표, 규제 공지 사항에 출력 내용을 고정하십시오. 현재 이자율이나 수수료 체계에 대해 모델의 파라미터 메모리(parametric memory)를 절대 신뢰하지 마십시오. 메모리는 변할 수 있지만, 버전 번호가 있는 PDF는 그렇지 않습니다.
오케스트레이션. 경로가 가시적인 워크플로우를 구축하십시오. LangGraph와 같은 도구를 사용하면 명시적이고 감사 가능한 상태 머신(state machine)을 정의할 수 있습니다. 결정은 추출(extract), 검증(verify), 결정(decision), 로그 기록(log)과 같이 정의된 단계를 거쳐야 합니다. 에이전트가 개방형 대화 루프 내에서 '채팅'만으로 결론에 도달하게 두지 마십시오. 플로우차트를 그릴 수 없다면, 규제 기관에 설명할 수도 없습니다.
도구 액세스. 에이전트는 핵심 뱅킹 시스템을 호출해야 하지만, 모든 통합은 잠재적인 실패 지점이 될 수 있습니다. Model Context Protocol을 사용하여 에이전트가 원장, CRM 기록 및 컴플라이언스 데이터베이스에 인증하고 쿼리하는 방식을 표준화하십시오. 통일된 인터페이스는 조용한 장애(silent breakage)가 발생할 수 있는 영역을 줄여줍니다.
검증. 인간의 판단을 위한 별도의 경로를 확보하십시오. 고위험 결정—대규모 송금, 신용 한도 초과 승인, 의심 거래 보고(SAR) 제출 등—은 인간 검토자나 격리된 모델에서 실행되는 두 번째 검증 에이전트에게 전달하십시오. 가장자리(edge)에서의 중복성은 중심부를 보호합니다.
올바른 것을 측정하십시오
단계별 정확도만으로 팀에게 보상하는 것을 중단하십시오. 각 모듈이 테스트 세트에서 99%의 정확도를 기록하더라도, 단계들이 상호작용할 때 실제 고객 5명 중 1명에게는 실패할 수 있는 파이프라인이 있습니다. 엔드 투 엔드(end-to-end) 신뢰성을 측정하기 시작하십시오. 합성 실패 사례(synthetic failure cases)를 주입하십시오. 공격자가 이음새를 테스트하듯 핸드오프(handoff)를 테스트하십시오.
2026년에 AI로 실제로 승리하는 은행은 가장 큰 모델을 빌려 쓰는 곳이 아닙니다. 가장 명확한 시스템을 엮어내는 곳입니다. 그들은 감사 가능한 작은 모델이 설명할 수 없는 거대 모델보다 낫다는 것과,