고객 문의를 어느 팀에 보낼지, 결제 보류 건을 사람이 볼지, 신고 콘텐츠를 숨길지처럼 시스템이 반복해서 내려야 하는 판정이 있습니다. 이 업무에 LLM을 붙이면 금방 시작할 수 있지만, 답을 설명문으로 받은 뒤 다시 파싱하고 분기하는 구조가 남습니다. 반대로 규칙 엔진은 예측 가능하지만, 사람이 문장으로 적은 예외를 계속 추가해야 합니다.
Jev처럼 정해진 질문에 선택지와 확률을 돌려주는 전용 판정 모델은 이 사이에 놓입니다. 핵심은 “200배 빠른 AI”라는 홍보 문구가 아닙니다. 시스템이 읽을 문장을 생성하지 않고, 코드가 바로 받을 수 있는 판정값과 확률을 반환한다는 점입니다.
다만 이 차이는 모든 자동화에 가치가 있지 않습니다. 업무 판정의 안정성, 잘못 처리했을 때의 비용, 확률을 믿고 경로를 나눌 수 있는지, 나중에 누가 왜 처리됐는지 설명해야 하는지를 함께 봐야 합니다.
먼저 업무를 네 종류로 나눠야 한다
모델 비교는 “어느 모델이 더 똑똑한가”에서 시작하면 흐려집니다. 먼저 자동화하려는 판단이 어떤 성격인지 나누는 편이 낫습니다.
규칙이 이미 확정된 업무라면 규칙 엔진이 우선입니다. 예를 들어 계약 상태가 해지이고 미납 금액이 있으면 기능을 제한하는 판단은 모델이 추론할 일이 아닙니다. 입력값, 우선순위, 예외 조건을 명시하고 버전별로 관리해야 합니다. 규칙은 틀릴 수 있어도 왜 틀렸는지 찾기 쉽고, 같은 입력에 같은 결과를 재현할 수 있습니다.
라벨이 충분히 쌓였고 기준이 안정적인 업무는 전통적인 분류 모델이 유리할 수 있습니다. 스팸 탐지, 문서 유형 분류, 반복 민원 분류처럼 수천 건 이상의 신뢰할 수 있는 라벨이 있고 분류 체계가 자주 바뀌지 않는 경우입니다. 학습·재학습 파이프라인을 운영할 역량이 있다면 비용과 처리량 면에서 좋은 선택이 될 수 있습니다.
기준은 언어로 설명할 수 있지만 라벨이 부족하거나 자주 바뀌는 업무에서는 Jev 같은 전용 판정 모델이나 LLM이 후보가 됩니다. 새 정책에 따라 문의를 분류해야 하거나, 제품 기능 변화로 티켓 라우팅 기준이 계속 수정되는 상황이 여기에 가깝습니다. 모델을 다시 학습시키기보다 질문과 선택지를 바꿔 시험할 수 있기 때문입니다.
맥락 해석과 후속 작업이 필요한 업무는 LLM이 더 적합합니다. 긴 문서의 내용을 비교하거나, 사용자의 요청을 이해한 뒤 답변을 작성하거나, 여러 도구를 호출해야 하는 경우입니다. Jev는 텍스트를 생성하지 않고 정해진 선택지 안에서만 판단하므로, 이메일 답장 작성이나 조사 보고서 요약을 대신할 수 없습니다.
이 구분에서 중요한 점은 한 시스템이 하나의 방식만 쓸 필요는 없다는 것입니다. 규칙으로 명백한 건을 먼저 걸러내고, 전용 판정 모델로 대량의 애매한 요청을 분류하며, 어려운 소수만 LLM이나 사람에게 보내는 구성이 더 현실적일 수 있습니다.
Jev의 비교 우위는 속도보다 “확률을 쓸 수 있는가”에 있다
TypeSafe가 공개한 Jev는 Choice, Score, Noul 형태의 제한된 판정을 제공합니다. Choice는 정해진 선택지 중 하나를 고르고, Score는 척도상의 값을 판단하며, Noul은 예·아니오 성격의 질문에 0과 1 사이의 확률을 반환합니다. 생성형 응답을 만들지 않으므로 출력 토큰 생성 시간이 없고, 회사가 공개한 자체 평가에서는 특정 비교 조건에서 Sonnet 5와 같은 평균 정확도 67.8%에 더 짧은 지연과 낮은 비용을 제시했습니다.
하지만 이 숫자만으로 도입을 결정하면 안 됩니다. 해당 수치는 회사가 정한 워크플로와 측정 환경에서 나온 값이며, 한국에서 호출할 때의 네트워크 지연, 한국어 데이터의 정확도, 자사 업무 기준에서의 오류 비용을 대신 보여주지 않습니다. 영어가 주요 학습 언어라는 점도 비영어권 업무에서는 별도 검증이 필요한 이유입니다.
전용 판정 모델의 더 중요한 가능성은 확률을 이용해 처리 경로를 나누는 데 있습니다.
- 높은 확률의 판정은 자동 처리한다.
- 중간 구간은 담당자 화면에 검토 표시를 남긴다.
- 낮은 확률이나 선택지 간 격차가 작은 건은 사람 또는 더 강한 모델로 넘긴다.
- 되돌릴 수 없는 실행은 확률이 높아도 별도 승인 조건을 둔다.
여기서 확률은 “이 결과가 맞다”는 보증서가 아닙니다. 확률 0.9를 받은 건들을 모았을 때 약 90%가 맞는 경향이 있는지를 확인해야 합니다. 이를 보정, 또는 캘리브레이션이라고 합니다. 정확도가 높은 모델도 틀린 답에 높은 자신감을 보일 수 있고, 그런 모델의 확률을 승인 임계값으로 쓰면 위험합니다.
따라서 Jev를 검토할 때는 정확도와 함께 “0.9 이상만 자동 처리했을 때 얼마나 많은 건이 통과하고, 그중 얼마나 맞는가”를 봐야 합니다. 이 수치가 없으면 확률 기반 라우팅의 장점은 아직 가설에 머뭅니다.
네 가지 선택지를 같은 표에 올려놓는 방법
| 비교 축 | 규칙 엔진 | 전통적 분류 모델 | LLM | Jev 같은 전용 판정 모델 |
|---|---|---|---|---|
| 판단 기준 | 사람이 명시 | 학습 데이터 | 프롬프트와 모델 추론 | 질문, 선택지, 모델 판단 |
| 출력 | 결정값과 규칙 경로 | 라벨과 점수 | 텍스트 또는 구조화 출력 | 제한된 선택지와 확률 |
| 변경 대응 | 규칙 수정 필요 | 재학습 필요 가능성 | 프롬프트 수정 가능 | 질문·선택지 수정 가능 |
| 설명·감사 | 가장 명확함 | 특징과 학습 이력 해석 필요 | 근거 문구는 만들 수 있으나 검증 필요 | 판정 로그는 남기기 쉬우나 이유를 제공하지 않음 |
| 대량 처리 | 매우 유리 | 유리 | 비용·지연이 커질 수 있음 | 빠른 판정이 강점일 수 있음 |
| 적합한 오류 | 규칙 누락, 예외 누락 | 학습 데이터 편향 | 형식은 맞지만 의미가 틀린 답 | 확률이 높아도 틀린 자동 판정 |
표에서 특히 주의할 항목은 감사 가능성입니다. Jev의 출력 형식이 고정돼 있다고 해서 업무 판단이 설명 가능해지는 것은 아닙니다. “사기 의심”이라는 선택지와 0.94라는 확률을 받았더라도, 담당자나 고객이 왜 그 결론이 나왔는지 알아야 하는 업무라면 별도 근거 체계가 필요합니다.
예를 들어 정책 조건이 명확한 승인 업무는 규칙 엔진이 판정 근거를 남겨야 합니다. 문서 내용의 모호함을 분류하는 업무라면 모델 결과와 함께 입력 원문, 질문 버전, 선택지 버전, 임계값, 후속 처리 경로를 보관해야 합니다. 모델이 이유를 생성하지 않는다고 해서 감사 항목이 줄어드는 것은 아닙니다. 오히려 어떤 질문으로 무엇을 자동 실행했는지 더 엄격히 남겨야 할 수 있습니다.
오류 비용이 임계값과 아키텍처를 정한다
자동 판정에서 가장 위험한 실패는 API 오류가 아닙니다. 형식은 정상인데 틀린 판정이 다음 시스템으로 전달되는 경우입니다. 잘못된 답도 정해진 스키마 안에 들어오면 모니터링 화면에서는 성공으로 보일 수 있습니다.
그래서 임계값은 모델 제공사가 정해줄 수 없습니다. 같은 0.9라도 문의 담당팀을 잘못 배정하는 비용과 결제를 잘못 승인하는 비용은 다릅니다. 다음 질문에 답한 뒤 임계값을 정해야 합니다.
- 잘못 자동 처리했을 때 누가 어떤 손실을 부담하는가?
- 사람 검토로 넘겼을 때 감당할 수 있는 대기 시간과 운영 비용은 얼마인가?
- 판정을 취소하거나 되돌릴 수 있는가?
- 오판이 특정 고객군, 언어, 상품군에 집중될 가능성은 없는가?
- 업무 기준이 바뀌었을 때 이전 판정과 새 판정을 비교할 수 있는가?
되돌릴 수 없는 조치라면 높은 확률 하나만으로 실행하지 않는 편이 안전합니다. 금액 한도, 계정 상태, 차단 목록 같은 결정적 조건을 규칙으로 다시 확인하고, 필요한 경우 사람 승인으로 묶어야 합니다. 반대로 티켓 우선순위 표시처럼 담당자가 최종 결정을 내리는 보조 기능이라면 더 낮은 확률 구간도 활용할 여지가 있습니다.
질문 문구도 운영 대상입니다. 전용 판정 모델은 프롬프트를 짧고 명확하게 쓰는 방식이 권장될 수 있지만, 문구를 조금 바꿨다고 기존 확률 보정이 유지된다고 가정하면 안 됩니다. 질문, 선택지, 입력 전처리, 정책 문서가 바뀔 때마다 이전 임계값을 다시 점검해야 합니다.
도입 검증은 모델 데모가 아니라 판정 흐름으로 한다
탐색 단계에서는 모든 업무를 옮기기보다 대표 판정 하나를 고르는 것이 좋습니다. 사람이 현재 처리하고 있고, 정답 또는 검토 결과를 비교적 신뢰할 수 있으며, 잘못 처리해도 통제 가능한 업무가 적합합니다.
검증 순서는 다음과 같이 잡을 수 있습니다.
- 먼저 현재 규칙, 담당자 기준, 예외 사유를 모아 선택지 정의를 고정합니다.
- 실제 업무 데이터를 시간 순서와 유형을 고려해 평가용과 점검용으로 나눕니다.
- 규칙 엔진, 기존 분류 모델, 구조화 출력 LLM, 전용 판정 모델을 같은 선택지와 같은 성공 기준으로 비교합니다.
- 전체 정확도만 보지 말고, 확률 구간별 정답률과 자동 처리 비율을 확인합니다.
- 각 오답을 비용 기준으로 분류합니다. 단순 재배정인지, 고객 피해인지, 금전·권한·안전 문제인지 구분해야 합니다.
- 운영 환경과 같은 리전, 언어, 입력 길이, 동시 요청 조건에서 지연과 실패율을 다시 측정합니다.
- 모델 호출부는 특정 벤더 SDK에 흩어 두지 말고 내부의 ‘판정 요청’ 인터페이스로 감쌉니다. 질문 버전, 모델 버전, 임계값, 결과를 함께 기록할 수 있어야 합니다.
Jev는 입력 텍스트와 제한된 선택지에 맞춘 도구입니다. 긴 문서를 통째로 읽고 보고서를 만들거나, 행동 계획을 작성하거나, 화면을 조작하는 역할을 기대하면 설계가 어긋납니다. 반대로 수많은 요청을 빠르게 분류하고, 자신 없는 건을 다른 경로로 보내려는 팀이라면 검토할 이유가 있습니다.
다음 회의에서는 “어떤 모델이 더 정확한가”보다 이 질문부터 정해보는 편이 낫습니다. 우리 시스템은 틀린 판정을 어느 지점까지 자동으로 실행해도 되는가. 그 답이 정해져야 Jev의 확률, LLM의 구조화 출력, 분류 모델의 점수, 규칙 엔진의 조건이 각각 어디에 들어갈지 결정할 수 있습니다.
