FinTech 성공 사례: 3명의 인원으로 10,000건의 문의 처리 (IA 2026)

일일 10,000건의 문의에 50명의 콜센터 직원이 필요하지 않을 때

많은 FinTech 스타트업에서 고객 서비스 부서는 제품 자체보다 더 빠르게 인력을 확장합니다. 거래, 잔액 또는 신원 확인에 관한 반복적인 질문에 답변하기 위해 인간 상담원을 채용, 교육 및 유지하는 것은 소규모 팀을 침몰시키는 자원 구멍이 되는 것을 우리는 목격해 왔습니다. 여기서 우리가 분석하는 사례는 정확히 그 반대 방향으로 나아갑니다. 한 라틴 아메리카 FinTech 기업은 언어 모델 (LLM), 자동화된 워크플로우 (Automated flows), 그리고 실용적인 엔지니어링의 결합을 통한 AI 아키텍처 (Architecture) 덕분에 단 3명의 팀으로 하루 10,000건의 문의를 처리할 수 있었습니다.

이것은 서투른 봇(Bot)이 있는 콜센터가 아닙니다. 이는 소음과 실제 가치를 분리하는 도구들의 수직적 통합이며, 트레이드오프 (Tradeoffs)를 알고 있다면 어떤 기술 팀이라도 복제할 수 있는 방식입니다.

아키텍처: 3계층 어시스턴트

이 시스템은 단일 구조 (Monolith)나 모든 것을 듣고 있는 단 하나의 LLM이 아닙니다. 세 단계로 나뉩니다:

경량 분류기 (Clasificador ligero) (임베딩 모델 (embeddings model) + 규칙): 각 문의를 약 15개의 카테고리(이체 상태, 생체 인증 확인, 결제 API 오류 등) 중 하나로 분류합니다. 저렴한 인스턴스에 호스팅된 all-MiniLM-L6-v2와 같은 작은 모델을 사용하여 100ms 미만으로 실행됩니다.
템플릿 프롬프트 (prompt templated)를 통한 자동 응답: 해결 방법이 알려진 카테고리(예: "제 이체가 언제 도착하나요?")의 경우, 고정된 프롬프트에 실시간 데이터(은행 코어 API)를 삽입하여 응답을 생성합니다. LLM(이 경우 GPT-4o-mini를 사용하지만, 지시 이행 능력이 좋은 모델이라면 무엇이든 가능)이 최종 응답을 포맷팅합니다.
에스컬레이션 전달 (Derivación escalada): 분류기의 신뢰도 임계값이 낮거나(<0.7), 문의가 중요한 카테고리(사기, 복잡한 환불 등)에 속하는 경우, 자동으로 생성된 컨텍스트 요약과 함께 세 명의 담당자에게 전달됩니다. 담당자는 사전 처리된 티켓을 확인하게 됩니다.

결과적으로 문의의 85%가 인간의 개입 없이 해결됩니다. 담당자들은 정말로 도움이 필요한 사례에만 시간을 할애합니다.

화이트페이퍼(whitepapers)에서 말해주지 않는 트레이드오프 (Tradeoffs)

구현 과정은 순탄치 않았습니다. 이 사례를 분석하며 발견한 실제 문제들은 다음과 같습니다:

새로운 카테고리에서의 모델 드리프트 (Model drift): 이 FinTech 기업이 신규 상품(소액 대출)을 출시했을 때, 분류기 (classifier)가 이를 인식하지 못해 정당한 문의를 사람에게 전달하기 시작했습니다. 해결책은 재학습 (retraining)이 아니라, 임시적인 휴리스틱 규칙 (heuristic rules)과 피드백 루프 (feedback loop)를 추가하는 것이었습니다. 즉, 사람이 새로운 티켓을 해결할 때마다 다음 미세 조정 (fine-tuning)을 위해 라벨링 (labeling)을 수행했습니다.
여러 API 호출이 필요한 응답의 지연 시간 (Latency): 생성 계층 (generation layer)이 세 개의 서로 다른 엔드포인트 (endpoints: 잔액, 거래 내역, 수취인 상태)를 조회해야 할 때 최대 4초가 소요되었습니다. 실시간 채팅에서는 이는 매우 긴 시간입니다. 해결책은 요청을 병렬화 (parallelize)하고 세션 캐시 (session cache)를 사용하는 것이었습니다.
대규모 모델의 추론 비용 (Inference cost): 분류에는 작은 모델을 사용했지만, 응답을 생성하는 LLM은 전체 문의당 약 0.003 USD가 소요되었습니다. 하루 10,000건의 문의를 처리하면 추론 비용만 하루 30 USD입니다. FinTech 기업에게 아주 비싼 금액은 아니지만, 100,000건으로 규모를 확장한다면 공급업체와 가격 협상을 하거나 로컬 오픈 소스 (open source) 모델로 마이그레이션 (migrate)해야 합니다.

오픈 소스 대안 및 벤더 종속 (Vendor lock-in)

OpenAI 또는 Anthropic에 의존하는 것을 피하고 싶다면, 현재 다음과 같은 구성으로 유사한 스택을 구축할 수 있습니다:

분류 (Classification): SentenceTransformers + scikit-learn (로지스틱 회귀 또는 SVM 분류기). 약 500개의 라벨링된 예시만 있으면 90% 이상의 정확도를 얻을 수 있습니다.
생성 (Generation): 온프레미스 (on-premise)에서 실행되는 양자화된 (quantized, GGUF 또는 llamafile 방식) Llama 3.1 8B 또는 Mistral 7B.
지연 시간 (latency)은 더 길지만 (1~3초 사이), 한계 비용 (marginal cost)은 제로입니다.
오케스트레이션 (Orchestration): LangChain 또는 많은 코딩 없이도 결정 노드 (decision nodes)를 포함한 흐름을 만들 수 있는 Dify (오픈 소스)와 같은 더 가벼운 시스템.

여기서의 트레이드오프 (tradeoff)는 운영 복잡성입니다. 자체 LLM을 호스팅하려면 GPU, 유지보수 및 모니터링이 필요합니다. 소규모 팀의 경우, 물량이 하드웨어 투자를 정당화할 수준이 될 때까지 API 공급업체에 비용을 지불하는 것이 더 수익성이 높을 수 있습니다.

우리의 프로젝트를 위해 배운 점은 무엇인가요?

이 사례는 FinTech (핀테크) 고객 지원에 대규모 인력이나 통제 불능의 클라우드 예산이 필요하지 않다는 것을 보여줍니다. 핵심은 **자신이 무엇을 모르는지 아는 지능형 계층 (intelligence layer)**을 설계하는 것입니다. 신뢰도가 낮은 분류기 (low confidence classifier)가 진정한 영웅입니다. 이는 봇이 터무니없는 답변을 하는 것을 방지하고 사용자 경험을 보호합니다.

금융 제품을 구축하고 있다면, 가장 단순한 문의(계좌 잔액, 영업 시간, PIN 번호 변경)의 60%를 자동화하는 MVP (최소 기능 제품)로 시작하여 점진적으로 반복(iterate)할 것을 권장합니다. 이 사례의 세 명의 작업자는 처음에는 100%의 문의를 처리하며 시작했으나, 점차 업무 부하를 줄여 나갔습니다.

더 자세한 내용과 가격 및 대안을 포함한 전체 비교는 FinTech 성공 사례: 3명의 인원으로 10,000건의 문의 처리 (IA 2026)에서 확인하실 수 있습니다.