TypeSafe AI란 무엇인가? Jev 1.13을 만든 연구소는 문장이 아니라 결정을 내린다

TypeSafe AI는 문장 하나도 쓸 수 없는 모델을 판매하는 샌프란시스코의 작은 연구소이며, 문제의 그 모델은 Jev 1.13 (typesafe/jev-1.13)이다. 그것은 상태 한 조각 — 이메일, 로그 한 줄, 지원 티켓, JSON 블롭 — 그리고 이름이 붙은 질문 묶음을 받아, 질문마다 타입이 지정된 답변 하나를 반환하며, 각 답변에는 고유한 신뢰도 값이 있다. 산문도, 코드도, 설명도, 채팅창도 없다. 모델 자체는 2026-09-15에 출시되었으므로 새로운 것이 아니며, 여기 있는 어떤 것도 출시 이야기가 아니다: 이 페이지는 더 작고 날짜를 특정할 수 있는 변화 때문에 존재한다. 2026-09-24에 OrcaRouter는 typesafe/jev-1.13을 자사 카탈로그에 추가하고 자체 주소에서 모델 카드를 열었는데, 이는 Jev가 TypeSafe 자체 엔드포인트를 통해서만이 아니라 서드파티 게이트웨이를 통해서도 호출될 수 있게 된 첫 사례였다. 그것이 그 사건이고, 2026-09-30 기준으로 엿새 된 일이며, 아직 TypeSafe 계약이 없는 독자도 이제 System One 모델을, 그것이 나란히 있도록 설계된 생성 모델들과 같은 키 아래에 둘 수 있는 이유다. 이 페이지의 나머지 모든 내용은 그것을 만든 회사에 대한 배경 설명이다.

타이밍을 솔직하게 정리하자면, 이는 이 내용이 얼마나 검증된 것인지에 중요하기 때문입니다: Jev는 두 주도 더 전에 출시되었고, TypeSafe가 대기자 명단을 해제한 2026-09-21부터 정식 제공되어 왔습니다. 7일 기간 안에 들어 있는 것은 모델이 아니라 라우팅 변경입니다. 출시 리뷰를 기대하고 이곳에 오셨다면, 출시는 이미 있었고 몇 편의 다른 글들이 그것을 다뤘습니다.

매니페스토는 있지만 아키텍처 다이어그램은 없는 회사 페이지

TypeSafe는 자체 메타 설명에서 스스로를 "자동화를 위한 머신 네이티브 인텔리전스 인프라를 구축하는 AI 랩"이라고 설명하며, 그 시스템은 "소프트웨어 내에서 의사 결정을 내리도록 설계"되었다고 밝힌다. 홈페이지에는 Version 0.01이 찍혀 있고 푸터에는 "Made in SF"가 적혀 있다. AI 형태의 경제적 전환으로 가는 가장 짧은 경로는 지능을 조합 가능하게 만들어, 소프트웨어가 함수를 호출하듯 의미 판단을 호출할 수 있게 하는 데 있다고 주장하는 선언문이 있다. 회사가 스스로 요약한 계획은 머신 네이티브 조합형 AI의 형태를 출시한 뒤, 실제 자동화에 쓰일 만큼 충분히 믿을 수 있게 만들고, 그 위에 층을 쌓을 수 있을 만큼 안정적인 더 높은 수준의 추상화를 제공하는 것이다. 슬로건은 "우리는 신이 아니라 프로덕션을 만든다"이다. 팀 페이지에는 세 명의 창립자가 이름을 올린다 — Diogo Almeida는 CEO, Sasha Sheng은 COO, Erik Gafni는 CTO다. 이것이 회사가 스스로에 관해 말하는 전부다: 하나의 입장, 하나의 제품, 세 개의 이름, 그리고 회사 자체에 관한 숫자는 전혀 없다.

이 사이트가 담고 있지 않은 것은 새로운 의존성을 평가하는 엔지니어가 가장 먼저 찾는 바로 그것이다. 아키텍처 페이지도, 파라미터 수치도, 학습 컴퓨트 공개도, 학술적 의미의 모델 카드도 없다. TypeSafe 자체의 벤치마크 대시보드는 여전히 보류 중으로 표시되어 있다. 신뢰성을 내세우는 회사치고는 공개 범위가 빈약하며, 이는 숨겨지고 있는 것에 대한 고발이라기보다 공개된 것에 관한 사실이다.

System One: 카테고리, 그리고 그 이름을 빌려온 이유

Jev는 TypeSafe가 System One 모델이라고 부르는 것들 중 첫 번째입니다. 그 이름은 대니얼 카너먼이 빠르고 직관적인 System 1 사고와 느리고 신중한 System 2 추론을 구분한 데서 비롯되었으며, 회사의 출시 게시물도 이를 직접 밝히고 있습니다 — 또한 "System 1 사고"가 오류가 발생하기 쉽다는 뉘앙스를 지녀 왔음을 인정하면서도, 이 모델들이 대안들보다 더 신뢰할 수 있게 만들어질 수 있다고 주장합니다. TypeSafe가 이 용어를 만든 것도, 소유한 것도 아닙니다.

카테고리의 실질적인 내용은 의도적인 역할 분담입니다: 결정하는 모델과 작성하는 모델입니다. 산술, 날짜 순서, 계산, 문자열 비교는 정확한 일반 코드에 남겨 두고, 의미론적 판단은 Jev에게 맡기도록 되어 있습니다. 그것이 답할 수 있는 것은 세 가지 질문 유형입니다:

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

• choice — 레이블이 지정된 최대 255개 옵션 중 하나를 선택합니다

• 점수 — 순서가 있는 척도로 평가합니다. 우리 카드는 2–10 레벨을 게시하며, TypeSafe 자체 문서에는 0부터 시작하는 예가 나오므로, 벤더의 레벨을 정의로, 2–10은 카드가 게시하는 것으로 취급하세요.

각 질문에는 자체 지침이 있고, 선택과 점수 산정에는 자체 기준이 있습니다. 대략 64K 입력 토큰을 초과하는 요청은 모델에 도달하기 전에 거부되며, 응답은 스트리밍되지 않습니다. 공급업체는 상태 예산 — 상태에 단일 최장 질문을 더한 것 — 을 32K 토큰으로 별도 문서화하는데, 이는 카드에 적힌 65,536토큰 컨텍스트보다 좁은 수치이며 그것과 모순되지 않습니다.

그들의 논지, 그들 자신의 말로

TypeSafe는 이 논지를 어떤 요약보다도 더 잘 말해 주므로, 여기에 그대로 옮긴다: “LLM은 사람을 위해 단어를 만들어 낸다. Jev는 타입이 지정된 결정을 산출하며, 코드에 더 가깝다: 신뢰할 수 있고, 빠르며, 스스로 작동하고, 타입 안전하다.” 그 배후의 훈련도 그들의 것이며, 이 용어는 마치 일반 명사인 것처럼 다른 곳에서 받아들여졌기 때문에 정확히 출처를 밝혀야 하는 말이다. TypeSafe는 이를 Reinforcement Learning for Calibrated Decisions, 즉 RLCD라고 부르며, RLHF 및 RLVR과 대비시킨다: RLHF와 RLVR이 인간 선호나 프로그래밍 방식으로 검증 가능한 보상을 최적화하는 반면, 회사의 표현을 빌리면 RLCD는 “System One 과제에서 인식론적으로 정직한 확률을 지닌 답변”을 목표로 한다. RLCD를 문헌에서 확립된 약어가 아니라 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배 낮음."이 있다. 그리고 "환각 제로"라는 제목의 섹션이 있는데, 자세히 살펴보면 이는 오류 제로에 대한 증명이라기보다 신뢰도 추정에 관한 주장이다: 모든 Jev 결정에는 신뢰도 추정치가 따르므로, 소프트웨어는 신뢰도가 높을 때 행동하고 그렇지 않을 때는 에스컬레이션할 수 있다. 네 가지 수치 모두 TypeSafe가 선택한 워크로드에서 나온 TypeSafe의 수치이며, 그중 어느 것도 독립적으로 재현되지 않았다. 출시 게시물 자체에서도 팀은 자사의 193.6배와 444.6배가 실제 환경에서 얻을 수 있는 개선폭의 높은 쪽에 있을 것으로 예상하며, 해당 워크플로는 자체 역량 팀이 구축했고 참조 답변은 경쟁 모델이 생성했다고 밝힌다. 동일 모델에 대한 저희 자체 7일 서빙 데이터에서는 오류율이 0.49%로 나타나는데, 이는 다른 워크로드에 대한 다른 측정치이며 "제로"를 절대적인 것으로 읽는 데 대한 정직한 균형추다.

그들이 공개하지 않은 것

Jev의 아키텍처, 파라미터 수, 학습 연산량 및 가중치는 공개되지 않았으며, 회사의 GitHub 조직에는 가중치 저장소가 없습니다. 2026-09-30 기준으로 확인했을 때, 그 조직에는 공개 저장소가 11개 있으며, 실질적인 저장소들은 모두 MIT 또는 Apache-2.0인 툴링입니다 — 에이전트 스킬 저장소, Python SDK, TypeScript SDK, 다른 LLM API를 기반으로 하는 드롭인 클라이언트 어댑터, Dagger 모듈 모음, 공개된 워크플로 평가 코드, n8n 노드, 그리고 조직 자체 사이트입니다. 스타 수와 푸시 날짜는 계속 변하므로, 이 페이지를 보고 판단하기보다는 그날그날 직접 확인하세요.

열한 개 중 셋은 서로 무관한 프로젝트의 포크입니다: vLLM, LLaDA, 그리고 ClickHouse Cloud용 Pulumi 프로바이더입니다. 그것들은 다른 누군가의 작업을 포크한 것이라 Jev가 어떻게 만들어졌는지에 대해서는 아무것도 말해주지 않습니다 — 특히 Jev가 확산 기반이라는 점에 대해서는요. Jev가 오픈 소스인지에 대한 한 줄 답은 도구는 공개되어 있고 모델은 그렇지 않다는 것입니다.

그들이 스스로 인정하는 것

런칭 포스트에서 나온 두 가지 인정은 대부분의 공급업체 주의사항보다 더 가치가 있습니다. 왜냐하면 그것들은 증거가 취약한 정확한 지점을 지목하기 때문입니다. 가격에 관해서는: "우리는 그것이 보조금을 받지 않는다는 것을 증명할 수 없습니다; 우리의 가격 책정의 지속 가능성을 증명하려면 장기적인 시간이 필요할 것입니다 (우리는 가격이 오르지 않고 내려갈 것으로 예상합니다)." 속도에 관해서는: "우리가 공개한 평가는 일반적으로 서부 해안에 있는 우리 노트북에서 실행됩니다 (현재 우리 서비스가 기반을 두고 있는 곳입니다)." 그것을 기반으로 구축하는 사람에게 더 유용한 세 번째 인정이 있습니다: 고유값이 많은 선택 세트의 경우, Jev는 독립적으로 점수를 매긴 후 명시적인 선택을 하는 2단계 시스템을 실행합니다, "따라서 때때로 속도 저하가 발생합니다." 그것은 공급업체가 질문 유형에 따라 지연 시간이 일정하지 않은 이유를 설명하는 것이며, 일반적으로 지원 스레드에서 알게 되는 종류의 것입니다.

오늘 기준으로, 실제로 그것을 호출할 수 있는 곳

TypeSafe 자체 API를 통해, 모델은 일반 제공되고 홈페이지는 여전히 벤더 자체 표현인 "early access"를 사용합니다. 그 표현은 현재 유효하며 유지할 가치가 있는 반면, "waitlisted"는 폐기되었습니다. 문서에는 구체적인 운영 한도(초당 100K 토큰, 초당 40회 요청, 둘 중 하나를 초과하면 SDK 백오프와 함께 429)가 게시되어 있고 대기자 명단 관련 표현은 전혀 없습니다. 그리고 2026-09-24부터는 OrcaRouter를 통해서도 이용할 수 있습니다.

우리가 제공하는 것이 무엇인지 정확히 밝힐 가치가 있습니다. 호출 형태가 바로 달라지는 부분이기 때문입니다. 카탈로그 항목은 typesafe/jev-1.13이고 이름은 TypeSafe: Jev 1.13이며, 지원되는 엔드포인트 유형은 "systemone"입니다. 따라서 OpenAI chat-completions 형태가 아니라 POST /v1/systemone으로 호출되며, 비스트리밍 방식이고, 텍스트를 입력받아 구조화된 JSON을 출력하며, state와 questions를 합쳐 최대 약 64K 입력 토큰까지 처리합니다. 입력은 백만 토큰당 $0.042이고 출력은 0으로 청구됩니다. 계량할 출력 토큰이 없기 때문입니다. 타입이 지정된 결정은 산문이 아니니까요. 이는 제공자 정가를 그대로 반영한 것으로, 0% 마크업이며, 카탈로그의 다른 200개 이상 모델과 동일한 키로 — 200개 이상 모델을 위한 하나의 API, 0% 마크업(제공자 정가를 그대로 반영하므로 벤더 가격 인하가 같은 날 여기에도 적용됩니다). TypeSafe AI에 대해 읽고 있는 이유가 프로덕션 경로에 적용하기 전에 Jev의 캘리브레이션이 자신의 데이터에서 견디는지 알아보려는 것이라면, 이미 신뢰하는 생성 모델 옆에서 실행해 보는 것이 그것을 알아내는 저렴한 방법입니다; Jev의 신뢰도가 낮게 돌아올 때 그 모델로 페일오버하는 것이 그것을 출시하는 저렴한 방법입니다.

2026-09-30에 종료되는 기간의 자체 7일 서빙 수치로, 벤더의 벤치마크가 아니라 자체 트래픽에서 나온 숫자입니다: p50 151ms, p95 247ms, 초당 약 349 출력 토큰, 오류율 0.49%, 서빙된 토큰 7,620만 개. 해당 기간의 일별 p50은 175, 170, 163, 161, 170, 147, 143ms였으므로 중앙값은 완만하게 낮아지는 추세입니다. 시리즈 중 하루인 09-28은 p95가 2,448ms로, 데이터에서 실제 이상치이며 일반적인 값도 아니고 지연 예산을 계획할 때 기준으로 삼을 숫자도 아닙니다. 이 수치들은 매일 갱신되며, 카드가 출처입니다.

TypeSafe에 따르면 모델이 취약한 부분

공급업체는 Jev 1.13에 대한 들쭉날쭉함(jaggedness) 페이지를 게시하며, 이 페이지는 2026-09-17에 마지막으로 검토되었고, 대부분의 출시 자료보다 실패 모드를 더 솔직하게 명시합니다. 이 모델을 기반으로 구축하기 전에 읽어야 할 바로 그 페이지이며, 그 자체의 목록은 다음과 같습니다. Jev는 당신이 의도한 질문이 아니라 당신이 작성한 질문에 답하므로, 범위 한정어, 부정어, 암시된 조건을 명시해야 합니다. 이것은 계산기가 아닙니다: 수학적 질문에서는 의미론적 질문보다 성능이 더 나쁩니다. 날짜를 순서가 있는 양이 아니라 텍스트로 읽으므로, 순서, 간격, 윈도우 포함 여부는 신뢰할 수 없고, 형식이 혼합된 경우에는 더 나쁩니다. 이중 부정과 다중 홉 우회는 정확도를 떨어뜨립니다. 상태가 관련 없는 세부 정보로 커질수록 정확도가 떨어집니다 — 페이지에서는 이를 두고 "컨텍스트 부패(context rot)를 겪는다"고 말합니다 — 따라서 먼저 코드에서 필터링하는 것이 해결책입니다. 상태는 기본적으로 적대적인 것으로 취급되지 않고 데이터로 취급되므로, 주입된 지시가 답변을 바꿀 수 있습니다. 지시와 기준이 서로 맞지 않으면 모델을 혼란스럽게 합니다. 구조적 불변식은 보장되지 않습니다: noul과 선택 출력이 반드시 대응할 필요는 없고, 질문과 그 부정의 합이 1이 될 필요도 없으므로, 둘 사이에 임계값을 이식해서는 안 됩니다. 그리고 이것은 텍스트 생성용으로 훈련되지 않았습니다 — 연쇄 선택을 통해 억지로 텍스트를 생성하게 하면 "잘 작동하지 않을 것이고 매우 느릴 것입니다."

라우팅 변경 6일차, TypeSafe AI를 어떻게 해석해야 할까

이 회사는 강력하고 구체적이며 반증 가능한 주장을 하고 있다: 좁은 범위의 결정 모델이 문단이 아니라 판단이 필요한 작업의 하위 집합에서 범용 모델보다 더 빠르고, 더 저렴하며, 더 신뢰할 수 있다는 것이다. 그 주장은 그럴듯하고 부분적으로 스스로 입증된다 — 신뢰도 추정치는 실제 설계상의 차이이며, 가격은 실재하고, 우리 자체 트래픽에서 측정한 지연 시간은 공급업체의 것과 같은 수준이다. 빠져 있는 것은 외부인이 나머지를 확인할 수 있게 해 주는 부분이다: 아키텍처도, 매개변수도, 가중치도, 독립적인 벤치마크도 없고, 회사 스스로 지속 가능하다고 입증할 수 없다고 말하는 가격이다. 실패 모드가 문서화되어 있는데, 이는 대부분의 연구소가 하는 것보다 더 많은 것이며 이 모델을 진지하게 받아들여야 할 단 하나의 가장 좋은 이유다.

주목할지 결정하는 중이라면: 이미 레이블을 붙여 둔 입력에 레이블은 숨긴 채 Jev를 실행하고, 그 신뢰도 수치가 Jev가 맞히는 사례와 틀리는 사례를 구분하는지 살펴보라. 그 테스트는 입력 토큰 100만 개당 $0.042로 거의 비용이 들지 않으며, 당신이 실제로 가진 질문에 답하는 유일한 테스트다. 그 회사를 신뢰할지 결정하는 중이라면: 공개된 정보는 있는 그대로이고, 솔직한 답은 현재의 증거가 공급업체의 말과 당신이 스스로 생성하는 것뿐이라는 것이다.