# 말을 하지 않는 AI, Jev는 무엇이 다른가? LLM과 함께 고려하는 효율화와 비용 절감

> https://bookfactory.kr/board/news/17663
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-09-18T14:12:23.399Z

---

![見出し画像](https://assets.st-note.com/production/uploads/images/314949451/rectangle_large_type_2_31baad7df3ffbb303ae1441338300f18.png?width=1280)

2026년 9월 18일 업데이트

2026년 9월 15일, TypeSafe AI가 AI 모델 “제브(Jev)”의 조기 액세스를 발표했습니다.

타입세이프 AI는 전 오픈AI 연구원인 디오고 알메이다(Diogo Almeida)氏らが 공동 창업한 AI 기업입니다. 알메이다 氏は、ChatGPT의 기초가 된 AI를 사람의 지시를 따르게 하는 연구와 InstructGPT의 개발에 참여한 인물입니다. 창업자들이 주목하는 것은 소프트웨어가 그대로 사용 가능한 판단을 돌려 업무 자동화를 지원하는 AI 개발입니다. 발표에 따르면, 사업 및 기술의 상세 내용을 공개하지 않는 “ステルス(ステル스)”의 형태로 2년간 개발을 진행했으며, 그 결과로 처음 공개한 모델이 Jev입니다. 개발의 배경

그러한 배경을 가진 Jev가 화제인 것을 보고, 저 또한 “이것은 제대로 공부하지 않으면 안 된다”고 생각하여 발표 기사와 공식 문서들을 읽기 시작했습니다. “말을 하지 않는 AI”가 무엇인지, 평소에 사용하고 있는 생성 AI와 무엇이 다른지. 이 기사에서는 읽어 내려갈수록 알게 된 시스템과, 그로부터 생각해 낸 활용 방안을 정리했습니다. 특히 흥미로웠던 점은 Jev와 다양한 LLM을 결합하여 업무에 따라 역할을 분담하는 가능성입니다. 작은 판단은 Jev에게 맡기고, 글을 만드는 상황이나 복잡한 검토가 필요한 상황에서는 LLM을 사용하는 것입니다. 이러한 조합 방식에 따라 처리 효율이나 비용을 크게 변화시킬 수 있을 것입니다.

예를 들어, 온라인 상점에 “상품이 아직 배송되지 않았습니다. 내일 사용할 예정이었으나”라는 문의가 접수되었다고 가정해 보겠습니다. 이 경우 필요한 것은 정중한 답변을 작성하는 것뿐만이 아니며, 배송 담당자에게 전달해야 할지, 급하게 확인해야 할지, 사람의 조치가 필요한지 등 여러 가지 판단이 필요합니다. 답변을 작성하기 전에 이미 여러 가지 결정을 내려야 합니다.

그는 “문맥을 읽고 다음 처리를 결정하기 위한 판단 자료를 제공하는” 역할을 수행하는 Jev이다.

TypeSafe AI는 이렇게 소프트웨어 사용 가능성을 판단하는 모델을 “System One Model”이라고 부릅니다. 하지만 여기서 의문이 듭니다. 일반적인 생성 AI에도 “배송, 청구, 기타 중에서 선택해 줘”라고 요청할 수 있는데, 별도의 AI를 사용하는 의미는 어디에 있는 걸까요.

![画像](https://assets.st-note.com/img/1789717191-xHZNDEkXesA7d3z5GJF9R2VM.jpg?width=1200)

![画像](https://assets.st-note.com/img/1789717191-twhkolBjJY94uEaTQMARLcWI.png?width=1200)

제작한 기사 내용을 Gamma에 입력하여 자동으로 슬라이드를 제작했습니다. 슬라이드 내용이 보기 좋으셨으면 좋겠습니다.

## Jev는 소프트웨어에 통합하는 판단 계수입니다.

제브는 문맥을 읽고, 지정된 선택지나 평가를 반환하는 AI 모델입니다. 문의 관리 시스템 등에 통합될 때 “판단 계수”와 유사한 역할을 한다고 생각하시면 이해하기 쉬울 것입니다.

개발자는 프로그램에서 Jev에 정보를 보내고 결과를 받습니다. 그 창구 역할을 하는 것이 “API”입니다. 담당자가 매번 채팅 화면에 문장을 붙여넣는 대신, 시스템에서 호출할 수 있는 방식입니다. 모델과 API의 공식 설명은 문장, 질문, 답변의 범위를 포함합니다. 앞선 문의와 같은 경우에는 이용자가 다음과 같이 설정합니다.

> 
> 
> 상품이 아직 배송되지 않았습니다. 내일 사용할 예정이었으나, 문의의 주요 내용은 배송입니다. 배송 확률은 85%이며, 청구 10%, 기타 5%입니다.
> 

※ 실제 측정값은 아니며, 시스템 작동 방식을 설명하기 위한 예시입니다. 숫자 값은 가상입니다.

선택형 작문이 아닌, 선택지별 확률도 기재하는 마크 시트와 유사한 방식으로 답하는 것입니다. “상품이 도착할 예정일”을 임의로 적고 반송하는 방식은 아닙니다. 객관식 질문의 형식에 따라 이 결과를 받은 프로그램이 사내 규정에 따라 배송 담당에게 전달합니다. 판단이 명확하지 않다면 확인을 기다립니다. Jev가 판단 자료를 제공하고, 실제로 무엇을 할지는 프로그램이 관리하는 방식으로 분담합니다. 組み込み方の公式ガイド(조합 방식 공식 가이드)

Choice, Score, NoulJev에는 “선택하는”, “단계별로 평가하는”, “조건에 해당하는 것을 보는”이라는 세 가지 판단 기능이 있습니다. 공식적으로는 “프리미티브”라고 불리는 질문 유형입니다. 모델 전체의 동작 모드를 전환하는 대신, 질문마다 유형을 지정하고 한 번의 호출에서 조합하여 사용할 수 있습니다.

![画像](https://assets.st-note.com/img/1789717033-7hGXN0FZ5H48V2iPrldfJDCU.png?width=1200)

예를 들어, 긴급도 설문에서는 0을 “기한 미기재”, 1을 “기한은 있지만 긴급성은 판단할 수 없음”, 2를 “사용 기한이 임박하여 대응을 서두르고 있음”으로 이용자가 정의합니다. 점수는 각 단계별 확률을 나타내며, 이를 종합한 숫자를 반환합니다. 따라서 1.8과 같은 중간 값도 포함될 수 있습니다. 이는 정답률이 아닌, 정해진 척도에 따라 어느 위치에 놓여있는지에 대한 평가입니다. 표의 숫자는 모두 설명용 가정을 나타냅니다. 단계 평가 규격인 Noul은 “예/아니오”로 질문되는 조건에 대해 “예”의 확률을 0부터 1까지 반환합니다. 0.5는 양쪽 모두 동등한 기대치를 의미하며, 점수처럼 “정도가 중간”이라는 의미는 아닙니다. 조건 판단 규격

이 세 가지 요소가 모이면 “담당 부서를 선택하고”, “요구 사항 우선순위를 설정하고”, “환불 담당자에게 확인이 필요한지 확인한다”는 판단 기준을 하나의 문의에서 추출할 수 있습니다. 받은 값을 프로그램의 조건 분기나 정렬에 활용하기 용이한 것이 업무에 적용하는 데 중요한 포인트입니다. 각 질문은 동일한 자료로부터 별도로 평가되며, 어느 질문의 답변이 다른 질문을 읽고 판단하는 것은 아닙니다. “배송과 분류가 완료되면 배송 시스템을 조회하고, 그 결과를 보고 판단한다”면 조회 후에 다시 호출합니다. 여러 답변을 어떻게 조합하여 사용할지도 이용자 스스로 결정합니다.

## 2. 일반적인 LLM도 가능하다. 하지만 제프가 다른 점은

ChatGPT 등에서 사용되는 LLM(Large Language Model)은 문장 생성 등 다양한 작업을 수행하는 대규모 언어 모델입니다. 분류도 가능하며, 짧은 답변만 반환하도록 설정할 수도 있습니다. 더 나아가 OpenAI에는 출력 항목과 값의 범위를 지정하는 “Structured Outputs” 기능이 있습니다. “담당 부서”와 같이 미리 정해둔 후보만 선택하도록 형식 규칙을 지키게 하는 기능입니다. 따라서 “정해진 형식으로 답변할 수 있는 것”만으로는 Jev의 독창성을 설명할 수 없습니다. OpenAI의 공식 가이드 TypeSafe 설명에 따르면 Jev 역시 사전 학습한 언어 모델을 출발점으로 하고 있습니다. 차이점의 중심은 그 모델에게 무엇을 학습시키고, 어떤 방식으로 답변을 생성시키느냐에 있습니다. 학습 방법의 공식적인 설명은…

일반적인 LLM은 문장을 순차적으로 생성하는 대신 판단 결과를 병렬로 내놓습니다. 이러한 LLM은 문자열을 세세한 단위로 나누어 이전에 제시된 내용을 바탕으로 순차적으로 다음 내용을 생성합니다. 짧은 분류 결과를 반환하는 경우에도 문자열로 출력하는 점은 동일합니다. 반면, TypeSafe에 따르면 Jev는 자유로운 문자열 생성은 하지 않고 주어진 질문에 대한 판단과 확률을 병렬로 내놓는 설계입니다. 해당 회사는 이러한 출력을 얻는 방식을 “병렬 샘플러”라고 설명합니다.

> 
> 
> 1건의 문의 → 사안, 긴급성, 환불 희망 여부를 각각 평가하여 세 가지 결과를 종합적으로 받습니다.
> 

이는 입력과 출력의 개념도입니다. 여러 결과를 문장으로 순차적으로 생성하는 처리를 줄임으로써 효율성을 높이는 것이 목표입니다. 짧게 답변하는 LLM에게도 답변을 생성하는 방식 자체를 변화시킨다는 회사의 설명입니다. 다만, 이 설명만으로는 내부 전체 구조가 파악되는 것은 아닙니다. 또한, 여러 판단을 종합하는 설계상의 이점이 실제 업무에서 얼마나 빠른 속도 차이를 가져오는지 별도로 확인해야 합니다.

② 정답뿐만 아니라 확률 제시 방법도 학습하는 또 다른 방법은 엉뚱한 경우의 수를 다루는 것입니다. TypeSafe가 채택하는 것은 “RLCD(Reinforcement Learning for Calibrated Decisions)”라는 학습 방법입니다. 한국어로는 “교정된 판단을 위한 강화 학습”입니다. 판단의 답과 함께 그 확률이 실제 결과에 맞도록 학습하는 것을 중시하며, RLCD의 공식 설명은 예를 들어 “배송 문의일 확률이 80%”라고 예측한 사례를 많이 모아놓은 경우, 실제로는 약 80%가 배송 문의인 경우입니다. 이렇게 예측한 확률과 실제 비율이 일치하는 것을 “교정”이라고 합니다. Jev는 단순히 숫자를 출력하는 것뿐만 아니라, 그 숫자가 판단 재료로서 유용하도록 학습하는 설계입니다.

![画像](https://assets.st-note.com/img/1789717075-IKaRWsNCtH0eBpzLj1nGJV37.png)

신뢰도 0.9를 “이 답변이 90% 확률로 정확하다”고 해석하는 것은 허용되지 않습니다. 교정 역시 단일 항목의 정확성을 보장하는 것이 아닙니다. 따라서 자체 데이터에서 확률 및 신뢰도와 오분류 간의 관계를 조사하여 활용합니다. 신뢰도의 공식 설명

주목할 만한 점은 판단에 특화하면서도 용도를 바꿀 수 있는 점을 글을 분류하는 기계 학습은 이전부터 있었습니다. 예를 들어, 정답 레이블이 붙은 문서들을 사용하여 분류기를 학습하는 방법은 기존부터 사용되어 왔습니다. scikit-learn의 문서 분류 예제 Jev는 이용 기업마다 모델을 추가 학습시키는 형태가 아닌, 공통의 모델에 글과 질문, 기준을 전달하여 사용합니다. 분류 항목을 바꿀 때도 이용자가 질문이나 선택지를 바꿔서 시험해 볼 수 있습니다. 하지만 수정한다 해도 필요한 정밀도가 나오지 않을 수 있으며, 검증은 필수입니다. 업무에 적용하는 방식, 즉 분류 자체도, 질문을 글로 제공하는 방식도 처음이 아닙니다. 제가 주목한 점은 질문으로 용도를 바꿀 수 있는 유연성을 갖추면서, 출력과 학습을 판단에 좁히고, 소프트웨어의 부품으로 활용하려는 시도입니다.

TypeSafe는 비교 평가도 공개하지만, 해당 회사가 만든 업무 흐름과 LLM에 확률을 포함한 결과를 도출시키는 조건에서의 평가입니다. 본 기사에서는 일본어 문의에 대한 정확도와 속도를 실측하지 않았으며, “어떤 분류든 다른 AI보다 빠르고 정확하다”라고 단정하기는 어렵습니다. 비교 평가의 조건

## 그럼에도 불구하고, 이 전문성은 요금에 어떻게 반영될까요?

시스템 차이를 고려하여 비용을 검토합니다.

여기서는 채팅 서비스의 월간 이용 요금과 비교하는 것이 아니라, 프로그램에서 호출하는 API의 요금을 비교하는 것입니다. “토큰”은 AI가 문장을 처리할 때의 단위로, 입력은 읽어주는 양, 출력은 생성하는 양과 관련이 있습니다. 아래는 2026년 9월 18일에 확인한 공식 공개 요금입니다. 비교를 위해 후속 계산에 사용할 세 가지 항목으로 좁혔습니다. OpenAI는 표준 처리, 짧은 입력, 캐시 미사용의 요금으로, 배치 할인이나 지역별 추가 요금은 포함하지 않습니다.

![画像](https://assets.st-note.com/img/1789717113-Re8573PA6WQsMHiUIVCgdKSh.png)

TypeSafe의 요금, OpenAI의 요금

제브의 입력 단가는 테라의 약 48분의 1, 루나의 약 4.8분의 1입니다. 다만, 이는 입력 단가의 차이일 뿐이며, 동일한 품질로 대체될 수 있는 비율은 아닙니다.

요금 측면에서 큰 특징은 입력 단가 인하에 더하여 출력이 무료라는 점, 즉 입력 토큰에만 과금된다는 점입니다. 공식 자료에도 이 과금 방식이 명시되어 있습니다. 판단 결과나 선택지별 확률을 받는 경우 출력분에 대한 요금은 추가되지 않으며, 입력만 과금되는 방식과 출력이 과금되는 LLM과 비교하면 방대한 판단 처리를 수행하는 경우 비용적인 이점입니다. 여러 판단이나 확률을 추출하는 구성이라도 Jev 측의 API 비용은 입력량에 따라 추정됩니다. 하지만 질문이나 선택지를 늘리면 입력도 증가하고, 이후 단계에서 사용하는 LLM에는 별도로 요금이 부과됩니다. 출력 무료라는 장점을 처리 전체의 절약으로 어떻게 연결할지 살펴보겠습니다.

## 4월 10만 건의 분류 작업을 어떻게 분담할지 논의해야 합니다.

대량 처리 방식의 차이를 검토하기 위해 온라인 쇼핑몰 문의를 월 10만 건으로 분류한다고 가정합니다. 대상은 담당 부서 결정 단계만을 포함하며, 답변 작성 및 고객 응대 비용은 포함하지 않습니다.

계산상 각 호출의 입력을 질문 또는 지시를 포함하여 평균 1,000 토큰, LLM의 과금 대상 출력을 평균 100 토큰으로 가정합니다. 100 토큰은 분류에 필수적인 양이 아니며, 단가 계산을 위한 가상 수치입니다. 짧은 출력의 경우에도 추후 확인합니다. 또한, 추론에 사용되는 숨겨진 토큰도 출력 요금의 대상으로 고려하며, 실제 비교 시 화면에 보이는 답변의 길이뿐만 아니라 이용 기록상 과금 대상량을 확인합니다.

먼저 확인해야 할 것은 “얼마를 위임할 수 있는가”이다. Jev로 1차 판단을 실시하고, 판단이 어려운 경우에만 별도의 LLM으로 회수하는 구성을 고려한다. 다만, 실수가 발생하는 전에 어떤 케이스를 재검토에 회수해야 하는지 파악해야 한다. 예를 들어, 과거 문의에 담당자가 정답의 분류를 지정하고 Jev 결과와 비교한다. 신뢰도뿐만 아니라, 분류 대상별로 어떤 실수가 발생하는지 조사하여 “이 조건이라면 채택하고, 그 외에는 재검토”라는 기준으로 만든다. 그 기준을 다른 문의 그룹에서도 시험하여 필요한 품질을 충족하는지 확인한다.

그 결과, 80%의 판단을 채택하고 나머지 20%를 재확인에 활용할 수 있다고 가정해 보겠습니다. 이 80%는 공개 성능이나 실측값으로는 나타나지 않는 수치이며, “확률이 80%라면 80%를 자동화할 수 있다”는 의미이기도 합니다. 세 가지 방안을 동일한 가정 하에 제시합니다.

![画像](https://assets.st-note.com/img/1789717155-t1jOTL8mdZhSnl9Mru4EAiyx.png)

동등한 품질을 입증한 비교는 아니며, 재확인 또한 1,000 입력 단위 및 100 토큰 대상 출력과 동일하게, 상위 제시된 공식 단가를 기준으로 계산되었습니다.

Terra만으로는 입력이 200달러, 출력이 120달러입니다. Jev를 전단계로 두는 경우라면, Jev의 4.20달러와 Terra의 64달러를 합한 금액입니다. 이 조건에서는 Terra만 사용하는 경우에 비해 약 79% 감소합니다. 반면, Luna만으로 필요한 품질을 충족하는 경우에는 32달러로 충분하며 구성도 간단합니다. “Jev를 넣으면 가격이 저렴해진다”는 식으로 생각하기보다는, 필요한 품질을 충족하는 방식대로 비교하는 것이 중요합니다. 출력을 100토큰에서 20토큰으로 바꿀 경우, 순서대로 224달러, 49달러, 22.40달러가 됩니다. 분류처럼 짧은 출력이 필요한 작업에서는 LLM 측면도 저렴해지는 것을 알 수 있습니다. 실제로는 모델마다 입력의 셈법이나 재확인 시 추가 정보에 따라 달라지므로, 견적은 실제 사용량으로 다시 만들어야 합니다. 또한, 모든 항목을 결국 Terra로 넘기는 경우에는 Jev는 추가 비용이 됩니다. 후단 호출을 정말 줄일 수 있는지가 이 분할의 핵심이 됩니다.

## 제브와 여러 LLM을 결합했을 때, 무엇이 열릴지

지금까지의 계산 결과, Jev와 하나의 LLM을 결합했습니다. 더 고려해볼 부분은 Jev의 판단을 바탕으로 업무에 적합한 LLM이나 처리에 연결하는 구성입니다. 앞선 문의의 경우, 다음과 같은 흐름이 가능할 것입니다.

- 제보 내용을 제프에게 전달한다.
- 제프가 용건과 긴급성을 판단한다.
- 프로그램이 판정 결과를 내규와 비교한다.
- 요건에 부합하는 LLM을 기존 시스템 및 담당자에게 배분한다.

예를 들어, 배송 상황 조회로도 해결 가능한 경우, 기존 시스템에서 정보를 가져와 표준 텍스트로 안내할 수 있습니다. 짧은 안내문 작성은 그 업무에서 필요한 품질을 충족하는 저렴한 LLM에 맡기고, 복잡한 검토나 여러 규약 및 경위를 비교할 경우에는 해당 검토에 적합한 LLM을 활용합니다. 예외적인 환불이나 내용 파악이 어려운 불만 사항은 담당자에게 전달하는 방식으로 구성하며, Jev는 “어떤 일을 누구에게 전달할지” 결정하는 데 필요한 판단 자료를 제공합니다. 조합할 LLM은 한 종류로 고정할 필요 없이, 문장 작성, 각 단계별 품질, 속도, 가격을 비교하여 적합한 모델을 선택할 수 있는 구성 예시입니다. 본 기사에서 제시하는 구성이며, 특정 조합의 효과를 실측한 결과는 아닙니다.

문맥 분류는 Jev, 정보 조회 및 계산은 프로그램, 문장 작성 및 복잡한 검토는 LLM, 중요한 최종 판단은 사람이다. 주변 프로그램은 판정 결과를 받아 각 처리의 실행 조건을 관리한다. 공식 설계 가이드라인에서 추구하는 것은 불필요한 LLM 호출을 줄이고, 필요한 상황에 처리 능력을 집중하며, 후속 단계로 전달되는 정보를 제한하는 것이다. 예를 들어 Jev에 의한 사전 평가로 참조 자료를 좁힐 수 있다면, 답변을 만드는 LLM의 입력을 줄일 수 있을 것이다.

이러한 분담이 성사된다면 API 비용뿐만 아니라 처리 시간이나 사람이 확인하는 양의 개선에도 도움이 될 수 있습니다. 저는 Jev에 큰 가능성을 느끼는 것은 이 조합의 다양성입니다. 다음 리뷰 분석이나 내부 검색에도 같은 생각을 넓혀갈 수 있습니다.

## 질문 외에는 어떤 경우에 사용할 수 있는지

다음은 공식 자료를 바탕으로 한 활용 이미지에 기반한 것으로, 효과를 실증한 도입 사례가 아닙니다.

리뷰 및 설문조사: 만족과 불만을 분리하여 수집

> 
> 
> 상품 자체에는 만족하고 있습니다. 다만, 초기 설정 방법이 잘 이해되지 않아 사용을 시작하는 데 어려움을 겪었습니다.
> 

이를 “좋은 리뷰-나쁜 리뷰”의 하나로 뭉개면 중요한 정보가 누락될 수 있습니다. 이용자가 “상품에 대한 만족도”, “설정의 어려움” 등의 항목을 마련하여 별도로 평가하고 집계하는 방식입니다. 그 위에 관심을 끄는 주제의 답변을 발췌하여 보고서를 작성할 때 LLM을 활용하는 방식을 고려해볼 수 있습니다. 미리 정해진 주제로 자유記述를 분류하는 것은 공식적으로 언급된 용도입니다. 용도 목록은 다음과 같습니다. 단, 준비한 항목만으로는 새로운 불만을 제대로 포착할 수 없으며, “기타” 또는 판단이 엇갈린 답변을 사람이 읽고 분류 항목을 재검토하는 운영도 필요합니다.

사내 검색: 답변을 작성하기 전에 읽을 자료를 좁히기 위해 사내 매뉴얼을 검색하면 유사한 자료가 여러 건이 쏟아져 나온다. 그 중에서도 질문과 관련된 자료를 우선순위로 하는 방식도 있다. 흐름은 일반 검색으로 후보를 모으는 것 → Jev에서 관련성을 평가하여 재정렬하는 것 → 선택한 자료를 LLM에 전달하여 답변을 작성하는 것이다. Jev가 담당하는 부분은 중간 단계의 평가이다. 자료 재정렬 구현 예시로 LLM에 전달되는 자료를 줄일 수 있지만, 중요한 자료를 놓치면 답변의 질이 하락한다. 비용과 함께 필요한 정보가 남아있는지 확인해야 한다.

## 숫자로 답하는 것만이 정답이라는 오류를 반복하고 있습니다.

지정된 선택지만을 고르는 것과 실제로는 청구 담당 업무인데 배송을 선택할 수 있는 것은 별개의 문제입니다. 마크 시트의 항목을 지키는 것과 올바른 항목을 선택하는 것은 서로 다른 문제입니다.

일본어 사용도, 직접 확인해 보려는 부분입니다. 공식 자료에서는 영어로 가장 훈련 언어가 주어지고, 현재 상황에서는 영어로 가장 높은 정확도를 얻을 수 있다고 보고됩니다. 입력은 텍스트만 가능하며, 이미지, 음성, 영상은 그대로 처리할 수 없습니다. 언어와 입력의 대응 정확한 계산, 날짜 비교, 불필요한 정보가 많은 긴 문장, 판단을 유도하는 입력 등에 취약점을 드러내고 있습니다. 계산이나 날짜 비교는 프로그램에 맡기고, Jev에는 판단에 필요한 자료를 좁혀서 전달하는 등의 설계가 필요합니다. Jev 1.13의 알려진 약점

비용 평가는 API 요금 외에도 구현 및 유지보수, 인적 검토, 오분류 수정 비용 등을 포함합니다. 소규모 처리는 API 요금 절약보다 시스템 구축 및 유지에 드는 노력이 더 클 수 있습니다. LLM 측의 캐시나 배치 할인 등을 포함하여 종합적으로 검토해야 합니다. OpenAI의 요금 설정도 고려해야 합니다.

## 요약 | Jev와 LLM의 조합에 큰 가능성을 느껴집니다.

Jev의 판단 기능과 다양한 LLM의 능력을 결합하여 업무 전반의 진행 방식을 개선할 수 있다는 점이었습니다.

선택·점수·노울을 통해 작은 판단을 추출하고, 문장 작성이나 복잡한 검토는 적합한 LLM에 넘겨준다. 계산이나 정보 조회는 프로그램이 담당하고, 중요한 확인은 사람이 수행한다. Jev는 이러한 역할 분담 안에서 사용되는 부품으로 捉えると, 활용의 폭이 보이고 있다.

분류 및 구조화 출력이 기존부터 가능했습니다. 그 위에 Jev는 판단과 확률에 초점을 맞춘 학습, 독립적인 판단의 병렬 출력, 낮은 입력 단가와 출력 무료라는 특징을 갖습니다. 이러한 특징을 활용하여 후속 LLM의 호출 횟수나 입력량을 줄일 수 있다면, 필요한 품질을 유지하면서 효율 증진과 비용 절감을 동시에 달성할 수 있을 것입니다.

처음 한 발걸음은 Jev를 사용하여 과거 문의사항에 분류 후보를 지정하고, 사람의 분류와 비교하는 것부터 시작하는 것이 좋을 것 같습니다. 어디에서 오류가 발생하는지, 어떤 결과가 채택 가능할지 파악한 후에 실제 분류로 연결하는 것이죠. 문의사항 분류, 리뷰 집계, 사내 검색 등의 작업 이후에도 판단과 문장 생성 과정을 분리하여 생각할 수 있는 업무는 충분히 있을 것으로 보입니다. 모델이나 과정을 조합하여 변화를 주면 시도 가능한 활용 방법은 훨씬 더 넓어질 것입니다.

이 일에 Jev와 LLM을 어떻게 조합하여 더 잘, 더 빠르게, 적은 비용으로 진행할 수 있을까. Jev의 등장은 그 설계를 생각하는 계기가 되었고, 저는 그 안에 큰 가능성을 느껴요.

![画像](https://assets.st-note.com/img/1789717206-hHScipEgKjkstYmXr4fBGqed.jpg?width=1200)

![画像](https://assets.st-note.com/img/1789717206-GcdF8lZaYIK0mkzwWv6byhQ2.png?width=1200)

## **65:**

“얘야, 그 ‘별의 전조’라는 책 정말 감동적이지 않아? 내가 어렸을 때 이 책을 읽고 어른이 되는 것에 대한 불안감을 조금 줄일 수 있었어. 물론 어른이 되는 건 멋진 일이지만, 어린 시절의 순수한 마음을 잊지 말라는 것을 알려줬지. 게다가 이 책은 인생의 교훈이 많이 담겨 있다고 생각해. 예를 들어, 소중한 것은 눈에 보이지 않는 것, 사람의 마음을 알아보는 것, 그리고 자신의 시간과 마주하는 것. 이러한 것들은 어른이 되어서야 깨닫는 경우가 많지. 그래서 이 책은 나에게 특별한 존재야.”

**66:**

“그러고 보면, 지난번에 친구가 ‘별의 전조’를 읽고 엄청 감동했었다고 하더구나. 친구는 이 책을 읽고 자신의 인생에 대해 깊이 생각하게 되었다는 거야. 나도 이 책을 읽고 내 생각이나 가치관을 조금 바꾸게 된 것 같아. 이 책은 정말 훌륭한 작품이야. 특히 이 책에 나오는 ‘장미’는 아름다움과 사랑, 그리고 책임이라는 것을 상징하는 것 같아. ‘장미’처럼 누군가를 소중히 여기고, 누군가에게는 소중한 존재가 되는 것은 인생의 기쁨 중 하나라고 생각해. 이 책은 앞으로도 오랫동안 내 마음속에 남아있을 거야.”

TypeSafe AI「시스템 원 모델 및 Jev 소개 (2026년 9월 15일)」(TypeSafe AI)https://typesafe.ai/blog/introducing-system-one-models-and-jev

TypeSafe AI「팀」(TypeSafe AI)https://typesafe.ai/team

TypeSafe AI「모델」(TypeSafe AI)https://docs.typesafe.ai/models

TypeSafe AI「선택」(TypeSafe AI)https://docs.typesafe.ai/primitives/choice

TypeSafe AI「시스템 원을 구축하는 방법」(TypeSafe AI)https://docs.typesafe.ai/concepts/how-to-build-with-system-one

TypeSafe AI「Primitives (질문)」(TypeSafe AI)https://docs.typesafe.ai/primitives

TypeSafe AI「점수」(TypeSafe AI)https://docs.typesafe.ai/primitives/score

TypeSafe AI「Noul」(TypeSafe AI)https://docs.typesafe.ai/primitives

OpenAI「구조화된 모델 출력」(OpenAI 개발자)https://developers.openai.com/api/docs/guides/structured-outputs

TypeSafe AI「AI 개론」(TypeSafe AI)https://docs.typesafe.ai/introduction/machine-learning-primer

TypeSafe AI「신뢰도」(TypeSafe AI)https://docs.typesafe.ai/confidence

scikit-learn「희소 특징을 사용한 텍스트 문서 분류」(scikit-learn)https://scikit-learn.org/stable/auto_examples/text/plot_document_classification_20newsgroups.html

OpenAI「가격 정책」(OpenAI 개발자)https://developers.openai.com/api/docs/pricing

OpenAI「추론 모델」(OpenAI 개발자)https://developers.openai.com/api/docs/guides/reasoning

TypeSafe AI「사용 사례」(TypeSafe AI)https://docs.typesafe.ai/concepts/use-case-map

TypeSafe AI「재순위 지정」(TypeSafe AI)https://docs.typesafe.ai/cookbooks/rerank_typesafe

TypeSafe AI「Jev 1.13 불규칙성」(TypeSafe AI)https://docs.typesafe.ai/model-jaggedness/jev-1.13

**출처:** [note 원문](https://note.com/yasuhitoo/n/n4ded5315dc86)

*번역: Gemma 3(.44) 초벌 + 교정 50청크*

[원문 보기](https://note.com/yasuhitoo/n/n4ded5315dc86) | 출처: note.com