AX Case BlogAI 전환 사례 연구

전체 사례No. 010

Neo Financial 20인 고객지원팀으로 월 5만 건을 감당하며 71% 무인 완결을 달성하다

사례 번호
010
1차 출처
Intercom Fin 고객 사례
원문 게시
미표기

1. 왜 이 사례인가

물리적 지점이 없는 100% 디지털 금융 서비스(챌린저 뱅크)에서 고객 지원은 부가 서비스가 아니라 은행 창구 그 자체입니다. 잔액 송금, 결제 승인 거절, 급여 입금 지연 등 고객이 지원팀을 찾는 상황은 대부분 즉각적인 해결이 요구되는 긴급 금융 이슈입니다.

캐나다의 디지털 핀테크 Neo Financial은 신용카드, 입출금 및 저축 계좌, 모기지 상품을 확장하며 급성장하는 과정에서 거대한 운영 병목에 직면했습니다. 약 20명의 지원 인력이 매달 약 5만 건에 달하는 인바운드 문의를 파편화된 도구(Zendesk, Amazon Connect)로 처리하고 있었으며, 활성 고객 수를 2배로 늘리려는 시점에서 기존의 선형적 인력 증원 방식은 막대한 운영 비용을 초래할 위기였습니다.

Neo는 단순한 FAQ 챗봇이 아닌 백엔드 금융 시스템과 직접 연동되는 AI 에이전트(Intercom Fin)를 프론트라인에 배치했습니다. 그 결과 채팅 유입의 96%에 에이전트가 개입하여 이 중 71%를 사람 없이 종단(end-to-end) 해결했고, 월 2만 건 이상의 문의를 무인 처리하며 고객 만족도(CSAT)를 86%까지 끌어올렸습니다. 이 사례는 고위험·고규제 금융 도메인에서 백엔드 데이터 연동형 AI 에이전트를 통해 ‘고객 2배 성장 시 비용 2배 증가’라는 선형적 비용 함정을 끊어낸 전형적인 성공 사례입니다.


2. Problem

디지털 은행 고객의 문의는 일반 이커머스 문의와 성격이 완전히 다릅니다. 생활비 결제 실패나 급여 미입금처럼 고객의 생계와 직결된 긴급한 사안이 많아 작은 오차나 지연도 즉각적인 신뢰 상실로 이어집니다.

Neo의 초기 지원 체계는 세 가지 핵심적 한계에 부딪혔습니다:

  1. 도구의 파편화와 높은 운영 복잡성: 티켓팅 도구(Zendesk)와 전화 상담 시스템(Amazon Connect)이 분리되어 있어, 상담원은 여러 화면을 오가며 고객 이력을 수동으로 조회해야 했습니다.
  2. 선형적 인력 확장의 한계: 20명의 상담원이 월 5만 건의 문의를 처리하는 한계 상황에서, 고객 수가 2배로 증가할 때 동일한 비율로 상담 인력을 채용하는 것은 재무적으로 지속 가능하지 않았습니다.
  3. 엄격한 금융 규제 및 컴플라이언스 제약: 금융 고객 데이터를 다루는 환경 특성상 PCI-DSS를 비롯한 엄격한 규제 가이드라인을 준수해야 했습니다. 기존 시스템에 구축된 보안 통제를 훼손하지 않으면서 새로운 자동화 체계를 도입해야 하는 높은 기술적 장벽이 존재했습니다.

확인된 사실: 지점 없는 100% 디지털 금융 환경, 약 20명의 지원 인력으로 월 약 5만 건 처리, Zendesk와 Amazon Connect로 나뉜 분절된 인프라, 3년 연속 Deloitte Fast 50 선정에 따른 급격한 고객 증가, 활성 고객 2배 확대 계획 직면.


3. Solution

Neo는 한 번에 전면 교체하는 모험을 피하고, 철저한 단계적 검증을 거쳐 헬프데스크 전체를 AI 퍼스트 환경으로 전환했습니다.

3.1 1단계: 실무 데이터 기반 파일럿 검증

Neo는 헬프데스크 전환에 앞서 기존 환경에서 Fin 에이전트를 먼저 시험 운용했습니다. 실제 고객 상담 대화 데이터를 투입해 답변의 정확도, 금융 규제 준수 여부, 계정별 맞춤 조회 능력을 검증했습니다.

  • 도입 첫 주 만에 자동 완결률이 3~4%포인트 상승했습니다.
  • 긍정 고객 만족도(CSAT)는 도입 전 약 50% 수준에서 약 75% 수준으로 즉각 반등했습니다.
  • 운용 3개월 시점에 Fin이 직접 처리한 대화의 60%를 스스로 해결하는 안정성을 입증했습니다.

3.2 2단계: 무중단 하룻밤 헬프데스크 마이그레이션

파일럿 성과를 확인한 후, 기존 Zendesk 체제에서 Intercom과 Fin의 통합 환경으로 전환을 단행했습니다. 24시간 자금이 오가는 디지털 뱅킹 특성상 서비스 중단은 허용되지 않았습니다.

  • AWS 마켓플레이스를 통해 도입 계약을 진행하여 기존 클라우드 인프라 자산과 연계했습니다.
  • 벤더(Fin)의 구축 전담 조직과 협력하여 수년간 Zendesk에 축적된 PCI 규제 준수 워크플로와 과거 전체 티켓 이력을 사전 매핑했습니다.
  • 고객 이용량이 적은 야간의 단일 점검 시간대를 활용해 무중단으로 전체 전환을 완료하고 익일 아침부터 정상 운영에 들어갔습니다.

3.3 3단계: 백엔드 코어 연동 및 프론트라인 배치

단순 텍스트 매칭 방식의 FAQ 챗봇과 달리, Fin 에이전트를 Neo의 핵심 금융 백엔드 시스템과 API로 연동했습니다:

  • 계정별 상태 조회: 특정 결제가 왜 승인 거절되었는지, 송금 입금이 왜 지연(pending) 상태인지, 계정 인증을 어떻게 갱신해야 하는지 등 고객별 고유 데이터가 필요한 질문을 실시간으로 조회해 답변하도록 설계했습니다.
  • 금융 규정 가드레일: 금융 컴플라이언스상 발언 가능한 문구와 발언이 금지된 표현을 엄격히 통제하는 지침을 부여했습니다.
  • 원활한 상담원 핸드오프: 에이전트가 완결할 수 없거나 규정상 사람이 직접 처리해야 하는 사안은 즉시 대화 전문과 계정 맥락을 보존한 채 인간 상담원에게 실시간 전달되도록 구성했습니다.

확인된 사실: 실대화 파일럿 1주 차 CSAT 50%→75% 상승, 3개월 차 60% 자체 해결 달성, AWS Marketplace를 통한 조달, 단일 야간 무중단 마이그레이션 완료, 결제 보류·거절 사유 조회를 위한 금융 백엔드 API 연동, 맥락 보존 상담원 핸드오프.


4. Impact

Intercom Fin 고객 사례 원문에 공개된 측정 지표는 다음과 같습니다. 원문에는 구체적인 게시 일자가 명시되지 않았으며, 지표 확인 기준일은 2026년 9월 22일입니다.

지표개선 성과비고
채팅 인바운드 개입률 (Involvement)96%인입되는 거의 모든 채팅 문의의 1차 접점 담당
채팅 종단 무인 해결률 (End-to-End Resolution)71%인간 상담원 개입 없이 에이전트가 자체 완결
월간 무인 해결 대화 건수20,000건 이상월 5만 건 문의 중 대다수를 자동 해결
고객 만족도 (CSAT)50% 수준 → 75% (1주 차) → 86%도입 전후 대비 극적인 만족도 개선
채팅 채널 선호 비중약 50% → 70%신속한 에이전트 응답으로 전화 대신 채팅 이용 급증
파일럿 1주 차 자동 해결률 상승 폭+3~4%p파일럿 투입 직후 확인된 조기 개선폭
3개월 차 자체 해결률60%전사 전면 전환 직전 단계의 지표

원문은 특히 인바운드 문의의 채널 비중이 전화에서 채팅으로 이동(50%→70%)한 점을 강조합니다. 고객은 답변을 제대로 주지 않는 챗봇을 경험하면 즉시 전화로 이탈하지만, Fin이 대기 시간 없이 즉시 계좌 문제를 해결해 주면서 자발적인 채팅 선호가 형성되었습니다.


5. Insight

Neo Financial의 사례는 고객 접점 자동화에서 ‘정확성’과 ‘시스템 연동’이 만들어내는 운영 레버리지를 증명합니다.

FAQ 지식 베이스를 넘어선 백엔드 연동이 핵심입니다. 정적 문서만을 검색하는 에이전트는 금융 도메인에서 해결률 30%를 넘기기 어렵습니다. Neo는 결제 실패 코드, 송금 대기 상태 등 백엔드 상태값을 실시간으로 조회해 인출·안내하는 동적 데이터 연동을 구현함으로써 71%라는 높은 종단 완결률을 이끌어냈습니다.

고객 경험 개선이 유도한 채널 시프트에 주목해야 합니다. 콜센터 운영 비용은 텍스트 채팅 대비 통상 수배 이상 비쌉니다. 전화 상담을 강제로 축소하는 대신, 채팅 접점의 체감 완결 속도와 만족도를 높임으로써 고객 스스로 전화를 걸지 않고 채팅을 선택하게 만들었습니다.

인력 채용의 디커플링을 달성했습니다. 20여 명의 린한 인력으로 월 5만 건을 방어하면서, 향후 고객 기반이 2배로 늘어나더라도 지원 인력을 비례적으로 늘리지 않고 스케일할 수 있는 기반을 마련했습니다.

복제 조건과 한계. 이 사례의 핵심 전제는 고객 계정 상태를 안전하게 반환할 수 있는 표준화된 내부 뱅킹 API와 엄격한 인증 인프라입니다. 백엔드 시스템이 레거시 모놀리스로 닫혀 있거나 개인정보 식별(PII) 통제가 분리되어 있지 않은 조직에서는 에이전트가 실질적인 조회를 수행하지 못해 겉핥기식 안내에 그칠 위험이 있습니다.


6. 원문에 없는 추정 (구현 가설)

6.1 계정별 결제 실패 및 보류 사유 조회를 위한 도구 호출(Tool Calling) 아키텍처

근거: 원문은 Fin이 Neo의 백엔드 시스템과 연동되어 특정 거래가 왜 승인 거절되었는지, 왜 보류 중인지와 같은 계정 고유의 질문에 답변한다고 기술합니다.

이 기능이 작동하기 위해서는 인앱 인증(SSO/JWT)을 거쳐 검증된 고객 ID가 대화 세션에 주입되는 구조가 선행되었을 것입니다. 고객이 “방금 마트에서 카드가 왜 긁히지 않았나요?”라고 입력하면, 에이전트는 지식 베이스 검색 대신 내부 트랜잭션 조회 도구(예: get_recent_declines(customer_id))를 호출하는 경로를 탑니다. 뱅킹 코어로부터 반환된 원시 에러 코드(예: ERR_INSUFFICIENT_FUNDS, ERR_CVV_MISMATCH, ERR_VELOCITY_LIMIT)를 수신한 뒤, 에이전트는 이를 금융 소비자 눈높이에 맞춘 정중하고 명확한 문장으로 변환하여 안내했을 가능성이 높습니다. 이 과정에서 잔액이나 카드 번호 같은 민감 정보는 마스킹(Masking) 처리된 채 전달되는 보안 프록시 계층이 필수적이었을 것으로 추정됩니다.

6.2 PCI-DSS 준수를 위한 하룻밤 컷오버 데이터 파이프라인

근거: 원문은 엄격한 규제와 PCI 의무를 준수하면서 Zendesk에서 Intercom으로 단일 야간 점검 시간 동안 무중단 전환을 완료했고, 과거 티켓 이력과 컴플라이언스 워크플로가 완벽히 이전되었다고 밝힙니다.

하룻밤 사이에 데이터 누락 없이 이전을 끝내기 위해서는 사전 동기화(Pre-sync) 파이프라인이 가동되었을 개연성이 큽니다. 수년간 쌓인 대용량 과거 티켓 데이터는 마이그레이션 수일 전부터 백그라운드 ETL을 통해 Intercom의 스키마에 맞추어 암호화 전송·적재해 두고, 점검 당일 밤에는 컷오버 시점 직전 수 시간 동안의 델타(변경분) 데이터만 최종 동기화하는 방식을 취했을 것입니다. 또한 PCI-DSS 요건에 따라 티켓 본문이나 첨부 파일에 포함되었을지 모르는 카드 번호(PAN) 등 결제 민감 정보를 탐지하여 토큰화하거나 마스킹하는 정제 작업이 마이그레이션 스크립트에 포함되었을 가능성이 매우 높습니다.

6.3 라이프사이클 마일스톤 기반 선제적(Proactive) 개입 트리거

근거: 원문 결미에서 Eunice Dunmade는 고객이 온보딩 라이프사이클의 한 단계에서 다음 단계로 5일 내에 도달하지 못할 때 에이전트가 먼저 다가가 도움을 제공하는 선제적 지원 체계를 준비 중이라고 언급합니다.

이러한 선제적 에이전트 워크플로는 백엔드 제품 분석 이벤트(예: 계좌 개설 완료 후 5일간 첫 입금 미발생)를 감지하는 내부 배치 작업이나 웹훅 트리거와 연동될 것으로 추정됩니다. 이벤트가 발생하면 고객 지원 시스템에 사전 정의된 아웃바운드 대화 컨텍스트가 생성되고, Fin 에이전트가 고객의 현재 상태(신분증 인증 통과 여부, 은행 계좌 연결 시도 실패 로그 등)를 조회하여 “계좌 개설을 완료하셨는데 첫 입금에 어려움이 있으신가요?”와 같이 맥락에 맞춘 선제적 메시지를 인앱 푸시나 메시지로 띄우는 형태로 구현될 수 있습니다.


7. 출처

  1. Intercom Fin Customer Stories — How Neo Financial built a support system that can double its customers without doubling costs
    https://fin.ai/customers/neo
    게시일: unknown (확인일: 2026-09-22)
    (Eunice Dunmade Director of Customer Operations; 71% end-to-end resolution, 96% chat involvement, ~20k monthly resolutions, CSAT 86%)