담당자를 잘못 찾는 문의, Jev로 줄일 수 있을까

담당자를 잘못 찾는 문의, Jev로 줄일 수 있을까

챗봇을 붙일 자리가 아니라, 라우팅을 고칠 자리다.

들어가며

사내 문의를 받다 보면 패턴이 보인다. 질문 자체는 명확한데 엉뚱한 사람한테 와 있는 경우가 꽤 많다.

받은 사람은 답을 모른다. 그래서 "그건 A팀에 물어보셔야 할 것 같아요"라고 넘긴다. 물어본 사람은 다시 처음부터 설명한다. 운이 나쁘면 A팀도 아니다.

이 과정에서 실제로 소모되는 건 답변 시간이 아니라 왕복 횟수다. 한 번에 갈 걸 세 번 거치면 하루가 간다.

사내에 AI를 붙이자는 얘기가 나오면 보통 챗봇을 떠올린다. FAQ를 학습시키고, 메뉴를 안내하고, 질문에 답하게 하는 그림. 그런데 Jev를 보고 생각이 좀 바뀌었다.

Jev가 뭔지부터 — 챗봇이 아니다

먼저 짚고 갈 게 있다. Jev는 대화하는 모델이 아니다.

텍스트를 만들지 않는다. 출력이 선택지, 점수, 예/아니오 셋뿐이다. 문장을 생성해서 사람에게 보여주는 용도가 아니라, 판단 결과를 코드가 받아 쓰는 용도다.

지식을 업로드하거나 학습시키지 않는다. 벡터 DB에 문서를 넣어두고 검색해오는 구조가 아니다. 호출할 때마다 두 가지를 같이 넣는다.

• state — 이번 문의 내용 + 판단에 필요한 관련 자료
• questions — 라벨 정의. 무엇 중에서 고를 것인가

즉 모델이 뭘 기억하고 있길 기대하지 않는다. 판단에 필요한 모든 걸 매번 같이 넣고, 좁은 답만 받는다.

 

참고로 지금은 웨이트리스트 단계다. 그래서 이 글은 써본 후기가 아니라, 구조를 보고 우리 문제에 맞겠다고 판단한 기록에 가깝다. 실제로 돌려보면 틀린 부분이 나올 것이다.

내 입장

메뉴 안내보다 담당자 라우팅에 쓰는 게 맞다.

이유는 하나다. 담당자 라우팅에는 정답 집합이 이미 존재하기 때문이다.

메뉴 안내는 "사용자가 원하는 걸 잘 설명해주기"라서 정답이 열려 있다. 잘했는지 판단하기도 애매하다. 반면 "이 문의는 누구한테 가야 하나"는 다르다. 담당자 목록이 곧 선택지다. 새로 만들 필요가 없다.

이미 조직도에 있다.

근거

1. 라벨 집합이 닫혀 있다

분류 문제에서 가장 먼저 막히는 게 "무엇 중에서 고를 것인가"를 정하는 일이다. 라벨을 잘못 설계하면 모델이 아무리 좋아도 소용없다.

담당자 라우팅은 이 단계가 공짜다. 담당자 목록이 그대로 라벨이 된다.

2. 출력이 좁아서 검증이 쉽다

Jev는 선택지 하나를 뱉는다. 맞았는지 틀렸는지 바로 안다.

텍스트를 생성하는 챗봇이었다면 "이 답변이 좋은 답변인가"를 또 판단해야 한다. 그 판단을 자동화하기가 원래 문제보다 어렵다.

여기선 그럴 일이 없다. 실제로 그 담당자가 처리했으면 정답, 다시 넘겼으면 오답이다. 정답 레이블이 업무 과정에서 저절로 쌓인다.

3. 비용이 분류 용도에 유리하다

무료는 아니다. 입력 $0.042 / 1M 토큰, 출력은 무료다.

출력이 무료라는 게 이 구조의 핵심이다. 애초에 출력이 선택지 하나라 길 수가 없다. 비용은 사실상 입력만 계산하면 된다.

대략 잡아보자. 문의 하나에 본문 + 관련 자료 + 라벨 정의를 합쳐 2,000 토큰쯤 들어간다고 가정하면 (어디까지나 가정이다):

1M 토큰 / 2,000 토큰 = 500건
500건당 $0.042  →  건당 약 $0.000084

월 10,000건 = 20M 토큰 = $0.84
환율 1,400원 기준 약 1,180원

월 천 원대다. 잘못 간 문의 하나를 되돌리는 데 드는 사람 시간과 비교하면 계산할 필요도 없다.

물론 자료를 많이 넣으면 토큰이 늘어난다. 그래도 자릿수가 바뀔 규모는 아니다.

4. 애매하면 사람으로 넘기면 된다

이게 의외로 중요하다.

분류 결과를 100% 신뢰할 필요가 없다. 확신이 낮으면 기존 방식대로 사람이 판단하면 된다. 최악의 경우가 지금과 같아지는 것이지, 지금보다 나빠지는 게 아니다.

도입 리스크가 낮다는 뜻이다.

진짜 일은 모델이 아니라 분류 체계다

여기가 핵심이다.

모델을 붙이는 건 어렵지 않다. 어려운 건 라벨을 제대로 정의하는 일이다.

라벨은 코드 경로와 1:1이어야 한다. "결제 관련"처럼 뭉뚱그린 라벨을 만들면, 모델이 그걸 골랐을 때 코드가 뭘 해야 할지 모른다. 라벨 하나가 정해지면 그 다음 동작이 하나로 정해져야 한다.

이 원칙을 지키면 애매한 라벨이 자연스럽게 걸러진다. "이 라벨 나왔을 때 뭘 하지?"에 답이 안 나오면 그 라벨은 잘못 만든 것이다.

그리고 애매한 건 애매한 채로 두면 된다. 억지로 분류하지 말고 사람에게 넘긴다.

모델이 틀리는 것보다, 라벨 정의가 흐린 게 훨씬 큰 문제다. 모델은 바꿀 수 있지만 잘못 잡은 분류 체계는 그 위에 쌓인 코드를 전부 끌고 다닌다.

반론도 일리 있다

"안 써보고 쓰는 글 아닌가"

맞다. 웨이트리스트 단계라 실측이 없다. 구조를 보고 판단한 것이고, 실제 정확도가 쓸 만한지는 돌려봐야 안다. 이 글의 가장 약한 부분이다.

 

"조직도는 자주 바뀐다"

이것도 맞다. 담당자 목록이 정답 집합이라는 게 장점이면서 동시에 부채다. 팀이 개편되면 라벨이 통째로 흔들린다.

다만 Jev는 지식을 학습시키는 구조가 아니라 매번 questions로 라벨 정의를 넣는다. 재학습이 없으니 목록만 갈아끼우면 된다. 이 구조에선 조직 개편 비용이 상대적으로 싸다.

 

"사람도 못 가르는 문의가 있다"

있다. 그런 건 모델도 못 가른다. 그래서 애매하면 사람으로 넘기는 경로가 반드시 있어야 한다.

이걸 실패로 보면 안 된다. 명확한 문의를 자동으로 보내고 애매한 것만 사람이 보는 것만으로도 충분한 개선이다.

 

"규칙 기반으로도 되지 않나"

부분적으로는 된다. 키워드 매칭으로 잡히는 문의도 꽤 있을 것이다.

규칙으로 먼저 해보고 안 되는 것만 모델에 넘기는 게 오히려 합리적일 수도 있다. 굳이 처음부터 전부 모델에 태울 이유는 없다.

결론

Jev가 흥미로운 건 성능이 아니라 범위를 좁혔다는 점이다.

텍스트를 만들지 않고, 지식을 쌓아두지 않고, 선택지만 돌려준다. 할 수 있는 걸 줄인 대신 결과를 코드가 바로 쓸 수 있게 만들었다.

그래서 챗봇을 붙일 자리보다 판단을 자동화할 자리에 맞는다. 사내 문의로 치면 답변을 대신 써주는 게 아니라, 올바른 사람에게 보내주는 쪽이다.

 

써보고 나면 생각이 바뀔 수도 있다. 웨이트리스트 풀리면 실제로 돌려보고 다시 쓰겠다.