LLM 라우팅과 가드레일은 어떻게 만들까? Jev와 LLM의 협업 사례

이해관계 및 증거 공개: PandaNpc는 Jev를 사용하는 Agent 의사결정 계층을 개발 중입니다. 아래에서는 TypeSafe 공식 문서, 공식 cookbook, 그리고 저장소의 실제 Jev 호출 및 합성나리오 캘리브레이션을 각각 인용합니다. 우리의 캘리브레이션은 스크립트화된 가짜 LLM provider를 사용하므로 실제 사용자 트래픽이나 전체 프로덕션 경로의 성능을 대표하지 않습니다.

LLM 라우팅은 이렇게 할 수 있습니다: 먼저 Jev가 요청이 어느 범주에 속하고 위험이 얼마나 높은지 판단하게 하고, 그다음 코드가 일반 함수, 전문 LLM, 또는 사람 검토로 넘길지 결정합니다. Jev는 검색과 생성 사이에서 증거를 걸러내거나, LLM 출력 뒤에 결과를 검사하는 데 놓일 수도 있습니다. Jev가 반환하는 것은 닫힌 선택지, 점수, 확률입니다; 개방형 답변, 코드 생성, 긴 추론은 여전히 LLM이 수행합니다. TypeSafe의 coding agents 설명은 Jev가 Claude Code나 Codex 뒤의 채팅 모델을 직접 대체할 수 없다고 명확히 밝힙니다.

이 글은 고객 지원 요청 하나, RAG 질의응답 파이프라인 하나, 그리고 우리 자신의 Agent 캘리브레이션 기록을 사용해 두 종류의 모델이 정확히 어디서 교대하는지, 그리고 낮은 신뢰도 결과에 왜 명확한 목적지가 있어 하는지 설명합니다.

Jev는 무엇을단할 수 있고, LLM은 무엇을 계속 담당할까?

2026년 9월 23일 기준으로 TypeSafe 모델 페이지에 나열된 안정델은 jev-1.13.0입니다. API는 하나의 state와 `` 집합을 받고, POST /v1/systemone을 통해 대응하는 구조화된 answers를 반환합니다. jev-latest는 당일 1.13.0을 가리켰지만, 별칭은 버전에 따라 바뀝니다; 임계값을 캘리브레이션한 시스템은 버전을 고정하고 응답의 실제 모델 ID를 기록하는 것이 좋습니다.

Noul에는 독립적인 confidence 필드가 없습니다; 하나의 Noul 확률을 곧바로 “모델 신뢰도”라고 쓰면 안 됩니다. Score도 정확한 금액을 계산하는 데 써서는 안 됩니다. 금액, 날짜 비교, 할당량, 권한 검사는 결정적 프로그램에 남겨야 하며, 공식에서 Jev 1.13의 이러한 경계를 나열했습니다.

한 번 호출의 최소 형태

아래 요청 형태는 공식 API 참조와 일치하며, 예시 질문은 이 글에서 구성한 설명용 구성으로, 이 글에서 온라인 실측을 수행하지 않았습니다:

아래 JSON은 영어 고객 메시지를 사용하지만, 한국어에서는 고객이 “주문이 중복 결제되었으니 환불해 주세요.”라고 말할 것입니다.

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

실제 시스템은 먼저 코드로 해당 청구가 같은 주문에 속하는지, 환불이 허용되는지 확인해야 합니다. 위 예시는 사용자 의도를 판독하는 데만 사용됩니다; 사용자가 환불을 요구한 것이 환불 자격이 입증되었다는 뜻은 아니며, 환불을 직접 실행할 권한을 구성하지도 않습니다.

Jev로 LLM 라우팅하기: 세 가지 교대 경로

TypeSafe 공식 의도 라우팅 예시는 고객 지원 요청을 먼저 Jev에 넘겨 의도와 복잡도를 판단하게 한 다음, 코드로 분기합니다: 주문 상태 조회는 데이터베이스 함수로; 제품 질문과 반품/교환은 각각 다른 자료를 로드한 전문 LLM으로; 복잡한 불만이나 낮은 신뢰도 결과는 사람 대기열로. 이것이 바로 Jev와 LLM의 가장 이해하기 쉬운 협업입니다: 전자는 구조화된 판단을 제공하고, 후자는 설명이나 대화 생성이 필요할 때만 등장합니다.

구현할 때는 모델이 모든 행동을 자유롭게 결정하게 하는 대신, 다음 순서로 설계할 수 있습니다:

1. 먼저 경로를 정의합니다: 일반 함수, 각 전문 LLM, 사람 검토가 처리할 수 있는 요청을 명확히 나열하고, Choice에 other 또는 같은 종류의 폴백 옵션을 둡니다.
2. 사실을 state에 넣습니다: 사용자 원문, 계정 상태, 주문 기록을 각각 필드로 만듭니다; 출처가 불분명한 웹페이지 텍스트를 시스템 지시로 넣지 않습니다.
3. 한 번에 좁은 질문을 합니다: 의도는 Choice, 위험 또는 긴급도는 Score, 확인이 필요한 단일 사실은 Noul로. 공식은 같은 state의 여러 독립 질문을 한 요청에서 병렬 평가할 수 있다고 권장합니다.
4. 코드가 최종 라우팅을 합니다: 먼저 권한과 하드 규칙을 확인하고, 그다음 Jev의 확률과 이 비즈니스에 맞게 캘리브레이션된 임계값을 봅니다; 낮은 신뢰도 또는 증거 부족 요청은 사람 또는 추가 질문으로 보냅니다.
5. 결과를 기록하고 재검토합니다: 모델 버전, 질문 버전, 확률, 최종 목적지, 사람 교정 결과를 저장해야 임계값이 적절한지 판단할 수 있습니다.

이미지 출처: TypeSafe AI《Introducing System One Models & Jev》, 2026-09-15. 네 가지 워크플로는 TypeSafe가 자체 구축했고, 지표는 워크플로별 등가중으로 집계되었습니다; 평가 방법은 TypeSafe workflow evals를 보십시오.

공식의 이 그림은 왜 “여러 좁은 판단을 프로그램 워크플로에 담으라”고 강조하는지 이해하는 데 도움이 됩니다. 그림의 세로축은 벤더의 “accuracy” 명칭을 따르지만, 그 참조 답은 두 대규모 모델의 예측 확률 합의에서 나온 것이며 사람이 검증한 유일한 정답이 아닙니다; 비용과 지표도 이 네 가지 워크플로 및 벤더의 평가 방법에 달려 있으므로 “어떤 시나리오에서든 얼마나 절약되는가”로 환산할 수 없습니다.

검색 증강 생성: Jev가 LLM 답변 전에 증거를 거릅니다

TypeSafe의 RAG passage cookbook은 더 구체적인 멀티모델 예시를 제공합니다: OpenAI embedding이 먼저 단락을 검색하고, Jev가 각 “질문＋단락”에 대해 네 가지 Noul을 묻습니다—관련이 있는지, 답변에 사용할 수 있는 증거를 포함하는지, 질문의 전제를 반박하는지, 답변 모델에 지시를 내리려 하는지. 코드는 네 확률을 순서대로 처리해 해당 단락을 증거 영역, 충돌 증거 영역에 넣거나 버릴지 결정합니다; 마지막으로 Claude Sonnet 5가 답변을 작성합니다.

이 단계는 흔한 문제를 해결합니다: 벡터 유사도가 높은 단락이 반드시 사용 가능한 것은 아닙니다. 비슷한 단어만 사용했을 수도 있고, 포럼 게시글에 “앞 문맥을 무시하라”는 프롬프트 인젝션을 끼워 넣었을 수도 있습니다. cookbook의 예시는 주입 검사를 라우팅 규칙 맨 앞에 두고, 동시에 임계값은 그 말뭉치에 맞춰 선택한 출발점이며 모든 RAG 애플리케이션의 기본값이 아니라고 알립니다. 그 데모 숫자는 2026-08-27의 jev-1.12에서 나온 것이므로 현재 jev-1.13.0의 새로운 평가 결과로 볼 수 없습니다.

생성 후에도 한 층의 대조를 할 수 있습니다. TypeSafe 인용 확인 cookbook은 먼저 프로그램으로 인용 원문을 찾고, 그다음 Jev로 해당 단락이 생성된 주장을 지지하는지, 반박하는지, 언급하지 않는지 판단합니다. 재검토할 가치가 있는 인용을 골라낼 수 있습니다; 모델 판단 자체는 여전히 틀릴 수 있으므로 “검사를 통과했다”를 사실 보증으로 쓰면 안 됩니다.

우리의 Agent 캘리브레이션: 낮은 신뢰도 에스컬레이션은 어디에서 막힐까?

PandaNpc 저장소에서 Jev 클언트, 질문 문제 은행, 오케레이터는 Jev를 Agent의 의도 인식, 후보 수정 점수화, 완료 조건 확인, 제출 판단에 사용합니다. 클라이언트는 타임아웃, 429, 5xx에 대해 제한적 재시도를 하고, 요청 예산과 만료 결과에 제한을 둡니다; 실행 권한은 오케스트레이터와 통제된 도구 계층이 보유하며, Jev의 한 판단이 직접 부여하지 않습니다.

우리는 2026-09-22에 jev-1.13.0으로 19개의 합성 turn마다 shadow 한 번, enforce 한 번을 실행해 총 38회 실행, 165개의 실제 Jev 결정을 기록했습니다. 이 내부 캘리브레이션 보고서와 저장된 실제 장치 응답은 스크립트화된 가짜 LLM provider를 사용하므로, 이 데이터는 통제된 시나리오에서의 의사결정 성능만 설명합니다. 실제 사용자 요청에서의 전체 성공률, 절감 비율, 종단 간 지연을 입증하지는 못합니다.

가장 가치 있는 발견은 평균 속도가 아니라 “안전해 보이는” 임계값이 만든 정체였습니다: enforce의 19개 turn 중 13개가 Q2 “정보가 수정을 시작하기에 충분한가”에서 Noul 확률이 원래 정한 0.15–0.85 불확실 구간에 들어가 에스컬레이션되었고; LLM Worker는 후속 단계를 실행할 기회가 없었습니다. 캘리브레이션 기록에 따르면 정보가 충분하다고 표시된 34개의 Q2 결정 중 많은 확률이 중간 구간에 있었습니다. 보고서는 복잡한 Q2를 더 원자적인 판단으로 쪼개거나 에스컬레이션 규칙을 조정할 것을 권장합니다; 이것은 권장 사항이며, 이미 배포된 임계값이 아닙니다.

우리 문제 은행은 입구를 answer_only, inspect, modify, out_of_scope로 판정합니다; 쓰기 경로에서 Worker가 제안한 후보 수정은 먼저 Score로 정렬되고, 최종 내용과 변경 요약은 다시 수락 및 제출 판단을 거칩니다. 이것들은 의사결정 지점일 뿐입니다: 실제로 객체를 읽고 쓸 수 있는지는 통제된 실행기가 단계에 따라 권한을 부여합니다. Jev는 스스로 도구 허용 목록을 완화할 권한이 없고, 제출 전 일관성 검사를 우회할 수도 없습니다.

캘리브레이션 데이터는 또 다른 절충을 드러냅니다. shadow 모드에서 Jev는 답과 전체 분포를 제공하지만 Worker의 원래 실행 경로를 바꾸지 않습니다; enforce 모드에서는 답이 계속할지, 에스컬레이션할지, 버릴지에 영향을 줍니다. shadow의 정확도를 enforce의 완료율로 바로 보면 시스템을 잘못 읽게 됩니다: Q2의 에스컬레이션은 작업을 조기에 가로막아 이후 후보 점수화, 수락, 제출 문제가 아예 나타날 기회를 없앨 수 있습니다. 따라서 이 보고서는 각 문제의 분포, 에스컬레이션 방향, 최종 상태를 분리해서 읽습니다.

후보 수정 중 구체적인 대조가 하나 있습니다: 같은 turn에서 정확한 수정 대상을 지정한 후보는 2.94점을 받았고, 전체 파일 덮어쓰기를 사용한 후보는 0.38점을 받았습니다; 높은 점수의 후보가 선택되었습니다. 이 예시는 그 합성 상황에서 점수 문제가 두 방안을 구분했다는 것만 보여줍니다. 반대로 증거가 잘린 후보는 2.27점을 받았는데, 숫자가 “괜찮아” 보인다고 해서 낮은 신뢰도와 잘림 표시를 무시해서는 안 됩니다. 우리 코드는 증거 불충분을 별도로 표시해, 모델이 보존된 앞부분만으로 확정적 쓰기 판단을 내리지 않게 합니다.

우리는 또한 “어느 후보를 선택할지”와 “그것을 쓰게 허용할지”를 서로 다른 두 단계로 분리했습니다. 후보가 Jev 점수를 통과한 뒤, 통제된 실행기는 ACT/modify 단계에서만 쓰기 도구를 엽니다; 발급된 일회용 티켓은 도구 호출 ID, 현재 리비전 번호, 대상 객체 해시, 파라미터 요약에 묶입니다. 후보 텍스트가 모델에게 “제한을 무시하라”고 유도하더라도, 이 검사들을 넘어서는 도구 권한을 얻지 못합니다. 이것은 우리가 코드 수준 통합에서 얻은 경험입니다: 확률 판단은 어느 길이 갈 만한지 결정하고, 부작용 권한은 재검토 가능한 프로그램 조건이 결정합니다.

실패 경로도 설계해야 합니다. 클라이언트는 타임아웃, 네트워크 오류, 429 또는 5xx일 때만 제한적으로 재시도합니다; 취소된 뒤 또는 turn 마감 시간을 넘긴 답변은 바로 버립니다. enforce 모드에서 Jev를 사용할 수 없으면, 다운그레이드 권한이 없는 경우 계속할 수 없습니다; llm_only로 가도록 승인되면 실행기는 읽기 전용으로 잠급니다. 분기가 이미 수정을 일으킨 뒤에 Jev를 잃으면, 오케스트레이터는 전체 회차를 실패로 표시하고, 이후 LLM이 의사결정 계층 없이 쓰기를 대신 수행하게 하지 않습니다. 이러한 경로는 사용자 경험에 비용이 들지만, “모델을 일시적으로 사용할 수 없음”이 조용히 “쓰기 권한은 그대로”가 되지는 않게 합니다.

캘리브레이션 보고서는 “낮은 신뢰도 에스컬레이션”과 “실행 거부”도 구분했습니다. 예를 들어 올바른 discard가 통일된 0.85 임계값에 도달하지 못한 신뢰도라면 사용자 입력이 필요하다고 기록됩니다; 이것은 잘못 허용한 것과 같지 않습니다. 보고서는 이에 따라 제출과 폐기 임계값을 나눌 것을 권장하지만, 아직 권장 사입니다. 쓰기 워크플로를 만들 때는 잘못 허용, 잘못 거부, 검토 대기라는 세 가지 결과를 반드시 구분해야 하며, 그렇지 않으면 같은 데이터에서 잘못된 임계값 결론을 도출하게 됩니다.

이 사례는 Jev와 LLM의 협업을 “Jev가 먼저 판단하고, LLM이 그다음 일한다”로만 그려서는 안 된다는 것을 보여줍니다. 각 판단마다 물어야 합니다: 불확실 구간이 얼마나 넓은가? 이후 프로세서가 영원히 작업을 받지 못하게 하는가? 입력 증거가 잘렸다면 추측 대신 명확히 에스컬레이션할 수 있는가? 우리 구현에서 state 빌더는 evidence_truncated를 기록하고, 호출자가 증거 부족 경로를 불확실로 취급하게 합니다; 개수 세기, 정렬 같은 결정적 계산은 먼저 코드에서 완료하고 Jev에게 추측시키지 않습니다. 공식 Jev 1.13 알려진 제한도 개수 세기와 산술을 코드에 남기라고 권장합니다.

LLM 가드레일은 어디에 두어야 할까?

TypeSafe의 LLM guardrails cookbook은 Jev를 LLM의 입력과 출력쪽에 둡니다. 한 세트의 Noul로 다양한 위험을 식별하고, Score로 심각도를 측정한 뒤, 코드가책에 따라 허용, 사람 검토, 차단 또는 지원팀 전달을 결정합니다. 출력도 검사해야 합니다. 일반 입력도 부적절한 생성 결과를 낼 수 있기 때문입니다.

이 가드레일의 경계도 분명합니다: Jev는 미리 작성된 질문에 따라 내용을 검사할 수 있지만, 만능 안전 증명은 아닙니다. 공식 제한 문서는 악성 내용이 판단에 영향을 줄 수 있다고 명확히 언급하며, criteria를 분명히 쓰고 경계를 테스트하라고 요구합니다. 우리의 합성 표본에서는 후보 파라미터를 겨냥한 주입 프로브를 16회 수행해 0회의 순위 뒤집힘을 기록했습니다; 표본이 너무 작아 “프롬프트 주입 저항이 해결되었다”고 결론 내릴 수 없습니다. 도구가 무엇을 할 수 있는지 실제로 결정하는 것은 여전히 코드의 허용 목록, 단계 게이트, 제출 전 검사입니다.

언제 적합하고, 언제 쓰지 말아야 할까?

Jev에 적합한 것은: 후보 집합이 알려져 있고, 문제를 몇 개의 짧은 판단으로 쪼갤 수 있으며, 소프트웨어가 확률로 자동 처리 또는 사람 에스컬레이션을 결정해야 하는 경우입니다. 예를 들어 고객 지원 라우팅, RAG 단락 필터링, Agent 후보 행동 점수화, 생성 결과의 인용 확인 등입니다. 작업이 답장을 쓰거나, 코드 일부를 고치거나, 복잡한 추론 과정을 설명하는 것이라면 LLM이 맡습니다. 작업이 정확한 금액 계산, 날짜 비교, 접근 제어 확인이라면 프로그램이 직접 계산해야 합니다. 모델 페이지는 또한 Jev가 텍스트만 받고, 영어가 현재 가장 잘 수행하는 훈련 언어라고 설명합니다; 중국어 시나리오는 자체 데이터로 평가해야 하며, 영어 cookbook의 임계값을 그대로 가져올 수 없습니다.

실제 Agent가 권한과 도구 호출을 어떻게 처리하는지 관찰하고 싶다면 PandaNpc Agent를 먼저 보십시오; 코딩 Agent의 경계와 사용 사례에 대해서는 Claude Code와 Codex 비교도 참고할 수 있습니다.

독자는 아주 작은 검증 세트로 시작할 수 있습니다: “명백히 자동 처리 가능”, “명백히 거부해야 함”, “의미가 모호함”, “악성 지시 포함” 네 가지 샘플을 준비합니다; 먼저 사람 라벨을 정하고, 그다음 Jev의 각 문제 확률과 라우팅 결과를 기록합니다. 성공 판단 기준은 모든 항목이 자동 통과하는 것이 아니라, 자동 처리 경로의 오류율과 사람 에스컬레이션량이 모두 수용 가능한 범위에 들어오는 것입니다. 모호한 샘플이 대량으로 같은 문제에서 막히면, 먼저 문제에 여러 판단이 섞였는지, state가 너무 긴지, 임계값이 로컬 데이터에 맞게 캘리브레이션되었는지 확인하십시오.

FAQ

Jev가 Claude Code, Codex 또는 채팅 모델을 대체할 수 있습니까? 아닙니다. TypeSafe는 이를 소프트웨어 내부의 구조화된 의사결정 모델로 위치시킵니다; 채팅, 글쓰기, 코드 생성에는 여전히 LLM이 필요합니다.

반환 유형이 고정되어 있으면 실수하지 않습니까? 아닙니다. 고정 유형은 파싱과 범위를 벗어난 출력 문제를 줄이지만, 분류, 점수화, 사실 판단은 여전히 틀릴 수 있습니다. 낮은 신뢰도와 높은 위험 경로에는 사람 검토를 남겨야 합니다.

같은 요청에 몇 개의 질문을 할 수 있습니까? 같은 state를 공유하는 여러 독립 Choice, Score, Noul을 한 요청에 넣을 수 있습니다. 문제는 각각 평가되며, 복잡한 판단은 여전히 나누고 코드가 조합해야 합니다.

중국어를 사용할 수 있습니까? 공식은 중국어, 일본어, 한국어 문자를 포함한 자연어를 지원한다고 밝히지만, 현재 영어 정확도가 가장 좋습니다. 중국어 워크로드는 별도 검증과 캘리브레이션이 필요합니다.