Jev 실전 가이드 — 글을 쓰지 않는 AI, 시스템 원 모델로 만들 수 있는 것 12가지

나는 이 접근이 왜 필요한지 청구서를 보고 나서 이해했다. 고객 문의를 여섯 개 카테고리로 나누는 작업에 프런티어 모델을 쓰고 있었다. 문의 하나당 2~3초, 요청마다 몇 센트. 한 달치를 합치니 "이 분류 하나 때문에 이 돈을?"이라는 숫자가 나왔다. 더 웃긴 건 그 모델이 내놓는 답의 대부분이 {"category":"billing"} 한 줄이었다는 점이다. 나머지는 전부 포장지였다.

시스템 원 모델이 무엇인가

생성 모델은 다음 토큰을 하나씩 만들어 낸다. 그래서 무엇이든 쓸 수 있지만, 무엇이든 쓸 수 있다는 게 곧 문제다. 스키마를 지키라고 프롬프트에 적어도 가끔 어긋나고, JSON 모드를 켜도 값 자체가 목록 밖으로 나가는 일이 생긴다. 그래서 우리는 검증하고, 재시도하고, 실패하면 기본값으로 떨어뜨리는 배관을 짠다.

시스템 원 모델은 그 배관을 없애는 쪽을 택했다. 애초에 생성하지 않는다. 디코더가 없으니 출력 토큰이 없고, 선택지 밖의 값이 나올 구조적 여지가 없다. 대신 할 수 있는 일도 좁다. 분류·점수화·판정, 딱 그 정도다.

어떻게 동작하나 — state와 questions

호출 구조는 단순하다. 판단의 재료가 되는 state를 주고, 답을 받고 싶은 questions를 함께 던진다. 여러 질문을 한 번에 넣으면 병렬로 평가된다. 답은 세 가지 프리미티브로 돌아온다.

# 개념적 호출 형태 (early access · POST /v1/systemone, model: jev-latest)
{
  "model": "jev-latest",
  "state": "고객 문의 원문 ...\n주문번호: 12345\n구매일: 2026-09-01",
  "questions": [
    { "id": "route",  "type": "choice",
      "prompt": "이 문의를 어느 팀으로 보낼까?",
      "options": ["결제", "배송", "반품", "계정", "기술지원", "기타"] },
    { "id": "urgent", "type": "noul",
      "prompt": "24시간 안에 대응하지 않으면 이탈 위험이 있는가?" },
    { "id": "tone",   "type": "score",
      "prompt": "고객의 불만 강도",
      "levels": ["평온", "약간 불편", "명확한 불만", "강한 분노"] }
  ]
}

# 응답(개념)
{
  "route":  { "value": "배송", "confidence": 0.94,
              "probs": { "배송": 0.94, "반품": 0.03, "결제": 0.01, ... } },
  "urgent": { "value": true,   "confidence": 0.71 },
  "tone":   { "value": "명확한 불만", "confidence": 0.63 }
}

여기서 중요한 건 probs와 confidence다. 값 하나만 받는 게 아니라 모델이 얼마나 확신하는지가 같이 온다. 이게 뒤에서 설명할 자동화 임계값의 근거가 된다.

숫자로 보기

타입세이프가 공개한 4개 워크플로 자체 평가에서 Jev의 평균 정확도는 약 67.8%로, 같은 평가에서 GPT-5.6 Sol 74.1%, Claude Opus 5 73.1%였다. 정확도는 6퍼센트포인트가량 낮지만 작업당 비용과 시간이 자릿수 단위로 다르다.

"환각하지 않는다"의 정확한 의미

마케팅 문구로 "0% 구조화 출력 오류"가 제시됐는데, 이건 실험 결과가 아니라 구조적 보장에 대한 진술이다. 정확히 말하면 이렇다.

이 구분을 뭉개면 위험한 신뢰가 생긴다. 형식 안전성(format safety)과 사실 정확성(factual accuracy)은 다른 축이다. Jev가 주는 건 전자이고, 후자는 여전히 평가 세트로 측정해야 한다.

진짜 제품은 신뢰도 보정이다

외부 개발자가 306건의 판단을 Claude Sonnet 5와 비교한 테스트가 인상적이었다. 정확도는 Jev 99.3%, Sonnet 99.0%로 비슷했는데, 틀린 지점의 성격이 달랐다. Jev의 오답 2건은 신뢰도 0.2~0.3 구간에서 나왔고, Sonnet의 오답 3건은 0.9 이상에서 몰렸다.

이게 운영에서 의미하는 바는 크다. 신뢰도가 낮을 때 틀리면 기계가 스스로 손을 들 수 있다. 신뢰도가 높을 때 틀리면 아무도 모르게 지나간다. 자동화 파이프라인을 짜 본 사람이라면 후자가 얼마나 무서운지 안다.

// 신뢰도 임계값으로 자동/수동을 가르는 기본 패턴
const r = await jev.ask(state, questions);

if (r.route.confidence >= 0.90) {
  await autoRoute(ticket, r.route.value);              // 자동 처리
} else if (r.route.confidence >= 0.60) {
  await queueForReview(ticket, r.route.value, 'low_conf');  // 제안 + 사람 확인
} else {
  await queueForHuman(ticket);                          // 사람이 처음부터
}

// 임계값은 감이 아니라 데이터로 정한다:
//  1) 신뢰도 구간별 실제 정확도를 기록(보정 곡선)
//  2) 오분류 1건의 비용과 사람 검토 1건의 비용을 비교
//  3) 두 비용이 만나는 지점이 임계값이다

이걸로 무엇을 만들 수 있나 — 아이디어 12가지

공통 조건은 하나다. 결과가 정해진 집합 안에서 나오고, 판단이 빈번하며, 틀렸을 때 되돌릴 수 있는 작업. 아래는 바로 적용해 볼 만한 것들이다.

반대로 넣지 말아야 할 것도 분명하다. 답변 생성, 요약, 번역, 코드 작성, 다단계 계획 수립. 타입세이프 스스로도 챗봇·코드 생성·추론 설명 용도로는 쓰지 말라고 명시하고 있다.

아키텍처 패턴 3가지

// 캐스케이드 — 실무에서 가장 자주 쓰게 되는 형태
async function classify(input) {
  const fast = await jev.choice(input, CATEGORIES);     // ~0.4초, ~$0.0004

  if (fast.confidence >= THRESHOLD) {
    metrics.inc('classify.fast');
    return { value: fast.value, via: 'jev', confidence: fast.confidence };
  }

  // 애매한 것만 큰 모델로 (전체의 10~20% 수준으로 유지되는지 감시)
  metrics.inc('classify.escalated');
  const deep = await frontier.classifyWithReasoning(input, CATEGORIES);
  return { value: deep.value, via: 'frontier', reason: deep.reason };
}

// 운영 지표 3개만 보면 된다:
//   escalation_rate  — 승격 비율(너무 높으면 임계값·스키마 재설계)
//   fast_accuracy    — 자동 처리 구간의 실제 정확도(표본 감사)
//   cost_per_1k      — 1천 건당 총비용(절감 효과 검증)

비용 감각 — 하루 100만 건이면

분류 작업 하나에 입력 400토큰을 쓴다고 가정하고, 하루 100만 건을 처리하는 서비스를 그려 보자. 실제 단가는 계약과 시점에 따라 다르므로 비율을 보기 위한 계산이다.

숫자의 절대값보다 구조를 보자. 쉬운 것을 싸게 처리하고 어려운 것에만 비싼 모델을 쓰는 것 — 이건 캐싱이나 CDN과 같은 오래된 원리다. 모델 시장이 티어별로 분화되면서 그 원리가 AI 파이프라인에도 그대로 적용되기 시작했을 뿐이다.

한계 — 알고 들어가야 하는 것들

• 텍스트 전용 — 이미지·오디오·영상 입력을 받지 않는다. 문서 이미지라면 OCR이 앞단에 필요하다.
• 64K 컨텍스트 — state 32K + 최장 질문 기준. 긴 문서를 통째로 넣는 용도가 아니다. 요약·발췌를 앞단에서 해야 한다.
• 비영어 성능 — 공개 벤치마크가 없고, 회사도 영어와 다를 수 있다고 밝혔다. 한국어 워크로드라면 직접 측정이 필수다.
• 리전 — 미국 서부 서버 기준이라 국내에서 호출하면 네트워크 왕복이 더해진다. 70ms 수치는 그대로 체감되지 않는다.
• 평가의 불확실성 — 공개 벤치마크를 의도적으로 피한다고 밝힌 만큼, 판단 근거는 자체 골든 세트뿐이다.
• 얼리 액세스 — 가용성·가격·API 형태가 바뀔 수 있다. 핵심 경로에 단독 의존시키지 말 것.

대안과 비교 — 언제 무엇을 쓰나

실무에서 Jev의 자리는 뚜렷하다. 분류 체계는 이미 있는데 라벨 데이터가 없는 구간. 라벨을 모으려면 사람이 붙어야 하고, 그 사이 서비스는 굴러가야 한다. Jev로 먼저 돌리면서 낮은 신뢰도 건을 사람이 처리하면, 그 처리 기록이 곧 라벨이 된다. 6개월 뒤엔 그 라벨로 전용 분류기를 학습시킬 수도 있다.

그래서, 추천한다

솔직한 평가를 적자면 이렇다. Jev는 만능이 아니고, 정확도 숫자만 보면 프런티어 모델보다 낮다. 그런데도 내가 이 모델을 권하는 이유는 제품 설계의 방향 때문이다.

시작은 작게 하는 게 맞다. 프로덕션 분류 경로 하나를 골라 섀도 모드로 붙여 보자. 실제 처리는 기존 방식대로 하면서 Jev의 판단을 함께 기록하고, 일주일 뒤 두 결과를 비교한다. 이 실험의 비용은 거의 0에 가깝고, 얻는 정보는 벤더의 벤치마크 표보다 백 배 유용하다.

그리고 이 모델을 쓰든 안 쓰든, 한 가지는 남는다. "우리 시스템이 내리는 판단 중 몇 퍼센트가 생성 모델을 필요로 하는가?" 이 질문에 답해 보면, 대개는 생각보다 훨씬 적다.

자주 묻는 질문

Jev는 어떤 모델인가요?

텍스트를 생성하지 않고 미리 정의한 스키마 안에서 값을 고르는 분류·판정 전용 모델입니다. 타입세이프AI가 2026년 9월 15일 공개했으며, 선택값과 함께 옵션별 확률과 보정된 신뢰도를 돌려줍니다. 회사는 이런 부류를 시스템 원 모델이라고 부릅니다.

정말 환각을 하지 않나요?

스키마 밖의 값이나 타입 오류는 구조적으로 발생하지 않습니다. 다만 선택지 안에서 틀린 항목을 고를 수는 있습니다. 형식 안전성과 사실 정확성은 다른 문제이므로, 자체 골든 세트로 정확도를 측정해야 합니다.

정확도가 프런티어 모델보다 낮은데 왜 쓰나요?

공개된 자체 평가 기준으로 6퍼센트포인트가량 낮은 대신, 작업당 비용과 시간이 자릿수 단위로 낮습니다. 게다가 오답이 낮은 신뢰도 구간에 몰리는 경향이 보고돼, 애매한 건만 사람이나 큰 모델로 넘기는 운영이 가능합니다.

어떤 작업에 쓰면 좋은가요?

고객 문의 라우팅, 보안 경보 트리아지, 문서·인보이스 분류, 모더레이션 1차 게이트, 에이전트의 도구 선택처럼 결과가 정해진 집합 안에서 나오는 판단입니다. 답변 생성·요약·코드 작성에는 적합하지 않습니다.

한국어 데이터에도 잘 동작하나요?

비영어 성능은 공개 벤치마크가 없고 회사도 영어와 다를 수 있다고 밝혔습니다. 한국어 워크로드라면 자체 데이터 200~500건으로 정확도와 신뢰도 보정 곡선을 직접 측정한 뒤 도입 여부를 판단하세요.

신뢰도 임계값은 어떻게 정하나요?

신뢰도 구간별 실제 정확도를 먼저 기록해 보정 곡선을 만든 다음, 오분류 1건의 비용과 사람 검토 1건의 비용이 만나는 지점을 임계값으로 잡습니다. 감으로 0.9를 쓰기보다 자기 데이터에서 계산하는 편이 훨씬 안전합니다.

기존 LLM 기반 분류에서 어떻게 옮기나요?

먼저 섀도 모드로 붙여 기존 결과와 나란히 기록하고 일주일 뒤 비교하세요. 그다음 신뢰도가 높은 구간만 Jev로 자동 처리하고 나머지는 기존 경로를 유지하는 캐스케이드로 전환하면, 품질을 지키면서 비용을 줄일 수 있습니다.

도입 시 주의할 점은 무엇인가요?

텍스트 전용이라 이미지·오디오는 앞단 처리가 필요하고, 컨텍스트가 64K로 제한되며, 서버 리전에 따른 네트워크 지연이 더해집니다. 또한 얼리 액세스 단계이므로 가격·API가 바뀔 수 있어 핵심 경로를 단독 의존시키지 않는 편이 안전합니다.