Typed Decision Model

"Agent 안의 작은 판단(라우팅, 분류, 점수, 통과 여부)을 매번 LLM에게 문장으로 물어야 하는가?" 이 페이지는 그 질문에 답한다. Typed decision model은 판단 대상인 상태(state)와 미리 형태를 정한 질문을 받아, 글 대신 타입이 정해진 값과 확률 분포를 돌려주는 모델 계층이다. 2026-09-15 TypeSafe AI가 Jev를 "System One model"로 공개하면서 널리 알려졌지만, 이 페이지는 제품 소식이 아니라 판단 단계를 코드·결정 모델·LLM 사이에 어떻게 나눌지를 다룬다. 상위 맥락은 AI Workflow vs Agent의 control boundary이며, 이 계층은 control을 코드에 남긴 채 그 안의 흐릿한 조건문만 모델에 맡기는 쪽으로 볼 수 있다.

무엇을 주고 무엇을 받나

• 입력은 판단할 상태와 형태가 정해진 질문이고, 출력은 코드가 바로 분기·정렬·라우팅에 쓸 수 있는 타입 있는 값과 확률 분포다. 글을 생성하지 않으므로 파싱할 문장도 없다.^[1]
• 질문 형태는 세 가지다.^[1:1]

• 한 번의 호출에 세 형태를 섞어 여러 질문을 넣을 수 있고, 각 질문은 같은 상태에 대해 병렬로, 서로 독립적으로 평가된다.^[1:2]
• 독립 평가이기 때문에 같은 요청 안의 질문끼리 서로의 답을 보지 못한다. 한 리뷰에서는 같은 응답이 어떤 계정을 "정지"로 판정하면서, 다른 질문에서는 테스트를 보내는 개발자로 분류했다.^[2]
• 답이 스키마 밖으로 나갈 수 없으므로 TypeSafe는 hallucination과 타입 오류가 0%라고 말한다. 하지만 이 수치는 측정값이 아니라 스키마 일치를 보장한다는 뜻이며, 스키마에 맞으면서 틀린 답의 비율은 결국 정확도 문제다.^[3][2:1]

코드·결정 모델·LLM의 역할 분담

• 핵심 설계는 일을 세 층으로 나누는 것이다. 결정 모델에는 좁은 의미 판단만 맡기고, 계산·권한·부작용은 코드에, 글쓰기와 긴 추론은 LLM에 남긴다.^[4]

flowchart LR
    R[요청과 상태] --> P{코드: 금지 규칙·한도}
    P -->|금지| X[거절]
    P -->|허용| D[결정 모델: Choice·Score·Noul]
    D --> G{confidence 게이트}
    G -->|높음| H[선택된 handler: 코드 또는 LLM]
    G -->|낮음| U[사람 검토 또는 큰 모델]
    H --> A[코드: 권한 확인·실행·기록]

• 위 흐름에서 금지 규칙은 확률적 라우팅보다 먼저 코드에서 처리하고, 결정 모델이 고른 handler도 자기 권한 검증과 출력 품질에 계속 책임을 진다.^[4:1]
• Agent workflow에서 결정 모델로 바꿀 만한 단계와 코드에 남겨야 할 부분은 다음과 같다.^[4:2]

confidence는 판단의 확신도이지 권한이 아니다

• confidence는 Choice와 Score가 돌려준 확률 분포의 모양을 0–1 숫자 하나로 요약한 통계다. 분포가 한 보기에 몰리면 높고 퍼지면 낮으며, Noul에는 붙지 않는다.^[1:3]
• TypeSafe 문서는 확신도를 높음(자동 처리)·중간(확인 요청이나 검토)·낮음(처리하지 않고 사람이나 다른 시스템으로 넘김)의 세 구간으로 나누고, 같은 시스템 안에서도 결과가 되돌리기 어려운 행동일수록 임계값을 높이라고 권한다.^[1:4]

action = response.answers["action"]
if action.confidence < 0.5:
    route_to_human(user_message)          # 모델이 모른다고 할 때는 추측하지 않는다
elif action.choice == "check_balance":
    show_balance(account_id)              # 틀려도 되돌릴 수 있는 읽기 작업
elif action.choice == "approve_transfer":
    if action.confidence > 0.9:
        confirm_then_execute(account_id)  # 위험한 작업은 더 높은 임계값 + 확인
    else:
        ask_user_to_confirm(account_id)

• 위 코드는 TypeSafe 문서 예시를 줄인 것이다.^[1:5] 다만 높은 confidence도 접근 권한을 주거나, 결제를 승인하거나, 위험 한도를 우회하는 근거가 될 수 없다. confidence는 선택이 맞다는 증명이 아니다.^[4:3]
• 보정(calibration) 품질은 데이터에 따라 달랐다. 22개 Choice 데이터셋을 합친 독립 평가에서는 기대 보정 오차(ECE)가 0.028로 잘 맞았다.^[5] 반면 확률 분포 전체를 돌려주는 LLM들과 비교한 다른 측정에서는 Jev의 보정 오차(0.161)가 가장 높았고, 과신과 과소신의 방향도 데이터마다 바뀌었다.^[2:2]
• Noul 같은 이진 확률은 순위는 잘 매기지만 고정된 0.5 기준에 잘 맞지 않았다. 학습 데이터로 임계값을 맞추자 UNFAIR-ToS의 micro-F1이 0.50에서 0.75로 올랐다.^[5:1]
• 자기 라벨 50개에서 수백 개로 온도(temperature) 하나를 맞추면 보정 오차의 대부분이 고쳐졌다. 같은 방식으로 읽는 오픈 모델에도 똑같이 적용됐다.^[2:3]

큰 질문 하나보다 원자적 질문 여러 개

• TypeSafe 문서는 질문 하나가 한 가지만 묻게 하라고 권한다. 여러 요인을 따져야 하는 판단은 요인별 질문으로 쪼개고, 가중치와 조합은 코드에 둔다. 그래야 우선순위가 바뀔 때 prompt를 다시 쓰지 않고 코드의 계수만 바꾸면 된다.^[1:6]
• 독립 측정에도 질문을 쪼갠 결과가 있다. 피싱 메일 벤치마크에서 좁은 Jev 질문 5개를 logistic regression으로 합치자 held-out 절반에서 95.0%가 나왔다.^[2:4]
• 같은 벤치마크에서 Luce(라벨 1,000개 학습)는 97.4%, Jev는 62.6%로 보고됐지만 두 점수는 서로 다른 문항에서 나왔다. 62.6%가 어떤 질문 구성의 값인지는 출처에 없으므로 95.0%와 같은 조건의 전후 비교로 읽을 수 없다.^[2:5]
• 같은 벤치마크에서 정규식 두 줄이 91.6%, Haiku 4.5에 같은 질문 5개를 물은 결과가 93.2%였다. 95.0%와 93.2%의 차이는 유의하지 않았다(p = 0.063).^[2:6] 이 결과로 보면 점수를 좌우한 것은 모델 교체보다 질문 설계였다고 해석할 수 있다.
• 세기(counting)처럼 코드가 정확히 할 수 있는 일은 모델에 묻지 않는다. 대신 항목마다 Noul을 하나씩 묻고 합계는 코드가 낸다.^[1:7]

실패 유형

• TypeSafe가 jev-1.13에 대해 공개한 약점 목록은 다음과 같다. 수학, 날짜·시간 비교, 구조 불변식 같은 항목에서는 판단은 모델에 맡기고 산술·비교·항등식은 코드에 두라고 권하며, 나머지 항목은 조건을 정확히 쓰거나 생성 모델을 쓰는 등 다른 대응을 제시한다.^[1:8]

• 구조 불변식이 깨지는 예로, 같은 티켓에 "환불 요청인가"는 0.72, "환불 외의 요청인가"는 0.47이 나와 합이 1.19였다.^[1:9]
• 보기 이름만 주고 설명을 붙이지 않은 라우터는 어려운 과제 40개를 전부 싼 모델로 보냈고, 이때 confidence 중앙값은 0.96이었다. 보기마다 한 줄 설명을 붙이자 40개 중 37개가 고쳐졌다.^[2:7]
• 정답이 입력에 없는 질문에서 가장 자신 있게 틀렸다. "모름" 보기가 없는 KoBBQ 편향 질문에서 모든 답이 설계상 오답이었는데도 confidence는 0.79였다.^[2:8] 그래서 닫힌 보기 목록에는 unknown·other·사람 검토 같은 탈출구를 넣어야 한다.^[4:4]
• 상태는 공격 표면이다. 사용자 입력이나 검색해 온 글에 섞인 지시가 판단을 움직일 수 있으므로, 신뢰하는 정책과 분리하고 적대적 입력을 시험해야 한다.^[1:10][4:5]

성능은 어느 정도인가

• 정확도는 중간 가격대 LLM과 비슷한 수준이다. 가장 깔끔한 비교에서 최상위 모델보다 6.5–11.5점 낮았고, 이진 판단과 보기가 적은 분류에서 가장 강했다.^[2:9]
• 37개 데이터셋 zero-shot 평가에서는 같은 요청을 받은 Qwen3.8-27B보다 27개 데이터셋에서 높았고, Gemma-4-E4B보다는 37개 모두에서 높았다.^[5:2]
• TypeSafe가 내세운 193.6배 빠름·444.6배 저렴은 자사 팀이 만든 4개 워크플로 평가에서 나온 수치다. TypeSafe 스스로도 실제 이득의 상단에 가깝다고 밝혔다.^[3:1]
• 독립 측정에서는 비교 대상과 네트워크 경로에 따라 속도가 0.5배(로컬 Gemma보다 느림)부터 12.1배, 비용이 0.6배(더 비쌈)부터 478배까지 퍼졌다. 비용 격차의 대부분은 출력이 무료라는 가격 구조에서 나온다.^[2:10]

한국어 입력

• TypeSafe는 영어가 주 학습 언어라고 밝힌다. 122개 언어 독해(Belebele)에서 영어는 97.2%, 언어 전체 중앙값은 91.1%였다. 10개 언어는 70% 아래로 떨어졌고 가장 낮은 것은 나이지리아 풀풀데어(37.4%)였으며, 논문은 저자원 언어에서 성능이 크게 떨어진다고 정리한다.^[5:3]
• 같은 문항을 번역해 비교한 100문항 표본 점검(오차 약 ±8점)에서 한국어 독해는 96점으로 영어 97점과 차이가 없었다. 두 문장 의미 동일성 판단(PAWS-X)은 한국어 76점, 영어 80점으로 두 언어 모두 약했다.^[6]
• 한국어 입력에 지시문을 한국어로 쓰든 영어로 쓰든 점수 차이는 1–2점이었다. Jev를 쓸 때는 지시문을 번역해도 얻는 것이 없었다.^[6:1]
• 같은 점검에서 비교 대상 LLM은 영어에서 한국어로 바꾸면 PAWS-X에서 11점을 잃었고, Jev는 4점을 잃었다. 유일하게 유의한 차이는 한국 의사 국가시험(KorMedMCQA)에서 비교 LLM이 Jev보다 8점 높은 것이었다.^[6:2]
• 따라서 한국어 여부보다 과제 종류(세밀한 의미 판단, 전문 지식)가 성능을 더 크게 가른다고 보인다. 다만 표본이 작으므로 실제 도입에서는 자기 과제의 한국어 라벨로 따로 재야 한다.

새로운 기술인가

• 독립 리뷰는 메커니즘의 모든 조각에 선행 연구가 있다고 정리한다.^[2:11]

• 눈에 보이는 기여는 패키징이다. 타입 있는 API, 호스팅된 endpoint 하나, 0원인 출력 가격, 한 요청 안의 여러 질문이 그것이다. 학습 방법(RLCD)은 논문이나 방법 설명이 공개되지 않았다.^[2:12]
• 같은 원리로 어떤 오픈 모델이든 보기 토큰의 점수만 읽어 softmax하면 같은 형태의 인터페이스를 만들 수 있다. 데이터를 망 밖으로 보낼 수 없는 환경에서 대안이 되는 이유다.^[2:13]

도입 전에 할 일

• 이미 결과 라벨이 있고, 자주 일어나고, 되돌릴 수 있는 판단 하나로 시작한다. 모델 라우팅은 기존 handler를 fallback으로 둔 채 결정 모델을 섀도 모드로 돌릴 수 있어서 좋은 후보다.^[4:6]
• 시범 도입 순서는 다음과 같다.^[4:7]
  1. 보기, unknown 경로, 강제 규칙, 최종 부작용을 누가 소유하는지를 담은 결정 계약을 정한다.
  2. 드문 사례, 모호한 사례, 다국어 입력, prompt injection을 포함한 평가 세트를 만든다.
  3. 모델 버전을 고정하고, 결정·분포·confidence·결과를 기록한다.
  4. 결과의 무게에 따라 임계값을 다르게 둔다.
  5. 강제 적용 전에 섀도 모드로 비교한다.
  6. 장애나 모델 변화에 대비해 deterministic 기본값과 롤백을 남긴다.
  7. 버전이 바뀔 때마다 같은 세트로 다시 평가한다.
• 판단 50개에서 수백 개에 라벨을 붙여 임계값을 정하고 확률을 맞출 계획을 세운다.^[2:14]

관련

• AI Workflow vs Agent: 결정 모델은 다음 행동을 모델에게 넘기는 agent 쪽이 아니라, workflow 코드 안의 흐릿한 분기 하나를 맡는 부품으로 볼 수 있다.
• Agent Safety Boundary: confidence 게이트는 판단의 경계이고, 권한 승인 경계는 여전히 코드와 사람에게 있어야 한다는 점에서 이어진다.
• Agent Tool Use: 도구 선택과 라우팅 같은 제한된 판단을 결정 모델로 좁히면, LLM tool call의 자유도를 줄일 수 있다.
• Agent Evaluation Loop: 라벨 기반 평가, 섀도 비교, 버전별 재평가가 도입의 전제 조건이다.

테스트 질문

• 결정 모델이 confidence 0.95로 "결제 승인"을 골랐다면, 그 값만으로 결제를 실행해도 되는가?
• "hallucination 0%"는 무엇을 보장하고 무엇을 보장하지 않는가?
• 한국어 입력에 Jev를 쓸 때 지시문을 영어로 바꿔야 하는가?

출처