Jev는 AI 에이전트 비용을 줄일 수 있을까? 모델 라우팅부터 결과 검증까지 전체 비용 계산

요약

Jev 한 번의 호출 비용은 매우 낮습니다. 하지만 AI 에이전트에 저비용 의사결정 모델을 추가했다고 해서 전체 작업 비용이 자동으로 낮아지는 것은 아닙니다.

실제로 계산해야 할 것은 Jev가 일부 요청을 일반 코드나 더 저렴한 모델로 보낼 수 있는지, 주 모델에 전달되는 컨텍스트를 줄일 수 있는지, 결과 검증으로 불필요한 재시도를 막을 수 있는지입니다. 동시에 Jev 자체의 오판, 지연 시간, 사람 검토, 엔지니어링 유지보수에도 비용이 발생합니다.

이 글은 모델 라우팅, 컨텍스트 필터링, 결과 검증이라는 세 가지 일반적인 아키텍처를 나누어 살펴보고, Jev가 어떤 경우에 에이전트의 총비용을 낮추며 어떤 경우에는 API 호출 하나만 더 추가하는지 판단할 수 있는 전체 비용 계산 방법을 제시합니다.

---

많은 AI 에이전트의 비용 문제는 겉으로 보면 “주 모델이 너무 비싸다”는 문제처럼 보입니다. 그러나 실제로는 워크플로가 서로 다른 작업 유형을 구분하지 않는 것이 더 근본적인 원인인 경우가 많습니다.

“내 주문 상태를 확인해 줘” 같은 요청은 데이터베이스 조회 한 번이면 충분할 수 있습니다. 반면 “지난 6개월 동안 발생한 주문 이상 현상의 원인을 분석해 줘” 같은 요청은 여러 자료를 종합할 수 있는 강력한 모델이 필요할 수 있습니다. 또 어떤 요청은 정보가 부족하므로 어떤 모델도 호출하지 않고 먼저 사용자에게 추가 설명을 요청하는 편이 가장 합리적입니다.

모든 요청을 같은 강력한 모델로 바로 보내면 시스템은 단순해집니다. 하지만 일반 코드나 작은 모델로 처리할 수 있는 많은 작업에도 똑같이 높은 비용을 지불하게 됩니다.

Jev는 다른 접근법을 제안합니다.

Jev는 대화나 장문 생성용 모델이 아닙니다. 개발자가 state를 제공하고 타입이 지정된 질문들을 제시하면, Jev는 Choice, Score, Noul 같은 구조화된 판단과 확률을 반환합니다. 이후 비즈니스 로직이 도구를 호출할지, 더 저렴한 모델을 사용할지, 더 강력한 모델로 에스컬레이션할지, 사람에게 넘길지를 결정합니다. TypeSafe는 Jev를 소프트웨어 안에서 빠르고 구조화된 결정을 내리도록 특별히 설계된 최초의 System One 모델이라고 설명합니다. (typesafe.ai)

가격만 보면 이런 판단 비용은 무시해도 될 정도로 작아 보입니다.

TypeSafe가 Jev를 공개할 때 제시한 가격은 입력 100만 토큰당 0.042달러였고, 출력 토큰은 무료였습니다. 회사는 일반적인 엔드투엔드 지연 시간을 70~500밀리초라고 밝혔지만, 이 수치는 특정 지역과 테스트 조건에서 측정된 것이며 모든 배포 환경을 대표하지는 않는다고 설명했습니다. (typesafe.ai)

문제는 다음과 같습니다.

의사결정 한 번이 저렴하다고 해서 에이전트 워크플로 전체가 자동으로 저렴해지는 것은 아닙니다.

Jev가 비용을 줄일 수 있는지는 Jev 호출 자체의 단가가 아니라, 그 판단 이후의 작업이 실제로 달라지는지에 달려 있습니다.

AI 에이전트의 실제 청구서는 모델 요금만으로 구성되지 않는다

에이전트가 작업 하나를 완료할 때는 보통 적어도 여섯 종류의 비용이 발생합니다.

비용 항목	포함되는 내용
판단 비용	의도 분류, 모델 라우팅, 위험 평가, 도구가 필요한지에 대한 판단
컨텍스트 비용	대화 기록, 검색 결과, 도구 출력, 로그, 문서
생성 비용	주 모델의 입력, 출력, 추론 토큰
재시도 비용	모델 타임아웃, 도구 실패, 형식 오류, 재생성
사람 비용	검토, 수정, 예외 처리, 고위험 작업 승인
오판 비용	잘못된 라우팅, 누락된 정보, 잘못 실행된 작업을 복구하는 비용

따라서 작업당 비용은 더 완전하게 다음과 같이 표현할 수 있습니다.

총비용
= 판단 비용
+ 컨텍스트 처리 비용
+ 후속 모델과 도구 비용
+ 재시도 및 폴백 비용
+ 사람 검토 비용
+ 잘못된 판단으로 인한 복구 비용

Jev 호출 비용은 대개 이 총액의 아주 작은 일부에 불과합니다.

Jev가 실제로 줄일 수 있는 것은 뒤에 이어지는 비용입니다. 비싼 모델 호출 한 번을 피하거나, 불필요한 컨텍스트를 보내지 않거나, 실패한 작업을 다시 실행하지 않도록 하거나, 정말 불확실한 경우만 사람이 검토하도록 만들 수 있습니다.

가장 일반적인 비용 절감 방식은 세 가지로 나눌 수 있습니다.

1. 사전 라우팅: 먼저 판단한 뒤 무엇을 호출할지 결정한다.
2. 컨텍스트 필터링: 주 모델을 호출하기 전에 불필요한 정보를 제거한다.
3. 사후 검증: 저렴한 모델이 먼저 처리하고 검증에 실패한 경우에만 에스컬레이션한다.

---

첫 번째 비용 절감 방식: Jev를 주 모델 앞에 두고 라우터로 사용하기

가장 직접적인 아키텍처는 다음과 같습니다.

사용자 요청
   ↓
Jev가 의도, 복잡도, 위험을 판단
   ↓
일반 코드 / 저렴한 모델 / 강력한 모델 / 사람

TypeSafe의 공식 라우팅 패턴도 같은 생각을 따릅니다. 모든 요청이 같은 LLM으로 들어갈 필요는 없습니다. 일부는 결정론적 코드로, 일부는 특화 모델로 보내고, 복잡하거나 위험한 요청은 더 비싼 모델이나 사람에게 에스컬레이션할 수 있습니다. (docs.typesafe.ai)

예를 들어 고객 지원 에이전트는 먼저 다음을 판단할 수 있습니다.

• 단순한 주문 상태 조회인가?
• 환불이나 차지백이 관련되어 있는가?
• 청구, 기술 지원, 영업 중 어느 팀으로 가야 하는가?
• 사람의 개입이 필요한가?
• 정말 프런티어급 추론 모델이 필요한가?

Jev는 이런 판단만 담당합니다.

데이터베이스 조회, 환불 처리, 답변 생성, 사람의 티켓 처리는 여전히 주변 시스템이 수행합니다.

라우팅 판단 한 번은 얼마나 저렴한가

자료에 기록된 실제 API 테스트에서는 지원 티켓 10건을 하나의 요청에 넣었습니다. 각 티켓마다 라우팅과 사람 검토 필요 여부를 판단해 총 20개 질문을 처리했습니다.

• 총 입력: 2,571토큰
• 호출 시간: 약 405밀리초
• 공개 가격 기준 총비용: 약 0.000108달러
• 티켓당 평균 비용: 약 0.0000108달러
• 같은 토큰 구조로 환산: 약 티켓 100만 건당 10.8달러

같은 티켓 10건을 10번의 개별 호출로 보냈을 때 총 소요 시간은 약 3,664밀리초였습니다. 주요 라우팅 결과는 같았지만, 일부 경계 사례의 확률은 눈에 띄게 달라졌습니다. 이는 배치 처리가 요청 오버헤드를 크게 줄일 수 있음을 보여 줍니다. 그러나 모든 업무 영역에서의 라우팅 정확도를 증명하는 것은 아니며, 고위험 게이트에 같은 임계값을 그대로 사용할 수 있다는 뜻도 아닙니다.

모델 라우팅의 손익분기점

다음과 같이 가정합니다.

• C_high: 강력한 모델을 한 번 호출하는 비용
• C_low: 저렴한 모델을 한 번 호출하는 비용
• C_jev: Jev 판단 비용
• P_code: 일반 코드로 완료할 수 있는 요청 비율
• P_low: 저렴한 모델로 완료할 수 있는 요청 비율
• P_error: 잘못된 라우팅 때문에 복구가 필요한 요청 비율

모든 요청을 강력한 모델로 바로 보낸다면 기대 비용은 다음과 같습니다.

C_direct = C_high

라우팅을 추가한 뒤의 기대 비용은 다음과 같습니다.

C_route
= C_jev
+ P_low × C_low
+ P_high × C_high
+ P_error × C_repair

따라서 라우팅이 실제로 비용을 줄이는 조건은 다음과 같습니다.

피한 강력한 모델 비용
>
Jev 비용 + 잘못된 라우팅으로 인한 복구 비용

Jev 자체가 저렴하므로 최종 경제성은 보통 두 가지 질문에 의해 결정됩니다.

1. 실제로 강력한 모델을 피할 수 있는 요청이 얼마나 많은가?
2. 잘못된 라우팅의 결과는 얼마나 비싼가?

설명을 위한 가상 계산

아래 가격은 계산 원리를 설명하기 위한 가정일 뿐, 특정 모델의 실제 가격이 아닙니다.

• 강력한 모델: 호출당 0.01달러
• 저렴한 모델: 호출당 0.002달러
• Jev: 호출당 약 0.0000108달러
• 총 요청량: 100,000건

라우팅 이후의 분포를 다음과 같이 가정해 보겠습니다.

• 20%는 일반 코드가 완료
• 50%는 저렴한 모델로 이동
• 30%는 강력한 모델로 이동
• 추가로 5%는 오류나 실패 때문에 강력한 모델을 한 번 더 호출해 복구해야 함

그러면 다음과 같습니다.

항목	비용
라우팅 없음: 모든 요청이 강력한 모델 사용	1,000달러
Jev 판단 100,000회	1.08달러
저렴한 모델 50,000회	100달러
강력한 모델 30,000회	300달러
복구 호출 5,000회	50달러
라우팅 후 총비용	451.08달러

이 가정에서는 총비용이 약 55% 감소합니다.

하지만 저렴한 모델로 보낼 수 있는 요청이 10%뿐이고, 90%가 결국 강력한 모델까지 가며, 5%가 추가 복구를 필요로 한다면 총비용은 약 971.08달러가 됩니다.

절감률은 약 2.9%입니다.

개발, 모니터링, 임계값 보정, 추가 지연 시간까지 포함하면 이런 라우팅 계층을 만드는 것이 가치가 없을 수도 있습니다.

따라서 가장 먼저 측정해야 할 것은 Jev의 단가가 아니라 다음입니다.

실제 트래픽 중 강력한 모델이 정말 필요하지 않은 비율은 얼마인가?

---

두 번째 비용 절감 방식: 주 모델에 보내는 컨텍스트 줄이기

컨텍스트는 에이전트 비용의 또 다른 큰 원천입니다.

오랫동안 실행되는 에이전트에는 다음과 같은 정보가 쌓일 수 있습니다.

• 대화 기록
• 여러 차례의 도구 출력
• Bash 또는 빌드 로그
• 웹페이지 본문
• 검색으로 가져온 문단
• 더 이상 유효하지 않은 계획과 중간 결과

많은 시스템은 이 모든 정보를 주 모델에 다시 보냅니다. 현재 작업에 필요한 것이 일부뿐이어도 모든 입력 토큰에 비용이 발생합니다.

Jev를 주 모델 앞에 두면 다음을 판단할 수 있습니다.

• 어떤 검색 결과가 현재 질문과 관련 있는가?
• 어떤 도구 출력이 이후에도 필요할 가능성이 있는가?
• 어떤 과거 메시지에 제약 조건이나 미완료 작업이 포함되어 있는가?
• 어떤 문단에 prompt injection이 포함되어 있을 수 있는가?
• 어떤 정보를 제거하거나 요약만 남길 수 있는가?

TypeSafe의 공식 use-case map에도 컨텍스트 선택, semantic retrieval, RAG 문단 필터링, agent harness 내부의 컨텍스트 관리가 포함되어 있습니다. (docs.typesafe.ai)

금전적 효과는 대략 다음과 같이 계산할 수 있습니다.

컨텍스트 순편익
= 제거한 토큰 × 주 모델 입력 단가
- Jev 필터링 비용
- 누락된 정보로 인한 재검색 및 재시도 비용

앞의 두 항은 계산하기 쉽습니다. 가장 자주 빠지는 것은 세 번째 항입니다.

관련 없는 로그 수십 줄을 제거하는 것은 대체로 명확한 이익입니다. 하지만 과거 메시지에 있던 사용자의 핵심 제약을 삭제하면 주 모델이 완전히 잘못된 결과를 만들 수 있고, 이후 재검색, 추가 모델 호출, 수동 수정이 필요할 수 있습니다.

한 번의 재실행이 그전의 여러 성공적인 컨텍스트 필터링에서 얻은 절감액을 모두 소모할 수 있습니다.

따라서 Jev는 어떤 자료가 관련 있을 가능성이 높은지 판단하는 용도에는 적합하지만, 유일한 영구 메모리 관리자로 사용하기에는 적합하지 않습니다. 운영 시스템은 최소한 다음을 갖춰야 합니다.

• 시스템 지시, 사용자의 필수 제약, 안전 규칙을 항상 보존한다.
• 제거한 내용의 인덱스나 원문을 저장한다.
• 정보가 부족할 때 에이전트가 생략된 자료를 다시 가져올 수 있게 한다.
• 단순한 압축률이 아니라 후속 작업의 성공률로 평가한다.

컨텍스트 압축에서 더 의미 있는 수치는 다음 합계입니다.

압축 후 총토큰
+ 재검색 토큰
+ 정보 누락으로 발생한 재시도 토큰

단순히 “이번 단계에서 몇 토큰을 줄였는가”만 봐서는 안 됩니다.

---

세 번째 비용 절감 방식: 저렴한 모델이 먼저 처리하고 Jev가 결과를 검증하기

또 다른 일반적인 아키텍처에서는 Jev가 어떤 모델을 호출할지 정하지 않습니다. 대신 다른 모델의 출력을 검사합니다.

흐름은 다음과 같습니다.

저렴한 모델이 결과 생성
       ↓
Jev가 사실 근거, 추출 필드, 정책 위험, 완료도를 확인
       ↓
통과: 결과 사용
실패: 재시도, 강력한 모델로 에스컬레이션, 또는 사람에게 전달

TypeSafe는 이런 종류의 패턴을 Universal Verification이라고 부릅니다. 공식 자료에는 RAG 인용 검증, 도구 호출 검사, 결과 품질 판단, 구조화 데이터 추출 캐스케이드가 포함됩니다. 공식 SDE Cascade 예시는 “저렴한 모델로 추출 → Jev가 필드별 검증 → 위험 신호가 있을 때만 추론 모델로 에스컬레이션”하는 구조를 사용합니다. 이는 공급업체 cookbook의 결과이므로 모든 추출 작업에서 같은 비용 절감이 나온다는 증거로 해석해서는 안 됩니다. (docs.typesafe.ai)

이 캐스케이드의 기대 비용은 대략 다음과 같습니다.

C_cascade
= C_low
+ C_jev
+ P_escalate × C_high
+ C_failure

가장 중요한 변수는 P_escalate입니다. 즉, 저렴한 모델의 결과 중 결국 강력한 모델로 보내야 하는 비율입니다.

실패 비용을 제외하면, 캐스케이드는 다음 조건에서 모든 요청을 강력한 모델로 보내는 것보다 저렴합니다.

P_escalate
<
1 - (C_low + C_jev) / C_high

앞과 같은 가상 가격을 사용하겠습니다.

• 강력한 모델: 0.01달러
• 저렴한 모델: 0.002달러
• Jev: 약 0.0000108달러

에스컬레이션 비율의 손익분기점은 약 80%입니다. 즉, 최종적으로 에스컬레이션되는 요청이 약 80% 미만이면 명목상 모델 비용은 “모든 요청에 강력한 모델 사용” 기준보다 낮을 수 있습니다.

하지만 이것은 가격의 손익분기점이지 품질의 손익분기점은 아닙니다.

“강력한 모델에 근접”과 “강력한 모델과 동일한 품질”은 서로 다른 비용 목표다

사전 등록된 독립 평가에서는 CLINC150 샘플에서 Jev에서 강력한 모델로 이어지는 캐스케이드를 테스트했습니다.

• 최종 정확도가 강력한 모델보다 1%포인트 낮아도 되는 경우, Jev는 약 22%의 요청만 에스컬레이션하면 됐습니다.
• 강력한 모델과 정확히 동일한 정확도를 요구한 경우, 모든 요청을 에스컬레이션해야 했고 사실상 “항상 강력한 모델 호출” 구조로 퇴화했습니다.

연구진은 이 결과를 “더 낮은 비용으로 강력한 모델의 품질에 근접한다”로 읽어야 하며, “더 적은 호출로 동일한 정확도를 얻는다”로 해석해서는 안 된다고 강조했습니다. 이 실험은 200개 샘플, 하나의 데이터셋, 하나의 서비스 경로만 사용했으므로 다른 에이전트에 직접 일반화할 수 없습니다. 그러나 품질 목표를 조금 높이는 것만으로도 에스컬레이션 비율이 크게 뛸 수 있다는 중요한 경제적 패턴을 보여 줍니다. (github.com)

따라서 캐스케이드 평가에서 다음만 보고해서는 안 됩니다.

• 강력한 모델 호출을 몇 번 피했는가?
• 트래픽의 몇 %를 자동 처리했는가?

다음도 함께 보고해야 합니다.

• 자동 처리된 부분의 정확도
• 최종 엔드투엔드 작업 성공률
• 모든 요청을 강력한 모델로 보낼 때와 비교한 품질 손실
• 후속 실행에서 어떤 오류가 확대되는지

---

한 번의 호출에서 여러 질문을 하는 것이 요청 자체를 배치하는 것보다 더 중요한 경우가 많다

Jev는 같은 state에 여러 질문을 하고 답을 병렬로 받을 수 있습니다. 공식 문서는 여러 판단을 하나의 모호한 질문 안에 넣기보다 복잡한 결정을 원자적 질문으로 나누고, 결과를 코드에서 조합할 것을 권장합니다. (docs.typesafe.ai)

예를 들어 다음처럼 묻는 대신,

이 지원 티켓은 어떻게 처리해야 하는가?

다음과 같이 나눌 수 있습니다.

• 어느 업무 큐로 보내야 하는가?
• 환불을 명시적으로 요청하는가?
• 차지백, 법적 조치, 규제 기관을 언급하는가?
• 어느 긴급도 구간에 속하는가?
• 사람의 개입이 필요한가?
• 더 강력한 모델을 호출할 가치가 있는가?

자료의 측정 결과에서는 같은 state에서 질문 수를 1개에서 8개, 다시 32개로 늘려도 워밍업 이후 지연 시간은 대략 같은 350~400밀리초 범위에 머물렀습니다. 입력 토큰은 질문 수에 따라 증가했지만 네트워크 왕복 횟수는 선형으로 늘지 않았습니다.

따라서 합리적인 패턴은 다음과 같습니다.

현재 단계에 정말 필요한 원자적 질문을 한 번의 요청에서 모두 묻고, 각 판단마다 별도 API 호출을 보내지 않는다.

그러나 배치한다고 해서 모든 사용자, 문서, 작업을 하나의 거대한 state에 넣어야 한다는 뜻은 아닙니다. 지원 티켓 실험에서도 배열 기반 배치는 주요 분류를 유지했지만 일부 경계 확률을 바꾸었습니다.

배치 전략은 실제 애플리케이션의 데이터 분포에서 계속 검증해야 합니다.

---

쉽게 빠뜨리는 네 가지 숨은 비용

1. confidence는 정확도가 아니다

타입이 지정된 출력은 응답이 인터페이스에 맞는다는 것을 보장할 수 있습니다. 하지만 비즈니스 판단이 맞다는 것을 보장하지는 않습니다.

한 독립 평가에서는 200개 샘플 중 102개에서 Jev의 confidence가 정확히 1.0이었고, 그중 6개는 오답이었습니다. 연구진은 Jev의 confidence가 작은 LLM의 자기 보고 confidence보다 자신의 오류를 더 잘 순위화한다는 증거도 찾지 못했습니다. (github.com)

따라서 운영 로직을 다음과 같이 단순화해서는 안 됩니다.

if (confidence === 1) {
  executeDestructiveAction();
}

더 안전한 방법은 다음과 같습니다.

• 구체적인 판단 규칙이 필요하다면 옵션별 probabilities를 우선 사용한다.
• 자체 라벨 데이터셋에서 임계값을 선택한다.
• 위험 수준별로 다른 임계값을 적용한다.
• 결제, 삭제, 정지 같은 작업에는 사람의 확인을 남긴다.
• 모델 버전, 확률, 실제 결과를 기록해 드리프트를 추적한다.

또 다른 사전 등록된 보정 평가에서도 결과는 엇갈렸습니다. CLINC150의 ECE는 0.0204였지만 Banking77에서는 0.0936이었고, 후자에서는 체계적인 과신이 나타났습니다. 이는 보정 성능이 작업과 코퍼스에 따라 달라지며, 한 데이터셋에서 조정한 임계값을 다른 업무 영역에 그대로 옮기면 안 된다는 뜻입니다. (systemonemodels.org)

2. 잘못된 라우팅은 공짜가 아니다

라우터가 단순한 요청을 강력한 모델로 보내면, 주된 결과는 절감 기회 하나를 놓치는 것일 수 있습니다. 하지만 복잡한 요청을 일반 코드로 잘못 보내면 잘못된 답변, 중복 작업, 사용자 이탈로 이어질 수 있습니다.

고위험 작업에서는 오판 한 번의 비용이 관련된 모든 모델 호출 비용보다 더 클 수 있습니다.

따라서 다음 네 가지 오류를 따로 추적하는 것이 좋습니다.

• 잘못된 에스컬레이션: 저렴하게 처리할 수 있는 요청을 강력한 모델로 보냄
• 잘못된 다운그레이드: 강력한 모델이 필요한 요청을 저렴한 경로에 배정함
• 잘못된 통과: 검증기가 결함 있는 결과를 놓침
• 잘못된 차단: 올바른 결과를 재시도나 사람 검토로 보냄

하나의 종합 정확도 수치만으로는 이 네 가지 비용을 표현할 수 없습니다.

3. 지연 시간과 실패도 비용이다

자료에서 워밍업된 직렬 호출은 대부분 340~450밀리초였습니다. 24개의 동시 요청을 보낸 한 테스트에서는 중앙 지연 시간이 약 1.2초로 올라갔고 전송 실패도 3건 발생했습니다. 이는 특정 환경에서 진행한 작은 테스트로, 공식 서비스의 일반적인 가용성을 설명하지는 않습니다. 그러나 운영 아키텍처가 의사결정 계층을 절대 실패하지 않는 로컬 함수처럼 취급해서는 안 된다는 점은 보여 줍니다.

최소한 시스템은 다음을 미리 정해야 합니다.

• 타임아웃 시 fail-open, fail-closed, 사람 에스컬레이션 중 무엇을 선택할지
• 재시도할지, 몇 번까지 할지
• Jev가 사용할 수 없을 때 주 모델을 직접 호출할지
• 라우팅 서비스 실패가 에이전트 전체를 막을 수 있는지
• p95와 p99 지연 시간이 제품의 상호작용 예산 안에 들어오는지

제3자의 사전 등록 평가에서는 Jev 호출 중앙값이 약 0.42~0.44초였습니다. 다만 연구진은 이 값이 특정 클라이언트, 게이트웨이, 지역, 부하 조건을 반영한 것이며 순수한 모델 추론 속도는 아니라고 명시했습니다. (github.com)

4. 이미 라벨 데이터가 있다면 Jev가 가장 저렴한 선택은 아닐 수 있다

Jev의 중요한 장점 중 하나는 콜드 스타트입니다. 라벨 데이터가 없어도 자연어 설명만으로 zero-shot 판단을 할 수 있습니다.

하지만 안정적인 업무 흐름에 이미 사람이 라벨링한 예시가 많이 쌓였다면 전통적인 작은 모델이 더 매력적일 수 있습니다.

사전 등록된 Banking77 평가에서는 10,003개 예시로 학습한 고정 bge-small 임베딩 모델과 로지스틱 회귀가 0.933의 정확도를 기록한 반면, Jev는 0.832였습니다. 테스트 하드웨어에서 인코더는 약 9밀리초에 실행됐고 요청별 API 비용도 없었습니다. 연구진은 정보 조건이 서로 달랐다는 점도 강조했습니다. 인코더는 같은 분포의 대규모 라벨 데이터셋을 본 반면, Jev는 zero-shot으로 평가됐습니다. 따라서 이는 같은 조건에서의 모델 능력 비교가 아니라 현실적인 배포 대안 간의 비교였습니다. (github.com)

실용적인 발전 경로는 다음과 같을 수 있습니다.

단계	검토할 만한 선택지
라벨 데이터가 없고 규칙이 자주 바뀜	Jev 같은 zero-shot 의사결정 모델
소량의 라벨 데이터가 쌓임	Jev + 임계값 보정 + 사람 검토
라벨이 안정적이고 큰 데이터셋이 있음	로컬 인코더, 분류기, 또는 파인튜닝 모델
롱테일 작업이 계속 변함	Jev를 폴백으로 유지

Jev는 콜드 스타트 가속기이자 롱테일 의사결정 계층으로 특히 유용할 수 있습니다. 그러나 모든 안정적인 분류 작업의 영구적인 최종 해법일 필요는 없습니다.

---

출시 전에 자체 경제성을 계산하는 방법

실제 애플리케이션의 과거 작업을 모아 오프라인에서 다음 세 경로를 비교합니다.

A. 모든 작업을 강력한 모델로 보냄
B. Jev 라우팅 → 코드 / 저렴한 모델 / 강력한 모델
C. 저렴한 모델 → Jev 검증 → 필요할 때 강력한 모델로 에스컬레이션

최소한 다음 지표를 기록해야 합니다.

지표	답해야 할 질문
평균 총비용	성공적으로 완료된 작업 하나에 실제로 얼마가 들었는가?
강력한 모델 호출 비율	Jev가 비싼 호출을 실제로 몇 건 막았는가?
자동 처리 범위	사람과 강력한 모델을 모두 피한 작업은 몇 건인가?
자동 처리 정확도	자동 처리된 작업 중 실제로 맞은 것은 몇 건인가?
에스컬레이션 비율	캐스케이드 작업 중 결국 강력한 모델로 간 비율은 얼마인가?
재시도 비율	라우팅이나 검증 오류로 추가 호출이 몇 번 발생했는가?
사람 검토 비율	사람의 작업이 줄었는가, 아니면 위치만 바뀌었는가?
p95 지연 시간	사용자가 실제로 경험한 꼬리 지연 시간은 얼마인가?
엔드투엔드 성공률	최종 작업 품질이 기준보다 낮아지지 않았는가?

가장 의미 있는 지표는 “Jev 판단 정확도”가 아니라 다음입니다.

성공적으로 완료된 작업 하나당 비용

의사결정 API가 매우 저렴하더라도 더 많은 재시도, 사람 검토, 잘못된 실행을 만든다면 에이전트의 경제성은 오히려 나빠질 수 있습니다.

---

Jev를 우선 시험할 가치가 있는 경우

다음 조건을 많이 만족할수록 Jev가 실제 가치를 만들 가능성이 높습니다.

• 요청량이 많고 판단이 자주 필요하다.
• 작업 경계가 명확하고 단일 단계의 의미 판단으로 나눌 수 있다.
• 많은 요청을 일반 코드나 저렴한 모델이 처리할 수 있다.
• 전용 분류기를 학습할 만큼 라벨 데이터가 아직 충분하지 않다.
• 주 모델 호출이 판단 호출보다 확실히 비싸다.
• 오류를 에스컬레이션, 재시도, 사람 검토로 제한할 수 있다.
• 시스템이 확률, 임계값, 최종 결과를 기록할 수 있다.
• 판단 기준을 빠르게 추가하거나 바꿔야 한다.

반대로 다음 상황에서는 Jev 추가를 첫 번째 선택으로 삼지 않는 편이 좋습니다.

• 거의 모든 요청이 결국 강력한 모델을 필요로 한다.
• 트래픽이 적어 API 절감액이 엔지니어링 복잡성을 정당화하지 못한다.
• 작업에 다단계 추론, 산술, 날짜 비교, 장문 생성이 필요하다.
• 잘못된 판단이 바로 되돌릴 수 없는 작업을 실행할 수 있다.
• 크고 안정적인 라벨 데이터셋이 이미 있어 로컬 소형 모델을 만들 수 있다.
• 신뢰할 수 있는 폴백 및 사람 검토 경로를 구축할 수 없다.
• 공식 데모의 임계값을 그대로 운영 환경에 복사하려 한다.

---

결론: Jev가 아끼는 것은 판단 비용이 아니라 그 뒤의 작업이다

Jev 한 번의 호출은 실제로 저렴합니다. 하지만 그것만으로 AI 에이전트의 비용이 줄어드는지는 결정되지 않습니다.

Jev의 진짜 가치는 원래라면 모든 요청을 하나의 강력한 모델에 보냈을 워크플로를 나눌 수 있다는 데 있습니다.

• 단순한 요청은 일반 코드로 보낸다.
• 반복적인 요청은 저렴한 모델로 보낸다.
• 복잡한 요청은 강력한 모델로 보낸다.
• 불확실한 요청은 사람에게 보낸다.
• 중복 컨텍스트는 보내지 않는다.
• 결함 있는 결과는 사용자에게 도달하기 전에 막는다.

Jev를 주 모델 앞에 두었지만 모든 요청이 결국 그대로 주 모델까지 간다면, API 호출 하나를 더 추가했을 뿐입니다.

비싼 호출, 컨텍스트 크기, 재작업을 안정적으로 줄인다면 그때 비로소 실제 비용 레버가 됩니다.

따라서 물어야 할 질문은 다음이 아닙니다.

Jev 호출 한 번은 얼마나 저렴한가?

대신 다음을 물어야 합니다.

이 판단 이후 시스템이 더 이상 하지 않아도 된 비싼 작업은 무엇인가?

이것이 AI 에이전트가 계산해야 할 전체 비용입니다.