For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/ko/articles/typesafe-jev-vs-openai-decisions-api-fast-7c48d620.md.
한 신생 AI 기업이 에세이, 코드를 작성하거나 친근한 채팅 답변을 생성하려 하지 않는 모델을 출시한 지 불과 몇 주 만에 **8억 7,000만 달러**를 조달했습니다.
한 신생 AI 기업이 에세이, 코드를 작성하거나 친근한 채팅 답변을 생성하려 하지 않는 모델을 출시한 지 불과 몇 주 만에 8억 7,000만 달러를 조달했습니다.
이 회사는 TypeSafe AI입니다.
이 회사의 모델 이름은 Jev입니다.
TypeSafe는 2026년 10월 9일 시리즈 A 투자 유치를 발표했으며, 기업 가치는 75억 달러로 평가되었습니다. Andreessen Horowitz가 이번 라운드를 주도했고 Sequoia Capital, 기존 투자자인 DCVC 및 기타 투자자들이 참여했습니다.
회사의 창업팀도 주목을 받았습니다.
TypeSafe는 Erik Gafni, Sasha Sheng, Diogo Almeida가 공동 설립했습니다. Almeida는 이전에 OpenAI에서 근무했으며 ChatGPT 시대의 명령 수행 시스템으로 이어진 연구 개발에 참여했습니다. Sheng은 이전에 Meta/FAIR에서 근무했고, Gafni는 엔지니어링 및 스타트업 분야의 경력을 보유하고 있습니다.
Jev는 9월 15일 공개 출시되었습니다.
불과 2주 후 OpenAI는 긴 생성 텍스트 대신 확률, 선택지, 점수를 반환하는 고속 API라는 매우 유사한 제품 방향의 제한적 프리뷰를 발표했습니다. OpenAI는 이 제품인 Decisions API를 10월 6일 퍼블릭 베타로 전환했습니다.
이후 OpenAI API 제품 책임자인 Nikunj Handa는 Jev가 이 제품 범주에 영감을 주었다고 공개적으로 밝혔습니다.
이 때문에 Jev는 두 가지 측면에서 흥미롭습니다.
첫째, 소프트웨어 내부에서 AI를 사용하는 다른 방식을 제안합니다.
둘째, 프론티어 AI 연구소가 이 분야에 이례적으로 빠르게 대응하도록 만들었습니다.
Jev는 사용자가 대화하는 AI가 되려 하지 않습니다.
사용자가 결과를 직접 보지 않더라도 소프트웨어가 수천 번 또는 수백만 번 호출할 수 있는 AI가 되려 합니다.
이메일 받은 편지함을 열면 수백 가지의 작은 판단이 기다리고 있습니다.
이 메시지는 중요한가?
곧 만료되는 청구서가 포함되어 있는가?
긴급한 답장이 필요한가?
회의 시간이 변경되었는가?
보관하거나, 에스컬레이션하거나, 무시해야 하는가?
일반적인 목적의 언어 모델은 이미 이러한 질문에 답할 수 있습니다.
문제는 기존 LLM이 대체로 언어를 생성하도록 설계되었다는 점입니다.
이메일 하나만 처리한다면 이러한 오버헤드는 중요하지 않을 수 있습니다.
하지만 규모가 커지면 달라집니다.
애플리케이션이 하루에 수천 번 또는 수백만 번 같은 유형의 의사결정을 수행한다면 지연 시간과 비용의 작은 차이도 큰 운영 비용으로 이어집니다.
Jev는 이러한 반복적인 판단을 위해 특별히 설계되었습니다.
TypeSafe는 Jev를 System One Model이라고 설명합니다.
이는 Daniel Kahneman이 대중화한 빠르고 직관적인 ‘System 1’ 사고방식을 가리킵니다.
애플리케이션은 Jev에 문단을 생성하라고 요청하는 대신 일부 상태 정보와 미리 정의된 질문 집합을 전달합니다.
Jev는 다음과 같은 타입이 지정된 값을 반환합니다.
애플리케이션은 결과를 바로 사용할 수 있습니다.
단순화한 흐름은 다음과 같습니다.
수신 이메일
↓
Jev가 여러 질문을 평가
↓
urgent_reply = 0.91
billing_related = 0.74
meeting_change = 0.03
↓
애플리케이션이 자체 규칙을 적용
↓
알림 / 보관 / 라우팅 / 검토
중요한 차이는 인터페이스에 있습니다.
일반적인 언어 모델을 사용할 때 개발자는 JSON이나 다른 구조화된 형식으로 답변하라고 요청한 다음 생성된 응답을 검증하는 경우가 많습니다.
Jev에서는 타입이 지정된 의사결정 출력 자체가 핵심 제품 설계입니다.
TypeSafe의 API는 하나의 systemone 엔드포인트를 제공하며, 개발자는 동일한 공유 상태에 대해 여러 질문을 제출할 수 있습니다.
TypeSafe는 병렬 의사결정을 강조합니다.
애플리케이션이 동일한 입력을 여러 독립적인 기준으로 평가하려는 경우, 각 기준을 별도의 대화 단계로 나누는 대신 질문을 함께 보낼 수 있습니다.
이는 다음과 같은 질문에 답해야 하는 소프트웨어에 유용합니다.
이후 애플리케이션은 일반 코드로 이러한 출력들을 조합합니다.
이 점 때문에 Jev는 챗봇보다는 지능형 조건문에 가깝게 느껴집니다.
TypeSafe는 현재 Jev의 가격을 다음과 같이 제시합니다.
| 사용량 | Jev 가격 |
|---|---|
| 입력 | 100만 토큰당 0.042달러 |
| 출력 | 무료 |
TypeSafe는 Jev가 긴 텍스트 시퀀스를 자기회귀 방식으로 생성하지 않기 때문에 출력 비용을 측정하는 것이 지나치게 저렴하다고 설명합니다.
이 가격이 중요한 이유는 Jev가 매우 빈번하게 발생할 수 있는 의사결정을 목표로 하기 때문입니다.
사용자 행동마다 한 번씩 호출하기에는 너무 비싼 의사결정도 비용이 10분의 1 수준으로 낮아지면 실용적인 자동화 대상이 될 수 있습니다.
이로 인해 배포에 관한 질문도 달라집니다.
기존에는 다음과 같이 물었다면:
이 작업은 AI 모델을 호출할 만큼 중요한가?
이제 소프트웨어 팀은 다음과 같이 질문할 수 있습니다.
이 작은 단계도 AI가 평가하지 않을 이유가 있는가?
이것이 이 제품의 경제적 논리입니다.
눈에 띄는 토큰 가격은 실제 운영 비용의 일부에 불과합니다.
팀은 여전히 다음 항목을 측정해야 합니다.
저렴한 의사결정이라도 오류가 지나치게 많으면 여전히 비용이 커질 수 있습니다.
이 점은 이후에 소개할 Jev의 독립 평가에서 중요하게 다뤄집니다.
Vercel은 출시 직후 거의 즉시 Jev를 AI Gateway에 추가했습니다.
첫날 반응은 이례적으로 강력했습니다.
Vercel에 따르면 Jev는 출시 후 24시간 이내에 **유료 AI Gateway 팀의 약 13%**가 사용했습니다.
이는 플랫폼에서 이전에 출시된 어떤 모델의 첫날 도달률보다도 두 배 이상 높은 수치였습니다.
Vercel은 이후 Jev를 AI Gateway 역사상 가장 빠르게 도입된 모델이라고 평가했습니다.
첫날의 급증만으로 장기적인 유지율을 입증할 수는 없습니다.
그러나 개발자들이 좁은 의사결정 모델이 유용할 수 있는 작업 범주를 즉시 인식했다는 점은 보여줍니다.
Vercel은 다음과 같은 사례를 제시합니다.
이는 화려한 작업이 아닙니다.
하지만 실제 운영 소프트웨어가 지속적으로 수행하는 바로 그런 작업입니다.
Jev의 아이디어는 어느 날 갑자기 등장한 것이 아닙니다.
Diogo Almeida는 OpenAI에서 근무할 당시 다음과 같은 기본적인 질문에 점점 더 관심을 갖게 되었다고 말했습니다.
AI가 경제를 변화시킨다면 앞으로 대부분의 모델 호출을 수행하는 주체는 누구일까?
사람이 직접 채팅 창을 여는 것일까?
아니면 소프트웨어가 백그라운드에서 자동으로 지능을 호출하는 것일까?
그의 답은 후자였습니다.
이는 AI 인터페이스가 무엇을 최적화해야 하는지를 바꿉니다.
사람을 대상으로 하는 모델은 자연스러운 대화, 유연한 문장, 설명, 창의성의 혜택을 받습니다.
소프트웨어를 대상으로 하는 모델은 다음 요소의 혜택을 받습니다.
Almeida는 Jev가 대화 능력은 인상적이지만 신뢰할 수 있는 소프트웨어 기본 요소로 사용하기는 어려운 모델과, 그 반대의 간극에 대한 대응이라고 설명해 왔습니다.
TypeSafe는 공개 출시 전에 약 2년 동안 이 시스템을 개발했다고 밝혔습니다.
Jev의 출시는 OpenAI 내부에서도 주목받았습니다.
OpenAI DevDay 전후에 녹화된 Latent Space 인터뷰에서 API 제품 책임자 Nikunj Handa는 Decisions API 추진에 Jev가 직접적인 영감을 주었다고 밝혔습니다.
그는 사용자와 내부 팀이 훨씬 빠른 분류 시스템을 요청하고 있었다고 설명했습니다.
또한 몇 주 전까지만 해도 이 프로젝트가 로드맵에 포함되어 있지 않았다고 확인했습니다.
OpenAI는 첫 버전을 위해 완전히 새로운 기반 모델을 학습하지 않았습니다.
대신 GPT-6 Luna를 사용하고 그 위에 전용 의사결정 인터페이스와 추론 경로를 구축했습니다.
이제 다음 경로를 통해 퍼블릭 베타로 사용할 수 있습니다.
POST /v1/decisions
Decisions API는 공유 증거와 하나 이상의 질문을 입력으로 받고 타입이 지정된 답변을 반환합니다.
OpenAI는 현재 세 가지 질문 유형을 지원합니다.
| 질문 유형 | 결과 |
|---|---|
predicate | 조건이 참일 확률 |
choice | 확률 및 신뢰도와 함께 선택된 하나의 옵션 |
score | 순서가 있는 수준에 따른 점수 |
이는 Jev가 목표로 하는 사용 사례와 상당 부분 겹칩니다.
현재 공개된 제품에서 가장 큰 아키텍처 차이는 바로 이 부분입니다.
TypeSafe는 Jev가 특화된 모델 아키텍처와 **보정된 의사결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions, RLCD)**이라고 부르는 학습 방식을 사용한다고 설명합니다.
반면 OpenAI의 첫 Decisions API 버전은 기존 GPT-6 Luna 가중치를 사용하고, 그 위에 전용 의사결정 서비스 인터페이스를 구축했습니다.
개념적으로는 다음과 같습니다.
TypeSafe:
특화된 의사결정 모델
→ 타입이 지정된 확률 출력
OpenAI:
GPT-6 Luna
→ 특화된 Decisions API 경로
→ 타입이 지정된 확률 출력
따라서 두 제품은 개발자에게 비슷하게 보일 수 있지만 내부적인 접근 방식은 다릅니다.
실용적인 차이 중 하나는 입력 모달리티입니다.
현재 OpenAI Decisions API는 텍스트, 이미지 또는 두 가지 모두를 입력으로 받을 수 있습니다.
TypeSafe의 공개 Jev 출시는 텍스트 및 상태 입력에 초점을 맞췄습니다.
OpenAI 문서에는 제품 사진을 검사하고 균열, 찢어짐, 찌그러짐과 같은 눈에 보이는 손상이 있는지 추정하는 예제가 포함되어 있습니다.
전자상거래 애플리케이션은 이 방식을 사용해 검토가 필요한 이미지를 자동으로 라우팅할 수 있습니다.
예를 들면 다음과 같습니다.
제품 사진
→ Decisions API가 눈에 보이는 손상 확인
→ 확률 = 높음
→ 수동 검사로 라우팅
이는 의사결정 API가 사용자에게 직접 답변을 생성하지 않고도 일반적인 소프트웨어 안에 들어갈 수 있는 이유를 잘 보여줍니다.
사용자는 어떤 모델이 사진을 평가했는지 전혀 알지 못할 수 있습니다.
사용자가 경험하는 것은 결과로 나타난 워크플로뿐입니다.
현재 공개된 가격은 명확합니다.
| 제품 | 입력 가격 | 출력 가격 |
|---|---|---|
| TypeSafe Jev | 100만 토큰당 0.042달러 | 무료 |
| GPT-6 Luna 기반 OpenAI Decisions API | 100만 토큰당 0.10달러 | 무료 |
기본 입력 토큰 가격만 보면 Jev가 더 저렴합니다.
OpenAI의 Decisions 문서에 따르면 이 API는 Responses API보다 약 10배 빠르게 타입이 지정된 답변을 반환합니다.
이 10배라는 주장은 OpenAI 자체의 Responses API 경로와 비교한 것입니다.
Jev보다 10배 빠르다는 직접적인 헤드투헤드 속도 우위를 공개적으로 주장한 것은 아닙니다.
이 구분은 중요합니다.
마찬가지로 TypeSafe는 자체 워크플로 평가에서 훨씬 큰 속도 및 비용 개선 배수를 공개하고 있지만, 이러한 테스트가 자체 방법론에 따른 것이며 실제 환경의 개선 폭 중 높은 범위에 해당할 수 있음을 명시적으로 인정합니다.
실제 제품을 선택할 때는 팀이 자체 워크로드를 벤치마크해야 합니다.
아이디어를 한 문장으로 입력하면 We0 AI가 쇼케이스 사이트, 페이지, CMS를 생성하고 출시 후 고객과 트래픽 확보를 돕습니다.
무료 등록을 위한 하나의 완전한 프로젝트 생성
하나의 완전한 생성 흐름을 시도하고 첫 번째 프로젝트 초안을 빠르게 보는 데 가장 적합합니다.
이 제품 이야기에서 이례적인 점은 OpenAI가 영감을 준 대상을 매우 직접적으로 인정했다는 것입니다.
Latent Space 인터뷰에서 Handa는 Jev가 이 범주에 영감을 주었고, OpenAI의 사용자와 내부 팀이 유사한 고속 분류 기능을 빠르게 요청하기 시작했다고 말했습니다.
그는 소규모 내부 그룹이 신속하게 프로토타입을 구축한 뒤 지연 시간을 최적화했다고 설명했습니다.
그렇다고 Jev와 Decisions API가 동일하다는 의미는 아닙니다.
다만 TypeSafe가 실제 제품 공백을 발견했다는 점은 보여줍니다.
경쟁의 기준은 다음 질문에서:
누가 가장 뛰어난 범용 모델을 보유하고 있는가?
다음 질문으로 이동했습니다.
소프트웨어 내부에서 반복되는 특정 의사결정에
가장 저렴하고 빠른 모델 기본 요소는 무엇인가?
이는 전통적인 챗봇 벤치마킹과는 다른 시장입니다.
Jev의 낮은 가격은 출시 직후 유용한 독립적 검토를 받았습니다.
9월 29일 본 대학교와 Lamarr Institute의 연구원들은 Jev 1.13.0을 평가한 프리프린트를 제출했습니다.
이 연구는 다음을 다뤘습니다.
Jev API의 총 비용은 10달러 미만이었습니다.
이는 눈에 띄는 수치입니다.
그러나 이 논문에서 더 중요한 부분은 신뢰성에 관한 내용입니다.
연구진은 Jev의 선택 확률이 선택적 예측에 유용할 수 있다는 사실을 발견했습니다.
쉽게 말하면 다음과 같습니다.
시스템이 가장 확신하는 사례에만 답변하면 정확도가 높아질 수 있습니다.
신뢰도가 낮은 사례까지 더 많이 수용하면 정확도가 떨어집니다.
이것이 자동화에서 확률이 유용한 이유입니다.
운영 워크플로는 신뢰도 수준에 따라 서로 다른 동작을 정의할 수 있습니다.
예를 들면 다음과 같습니다.
신뢰도 >= 0.95
→ 자동화
0.70 <= 신뢰도 < 0.95
→ 2차 검증 요청
신뢰도 < 0.70
→ 사람 검토
정확한 임계값은 직관이 아니라 평가 데이터에서 도출해야 합니다.
이 연구는 이진 의사결정에서 중요한 주의점을 발견했습니다.
Jev의 확률은 사례의 순위를 잘 정할 수 있었지만 고정된 0.5 임계값 주변에서는 제대로 보정되지 않을 수 있었습니다.
이는 다음 규칙이 모든 작업에 자동으로 최적이라는 뜻이 아닙니다.
확률 >= 0.5이면:
실행
한 UNFAIR-ToS 평가에서 연구진은 학습 데이터에 맞춰 임계값을 조정했을 때 마이크로 F1이 0.50에서 0.75로 향상되었다고 보고했습니다.
일반적인 교훈은 간단합니다.
확률은 유용하지만, 애플리케이션은 여전히 어느 정도의 확률부터 행동할 만큼 높은 것으로 간주할지 결정해야 합니다.
이는 Jev에만 해당하는 내용이 아닙니다.
확률적 분류기를 책임 있게 배포하기 위한 기본적인 요구사항입니다.
이메일 사례로 돌아가 보겠습니다.
모델이 홍보 이메일 하나를 중요한 메일로 잘못 표시했다고 가정해 보겠습니다.
비용은 약간의 불편함에 그칩니다.
반대로 하루가 끝나기 전에 답장해야 하는 이메일을 놓쳤다면 어떨까요?
비용은 훨씬 클 수 있습니다.
따라서 올바른 임계값은 오탐과 미탐 사이의 비대칭성에 따라 달라집니다.
실제 시스템은 의사결정마다 서로 다른 규칙을 사용할 수 있습니다.
| 의사결정 | 더 안전한 기본값 |
|---|---|
| 홍보 이메일 탐지 | 적극적으로 자동화 |
| 청구 기한 탐지 | 알림에는 더 낮은 임계값 사용 |
| 법률·컴플라이언스 분류 | 불확실성 에스컬레이션 |
| 고위험 계정 작업 | 사람의 확인 요구 |
| 가치가 낮은 콘텐츠 태깅 | 대부분 자동화 |
강력한 의사결정 모델이 제품 정책을 없애주는 것은 아닙니다.
대신 제품 정책을 소프트웨어로 표현하기 쉽게 만들어 줍니다.
TypeSafe는 Jev의 출력이 타입 안전하다는 점을 강조합니다.
이는 실제 엔지니어링 특성입니다.
개발자가 허용된 출력 집합을 정의하면 모델은 해당 스키마 밖의 임의 문자열을 만들어낼 필요가 없습니다.
그러나 정확성에는 서로 다른 두 가지 종류가 있습니다.
출력이 허용된 타입과 일치한다.
선택된 답변이 실제로 옳다.
의사결정 모델은 후자보다 전자를 훨씬 강하게 보장할 수 있습니다.
독립 벤치마크는 이 차이를 분명하게 보여줍니다. Jev의 응답은 타입이 지정된 값으로 완벽하게 유효하더라도 여전히 잘못된 답을 선택할 수 있습니다.
따라서 운영 환경에서 가장 안전한 해석은 다음과 같습니다.
Jev는 서식 및 파싱 오류의 큰 범주를 제거하지만 모델 오류까지 제거하지는 않습니다.
원문은 모든 판단을 Jev에 맡겨서는 안 된다는 점을 올바르게 강조합니다.
TypeSafe의 자체 자료도 특화된 System One 모델이 범용 언어 모델보다 역할이 좁다는 점을 인정합니다.
다음과 같이 역할을 나누는 것이 유용합니다.
예시:
예시:
예시:
예시:
저렴한 모델이 사람이 계속 정리해야 하는 의사결정을 만들어 새로운 비용을 발생시켜서는 안 됩니다.
Jev라는 이름은 경제학자 William Stanley Jevons를 가리킵니다.
Jevons는 오늘날 제본스의 역설이라고 불리는 개념과 관련이 있습니다.
단순화하면 다음과 같습니다.
자원이 더 효율적으로 변함
→ 사용당 비용이 하락함
→ 수요가 증가함
→ 전체 자원 소비량이 늘어날 수 있음
TypeSafe는 이 논리를 기계 지능에 적용합니다.
모든 AI 호출이 훨씬 저렴해지면 소프트웨어는 동일한 워크로드에 더 적은 비용만 지출하는 데 그치지 않을 수 있습니다.
개발자는 이전에는 비용 때문에 정당화하기 어려웠던 완전히 새로운 워크로드를 만들 수 있습니다.
이는 다음과 같은 사례에서 이미 확인할 수 있습니다.
그 결과 의사결정당 비용은 낮아지지만 전체 의사결정 수는 훨씬 늘어날 수 있습니다.
이것이 Jev에 담긴 제본스의 역설에 대한 베팅입니다.
이러한 흐름에서 가장 중요한 부분은 사용자에게 보이지 않을 수 있습니다.
오늘날 사람들은 AI와 명시적으로 상호작용하는 경우가 많습니다.
챗봇 열기
→ 맥락 붙여넣기
→ 프롬프트 작성
→ 답변 읽기
→ 결과를 다른 도구에 다시 복사
머신 네이티브 의사결정 모델은 다음과 같은 패턴을 제안합니다.
사용자가 일반 소프트웨어를 사용
→ AI가 백그라운드에서 작은 의사결정을 평가
→ 소프트웨어가 자동으로 라우팅, 점수화, 확인 또는 필터링
→ 사람은 중요한 사례만 확인
받은 편지함은 긴급한 메일만 보여줄 수 있습니다.
글쓰기 도구는 검토가 필요한 문장만 표시할 수 있습니다.
에이전트는 다음에 사용할 도구를 자동으로 선택할 수 있습니다.
고객지원 시스템은 담당자가 보기 전에 티켓을 라우팅할 수 있습니다.
마켓플레이스는 가입 직후 후보자의 순위를 정할 수 있습니다.
이 시점에서 사용자는 기반 시스템이 Jev를 사용했는지, GPT-6 Luna를 사용했는지, 아니면 다른 의사결정 모델을 사용했는지 신경 쓰지 않을 수 있습니다.
사용자가 중요하게 여기는 것은 소프트웨어가 더 빠르게 느껴지고 수동 작업이 줄어드는지 여부입니다.
이러한 관점에서 보면 TypeSafe의 투자 유치는 더 잘 이해할 수 있습니다.
이 회사는 사람들이 또 하나의 챗봇 탭을 원한다고 베팅하는 것이 아닙니다.
소프트웨어 자체가 막대한 수의 모델 호출을 수행할 것이라고 베팅하고 있습니다.
TypeSafe는 Fortune 500 기업의 3분의 1이 이미 Jev를 사용하고 있다고 밝혔지만, 이는 회사가 보고한 도입 수치이며 해당 고객 전부의 이름을 공개적으로 밝힌 것은 아닙니다.
8억 7,000만 달러의 시리즈 A 투자는 TypeSafe가 이러한 전략을 확장할 수 있는 상당한 자본을 제공합니다.
투자 발표에 따르면 회사는 다음을 구축할 계획입니다.
OpenAI의 신속한 Decisions API 대응은 대형 연구소들도 같은 기회를 보고 있음을 시사합니다.
다음 경쟁의 핵심 질문은 단순히 어느 제품이 더 저렴한지가 아닙니다.
개발자가 소프트웨어가 자동으로 행동하도록 맡길 만큼 신뢰할 수 있는 의사결정을 어느 제품이 만들어내는지가 핵심입니다.
Jev는 TypeSafe AI의 첫 번째 ‘System One Model’로, 자유로운 텍스트 생성보다 빠르고 기계가 읽을 수 있는 의사결정을 위해 설계되었습니다. 공유 상태와 타입이 지정된 질문을 입력으로 받고, 소프트웨어가 직접 사용할 수 있는 선택지, 점수 또는 확률을 반환합니다.
TypeSafe는 현재 Jev의 가격을 입력 토큰 100만 개당 0.042달러로 제시하며 출력은 무료입니다. 실제 애플리케이션 비용은 요청량, 입력 크기, 재시도, 평가 오버헤드, 더 큰 모델이나 사람에게 에스컬레이션되는 사례 수에 따라 달라집니다.
TypeSafe는 Jev를 텍스트 생성을 위한 전통적인 대규모 언어 모델이라기보다 트랜스포머 기반 System One 모델로 설명합니다. Jev의 핵심적인 제품 동작은 임의의 문장을 생성하지 않고 타입이 지정된 확률적 의사결정을 반환한다는 점입니다.
그렇습니다. 타입 안전 출력은 일부 서식 및 스키마 오류를 방지하지만 선택된 의사결정이 의미적으로 잘못될 가능성은 여전히 있습니다. 독립 평가에서도 여러 데이터셋에서 강력한 결과가 확인되었지만 작업에 따른 오류와 임계값 보정 문제가 함께 발견되었습니다.
OpenAI Decisions API는 GPT-6 Luna를 기반으로 텍스트 또는 이미지를 타입이 지정된 조건값, 선택지 또는 점수로 변환하는 퍼블릭 베타 엔드포인트입니다. OpenAI는 동일한 유형의 작업을 Responses API를 통해 수행하는 것보다 약 10배 빠르다고 설명합니다.
현재 Decisions API의 가격은 입력 토큰 100만 개당 0.10달러이며 출력 토큰 요금은 없습니다. Jev가 공개한 기본 입력 가격은 100만 토큰당 0.042달러로 더 저렴하며, 출력 역시 무료입니다.
확률만으로 애플리케이션이 어떤 행동을 취해야 하는지가 결정되지는 않습니다. 팀은 0.5가 항상 올바른 기준이라고 가정하기보다 라벨이 지정된 평가 데이터와 오탐, 미탐, 사람 검토의 실제 비용을 바탕으로 임계값을 정해야 합니다.
의사결정 모델은 가능한 출력이 미리 정의되어 있고 대규모 분류, 라우팅, 점수화, 검증, 분기에 적합합니다. 개방형 추론, 설명, 콘텐츠 생성 또는 복잡한 계획 수립이 필요한 작업에는 범용 모델을 사용해야 합니다.
TypeSafe Jev는 의도적으로 좁은 방식으로 AI에 접근합니다. 사람을 위한 언어를 생성하는 대신 소프트웨어를 위한 타입이 지정된 의사결정을 생성합니다. 이러한 설계 덕분에 대규모 분류, 라우팅, 점수화 및 검증을 훨씬 저렴하게 수행하고 코드에 쉽게 통합할 수 있습니다.
Jev는 초기 도입 속도가 매우 빨랐고, OpenAI가 GPT-6 Luna 기반 Decisions API로 같은 제품 범주에 신속하게 진입할 정도였습니다. 공개된 기본 입력 가격 기준으로 Jev가 여전히 더 저렴한 반면, OpenAI는 이미지 지원과 기존 범용 모델 플랫폼의 규모를 제공합니다.
핵심 엔지니어링 과제는 형식이 아니라 신뢰성입니다. 타입이 지정된 출력은 한 가지 오류 유형을 줄여주지만 의사결정 정확도는 여전히 데이터셋, 임계값, 오류 비용, 에스컬레이션 정책에 따라 달라집니다. Jev에 대한 독립 연구는 이 점을 특히 분명하게 보여줍니다.
더 큰 변화는 AI가 사용자가 직접 ‘대화하는’ 대상에서 벗어나 일반적인 소프트웨어 내부에서 조용히 실행되는 저비용 의사결정 계층이 될 수 있다는 점입니다.
한 문장에서 시작해 몇 분 안에 완전한 웹사이트를 받아보세요.
