AI 고객문의 자동 분류 — 감정을 무시하라고 적어야 합니다

고객센터로 들어온 글을 읽고 어느 팀으로 넘길지 정하는 일. 예전엔 분류 모델을 따로 학습시키거나, 키워드 규칙을 수백 줄 쌓아 올렸습니다. 지금은 AI 고객문의 자동 분류를 프롬프트 한 장으로 붙입니다. 공식 안내서에 코드까지 통째로 나와 있고요.

그런데 그 안내서가 「이렇게 하면 틀린다」고 따로 뽑아 둔 함정이 셋 있습니다. 그중 하나는 처음 들으면 좀 웃깁니다 — 고객이 화를 내면 모델이 문제 대신 감정을 봅니다. 그리고 그 해법이 더 단순합니다.

📌 30초 요약

• 라벨 수십 개면 시작할 수 있습니다. 예전 방식은 대량의 학습 데이터가 필요했습니다.
• 「고객 감정은 전부 무시하라」를 프롬프트에 적으세요. 안 적으면 화난 글에서 의도를 놓칩니다.
• 범주가 20개를 넘으면 한 장으로 안 됩니다. 계단식으로 나누되, 지연이 늘어납니다.
• 예시를 골라 넣으면 71%가 93%가 됩니다. 안내서가 직접 든 숫자입니다.
• 판단 근거와 분류값을 따로 받으세요. 라우팅엔 분류값만, 근거는 사람이 볼 때만 씁니다.

① 언제 AI로 바꿀 만한가

이미 돌아가는 분류 장치가 있다면 굳이 바꿀 이유가 없습니다. 안내서는 갈아탈 만한 조건을 따로 나열해 두었는데, 정리하면 이렇습니다.

상황	예전 방식	AI로 바꾸면
쌓인 라벨이 적다	대량 학습 데이터 필요	수십 개로 시작
범주가 자주 바뀐다	바꿀 때마다 재라벨링	문장만 고치면 끝
규칙이 「조건」으로 정의된다	단어 매칭에 의존	조건을 읽고 적용
여러 언어가 섞인다	언어마다 따로 구축	하나로 처리
애매한 글이 많다	기타 범주로 몰림	맥락을 읽어 배분

특히 마지막 줄이 실무에서 크게 다가옵니다. 예전 방식은 애매한 글을 「기타」로 몰아넣고, 그 「기타」를 사람이 다시 열어 봐야 했습니다. 안내서는 이 사람이 손대야 하는 잔여분을 줄이는 것을 주요 효과로 꼽습니다.

모델은 가장 빠르고 값싼 것을 권합니다. 문의 하나하나에 붙는 작업이라 지연이 곧 체감이고, 판정에는 큰 모델이 필요 없기 때문입니다. 다만 전문 지식이 필요하거나 범주가 아주 많으면 한 단계 위로 올리라고 덧붙입니다. 값은 붙이기 전에 재 보실 수 있습니다(토큰 미리 세기).

② 감정을 무시하라고 적어야 합니다

안내서가 틀리는 경우를 셋 뽑아 두었습니다. 셋 다 처음 붙였을 때 반드시 만나는 것들입니다.

가. 고객이 돌려 말합니다

「2주째 기다리고 있는데요」는 불평처럼 보이지만 사실 주문 조회 요청입니다. 사람은 바로 알아듣는데 규칙 기반으로는 절대 안 잡힙니다. 해법은 이런 실제 문의를 예시로 넣고, 그 밑에 깔린 의도가 무엇인지까지 함께 적어 주는 것입니다. 판단 이유까지 붙이면 비슷한 다른 문의에도 그 논리가 옮겨 갑니다.

⚠️ 나. 감정을 의도보다 앞세웁니다 — 이게 가장 안 잡힙니다

고객이 불만을 강하게 드러내면, 모델이 문제를 푸는 쪽이 아니라 감정을 다루는 쪽으로 기웁니다. 화면을 덮는 광고 때문에 화가 나서 길게 쓴 글이 있다고 칩시다. 그 글의 진짜 용건이 「내 계정에 등록된 주소를 알려 달라」인데도, 불만 접수로 분류되어 엉뚱한 팀으로 넘어갑니다.

해법이 허무할 만큼 단순합니다. 안내서가 제시한 문장은 이겁니다 — 「고객의 감정은 전부 무시하라. 요청의 의도와 고객이 알고 싶어 하는 정보만 분석하라.」 이 한 줄을 프롬프트에 넣느냐 마느냐로 갈립니다.

다. 한 글에 용건이 여럿입니다

환불도 묻고 배송도 묻고 기능도 묻는 글에서 무엇이 주된 용건인지 모델이 헷갈립니다. 해법은 우선순위를 명시하는 것입니다 — 「환불 요청이 섞여 있으면 항상 환불로 분류하라」처럼요. 순위를 안 정해 주면 그때그때 달라집니다.

세 함정에 공통점이 있습니다. 전부 「사람이라면 당연히 아는 것」을 안 적어서 생깁니다. 분류 기준을 신입에게 넘긴다고 생각하고, 말로 설명하지 않으면 모를 것들을 전부 적어 넣으시면 됩니다.

③ 범주가 20개를 넘으면 한 장으로 안 됩니다

범주가 늘면 예시도 같이 늘어야 하고, 프롬프트가 감당 못 할 만큼 길어집니다. 안내서는 20개를 넘어가는 지점을 기준으로 제시하며 계단식 분류를 권합니다.

# 한 번에 30개 중 하나를 고르게 하지 말고, 두 번 나눠 묻는다

들어온 문의
   │
   ├─ 1차 분류 ─ 기술 문제 ─┬─ 하드웨어
   │                              ├─ 소프트웨어 결함
   │                              └─ 성능
   │
   ├─ 1차 분류 ─ 결제 문의 ─┬─ 환불
   │                              └─ 구독 변경
   │
   └─ 1차 분류 ─ 일반 문의 ─┬─ 사용법
                                  └─ 제품 정보

# 갈래마다 프롬프트를 따로 쓸 수 있어 더 정확해진다
# 대신 호출이 두 번 → 지연이 그만큼 늘어난다

장점은 분명합니다. 갈래마다 프롬프트를 따로 쓸 수 있어 「결제 문의」 안에서는 결제 맥락에 맞는 예시만 보여 줄 수 있습니다. 대신 대가가 있습니다 — 분류기를 여러 번 거치니 지연이 늘어납니다. 안내서가 이 방식을 권하면서 「가장 빠른 모델로 구현하라」고 못박은 이유가 여기 있습니다.

출력 형식도 챙기셔야 합니다. 안내서의 뼈대는 판단 근거와 분류값을 서로 다른 표시로 감싸 내보내게 합니다. 그래야 정규식으로 분류값만 따로 뽑아 라우팅에 쓰고, 근거는 사람이 확인할 때만 꺼내 볼 수 있습니다. 한 덩어리로 받으면 이 분리가 안 됩니다.

사소해 보이지만 놓치기 쉬운 것 하나 — 흐르듯 받는 방식을 끄고 쓰라고 예제가 명시합니다. 근거와 분류값이 전부 생성된 뒤에야 잘라낼 수 있기 때문입니다. 응답을 조각조각 받아서는 정규식을 걸 수 없습니다.

④ 71%를 93%로 — 예시를 고르는 법

안내서가 성능 개선에 가장 효과적인 방법으로 꼽는 건 예시를 넣는 것입니다. 그런데 문의가 워낙 다양하면 프롬프트 한 장에 충분한 예시를 담을 수 없습니다.

여기서 나오는 해법이 예시를 미리 다 넣지 말고, 들어온 문의와 닮은 것만 골라 넣는 것입니다. 예시를 벡터로 저장해 두고 유사도 검색으로 뽑아 씁니다. 그리고 안내서가 이 방식의 효과를 숫자로 밝혔습니다.

정확도
71% → 93%
닮은 예시만 골라 넣었을 때

22%포인트입니다. 프롬프트 문장을 다듬어서 이만큼 올리기는 어렵습니다. 다만 이 방식은 벡터 저장소와 임베딩이 따로 필요하니 구조가 한 겹 늘어납니다(임베딩 모델 고르기). 처음부터 이걸 깔지 말고, 예시를 넣어도 정확도가 안 오를 때 꺼내 드시면 됩니다.

그럼 「충분히 좋다」는 어디서 끊을까요. 안내서가 제시한 목표 숫자들이 있습니다.

무엇을	목표
같은 문의를 늘 같게 분류하나	95% 이상
새 범주에 적응하는 속도	50~100건이면 90% 이상
주력 아닌 언어에서의 하락폭	5~10% 이내
까다로운 사례 정확도	80% 이상
제목과 짧은 설명만 줬을 때	90% 이상
처음에 제대로 넘어가는 비율	90~95%
다시 넘겨야 하는 비율	10% 미만 (잘하면 5%)

세 번째 줄이 한국어 서비스에는 중요합니다. 주력 언어가 아닌 쪽에서 5~10% 떨어지는 건 정상 범위로 잡혀 있습니다. 안내서 예시가 전부 영어이니, 한국어 문의로 직접 재 보고 이 범위 안에 드는지 확인하시는 게 맞습니다.

다섯 번째 줄도 값과 직결됩니다. 제목과 짧은 설명만으로 90%가 나온다면, 본문 전체를 안 보내도 된다는 뜻입니다. 문의 본문이 긴 서비스일수록 이 차이가 청구서에 그대로 찍힙니다.

⑤ 자주 묻는 질문 (FAQ)

Q. 쓰던 분류 장치를 걷어내고 바꿔야 하나요?

한꺼번에 바꾸지 마세요. 안내서가 권하는 방식은 기존 방식과 같은 입출력 모양으로 감싸는 것입니다. 그러면 둘을 나란히 돌려 정확도와 값을 비교할 수 있고, 나빠지면 되돌리기도 쉽습니다.

Q. 문의 시스템과는 어떻게 잇나요?

두 갈래입니다. 밀어 주는 방식은 문의가 들어오는 순간 시스템이 우리 쪽을 호출합니다 — 규모를 키우기 좋지만 바깥에 열린 주소가 필요합니다. 당겨 오는 방식은 우리가 주기적으로 새 문의를 가져옵니다 — 만들기 쉽지만 주기가 짧으면 헛호출, 길면 느려집니다. 쓰시는 문의 시스템이 무엇을 제공하느냐로 갈리는 문제입니다.

Q. 검열 붙이는 것과 같은 이야기 아닌가요?

뼈대는 같은 분류 작업이지만 결정적인 차이가 하나 있습니다. 검열은 모델에 박힌 안전 동작이 프롬프트를 덮어써서 「이건 통과시켜라」가 안 먹힙니다. 문의 분류는 그런 제약이 없어 범주를 우리가 온전히 정합니다. 대신 검열은 틀려도 사람이 다시 보면 되지만, 문의 분류는 틀리면 고객이 기다립니다.

Q. 주말에 붙여 본다면 순서를 어떻게 잡을까요?

① 지난 문의 100건을 뽑아 정답 라벨을 답니다(까다로운 것 20건 포함). ② 범주는 다섯 개 이하로 시작하세요 — 늘리는 건 나중이 쉽습니다. ③ 프롬프트에 「감정은 무시하라」와 우선순위 규칙을 처음부터 넣으세요. ④ 정확도를 재고, 모자라면 예시를 늘리는 것부터 하세요. 벡터 검색은 그다음입니다. ⑤ 처음엔 자동 배정 대신 추천만 띄우고 상담원이 확인하게 하면, 실제 정확도가 저절로 쌓입니다.

✨ 정리

문의 자동 분류는 붙이는 데 하루, 다듬는 데 한 달인 종류의 일입니다. 처음 붙이면 대체로 잘 되는데, 안 되는 것들이 하나같이 「사람이면 당연히 아는데 안 적어서」 생깁니다. 화난 글에서 용건을 못 찾고, 용건이 여럿이면 헤매고, 돌려 말하면 놓칩니다. 그래서 「감정은 무시하라」 한 줄이 그렇게 큰 차이를 냅니다. 그리고 예시를 늘려도 안 오를 때가 오면, 그때 닮은 예시만 골라 넣는 방식을 꺼내시면 됩니다 — 71%가 93%가 되는 자리입니다.

더 읽을거리: AI 개발 비용·도구 총정리 허브

출처: Anthropic 공식 문서 「Ticket routing」 활용 안내서(platform.claude.com, 2026년 9월 확인). 예전 방식과의 비교 조건, 경계 사례 세 가지와 각 해법, 범주 20개 기준의 계단식 분류와 지연 대가, 유사도 검색 적용 시 71%→93%, 목표 숫자들(일관성 95%·적응 50~100건·다국어 하락 5~10%·까다로운 사례 80%·제목만 90%·재배정 10% 미만), 밀어 주는 방식과 당겨 오는 방식은 모두 해당 문서에 명시된 내용입니다. 다만 71%→93%는 문서가 인용한 별도 사례의 수치이며 작업 성격에 따라 달라집니다 — 필자가 재현한 결과가 아닙니다. 한국어 정확도에 관한 서술은 문서에 근거가 없어 「직접 재 보라」는 권고로만 적었습니다. 정책·모델 구성은 변동될 수 있으니 적용 전 공식 문서를 확인하세요.