LLM vs Jev, 무엇을 맡겨야 할까? 생성·판단·비용으로 비교하기

 

LLM(Large Language Model, 대규모 언어 모델)은 문맥을 읽고 문장과 코드 등을 생성하는 모델이다. Jev는 TypeSafe AI가 공개한 의사결정 모델로, 자연어를 읽고 미리 정의한 선택지·점수·확률을 반환한다. 고객에게 보낼 답장을 작성하는 일과 고객 문의를 어느 부서로 보낼지 고르는 일은 비슷해 보여도 필요한 출력이 다르다. TypeSafe AI의 System One 설명

 

TypeSafe AI는 2026년 9월 15일 Jev를 공개하며 빠른 판단을 소프트웨어에 연결하는 모델이라는 방향을 제시했다. 이 글은 특정 LLM 한 개와의 성능 대결이 아니라, 일반적인 생성형 LLM 사용 방식과 Jev의 역할을 비교한다. 기능·가격은 2026년 9월 28일 공식 문서 기준이며, 아래 계산과 업무 사례는 설명을 위한 예시다. 직접 수행한 성능 실험은 포함하지 않았다. 공식 공개 글

 

먼저 출력 방식의 차이를 살펴보고, 정확도와 비용을 읽는 기준을 정리한 다음, 두 모델을 실제 서비스에서 함께 배치하는 방법까지 연결해 보자.

1. 답장을 쓰는 일과 담당 부서를 고르는 일

다음과 같은 고객 문의가 들어왔다고 가정해 보자.

결제는 완료됐는데 서비스가 활성화되지 않았습니다. 사용 가능한 상태인지 확인해 주세요.

이 문의를 처리하려면 적어도 세 가지 작업이 필요하다. 어느 팀이 맡을지 판단하고, 실제 결제·이용 상태를 조회하고, 확인된 내용을 고객이 이해할 수 있는 문장으로 설명해야 한다. 판단, 조회, 설명은 서로 연결되지만 같은 작업은 아니다.

 

담당 팀의 후보가 billing, technical, account, other로 정해져 있다면 결과도 그중 하나면 된다. 반면 답장에는 상황에 맞는 어조, 확인된 사실, 다음 행동이 들어가야 한다. 가능한 답변 문장을 미리 모두 열거하기는 어렵다. 이 차이가 Jev와 생성형 LLM을 나누어 생각하는 출발점이다.

 

일반적인 자기회귀형 LLM은 입력 문맥과 지금까지 생성한 결과를 바탕으로 다음 토큰을 예측한다. 토큰은 모델이 처리하는 텍스트 조각이다. 이를 반복해 짧은 분류 결과부터 긴 설명, 프로그램 코드까지 만든다. 출력의 자유도가 높아 다양한 업무를 같은 인터페이스로 다루기 쉽다. Hugging Face의 텍스트 생성 설명

 

Jev는 애플리케이션이 정의한 답의 범위 안에서 판단하도록 설계됐다. 개발자는 평가할 자료인 state와 질문을 전달하고, 반환된 값을 코드에서 비교하거나 분기 조건으로 사용한다. 공식 문서의 System One은 이런 빠르고 구조화된 판단을 가리키는 TypeSafe의 모델 분류다. 사람의 사고 방식과 완전히 같다는 의미로 받아들일 필요는 없다. System One 개념 문서

그림 1. 출력이 필요한 모양부터 비교한다. LLM에도 구조화 출력 기능이 있으며, 그림은 대표적인 사용 방식의 차이를 나타낸다. Hugging Face, TypeSafe AI, Claude 공식 문서를 바탕으로 재구성.

2. LLM도 JSON을 만들 수 있는데 무엇이 다른가?

LLM이 자유로운 문장만 반환한다고 생각하면 비교가 어긋난다. Claude의 Structured Outputs처럼 JSON Schema에 맞춰 출력을 제한하는 기능이 이미 있다. 스키마를 문법 제약으로 바꾸어 허용된 형태만 생성하게 하는 방식이다. 도구 호출 인자의 형식을 강제하는 strict tool use도 별도로 제공한다. 지원 스키마 범위와 예외 조건은 제품 문서를 확인해야 한다. Claude 구조화 출력, Strict tool use

 

따라서 비교의 질문은 “JSON을 만들 수 있는가?”에서 더 나아가야 한다. 필요한 출력의 범위가 얼마나 넓은지, 제한된 판단을 얼마나 자주 반복하는지, 판단 확률을 어떻게 활용할 것인지가 중요하다.

비교 기준	생성형 LLM	Jev
대표적인 출력	설명·요약·코드·구조화 데이터	정의된 선택지, 단계에 따른 점수, 예·아니오 확률
답의 범위	자유로운 문자열을 포함한 넓은 범위	개발자가 질문으로 정한 범위
형식 제어	지원 제품에서 JSON Schema·도구 스키마 활용	Choice·Score·Noul이라는 정해진 출력 계약
주로 검토할 업무	답변 작성, 문서 요약, 코드 생성, 복합 과제	분류, 라우팅, 관련성 평가, 짧고 명확한 판단
판단 이유의 설명	문장 생성 가능. 설명의 정확성은 별도 확인	자유로운 설명문 생성용으로 설계되지 않음
가격 비교 단위	선택한 모델과 입력·출력·캐시 등 과금 조건	공식 가격표상 입력 토큰 과금, 출력 토큰 무료

예를 들어 고객 문의가 하루에 수백 건이고 대부분 자세한 답변을 작성해야 한다면, 이미 사용하는 LLM의 구조화 출력으로 분류까지 처리하는 구성이 간단할 수 있다. 반대로 대량의 메시지를 고정된 부서로 나누는 단계가 비용과 지연의 큰 부분을 차지한다면, 그 단계에 Jev를 붙여 비교 평가할 이유가 생긴다. 이는 보편적인 승자를 정하는 문제가 아니라 해당 서비스에서 반복되는 작업을 찾는 문제다.

3. Jev의 세 가지 질문: Choice, Score, Noul

Jev를 이해하는 가장 빠른 방법은 결과를 소비하는 코드를 떠올리는 것이다. 부서 이름은 switch나 조건문에, 관련성 점수는 정렬에, 특정 조건의 확률은 임계값 비교에 연결된다. 공식 문서는 질문을 다음 세 가지로 나눈다. Primitives 문서

질문 종류	물어보는 내용	반환값의 의미
Choice	“어느 부서가 처리할까?”	선택 결과 choice, 선택지별 probabilities, confidence
Score	“이 문서가 질문에 얼마나 관련 있을까?”	정의한 단계 사이의 score, 단계 설명 legend, 분포와 confidence
Noul	“명시적으로 환불을 요청했는가?”	예라고 판단하는 확률 noul, 0~1

Choice의 후보에는 업무상 필요한 예외도 포함해야 한다. 부서가 세 개뿐이라고 해서 모든 메시지가 그중 하나에 명확히 해당하지는 않는다. other나 검토 경로가 있으면 아직 분류 체계에 들어오지 않은 요청을 처리하기 쉬워진다.

 

아래는 문의 분류를 설명하기 위한 요청 본문 예시다. 실제 API 호출 결과나 검증된 한국어 정확도를 제시하는 코드는 아니다. 필드 구성은 공식 Quickstart를 따른다. TypeSafe AI Quickstart

{
  "model": "jev-1.13.0",
  "state": {
    "ticket": "결제는 완료됐는데 서비스가 활성화되지 않았습니다."
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "ticket의 문의를 처음 검토할 담당 부서를 고르세요.",
      "criteria": {
        "billing": "결제 승인, 청구 또는 중복 결제 문제",
        "technical": "결제 이후 서비스 기능이나 활성화 문제",
        "account": "계정 접근 또는 계정 정보 문제",
        "other": "위 기준에 해당하지 않거나 판단에 필요한 정보가 부족함"
      }
    }
  }
}

이 예시에서 중요한 것은 모델 이름보다 부서별 기준이다. “결제라는 단어가 있으면 billing”처럼 업무 의미와 어긋나는 분류를 원하지 않는다면, 결제 처리 문제와 결제 이후 서비스 문제를 구분해 주어야 한다. 어떤 팀을 첫 담당자로 삼을지는 회사의 실제 업무 규칙에 맞춰 정할 일이다.

 

여러 질문을 한 요청에 넣을 수도 있다. 다만 각 질문은 같은 자료를 독립적으로 평가한다. 첫 질문의 결과를 보고 두 번째 질문을 바꿔야 한다면 애플리케이션에서 후속 요청을 구성해야 한다. 질문을 한꺼번에 보냈다고 자동으로 단계적 추론이나 업무 순서가 만들어지는 것은 아니다. 여러 질문의 구성과 의존 관계

4. 형식이 맞는 답과 판단이 맞는 답은 별개다

technical이라는 값이 허용된 후보 중 하나라는 사실은 출력 형식이 맞다는 뜻이다. 실제로 기술지원팀이 처리할 문의인지는 정답 데이터나 업무 결과로 따로 확인해야 한다. 잘못된 부서를 선택해도 결과 문자열은 완벽하게 유효할 수 있다.

 

출력 오류를 나누면 평가가 선명해진다. 첫째는 JSON을 읽을 수 없거나 정의하지 않은 값이 오는 형식 오류다. 둘째는 형식은 맞지만 분류가 틀린 의미 오류다. 셋째는 분류가 맞아도 권한이 없는 작업을 실행하는 시스템 오류다. 어느 출력 방식을 선택하든 세 문제를 한 지표로 합치면 원인을 찾기 어렵다.

 

Jev의 Choice와 Score에는 확률 분포와 confidence가 함께 온다. 여기서 confidence는 분포가 얼마나 한 결과에 모여 있는지를 요약한 수치다. 선택된 항목의 확률과 같은 개념으로 단순히 바꾸어 읽으면 안 된다. Noul에는 별도 confidence 필드가 없고, noul 자체가 예라는 판단의 확률이다. Confidence 문서

 

확률을 읽는 예시도 구분해 보자. Noul이 0.5에 가깝다는 것은 예와 아니오 사이에서 불확실하다는 의미이지, 고객 만족도가 중간이라는 뜻이 아니다. 만족도처럼 정도를 평가하려면 단계별 의미를 정한 Score가 더 자연스럽다. 질문 유형 선택 기준

 

또한 “90%라고 예측한 사례들의 실제 정답 비율이 약 90%인가?”라는 보정 평가와 “이번 한 건이 반드시 맞는가?”는 다른 질문이다. TypeSafe도 확률 보정은 예측 집단을 대상으로 평가하며 개별 답의 정답을 보증하지 않는다고 설명한다. 확신이 큰 오답이 업무상 얼마나 발생하는지도 함께 측정해야 한다. 확률 보정의 의미

 

실제 서비스에서는 confidence가 낮은 문의를 상담원이나 다른 모델로 보내고, 기준을 충족하는 문의만 자동 분류하는 구성을 검토할 수 있다. 경계값은 0.8이나 0.9처럼 보기 좋은 숫자를 먼저 고르기보다, 실제 자료에서 허용할 오분류율과 자동 처리 비율을 보고 정하는 편이 낫다. Confidence를 이용한 분기

5. 속도와 비용: 공개 수치를 어디까지 읽을 것인가?

TypeSafe의 공개 글에는 Jev가 193.6배 빠르고 444.6배 저렴하다는 비교 수치가 등장한다. 이는 업체가 구성한 워크플로 평가 결과다. 회사도 실제 사용에서 기대할 개선 폭의 높은 쪽에 해당할 수 있다고 적었다. 미국 서부 중심의 측정 환경과 확률까지 출력하는 LLM 비교용 래퍼가 결과에 영향을 준다. 그대로 모든 서비스의 예상 절감률로 쓰기는 어렵다. 벤치마크와 측정 조건

 

같은 공개 글의 워크플로 평가는 사람이 확정한 분류 정답 대신 강한 외부 모델들의 평균 판단과 비교한 항목도 사용한다. 따라서 그래프를 볼 때는 응답 시간, 비용, 참조 모델과의 일치도, 실제 업무 정답률을 나누어 읽어야 한다. “형식에 맞는 출력”을 뜻하는 보장 역시 모든 사실 판단이 맞는다는 보장으로 확대할 수 없다. 공식 평가 설명

 

2026년 9월 28일 모델 문서상 Jev 1.13의 가격은 입력 100만 토큰당 0.042달러, 출력 토큰은 무료다. 입력에는 실제로 보내는 자료와 질문이 포함되므로, 고객 메시지 길이만으로 요금을 계산하면 빠진 부분이 생길 수 있다. Jev 모델·가격 문서

 

단순 계산을 해 보자. 호출 1회당 과금 대상 입력이 평균 2,000토큰이고 100만 회 호출한다면 총 20억 입력 토큰이다. 공개 단가를 그대로 적용한 모델 입력 비용은 다음과 같다.

2,000토큰 × 1,000,000회 = 2,000,000,000토큰
2,000,000,000 ÷ 1,000,000 × $0.042 = $84

84달러는 이 가정에서의 모델 입력 비용이다. LLM으로 넘기는 후속 요청, 재시도, 서버 운영, 사람이 검토하는 비용을 더하면 전체 처리 비용은 달라진다. LLM과의 비교에서도 특정 모델의 단가와 실제 입출력 길이를 넣어야 한다. 모델을 지정하지 않은 채 “LLM 대비 몇 배 저렴하다”는 하나의 숫자를 만드는 것은 의미가 약하다.

 

예를 들어 분류 모델을 추가한 뒤에도 거의 모든 요청이 LLM으로 넘어간다면 호출 단계가 하나 늘어난다. 반대로 많은 요청을 간단한 데이터 조회와 정해진 응답으로 끝낼 수 있다면 후속 생성 비용을 줄일 여지가 있다. 따라서 비교 단위는 토큰 가격뿐 아니라 정상적으로 해결한 업무 한 건의 총비용이어야 한다.

 

속도도 같은 방식으로 재야 한다. 모델 API 응답 시간과 사용자가 최종 답을 받는 시간은 다르다. 네트워크, 대기열, 검색, 후속 LLM 생성까지 포함한 전체 지연과 느린 요청의 지연을 함께 보아야 실제 체감 성능을 알 수 있다.

6. 함께 쓰는 구조: 분류는 Jev, 설명은 LLM

두 모델의 차이는 하나의 서비스에 배치했을 때 더 명확해진다. 고객지원 서비스를 예로 들면 API 서버가 요청을 받아 필요한 자료만 구성하고, Jev가 문의 유형을 판단한다. 애플리케이션은 그 결과를 이용해 정해진 조회 코드, 설명을 담당할 LLM, 상담원 검토 중 하나로 보낸다. TypeSafe의 공식 Intent routing 문서도 이런 분리 방식을 소개한다. Intent routing

그림 2. 고객지원에 두 모델을 연결하는 참조 설계. Jev는 판단 신호를 반환하고, 애플리케이션 코드가 분기와 실행 권한을 결정한다. TypeSafe의 Intent routing과 Confidence 공식 문서를 바탕으로 재구성.

가령 “내 주문의 배송 상태를 보여 달라”는 요청은 인증된 사용자의 주문을 조회해 정해진 화면에 표시하면 될 수 있다. “설치 중 오류가 발생했는데 어떻게 해결하느냐”는 요청은 관련 문서를 찾아 LLM이 설명하도록 보낼 수 있다. 분류 기준 밖의 요청이나 불확실한 사례는 추가 정보 수집 또는 검토 경로로 보낸다.

 

이때 모델의 선택 결과가 실행 권한을 만들어 주지는 않는다. 배송 조회로 분류됐더라도 해당 주문이 현재 사용자의 것인지 확인해야 한다. 환불 요청으로 분류됐더라도 실제 환불 가능 여부, 금액, 중복 처리 여부는 업무 코드와 데이터베이스에서 검사해야 한다. 분류기의 confidence가 높다는 이유로 이 검사를 생략하는 구조는 피해야 한다.

 

RAG(Retrieval-Augmented Generation, 검색 증강 생성)에도 비슷한 역할 분담을 적용할 수 있다. 검색기가 후보 문서를 찾으면 Jev로 각 문서의 관련성이나 근거 적합성을 평가하고, 코드가 선택한 문서를 LLM에 전달해 답변을 작성하게 하는 구성이다. 이 경우 Jev는 검색 인덱스나 최종 답변 모델 전체를 교체하지 않고, 중간 평가 단계에 들어간다. RAG 문서 평가 예제

 

검색 결과에 의심스러운 지시가 있는지 분류하는 것도 보조 신호로 활용할 수 있다. 다만 분류 결과만으로 프롬프트 인젝션이 완전히 차단된다고 가정해서는 안 된다. Jev 공식 한계 문서도 악의적으로 작성된 입력이 판단을 바꿀 수 있음을 명시한다. Jev 1.13의 알려진 한계

7. 도입 전에 확인할 제약과 평가 방법

현재 모델 문서에서 Jev 1.13은 텍스트 입력을 지원하며 이미지·음성·영상은 직접 받지 않는다. 요청 전체에는 64k 토큰, state와 가장 긴 질문의 합에는 32k 토큰 제한이 함께 적용된다. 영어가 주된 학습 언어이고 다른 언어의 성능은 동일하지 않다고 안내한다. 한국어 고객 문의에 쓸 계획이라면 실제 한국어 자료를 평가에 포함해야 한다. 입력·문맥·언어 지원

 

또한 공식 한계 문서는 숫자 계산, 날짜 비교, 복잡한 간접 추론, 불필요한 자료가 많은 입력 등을 주의할 대상으로 든다. 자유로운 문자열을 추출해야 한다면 정규식이나 생성형 모델로 후보를 얻고 Jev가 그중에서 선택하는 구성을 검토할 수 있다. 정확한 합계와 날짜 연산은 코드에 맡기는 편이 명확하다. 알려진 실패 유형

 

도입 평가는 다음처럼 작게 시작할 수 있다. 아래는 이 글에서 제안하는 비교 절차이며 공식 벤치마크 결과가 아니다.

1. 업무 하나를 고른다. 예를 들어 고객 문의의 첫 담당 부서 분류로 범위를 제한한다.
2. 정답 기준을 만든다. 담당자가 판단한 사례와 애매해서 검토가 필요한 사례를 함께 모은다. 중복 문장만 많은 자료는 피한다.
3. 비교 대상을 맞춘다. 현재 사용하는 LLM의 구조화 출력, 간단한 규칙, Jev에 동일한 입력과 같은 후보·업무 기준을 준다.
4. 실패를 나눠 기록한다. 형식 오류, 오분류, 검토로 넘긴 비율, 실제 처리 실패를 구분한다.
5. 전체 지연과 총비용을 측정한다. 평균뿐 아니라 95%의 요청이 그 이하에서 끝나는 p95 지연, 후속 호출과 검토 비용도 본다.
6. 임계값을 고정한 뒤 새 자료로 확인한다. 기준 조정에 사용한 자료와 최종 평가 자료를 나누고, 한국어 표현·축약어·복합 문의를 포함한다.

confidence 기준을 높이면 자동 처리 대상이 줄어들 수 있다. 중요한 것은 “정확도 몇 퍼센트” 하나가 아니라, 허용한 오류 수준에서 전체 업무 중 얼마를 자동 처리할 수 있는지다. 대부분을 사람에게 넘기면서 자동 처리된 소수의 정확도만 보고하면 운영 효과를 과대평가하기 쉽다.

 

운영에서는 모델 버전도 남겨야 한다. jev-latest 같은 별칭은 새 버전으로 이동할 수 있으므로, 평가 결과를 재현하거나 임계값을 유지해야 할 때는 버전 ID를 고정하는 방법을 검토할 수 있다. 공식 문서는 응답의 model 필드로 실제 응답한 버전을 확인할 수 있다고 안내한다. 모델 별칭과 버전 관리

8. 무엇을 선택해야 할까?

필요한 결과가 설명문, 요약, 코드처럼 열려 있다면 생성형 LLM이 자연스러운 출발점이다. 후보가 정해진 분류나 관련성 판단을 대량으로 반복한다면 Jev를 비교 대상에 넣을 수 있다. 정답을 규칙과 계산으로 정확하게 구할 수 있다면 해당 부분은 일반 코드로 처리하는 것이 명확하다.

 

많은 서비스에는 세 가지가 함께 들어간다. 코드는 데이터 접근과 실행 규칙을 책임지고, Jev 같은 판단 모델은 좁게 정의된 질문에 신호를 제공하며, LLM은 필요한 설명과 결과물을 생성한다. 어느 단계를 분리할지는 실제 오류, 지연, 비용을 측정한 뒤 결정하면 된다.

 

전체 서비스에서 이 구성요소가 들어갈 위치가 궁금하다면 LLM 시스템 아키텍처: 프론트엔드부터 RAG·에이전트·공급망까지를 함께 참고할 수 있다.

 

LLM과 Jev를 비교할 때 먼저 정할 것은 서비스가 받아야 할 답의 모양이다. 그다음 업무 한 건의 정확도·지연·총비용을 같은 조건으로 비교하면, 생성과 판단을 어디에 맡길지 판단하기 쉬워진다.