요즘 핫한 TypeSafe AI Jev와 System One 모델
목차
English version: TypeSafe AI’s Jev and the System One Models Everyone’s Talking About
TypeSafe AI가 9월 15일 Jev를 공개했다. 창립자 Diogo Almeida는 OpenAI에서 ChatGPT의 기반이 된 instruction-following 방법론을 만든 사람이고, 4년간 던져온 질문이 이거였다. “모델은 오래전부터 채팅에서 초인적이었는데, 자동화는 다 어디 갔나.” Jev는 이 질문에 대한 답으로 내놓은 새 모델 클래스 “System One 모델”의 첫 공개 모델이다.
기존 LLM이 자동화에는 안 맞는 이유
지금 LLM은 사람과 주고받을 대화, 코드 생성처럼 human-in-the-loop 작업에 맞춰져 있다. 소프트웨어 파이프라인 안에 그대로 박아서 “이 요청을 승인할지”, “이 항목이 어느 카테고리인지” 같은 결정을 대신 시키려면 몇 가지가 걸린다.
- 출력이 문자열이다. 답을 파싱해서 원하는 필드를 뽑아내야 하고, 형식이 어긋나면 파이프라인이 죽는다.
- 느리다. 토큰을 하나씩 순차 생성하니 응답에 3초에서 길게는 5분 넘게 걸린다.
- 비싸다. 입력 토큰과 출력 토큰 모두 과금되고, 자동화는 이 호출을 대량으로 반복한다.
- 신뢰도가 과신 경향이 있다. RLHF는 사람이 선호할 답을 만들도록 훈련하는 것이지, 확률을 정직하게 매기도록 훈련하는 게 아니다.
TypeSafe는 이 네 가지를 묶어서 “채팅에 최적화된 모델을 그대로 자동화에 쓰는 것” 자체가 어긋난 접근이라고 본다.
Jev는 문장이 아니라 타입이 정해진 확률을 반환한다
Jev의 입출력 관계를 회사는 “unstructured state in, typed probabilistic decisions out”(비정형 입력, 타입 안전 확률적 결정 출력)이라고 표현한다. 쓰는 방식은 데이터와, 타입이 미리 정해진 질문 목록을 같이 보내는 것이다. “이 텍스트가 스팸인가”에는 yes/no 확률을, “다음 중 어떤 카테고리인가”에는 정의해 둔 선택지 중 하나를 확률과 함께 돌려준다. 답이 항상 정의한 스키마 안에서 나오기 때문에, 파싱 실패나 형식 불일치로 파이프라인이 죽는 경우가 구조적으로 없다.
이름은 카너먼의 《생각에 관한 생각》에서 가져왔다. 빠르고 직관적인 System 1 사고를, 신뢰할 수 있는 형태로 체계화하겠다는 뜻이다.
기존 LLM과 Jev의 차이
| 구분 | 기존 LLM | Jev |
|---|---|---|
| 훈련 목표 | RLHF(인간 선호) / RLVR(검증 가능한 보상) | RLCD(보정된 결정) |
| 입력 강조 | 순차적 메시지 | 구조화된 프로그램 상태 |
| 출력 | 순차 생성 문자열 | 정의된 옵션에 대한 확률 분포 |
| 샘플링 | 토큰 단위 순차 | 질문 단위 병렬(단일 쿼리) |
| 응답 시간 | 3~329초 | 70~500ms |
| 입력 토큰 비용 | $0.20~$10/M | $0.042/M |
| 출력 토큰 비용 | 입력의 약 5배 | 무료 |
핵심은 두 가지 축이다. 하나는 병렬 샘플러다. 질문마다 순차 생성하는 대신 모든 답을 한 쿼리에서 동시에 뽑아내서 속도를 끌어올린다. 다른 하나는 **RLCD(Reinforcement Learning for Calibrated Decisions)**다. 정답을 맞히는 것과는 별개로, 모델이 90%라고 말한 예측들이 실제로 90%쯤 맞도록 확률 자체를 훈련 목표로 삼는 방식이다. RLHF가 “사람이 좋아할 답”, RLVR이 “프로그램이 검증할 수 있는 답”을 목표로 한다면, RLCD는 “확률이 정직한 답”을 목표로 한다.
실제로 어떻게 쓰이나
회사가 공개한 사례 둘.
- Doom: 게임 상태(텍스트로 구조화된 데이터)를 보고 실시간으로 다음 행동을 결정한다. 초당 10개 쿼리를 던지는 데 시간당 약 7달러.
- Wikiracing: 수백~수천 개 링크 중 최적 경로를 고른다. 선택지가 최대 255개까지 늘어나는 고카디널리티 상황에서도 매 호출이 정의된 선택지 중 하나로 떨어진다.
TypeSafe가 이런 자동화용 워크로드를 위해 새로 짠 스택은 셋이다. 구조화된 결정에 맞춘 모델 아키텍처, 병렬 샘플러, 그리고 RLCD 훈련 방법론. 반대로 사람과의 상호작용이 필요한 챗봇·코파일럿, 수학 증명처럼 검증 가능한 문제, 프로토타입 데모는 여전히 기존 LLM의 영역으로 남겨둔다.
어떤 파이프라인에 맞는 모델인가
이 모델이 맞는 자리는 선택지가 이미 정해져 있는 반복 판정이다. 스팸 필터링, 콘텐츠 모더레이션, 사기 탐지처럼 “어느 카테고리인가”, “위험한가 아닌가”를 대량으로 되풀이해서 묻는 파이프라인이 여기 해당한다. 지금 이런 파이프라인에 LLM을 쓴다면 답을 문자열로 받아 파싱하고, 스키마가 어긋나면 재시도하거나 실패 처리하는 방어 로직이 따라붙는다. Jev가 실제로 회사 주장만큼 나온다면 이 구간에서 얻을 게 분명하다. 파싱 실패가 구조적으로 없어지고, 응답이 초 단위에서 100ms대로 줄고, 판정마다 붙는 확률을 다음 단계(자동 처리로 넘길지, 사람에게 넘길지)를 가르는 기준으로 바로 쓸 수 있다.
반대로 맞지 않는 자리도 분명하다. 선택지 자체가 명확하지 않은 대화형 작업이나, 답이 하나의 정답으로 떨어지지 않는 창작·설명형 작업에는 이 구조가 오히려 제약이 된다. “타입이 정해진 질문을 던질 수 있는가”가 먼저 성립해야 Jev를 고려할 이유가 생긴다.
지금은 얼리 액세스 대기열 단계라 직접 검증은 못 했다. 판단 기준은 간단하다. 지금 자동화 파이프라인이 LLM 응답을 파싱해서 쓰고 있고, 그 파싱 실패나 응답 속도가 실제로 병목이라면 시도해 볼 이유가 있다. 반대로 파싱은 이미 안정적이고 속도도 문제없다면, 이 모델이 해결해 줄 문제가 없다.
남은 질문은 두 가지다. 회사가 공개한 속도·비용 수치가 자유 형식 생성이 아니라 같은 조건의 구조화 출력과 비교해도 유지되는지, 그리고 확률이 “보정됐다”는 주장이 실제 반복 호출에서 그대로 재현되는지. 얼리 액세스가 열리면 이 두 수치부터 직접 찍어 볼 계획이다.
References
- Introducing System One Models & Jev: https://typesafe.ai/blog/introducing-system-one-models-and-jev
- TypeSafe AI: https://typesafe.ai/