오늘날 LLM(Large Language Model) 판정을 출시하는 대부분의 팀들은 같은 방식으로 진행합니다. 모델에 텍스트를 제공하고, 평결을 요청한 다음, 단락 형태의 답변을 받습니다. 그리고 그 단락에 곧바로 실망합니다. 그 세네 문장 어딘가에는 '예' 또는 '아니요'라는 의미를 가진 단어가 있는데, 이를 신뢰성 있게 추출하는 유일한 방법은 모델에게 단일 토큰으로 끝내도록 요청하고, 그 결과를 파싱하며, 혹시라도 'not'이 포함되진 않았는지 확인하거나 전체 내용을 유효하지 않은 JSON 블록 안에 감싸지 않기를 바라는 것입니다.
이러한 워크플로우는 취약하지만, 그 기저의 직관은 타당합니다. 팀들은 보통 산문(prose)을 원하지 않습니다. 그들이 원하는 것은 분기 처리할 수 있는 값입니다. 지원 티켓은 청구서 문제이거나 그렇지 않거나 둘 중 하나입니다. 리뷰는 5점 만점에 4점입니다. 들어오는 요청은 빠른 경로로 라우팅해도 안전하거나 사람이 필요합니다. 실제로 소비하는 출력이 레이블, 점수 또는 확률일 때, 그 사이에 있는 산문은 생성하는 데 비용을 지불하고 다시 제거하는 데 또다시 비용을 지불해야 하는 오버헤드입니다.
흥미로운 깨달음은 이것이 프롬프팅 기술의 문제가 아니라는 것입니다. '예' 또는 '아니요'라는 단어만으로 응답하라고 아무리 요청해도, 생성 모델을 신뢰할 수 있는 분류기(classifier)로 만들지 못합니다. 왜냐하면 모델은 여전히 토큰을 생성하고 사용자는 그것들을 손으로 의미로 디코딩하기 때문입니다. 실패 모드는 계약 자체에 내재되어 있습니다. 텍스트를 요청했고 텍스트를 받았으며, 그 텍스트의 단 한 부분만 필요하다는 사실 자체가 해결해야 할 문제입니다.
타입 기반 결정(typed decision)은 이 계약을 역전시킵니다. 사용자는 고정된 스키마 내에서 질문을 미리 지정하고, 모델의 임무는 요청한 각 질문에 대해 확률, 레이블, 점수를 반환하는 것입니다. 파싱할 단락도 없고, 산문으로부터 구출해야 할 JSON도 없으며, 조립할 스트리밍 토큰도 없습니다. 한 번의 요청으로 단일 텍스트에 대한 최대 스무 가지 질문을 하고, 응답은 if 문이나 라우팅 테이블에 직접 공급할 수 있는 구조화된 값으로 돌아옵니다.
이것이 바로 Jev AI입니다. Jev는 TypeSafe AI의 System One 의사결정 모델로, 2026년 9월 초기에 얼리 액세스로 출시되었습니다. 이것은 채팅 모델이 아니며 그렇게 되려고 시도하지 않습니다. 텍스트에 대한 유형화된 질문에 답하고 확률, 레이블 및 점수를 반환합니다. 프롬프트 튜닝(prompt tuning)도 없고, 대화도 없고, 유도하는 과정도 없습니다. 질문 유형—예/아니오 판단(noul), 카테고리 간의 choice, 또는 숫자 score—을 선언하면 모델이 답변을 채웁니다.
유형화된 결정이 여러분의 문제에 적합한지 확인하는 가장 저렴한 방법은 엔드포인트(endpoint)를 건드리기 전에 수동으로 실행해보는 것입니다. 플레이그라운드는 바로 이런 것을 위해 구축되었습니다: 텍스트 조각을 붙여넣고, 질문 한두 개를 정의한 다음, 돌아오는 레이블과 확률을 확인합니다. 이것을 설계 연습처럼 다루세요. 만약 여러분이 신경 쓰는 결정을 명확한 예/아니오, 선택지, 또는 점수로 표현할 수 없다면, 그것은 실제로 요약(summarization)이나 초안 작성 작업에 분류기(classifier)를 붙이려 했다는 신호입니다.
여기에서 첫 번째 결정을 플레이그라운드에서 시도해보세요. 새 계정에는 소량의 환영 크레딧이 지급되므로, 비용을 지출하기 전에 몇 가지 실제 예시와 비교하여 답변의 형태를 검증할 수 있습니다. 이 체험판은 생산 볼륨(production volume)을 무료로 실행하기 위한 것이 아니라 출력 형태를 확인하는 데 존재합니다—TypeSafe는 2026년 9월 후반에 신규 가입자에게 무료 크레딧 지급을 중단했으며, 무료 등급은 생산 계획이 아닌 플레이그라운드 체험판입니다. 그 차이를 알고 들어가세요.
이 다섯 분짜리 확인 과정의 가치는 주로 여러분 자신의 명세화(specification)에 관한 것입니다. API를 호출하기 전에 20개의 후보 질문을 작성하고 서로 점수를 매겨보세요. 이런 종류의 작업에서 어려운 부분은 결코 모델 호출 자체가 아니었습니다. 그것은 '상향 조정(escalate)'이 여러분의 비즈니스에서 무엇을 의미하는지, 그리고 두 카테고리가 하나의 질문으로 모호할 만큼 충분히 겹치는지 결정하는 것입니다. 구조화된 답변은 그 모호성을 즉시 드러내는데, 왜냐하면 단락 속에 숨길 수 없기 때문입니다.
결정(decision)이 지정되면 모델 선택은 주로 결정론적(determinism) 방식과 최신성(currency) 방식 중 어떤 것을 택할지에 달려 있습니다. 고정된 기본값(pinned default)은 jev-1.13이며, 순환 별칭(rolling alias)은 jev-latest입니다. Pinning을 사용하면 배포 시 임계값 하에서 동작이 조용히 변경되는 것을 막아주는 고정 모델을 얻을 수 있습니다. 반면, 별칭(alias)은 업데이트를 추적하지만 버전 관리 규율 없이 프로덕션 라우팅에 의존해서는 안 되는 것입니다. 컨텍스트 길이는 32,000 토큰이며, 단일 엔드포인트는 /api/v1/systemone/으로 POST 요청을 보냅니다. 두 모델 옵션의 자세한 내용은 Jev AI Model에서 확인할 수 있습니다.
여기서 지연 시간(Latency)이 중요한 이유는 타입 기반 결정이 보통 동기식 경로에 위치하기 때문입니다. 예를 들어, 티켓 분류 단계, 다른 LLM 호출 전의 가드레일, 또는 사람이 검토하기 전에 필터링하는 과정 등이 이에 해당합니다. 홈페이지에서는 중앙값 상류 응답 시간을 약 0.22초로 보고하며, 문서는 일반적인 지연 시간을 약 0.2초로 설명하고 있습니다. 이는 백그라운드 작업보다는 요청 내부나 짧은 파이프라인 내에서 발생하는 결정에 적합한 범위입니다.
API 키를 서버 비밀(server secret)처럼 취급해야 합니다. 실제로도 그렇습니다. 키는 설정(Settings)에서 생성되며, 단 한 번만 표시되고 sk-glm5-로 시작합니다. 만약 이 키가 브라우저 번들이나 클라이언트 측 로그에 나타난다면 즉시 순환(rotate)시켜야 합니다. 분기 처리하고 싶은 결정은 브라우저 안에 있는 것이 아니라 자체 서비스 경계(service boundary) 뒤에 있어야 합니다.
가격 모델을 이해하는 것은 비용 추정 전에 알아두면 좋습니다. 입력 토큰에 대해서만 비용을 지불하며, 출력 토큰은 무료이고, 연간 플랜은 월별 요금의 약 절반입니다. 가장 낮은 공개 예시 실행 비용은 소수점 몇 센트부터 시작합니다. 이러한 구조는 라벨(labels)이 아닌 전송하는 텍스트에 대해 청구하기 때문에 대량 분류(high-volume classification)에 유리합니다.
이 모든 것이 마법은 아니며, 이것이 무엇이 아닌지 명확히 하는 가치가 있습니다. 이 모델은 설명(explanation), 요약(summary) 또는 초안(draft)이 필요할 때 사용하는 모델이 아닙니다. 대신 레이블, 점수 또는 단락 대신 확률이 필요할 때 사용하는 모델입니다—예를 들어, 지원 티켓 분류(support-ticket triage), 콘텐츠 조정(content moderation), 의도 라우팅(intent routing), 리뷰 및 리드 점수화(review and lead scoring), 다른 LLM 호출 전의 가드레일(guardrails), 인용 확인(citation checks), 이력서 심사(résumé screening) 등입니다. 이러한 사용 사례들 전반에 걸쳐 공통적인 특징은 하나입니다: 어느 다운스트림 지점에서든 코드가 그 답변을 기반으로 분기된다는 것입니다.
타입 기반 결정(typed decision)의 가장 큰 이점을 얻는 팀들은 분류(classification)를 프롬프팅 문제로 취급하는 것을 멈춘 팀들입니다. 그들은 질문을 명시하고, 모델을 고정하며, 핵심 로직을 서버에 유지하고, 단락이 사라지도록 합니다. 남는 것은 숫자, 레이블, 그리고 확률—그들의 코드가 기다리던 바로 세 가지 요소입니다.
