0회차에서는 개인 자산관리 서비스를 만들려다가 주제를 바꿨다. 이걸 굳이 내가 만들어야 하는 이유를 찾지 못해서였다. 대신 정한 주제는 이거였다.
금융 고객의 상담 요청을 실제 금융 데이터 조회와 업무 처리까지 연결하는 작은 컨택센터 백엔드
흐름도 이렇게 그려뒀다.
고객 문의 → 문의 유형 파악 → 고객 데이터 조회 → 업무 처리 → 응답 → 상담 이력 저장이번 글에서는 이 흐름을 고객 한 명 기준으로 따라가 보면서 설계로 옮겨보려고 했다. 그런데 따라가다 보니 빠진 부분이 보였다.
0회차 흐름은 모든 문의가 챗봇 선에서 끝까지 처리된다는 전제로 그린 것이었다. 실제로는 그렇지 않다. 챗봇이 질문을 못 알아듣기도 하고, 알아듣더라도 이의 제기처럼 사람이 판단해야 하는 일이면 처리할 수 없다. 고객이 처음부터 상담원을 찾는 경우도 있고, 이미 화가 난 채로 들어오는 경우도 있다.
이런 문의는 결국 상담원에게 넘어간다. 그런데 0회차 흐름에는 상담원이 없었다.
0회차 글에 이 부분을 아예 안 쓴 건 아니었다. 상담 이력을 설명하면서 "처리하지 못한 요청은 이후 확장 단계에서 ESCALATED 상태로 관리할 수 있도록 설계한다"고 적어두긴 했다. 나중에 할 일로 미뤄둔 셈인데, 다시 보니 이 부분을 먼저 정해야 나머지 설계도 할 수 있을 것 같았다.
예를 들어 챗봇에 "카드 결제가 두 번 된 것 같아요"라고 쓴다. 챗봇은 본인 확인을 하고, 결제 내역을 보여주고, 확인하는 방법을 안내한다. 그래도 해결이 안 되면 상담원 연결로 넘어간다.
연결된 상담원이 처음 하는 말은 보통 이렇다.
고객님, 성함과 생년월일 말씀해 주시겠어요? 어떤 일로 연락 주셨어요?
챗봇에서 본인 확인도 했고 무슨 일인지도 이미 적었는데 처음부터 다시 말해야 한다.
상담원 입장에서도 고객이 챗봇에 뭐라고 했는지 모르는 상태로 시작한다. 계좌 화면, 카드 화면, 이전 상담 이력을 오가며 다시 확인하고, 상담이 끝나면 내용을 직접 정리해서 남긴다.
내 경험만으로 문제라고 하기는 어려워서 자료를 찾아봤다.
더스쿠프 기사에 인용된 한국능률협회컨설팅(KMAC)의 2024년 12월 국내 기업 챗봇 평가를 보면, 챗봇을 이용한 고객의 49.5%가 문의를 해결하지 못했고, 그중 93.8%는 콜센터로 다시 문의했다. 챗봇에서 사람으로 넘어가는 경우가 적지 않다는 뜻이다.
다시 설명하는 문제는 Salesforce의 State of the Connected Customer 6판(2023)에 나온다. 응답자의 56%가 여러 직원에게 같은 정보를 반복하거나 다시 설명해야 할 때가 많다고 답했고, 70%는 모든 직원이 자신에 대해 같은 정보를 알고 있기를 기대한다고 답했다.
상담원 쪽 자료도 있었다. 폴리뉴스가 보도한 한국노총 중앙연구원 조사(콜센터 종사자 168명)에서는 63.1%가 AICC 관련 고객 민원을 겪었다고 답했다. 하루 평균 민원은 AI 도입 전 8.55건에서 도입 후 10.08건으로 늘었고, 하루 상담 건수는 줄었지만 건별 후처리 시간은 두 배 넘게 길어졌다. 사회공공연구원의 공공·금융 콜센터 AI 도입 보고서도 상담사들이 AI가 처리하지 못한 문제를 마무리하는 2차 대응자가 되면서 고객 불만과 더 어려운 업무를 떠안고 있다고 정리했다.
금융감독원도 AI 상담이 맥락을 이해하지 못한 채 상담원 연결만 늦어지는 문제를 두고 콜센터 점검을 검토하고 있다(서울경제, 2026년 8월).
이 자료들이 재설명 하나 때문에 민원이 늘었다고 말하는 건 아니다. 다만 챗봇에서 사람으로 넘어가는 경우가 많고, 넘어간 뒤에 고객과 상담원 모두 부담이 커지고 있다는 건 확인할 수 있었다.
나는 인턴으로 회사의 상담 솔루션을 분석하면서, 상담 시스템이 IPCC에서 AICC로 넘어가는 과정을 옆에서 볼 수 있었다. 솔루션을 살펴보며 알게 된 건 상담 시스템이 질문에 답하는 프로그램 하나가 아니라는 점이었다. 고객을 식별하고, 데이터를 조회하고, 업무를 처리하고, 필요하면 상담원에게 연결하고, 이력을 남기는 흐름이 여러 시스템에 걸쳐 이어져 있었다.
AWS의 AICC 워크숍에서 AI 에이전트가 상담을 처리하는 구조를 직접 실습해 보면서도 비슷한 생각을 했다. AI를 상담 앞단에 붙이는 건 생각보다 금방 됐다. 그런데 AI가 처리하지 못한 상담이 사람에게 넘어갈 때, 그때까지 쌓인 내용은 어떻게 같이 넘길지가 궁금해졌다. 이번 프로젝트는 여기서 시작했다.
비슷한 지점을 다루는 사례를 몇 개 찾았다.
사례 | 내용 |
|---|---|
우리은행 · KT AICC 개편 | 챗봇, 상담봇, AI 뱅커 등 채널을 묶는 "에이전트 커넥터"로, 고객이 채널을 옮겨도 이전 상담 맥락을 유지 |
토스뱅크 AI 에이전트 | 단순 문의는 AI가 먼저 처리하고, 상담원에게는 실시간 요약과 응답 초안을 제공 |
Amazon Connect | 상담이 끝나면 생성형 AI 요약을 상담원의 후처리 화면에 표시 |
AI가 상담 앞단을 맡는 건 이미 진행되고 있고, 채널 사이에서 맥락을 잇거나 상담 뒤 정리를 돕는 기능도 나오고 있다. 이 프로젝트에서는 그중 AI에서 상담원으로 넘어가는 부분과 그 뒤처리를 다뤄보기로 했다.
프로젝트 이름은 이음으로 정했다. 한 줄로 정리하면 이렇다.
AI 상담이 해결하지 못해 상담원에게 넘어갈 때, 고객이 처음부터 다시 설명하지 않도록 맥락을 넘겨주고, 상담이 끝나면 요약·분류·기록까지 남기는 금융 상담 백엔드
3절의 예시로 보면, 챗봇에서 상담원으로 넘어가는 시점에 상담원 화면에 이런 내용이 먼저 떠 있는 게 목표다.
┌──────────────────────────────────────┐
│ 본인 확인: 완료 (챗봇, 3분 전) │
│ 용건: 카드 이중 결제 문의 │
│ 챗봇 진행 내용: 결제 내역 조회 → 미해결 │
│ 조회 결과: 같은 가맹점 · 같은 금액 승인 2건 │
│ 이관 사유: 고객 상담원 연결 요청 │
└──────────────────────────────────────┘상담원은 이 내용을 보고 바로 용건부터 확인할 수 있다. 상담이 끝나면 요약과 분류 초안이 채워져 있고, 상담원은 이를 확인하고 고친다.
사용자는 세 부류로 봤다.
사용자 | 지금 불편한 점 | 이음에서 바꾸려는 것 |
|---|---|---|
고객 | 같은 내용을 여러 번 말해야 한다 | 챗봇에서 말한 내용이 상담원에게 넘어간다 |
상담원 | 여러 화면을 오가며 확인하고, 상담 후 정리를 직접 한다 | 한 화면에서 시작하고, 정리는 초안을 확인하는 수준으로 줄인다 |
센터·준법 담당 | AI가 왜 해결하지 못했는지, 누가 고객 정보를 조회했는지 파악하기 어렵다 | 이관 사유와 고객 정보 조회 기록을 남긴다 |
고객이 직접 쓰는 서비스는 아니지만, 결과는 고객이 상담에서 바로 느끼게 된다.
은행 시스템은 보통 계정계, 정보계, 대외계로 나누고, 여기에 고객과 만나는 채널계를 더해 설명한다. 계좌, 거래, 이자 같은 금융 로직과 원장은 계정계에 있고, 앱이나 콜센터처럼 고객을 직접 상대하는 쪽이 채널계, 쌓인 데이터를 모아 통계를 내고 분석하는 쪽이 정보계다.
0회차 설계에서는 상담 백엔드가 계좌와 금리를 직접 들고 이자까지 계산하려고 했다. 이건 계정계가 할 일이다. 토스뱅크가 SLASH 23에서 공개한 코어뱅킹 전환기에서도 고객 요청을 코어뱅킹 서버로 전달하는 채널계와 돈과 관련된 핵심 로직을 처리하는 계정계를 나눠서 설명한다.
그래서 이음은 채널계에 두고, 금융 데이터는 계정계에서 조회하는 구조로 정했다.
[고객 · Telegram 챗봇] [상담원 웹 화면]
│ ▲
▼ │
┌──────────────── 이음 (채널계) ────────────────┐
│ 챗봇 상담 → 이관 판단 → 맥락 묶기 │
│ → 상담원 배정 → 후속 처리 → 요약 · 기록 │
└──────────────────────┬──────────────────────┘
│ 연계 (타임아웃, 장애 격리)
▼
가상 은행 (계정계)
고객 · 계좌 · 원장 · 이체 상태 · 카드 승인 내역 · 이자 산출 근거
정보계 배치
이관 사유 통계 · 개인정보 조회 점검실제 은행과 연결할 수는 없으니 계정계는 작은 가상 은행을 직접 만들어서 대신한다. 이음은 이 가상 은행의 데이터를 복사해 두지 않고, 필요할 때 조회해서 상담원에게 보여준다.
설계하면서 계속 기준으로 삼을 조건을 네 가지로 정했다.
① 잃지 않는다
챗봇 단계에서 있었던 본인 확인, 용건, 조회한 내용, 이미 처리한 것은 빠짐없이 상담원에게 넘어가야 한다.
② 한 번만
상담 한 건은 상담원 한 명에게만 배정되어야 한다. 여러 상담원이 동시에 수락해도 마찬가지다. 상담원이 카드 정지 같은 후속 처리를 두 번 눌러도 실제 처리는 한 번만 되어야 한다.
③ 모르면 확인한다
은행에 처리를 요청했는데 응답이 끊기면, 처리가 됐는지 안 됐는지 알 수 없다. 이때 요청을 다시 보내지 않고, 처리 결과를 조회해서 확정한다. 카카오페이 기술블로그에서 소개한 방식처럼 결과를 성공, 실패, 알 수 없음 세 가지로 나눠서 다룬다.
④ 남긴다
고객 정보를 조회할 때마다 누가, 언제, 누구의 정보를, 어떤 업무로 봤는지 기록한다. 상담 기록과 조회 기록은 수정하지 않고 추가만 한다.
각 조건은 테스트로 확인할 예정이다. 예를 들어 ②는 여러 상담원이 같은 상담을 동시에 수락하는 상황을 만들어서 배정이 한 건만 생기는지 확인한다.
실제 콜센터에서 상담 시간이 얼마나 줄었는지는 이 프로젝트에서 잴 수 없다. 대신 아래 항목을 대리 지표로 보려고 한다.
이관 후 상담원이 본인 확인이나 용건을 다시 물어본 비율
자동으로 만든 요약 초안을 상담원이 얼마나 수정했는지
챗봇이 해결하지 못한 이유가 어떻게 분포하는지
고객 정보 조회 중 조회 사유가 남은 비율
실제 효과가 아니라 대리 지표라는 점은 결과를 정리할 때도 같이 적을 생각이다.
맥락을 넘기는 데 꼭 AI가 필요한 건 아니다. 챗봇 단계에서 일어난 일을 빠짐없이 기록해 두고, 이관할 때 정리해서 넘기면 된다. 이건 백엔드에서 해결할 부분이다.
AI는 고객의 말이 어떤 문의인지 분류하는 것과 상담 요약 초안을 만드는 데만 쓴다. 이것도 처음에는 규칙 기반으로 만들고, 기본 기능이 완성된 뒤에 작은 모델과 비교해볼 계획이다. 상담원에게 넘길지 말지는 규칙으로 결정한다. 고객이 상담원 연결을 요청하거나 챗봇이 문의를 해석하지 못하면 상담원에게 넘기는 식이다.
0회차에서 AI는 처음부터 넣지 않는다고 했던 방향은 그대로 유지한다.
유지하는 것
금융 상담 백엔드를 만든다. 고객 채널은 Telegram 챗봇으로 시작한다
0회차 흐름(문의 → 유형 파악 → 조회 → 처리 → 응답 → 이력)은 챗봇 단계의 흐름으로 그대로 쓴다
Transaction, Idempotency, Batch, 상담 이력은 직접 구현한다
설계 → 장애 → 원인 분석 → 개선 과정을 기록한다
바뀌는 것
이자나 수익률 계산은 상담 백엔드가 아니라 계정계(가상 은행)에서 한다. 이음은 그 결과와 근거를 조회해서 보여준다
주식 보유, KIS API 연동, 매일 자산 리포트는 범위에서 뺐다
DB는 PostgreSQL 대신 MySQL을 쓴다
0회차에서 마지막 단계였던 상담 이력이 프로젝트의 중심이 됐다
사용자가 고객 한 명에서 고객, 상담원, 센터·준법 담당 셋으로 늘었다
0회차에 적었던 개념들은 이렇게 쓰인다.
0회차에 적은 것 | 이음에서 쓰이는 곳 |
|---|---|
Transaction | 상담 배정, 후속 처리 요청과 상담 기록을 함께 남길 때 |
Idempotency | 상담 배정과 후속 처리 중복 방지 |
Batch / Scheduler | 결과를 알 수 없는 처리 확정, 정보계 통계, 개인정보 조회 점검 |
상담 이력 | 상담원에게 넘길 맥락, 고객 정보 조회 기록 |
음성 상담은 하지 않는다. 채팅으로 만들고, 나중에 음성을 텍스트로 바꾼 결과가 같은 방식으로 들어올 수 있게만 열어둔다
실제 은행 연동과 실제 본인 인증은 하지 않는다. 가상 은행과 가상 인증으로 대신한다
상담원 화면은 확인에 필요한 정도로만 만든다
다음 글에서는 이음의 유스케이스와 흐름을 정리한다. 카드 이중 결제, 송금했는데 상대가 못 받았다는 문의, 이자 문의, 카드 분실, 상담원 연결 요청 같은 상황을 하나씩 따라가면서 챗봇이 어디까지 처리하고, 언제 상담원에게 넘기고, 넘길 때 어떤 정보를 함께 보낼지 정할 예정이다.
설계는 이번처럼 공개된 기술 블로그와 문서를 먼저 찾아보고, 그중 이 규모에서 가져올 것과 뺄 것을 정하는 식으로 진행하려고 한다.
0회차에서 주제를 정했다면, 이번에는 그 주제 안에서 어떤 문제를 풀지 좁혔다. 처음 그린 흐름을 따라가다 보니 챗봇이 해결하지 못한 상담이 사람에게 넘어가는 부분이 비어 있었고, 자료를 찾아보니 실제로도 그 부분에서 고객과 상담원 모두 불편을 겪고 있었다.
그래서 이 프로젝트는 챗봇에서 상담원으로 넘어가는 과정과 그 뒤처리를 중심으로 만들기로 했다. 다음 글부터는 이 방향을 구체적인 흐름과 설계로 옮겨볼 생각이다.