상담 데이터 분석을 통해 메뉴얼 추출하기

여러 고객사에 상담 에이전트 ALF를 도입하며 발견한 공통 패턴은 가장 오래 걸리는 구간이 세팅이 아니라 세팅 전 단계라는 것이었다. 고객사의 상담이 어떤 유형으로 이뤄지고 각 유형이 어떤 흐름으로 처리되며 AI가 어떤 상황에 어떻게 판단해야 하는지를 함께 정의하는 데 대부분의 시간이 쓰였다. 상담 데이터에서 SOP를 자동 생성하고 그것을 ALF 등록 단위로 분리하는 파이프라인을 만든 이야기다.

핵심 포인트

상담 프로세스를 처음부터 언어로 정의하는 것은 오랫동안 암묵적으로 처리해온 것을 꺼내 문서로 만드는 작업이라 생각보다 어렵다.
이전에도 데이터 분석은 했지만 AI에게 분류를 맡기면 같은 데이터를 넣어도 매번 다른 결과가 나와 사람이 계속 붙어야 했고 자동화라 부르기 어려웠다.
"배송 문의가 23%"라는 정보는 있어도 챗봇이 그 문의에 어떻게 대응해야 하는지는 여전히 사람이 정리해야 해, 도입 계획이 자동화 가능 여부 수준에서 멈췄다.
분류는 임베딩과 클러스터링 스크립트로 처리해 재현성을 확보하고, AI 동작은 RFC 2119 키워드로 명시된 Agent SOP 문서로 제어했다.
상담 유형별 비중과 SOP 커버 범위를 합치면 도입 전에 월 몇 건을 처리할 수 있다는 기대치를 근거 있게 제시할 수 있다.

상세 정리

파이프라인 흐름: 상담 데이터를 받아 SOP를 만들고, 그 SOP를 ALF에 바로 올릴 수 있는 세팅 파일로 분리한다.
1단계 분류: 임베딩과 클러스터링으로 상담을 유형별로 묶고 라벨은 AI가 샘플을 직접 읽고 붙인다.
2단계 패턴 추출: 각 클러스터에서 실제 고객 표현과 빈출 패턴, 상담사의 해결 방식을 뽑는다. 배송 문의라면 "언제 와요", "배송이 너무 느려요", "아직도 안 왔어요" 같은 표현과 주문번호 확인에서 배송사 조회, 지연 사유 안내, 필요 시 CS 연결로 이어지는 처리 흐름이다.
3단계 SOP 작성: 패턴을 바탕으로 단계별 대응 흐름을 문서화하는데, 단순 안내인지 문제 해결인지에 따라 구조가 달라진다. "배송 조회 방법"과 "배송이 안 왔어요"는 같은 주제지만 챗봇이 다르게 대응해야 한다.
환불 확정이나 결제 취소처럼 챗봇이 혼자 처리할 수 없는 상황에서 언제 어떻게 사람에게 넘길지도 SOP에 포함된다.
4단계 분리: 만들어진 SOP와 분석 결과를 ALF가 읽을 수 있는 단위로 나눈다. 상담 토픽별로 상담사가 실제 답하던 방식을 "이 상황에선 이렇게 행동해라"로 바꾼 판단 기준, 배송사별 지연 안내 기준이나 환불 처리 절차 같은 참조 지식, 주문번호 조회나 배송 상태 확인처럼 API 연동이 필요한 동작으로 갈린다.
이 파일들이 ALF 등록 단위와 1:1로 대응해, 파이프라인이 끝나면 각 파일을 검토하고 올리면 된다.
효과 1 근거 있는 기대치: 막연한 "자동화가 됩니다"가 아니라 데이터에서 나온 숫자로 제시할 수 있다.
효과 2 규칙의 재료: 상담사가 토픽별로 어떻게 답변했는지가 SOP에 담기고 이것이 곧 챗봇 규칙의 재료가 된다. 빈 화면 앞에서 규칙을 쓰는 게 아니라 실제 상담 데이터에서 나온 초안을 다듬는 작업이 된다.