결정만 하는 AI: Jev로 만든 214개 프로젝트에서 보이는 패턴

AI가 해야 할 일 중 상당수는 글을 쓰는 게 아니라 "고르는" 일입니다. 정해진 선택지 중 하나와 그 확률만 돌려주는 결정 모델을 쓰면, 분류·선택·채점 같은 판단을 LLM보다 수십 배 빠르고 싸게 돌릴 수 있습니다. 대신 질문을 좁게 설계하고, 확률을 믿을 수 있는지 먼저 검증하고, 애매한 건 LLM이나 사람에게 넘기는 장치가 함께 있어야 합니다.

요약

Jevable은 AI 연구소 TypeSafe가 2026년 9월 공개한 모델 Jev로 개발자들이 만든 프로젝트를 모아 둔 갤러리입니다. 각 프로젝트는 제작자의 X 게시물로 연결되고, 에이전트, 브라우저 확장, 개발 도구, 금융, 게임, 로보틱스 등 12개 분류로 나뉘어 있습니다. 집계 시점 기준으로 214개가 올라와 있습니다. Jev는 OpenAI 출신으로 RLHF(사람 피드백 강화학습) 개발에 참여한 디오구 알메이다(Diogo Almeida)가 세운 TypeSafe의 첫 모델로, 회사는 이를 “System One” 모델이라고 부릅니다. 데이터와 함께 형식이 정해진 질문을 보내면, 질문마다 예·아니오 확률, 내가 정한 선택지 중 하나, 내가 정한 척도 위의 위치를 확률과 함께 돌려줍니다. 문장이나 코드는 쓰지 않습니다.

갤러리에 올라온 결과물은 대부분 같은 방향을 가리킵니다. 사람이 쓰는 앱 안에서, 또는 에이전트의 한 단계에서 “이건 무엇인가”, “다음엔 무엇을 할까”, “이 답은 맞는가”를 아주 짧은 시간에 판단하는 데 Jev를 씁니다. 제작자들은 같은 일을 LLM으로 할 때와 비교해 걸린 시간과 비용을 함께 올리는 경우가 많습니다. TypeSafe는 LLM보다 20200배 빠르고 40400배 싸다고 밝히고 있고, Vercel과 Deel 같은 회사도 지연과 비용이 크게 줄었다는 사례를 냈습니다. 다만 이 수치는 제작사와 사용자 측 발표이고, Jev는 아직 대기자 명단을 거치는 초기 공개 단계입니다. 아래에서는 Jev가 어떻게 작동하는지, 프로젝트들이 어떤 패턴으로 쓰고 있는지, 그리고 이를 실제 업무에 붙이는 방법을 정리합니다.

핵심 메커니즘

1. 타입이 정해진 결정

무엇인가. 답의 형식을 미리 정해 두고, 모델은 그 형식 안에서만 답하게 하는 방식입니다. Jev가 다루는 형식은 세 가지입니다. 예·아니오, 내가 준 선택지 중 하나, 내가 정한 척도(예: 0~10) 위의 위치입니다.

어떻게 작동하나. 입력은 판단 대상 텍스트와 질문 목록입니다. 질문마다 형식과 선택지를 함께 보냅니다. 모델은 각 질문에 대해 선택지별 확률을 계산하고, 가장 그럴듯한 답과 그 확률을 돌려줍니다. 답이 반드시 정해진 형식 안에 들어오기 때문에, 받는 쪽 코드는 문장을 해석할 필요 없이 바로 if문으로 분기할 수 있습니다. TypeSafe가 말하는 “환각이 없다”는 표현은 형식이 항상 지켜진다는 뜻이지, 답이 항상 맞는다는 뜻은 아닙니다.

언제 쓰고 언제 안 쓰나. 답이 몇 개의 선택지로 정리되는 판단(문의 유형 분류, 사기 의심 여부, 다음 화면 선택)에 맞습니다. 이유를 설명하는 글, 요약, 코드 작성처럼 답의 모양이 열려 있는 일에는 쓰지 않습니다.

원문의 예. MotherDuck은 SQL 안에서 텍스트를 분류하는 함수를 만들었고, ElevenLabs 개발자팀은 통화 내용을 실시간으로 읽어 사기 위험 점수를 매기는 데모를 올렸습니다.

작은 예시 (가상). 품질팀에 들어오는 고객 클레임 메일을 받아 “불량 유형(외관·치수·기능·포장·기타 중 하나)”, “긴급 여부(예·아니오)”, “고객 불만 강도(0~10)” 세 질문을 한 번에 보냅니다. 돌아온 답으로 담당자 배정과 회신 기한을 코드가 자동으로 정합니다.

2. 보정된 확률과 경계값

무엇인가. Jev의 답에 붙는 확률은 “보정(calibration)“을 목표로 학습됩니다. 0.8이라고 답한 것들을 모아 보면 실제로 약 80%가 맞는 상태를 말합니다. TypeSafe는 이를 위해 보정된 결정을 위한 강화학습(RLCD)이라는 학습 방법을 썼다고 밝혔습니다.

어떻게 작동하나. 개발자는 확률에 경계값을 정해 처리 경로를 나눕니다. 높으면 자동으로 처리하고, 중간이면 사람 검토로 보내고, 낮으면 더 비싼 LLM이나 담당자에게 넘깁니다. 확률이 실제와 맞아야 이 분기가 의미가 있으므로, 경계값은 감으로 정하지 않고 검증 세트로 정합니다(아래 기술 디테일).

언제 쓰고 언제 안 쓰나. 틀렸을 때의 비용이 크고 사람 검토 여력이 한정된 업무에서 효과가 큽니다. 모든 건을 사람이 어차피 다시 보는 업무라면 확률 분기의 이점이 작습니다.

3. 한 번에 여러 질문 묻기

무엇인가. Jev는 병렬 샘플러를 써서 한 번의 호출로 여러 질문에 동시에 답합니다. LLM처럼 한 글자씩 순서대로 만들어 내는 방식이 아니라서, 질문이 늘어도 지연이 크게 늘지 않는다는 것이 제작사의 설명입니다.

어떻게 작동하나. 하나의 입력에 대해 성격이 다른 질문 여러 개를 묶어 보냅니다. 답은 질문별로 따로 돌아오므로, 결과를 여러 축의 점수나 슬라이더로 바로 쓸 수 있습니다.

원문의 예. 한 제작자는 기분을 적으면 열 가지 색상 계열 각각에 대한 확률과 따뜻함·밝기·에너지 점수를 받아 화면 색을 칠하는 도구를 만들었습니다. 또 다른 제작자는 기술적 깊이, 자극성 같은 여섯 가지 슬라이더로 Hacker News 첫 화면을 내 취향대로 다시 정렬하는 도구를 만들었습니다.

4. LLM과 짝짓는 네 가지 방식

무엇인가. 갤러리의 프로젝트 대부분은 Jev 혼자가 아니라 LLM이나 다른 도구와 함께 씁니다. 역할을 나누는 방식은 크게 네 가지로 묶입니다.

어떻게 작동하나. 첫째는 라우터입니다. 요청마다 어떤 모델과 추론 강도를 쓸지 Jev가 고릅니다(OpenRouter). 둘째는 다음 행동 고르기입니다. 에이전트가 쓸 도구나 다음 클릭을 Jev가 고르고, 실제 작업은 브라우저나 다른 도구가 합니다(Browser Use, 브라우저 사이드 패널). 셋째는 검증·가드레일입니다. LLM이 쓴 답이나 사람이 쓴 글을 Jev가 규칙에 비춰 판정합니다(작성 규칙을 검사하는 글쓰기 린터). 넷째는 분기 탐색입니다. 같은 지점에서 여러 갈래를 동시에 시도하게 하고 살아남은 갈래를 고릅니다(마리오, 둠 플레이 실험).

언제 쓰고 언제 안 쓰나. 결정이 자주, 빠르게 필요한 자리에 Jev를 두고, 결과물을 만드는 자리에는 LLM을 둡니다. 협상처럼 길게 주고받아야 하는 일에는 맞지 않습니다. 여러 Jev에게 보드게임 카탄을 시킨 실험에서는 에이전트들이 협상을 멈추고 차례를 그냥 넘기는 모습이 나왔습니다.

5. 판단 단가가 내려가면 판단 횟수가 늘어난다

무엇인가. Jev라는 이름은 제번스의 역설(자원 효율이 오르면 오히려 사용량이 늘어나는 현상)에서 왔습니다. 판단 한 번의 비용과 시간이 충분히 떨어지면, 전에는 비싸서 사람이 뭉뚱그려 하던 판단을 건건이 자동으로 할 수 있게 된다는 생각입니다.

어떻게 작동하나. 같은 일을 LLM으로 하면 수십 분과 수십 달러가 드는 대량 판단이 수십 초와 몇십 센트로 내려옵니다. 그러면 표본만 보던 데이터를 전수로 보거나, 하루 한 번 하던 판단을 매 이벤트마다 하는 쪽으로 설계가 바뀝니다.

원문의 예. MotherDuck은 10만 행 분류에 40초, 0.5달러가 들었고 같은 일을 LLM으로 하면 32분, 37달러였다고 밝혔습니다. 회계 도구 Finta의 제작자는 34개월 치 장부 정리를 약 20초, 0.32달러에 끝냈다고 올렸습니다.

통념과 다른 주장

저자가 든 사례

갤러리의 사례는 각 제작자가 X에 올린 내용입니다. 수치는 모두 게시자가 밝힌 것입니다.

MotherDuck: SQL 안에서 텍스트 분류

상황	한 일	결과	연결
데이터 웨어하우스 안의 대량 텍스트를 분류하려면 LLM 호출 비용과 시간이 큼	SQL에서 바로 부르는 분류 함수로 Jev를 연결	10만 행에 40초·0.5달러 (LLM은 32분·37달러)	타입 결정, 판단 단가

ElevenLabs 개발자팀: 통화 중 사기 신호 감지

상황	한 일	결과	연결
전화 사기는 통화가 끝나기 전에 알아채야 의미가 있음	실시간 통화 기록을 읽어 사기 위험 점수를 매기게 함	요청당 약 180ms, 11번 요청에 0.00043달러	타입 결정, 확률

Browser Use: 더 빠른 브라우저 에이전트

상황	한 일	결과	연결
브라우저 에이전트는 클릭마다 LLM을 불러 느리고 비쌈	다음 행동 선택을 Jev에 맡김	항공권 검색 7초, 0.0039달러, 오픈소스 공개	다음 행동 고르기

Proq: 건설 도면 분류

상황	한 일	결과	연결
수십 장짜리 도면 세트를 시트별로 분류해야 함	시트마다 유형을 Jev로 분류	26장 세트를 2.9초, 0.0052달러에 처리. 정확도는 비교한 GPT 모델들과 같은 수준이라고 밝힘	타입 결정, 판단 단가

여러 Jev의 카탄 대결

상황	한 일	결과	연결
결정 모델끼리 협상이 필요한 게임을 할 수 있는지 시험	여러 Jev에게 카탄을 시킴	협상을 멈추고 차례를 그냥 넘기는 모습이 나옴	LLM과의 분업이 필요한 자리

기술 디테일: 실제로 붙이려면

타입이 정해진 결정을 쓰려면, 질문부터 좁게 설계합니다. 질문 하나에는 판단 하나만 담고, 선택지는 서로 겹치지 않게 3~7개로 둡니다. “기타”를 반드시 넣어 억지 분류를 막습니다. 아래는 질문 설계를 정리하는 형식의 예입니다. 실제 API의 필드 이름과 호출 형식은 TypeSafe 문서를 확인해야 합니다(이 노트의 JSON은 설계용 개념 예시입니다).

{
  "input": "제목: 배송된 브라켓 구멍 위치가 도면과 2mm 다릅니다 ...",
  "questions": [
    { "id": "defect_type", "type": "choice",
      "options": ["외관", "치수", "기능", "포장", "기타"] },
    { "id": "urgent", "type": "boolean" },
    { "id": "severity", "type": "scale", "min": 0, "max": 10 }
  ]
}

받는 쪽에서는 답과 확률을 함께 저장합니다.

{
  "defect_type": { "answer": "치수", "p": 0.94 },
  "urgent": { "answer": true, "p": 0.71 },
  "severity": { "answer": 7, "p": 0.48 },
  "latency_ms": 96,
  "model_version": "jev-2026-09"
}

보정된 확률을 믿기 전에, 내 데이터로 보정 상태를 확인합니다. 정답이 확정된 과거 사례 300건으로 검증 세트를 만듭니다. Jev의 확률을 0.50.6, 0.60.7처럼 구간으로 나누고, 구간마다 실제 정답률을 계산합니다. 구간마다 최소 30건이 들어가도록 표본을 모읍니다. 확률보다 정답률이 낮은 구간이 있으면 그 구간은 자동 처리에서 빼고 경계값을 올립니다.

경계값은 비용으로 정합니다. 틀린 자동 처리 한 건의 비용과 사람 검토 한 건의 비용을 먼저 적습니다. 예를 들어 잘못 배정된 클레임 한 건이 하루 지연을 만들고 사람 검토가 3분이라면, 검증 세트에서 “자동 처리 오류율 2% 이하”가 되는 가장 낮은 경계값을 고릅니다. 경계값은 질문마다 따로 정합니다.

숫자는 말로 바꿔 넣습니다. TypeSafe 문서는 Jev가 텍스트만 읽고 숫자보다 단어를 더 잘 다룬다고 안내합니다. 실제로 한 개발자가 손그림을 숫자 좌표로 넣어 분류해 본 비공식 실험에서는 정답률이 약 35%에 그쳤고, 절반 넘게 한 가지 답으로 쏠렸습니다. 측정값은 “공차 초과 2mm”, “전월 대비 30% 증가”처럼 의미가 담긴 문장으로 바꿔 넣습니다.

선택지 쏠림을 매주 점검합니다. 같은 기간 실제 분포와 Jev 답의 분포를 비교합니다. 한 선택지가 실제보다 10%p 이상 많이 나오면, 그 선택지의 이름이 너무 넓은지, “기타”가 빠졌는지 확인하고 질문을 고칩니다.

LLM과 짝지을 때는 실패 경로를 먼저 정합니다. 라우터로 쓸 때는 Jev가 고른 모델이 실패하면 한 단계 위 모델로 재시도하게 하고, 다음 행동 고르기로 쓸 때는 에이전트 단계 수를 최대 8~12회로 제한합니다. 검증으로 쓸 때는 Jev의 판정과 이유가 필요한 경우에만 LLM에게 설명을 따로 요청합니다. 확률이 낮은 건은 항상 LLM이나 사람에게 넘깁니다.

도입 전에 같은 데이터로 맞비교합니다. 검증 세트 300건을 Jev와 현재 쓰는 LLM(구조화 출력 모드)에 똑같이 돌려 정확도, p95 지연, 1,000건당 비용을 표로 비교합니다. 정확도가 2%p 넘게 떨어지면 속도·비용 이점이 있어도 그 질문에는 쓰지 않습니다. Jev는 초기 공개 단계라 가격과 동작이 바뀔 수 있으니, 응답에 모델 버전을 기록하고 분기마다 다시 비교합니다.

현업 실행 디테일: 누가, 언제, 무엇을

결정 모델을 붙일 업무는 세 조건으로 고릅니다. 같은 판단이 하루 수백 건 이상 반복되고, 답이 몇 개의 선택지로 정리되며, 정답을 나중에 확인할 수 있는 업무입니다. 예를 들면 고객 클레임 유형 분류, 공급사 메일 분류와 담당 배정, 전표의 계정 과목 분류, 불량 기록의 원인 유형 분류입니다.

역할	누가	맡는 일
업무 오너	해당 팀장	대상 판단과 선택지 확정, 오류 비용 정의, 결과 사용 결정
엔지니어	AI·데이터 엔지니어 1명	질문 설계, 검증 세트 구축, 보정 확인, LLM 맞비교
검토자	실무자 2명	검증 세트 정답 확인, 사람 검토 대기열 처리
보안	IT 담당	외부 API로 나가는 데이터 범위와 마스킹 확인

시작 전에 모을 것. 정답이 확정된 과거 사례 300건, 현재 사람이 그 판단에 쓰는 건당 시간, 틀렸을 때의 비용(지연, 재작업), 외부로 보내도 되는 필드 목록입니다.

기간	할 일	산출물
1~3일	선택지 확정, 과거 사례 300건 정답 정리	검증 세트
3~4일	질문 설계, 1차 실행	답·확률 표
5~6일	확률 구간별 정답률 확인, 경계값 결정	보정 그래프, 경계값표
6~7일	현재 LLM과 정확도·지연·비용 맞비교	비교표
8~9일	실제 업무 옆에서 결과만 기록(그림자 운영)	실제 데이터 성능
10일	진행 여부 결정	한 장 보고서

확인할 질문.

1. 이 판단의 선택지를 현업 두 사람이 따로 정리해도 같은 목록이 나오나?
2. 검증 세트에서 Jev와 사람의 판단이 갈린 사례 20건을 열어 보면, Jev가 틀린 것인가 정답 기준이 애매한 것인가?
3. 자동 처리 구간에서 틀렸을 때 누가 언제 알아채나?
4. 외부로 나가는 텍스트에 개인정보나 계약 조건이 섞여 있지 않나?

진행 판정 기준 (예시). 자동 처리 구간의 오류율 2% 이하, 전체 건의 60% 이상이 자동 처리 구간에 들어가고, 현재 LLM 대비 정확도 하락이 2%p 이내면 진행합니다. 기준은 파일럿 첫날 문서로 남깁니다.

AX 프로젝트에 쓸 때. 기업 업무를 프로세스 마이닝으로 보면, 흐름 곳곳에 “사람이 잠깐 보고 고르는” 결정 지점이 있습니다. 클레임 분류, 승인 여부, 담당 배정 같은 지점입니다. 이 결정 지점을 목록으로 만들고, 반복 횟수와 오류 비용으로 순위를 매기면 결정 모델을 붙일 자리가 나옵니다. 선택지는 온톨로지의 분류 체계(불량 유형, 계정 과목, 공급사 등급)를 그대로 쓰면 결과가 다른 시스템과 바로 연결됩니다. 생성이 필요한 보고서 작성은 LLM에 두고, 그 안의 판단만 결정 모델로 떼어 내는 것이 출발점입니다.

원문 사례

항목	내용
사이트	Jevable: Jev로 만든 프로젝트 갤러리 (각 항목은 제작자의 X 게시물로 연결)
규모	214개 프로젝트, 12개 분류(에이전트, 브라우저 확장, 크리에이티브 도구, 데이터·리서치, 개발 도구, 실험, 금융, 게임, 마케팅, 생산성, 로보틱스 등)
모델	TypeSafe의 Jev, 2026년 9월 공개. 첫 “System One” 모델, 텍스트 전용
제작사	TypeSafe. 공동 창업자 겸 CEO 디오구 알메이다(OpenAI 출신, RLHF·InstructGPT 공동 개발). DCVC 주도 시드 4,000만 달러
작동	데이터 + 형식이 정해진 질문 → 질문별 예·아니오, 선택지, 척도 답과 확률. 병렬 샘플러, RLCD 학습
제작사 주장	LLM 대비 20200배 빠르고 40400배 저렴, 대부분 약 100ms. 입력 100만 토큰당 0.042달러, 출력 무료
공개 사례	MotherDuck 10만 행 40초·0.5달러 · ElevenLabs 사기 감지 약 180ms · Browser Use 항공권 검색 7초·0.0039달러 · Proq 도면 26장 2.9초 · Finta 34개월 장부 약 20초·0.32달러 · 로봇 조종 233ms(비교 2초) · jevgrep 에이전트 비용 40% 절감 · Drape 결정당 약 620ms
기타 보도	Vercel AI Gateway 유료 팀의 약 13%가 24시간 안에 사용, Deel은 비용 최대 59배 절감
안내된 제약	텍스트만 읽음, 숫자보다 단어에 강함, 문장·코드 생성 안 함, 대기자 명단을 거치는 초기 공개

핵심 개념

결정 모델

문장을 만들지 않고, 정해진 형식의 답(예·아니오, 선택지, 점수)과 확률만 돌려주는 모델.

System One

TypeSafe가 Jev 같은 모델을 부르는 이름. 글을 쓰는 대신 빠르고 일관되게 판단하는 모델이라는 뜻으로 씁니다.

보정(calibration)

모델이 말하는 확률과 실제 정답률이 맞는 정도. 0.8이라고 한 답의 80%가 실제로 맞으면 잘 보정된 상태입니다.

RLCD

TypeSafe가 밝힌 학습 방법 이름(보정된 결정을 위한 강화학습). 세부 내용은 공개되지 않았습니다.

그림자 운영

새 시스템의 결과를 실제 업무에 쓰지 않고 옆에서 기록만 하며 성능을 확인하는 단계.

제번스의 역설

자원을 쓰는 효율이 좋아지면 오히려 전체 사용량이 늘어나는 현상. Jev라는 이름의 유래입니다.

내 메모

TODO: 내 생각 추가

원문은 Jevable 갤러리(Jev로 만든 프로젝트 모음)이며, 모델 설명은 TypeSafe 발표를 다룬 The New Stack, Dealroom 기사를 함께 참고했습니다. 요약·메커니즘·사례는 갤러리와 기사에 나온 내용을 AX Review가 다시 정리했고, 수치는 제작사와 각 게시자가 밝힌 것입니다. 기술·현업 디테일, JSON 예시, 인포그래픽, 표는 새로 작성했습니다. 각 프로젝트의 원래 게시물은 갤러리에서 볼 수 있습니다.