“배송이 늦어서 환불받고 싶어요.” 이 문의를 배송으로 분류할까요, 환불로 분류할까요? 고객 문의 자동화에서 어려운 부분은 범주를 출력하는 일만이 아닙니다. 두 요구가 섞였을 때 무엇을 우선하고, 언제 사람이 확인할지 정해야 실제 업무에 연결할 수 있습니다.
긴 답변 대신 분류 결과만 받는 AI
Ollaya 공식 사이트는 텍스트나 JSON에 정해진 질문을 적용하고 선택값·점수 등을 받는 모델을 로컬에서 실행하는 도구를 소개합니다. Ollama나 TypeSafe와는 독립된 프로젝트라고 밝힙니다. 이름이 비슷하다는 이유로 같은 제품이라고 소개하면 안 됩니다.
사이트의 속도와 정확도 수치는 특정 모델·장비·평가 조건에서 나온 제공자 측 자료입니다. 여기서는 그 수치를 한국어 문의의 성능으로 옮겨 쓰지 않습니다. 도구를 직접 설치하거나 한국어 성능 실험을 한 후기도 아닙니다. 아래는 로컬 분류 도구를 업무에 적용하기 전에 구성할 수 있는 자체 설계 예시입니다.
먼저 분류가 결정하는 범위를 좁힙니다
첫 단계의 목표를 ‘담당 큐 추천’으로 정해 보겠습니다. 환불 요청을 환불 담당자에게 전달하는 판단과 실제 환불 승인은 다릅니다. 분류기는 후속 담당자를 추천하고, 실제 처리는 별도의 업무 규칙에 맡깁니다.
예시 범주는 환불, 배송, 영수증, 기타, 검토 필요입니다. 이 중 ‘검토 필요’는 오류를 숨기는 칸이 아니라, 의도가 불명확하거나 여러 요청이 섞인 사례를 확인할 경로입니다. 실제 업무에서 복수 범주를 허용한다면 다중 라벨 방식도 검토할 수 있습니다.
한국어 예시 여덟 개로 기준을 드러내세요
아래 정답은 모델 출력이 아니라 사람이 먼저 정한 예시 규칙입니다. 이 글에서는 ‘환불 의사가 명확하면 환불’, ‘질문만으로 의미가 결정되지 않으면 검토 필요’를 적용합니다. 다른 조직에서는 다른 우선순위를 택할 수 있습니다.
| 예시 문의 | 기대 분류 | 이유 |
| 결제한 금액을 돌려받고 싶어요 | 환불 | 환불 요청 명시 |
| 택배가 어디까지 왔나요? | 배송 | 배송 위치 질문 |
| 지난달 결제 영수증을 보내주세요 | 영수증 | 증빙 발급 요청 |
| 배송이 늦어서 환불하고 싶어요 | 환불 | 배송 불만보다 명시적 환불 의사 우선 |
| 환불 말고 언제 도착하는지만 알려주세요 | 배송 | 환불 의사를 부정함 |
| 저번처럼 처리해 주세요 | 검토 필요 | 이전 맥락이 없음 |
| 영수증도 필요하고 주소도 바꿔야 해요 | 검토 필요 | 서로 다른 두 요청 |
| 오늘도 수고하세요 | 기타 | 처리할 요청 없음 |
‘환불’이라는 단어가 있다고 무조건 환불로 보내면 다섯 번째 사례를 틀립니다. 처음부터 예시를 정해두면 모델 선택 전에 범주 자체가 모호한지 확인할 수 있습니다. 여덟 개는 설계 점검의 출발점이며 운영 성능을 평가하기에 충분한 표본은 아닙니다.
정확도와 자동 처리 범위를 함께 읽습니다
가상의 문의 100개를 분류했다고 가정하겠습니다. ‘자동 전달’은 담당 큐로 보내는 동작만 뜻하며 금전 처리나 계정 변경을 포함하지 않습니다. 아래 숫자는 실제 모델 측정값이 아닙니다.
| 가상 운영 기준 | 자동 전달 | 그중 올바른 전달 | 잘못된 전달 | 사람 검토 |
| 넓게 자동 전달 | 70건 | 63건 | 7건 | 30건 |
| 더 엄격하게 선별 | 50건 | 48건 | 2건 | 50건 |
첫 기준의 자동 전달 범위는 전체의 70%이고, 자동 전달한 사례 안의 정답률은 63÷70=90%입니다. 두 번째는 범위 50%, 정답률 48÷50=96%입니다. 더 높은 정답률을 얻었지만 사람에게 넘어가는 양도 늘었습니다. 따라서 90%와 96%만 보고 어떤 방식이 더 낫다고 결론 내릴 수 없습니다.
사람이 검토한 30건 또는 50건의 결과는 표에 포함하지 않았습니다. 이 수치를 전체 시스템 정확도라고 부르지 않는 이유입니다. 오류 비용과 검토 시간을 함께 비교해야 합니다.
점수 0.9를 자동 승인 규칙으로 쓰기 전에
모델이 0.9를 출력해도 해당 업무에서 항상 90% 정답을 보장하는 것은 아닙니다. 실제 한국어 문의에서 점수대별 오류를 확인해야 합니다. 어떤 점수부터 자동 전달할지는 사람의 판정과 비교한 별도 데이터로 정합니다.
범주 정의를 만드는 데 사용한 예시와 최종 평가용 사례도 구분하세요. 익숙한 예시만 계속 고치면 처음 보는 표현에 약한 점을 놓칠 수 있습니다. 출시 후에는 부정 표현, 복합 요청, 짧은 문장 등 어떤 유형에서 잘못 분류되는지 기록합니다.
도입 전에 작성할 짧은 설계서
목적: 고객 문의의 담당 큐를 추천한다.
범주: 환불 / 배송 / 영수증 / 기타 / 검토 필요.
우선순위: 명시적 환불 요청을 우선하되, 환불 부정 표현은 구별한다.
보류: 이전 맥락 누락 또는 서로 다른 요청이 섞이면 사람이 검토한다.
평가: 범주별 오류, 자동 전달 비율, 검토 소요 시간을 함께 기록한다.
범위: 분류만 수행하며 환불 승인·계정 변경은 실행하지 않는다.기록에는 모델과 버전, 범주 설명, 평가 날짜도 남깁니다. 같은 모델이라도 범주 문구가 바뀌면 결과가 달라질 수 있어 비교 조건을 유지하는 편이 좋습니다.
자주 묻는 질문
로컬이면 비용이 없나요? 외부 호출 요금과 별개로 장비·전력·운영 비용이 있습니다. 유지에 드는 시간도 비교해야 합니다.
한국어도 잘 분류하나요? 이 글에서는 직접 측정하지 않았습니다. 실제 업무와 비슷한 한국어 사례를 따로 평가해야 합니다.
모든 문의를 자동화해야 하나요? 반드시 그럴 필요는 없습니다. 판단이 명확한 범주부터 추천 용도로 적용하고, 애매한 입력을 검토하는 경로를 유지할 수 있습니다.
참고 자료
확인일: 2026년 9월 29일. 제품 설명은 공개 문서 기준이며, 문의 예시와 100건 계산표는 자체 구성한 가상 사례입니다.