"모델 범주로서의 "System One": Jev 1.13이 그 안에서 어디에 위치하는가"

"System One"은 TypeSafe가 결정을 내리는 모델과 글을 쓰는 모델을 나눌 때 사용하는 범주 용어이며, Jev 1.13(typesafe/jev-1.13)은 그 첫 번째 구성원이다 — 문장이 아니라 타입이 지정된 답변을 반환하는 모델이다. 새로운 모델이 아니다. TypeSafe는 2026-09-15에 Jev를 출시했고, 이 페이지는 출시 기사가 아니다. 이 모델은 나온 지 15일 된 것으로, 이 블로그가 다루는 7일 범위 밖에 있다. 그 범위 안에서 일어난 일은 OrcaRouter가 2026-09-24에 이 모델을 자사 카탈로그에 추가하고 https://www.orcarouter.ai/models/typesafe/jev-1.13 에서 Jev 1.13 모델 카드를 공개한 것이다 — 제3자 게이트웨이를 통해 호출할 수 있게 된 첫 번째 사례. 지금까지는 TypeSafe 자체 엔드포인트를 통해서만 호출할 수 있었다. 이 범주 개념이 이 페이지가 존재하는 이유이고, 서빙 변경이 이 페이지의 날짜가 오늘인 이유다.

범주를 쉽게 말하면: LLM은 질문을 받고 사람이 읽을 답을 쓴다. System One 모델은 질문을 받고 프로그램이 분기할 값을 반환한다. TypeSafe의 자체 설명은 "LLM은 사람을 위한 단어를 생성한다"인 반면 "Jev는 타입이 지정된 결정을 생성하며 코드에 더 가깝다: 신뢰할 수 있고, 빠르고, 자기 일관적이며, 타입 안전하다"라는 것이다. 그 문장은 전체 범주를 하나의 절로 압축한 것이며, 천천히 풀어볼 가치가 있다. 네 형용사가 각기 다른 양의 일을 하고 있고 그중 하나는 다른 것들보다 더 많은 일을 하고 있기 때문이다.

'코드에 더 가깝다'가 실제로 주장하는 것

네 가지 주장을 순서대로 살펴보세요. 그것들은 ‘더 낫다’라는 말을 네 번 다시 말한 것이 아니기 때문입니다.

• 신뢰할 수 있음 — 출력 형태는 미리 고정되어 있습니다. 질문은 당신이 선언하고, 답변은 당신이 허용한 값 중 하나로만 돌아올 수 있습니다. TypeSafe는 "모델은 결코 타입 오류를 일으키지 않는다"라고 분명히 밝히며, 이 주장이 반례로 반증하는 것이 "수학적으로 불가능"한 그들의 유일한 주장이라고 언급합니다. 왜냐하면 당신이 선언한 집합에 없는 값은 모델이 내보낼 수 있는 값이 아니기 때문입니다.

• 빠름 — 모든 답변은 토큰을 하나씩 생성하는 대신 단일 패스로 생성됩니다. TypeSafe의 출시 게시물은 "Jev는 토큰별로 자기회귀적으로 생성하는 대신 모든 확률을 병렬로 출력합니다"라고 표현합니다. 2026-09-30에 끝나는 자체 7일 서빙 기간에서 typesafe/jev-1.13의 첫 토큰까지의 시간 중앙값은 151ms이고 p95는 247ms입니다.

• 자기 일관성 — 동일한 상태에서 동일한 질문을 하면 동일한 답을 낼 경향이 있다. 코딩 비유는 이것을 이해할 수 있게 해주지만, 그것은 또한 비유가 증명이기를 그치는 지점이기도 하다: 컴파일러의 결정성은 그 구성의 속성인 반면, 이것은 행동에 대한 주장이다. 우리 자신의 측정이 이에 대한 정직한 해석이다 — 동일한 7일 기간 동안 우리 플레이그라운드 트래픽의 오류율은 0.49%이므로, 그것은 산술이 일관적인 방식이 아니라 좋은 함수가 일관적인 방식으로 자기 일관적이다.

• 타입 안전 — 그리고 이것이 가장 무게를 많이 지는 항목입니다. 여기서 타입 안전은 품질을 나타내는 형용사가 아닙니다. 이는 모델이 타입 검사기에 대해 어디에 위치하는지에 관한 진술입니다. 일반적인 생성 파이프라인에서 타입 시스템은 모델이 끝난 뒤에 시작됩니다. 모델이 텍스트를 쓰고, 파서가 그 형태를 추측하고, 검증기가 이를 확인하며, 추측이 틀린 경우는 실패 경로가 처리합니다. System One 모델은 타입 선언을 호출 이전으로 옮깁니다. 우리 카드가 문서화하는 세 가지 기본 요소가 바로 그 타입 시스템입니다: noul, 보정된 확률과 함께 반환되는 참/거짓 판정; choice, 최대 255개의 레이블이 붙은 옵션 중에서 선택된 하나의 레이블; 그리고 score, 2~10단계의 순서형 척도상의 평점. 기본 요소를 고르고, 레이블이나 기준을 제공하면, 돌아오는 값은 바로 그 집합에서 나옵니다.

TypeSafe는 자사 문서와 우리 문서 사이에 하나의 차이가 있음을 공개하는데, 이는 해결하기보다는 짚고 넘어갈 가치가 있습니다. 벤더 문서에는 0부터 시작하는 인덱스를 쓰는 Score 예제가 나와 있는 반면, 우리 카드에서는 척도를 2~10레벨로 문서화합니다. 둘 다 같은 프리미티브를 설명하는 것입니다. 임계값을 만들고 있다면, 사용 중인 SDK가 어떤 인덱싱을 쓰는지 정확히 확인하려면 벤더 페이지를 읽으세요.

더 이상 존재하지 않게 되는 두 가지 실패 모드

"산문 없음"의 흥미로운 결과는 미학적인 것이 아니다. 그것은 프로덕션 생성 파이프라인을 지배하는 두 가지 실패가 이 설계에서 완화되는 것이 아니라 아예 존재하지 않는다는 점이다.

형식 드리프트가 첫 번째입니다. JSON을 반환하라는 지시를 받은 LLM은 대부분의 경우 JSON을 반환하지만, 나머지 경우에는 JSON에 가까운 무언가를 반환합니다 — 뒤따르는 주석, 마크다운 펜스, 동의어로 이름이 바뀐 필드, 스키마가 문자열을 원했던 곳에 중첩 객체. 프롬프트 수준의 수정(더 강력한 지시, few-shot 예시, 시스템 메시지의 스키마)은 모두 모델이 자유롭게 버릴 수 있는 형태를 유지하려는 시도입니다. 왜냐하면 그 형태는 제약이 아니라 요청이기 때문입니다. TypeSafe의 프레이밍은 그 대비를 명확히 합니다: 문자열의 경우, "가능한 출력과 구조"는 요청되고 응답은 "파싱 + 검증"이 필요하며, "AI가 궤도를 이탈할 위험이 항상 있습니다." 가능한 출력이 미리 선언되면, 드리프트는 갈 곳이 없습니다.

파싱할 수 없는 출력은 두 번째이며, 그것은 정말로 더 나쁜 순간에 발생하는 같은 실패입니다 — 약간 잘못된 값으로 돌아온 필드가 아니라, 파서가 전혀 읽을 수 없는 응답이 워크플로에서 가장 곤란한 시점에 도착하는 경우입니다. 타입이 지정된 값을 내보내는 모델에는 그런 상태가 없습니다.

이것은 구조적 논증이며, 그렇게 진술되어야 합니다. 그것은 개별 답변이 올바른지에 대해서는 아무 말도 하지 않습니다 — 선택형 질문은 잘못된 레이블을 고를 수 있고, noul은 true를 정직한 답이 거짓일 때도 높은 확신으로 반환할 수 있습니다. 사라지는 것은 파서라면 잡아냈을 실패 범주입니다. 이는 실질적이고 유용한 감소이며, "답변들이 맞다"라는 주장과는 같지 않습니다.

가격이 할인이 아니라 형태인 이유

이 모델의 가격은 입력 토큰 100만 개당 $0.042이며, 출력에는 요금이 전혀 부과되지 않습니다. 그리고 그 0은 프로모션 요율이 아니라 설계상의 산물입니다. 구조화된 답변을 세 개의 토큰으로 내놓는 모델은 과금할 출력량이 없으므로, 출력 토큰당 과금은 붙을 대상이 없습니다. 과금 형태는 입력 토큰당 요금과 하나의 결정으로 이루어집니다. 우리 카탈로그는 공급자의 정가를 0% 마진으로 그대로 전달하므로, $0.042는 우리가 정한 숫자가 아니라 TypeSafe의 숫자이며, 공급자가 가격을 변경하면 같은 날 바로 반영됩니다.

두 도형을 나란히 놓으면 그 차이는 백분율이 아니다. 생성형 파이프라인의 비용은 모델이 얼마나 말하는지에 비례한다. 같은 결정에 대해서도 장황한 답변이 간결한 답변보다 더 많은 비용이 들며, 사고 연쇄 추론 모델은 답변이 개선되든 아니든 답하기 전에 생각하는 데 소비한 토큰에 대해 비용을 청구한다. System One 호출의 비용은 얼마나 많이 보여주는지, 즉 상태와 질문에 비례한다. 긴 문서에 대해 질문 하나를 던지면 문서값을 지불한다. 같은 상태에 질문 40개를 몰아넣으면(우리 카드의 입력 예산은 상태와 질문을 합쳐 65,536토큰, 대략 64K다. 이전 OrcaRouter 기사에서 “약 32,000토큰”이라는 수치를 본 적이 있다면, 그것은 상태 예산만을 가리키는 것이지 이와 경쟁하는 총합이 아니다) 문서값은 한 번만 지불하고 40개의 결정을 돌려받는다.

그렇기 때문에 이 범주에서는 토큰당 비용이 아니라 결정당 비용이 올바른 단위입니다 — 그리고 대부분의 팀이 예상하는 것과 반대 방향으로 비용 계량기가 돌아가는 이유이기도 합니다. 생성형의 전형적인 비용 절감 방식은 "모델이 말을 덜 하게 만들기"입니다. 여기서는 덜 말하게 할 것이 아무것도 없습니다.

TypeSafe가 자체적으로 내놓은 수치—공급업체가 보고한 것이며 독립적으로 재현된 적은 없다—는 바로 그 비교를 정면으로 겨냥한다: "193.6배 더 빠르고, 444.6배 더 저렴함"이라는 문구가 "System One 작업을 위한 워크플로에 기반함(증명)"이라는 각주와 함께 붙고, "TypeSafe AI 비용 $0.000081, 0.114초에 완료 / LLM 비용 $0.013880, 8.566초에 완료"라는 계산 예시가 제시된다. 홈페이지는 또한 "입력 토큰 10억 개당 $42"를 "Claude Fable 5.1보다 238배 더 낮은 입력 가격"과 대비해 나열한다. 이 모든 것을 측정된 결과가 아니라 공급업체의 주장으로 취급하라: 출시 게시물은 "우리가 공개한 평가는 일반적으로 서부 해안에서 우리 노트북으로 실행된다"라고 인정하고, "그것이 보조금을 받은 것이 아니라고 증명할 수 없다; 우리 가격 책정의 지속 가능성을 증명하려면 장기적인 시간이 필요하다(우리는 그 가격이 오르지 않고 내려갈 것으로 예상한다)"라고도 인정한다. 그 두 가지 인정은 공급업체 스스로 한 것이며, 페이지의 모든 배수에 적용해야 할 올바른 틀이다.

캘리브레이션은 아이디어의 후반부입니다.

만약 이 범주가 단지 "구조화된 출력"에 불과하다면, 그것은 추가 단계가 있는 함수 호출을 설명하는 것에 지나지 않을 것이다. 이것을 독자적인 것으로 만드는 부분은 모든 답변이 확률과 함께 제공된다는 점이며, 그 확률들이 훈련 목표이다. TypeSafe는 이 방법을 RLCD(Reinforcement Learning for Calibrated Decisions)라고 부른다 — 일반적인 약어가 아니라 그들만의 용어이다 — 그리고 출시 게시물의 비교 표는 이를 RLHF 및 RLVR과 나란히 배치한다: RLHF는 인간 평가자가 선호하는 것을 최적화하고, RLVR은 프로그래밍 방식으로 확인할 수 있는 출력을 최적화하며, RLCD는 "시스템 1 작업에서 인식론적으로 정직한 확률을 가진 답변"을 최적화한다.

실질적인 차이는 그 확률이 무엇을 위한 것이냐에 있습니다. 생성형 파이프라인에서 신뢰도 추정은 2차 생성입니다. 모델에게 얼마나 확신하는지 물으면 숫자를 써 내는데, 그 숫자 자체가 동일한 실패 양상을 지닌 산문입니다. 여기서는 확률이 결정과 함께, 같은 패스에서 돌아오며, 그것이 바로 분기 기준이 됩니다. Theseus의 출력 프레이밍은 이렇습니다: 95%의 경우 작업을 수행할 수 있지만 "1%일 때는 말하지 않는" 모델은 그 작업을 자동화하는 데 사용할 수 없습니다. 신뢰도는 에스컬레이션을 둘 곳 — 사람에게든 추론 모델에게든 — 을 제공합니다.

TypeSafe의 홈페이지는 이를 "Zero Hallucinations"라고 표현하며, 모든 결정에 신뢰도 추정치가 포함되어 소프트웨어가 "신뢰도가 높을 때 행동하고 그렇지 않을 때 에스컬레이션할 수 있다"고 설명합니다. 이를 주의 깊게 읽어보세요: 그것은 신뢰도 추정치에 관한 주장이지, 어떤 답도 결코 틀리지 않는다는 주장이 아닙니다. 우리 자체 카드는 그에 대한 균형추입니다 — 2026-09-30로 끝나는 7일 동안, 우리 트래픽에서, 우리가 측정한 0.49%의 오류율. 그 수치는 고정된 테스트 세트가 아니라 롤링 윈도우입니다: 같은 윈도우에서 며칠 전에는 0.57%를 기록했고, 앞으로도 다시 변할 것입니다.

System One이 System Two 옆에 위치한 곳

fast/slow라는 용어는 TypeSafe보다 훨씬 오래전부터 있었습니다. 그것은 카너먼의 《생각에 관한 생각》에서 비롯되었으며, 이보다 수년 전부터 AI 연구자들이 이를 차용해 왔습니다 — "System 2"라는 레이블은 TypeSafe가 존재하기 훨씬 전부터 사고 연쇄와 숙고형 추론 모델에 붙어 있었고, TypeSafe는 두 용어 중 어느 것도 자신들이 만들어냈다고 주장하지 않습니다. 그들이 한 일은 그 구분을 프롬프팅 모드가 아니라 제품 경계에 적용한 것입니다.

• 시스템 2 추론 모델은 답하기 전에 더 많은 연산을 사용하고, 그 연산이 필요한 문제를 더 잘 해결한다. 출력은 여전히 산문이며, 추가 연산은 출력 토큰으로 청구된다.

• TypeSafe가 말하는 의미의 System One 모델은 더 나은 답을 내기 위해 더 오래 생각하지 않는다. 그것은 단 한 번의 패스로 답하며, 속도를 위해 포기하는 것은 타입이 지정된 값이 아닌 다른 무엇이든 생성할 수 있는 능력이다.

• 이 둘은 비교의 경쟁자가 아니라 워크플로우에서 서로를 보완하는 요소다. System One 호출은 빠르고 저렴하며 알아보기 쉬워야 하는 결정을 처리하고, 추론 모델은 신뢰도 점수가 불확실하다고 표시한 사례를 맡는다. 타입이 지정된 출력이야말로 인계를 깔끔하게 만든다 — 다음 단계로 다시 파싱할 문장이 아니라 값과 확률을 넘기는 것이다.

용어가 흔들리는 지점은 "System One 모델"을 다른 벤더들이 채택한 확립된 범주로 취급하는 데 있다. 그에 대한 증거는 없으며, 이 페이지가 그런 주장을 하는 것으로 읽혀서는 안 된다. TypeSafe는 이 용어를 자사의 모델 부류에 사용한다. 우리 자체 카드의 면책 문구도 단일 모델에 대해 단일 엔드포인트 유형만 나열함으로써 같은 점을 생략으로 말해 준다. 다른 연구소가 동일한 아키텍처를 가리켜 이 표현을 쓰기 시작한다면, 그것은 보고할 가치가 있는 사실이 될 것이며, 그 사실을 보고하려면 그들 자신의 말이 필요할 것이다.

우리 카드 역시 들쭉날쭉함을 뜻밖의 일이 아니라 정직한 경계의 일부로 명시합니다: 이름 붙은 아홉 가지 실패 모드입니다. 문자 그대로 읽기와 우회 표현 항목은 "코드에 더 가깝다"는 비유에서 곧바로 따라 나오는 것들입니다 — 당신이 의도한 질문이 아니라 당신이 쓴 질문에 답하는 모델은 코드가 말한 대로 정확히 수행한 함수처럼 행동하는 것입니다. 세기 항목은 그렇지 않습니다. "집계하기보다는 답의 모양을 알아보는" 모델은 코드와 전혀 닮지 않았으며, 그래서 TypeSafe 자체의 권장 사항은 코드에서 세고, 판단이 진정으로 필요한 경우에는 항목마다 질문 하나를 던지고 답을 직접 더하라는 것입니다.

점수가 아니라 디자인을 결정짓는 두 가지 한계

둘 다 같은 곳에서 비롯됩니다: 문자열이 없다는 것은 스트리밍할 것도, 조각으로 나누어 보낼 것도 없다는 뜻입니다.

• 비스트리밍 — 첫 출력이 완성된 답변이므로, System One 호출은 스트림이 아니라 단일 응답입니다. 문제는 스트리밍할 수 있는지가 아니라 무엇이 스트리밍될 것인가입니다.

• 하나의 요청 형태 — 이 모델은 chat-completions 형태가 아니라 우리 카탈로그에서 POST /v1/systemone을 통해 제공되며, 이것이 이 모델이 "자체적인 요청 형태를 사용한다"는 예전 주장을 솔직하게 표현한 것입니다. 이는 호출 방식에 실질적인 차이를 만듭니다: 상태 객체와 이름이 지정된 질문 맵이 들어가고, 질문별 구조화된 답변이 나옵니다. 여러분은 이에 대한 매퍼를 작성하게 될 것이며, 출력이 타입 지정되어 있기 때문에 매퍼가 통합의 전부입니다 — 그 아래에는 방어적인 파싱 계층이 없습니다.

부하 테스트를 하기 전에 알아두면 좋은 점: 지연 시간은 질문 유형 전반에 걸쳐 일정하지 않습니다. TypeSafe는 그 이유를 그들 나름의 표현으로 이렇게 설명합니다 — "카디널리티가 더 높은 선택지의 경우, 우리는 독립적으로 점수를 매긴 다음 명시적으로 선택하는 2단계 시스템을 사용하기 때문에 가끔 느려집니다." 4개 선택지 라우팅 결정과 200개 선택지 분류는 이론상 같은 프리미티브이고, 실제로는 작업량이 다릅니다. 2026-09-30에 끝나는 7일 동안의 일별 중앙값은 175, 170, 163, 161, 170, 147, 143ms입니다. 그 시계열 중 하루인 2026-09-28은 p95가 2,448ms였습니다. 이는 시계열에 정직하게 자리하는 실제 단일 일자 이상치이지만, 서비스의 형태는 아닙니다.

첫 통합 전에 알아야 할 또 하나는 무엇에 연결하는지입니다. Jev를 둘러싼 툴링은 MIT 및 Apache-2.0 라이선스로 오픈 소스입니다 — Python 및 JavaScript SDK, 일반 LLM API를 백엔드로 같은 클라이언트를 제공하는 어댑터, 워크플로 평가 코드, 그리고 일련의 에이전트 스킬이 모두 TypeSafe의 공개 저장소에 있으며, 스타 수와 푸시 날짜는 2026-09-26과 2026-09-29처럼 최근까지도 움직였습니다. 모델은 다릅니다. 가중치 저장소는 없습니다. Jev의 아키텍처, 파라미터 수, 학습 컴퓨트, 가중치는 공개되지 않았으며, 이를 확인하는 독자는 해당 조직의 저장소 중 서로 무관한 프로젝트의 포크인 세 개 — vLLM 포크, 2025년의 확산 언어 모델 릴리스, 그리고 Pulumi 제공자 — 에 현혹되어서는 안 됩니다. 그중 어느 것도 Jev가 어떻게 만들어졌는지에 대해 말해주지 않습니다. 한 줄로 답하자면, 툴링은 열려 있고 모델은 그렇지 않습니다.

오늘 실행해 보기, 그리고 독자에게 달라지는 점

Jev 1.13은 OrcaRouter에 typesafe/jev-1.13으로 있으며, 200개 이상의 다른 모델과 동일한 키로 접근할 수 있고, 공급자의 정가는 0% 마크업으로 그대로 전달됩니다. 카테고리에 관한 페이지에서 이것이 지니는 실질적 가치는 좁고, 정확히 밝힐 가치가 있습니다. System One 모델을 시험하는 데 이제 별도 계정, 별도 키, 별도 청구서가 필요하지 않습니다 — 아직 원하는지 모를 수도 있는 모델을 위해서도 말입니다. 그것은 같은 워크플로의 생성 절반 옆에 자리합니다 — 분류기와 작성기가 하나의 자격 증명으로, 한곳에서, 실제로 호출한 것의 집계와 함께 있습니다.

여기서 모델 자체가 무엇인지는 달라지지 않습니다. 이 모델은 2026-09-15에 출시되었고 TypeSafe는 여전히 얼리 액세스라고 설명하며, 그 정체는 그때 이후로 변하지 않았습니다. 2026-09-24에 달라진 점은, 이제 독자가 먼저 두 번째 공급업체 관계를 맺지 않고도 실제로 자신에게 비용이 얼마나 드는지 알아볼 수 있다는 것입니다. 이 범주가 프로토타입을 만들어 볼 가치가 있는지 지켜보고 있었다면, 바로 그 부분이 달라진 것입니다.