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

안녕하세요, 채널톡 AX팀의 Pete입니다.

여러 고객사의 ALF 도입에 함께 들어가면서 공통된 패턴을 발견했습니다. 가장 시간이 오래 걸리는 구간이 세팅이 아니라, 세팅 전 단계라는 것이었습니다.

ALF에 필요한 자료를 세팅하는 건 생각보다 빠릅니다. 오래 걸리는 건 그 전 단계입니다. 고객사의 상담이 어떤 유형으로 이루어져 있는지, 각 유형에서 어떤 흐름으로 처리되는지, AI가 어떤 상황에서 어떻게 판단해야 하는지—이걸 함께 정의하는 과정이 ALF 도입의 시작이고, 대부분의 시간이 여기서 쓰입니다.

상담 프로세스를 처음부터 언어로 정의하는 건 생각보다 어렵습니다. 오랫동안 암묵적으로 처리해온 것들을 꺼내서 문서로 만드는 작업이기 때문입니다.

그 과정을 자동화했습니다.

기존 방식의 한계

이전에도 데이터 분석은 했습니다. 고객사에게 상담 데이터를 받으면 어떤 유형이 몇 %를 차지하는지 뽑아서 보여줬습니다.

문제는 두 가지였습니다.

1. 결과가 일관되지 않았습니다. AI에게 분류를 맡기면 같은 데이터를 넣어도 매번 다른 결과가 나왔습니다. 중간에 사람이 계속 붙어서 AI와 인터렉션해야 했고, 자동화라고 부르기 어려웠습니다.

2. 숫자만 나오고 SOP는 못 뽑았습니다. "배송 문의가 23%"라는 정보는 있었지만, 챗봇이 배송 문의에 어떻게 대응해야 하는지는 여전히 사람이 정리해야 했습니다. 결국 도입 계획이 "이 유형은 자동화 가능하다/없다" 수준에서 멈췄습니다. ALF가 실제로 어떤 지식을 가져야 하는지, 어떤 상황에서 어떻게 동작해야 하는지는 탐색조차 못 했습니다.

이번에 바꾼 건 두 가지입니다. 분류는 임베딩 + 클러스터링 스크립트로 처리해서 재현성을 확보했습니다. AI 동작은 Agent SOP 문서(RFC 2119 키워드로 명시된 구조화된 지시문)로 제어해서, 중간 인터렉션 없이 파이프라인이 끝까지 완주합니다. (물론, 지금은 설정으로 제어합니다.)

상담 데이터가 있다면, ALF 세팅 초안이 만들어집니다

파이프라인은 상담 데이터를 받아서 SOP를 만들고, 그 SOP를 ALF에 바로 올릴 수 있는 세팅 파일로 분리합니다.

SOP가 나오면, ALF 세팅의 방향도 나옵니다

어떤 식으로 흘러가는지 보여드립니다

이커머스 고객사를 예로 들겠습니다. 상담 데이터 1,000건을 파이프라인에 넣으면 이런 흐름으로 진행됩니다.

1단계 — 상담 유형 자동 분류

임베딩과 클러스터링으로 상담을 유형별로 묶습니다. 라벨은 AI가 샘플을 직접 읽고 붙입니다.

클러스터 1 (23%) — 배송 지연 문의
클러스터 2 (18%) — 주문 취소/환불 요청
클러스터 3 (15%) — 결제 오류 및 이중결제
클러스터 4 (12%) — 포인트/쿠폰 적용 문의
클러스터 5 (9%)  — 앱 로그인/계정 오류
...

2단계 — 패턴과 FAQ 추출

각 클러스터에서 실제 고객 표현, 빈출 패턴, 상담사 해결 방식을 뽑습니다.

[배송 지연 문의] 주요 고객 표현:
- "언제 와요?", "배송이 너무 느려요", "아직도 안 왔어요"
[해결 패턴]:
- 주문번호 확인 → 배송사 조회 → 지연 사유 안내 → 필요 시 CS 연결

3단계 — SOP 문서 생성

패턴을 바탕으로 단계별 대응 흐름을 문서화합니다. "단순 안내"인지 "문제 해결"인지에 따라 구조가 달라집니다. "배송 조회 방법"과 "배송이 안 왔어요"는 같은 배송 주제지만 챗봇이 다르게 대응해야 합니다.

챗봇이 혼자 처리할 수 없는 상황—환불 확정, 결제 취소 등—에서 언제, 어떻게 사람에게 넘길지도 SOP에 포함됩니다.

4단계 — ALF 세팅 파일로 분리

만들어진 SOP와 분석 결과를 ALF가 읽을 수 있는 단위로 나눕니다.

• 규칙 파일: 챗봇 판단 기준 — 상담 토픽별로 상담사가 실제로 답하던 방식을 기반으로 "이 상황에선 이렇게 행동해라"로 변환

• RAG 문서: 챗봇이 참조할 지식 — SOP 안의 해결 방식에서 "배송사별 지연 안내 기준", "환불 처리 절차" 같은 문서로 변환

• 태스크 초안: 주문번호 조회, 배송 상태 확인 등 API 연동이 필요한 동작

이 파일들이 ALF 등록 단위와 1:1로 대응합니다. 파이프라인이 끝나면 각 파일을 검토하고 ALF에 올리면 됩니다

SOP가 가능하게 한 것

SOP가 생기면서 기존에 못 했던 것들이 됩니다.

ALF 도입의 가치를 수치로 보여줄 수 있습니다.

상담 유형별 비중과 SOP 커버 가능 범위를 합치면, 도입 전에 "이 ALF가 월 X건을 처리할 수 있다"는 기대치를 근거 있게 제시할 수 있습니다. 막연한 "자동화가 됩니다"가 아니라, 데이터에서 나온 숫자입니다.

1. 상담사가 응대하는 방법 = 규칙(프롬프트)이 나옵니다.

   상담사가 토픽별로 어떻게 답변했는지가 SOP에 담깁니다. 이게 곧 챗봇이 같은 상황에서 어떻게 동작해야 하는지를 정의하는 규칙의 재료가 됩니다. 처음부터 빈 화면 앞에서 규칙을 쓰는 게 아니라, 실제 상담 데이터에서 나온 초안을 다듬는 작업이 됩니다.

2. 상담사가 참고하는 문서 = 지식(RAG)이 나옵니다.

   SOP 안의 해결 절차와 안내 내용이 RAG 문서의 뼈대가 됩니다. 챗봇이 참조해야 할 정보를 처음부터 작성하는 대신, 이미 상담사들이 쓰던 내용을 문서 형태로 정리하는 과정이 됩니다.

3. 상담 흐름이 ALF 대화 유형으로 자동 분류됩니다.

   ALF는 챗봇 동작을 7가지 대화 유형으로 구분합니다. 지식응답, 정보조회, 단순실행, 정책확인, 조건부실행, 의도불명확, 상담사전환. SOP가 생기면 각 상담 흐름이 이 유형 중 어디에 해당하는지 자동으로 매핑됩니다.

"배송 조회 방법"은 지식응답, "반품 가능 여부 확인"은 정책확인→조건부실행, "AS 접수"는 정보조회→단순실행으로 이어지는 식입니다. ALF를 어떻게 설계해야 하는지의 답이 SOP에서 자연스럽게 나옵니다.

"해결율"보다 "시간 절감"이 더 설득력 있었습니다.

초기엔 "이 ALF가 전체 상담의 X%를 해결할 수 있다"는 방식으로 가치를 제시했습니다. 문제는 "해결"의 기준이 사람마다 다르다는 것이었습니다. 완전 자동 처리인지, 상담사가 조금이라도 개입하면 해결이 아닌 건지.

지표를 바꿨습니다. "이 유형 1건 처리에 걸리는 평균 시간 × 월 발생 건수". 상담사가 이미 알고 있는 숫자입니다. 그 숫자를 데이터에서 나온 건수와 곱하면 실제로 얼마의 시간이 줄어드는지가 나옵니다. 추상적인 자동화율보다 현실감 있는 숫자였습니다.

AI 서비스 도입의 첫 단계를 낮추다

AI 기반 서비스 도입에서 가장 어려운 구간은 처음입니다. 무엇을 알려줘야 하는지, 어떤 상황에서 어떻게 동작해야 하는지—이걸 처음부터 정의하는 건 막막합니다. 보통 이 구간에서 수 일이 걸립니다.

이 파이프라인은 그 초벌 단계를 담당합니다. 완성된 세팅을 만들어주는 게 아닙니다. 데이터에서 뽑아낸 초안을 제공해서, 팀이 "맞다/틀리다"를 판단하고 다듬는 작업부터 시작할 수 있게 합니다. 빈 화면 앞에서 시작하는 것과, 초안을 보면서 시작하는 것은 다릅니다.

상담 규모가 작은 고객사라면 이 초안 그대로 ALF를 먼저 세팅해보고 실제 커버 가능한 범위를 확인한 다음 도입 여부를 결정할 수 있습니다. 회의 없이, 데이터를 넣고 결과를 보면서 판단하는 방식입니다.

만들면서 틀린 것들

이 파이프라인을 처음부터 이렇게 만든 건 아닙니다.

• 알고리즘은 숫자가 아니라 목적으로 골라야 합니다

  클러스터링 알고리즘을 고를 때 K-Means와 HDBSCAN을 비교했습니다. 수치상으로는 HDBSCAN이 압도적이었습니다. Silhouette Score 0.433 vs 0.045.

  그런데 결과를 보니 전체 상담의 89.7%가 클러스터 하나에 몰려 있었습니다. 단일 도메인 서비스는 상담 주제가 좁게 집중되어 있어서, HDBSCAN 입장에선 전부 하나의 밀집된 덩어리로 보인 것입니다. 이 결과로는 SOP를 만들 수 없습니다.

  알고리즘을 평가하는 기준을 "수치"가 아니라 "이걸로 SOP를 쓸 수 있냐"로 잡은 순간 선택이 명확해졌습니다.

• 카테고리를 고정하면 "기타"가 넘쳐납니다

  초기엔 구매/배송/AS/취소/견적으로 카테고리를 하드코딩했습니다. 단일 도메인 버티컬 서비스 데이터를 넣었더니 57%가 "기타"로 분류됐습니다. 카테고리를 없애고 에이전트가 샘플을 보고 업종에 맞는 카테고리를 직접 만들도록 했더니 "기타" 비율이 0%가 됐습니다.

• "추측하지 마"를 말로 하면 안 됩니다

  프롬프트에 "클러스터 라벨만 보고 추측하지 말고 실제 샘플을 봐"라고 써도 불안정했습니다. 결국 구조를 바꿨습니다. 샘플 추출 스크립트가 먼저 실행되고, 그 결과물을 LLM이 받도록. 말로 부탁하지 않고 시스템이 강제하게 했습니다.

• 클러스터당 샘플이 15개면 패턴을 못 잡습니다

  K=20으로 설정했을 때 클러스터당 샘플을 300÷20 = 15개만 추출했습니다. 15개 대화에서 패턴을 뽑으면 결과가 빈약합니다. SOP의 "고객 표현" 섹션에 2~3가지밖에 안 나오고, 해결 흐름 기술이 피상적으로 끝납니다.

  수식을 바꿨습니다: max(20, ceil(300 / K)). K가 얼마든 전체적으로 최소 300개 샘플이 분석되도록 하단을 고정했습니다. 패턴 추출 결과가 눈에 띄게 풍부해졌습니다.

• 규칙 초안은 형식이 맞아야 쓸 수 있습니다

  처음 뽑힌 규칙 초안은 내용은 있는데 형식이 맞지 않았습니다. ALF에 올릴 때 담당자가 처음부터 다시 써야 하는 수준이었습니다. CSM 팀이 실제로 사용하는 규칙 레퍼런스 문서가 따로 있었고, 그 형식에 맞춰 템플릿을 재구성했습니다. 이제 초안이 나오면 다시 쓰는 게 아니라 수정 작업의 출발점으로 쓸 수 있습니다.

마치며

ALF 도입이 어려운 이유는 AI 기술이 어렵기 때문이 아닙니다. 챗봇에게 무엇을 가르쳐야 하는지를 정의하는 것이 어렵기 때문입니다. 그 정의를 처음부터 만들려고 하면 막막합니다. 회의가 길어지고, 결론이 추상적으로 흐릅니다.

그런데 상담 데이터를 보면 그 정의가 이미 거기 있습니다. 상담사들이 수천 건의 문의를 처리하면서 쌓아온 판단 기준, 해결 흐름, 고객이 쓰는 말들. 정리되지 않았을 뿐, 데이터 안에 있습니다.

이 프로젝트는 여러 동료들의 고민들의 집합에서 시작됐습니다.

• "ALF를 빠르게 세팅할 수 있는 초안이 필요하다."

• "고객의 SOP가 잘 정의되어 있다면 도입이 훨씬 쉬울 텐데."

• "상담 데이터 자체가 상담을 문서화할 수 있는 좋은 소스 아닐까?"

각자의 자리에서 나온 아이디어와 가설들을 하나로 모아서 실제로 만들어보는 역할에 가까웠습니다. 그 과정에서 여러 사람의 고민을 안고 간다는 책임감이 있었고, 그게 계속 진행할 수 있는 동력이 됐습니다.

글을 쓰고 회고하다 보니 이런 생각이 듭니다. 고민과 아이디어를 머릿속에만 두지 않고 꺼내서 공유하는 것, 그 자체가 효율화를 만드는 일이 아닐까 하고요. 앞으로도 이런 고민들을 밖으로 가져와 AI와 함께 더 많은 것들을 만들어볼 생각입니다.