Jev로 이메일과 지원 티켓을 라우팅하는 방법: 분류 데모에서 완전한 비즈니스 워크플로까지

500개의 이메일을 몇 개 범주로 빠르게 나누는 것은 이해하기 쉬운 Jev 데모입니다.

한 커뮤니티 사례의 작성자는 Jev가 500개의 이메일을 몇 초 안에 배치 분류했고 비용은 약 0.035달러였다고 보고했습니다. 하지만 이 데모는 이메일 구성, 범주 정의, 사람이 만든 정답 라벨, 정확도, confusion matrix를 공개하지 않았습니다. 따라서 이는 가능한 호출 방식의 예시로 보는 편이 적절하며, 프로덕션 환경의 고객지원 라우팅을 이미 대체할 수 있다는 증거로 볼 수는 없습니다.

실제 이메일 및 티켓 시스템에서 어려운 점은 단순히 “이 이메일을 어느 부서로 보내야 하는가?”를 정하는 데 그치지 않습니다.

하나의 티켓에 중복 결제, 환불 요청, 차지백 위협, 여러 차례 해결되지 않은 불만이 동시에 포함될 수 있습니다. 이를 billing 큐로 보내는 분류 자체는 맞을 수 있지만, 시스템은 가장 높은 우선순위로 처리해야 할 위험 신호를 여전히 놓칠 수 있습니다.

Jev에 더 적합한 역할은 “한 번의 분류로 전체 지원 프로세스를 해결하는 것”이 아니라, 그 안의 판단 계층이 되는 것입니다. 하나의 이메일을 경계가 명확한 여러 질문으로 분해하고, 구조화된 결과를 비즈니스 코드에 넘겨 결합, 라우팅, 실행하도록 합니다.

이메일 또는 지원 티켓
   ↓
전처리: 제목, 본문, 필요한 과거 맥락 추출
   ↓
Jev: 큐 선택, 환불 탐지, 위험 탐지, 긴급도 점수화
   ↓
비즈니스 규칙: 확률, 임계값, 고객 정보, 회사 정책 결합
   ↓
자동 라우팅 / 사람의 검토 / 고위험 에스컬레이션 / 답변 초안 생성

가장 중요한 역할 분담은 다음과 같습니다. Jev는 의미 판단을 하고, 코드는 제어 흐름을 담당하며, 고객지원 담당자나 생성형 모델이 최종 답변을 작성합니다.

Jev가 이 판단 계층에 적합한 이유

Jev는 긴 텍스트 생성을 목표로 하는 채팅 모델이 아닙니다. state를 입력받고 개발자가 미리 정의한 typed questions에 답합니다. 주된 형태는 세 가지입니다.

유형	적합한 질문	반환 결과
Choice	이 티켓을 보내기에 가장 적합한 큐는 어디인가?	하나의 선택지, 각 선택지의 확률, confidence
Noul	사용자가 명시적으로 환불을 요청했는가?	0부터 1까지의 “예” 확률
Score	이 티켓은 어느 긴급도 구간에 속하는가?	점수, 각 구간의 확률, confidence

하나의 요청 안에서 여러 질문을 병렬로 평가할 수 있습니다. 모델에게 티켓을 읽고 분석문을 작성하게 한 뒤 프로그램이 다시 그 문장을 파싱하도록 하기보다, 몇 개의 원자적 질문을 직접 던져 후속 코드가 바로 사용할 수 있는 결과를 받는 편이 더 명확합니다.

하지만 typed response가 보장하는 것은 결과가 미리 정의된 인터페이스를 따른다는 점뿐입니다. 비즈니스 판단이 반드시 맞다는 뜻은 아닙니다. 시스템에는 여전히 임계값, 폴백, 사람의 검토, 오프라인 평가가 필요합니다.

하나의 티켓을 하나의 질문으로만 처리해서는 안 된다

사용자가 다음 이메일을 보냈다고 가정해 보겠습니다.

Pro 요금제로 업그레이드한 뒤 결제가 두 번 청구됐습니다. 3일 전에 이미 문의했지만 아직 아무도 해결하지 않았습니다. 오늘 안에 환불해 주세요. 그렇지 않으면 은행에 차지백을 신청하겠습니다.

“이 이메일은 어느 부서에 속하는가?”만 묻는다면 답은 아마 billing일 것입니다. 하지만 프로덕션 시스템은 적어도 다음 네 가지도 알아야 합니다.

판단	질문 유형	권장 선택지 또는 기준	목적
어느 기본 큐로 보낼 것인가?	Choice	billing / shipping / technical / account / sales / legal / none	초기 라우팅
환불 요청이 있는가?	Noul	환불, 결제 취소, 비용 반환을 명시적으로 요구하면 “예”로 간주	환불 워크플로 시작
차지백, 규제 또는 법적 위험이 있는가?	Noul	chargeback, 은행 민원, 규제 기관, 법적 조치 언급	고위험 에스컬레이션
긴급도	Score	기한 없는 일반 문의 / 서비스 이용에 이미 영향이 있거나 반복 문의 / 금전 손실, 차지백 또는 명확한 기한	큐 우선순위
사람의 처리가 필요한가?	Noul	금전, 법률, 반복적으로 해결되지 않은 불만 또는 불확실한 모델 판단	자동 처리 허용 여부 결정

이 질문들은 서로 연관되어 있지만, “이 티켓을 종합적으로 어떻게 처리해야 하는지 판단해 달라”는 하나의 질문으로 합쳐서는 안 됩니다.

Jev의 공식 설계 지침은 복잡한 작업을 원자적 판단으로 분해하는 것입니다. 질문을 분리하면 비즈니스 코드는 어느 큐로 보낼지, 우선순위를 높일지, 자동 답변을 중지할지, 당직 담당자에게 알릴지를 각각 독립적으로 결정할 수 있습니다.

Choice에는 none, other, unclear 같은 선택지도 남겨야 합니다. 올바른 답이 선택지에 없다면 모델은 새 큐를 만들어 낼 수 없고, 기존 선택지 중 가장 가까운 것을 억지로 고를 수밖에 없습니다.

모델 출력과 비즈니스 동작 사이에는 규칙 계층이 필요하다

아래 제어 흐름 pseudocode는 Jev와 주변 시스템의 역할 분담을 보여 줍니다. 공식 SDK 요청을 그대로 옮긴 것은 아닙니다.

const decision = await evaluateTicket(ticket, ticketQuestions)

if (decision.transportFailed) {
  return moveToQueue("manual_triage", {
    reason: "decision_service_unavailable"
  })
}

if (
  decision.chargebackRisk >= T_CHARGEBACK ||
  decision.legalRisk >= T_LEGAL
) {
  return moveToQueue("risk_escalation", {
    priority: "highest",
    requireHuman: true
  })
}

if (
  decision.teamTopProbability < T_ROUTE ||
  decision.teamProbabilityMargin < T_MARGIN
) {
  return moveToQueue("manual_triage", {
    reason: "uncertain_route"
  })
}

moveToQueue(decision.team)

if (decision.refundIntent >= T_REFUND) {
  attachWorkflow("refund_review")
}

if (decision.urgency >= T_URGENCY_HIGH) {
  raisePriority()
}

T_ROUTE, T_REFUND 같은 상수는 Jev가 제공하는 범용 기본값이 아니라 비즈니스 정책입니다. 자체 티켓 데이터로 보정해야 하며, 위험 수준, 언어, 모델 버전, 큐 정의에 따라 달라질 수 있습니다.

저위험 일반 문의에는 자동 라우팅의 임계값을 비교적 완화할 수 있습니다. 반면 환불, 차지백, 계정 정지, 법적 불만에는 더 엄격한 임계값을 적용하고 사람의 검토를 남겨야 합니다.

배치 호출은 라우팅에 적합하지만 고위험 게이트는 더 신중해야 한다

Jev의 공식 인터페이스는 하나의 요청 안에서 여러 질문에 병렬로 답할 수 있는 기능을 제공합니다. 여러 티켓을 한 번의 호출에 묶어 처리할 때의 결과가 개별 호출과 일치한다고 가정해서는 안 되며, 독자의 자체 데이터에서 배치 호출과 단일 항목 호출 간의 동작을 직접 벤치마크해야 합니다.

“이메일 하나당 한 번, 질문 하나당 또 한 번” 호출하는 방식보다 필요한 판단을 가능한 한 적은 호출에 묶으면 일반적으로 네트워크 왕복을 줄이고 throughput을 제어하기 쉬워집니다.

또한 배치 호출과 단일 항목 호출 간에 Noul 확률의 동등성을 가정해서는 안 되며, 이를 자체 데이터에서 검증해야 합니다. 환불, 차지백, 법적 위험과 같은 고위험 티켓이나 불확실한 티켓은 별도로 처리해야 합니다.

따라서 더 신중한 2단계 설계는 다음과 같습니다.

1. 첫 번째 단계에서는 기본 큐, 주제, 명백한 스팸 여부 같은 저위험 판단을 배치로 수행합니다.
2. 환불, 차지백, 법적 위험과 관련되거나 확률이 불확실 구간에 있는 티켓은 단일 티켓으로 다시 검토하거나 곧바로 사람의 큐로 보냅니다.

목적은 모델에게 반복 투표를 시키는 것이 아니라, 고위험 동작에 더 명확한 맥락과 더 엄격한 처리 경로를 제공하는 것입니다.

confidence를 “정확도”로 해석하지 말 것

Choice와 Score는 confidence를 반환하지만, 이 값은 확률 분포가 얼마나 집중되어 있는지를 나타낼 뿐 독자의 비즈니스에서 직접 검증된 정답 확률이 아닙니다.

자체 데이터로 보정(calibration)을 거치지 않은 confidence를 정답 확률로 가정해서는 안 되며, 따라서 다음과 같은 규칙은 안전하지 않습니다.

confidence = 1.0 → 자동 실행

실제 시스템은 여러 신호를 함께 봐야 합니다.

• 가장 높은 선택지의 probability
• 1위와 2위 선택지 사이의 probability 차이
• 해당 비즈니스 위험과 연결된 독립적인 Noul
• 티켓이 학습 또는 검증 데이터에서 다루지 않은 새로운 분포에 속하는지 여부
• 현재 모델 버전이나 질문 문구가 바뀌었는지 여부

“어느 큐로 보내야 하는가?”와 “자동 처리해도 되는가?”도 하나의 Choice만으로 해결하지 않는 편이 좋습니다. 전자는 Choice로 큐를 고르고, 후자는 별도의 Noul로 자동 처리 조건 충족 여부를 판단합니다.

질문 문구는 코드처럼 관리해야 한다

Jev 워크플로에서 질문 문구는 단순한 프롬프트 문장이 아니라 비즈니스 로직의 일부입니다.

instructions와 criteria의 의미가 충돌하면 모델은 오류를 내지 않은 채 구조적으로는 유효하지만 의미적으로는 잘못된 결과를 반환할 수 있습니다.

따라서 이메일 라우팅 프로젝트는 적어도 다음과 같이 질문 정의를 관리해야 합니다.

관리 항목	구체적인 방법
버전 관리	질문 문구, 선택지, 기준을 바꿀 때마다 새 버전을 생성
코드 리뷰	질문 정의와 라우팅 규칙을 관리자 텍스트 필드에 흩어 두지 말고 repository에 저장해 review
테스트 예시	각 질문에 대해 긍정, 부정, 경계, 다중 의도 티켓을 보관
충돌 검사	instruction과 true/false criteria가 같은 의미 방향을 가리키는지 확인
모델 버전 고정	임계값을 보정한 뒤에는 변동 가능한 latest alias에 직접 의존하지 말고 특정 버전을 고정

특히 Score의 각 구간은 “낮음, 중간, 높음”만 쓰기보다 관찰 가능한 비즈니스 상황을 설명해야 합니다. 예를 들어 “사용자가 가격만 묻고 있다”와 “사용자가 여러 번 문의했고 서비스도 이용할 수 없다”는 “중간 긴급도”보다 더 안정적으로 판단할 수 있습니다.

네트워크 실패 시 시스템이 무엇을 할지 알고 있어야 한다

분류 모델의 응답 실패를 “위험 없음”이나 “기본 허용”으로 해석해서는 안 됩니다.

높은 동시성 환경에서는 일시적인 transport failure가 발생하거나 latency가 뚜렷하게 높아질 수 있습니다. 프로덕션 시스템이 이상적인 성공 경로만 가정하고 구현되어서는 안 됩니다.

최소 네 가지 보호 계층이 필요합니다.

1. 재시도와 backoff: 일시적인 네트워크 오류로 티켓을 잃지 않도록 retries와 retry-after를 지원하는 SDK를 우선 사용합니다.
2. 명시적인 폴백 의미: 판단 서비스가 사용할 수 없을 때 티켓을 사람의 triage로 보낼지, 처리를 미룰지, deterministic rules만 실행할지 미리 정합니다.
3. 멱등성과 중복 제거: 이메일 재전송, 큐 재시도, timeout 재시도로 중복 티켓이 생성되지 않아야 합니다.
4. 완전한 로깅: 모델 버전, 질문 버전, probabilities, 호출 latency, usage, 최종 사람 처리 결과를 기록합니다.

금전, 계정, 법률 관련 티켓에서 가장 안전한 기본 폴백은 대개 “자동 승인”이 아니라 “자동 동작을 멈추고 사람에게 전달”하는 것입니다.

다국어 큐는 하나의 Score 임계값을 공유할 수 없다

다국어 환경에서는 특정 언어에서 설정한 임계값이 다른 언어로 전이될 수 있다고 가정해서는 안 되며, 언어별로 별도의 검증을 거쳐야 합니다. 라우팅 라벨이 같아 보이더라도 임계값의 전이 가능성을 전제할 수 없습니다.

따라서 다국어 고객지원 시스템은 최소한 다음을 해야 합니다.

• 언어별로 별도의 검증 세트를 구축
• 긴급도와 사람 에스컬레이션 임계값을 언어별로 따로 검증하고 보정
• 영어 데이터에서 만든 점수 구간을 다른 언어에 그대로 복사하지 않기
• 번역문, 원문, 과거 대화 맥락을 어떻게 사용할지 일관된 정책 적용

출시 전에 무엇을 평가해야 하는가

이메일 라우팅 시스템은 전체 정확도만으로 평가할 수 없습니다. 오류마다 비용이 크게 다르기 때문입니다. 사전 영업 문의를 고객지원 큐로 보내는 일은 전달이 한 번 늘어나는 정도일 수 있지만, 차지백 위협이나 법적 불만을 놓치면 직접적인 금전 및 컴플라이언스 위험이 생길 수 있습니다.

최소한 다음 지표를 각각 따로 봐야 합니다.

지표	답해야 할 질문
기본 큐 정확도	티켓이 올바른 첫 처리 큐에 도착했는가?
고위험 recall	차지백, 법률, 규제, 계정 보안 티켓을 얼마나 놓쳤는가?
자동 라우팅 커버리지	사람의 1차 분류가 필요 없었던 티켓 비율은 얼마인가?
잘못된 자동 처리율	사람이 처리했어야 할 티켓 중 자동으로 통과한 비율은 얼마인가?
사람 검토율	임계값이 지나치게 보수적이어서 사람 큐의 의미가 사라지지 않았는가?
latency 및 failure rate	실제 동시성, 이메일 길이, 네트워크 조건에서 안정적인가?
티켓당 전체 비용	판단, 재시도, 후속 모델, 사람 검토까지 포함해도 경제적인가?

비교 기준을 고를 때 Jev를 비싼 최첨단 채팅 모델과만 비교해서는 안 됩니다. 규칙 시스템, 구조화 출력을 지원하는 Flash 모델, embedding과 classifier의 조합, 자체 라벨 데이터로 학습한 소형 모델도 합리적인 대안이 될 수 있습니다.

라벨 데이터가 확보되어 있다면 전용 classifier를 벤치마크하는 것을 권장합니다. 합리적인 발전 경로는 cold start와 라벨이 자주 바뀌는 단계에서 Jev를 사용하고, 특정 고빈도 큐에 충분한 데이터가 쌓인 뒤 전용 classifier를 벤치마크하여 전환 여부를 평가하는 것입니다.

Jev는 최종 고객지원 답변을 작성하지 않는다

라우팅 이후에도 시스템은 문제 요약, 주문 조회, 환불 자격 확인, 답변 초안 생성을 해야 할 수 있습니다. 이 모든 작업을 Jev에 맡겨서는 안 됩니다.

더 명확한 역할 분담은 다음과 같습니다.

단계	더 적합한 실행 주체
정확한 주문 조회, 금액 계산, 날짜 비교	비즈니스 코드와 데이터베이스
큐, 위험, 의도, 긴급도 판단	Jev 또는 다른 분류 모델
지식베이스 검색	검색 및 RAG 시스템
답변 초안, 설명, 자연어 커뮤니케이션	생성형 LLM
환불 승인, 계정 정지, 법적 처리	사람과 회사 정책

이 구조는 Jev를 “자동 고객지원 상담원”으로 만드는 것이 아닙니다. 각 이메일이 비싼 모델이나 사람의 큐로 들어가기 전에, 코드가 직접 사용할 수 있는 저비용의 구조화된 판단 계층을 하나 추가하는 것입니다.

결론: 분류가 아니라 제어 흐름이 제품이다

Jev는 유용한 방향을 보여 줍니다. 소프트웨어에 필요한 것이 하나의 큐, 하나의 확률, 하나의 단계뿐이라면 매번 생성형 모델을 호출해 문장을 쓰게 하고 코드가 그 의미를 추측하도록 할 필요는 없습니다.

하지만 이메일 분류 데모에서 완전한 비즈니스 워크플로로 가려면 분류 이후의 제어 흐름을 설계해야 합니다. 어떤 티켓을 자동 라우팅할 수 있는지, 어떤 신호를 별도로 탐지해야 하는지, 언제 사람이 개입해야 하는지, 서비스 실패 시 시스템이 어떻게 degrade해야 하는지, 실제 라벨 데이터로 임계값을 어떻게 계속 확인할지를 정해야 합니다.

따라서 Jev 티켓 시스템은 “500개 이메일을 얼마나 빨리 분류했는가?”만으로 평가해서는 안 됩니다. 더 중요한 질문은 다음과 같습니다.

고위험 티켓을 놓치지 않으면서 불필요한 전달, 모델 호출, 사람의 1차 분류를 안정적으로 줄이는가?

자체 비즈니스 데이터에서 이 질문에 긍정적으로 답할 수 있을 때만 이메일 라우팅은 모델 데모에서 실제로 사용할 수 있는 비즈니스 워크플로가 됩니다.