Maven은 TypeSafe의 새로운 결정 모델을 모든 Maven 대화에 들어 있는 판단 작업, 즉 티켓 분류, Intelligent Fields, 품질 검사 등에 적용해 이미 테스트하고 있습니다. 자체 초기 테스트에서 분류 작업 속도는 현재 방식보다 약 12배 빨랐으며, 같은 요청에 분류 항목을 추가해도 느려지지 않았습니다.
고객 요청에는 여러 개의 결정이 담겨 있습니다
어떤 고객이 이렇게 문의했다고 가정해 보겠습니다. "청구 금액이 2배로 늘었고, 팀원 절반이 로그인을 못 하고 있어요. 내일 갱신 전까지 해결해야 합니다."
이 요청을 해결하려면 여러 종류의 작업이 필요합니다. 에이전트는 청구 문제와 접근 문제를 인식하고, 긴급성을 파악하고, 고객 계정을 확인하고, 적절한 정책을 따라야 합니다. 사람이 개입해야 한다면 대화가 충분한 맥락과 함께 올바른 팀에 전달되어야 합니다.
그중 일부는 추론과 설명이 필요합니다. 일부는 단순 조회로 충분합니다. 또 일부는 어떤 문제가 있는지, 얼마나 긴급한지, 고객이 상담원 연결을 요청했는지 같은 집중된 판단으로 귀결됩니다.
Jev가 흥미로워지는 지점이 바로 이 마지막 범주입니다.
Jev가 얼리 액세스를 벗어나자마자, Maven은 음성 모델을 위해 구축한 것과 같은 평가 체계로 테스트를 시작했습니다. 이런 주장은 벤더 벤치마크만이 아니라 고객의 실제 워크플로에서 어떻게 작동하는지로 검증해 볼 가치가 있기 때문입니다.
Jev는 분류기와 비슷하지만 차이가 있습니다. 맥락과 범위가 정해진 질문을 주면 선택지, 점수 또는 확률을 반환합니다. TypeSafe AI의 새 모델은 소프트웨어가 바로 사용할 수 있는 구조화된 결정을 반환하도록 설계되었습니다. Maven 같은 엔터프라이즈 플랫폼에서는 고객 요청과 해결 사이에 놓인 수많은 판단을 개선할 기회가 생깁니다.
Jev가 LLM과 다른 점
TypeSafe는 Jev를 "System One" 모델이라고 부릅니다. 개발자가 맥락, 질문, 가능한 답변을 제공하면 Jev는 선택지, 점수, 확률을 반환합니다. 같은 맥락에 대한 여러 개의 독립적인 질문을 병렬로 평가할 수 있습니다. LLM처럼 자유 형식의 텍스트를 생성하지는 않습니다.
위 요청의 경우, 시스템은 청구 문제가 포함되어 있는지, 접근이 차단되었는지, 고객이 기한을 언급했는지 물을 수 있습니다. 각 답변은 워크플로의 다음 단계에 입력값이 됩니다.
기존 LLM도 이미 스키마를 따르는 출력을 생성할 수 있습니다. Jev가 내세우는 것은 이 작업을 위해 특별히 만들어진 모델이라는 점으로, 병렬 출력 생성과 TypeSafe가 Reinforcement Learning for Calibrated Decisions라고 부르는 학습 방식을 갖추고 있습니다. 목표는 더 낮은 지연 시간과 비용과 함께, 불확실성을 소프트웨어가 활용할 수 있게 만드는 것입니다.
초기 사용자들도 특정 작업에서 상당한 속도 향상을 보고했습니다. Maven의 자체 테스트에서 Jev는 현재 방식보다 약 12배 빠르게 응답했습니다. 이는 벤치마크가 아닌 초기 프로토타이핑 결과이며, 고객 운영 환경에서는 사용하지 않고 있습니다. 다른 곳에서도 자체 작업에서 비슷한 수치를 보고하고 있습니다. Vercel의 Guillermo Rauch는 자사 에이전트가 수행하는 명령 안전성 검토에서 95번째 백분위수 기준 최대 18배 빠른 속도를 측정했으며, 기존에 사용하던 GPT-5.6-Luna 검토기보다 정확도도 높았다고 밝혔습니다.
Intelligent Fields는 평가하기에 적합한 영역입니다
Maven은 2026년 봄 Intelligent Fields를 출시했습니다. 팀은 제품 영역, 감정, 환불 의도, 에스컬레이션 신호 등 대화에서 파악하고 싶은 항목을 정의하고, 그 결과 필드는 리포팅, 라우팅, 에이전트 구성에 활용됩니다.
현재 이 기능의 장점은 요구하는 것이 거의 없다는 점입니다. 알고 싶은 내용을 일상적인 언어로 정의하면 Maven이 모든 대화를 그 기준으로 평가합니다. 레이블이 지정된 학습 데이터도, 레이블별로 관리할 모델도, 일주일 뒤에 티켓을 수작업으로 태깅하는 분석가도 필요 없습니다. 각 값은 신뢰도 점수와 근거와 함께 반환되며 API와 분석 화면에서 확인할 수 있습니다. 덕분에 사람이 레이블을 그대로 믿는 대신, 왜 해당 대화가 이탈 위험으로 분류되었는지 감사할 수 있습니다.
각 필드는 의도적으로 개별 평가됩니다. 이렇게 분리되어 있기 때문에 대화 전체에 대한, 아무도 감사할 수 없는 하나의 종합 판정이 아니라 각 값마다 고유한 신뢰도 점수와 근거가 제공됩니다.
Jev 같은 결정 모델은 이 구조에 깔끔하게 들어맞습니다. 같은 맥락에 대한 독립적인 질문을 병렬로 평가하므로, 여러 필드 평가를 하나의 요청으로 묶어도 개별적으로 점수가 매겨진 별도의 답변으로 반환됩니다. 출력 형태는 바뀌지 않습니다. 바뀌는 것은 동시에 처리할 수 있는 질문의 수입니다.
따라서 Jev를 적용해도 Intelligent Fields의 작동 방식은 달라지지 않을 것으로 예상합니다. 대신 효율이 높아지고 비용이 줄어들 것으로 기대합니다.
| 대화에 대한 질문 | 결정 모델의 처리 방식 | 가능해지는 것 |
|---|---|---|
| 어떤 제품 영역에 관한 문의인가? | 정의된 카테고리 중에서 선택 | 수요를 분류하고 관련 가이드 선택 |
| 보고된 문제는 얼마나 심각한가? | 명시적인 기준표에 따라 점수화 | 실제 영향도에 따라 작업 우선순위 지정 |
| 고객이 상담원 연결을 요청했는가? | 해당 진술이 참인지 추정 | 에스컬레이션 처리에 반영 |
| 이 요청에는 어떤 문제가 포함되어 있는가? | 후보 문제를 각각 개별 평가 | 한 대화 안의 여러 의도를 모두 유지 |
이는 평가해 볼 후보 매핑입니다. Jev는 각 필드의 의미와, 해당 필드에 의존하는 모든 워크플로의 동작을 그대로 유지해야 합니다. 출력 범위가 좁다는 점도 고려해야 합니다. 자유 형식의 요약과 서술형 설명에는 여전히 생성형 모델이나 다른 소스가 필요합니다.
이 기회는 팀이 각 상호작용에서 더 많은 정보를 얻고자 할 때 특히 중요합니다. 평가당 비용이 낮아지면, 새 필드를 추가할 때마다 비싼 모델 호출이 늘어나는 부담 없이 추가적인 제품 문제, 해지 사유, 에스컬레이션 신호를 추적할 수 있습니다.
출시된 지 일주일 된 모델을 엔터프라이즈 고객에게 적용하지 않습니다
위의 내용은 모두 테스트와 설계 단계의 구상입니다. Jev는 어떤 고객 워크플로에서도 사용되지 않으며, 며칠 전에 출시된 모델은 Maven이 모든 신규 모델에 적용하는 동일한 평가 체계를 통과하기 전까지 고객 워크플로에 적용되지 않습니다. GPT-Live-1을 비롯한 음성 모델을 어떻게 테스트해 왔는지 확인해 보세요. Maven은 모호한 사례와 판단에 필요한 맥락이 누락된 사례를 포함한 대표 사례로 현재 방식과 결정 품질을 비교한 뒤, 실제 라우팅에 적용하기 전에 지연 시간, 채택된 결과당 비용, 고객 성과를 비교합니다.
엔터프라이즈 업무를 위한 더 넓은 모델 선택지
Jev는 엔터프라이즈 AI 에이전트 구축의 선택지를 넓혀 줍니다. 대화, 추론, 분류, 검증은 각각 요구하는 모델 조건이 다를 수 있습니다.
Maven에게 기회는 고객 요청 해결에 필요한 맥락과 통제를 유지하면서, Intelligent Fields 같은 기능을 더 효율적으로 만들 수 있는 영역에서 Jev를 평가하는 것입니다.
반복되는 결정이 경험을 느리게 만드는 워크플로가 있다면 Maven에 알려 주세요. 계속 대기열이 바뀌는 티켓, 평가 비용이 많이 드는 필드, 너무 늦게 실행되는 품질 검사 등이 그 예입니다. 새로운 모델이 진가를 발휘할 수 있는 곳이 바로 이런 영역입니다.
이를 빠르게 진행할 수 있는 이유는 Charters, Segments, Intelligent Fields가 이미 중요한 결정을 정의하고 있기 때문입니다. 그 아래에 더 빠른 판단 계층을 적용하는 것은 며칠 만에 테스트할 수 있는 구성 변경이지, 몇 분기가 걸리는 재구축이 아닙니다.
귀사의 실제 대화로 확인하세요.
맞춤형 무료 데모를 신청하세요.
