1. 상담요약은 왜 필요할까?
AI 상담 어시스트 제품을 기획하면서 상담요약 기능을 구현해야 했다. 기능을 설계하기 전에 먼저 생각한 것은 상담요약이 왜 필요한가였다.
상담사는 통화가 끝나면 상담이력을 남긴다. 상담요약은 그 이력에 들어가는 여러 정보 중 하나다. 다음에 고객을 응대하는 상담사는 이전에 어떤 대화가 오갔고 무엇을 처리했는지 알아야 한다. 관리자는 고객관리와 상담관리 차원에서 어떤 상담이 이루어졌는지 빠르게 파악해야 한다.
그런데 이런 목적이라면 상담 내용을 단순히 짧은 줄글로 만드는 것이 최선일까? 저장된 요약을 읽는 것만으로는 고객이 어떤 상황에서 무엇을 요청했고 상담사가 어떻게 조치했는지 한눈에 구분하기 어려울 수 있다.
그래서 상담 내용을 세 가지로 나누는 방식을 생각했다.
- Situation: 고객은 어떤 상황에 있었는가?
- Request: 무엇을 요청했는가?
- Action: 상담사는 어떻게 처리했는가?
이렇게 나누면 다음 상담사가 이전 대화를 더 빠르게 이해하고, 관리자도 상담 내용을 일정한 기준으로 확인할 수 있을 것이라고 판단했다.
하지만 상담이력을 남기는 목적을 생각할수록 여기서 끝내기는 아쉬웠다. 상담이력은 고객의 이전 대화를 확인하기 위한 기록인 동시에, 기업이 고객을 지속적으로 관리하기 위해 축적하는 데이터이기도 하다.
그렇다면 이 데이터를 읽는 데만 쓰지 않고, 분석에도 활용할 수 있지 않을까? 상황·요청·조치를 하나의 요약 문장으로만 남기지 않고 각각 구조화해 저장하려고 생각한 이유다.
2. 상황·요청·조치를 연결하면 무엇이 보일까?
각각의 데이터가 분리되어 있다면 개별 상담을 읽는 것과 다른 분석이 가능해진다.
같은 상황의 고객들은 무엇을 요청할까? 대출 만기를 앞둔 고객이라도 누군가는 연장 신청을 원하고, 누군가는 절차를 묻고, 다른 고객은 비대면으로 처리할 수 있는지 확인하고 싶어 할 수 있다.
같은 요청에 상담사는 어떻게 대응할까? 연장 절차를 묻는 고객에게 어떤 상담사는 서류 안내 문자를 보내고, 다른 상담사는 영업점 방문을 안내할 수 있다.
이런 흐름을 한눈에 보기 위해 Sankey 다이어그램을 활용하는 실험을 했다. n8n과 LLM을 이용해 대출 만기 연장 상담 STT 30건에서 상황·요청·조치를 추출하고, 비슷한 표현을 정규화한 뒤 코드북을 만들었다. 그리고 세 가지 데이터의 연결을 Sankey로 시각화했다.
실험에서 흥미로웠던 것은 같은 상황과 요청에서도 조치가 달라지는 분기였다. 고객의 조건이 달랐거나 상담사의 업무 처리 방식이 달랐을 수 있다. 조치가 갈라졌다는 사실만으로 어느 쪽 처리가 적절했는지 판단하기는 어렵다. 다만 어느 지점에서 처리가 달라지는지, 그리고 무슨 조건을 더 확인해야 하는지를 볼 수 있었다.
30건은 가능성을 확인하기 위한 작은 실험이었다. 실제 반복 패턴을 판단하려면 더 많은 데이터와 검증이 필요하다.
3. 상담유형에 가려진 고객 문제를 볼 수 있을까?
이 실험을 통해 더 생각해 보고 싶었던 것은 고객센터의 기존 상담유형이었다. 상담유형은 상담 업무를 기록하고 운영하기 위한 분류다. 하지만 동일한 유형으로 기록된 상담이라도 고객이 처한 상황과 필요한 해결 방식은 다를 수 있다.
예를 들어 모두 ‘한도 상향’ 문의라고 해보자. 한 고객은 현재 한도를 모두 사용했고, 다른 고객은 이전에 낮춘 한도를 다시 올리려고 한다. 같은 한도 상향 요청이지만 확인해야 할 조건과 필요한 절차는 다를 수 있다.
기존 상담유형에서는 두 고객의 문의가 하나로 묶인다. 상황·요청·조치를 각각 구분하면 같은 유형 안에서도 어떤 상황에서 어떤 요청이 발생하고, 그 요청이 어떤 조치로 이어지는지 비교할 수 있다.
상담을 운영하기 위한 분류와 고객의 문제를 발견하기 위한 분석 단위는 달라야 한다고 생각했다. Sankey는 그 차이를 관찰하는 하나의 방법이었다.
4. 여기에 고객의 상태와 행동을 연결한다면?
Sankey가 보여주는 것은 상담 안에서의 관계다. 같은 요청에서 서로 다른 조치가 발생한 이유를 알려면 상담 이전의 정보가 필요하다.
고객이 어떤 상품과 조건을 가지고 있었는지, 어떤 화면에서 무엇을 시도했는지, API가 어떤 상태를 반환했는지, 직전에 어떤 알림을 받았는지 같은 정보다. 그래서 상담 데이터에 이런 정보를 메타데이터로 연결하는 구조를 생각했다.
이를 통해 비슷한 조건에서 같은 문제를 경험한 고객을 찾을 수 있지 않을까? 상담에 나타난 문제가 특정 정책 변경이나 시스템 이벤트 이후 반복된다면 그 사건과의 관련성을 검토할 수 있을 것이다.
같은 시점에 발생했다는 사실은 가설을 세울 단서다. 원인을 확인하려면 상담 내용과 시스템 기록을 대조하고, 다른 가능성도 검토해야 한다.
5. 문제를 발견한 다음에는 누가 해결할까?
고객이 어디에서 막혔는지 알게 되더라도, 그 문제를 실제로 해결할 수 있는 조직은 따로 있을 수 있다. 제품 기능이 원인이라면 제품 담당자가, 정책이 문제라면 정책 담당자가, 안내가 불충분하다면 관련 업무 담당자가 검토해야 한다. 그런데 이 문제들은 고객센터에 들어온 뒤 상담유형과 처리 건수로 기록되고 끝나기 쉽다.
고객센터에서 발견한 문제를 실제로 바꿀 수 있는 조직까지 연결하려면 어떤 정보가 필요할까?
상담에서 추출한 상황·요청·조치에 발생 이벤트, 관련 기능, 고객 상태, 원인 가설, 영향 범위 등의 정보를 연결한다면 담당 조직을 찾는 데 도움이 될 수 있다고 생각했다.
그래서 이벤트별 담당 부서를 미리 연결해 두고, 반복되는 패턴이 나타나면 근거와 함께 검토할 조직을 제안하는 구조를 구상했다. 담당자는 근거를 검토해 개선 요청을 확정하고, 조치 이후에도 같은 문제가 발생하는지 추적한다. 문제를 발견한 조직과 실제로 바꿀 수 있는 조직이 다를 수 있다는 전제에서 출발한 구상이다.
6. 지금 어디까지 해봤고, 무엇을 검증해야 할까?
현재까지 해본 것은 상담 STT를 상황·요청·조치로 구조화하고, 코드북으로 정규화해 Sankey로 시각화하는 프로토타입 실험이다.
고객 행동·상태·이벤트 메타데이터의 결합, 문제 패턴 탐지, 담당 조직 추천, 개선 이후 재발 추적은 앞으로 검증해야 할 설계다.
서로 다른 시스템의 기록을 어떻게 연결할지, 같은 고객의 여러 문의를 어디까지 하나의 문제로 볼지, 원인 가설과 확인된 사실을 어떻게 구분할지, 부서별 책임을 어떤 기준으로 판단할지 검증해야 한다. Lab에서는 합성 데이터로 이 흐름을 탐색할 수 있다.
출발점은 상담요약 기능이었다. 상담이력을 왜 남기는지 질문하면서, 상담 데이터가 기록을 넘어 고객의 문제를 발견하고 해결하는 데 쓰일 수 있지 않을까 생각하게 됐다. 이제 확인하고 싶은 것은 그 가능성이 실제로 작동하는가이다.