Jev, 토큰 대신 확률적 결정을 내놓는 새로운 형태의 System One 모델 (feat. TypeSafe AI)

9bow · 9월 16, 2026, 10:30오후

TypeSafe AI, System One 모델과 Jev 소개

지난 몇 년간 언어 모델은 채팅에서는 이미 인간을 능가하는 수준에 도달했습니다. 그런데도 정작 소프트웨어 안에서 자동으로 돌아가는 판단, 그러니까 이 거래를 승인할지, 이 알림을 어떤 등급으로 분류할지, 이 요청을 어느 파이프라인으로 보낼지 같은 결정은 여전히 사람이 붙어서 감독해야 하는 경우가 많습니다. TypeSafe AI의 창업자 Diogo Almeida는 이 간극을 지난 4년간 붙잡고 있던 질문이라고 말합니다. 그는 OpenAI에서 언어 모델이 지시를 잘 따르고 사람과 자연스럽게 대화하도록 만드는 방법을 연구했고, 그 결과물이 ChatGPT의 기반이 된 인간 피드백 기반 강화학습(Reinforcement Learning from Human Feedback, RLHF) 이었습니다. 하지만 채팅 모델이 자동화의 정답은 아니라는 확신이 점점 커졌고, 2년의 비공개 개발 기간을 거쳐 TypeSafe AI는 오늘 첫 번째 System One 모델을 공개했습니다.

System One 모델은 소프트웨어가 직접 소비할 수 있는 빠르고 구조화된 결정을 내리도록 만들어진 새로운 모델 부류입니다. 그 첫 공개 모델의 이름은 Jev 이며, 오늘부터 얼리 액세스로 제공됩니다. Jev는 기존 LLM과 비슷한 수준의 지능을 System One 과제에서 보여주면서도, 속도와 효율은 두 자릿수 배 이상 앞선다고 TypeSafe는 주장합니다. 다만 Jev는 문자열을 생성하지 않는 대신 구조화된 출력에 특화되어 있고, TypeSafe의 표현을 빌리면 태생적으로 환각(hallucination) 을 일으킬 수 없습니다. 이 모델을 이해하는 가장 쉬운 비유는 프런티어급 지능을 가진 함수 호출입니다. 비정형 상태를 입력하면, 타입이 정해진 확률적 결정이 출력으로 나옵니다.

이런 접근이 낯설게 느껴진다면, 그동안 우리가 구조화된 출력(structured output) 이나 함수 호출 기능으로 이 문제를 우회해 왔다는 점을 떠올리면 됩니다. Anthropic이 Claude의 구조화된 출력 기능을 공개 베타로 내놓은 사례처럼, 업계는 대체로 텍스트 생성 모델에 스키마를 강제한 뒤 결과를 파싱하고 검증하는 식으로 대응해 왔습니다. TypeSafe의 주장은 이것이 임시방편에 가깝다는 것입니다. 텍스트를 생성하도록 학습된 모델에 구조를 억지로 씌우는 대신, 처음부터 결정과 확률을 내놓도록 학습 목표 자체를 바꾸면 더 빠르고 더 신뢰할 수 있는 시스템을 만들 수 있다는 것이 이 회사의 핵심 베팅입니다.

왜 새로운 모델 클래스가 필요했는가: RLHF에서 RLCD까지

TypeSafe는 이 결정을 TypeSafe AI 문서의 AI 기초 원리 페이지에서 비교적 자세히 설명합니다. 사전 학습된 언어 모델은 지금까지 크게 두 가지 방식으로 후처리 학습되어 왔고, TypeSafe는 여기에 세 번째 축을 더했다고 말합니다.

첫 번째는 앞서 언급한 RLHF 입니다. 사람이 선호하는 답변을 학습시켜 ChatGPT나 InstructGPT 같은 챗봇을 만든 방법이고, TypeSafe는 이 기법이 Diogo Almeida가 공동 발명에 참여한 방법이라고 소개합니다. 두 번째는 검증 가능한 보상 기반 강화학습(Reinforcement Learning with Verifiable Rewards, RLVR) 으로, 수학 증명이나 코드 최적화처럼 정답을 프로그램적으로 채점할 수 있는 과제에서 강한 추론(reasoning) 모델을 만들어 냈습니다. 그리고 TypeSafe가 새로 제시하는 세 번째 축이 보정된 결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions, RLCD) 입니다. 이 방법은 텍스트를 생성하는 대신 결정과 확률을 직접 내놓도록 모델을 학습시키며, 더 높은 확률이 실제로 더 높은 정답률과 일치하도록, 즉 보정(calibration) 되도록 최적화합니다.

TypeSafe가 RLHF를 문제 삼는 지점은 단순히 사람을 기쁘게 하려다 아첨하게 된다는 익숙한 비판을 넘어섭니다. 그들은 RLHF가 구조적으로 모드 드로핑(mode dropping) 을 유발한다고 지적합니다. 기본 모델이 여러 그럴듯한 답변 후보를 가지고 있더라도, 보상 모델이 선호하는 하나의 응답 방식만 남기고 나머지 확률 질량을 깎아내는 현상입니다.

이는 GAN(Generative Adversarial Network)에서 생성자가 판별자를 속이는 한 가지 출력만 반복해서 내놓는 극단적 실패 사례인 모드 붕괴(mode collapse) 의 완화된 버전이라고 TypeSafe는 설명합니다. RLHF 자체는 대화형 모델에는 여전히 잘 맞는 방법이지만, 프로덕션 자동화에는 확률적 불확실성을 있는 그대로 다룰 수 있는 다른 학습 목표가 필요하다는 것이 TypeSafe의 입장입니다. 실제로 회사가 공개한 자체 수치에서, 잘 보정된 모델이라면 확률 0.2를 부여한 사건은 실제로 약 20%의 빈도로, 확률 0.8을 부여한 사건은 약 80%의 빈도로 일어나야 합니다. 이 비율은 개별 답 하나의 정오를 보장하지는 않지만, 여러 예측을 모아 보면 소프트웨어가 언제 자동으로 행동하고 언제 사람에게 넘겨야 할지를 판단하는 근거가 됩니다.

텍스트 생성 대신 확률적 결정: 기존 LLM과 System One의 차이

원문 블로그는 기존 LLM과 System One 및 Jev의 차이를 아래와 같은 표로 정리합니다. 표에서 보듯, 차이는 단순한 성능 격차가 아니라 입력과 출력의 형태, 샘플링 방식, 비용 구조 전반에 걸쳐 있습니다.

구분	기존 LLM	System One + Jev
학습 방법	RLHF / RLVR	RLCD
최적화 대상	사람이 선호하는 응답, 검증 가능한 보상	보정된 확률의 결정
입력	순차적 메시지 중심의 비정형 데이터	구조화된 프로그램 상태 중심의 비정형 데이터
출력	문자열, 파싱과 검증이 필요	타입이 정해진 구조화된 값과 확률
샘플링	순차적, 토큰을 하나씩 생성	병렬적, 한 번의 쿼리로 모든 답 생성
입력 토큰 비용	100만 토큰당 0.20달러에서 10달러	100만 토큰당 0.042달러
출력 토큰 비용	입력의 약 5배	사실상 무료
응답 속도	프런티어 모델 기준 3초에서 329초	70밀리초에서 500밀리초
신뢰도 표현	확신 요청 시에도 과신, 비일관적인 경향	모든 출력에 보정된 확신도 동반

이 표에서 가장 눈여겨볼 대목은 샘플링 행입니다. LLM은 다음 토큰이 이전 토큰에 조건부로 이어지는 순차적 생성 방식이라, 답이 길어질수록 지연이 커집니다. 반면 Jev는 여러 개의 질문을 병렬 샘플러로 한 번에 처리하기 때문에, 질문 개수를 늘려도 응답 시간이 거의 늘지 않습니다. TypeSafe는 이를 실제 쿼리 예시로 공개하며, 같은 입력에 대해 Jev와 비교 대상 LLM이 어떻게 다르게 응답하는지 나란히 보여줍니다. 다만 TypeSafe 스스로도 이 데모의 입력이 사람이 읽기 좋도록 짧고 단순화되어 있어 자사 모델에 유리하게 작용할 수 있다는 점, 그리고 녹화된 예시에서 유일하게 의견이 갈린 항목("이탈 가능성 등급")은 정답 자체가 모호했다는 점을 스스로 밝혀 두었습니다. 비교 대상으로는 지능 수준이 Jev와 가장 근접하다고 판단한 OpenAI의 GPT-5.6 Terra를 기본 추론 설정으로 사용했습니다.

Jev를 구성하는 세 가지 AI 기본 요소: Choice, Score, Noul

TypeSafe 문서는 Jev가 노출하는 API를 소프트웨어 원시 자료형에 비유해 세 가지 AI 기본 요소(AI primitive) 로 설명합니다. 모듈적이고 구조적이며 빠르다는 점에서 소프트웨어의 원시 자료형과 비슷하고, 각각은 서로 다른 형태의 질문(question) 을 던져 서로 다른 형태의 답을 돌려줍니다.

기본 요소	목적	반환값
Choice	목록에서 하나의 선택지를 고른다	선택값, 확률 분포, 확신도
Score	정해진 기준으로 상태를 채점한다	점수, 확률 분포, 확신도
Noul	이 진술이 참인지 판정한다	0에서 1 사이의 값

이 세 가지 질문 유형은 한 번의 API 호출 안에서 자유롭게 섞을 수 있습니다. 모든 질문은 동일한 상태(state) 를 놓고 병렬로, 그리고 서로 독립적으로 평가됩니다. 질문을 추가해도 응답 시간은 거의 늘어나지 않고, 각 질문이 독립적으로 평가되기 때문에 질문을 많이 넣는다고 해서 문맥이 오염되는 이른바 컨텍스트 로트(context rot) 문제도 생기지 않는다고 TypeSafe는 설명합니다.

TypeSafe가 강조하는 또 다른 설계 원칙은 한 번에 하나씩, 원자적인 질문입니다. System One 모델은 각 질문이 하나의 구체적이고 범위가 좁은 사안을 물을 때 가장 잘 동작합니다. 숙련된 사람이라면 몇 초 안에 판단할 수 있는 수준의 직관적 결정이라고 생각하면 됩니다. 만약 물으려는 질문이 여러 독립적 요인을 동시에 저울질해야 하거나 긴 추론을 필요로 한다면, 그 질문을 더 작은 요인들로 쪼개서 각각을 별도 질문으로 던지고 코드에서 로직으로 결합하라고 권합니다. 예를 들어 이 스타트업의 피칭을 평가하라 같은 하나의 뭉뚱그려진 질문 대신, 시장 규모와 기술적 실현 가능성과 차별성을 각각 따로 물은 뒤 자체 공식으로 점수를 합산하는 식입니다. 이렇게 하면 우선순위가 바뀔 때 프롬프트를 다시 쓰는 대신 코드의 계수 하나만 바꾸면 됩니다. 워크플로우 평가 사이트는 이 원칙을 설명하는 예시로, 영수증을 읽을 수 있는지와 지출 항목의 종류, 75달러 초과 여부를 차례로 따지는 경비 청구서 심사 정책을 하나의 장난감 예제로 들어, 사람이 적은 정책 문장이 어떻게 Noul과 Choice 질문, 그리고 코드의 조건문으로 쪼개지는지 그림으로 보여줍니다.

병렬 샘플링과 초저지연 응답: Jev가 빠르고 저렴한 이유

Jev의 속도는 세 가지 요소, 즉 새로운 모델 아키텍처, 병렬 샘플러, 그리고 RLCD 학습 방식이 함께 만들어 낸 결과라고 TypeSafe는 설명합니다. 홈페이지에 따르면 Jev의 입력 토큰 가격은 100만 토큰당 0.042달러, 10억 토큰 기준으로는 42달러이며, 이는 Anthropic의 Claude Fable 5.1 입력 가격 대비 238배 낮은 수준이라고 주장합니다. 출력 토큰은 계측하기에도 너무 저렴하다는 표현으로 사실상 무료로 제공됩니다. 다만 TypeSafe 스스로도 이 가격이 보조금 지급 형태로 유지되고 있는지는 스스로도 증명할 수 없으며, 장기적으로 지속 가능한 가격인지는 시간이 지나야 알 수 있다고 인정합니다. 다만 가격이 오르지는 않고 내려갈 것으로 예상한다는 입장입니다.

속도 면에서 Jev의 종단 간 응답 시간은 70밀리초에서 500밀리초 사이로, 회사는 이를 사람과 대화하기에는 충분히 빠르지만 코드에 통합하기에는 큰 병목이 되는 기존 프런티어 모델의 3초에서 329초 응답 시간과 대비합니다. TypeSafe는 이 속도 덕분에 UX가 중요한 실시간 애플리케이션에도 AI를 끼워 넣을 수 있고, 페타바이트 단위 데이터를 피처와 인사이트로 바꾸는 맵리듀스형 워크로드에도 적합하다고 설명합니다. 실제 사용 사례로는 사람의 감독이 필요한 챗봇이나 코딩 에이전트보다는, 미리 정해진 규칙이 다루기에는 너무 복잡한 판단을 대신하는 AI 기반 워크플로우, 다시 말해 분류하고 라우팅하고 채점하고 추출하는 퍼지(fuzzy)한 if문 역할을 꼽습니다.

워크플로우 평가로 증명한 성능: 정확도 대비 비용의 파레토 프런티어

TypeSafe는 자사 벤치마크가 하네스나 모델이 정답 라벨에 맞춰 과적합할 여지를 남기는 기존 방식 대신, 코드가 옳다고 가정하고 가장 똑똑한 외부 모델들의 예측 평균을 기준 확률로 삼는 평가 방식을 만들었다고 설명합니다. 워크플로우 평가 사이트에 공개된 기준 답안은 OpenAI의 GPT-6 Astra와 Anthropic의 Fable 5.1이 둘 다 최고 추론 강도로 답한 결과의 평균이며, 나머지 비교 모델은 모두 각 제공사의 기본 추론 설정으로 평가되었습니다. 공개된 워크플로우는 보안 경보를 심사하는 Security Incidents, 에이전트의 도구 호출 기록을 검토하는 Agent Trace Observability, 거래명세서를 대사하는 Invoice Processing, 고객 문의에 응대하는 Customer Service 네 가지이며, 사이트는 각 워크플로우의 전체 쿼리와 모델 간 불일치 사례까지 그대로 공개해 두었습니다.

차트가 보여주듯 Jev는 네 워크플로우 평균 정확도 67.8%를 케이스당 0.0004달러, 0.4초 만에 달성하며 정확도 대비 비용과 시간 두 축 모두에서 거의 두 자릿수에 가까운 구간의 파레토 프런티어(Pareto frontier) 를 독차지합니다. 다만 이 수치를 정직하게 읽으면 Jev가 언제나 가장 정확한 것은 아닙니다. 예컨대 Invoice Processing 워크플로우에서 Jev의 정확도는 61.8%로, 같은 워크플로우에서 79.1%를 기록한 OpenAI의 sol보다 17.3%p 낮습니다. 대신 비용은 건당 0.0011달러 대 0.2152달러로 약 200배, 응답 시간은 0.5초 대 34.3초로 60배 이상 차이가 납니다. 즉 Jev의 강점은 가장 정확한 답을 내놓는 것이 아니라, 충분히 쓸 만한 정확도를 거의 공짜에 가까운 비용과 즉각적인 속도로 내놓는 쪽에 가깝습니다. 한편 평가 사이트는 워크플로우 구조 자체의 효과도 함께 보여주는데, 하나의 프롬프트에 모든 판단을 맡기는 방식과 비교했을 때 거의 모든 모델이 문제를 여러 질문으로 쪼갠 워크플로우로 풀 때 더 정확하고 더 저렴하고 더 빨라졌다고 밝힙니다. 이는 자사 모델뿐 아니라 경쟁 LLM에도 함께 나타난 효과라, 질문을 원자적으로 쪼개 코드로 결합하라는 TypeSafe의 설계 원칙 자체를 뒷받침하는 결과이기도 합니다. 아래는 블로그가 4개 워크플로우 중 가장 단순하다고 소개한 Security Incidents의 실제 구조입니다. 경보와 자산, 티켓 세 곳의 정보를 세 가지 질문으로 훑어 승인, 대기, 조치 중 하나를 정하고, 다시 열한 개의 세부 질문으로 침해 사고의 현재 상태를 확인한 뒤, 코드가 미리 정의해 둔 대응 그룹 중 조건을 만족하는 가장 강한 조치를 순서대로 골라 실행합니다. 조건에 맞는 그룹이 하나도 없으면 곧바로 긴급 에스컬레이션으로 넘어갑니다.

TypeSafe는 홈페이지에서 내세우는 193.6배 빠르고 444.6배 저렴하다는 수치가 바로 이 워크플로우 평가에서 나온 것이며, 이는 실제 환경에서 기대할 수 있는 개선폭 중에서도 높은 편에 속할 것이라고 스스로 인정합니다. 또한 이 워크플로우들은 자사 모델 역량 팀 소속 인원이 직접 만든 것이라 어느 정도의 편향이 존재할 수 있고, 기준 확률로 OpenAI와 Anthropic 모델의 평균을 사용했기 때문에 자사 모델과 DeepSeek 계열 모델의 상대적 성능은 과소평가되었을 가능성이 있다고 밝힙니다. 비교 대상 LLM들은 System One LLM 래퍼(wrapper)를 통해 TypeSafe API와 호환되는 구조화된 결정을 내놓도록 강제했는데, 이 방식이 LLM에서 결정을 산출하는 가장 정확한 방법이긴 하지만 확률 없이 답만 내놓게 하는 것보다는 느리고 비싸다는 점도 함께 밝혔습니다. 스타트업이 자체 벤치마크를 공개할 때 흔히 생략하는 이런 한계를 원문이 먼저 짚어 둔 점은, 수치를 그대로 받아들이기보다 원문의 "Nuance" 절과 평가 사이트의 세부 쿼리를 직접 확인해 볼 가치가 있다는 뜻이기도 합니다.

환각 없는 소프트웨어 연동: 타입 안전성이 만드는 신뢰

TypeSafe가 반복해서 강조하는 지점은 환각(hallucination) 과 타입 안전성(type safety) 이 사실상 같은 문제의 양면이라는 것입니다. 에이전트가 도구를 잘못 호출하는 정도는 불편한 수준에 그치지만, 지연 시간 보장이 걸린 시스템이나 여러 계층 깊이 묻혀 있는 의존성 체인 안에서 같은 일이 벌어지면 그 자체로 시스템 장애가 됩니다.

왼쪽 차트의 구조화된 출력 오류율과 오른쪽 차트의 도구 호출 오류율 모두에서 Jev는 0%를 기록한 반면, 비교 대상 LLM들은 구조화된 출력에서 최대 45.5%(haiku 4.5), 도구 호출에서 최대 17.0%(sol)까지 오류율이 치솟았습니다. TypeSafe는 이 LLM 쪽 수치가 OpenRouter에서 수집되었기 때문에 더 복잡한 질의가 더 뛰어난 모델로 라우팅되었을 편향이 있을 수 있다고 밝혔고, 반대로 자사 수치는 경험적으로 측정한 것이 아니라 스키마 일치가 구조적으로 보장되기 때문에 0%를 자신 있게 그릴 수 있었다고 설명합니다. 즉 아무리 똑똑해도 기존 모델은 환각과 타입 오류에서 자유롭지 않다는 주장의 근거는, Jev가 애초에 스키마를 벗어난 답을 표현할 수 없는 출력 공간을 갖도록 설계되었다는 점에 있습니다.

실전 데모로 보는 활용 사례: Doom, 위키레이싱, 스마트홈 어시스턴트

TypeSafe 팀이 가장 신나 한다고 밝힌 대목은 새로운 활용 사례를 여는 부분입니다. 블로그에서 소개한 두 가지 데모는 다음과 같습니다.

Doom 플레이: 텍스트로 표현된 게임 상태를 초당 10회 넘게 질의하며 실시간으로 반응하는 봇을 만들었습니다. 초당 10회 질의는 시간당 약 7달러의 비용으로 계산되는데, 이 수치를 걱정한 담당 엔지니어와 달리 나머지 팀원들은 오히려 예상보다 저렴하다는 반응을 보였다고 합니다. 다만 이 데모는 이미지가 아니라 게임 상태를 나타내는 데이터 구조를 입력으로 사용했고, AI를 배제한 봇이라면 더 잘 플레이할 수 있었겠지만 다양한 게임 상태 표현에 반응하며 지시를 그대로 따르는 봇을 만들고 싶었다는 설명도 함께 제공됩니다.

위키레이싱: 위키백과의 한 문서에서 시작해 오직 문서 안의 링크만 타고 넘어가며 목표 문서에 도달하는 게임입니다. 매 단계마다 수백에서 수천 개의 링크 중 하나를 골라야 하기 때문에, 단순히 초당 처리 속도뿐 아니라 카디널리티가 높은 선택지에서 환각 없이 고르는 능력의 누적 효과를 보여주는 좋은 실험대라고 TypeSafe는 설명합니다. Jev는 최대 255개의 선택지를 지원하며, 더 많은 선택지에서는 먼저 독립적으로 점수를 매긴 뒤 명시적으로 하나를 고르는 2단계 방식을 사용해 약간의 지연이 발생한다고 밝혔습니다.

세 번째 사례는 블로그 발행과 함께 공개된 스마트홈 어시스턴트 데모입니다. 이 데모의 핵심 설계 패턴은 투기적 팬아웃(speculative fan-out) 입니다. 집 안의 모든 조명을 꺼줘라는 사용자 요청이 들어오면, 실제로는 이 요청의 카테고리는 무엇인가, 어느 영역을 대상으로 하는가, 어떤 종류의 기기를 대상으로 하는가, 조명에 대해 어떤 동작을 취해야 하는가라는 네 가지 질문 중 마지막 질문은 요청이 조명을 대상으로 한다는 사실이 확정되기도 전에 미리 물어봅니다. 이렇게 관련성이 확정되기 전에 질문을 미리 던져 두고, 이후 코드가 관련 없는 결과를 걸러내는 방식이 투기적 팬아웃 패턴입니다. 질문을 필요할 때만 순차적으로 나누어 호출하는 올바르게 보이는 방식보다, 모든 질문을 한 번의 API 호출로 묶어 처리하는 편이 훨씬 빠르고 저렴하다는 것이 TypeSafe의 설명입니다.

이 데모는 동시에 TypeSafe가 LLM과 어떻게 짝을 이루는지도 보여줍니다. 사용자 요청이 여러 개의 독립된 동작을 한 문장에 담고 있는지 판별하는 Noul 질문이 참으로 나오면, 그 문장을 원자적인 명령 목록으로 쪼개는 역할은 다시 LLM에게 맡깁니다. 또한 TypeSafe가 일반적인 대화나 정보 요청이라고 판단하면, 자유 형식 응답을 생성하는 역할도 대화형 LLM에게 넘깁니다. TypeSafe의 초기 응답이 워낙 빠르기 때문에, 이 판단 자체가 전체 시스템의 지연 시간에 거의 영향을 주지 않는다는 것이 핵심입니다. 결정론적으로 처리할 수 있는 요청은 빠르고 저렴하게 처리하면서, 생성형 LLM이 제공하는 유연함도 필요할 때 그대로 활용하는 구조입니다.

이름의 유래: 시스템 1, 그리고 제번스

TypeSafe는 자주 묻는 질문에서 두 가지 이름의 유래를 직접 밝혔습니다. System One 모델이라는 이름은 대니얼 카너먼의 저서 Thinking, Fast and Slow에서 말하는 빠르고 직관적인 시스템 1(System 1) 사고와, 느리고 심사숙고하는 시스템 2(System 2) 사고의 구분에서 따왔습니다. 시스템 1 사고는 통상 오류에 취약하다는 뉘앙스를 갖지만, TypeSafe는 훈련 방식만 제대로 갖춘다면 System One 모델이 오히려 그 대안들보다 더 신뢰할 수 있게 만들 수 있다고 주장합니다.

모델 이름 Jev는 윌리엄 스탠리 제번스(William Stanley Jevons)에서 따왔습니다. 증기기관의 효율이 오히려 석탄 수요를 늘렸다는 제번스의 역설(Jevons paradox) 처럼, 지능의 비용이 한 자릿수 낮아질 때마다 그만큼 더 많은 활용 사례가 열릴 것이라는 기대를 담은 이름입니다.

가격과 시작하기

Jev는 오늘부터 얼리 액세스로 제공되며, 대기자 명단에 있던 개발자들을 순차적으로 초대하고 있습니다. 입력 토큰은 100만 토큰당 0.042달러, 출력 토큰은 사실상 무료로 책정되어 있고, 얼리 액세스 사용자는 TypeSafe 콘솔의 플레이그라운드에서 직접 쿼리를 실행해 볼 수 있습니다. 더 깊이 있는 학습을 원한다면 퀵스타트 가이드, 기본 요소 문서, 확신도 다루는 법, 자주 쓰이는 설계 패턴 모음을 차례로 살펴보는 것을 추천합니다. LLM과 함께 Jev를 사용하고 싶다면 공개된 System One LLM 어댑터로 시작할 수 있습니다.

시사점: 소프트웨어 안에 심는 확률적 판단

Jev를 관통하는 메시지는 결국 모든 판단을 텍스트 생성으로 환원하지 말라는 것입니다. 지난 몇 년간 우리는 함수 호출, JSON 모드, 구조화된 출력, 프롬프트로 짜낸 분류기처럼 LLM에 소프트웨어스러운 계약을 억지로 씌우는 방법들을 계속 쌓아 왔습니다. TypeSafe의 제안은 그 계약을 프롬프트가 아니라 학습 목표 단계에서부터 만족시키자는 것이고, 그 결과로 나온 것이 확률과 확신도를 동반한 타입 안전한 값입니다. 이는 개발자 입장에서 보면 파싱과 재시도, 스키마 검증 코드를 제거하고 그 자리에 임계값 기반의 분기 로직을 놓을 수 있다는 뜻이기도 합니다.

물론 신생 기업이 자체적으로 설계하고 자체적으로 측정한 벤치마크라는 점은 감안하고 읽어야 합니다. TypeSafe 스스로도 가격의 지속 가능성이나 평가 편향에 대한 한계를 원문 곳곳에서 인정하고 있고, 소프트웨어 개발자 입장에서는 자신의 실제 워크플로우에 대입해 직접 검증해 보기 전까지는 판단을 유보하는 편이 안전합니다. 다만 채팅이 아닌 자동화를 겨냥한 학습 목표를 처음부터 설계했다는 방향성 자체는, 에이전트와 파이프라인 곳곳에 LLM을 끼워 넣는 지금의 흐름 속에서 눈여겨볼 만한 시도입니다.

Introducing System One Models & Jev 소개 블로그

TypeSafe AI 홈페이지

TypeSafe AI 문서

TypeSafe 워크플로우 평가 사이트

System One LLM 어댑터 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

이 글은 파이토치 한국 사용자 모임이 직접 정리한 글입니다. 새 글을 놓치지 않으시려면 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 알림을 받으시고, 회원으로 가입하시면 주요 글들을 이메일로도 보내드립니다!

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~

9bow · 9월 17, 2026, 6:12오전

BrowserUse에서도 요런 저장소를 공개했네요. 공개가 기대됩니다 +_+