AI에게 말을 시키지 말고,
판단만 시켜라
TypeSafe AI가 공개한 System One Model과 첫 모델 Jev. "LLM을 대체하는 새 AI"라기보다, AI를 소프트웨어에 넣는 방법을 아예 다르게 보자는 제안이다. 생성의 시대에서 판단의 시대로 — 이 문서를 뜯어본다.
2026년 9월 15일, TypeSafe AI가 System One Model이라는 새로운 모델 클래스와 첫 모델 Jev를 공개했습니다. 핵심은 한 문장으로 줄일 수 있습니다. AI에게 글을 쓰게 하지 말고, 판단만 시키자. ChatGPT·Claude·Gemini류가 문장을 생성하는 모델이라면, Jev는 문장을 만들지 않습니다. 미리 정해 놓은 선택지에 대해 판단과 확률만 돌려줍니다. TypeSafe는 이것을 "unstructured state in, typed probabilistic decisions out" — 복잡한 상황을 넣으면 프로그램이 바로 쓸 수 있는 정형화된 확률적 판단이 나온다고 설명합니다.
01 / 문제프로그램은 문장이 아니라 값이 필요하다
ChatGPT에게 민원 하나를 주고 이렇게 물었다고 해보겠습니다.
ChatGPT가 대답합니다. "이 민원은 도로 파손과 관련된 내용이므로 도로관리과에서 처리하는 것이 적절해 보입니다." 사람에게는 아주 좋은 답입니다. 그런데 프로그램 입장에서는 귀찮습니다. 프로그램은 여기서 도로관리과라는 값 하나만 필요합니다. 그런데 AI가 "판단하기 어려우나 도로관리과 또는 안전총괄과가 적절해 보입니다"라고 하면? "도로관리과입니다. 다만…"이라고 하면? 결국 개발자는 이 과정을 다시 거쳐야 합니다.
- LLM 답변 받기
- JSON 변환
- 형식 검사
- 오류 검사
- 재시도
- 그제야 프로그램 실행
이것이 현재 AI Agent에서 상당히 흔한 구조입니다. TypeSafe가 던지는 문제의식은 여기서 날카로워집니다. "어차피 컴퓨터가 사용할 건데, 왜 인간의 언어를 중간에 만들지?"
02 / 방식Jev는 처음부터 선택지를 정한다
Jev는 아예 다르게 갑니다. 먼저 선택지를 정합니다. 민원 담당 부서라면 도로관리과·교통행정과·환경과·복지과·기타. 그리고 민원을 던지면, 글을 쓰는 것이 아니라 이런 개념의 결과를 줍니다.
도로관리과 91% 교통행정과 5% 환경과 2% 복지과 1% 기타 1%
끝입니다. 설명도 안 합니다. 문장도 안 씁니다. TypeSafe의 공식 API도 이 철학으로 설계되어 있고, 현재 세 가지 기본 질문 유형을 제공합니다.
그리고 모든 결과에 확률 또는 confidence가 붙습니다. 여기서 중요한 사용 패턴이 하나 나옵니다. 하나의 거대한 질문을 던지는 게 아니라, 작은 판단 여러 개로 분해해서 동시에 묻는 것입니다. 민원 하나를 놓고 이렇게 병렬로 묻습니다.
담당부서 = 교통과 0.94 (Choice) 긴급도 = 4/5 0.87 (Score) 개인정보 = TRUE 0.98 (Noul) 악성민원 = FALSE 0.91 (Noul) 법률검토 = TRUE 0.72 (Noul) 기관장보고 = FALSE 0.89 (Noul)
그러면 나머지는 일반 코드가 처리합니다. TypeSafe 문서도 스타트업을 한 번에 평가하지 말고 시장성·기술가능성·차별성을 각각 판단시킨 뒤 코드에서 점수를 합치라고 권합니다. TypeSafe 자신들은 이 방식을 "smart if-statements", 똑똑한 IF문이라고 부릅니다. 이 표현이 이 기술의 본질을 굉장히 잘 보여줍니다.
기존 LLM 경로와 System One 경로 — 점선 구간이 통째로 사라지는 것이 핵심이다.
03 / 신뢰Confidence — 틀리면서 당당한 AI를 다루는 법
지금 LLM의 심각한 문제 중 하나가 틀리면서도 당당하다는 것입니다. GPT가 "이건 교통과입니다"라고 하면, 프로그램 입장에서는 이것이 50% 확신인지 99% 확신인지 알기 어렵습니다.
Jev의 철학은 다릅니다. "교통과 52%"라고 나오면 담당 공무원에게 넘기고, "교통과 99.2%"라면 자동 분류하면 됩니다.
IF confidence >= 0.90 → 자동 처리 IF 0.70 ~ 0.90 → 2차 검토 IF < 0.70 → 담당자에게 전달
그래서 TypeSafe는 학습법의 이름부터 RLCD — Reinforcement Learning for Calibrated Decisions라고 붙였습니다. 핵심 목표가 단순히 정답률을 올리는 게 아니라, 80%라고 말한 판단들이 실제로 약 80% 정도 맞도록 만드는 것입니다. 자동화에서는 이것이 정답률만큼 중요합니다. 확률을 믿을 수 있어야 그 확률로 분기할 수 있기 때문입니다.
04 / 주의"Hallucination이 없다"는 말의 정확한 뜻
발표문에는 Jev가 hallucination을 하지 않는다는 표현이 나옵니다. 이 부분은 주의해서 읽어야 합니다. Jev도 판단을 틀릴 수 있습니다. 실제 담당 부서는 복지과인데 "환경과 87%"라고 판단할 수 있습니다. 그건 여전히 오류입니다.
Jev가 하지 않는 것은 이런 것입니다. 선택지가 복지과·환경과·교통과 세 개뿐인데 갑자기 "미래전략AI혁신행정국"이라는 존재하지 않는 부서를 만들어내는 것. 이것을 구조적으로 불가능하게 만든 겁니다. TypeSafe는 이를 type error가 0%라고, 수학적으로 불가능하다고 주장합니다.
05 / 성능왜 빠르고 왜 싼가
LLM은 "오늘 → 오늘 날 → 오늘 날씨 → 오늘 날씨는 맑습니다"처럼 토큰을 하나씩 순서대로 생성합니다(autoregressive generation). 문장이 길어질수록 계산이 계속됩니다. 반면 Jev는 애초에 문장을 만들지 않고, 질문 여러 개의 확률을 병렬로 계산합니다.
그래서 회사 측 측정으로 응답 시간이 약 70~500ms이고, System One 형태의 작업에서 기존 frontier LLM(3~329초)보다 40~200배 빠를 수 있다고 주장합니다. 비용도 같은 이유입니다. LLM 비용의 큰 부분이 출력 토큰 생성인데 Jev는 긴 문장을 만들지 않으니, 현재 가격은 입력 100만 토큰당 $0.042에 출력은 과금하지 않는 형태입니다.
회사가 자체 워크플로 벤치마크에서 주장하는 최고 수준의 차이는 193.6배 빠름, 444.6배 저렴함입니다. 다만 이 숫자는 매우 주의해서 봐야 합니다. TypeSafe 스스로 이것이 실제 이익의 상단선이라고 명시하고 있고, 평가 워크플로를 자체 팀이 만들었기 때문에 편향 가능성도 있습니다. "GPT보다 444배 좋은 모델"이라는 뜻이 절대 아닙니다.
06 / 구조하네스 관점 — AI를 지배자가 아니라 부품으로
제가 보기에 이번 발표에서 제일 중요한 부분은 속도도 가격도 아니고 이 구조입니다. 기존 Agent는 흔히 LLM에게 생각·판단·실행을 모두 맡기는, LLM에게 너무 많은 자유를 주는 구조로 갑니다. System One 철학은 반대입니다. AI가 시스템을 지배하는 것이 아니라, 시스템 안에 AI 판단기를 집어넣는 것입니다.
LLM은 생각하고, Jev는 판단하고, 코드는 실행한다 — 하네스가 전체 흐름을 통제한다.
즉 LLM 중심 설계에서 Workflow 중심 설계로 이동하는 것입니다. 지난 글 "LLM은 아무것도 못한다"에서 에이전트를 LLM(뇌) + 도구(손발) + 반복 루프로 정리했는데, System One은 그 옆에 다른 계보를 하나 더 세웁니다. AI에게 전체를 맡기는 것이 아니라, 사람이 설계한 워크플로우 안에서 판단이 필요한 구간만 AI에게 맡기는 구조입니다. 공공·기업 업무에서 통제 가능성과 책임성을 높이기 좋은 방향입니다.
System One이라는 이름도 여기서 나옵니다. Daniel Kahneman의 『Thinking, Fast and Slow』에서 System 1은 빠르고 즉각적인 판단, System 2는 느리고 깊은 사고입니다. 지금의 Reasoning 모델들이 System 2를 지향한다면, Jev는 System 1을 노립니다. 회사도 이름의 출처를 명시적으로 Kahneman에서 가져왔다고 밝힙니다.
07 / 시장이것이 노리는 곳은 챗봇 시장이 아니다
사람과 ChatGPT가 대화할 때는 2초냐 5초냐가 큰 문제가 아닙니다. 그런데 백엔드에서 1,000만 건을 처리한다면 100ms와 10초는 시스템 설계 자체가 달라집니다. 그래서 TypeSafe가 노리는 시장은 챗봇이 아니라, 엄청나게 많은 작은 판단이 계속 일어나는 곳입니다.
- 금융 사기판단 · 거래 승인
- 보안 이벤트 판정
- 민원 분류 · 문서 라우팅
- 광고 판단 · 상품 추천 · 고객 이탈 판단
- Agent 결과 검증 · 콘텐츠 moderation
공식 워크플로 평가도 보안 사고 처리, Agent trace 감시, invoice 처리, 고객 서비스 같은 생산 환경을 대상으로 하고 있습니다.
08 / 실습지금 바로 써볼 수 있는 네 가지 경로
흥미로운 것은 생태계에 붙는 속도입니다. TypeSafe 본가 API는 Waitlist 승인제이지만, 이미 세 곳의 플랫폼에서 바로 써볼 수 있습니다.
env.AI.run()으로 호출. D1·KV·R2와 바로 결합돼 업무자동화 PoC에 적합typesafe/jevevaluate() 계열로 사용. 이름부터 generate가 아니라 evaluate다typesafe-ai/jevCloudflare 문서의 실제 호출 형태는 이렇습니다.
const r = await env.AI.run("typesafe/jev", {
state: "로그인이 안 되고 비밀번호 메일도 안 옵니다.",
questions: { team: {
type: "choice", instructions: "담당팀은?",
criteria: { account: "계정", billing: "결제", tech: "기술" }
}}
});
// → account 0.97 ...
한 가지 함정이 있습니다. Jev는 챗 모델이 아니라서, 기존처럼 chat/completions로 호출하면 안 되고 각 플랫폼의 판단(decisions/evaluate) 계열 API를 써야 합니다. GPT는 chat/completions, Jev는 decisions — API 이름부터 철학이 다릅니다. 모델 ID와 API 사양은 바뀔 수 있으니 실습 전에 각 서비스의 최신 공식 문서를 확인하는 것이 안전합니다.
09 / 판단그래서, 엄청난 패러다임인가
아이디어 자체는 굉장히 중요합니다. 다만 지금 당장 "LLM 시대가 끝났다"고 볼 단계는 아닙니다. 정확히 표현하면 이렇습니다. 2022~2024년의 AI는 Chat이었습니다(사람 ↔ LLM). 2024~2026년의 AI는 Agent입니다(LLM ↔ 도구·컴퓨터). 그리고 다음에 등장할 가능성이 있는 구조는 AI = Software Primitive입니다. AI가 더 이상 화면에서 사람과 이야기하는 특별한 존재가 아니라, if문·함수·API·데이터베이스처럼 프로그램 안에 박혀 있는 하나의 기본 부품이 되는 것입니다. TypeSafe가 Choice·Score·Noul을 AI primitives라고 부르는 이유도 이것입니다.
이 관점에서 보면 진짜 패러다임은 Jev라는 모델 하나가 아니라 이 이동입니다. AI의 중심이 생성(Generation)에서 판단(Decision)으로 확장되고, Prompt 중심에서 Workflow 중심으로, LLM 중심에서 하네스 중심으로, "AI가 알아서 한다"에서 "코드가 통제하고 AI는 판단한다"로 옮겨갑니다.
LLM은 AI를 사람에게 연결했다.
Agent는 AI를 도구에 연결했다.
System One은 AI를 코드 자체에 넣으려 한다.
ChatGPT는 "무엇을 해야 할지 말해드립니다"였고, Agent는 "제가 도구를 써서 해보겠습니다"입니다. Jev는 이렇게 말합니다. "판단만 하겠습니다. 실행은 프로그램이 하십시오." 이것이 이 문서에서 말하는 가장 본질적인 변화입니다.
원문: TypeSafe AI, Introducing System One Models and Jev (2026. 9. 15)