Jev는 오픈 소스인가요? 가중치는 비공개이고, 툴링은 그렇지 않습니다

아니요. Jev 1.13(typesafe/jev-1.13)은 오픈 소스가 아니며, 찾을 수 있는 가중치 저장소도 없고, TypeSafe의 GitHub 조직을 아무리 스크롤해도 체크포인트나 아키텍처 문서, 파라미터 수가 나오지 않습니다. 있는 것은 모델을 둘러싼 소프트웨어뿐입니다: 공개 저장소 11개, 모두 MIT 또는 Apache-2.0이고, 그중 어디에도 Jev 자체는 없습니다. 이것이 정직한 한 줄 답변입니다 — 도구는 열려 있지만 모델은 그렇지 않습니다 — 그리고 이는 독자가 "폐쇄적, 호스팅됨, 미공개"라는 말만으로는 결코 얻지 못하는 이야기의 절반입니다. 두 날짜가 이 이야기의 틀을 이룹니다. TypeSafe는 2026-09-15에 모델을 출시했는데, 이는 이 블로그가 다루는 7일 창 밖이므로 이것은 출시 기사가 아니며, 이 글의 어떤 내용도 출시 기사로 읽혀서는 안 됩니다. 날짜가 붙은 사건은 2026-09-24로, OrcaRouter가 자체 카탈로그에 typesafe/jev-1.13을 추가한 때입니다: Jev가 TypeSafe 자체 엔드포인트만이 아니라 서드파티 게이트웨이를 통해 호출 가능해진 첫 사례입니다. 바로 이것이 이 페이지가 다루는 예외입니다 — 실행 가능하지 않았던 곳에서 실행 가능해진 모델입니다.

독자에게 이것이 바꾸는 것은 좁고 실용적입니다. 2026-09-24 이전에 Jev를 평가한다는 것은, 단 하나의 결정을 테스트하기도 전에 두 번째 벤더 관계를 열어야 한다는 뜻이었습니다. 그 이후에는 Jev가 동일한 워크플로의 생성 부분과 같은 키 위에 자리 잡습니다: 200개 이상의 모델을 위한 단일 API, 0% 마크업(공급자 정가가 그대로 전달되므로 벤더의 가격 인하가 같은 날 여기에 반영됩니다)과 함께, typesafe/jev-1.13에서 모델에 접근할 수 있습니다. 여전히 고유한 형태 — POST /v1/systemone, 비스트리밍 — 로 호출합니다. 그것은 OpenAI chat-completions 경로가 아니기 때문입니다. 하지만 여러분이 서명하는 계약과 교체하는 키는 이미 가지고 있는 것입니다.

그 답은 두 가지 답이며, 둘 다 필요합니다.

“Jev는 오픈 소스인가?”는 예/아니오 질문처럼 읽히지만, 실제로는 두 부분으로 된 질문처럼 작동한다. 첫 번째 부분: 모델. 모델은 비공개다. TypeSafe는 Jev 1.13의 가중치, 아키텍처, 학습 연산량 수치, 파라미터 수를 하나도 공개하지 않았고, 그 이름을 딴 저장소도 없다. 두 번째 부분: 주변 소프트웨어. 이것은 오픈 소스이고, 활발히 유지 관리되며, 정말 유용하다. 그리고 저장소를 찾는 독자가 단순히 운이 없는 게 아닌 이유가 바로 이것이다.

이 둘을 혼동하면 양쪽 방향 모두에서 잘못된 결론에 이른다. 전체가 열려 있다고 가정하면, 존재하지도 않는 체크포인트를 찾느라 오후 한나절을 보내게 된다. 전체가 닫혀 있다고 가정하면, 락인(lock-in)이 걱정될 때 실제로 중요한 조각, 즉 typed-decision 인터페이스에 맞춰 빌드하고 그 뒤에 있는 것을 바꿀 수 있게 해 주는 MIT 라이선스 어댑터를 놓치게 된다.

TypeSafe가 실제로 발표하는 것

2026-09-30 기준으로 확인한 결과, 이 조직은 공개 저장소를 11개 보유하고 있습니다. 스타 수와 푸시 날짜는 계속 바뀌므로, 이를 프로젝트의 고정된 속성이 아니라 스냅샷으로 간주하세요. 별도로 명시되지 않은 한 모든 라이선스는 MIT 또는 Apache-2.0입니다.

• skills — MIT, 약 2.4k 스타, 마지막 푸시 2026-09-12. "TypeSafe의 System One API로 구축하기 위한 에이전트 스킬."

• system-one-adapter-python — MIT, 스타 356개, 최근 푸시 2026-09-22. "LLM API를 기반으로 하는 드롭인 TypeSafeClient 대체품."

• typesafe-sdk-js — MIT, 스타 257개, 마지막 푸시 2026-09-15. TypeSafe API를 위한 공식 TypeScript/JavaScript 라이브러리입니다.

• typesafe-sdk-python — MIT, 스타 254개, 마지막 푸시 2026-09-26. 공식 Python 라이브러리이며, 그날 v0.7.2에서는 `http2` 추가 기능이 추가되었고, 2026-09-21의 v0.7.1에서는 AI 게이트웨이와 함께 사용하는 예제가 추가되었습니다.

• daggerverse — Apache-2.0, 스타 23개, 마지막 푸시 2026-09-25. Dagger 모듈 모음입니다.

• WorkflowEvals — Apache-2.0, 스타 7개, 마지막 푸시 2026-09-29. "evals.typesafe.ai 워크플로 코드 공개됨."

• n8n-nodes-typesafe-ai — MIT, 스타 1개, 최근 푸시 2026-09-29.

• typesafe-ai.github.io — 라이선스 미선언, 스타 2개, 최근 푸시 2026-06-04.

세 개 더는 관련 없는 프로젝트의 포크이며 아래에서 다룹니다: pulumi-clickhouse, LLaDA 및 vllm.

그 목록에 있는 어떤 것도 모델이 아니다. Jev 저장소도, 가중치 파일도, 토크나이저도, 서빙 구성도 없다 — 작동하는 사본을 띄울 수 있게 해 줄 어떤 것도. 저장소들은 클라이언트 측 부속물이다: 두 개의 공식 SDK, 에이전트 스킬 팩, CI 모듈 모음, 공개된 평가 스위트, n8n 노드, 조직 사이트, 그리고 어댑터. 그것은 실재하고 잘 관리되는 표면이며, 모델은 아니다.

락인을 피하려 한다면 주목해야 할 단 하나의 리포지토리

system-one-adapter-python은 도입 결정을 내리는 사람이라면 누구에게나 가장 영향이 큰 항목이며, 그 설명 자체가 핵심을 말해 줍니다: "LLM API 기반의 드롭인 TypeSafeClient 대체품."

그것을 주의 깊게 읽어 보세요. 그것은 특정한 일을 하고 있으니까요. System One 통합에서 지속적인 자산은 인터페이스이지, 그 뒤에 있는 엔드포인트가 아닙니다: 당신은 상태 한 조각과 이름이 지정된 질문들의 집합을 정의하고, 그러면 무언가가 질문마다 하나의 타입이 지정된 답변을 반환합니다. 그 계약이 바로 당신의 코드베이스가 결국 그 모양으로 형성되는 중심입니다. 어댑터는 계약을 구현으로부터 분리합니다 — 당신은 계속 타입이 지정된 결정 인터페이스에 맞춰 구축하고, 결정을 생성하는 것은 그 아래에서 교체 가능한 LLM API 호출입니다.

두 가지 솔직한 단서. 어댑터는 모델이 아니다: 이 경로를 통해 일반 LLM이 생성한 답변은 Jev가 반환하는 보정된 확률이 아니므로, 이는 인터페이스를 이식 가능하게 유지하는 방법이지 Jev 없이 Jev의 동작을 얻는 방법은 아니다. 그리고 이것은 명시적으로 TypeSafe 프로젝트다 — 탈출구는 당신이 탈출하고 싶을 수도 있는 바로 그 공급업체가 만든 것이며, 이는 아무것도 없는 것보다 낫지만 독립적인 탈출구와 같은 것은 아니다.

두 개의 갈림길, 그리고 그것들이 불러일으키는 추론

열한 개 저장소 중 세 개는 포크다. pulumi-clickhouse는 ClickHouse Cloud용 Pulumi 프로바이더이며, Apache-2.0, 별 3개, 마지막 푸시 2026-07-08이다. 나머지 둘은 증거로 읽히는 것들이고, 두 해석 모두 틀렸다.

• vllm — Apache-2.0, 3개, 최근 푸시 2025-05-23. 고처리량 추론 및 서빙 엔진의 포크입니다.

• LLaDA — MIT, 스타 12개, 마지막 푸시 2025-06-17. "Large Language Diffusion Models"를 위한 공식 PyTorch 구현의 포크입니다.

안이한 추론은 저절로 나온다: 그들이 diffusion-language-model 저장소를 포크했으니 Jev도 디퓨전 기반일 것이다. 아니다. 그리고 그 포크는 Jev의 아키텍처에 대해 아무것도 알려주지 않는다. 포크는 다른 누군가의 코드를 다른 누군가의 라이선스 아래 복사한 것이며, 어떤 조직에 놓여 있는 이유는 그 자체의 마지막 푸시 날짜가 명백히 드러내 준다 — 2025년 5월과 6월, Jev가 공개 출시되기 1년 넘게 전이고, 그 이후로는 손대지 않았다. 두 저장소 모두 TypeSafe가 9월에 출시한 것의 일부가 아니다. Jev가 어떻게 작동하는지 알고 싶다면, TypeSafe는 그것을 공개하지 않았고, 그 조직의 어떤 포크도 그 공백을 메우지 못한다.

{{1}}가중치를 닫는 것이 실제로 당신에게 치르게 하는 대가{{/1}}

네 가지입니다. 그리고 그것들은 철학적인 것이 아니라 구체적인 것입니다.

• 셀프 호스팅은 할 수 없습니다. 실행할 아티팩트가 없으므로, 공급업체의 장애나 접근 권한 변경을 자체 사본을 구축해서 우회할 수 있는 방법은 없습니다.

• 감사할 수는 없다. TypeSafe는 Jev 1.13에 대한 들쭉날쭉함 페이지를 게시하기는 한다 — 2026-09-17에 마지막으로 검토됨 — 그 페이지는 모델이 신뢰할 수 없는 부분을 명시한다: 의도보다 문구를 문자 그대로 읽는 것, 산술과 관련된 모든 것, 날짜와 시간 비교, 간접적인 표현과 이중 부정, 무관한 세부 사항으로 가득 찬 큰 상태, 상태 안의 적대적 콘텐츠, 모순되는 지시와 기준, 그리고 모델이 보장하지 않는 구조적 불변식, 가령 true/false 답변과 이에 상응하는 yes/no 선택이 서로 어긋나는 경우다. 그 페이지는 이례적으로 솔직하지만, 여전히 벤더가 자기 숙제를 스스로 채점하는 셈이다. TypeSafe 외부의 누구도 가중치를 검사한 적이 없다.

• 파인튜닝은 할 수 없습니다. 베이스 모델이 없으므로, 잘못 처리된 의사결정 과제는 그 사람이 그것을 바꾸기 전까지 잘못 처리된 상태로 남습니다 — jaggedness 페이지 자체의 우회책은 학습 실행이 아니라 당신 손에 달린 작업입니다.

• 공급업체의 별칭을 넘어서까지 버전을 고정할 수는 없습니다. typesafe/jev-1.13은 호스팅된 이름이므로, 다음 달에 호출에 응답하는 것은 그때 TypeSafe가 그 이름 아래에서 제공하는 것입니다.

그중 Jev만의 특별한 점도 없고 스캔들도 아니다. 그것은 호스팅된 의사결정 모델이 감수하는 트레이드오프이며, 그 반대급부는 체크포인트나 GPU 비용, 추론 스택을 직접 떠안지 않아도 된다는 것이다. 그 위에 구축하기 전에 자신이 그 트레이드오프의 어느 쪽에 있는지 아는 것이 좋다.

이제 호출할 수 있게 되었으니, Jev란 무엇인가

Jev는 채팅 모델이 아니며 산문을 생성하지 않습니다. 상태 — 판단 대상이 되는 자료로, 텍스트, 객체 또는 배열 — 와 이름이 지정된 질문 집합을 보내면, 질문마다 하나의 구조화된 답변을 반환합니다. 모든 질문은 세 가지 기본 요소 중 하나입니다:

• noul — 보정된 확률과 함께 반환되는 참/거짓 판단.

• 선택 — 최대 255개의 레이블이 지정된 옵션 중 하나를 선택하세요.

• 점수 — 2~10단계의 순서형 척도로 평가합니다.

TypeSafe의 자체 문서에는 0부터 시작하는 점수 예시가 나와 있고, Jev 1.13 모델 카드에는 2–10 레벨이 공개되어 있습니다. 둘 다 벤더 자체 자료이며, 이 페이지는 그 둘 사이의 조정을 임의로 만들어 내지 않습니다.

이 훈련 방법은 TypeSafe가 자체적으로 만든 조어인 보정된 결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions, RLCD)으로, 출시 게시물에서 RLHF 및 RLVR과 대비하여 정직한 확률을 갖춘 보정된 결정이라는 축을 기준으로 설명되었다. RLCD는 일반적인 머신러닝 약어가 아니라 TypeSafe의 용어이며, 독립적으로 규명된 기법이라기보다는 벤더 설명으로 읽어야 한다.

접근은 더 이상 제한되지 않습니다: Jev는 2026-09-21부터 일반 제공되었으며, "waitlisted"는 폐기되었습니다. "Early access"는 여전히 TypeSafe가 자사 홈페이지에서 사용하는 현재 표현이므로, 일축할 주장이 아니라 단순히 공급업체의 명칭이며, 그와 함께 공개하는 운영 한도는 구체적입니다.

우리 카드에 적힌 숫자는 다음과 같습니다: 65,536토큰 컨텍스트이며, 공급업체는 결합된 상태와 질문을 통틀어 대략 64K의 입력을 문서화하고 있습니다. Jev에 대해 더 작은 수치가 인용된 것을 보셨다면, 그것은 상충하는 측정치가 아니라 상태 예산만을 가리키는 것이므로, 두 수치를 모순으로 제시해서는 안 됩니다. 가격은 백만 입력 토큰당 $0.042이고 출력은 0으로 청구됩니다 — 계량할 출력 토큰이 없습니다. 왜냐하면 입력된 결정은 산문이 아니기 때문입니다.

벤더 벤치마크가 아닌 자체 트래픽에서 얻은 우리의 서빙 데이터, 2026-09-30까지 7일간: p50 151ms, p95 247ms, 초당 출력 토큰 약 349개, 오류율 0.49%, 서빙 토큰 7,620만 개. 해당 기간의 일별 p50은 175 → 170 → 163 → 161 → 170 → 147 → 143ms였고, 실제 이상치가 하나 있습니다 — 2026-09-28의 p95 2,448ms로, 이는 시계열에 포함되지만 일반적인 기준은 아닙니다.

TypeSafe의 대표 주장들은 벤더 측 주장으로 표시되어 있으며 독립적으로 재현되지 않았습니다: System One 워크플로에 각주가 달린 "193.6배 더 빠르고, 444.6배 더 저렴함"; LLM의 경우 8.566초에 $0.013880인 것과 대비되는 0.114초에 $0.000081이라는 산출 예시; "입력 토큰 10억 개당 $42"; 그리고 "환각 제로"가 있는데, 이는 오류가 전혀 없다는 증명이라기보다 신뢰도 추정에 관한 주장입니다 — 우리 카드의 0.49% 오류율이 정직한 균형추입니다. TypeSafe는 또한 자사의 가격 책정이 보조금을 받지 않았다는 것을 증명할 수 없다고 분명히 밝히며, 공개된 평가는 일반적으로 서비스 기반지인 서부 해안에서 노트북으로 실행되었다고 합니다. 자체 벤치마크 카드도 여전히 보류 중으로 표시되어 있습니다.

제3자 리포지토리는 존재하며, 당사는 이에 대해 보증하지 않습니다.

"jev github"를 검색하면 결국 TypeSafe의 것이 아닌 저장소들이 나타난다. 래퍼, 프롬프트 모음, 어댑터 실험, 그리고 새로운 모델이 나올 때마다 등장하는 익숙한 "awesome" 목록이다. 이것들은 벤더가 게시하는 것의 일부가 아니며, 벤더의 검토를 거치지 않았고, 스타 수는 정확성보다 호기심을 측정한다. 유용할 수는 있지만 문서는 아니며, 그 안의 어떤 내용도 Jev가 어떻게 작동하는지에 대한 진술이 아니다.

이 답변을 바꾸려면 무엇이 필요할까요?

가중치 공개, 아키텍처 공개, 또는 지연 시간이 아니라 결정 품질에 대한 독립적 평가. 이 세 가지 중 어느 하나라도 이 페이지의 첫 단어를 뒤집을 것입니다. 그때까지는 검색에 안정적인 답이 있으며, 그중 실제로 행동할 가치가 있는 부분은 툴체인입니다: 타입 지정 결정 인터페이스를 대상으로 개발하고 있다면, 백킹 모델을 교체하는 MIT 라이선스 어댑터가 다시 검토할 수 있는 결정과 그럴 수 없는 결정을 가르는 차이입니다.

Jev 1.13은 typesafe/jev-1.13 아래 우리 카탈로그에 있으며, 스택의 나머지와 동일한 키로 chat-completions 형태가 아닌 전용 systemone 엔드포인트를 통해 라우팅됩니다. 모델은 비공개이고 도구는 공개되어 있으며, 그 두 측면 모두 이제 한곳에서 접근할 수 있습니다.