프론티어 모델 대신, 우리 모델이 모든 상담을 분석합니다

안녕하세요, 채널 AI팀 ML Engineer 새미(LinkedIn)입니다.

채널에서는 매일 수많은 상담이 오가고, 저희는 이렇게 발생하는 모든 상담을 AI로 분석합니다. 상담마다 고객이 정말 물어본 것을 뽑고(핵심 이슈 추출), 비슷한 상담끼리 묶고(토픽 배정), 상담이 잘 됐는지 평가합니다(상담 평가). 이 세 가지 작업은 그동안 상용 LLM으로 돌아가고 있었습니다.

최근 이 세 작업을 직접 학습한 모델 하나로 옮겼습니다. 결과부터 말씀드리면, 상용 LLM 대비 비용은 99.4% 줄었고, 성능은 세 작업 모두 상용 LLM보다 좋아졌습니다. 이 글에서는 왜 자체 모델이 필요했는지, 그리고 그 과정에서 어떤 문제를 마주했는지를 소개해보려 합니다. 저는 이번 프로젝트에서 데이터 구축부터 학습, 평가, 배포와 운영까지 전 과정을 맡았고, 서빙과 운영 안정성은 같은 팀 ML Engineer 카오루와 함께했습니다.

결과부터

세 작업 모두 상용 LLM을 넘었고, 비용은 99.4% 줄어 1년에 약 6억 원을 아끼고 있습니다.

※ 99.4%는 전환 전후 한 주의 상용 LLM API 비용을 실측해 비교한 값입니다. 연간 약 6억 원은 여기서 자체 GPU 비용을 뺀 주간 순절감액을 1년으로 환산한 보수적 추정치입니다.

모든 상담을 AI가 읽게 된 이유

상담이 잘 되고 있는지 알려면 먼저 매일 쌓이는 수많은 상담을 평가할 수 있어야 했습니다.

처음에는 고객의 설문을 받아요

처음에는 상담이 끝나면 고객에게 만족도 설문인 CSAT(Customer Satisfaction Score)을 받습니다. 문제는 세 가지였습니다.

• 대부분 답하지 않습니다. 응답률이 낮아 점수가 남는 상담은 전체의 일부뿐입니다.

• 극단적인 분들만 답합니다. 매우 부정적인 경험을 했거나, 매우 긍정적인 경험을 한 분들입니다.

• 기준이 사람마다 다릅니다. 같은 상담에도 누구는 5점, 누구는 3점을 줍니다.

숫자는 있지만 무엇을 고칠지 정하기엔 모호한 정보였습니다. 채널의 AI 상담원 ALF를 쓰는 고객사가 늘면서 "우리 AI 상담이 잘하고 있나?"를 확인하려면 대화를 하나씩 열어봐야 하는 문제도 있었습니다.

그래서 AI가 모든 상담을 읽고 평가합니다

고객에게 묻는 대신 AI가 대화 기록을 직접 읽고 평가하게 했습니다. 이것이 CX Score입니다. 종료된 상담을 100% 평가하고, ALF와 사람 상담원도 같은 기준으로 봅니다.

평가 항목은 CX팀과 함께 공감 및 배려, 고객 노력도, 고객 감정, 응대 정확도(ALF), 응대 품질(사람) 다섯 가지로 정리했습니다. AI는 항목별 판정까지만 하고, 최종 점수는 정해진 수식으로 계산해 같은 상담은 항상 같은 점수를 받습니다. 판단 근거가 없는 항목은 Neutral(중립)로 두고, 최종 점수를 계산할 때는 뺍니다.

점수만으로는 무엇을 고칠지 모른다

점수가 생기자 "그래서 뭘 고쳐야 하죠?"라는 질문이 나왔습니다. 수백만 건의 상담이 각자 점수만 달고 흩어져 있으면 손을 댈 수 없기 때문입니다. 그래서 비슷한 상담끼리 토픽으로 묶었습니다. 사람이 붙이는 태그는 제각각이고 미리 정한 목록 밖의 새 이슈를 잡지 못해, 분류를 대화에서 직접 끌어올렸습니다.

1. 핵심 이슈 추출: 고객이 정말 물어본 것을 뽑습니다. "택배가 안 움직여요"와 "신발이 아직 안 왔어요"는 같은 "배송 상태 확인"이 됩니다.

2. 토픽 배정: 뽑은 이슈를 토픽에 배정합니다. 맞는 토픽이 없으면 미분류로 두었다가, 반복되는 패턴이 확인될 때 새 토픽을 만듭니다.

3. CX Score와 결합: 상담은 많은데 점수가 낮은 토픽이 바로 보이니 우선순위를 정할 수 있습니다.

정리하면, 상담 하나마다 핵심 이슈 추출, 토픽 배정, 상담 평가라는 세 가지 LLM 작업이 돌아가는 구조입니다.

자체 모델을 만든 이유

이 구조는 "모든 상담을 빠짐없이 읽는다"는 전제 위에서만 돌아갑니다. 모든 고객사의 상담이 분석 대상이고, 대화는 길고, 상담 하나마다 세 가지 작업이 돌고, API 가격은 계속 오르고 있었습니다. 비용 절감은 선택이 아니라 필수였습니다.

그래서 자체 모델을 만들기로 했습니다. 모든 작업을 한 번에 옮길 수는 없었기에, 여러 LLM 작업 중 트래픽이 가장 많아 ROI(투자수익률)가 가장 크게 나오는 세 작업부터 시작했습니다. 그런데 팀에는 오픈 모델을 직접 학습하고, 평가하고, 운영해 본 경험이 없었습니다. "프론티어 모델 대비 자체 모델을 운영하는 게 정말 이점이 있을까?"를 계속 의심했습니다. 보통 작은 모델은 비용이 적게 들지만 서툴고, 큰 상용 모델은 잘하지만 비싸기 때문입니다.

상담 분석 결과는 상담 품질 관리와 운영 의사결정에 쓰이기 때문에, 비용을 아낄 수 있다는 이유만으로 바꿀 수도 없었습니다. 그래서 전환 조건을 "세 작업 모두 상용 LLM보다 좋을 것"으로 잡았습니다. 목표는 비용은 아끼면서, 지금보다 더 잘하는 작은 모델이었습니다.

정답이 없는 문제를, 채점 가능한 문제로

학습보다 먼저 부딪힌 벽은 평가였습니다. 세 작업 모두 정답이 하나로 정해지지 않는 문제라, 처음에는 이런 질문에도 답할 수 없었습니다.

• 무엇이 좋은 핵심 이슈이고, 무엇이 좋은 토픽일까?

• 모델이 좋아졌다는 걸, 무엇을 기준으로 믿을 수 있을까?

• 학습 데이터는 어떻게 정의하고, 긴 상담과 성격이 다른 고객사는 어떻게 다뤄야 할까?

평가 기준이 흔들리면 그 위에서 한 모든 실험이 의미를 잃습니다. 그래서 학습에 앞서 평가 기준과 데이터 기준부터 세웠습니다.

1. 무엇이 좋은 핵심 이슈이고, 무엇이 좋은 토픽일까?

좋은 상담, 좋은 핵심 이슈, 좋은 토픽은 모두 정성적인 기준입니다. 중요한 건 모델이 평균적으로 높은 점수를 주는 게 아니라, CX팀이 실제로 중요하게 생각하는 기준을 얼마나 일관되게 재현하느냐였습니다. 그래서 CX팀과 함께 기준을 항목 단위로 쪼개, 항목별 평가 기준표인 Rubric을 만들었습니다.

예를 들어 좋은 핵심 이슈는 단순히 자연스러운 문장이 아니라, Downstream Task에 유용한, 즉 토픽으로 묶기 좋은 문장이어야 합니다. 좋은 토픽은 서로 겹치지 않으면서 묶인 상담을 보고 무엇을 고칠지 알 수 있는 단위여야 합니다.

• 자연스럽지만 묶기 어려운 이슈: "택배 언제 와요? 너무 늦네요ㅠ"

• 토픽으로 묶기 좋은 이슈: "배송 지연 문의"

※ 실제 데이터가 아닌 예시입니다.

2. 모델이 좋아졌다는 걸, 무엇을 기준으로 믿을 수 있을까?

모델이 학습됐을 때 정말 개선됐는지 알려면 정답지가 필요합니다. 상용 LLM보다 높은 점수를 줘도, 그게 CX팀이 정의한 기준과 맞지 않을 수 있기 때문입니다. CX팀의 기준과 잘 맞는(align된) 골든셋을 만드는 것 자체도 큰 고민이었습니다. 그렇게 만든 약 1만 2천 건(12k)의 골든셋은 학습 데이터와 완전히 분리해, 모델이 정말 좋아졌는지를 확인하는 데만 사용했습니다.

작업에 맞는 지표 고르기

• 핵심 이슈 추출, 토픽 배정 → Win Rate. 문장을 만들거나 토픽을 고르는 작업은 정답이 하나로 정해지지 않아서, 상용 LLM의 결과와 나란히 비교하는 Win Rate를 택했습니다. Judge는 앞서 만든 Rubric을 기준으로, 핵심 이슈는 downstream task(토픽 배정)에 유용한지, 토픽은 고객의 의도에 맞게 배정됐는지를 비교합니다. 또 teacher 및 비교 대상과 다른 계열의 모델을 Judge로 써서, 자기 계열의 답을 더 좋게 평가하는 Self-preference Bias[1]를 없앴습니다.

• 상담 평가 → QWK[2]. 판정이 순서가 있는 등급이라, 한 칸 틀린 것과 네 칸 틀린 것을 다르게 봐야 합니다. QWK는 이 차이까지 반영해 골든셋과의 일치도를 측정합니다. QWK를 계산할 때는 판단 근거가 없는 neutral을 5단계의 가운데인 3점으로 두었습니다.

3. 학습 데이터는 어떻게 정의하고, 긴 상담과 성격이 다른 고객사는 어떻게 다뤄야 할까?

어떤 상담은 매우 길고, 하나의 프롬프트에 여러 상담을 넣어 한 번에 답하게 하는 Batch Prompting을 쓰기도 합니다. 고객사마다 업종도, 자주 나오는 토픽도 다릅니다. 데이터를 어떻게 정의하고 구성할지부터가 쉽지 않은 문제였습니다.

작은 모델로, 상용 LLM보다 더 잘하기

평가 기준이 생긴 뒤에는 더 어려운 문제가 남았습니다. 보통 모델을 작게 만들면 비용은 줄지만 품질도 함께 떨어집니다. 저희는 반대로, 작게 만들면서 상용 LLM보다 잘하게 만들어야 했습니다. 이 과정에서 세 가지 벽을 만났습니다.

1. Distillation의 역설

가장 먼저 떠올린 방법은 Knowledge Distillation[3][4]이었습니다. 큰 모델(Teacher)이 만든 답을 작은 모델(Student)이 따라 배우게 하는 방법으로, 여기서는 프론티어 모델을 Teacher로 두었습니다. 그런데 이렇게 만든 데이터를 전부 학습하면 오히려 성능이 떨어졌습니다. Teacher의 출력 분포와 Student가 실제로 다루는 데이터의 분포가 어긋나는 Distribution Shift 문제였습니다.

그래서 질문을 바꿨습니다. "어떤 데이터가 student에게 학습 가치가 있을까?" 생성한 데이터를 그대로 쓸 수는 없었고, 어떤 데이터를 더해야 하는지, 어떻게 균형을 맞춰야 하는지, 어떤 기준을 충족해야 하는지 모두 답이 정해져 있지 않았습니다. 이 질문에 답을 찾는 데 많은 실험이 들었습니다.

2. 세 작업을 하나의 모델에 담기

작업마다 모델을 따로 학습하는 Single-task 방식으로 distillation하자, 세 작업 모두 좋은 성능이 나왔습니다. 작업별 모델을 서빙하는 방법으로는, 작업마다 LoRA(Low-Rank Adaptation)[5] adapter를 두고 한 서버에서 바꿔 끼우는 Multi-LoRA[6] 방식도 고려했습니다. 하지만 서빙까지 생각하면, 세 작업을 하나의 모델로 처리하는 Multi-task 단일 모델이 훨씬 유리했습니다. 같은 환경에서 직접 실측해 본 결과입니다.

Multi-LoRA는 같은 batch 안에서도 요청마다 다른 adapter를 적용해야 해서 추가 비용이 생기고, 실제로 요청 queue가 쌓였습니다. 하나의 모델로 처리하면 TTFT는 약 10배(p95 기준 약 16배) 빨라지고, throughput은 54.4% 높아졌습니다. 작업별로 모델을 따로 운영할 때와 비교하면, 필요한 인스턴스도 절반으로 줄었습니다. 결국 인프라 비용과 서빙 성능을 모두 고려하면, 하나의 모델이어야 했습니다.

그래서 세 작업을 하나의 모델에 담기로 했습니다. 문제는 합칠 때였습니다.

세 작업의 데이터를 단순히 섞어 한 번에 학습하는 Joint Training을 하자 성능이 크게 망가졌습니다. 두 작업만 합쳐도 핵심 이슈 추출이 93.4%에서 85%로 떨어졌고, 세 작업을 모두 합치자 토픽 배정은 52%, 상담 평가는 0.703까지 내려갔습니다. 상용 LLM과 비기는 수준(50%, 0.702)까지 돌아간 셈이라, "세 작업 모두 상용 LLM보다 좋을 것"이라는 전환 조건을 지키지 못할 뻔했습니다. 출력의 모양도 목표도 다른 작업들이, 모델을 업데이트하려는 방향이 서로 부딪히는 Gradient Conflict[7]로 간섭한 것으로 보입니다.

작업별 모델로 돌아가는 쉬운 길도 있었지만, 인프라 비용과 서빙 성능을 고려하면 하나의 모델을 포기할 수 없었습니다. 한 번에 풀리는 문제는 아니었습니다. 여러 번의 실험 끝에 Multi-Task 학습을 다듬은 결과, 하나의 모델로 핵심 이슈 추출과 상담 평가는 Single-Task에 가까운 성능을 되찾았고, 토픽 배정은 오히려 Single-Task(68%)를 넘어 72.9%까지 올랐습니다. 성능은 잘 유지하면서, 서빙 효율은 크게 좋아졌습니다.

3. 하나를 고치면 다른 하나가 틀린다

토픽 배정에서는 까다로운 현상이 하나 더 있었습니다. 학습할 때마다 새로 맞히게 되는 케이스(Acquisition)와, 원래 맞히던 걸 틀리게 되는 케이스(Regression)가 동시에 생긴 겁니다. 전체 점수만 봐서는 드러나지 않는 문제였습니다.

모델이 판단을 가르는 경계인 Decision Boundary를 건드리면, 한 쪽을 고칠수록 다른 쪽이 흔들렸습니다. 이미 잘 맞히던 판단은 지키면서, 사람도 헷갈릴 만한 경계 근처의 케이스만 바꿔야 하는 쉽지 않은 문제였습니다.

전 고객사 배포, 그리고 모델 업데이트

현재 이 모델은 전 고객사에 배포되어, 이미 한 달 넘게 모든 상담을 분석하고 있습니다.

숫자 밖에서 확인한 차이

Win Rate와 QWK가 "얼마나" 나아졌는지를 보여준다면, 실제 판정을 들여다보면 "어떻게" 다르게 판단하는지가 보입니다. 배포 후 두 모델의 판정을 비교하며 여러 차이를 확인했는데, 그중 하나를 소개합니다.

전 고객사에 배포한 뒤, 일부 고객사에서 neutral 판정이 크게 늘어난 것을 발견했습니다. 모델이 판단을 피하는 것처럼 보여 되돌릴 수도 있었지만, 오프라인 평가에서 확인한 성능을 믿었기에 원인 분석부터 했습니다. neutral이 늘어난 고객사 중 6곳을 분석해 보니 반대였습니다. 자체 모델이 Rubric의 판단 근거 유무를 상용 LLM보다 더 정확하게 적용하고 있었습니다. 기본 Rubric도 판단할 충분한 근거가 없으면 neutral로 평가하도록 정의되어 있습니다.

• 사례 1/ 보험 상담. 상담이 Rubric에서 정의한 단계(전자청약 링크 전송, 체결 지원)까지 도달하지 않았습니다. 자체 모델은 판단할 근거가 없다며 neutral을, 상용 LLM은 해당 행동이 없었다는 이유로 negative를 줬습니다.

• 사례 2/ 응답 시간. Rubric은 3분 이내 응답을 요구하지만, 모델 입력에는 시간 정보가 없습니다. 자체 모델은 판단할 수 없다며 neutral을, 상용 LLM은 "지체 없이 응대했다"며 positive를 줬습니다. 확인할 수 없는 정보를 있다고 가정한 셈입니다.

점수를 후하게 주거나 박하게 주는 것이 아니라, 판단할 수 없는 것은 판단하지 않는 것. CX팀의 기준을 일관되게 재현한다는 목표가 숫자 밖에서도 드러난 사례 중 하나였습니다.

앞으로의 과제

다만 오프라인 평가에서 검증했더라도, 전 고객사의 실제 상담에는 예상하지 못한 케이스가 있을 수 있습니다. 그래서 실제 데이터의 분포가 바뀌어 성능이 떨어지거나 특정 Failure Case가 쌓이는 등, 재학습이 필요한 시점을 판단하는 기준인 Retraining Trigger를 정해, 문제가 생기면 피드백을 받아 모델을 업데이트하는 관리 체계를 만들고 있습니다. 새로 쌓이는 데이터로 학습부터 평가, 배포까지 주기적으로 돌리는 자동화도 함께 구축하고 있습니다.

마치며

처음에 가장 궁금했던 건 "프론티어 모델 대비 자체 모델을 운영하는 게 정말 이점이 있을까?"였고, 이번 프로젝트로 답을 찾았습니다. 쉽지 않은 길이었지만, 상용 LLM이 아니어도 작은 자체 모델로 비용과 성능을 모두 잡을 수 있었습니다.

비용의 구조도 바뀌었습니다. 상용 LLM은 상담이 늘어나는 만큼 비용도 그대로 늘어나지만, 자체 모델은 GPU 장비라는 고정비로 운영됩니다. 서빙 최적화와 오토스케일링으로 늘어나는 상담도 장비 몇 대만 더해 감당할 수 있어, 상담이 많아질수록 이점이 커지는 구조가 됐습니다.

이번 프로젝트는 상용 LLM을 자체 모델로 바꿔 성능과 비용을 모두 잡은 첫 사례입니다. 상담 분석에서 시작한 이 경험을 바탕으로, 앞으로도 이런 사례를 계속 만들어 가겠습니다.

Reference

[1] Zheng, L., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023 Datasets and Benchmarks. arXiv:2306.05685

[2] Cohen, J. (1968). Weighted kappa: Nominal scale agreement with provision for scaled disagreement or partial credit. Psychological Bulletin, 70(4), 213–220.

[3] Hinton, G., Vinyals, O., & Dean, J. (2015). Distilling the Knowledge in a Neural Network. arXiv:1503.02531

[4] Kim, Y., & Rush, A. M. (2016). Sequence-Level Knowledge Distillation. EMNLP 2016. arXiv:1606.07947

[5] Hu, E. J., et al. (2022). LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022. arXiv:2106.09685

[6] Sheng, Y., et al. (2024). S-LoRA: Serving Thousands of Concurrent LoRA Adapters. MLSys 2024. arXiv:2311.03285

[7] Yu, T., Kumar, S., Gupta, A., Levine, S., Hausman, K., & Finn, C. (2020). Gradient Surgery for Multi-Task Learning. NeurIPS 2020. arXiv:2001.06782