# 2회차 | 구체적인 흐름과 설계

Об этом предложении

2회차 | 구체적인 흐름과 설계 0. 이번 글에서 정하는 것 1회차에서 이음의 방향을 정했다. AI 상담이 해결하지 못해 상담원에게 넘어갈 때, 고객이 처음부터 다시 설명하지 않도록 맥락을 넘겨주는 금융 상담 백엔드다. 이번 글에서는 문의 하나를 처음부터 끝까지 따라가면서, 설계 전에 정해야 할 것들을 결정한다. 대상 시나리오: 카드 이중 결제 문의 결과물 1: 정상 흐름과 단계별로 남길 기록 결과물 2: 이관 패키지에 담을 것과 담지 않을 것 결과물 3: 네 가지 결정 (이관 기준, 인증 승계, 배정 방식, 챗봇 처리 범위) 결과물 4: 예외 흐름 네 가지 1. 등장인물과 시스템 이 흐름에는 사람 셋과 시스템 둘이 나온다. 구분 이름 역할 사람 고객 Telegram 챗봇으로 문의 사람 상담원 웹 상담원 화면에서 이관된 상담 처리 사람 센터·준법 담당 이관 사유와 고객 정보 조회 기록 확인 시스템 이음 (채널계) 챗봇 상담, 이관 판단, 이관 패키지 생성, 배정, 기록 시스템 가상 은행 (계정계) 고객, 카드, 승인 내역 등 금융 데이터 보유 2. 왜 카드 이중 결제부터인가 카드 이중 결제는 챗봇이 혼자 끝내기 어렵고, 상담원이 판단할 근거가 필요한 문의다. 이번 주 금테크 스터디에서 카드 결제 흐름을 조사하면서 확인한 내용이 그 이유다. 카드 결제는 승인 과 매입 이 나뉘어 있다 승인: 카드사가 결제를 허가하는 단계. 신용카드는 이 시점에 한도만 차감되고, 체크카드는 바로 출금된다 매입: 승인된 결제를 카드사에 청구해 정산받는 단계 취소도 시점에 따라 다르다 매입 전 취소는 승인 취소로 즉시 처리된다 매입 후 취소는 환불까지 2~3영업일이 걸린다 그래서 고객 눈에는 똑같이 두 번 결제로 보여도, 상담원이 확인해야 할 상황은 여러 가지다. 실제로 같은 결제가 두 번 승인된 경우 응답을 받지 못해 다시 요청하면서 두 건이 승인된 경우 한 건은 이미 취소됐지만 환불이 아직 반영되지 않은 경우 결론: 상담원 화면에는 승인 금액만이 아니라 승인 건별 상태와 시각이 함께 있어야 한다. 이 결정이 이후 이관 패키지 설계로 이어진다. 3. 정상 흐름 카드 이중 결제 문의는 아래 순서로 흘러간다. 오른쪽은 각 단계에서 이음이 남기는 기록이다. [고객] [이음 · 챗봇] [가상 은행] [상담원] │ 카드 결제가 두 번 됐어요 ├──────────────▶│ MESSAGE_RECEIVED │ │ 본인 확인 요청 (PIN) │◀──────────────┤ ├──────────────▶│ AUTH_VERIFIED │ │ 문의 분류: 카드 이중 결제 INTENT_CLASSIFIED │ │ 최근 승인 내역 조회 │ ├──────────────────────▶│ │ │◀──────────────────────┤ CORE_QUERIED │ │ 같은 가맹점·같은 금액 2건 발견 │ 승인 내역 안내 │ │◀──────────────┤ BOT_REPLIED │ 상담원 연결해 주세요 ├──────────────▶│ HANDOFF_DECIDED │ │ 이관 패키지 생성 HANDOFF_PACKAGED │ │ 대기열 등록 QUEUED │ │ 상담원이 가져감 │ │◀───────────────────────────────────────┤ ASSIGNED │ │ 이관 패키지 전달 ─────────────────────────▶│ │◀──────────────┼──────────── 상담원 채팅 ──────────────────┤ AGENT_MESSAGE │ │ 승인 취소 요청 │ │ ├──────────────────────▶│◀────────────────┤ FOLLOWUP_REQUESTED │ │◀──────────────────────┤ FOLLOWUP_CONFIRMED │ │ 상담 종료 │ │ │ 요약·분류 초안 생성 SUMMARY_DRAFTED │ │ 초안 확정 │ CLOSED 이 흐름에서 정한 원칙은 세 가지다. 모든 단계는 상담 이벤트 로 남고, 수정하지 않고 추가만 한다 이관 패키지는 이관 시점까지 쌓인 이벤트를 묶은 결과다 가상 은행을 조회할 때마다 조회 기록을 함께 남긴다 4. 이관 패키지에 무엇을 담나 이관 패키지는 상담원이 고객에게 다시 묻지 않고 바로 용건부터 확인할 수 있는 만큼만 담는다. 구분 항목 이유 필수 상담 ID, 내부 고객 식별자 상담과 고객을 잇는 기준 필수 본인 확인 결과, 방식, 시각 인증 승계 판단 근거 필수 문의 분류 결과 상담원의 첫 질문을 정하는 기준 필수 이관 사유 통계와 상담원 대응 방식 결정 필수 챗봇 대화 원문 요약이 틀렸을 때 원문으로 확인 필수 챗봇이 조회한 내역과 조회 시각 같은 조회를 반복하지 않기 위해 필수 챗봇이 이미 처리한 것 같은 처리를 두 번 하지 않기 위해 선택 불만 신호 (감지된 키워드) 상담원 첫 응대 방식 참고 선택 최근 상담 이력 반복 문의 여부 확인 담지 않음 카드번호 전체 끝 4자리만 표시 담지 않음 PIN 등 인증 정보 원문 인증 결과만 넘긴다 담지 않음 용건과 무관한 금융 정보 (전체 계좌 잔액 등) 필요한 경우 상담원이 사유를 남기고 추가 조회 카드 이중 결제의 경우 승인 내역은 건별로 이렇게 담는다. 항목 예시 가맹점 강남 OO카페 금액 4,500원 승인 시각 2026-10-04 12:31:05 상태 승인 / 매입 / 취소 승인번호 끝 4자리 조회 시각 2026-10-04 12:33:40 조회 시각을 함께 담는 이유는, 상담원이 보는 정보가 실시간 값이 아니라 챗봇이 조회한 시점의 값 이라는 걸 분명히 하기 위해서다. 상담원이 최신 상태가 필요하면 다시 조회한다. 5. 네 가지 결정 5-1. 언제 상담원에게 넘기나 (이관 기준) 결정: 아래 네 가지 중 하나라도 해당하면 넘긴다. 판단은 모두 규칙으로 한다. 이관 사유 판단 방법 고객이 상담원 연결을 요청 상담원, 사람, 연결 등 키워드 같은 용건 해석 실패 2회 문의 분류 실패 횟수 챗봇 권한 밖 업무 승인 취소 요청, 이의 제기, 카드 정지 해제 불만 신호 감지 불만 키워드 선택지로 AI가 이관 여부를 판단하는 방식도 있었지만 제외했다 이유: 같은 상황에서 항상 같은 결과가 나와야 이관 사유 통계를 믿을 수 있다 2회라는 기준은 가정값이다. 정책 데이터로 분리해서 나중에 바꿀 수 있게 한다 5-2. 챗봇의 본인 확인을 상담원이 이어받나 (인증 승계) 결정: 챗봇에서 본인 확인을 마친 뒤 10분 이내이고 조회성 상담이면 이어받는다. 위험을 늘리는 처리는 다시 확인한다. 상황 처리 본인 확인 후 10분 이내, 조회·안내 상담 승계, 상담원은 다시 묻지 않음 본인 확인 후 10분 초과 상담원이 다시 확인 카드 정지 해제 등 위험을 늘리는 처리 시간과 관계없이 다시 확인 항상 다시 확인하면 1회차에서 정한 재설명 문제가 그대로 남는다 항상 승계하면 오래된 인증으로 위험한 처리가 될 수 있다 10분은 가정값이다. 실제 금융사의 인증 유효시간 기준은 따로 확인이 필요하다 5-3. 누구에게 넘기나 (배정 방식) 결정: 상담원이 대기열에서 직접 가져가는 방식으로 한다. 여러 상담원이 동시에 가져가도 한 명만 성공한다. 선택지 장점 단점 상담원이 가져가기 (선택) 상담원 상태를 시스템이 몰라도 됨, 구현 단순 동시에 여러 명이 같은 건을 누를 수 있음 시스템이 배정하기 대기 시간 관리가 쉬움 상담원 상태 추적, 배정 알고리즘 필요 동시 수락 문제는 조건부 UPDATE로 막는다 블로그 스터디 1주차에 회의실 예약 중복을 실험하면서, 조건부 UPDATE가 충돌한 요청만 정확히 막는 것을 확인했다 같은 방식을 상담 배정에 적용하고, 구현 회차에서 동시 수락 테스트로 검증한다 5-4. 챗봇은 어디까지 처리하나 (챗봇 처리 범위) 결정: 위험을 줄이는 처리와 조회는 챗봇이 끝낸다. 위험을 늘리거나 판단이 필요한 처리는 상담원이 한다. 챗봇이 처리 상담원이 처리 승인 내역 조회 승인 취소 요청 이체 상태 조회 이의 제기 접수 이자 조회 카드 정지 해제 카드 분실 정지 카드 분실 정지는 위험을 줄이는 처리라서 챗봇이 바로 한다 정지 해제는 같은 카드에 대한 처리지만 위험을 늘리는 처리라서 상담원에게 넘긴다 1회차에서 정한 원칙과 같다: 위험을 줄이는 요청은 빠르게, 늘리는 요청은 신중하게 6. 예외 흐름 정상 흐름 외에 반드시 정해둬야 할 예외는 네 가지다. 구현은 이후 회차에서 한다. 예외 어떻게 처리하나 대기 중 고객 이탈 상담을 이탈 상태로 바꾸고 이관 패키지는 보존. 30분 이내 재접속하면 이어서 처리 배정 후 상담원 무응답 가져간 뒤 60초 안에 첫 응답이 없으면 대기열로 되돌림 가상 은행 일부 장애 카드 정보 조회가 실패해도 이관 패키지는 생성. 해당 항목은 조회 불가로 표시하고 상담원이 다시 조회 후속 처리 결과 불명 승인 취소 요청의 응답이 끊기면 다시 요청하지 않고 처리 상태를 조회해서 확정. 확정 전에는 고객에게 처리 확인 중이라고 안내 마지막 예외는 카카오페이 기술블로그에서 소개한 방식을 따른다. 결과를 성공, 실패, 알 수 없음 세 가지로 나누고, 알 수 없음은 조회로 확정한다 30분, 60초는 가정값이다 7. 나머지 시나리오는 무엇이 다른가 카드 이중 결제와 같은 흐름을 쓰되, 아래 부분만 다르다. 시나리오 챗봇 단계 이관 패키지의 핵심 항목 송금했는데 상대가 못 받음 이체 상태 조회. 처리 중이면 안내로 종료 가능 거래번호, 이체 상태, 요청 시각 이자가 왜 이것밖에 안 되나 이자 조회. 대부분 챗봇에서 종료 일별 잔액, 적용 금리 등 산출 근거 카드 분실 챗봇이 정지까지 처리. 재발급 문의만 이관 정지 처리 결과와 시각 상담원 연결 요청, 해석 실패 용건 파악 전에 이관 챗봇 대화 원문, 이관 사유 8. 정리 정한 것 모든 상담 단계는 상담 이벤트로 남기고, 이관 패키지는 이벤트를 묶어서 만든다 이관 패키지의 필수, 선택, 담지 않는 항목 이관 기준 네 가지, 모두 규칙으로 판단 인증 승계는 시간과 처리 위험도로 판단 배정은 상담원이 가져가는 방식, 조건부 UPDATE로 한 명만 성공 챗봇은 조회와 위험을 줄이는 처리까지 가정으로 남긴 것 해석 실패 2회, 인증 유효시간 10분, 이탈 후 재접속 30분, 상담원 무응답 60초 모두 정책 데이터로 분리해서 바꿀 수 있게 한다 다음에 정할 것 가상 은행의 카드 승인 내역에 어떤 상태를 둘지 (승인, 매입, 취소) 응답을 받지 못한 결제 승인을 실제 결제 시스템에서는 어떻게 정리하는지 (금테크에서 추가 조사) 상담 이벤트와 이관 패키지의 데이터 구조 9. 다음 글 다음 글에서는 가상 은행을 설계한다. 상담원이 보게 될 근거 데이터인 고객, 계좌, 원장, 카드, 승인 내역을 어떻게 저장할지 정한다. 이번 글에서 정한 승인 건별 상태와 시각이 그 출발점이 된다. 참고 토스페이먼츠 개발자센터 — 카드 결제 총정리 토스페이먼츠 블로그 — 신용카드 승인과 매입, 어떤 개념인가요? 카카오페이 기술블로그 — MSA 환경에서 네트워크 예외를 잘 다루는 방법 이데일리 — KT, 우리은행 AICC 에이전틱 전환