우리는 LLM을 모든 AI 문제, 심지어 단순한 의사결정에도 망치처럼 사용해 왔습니다. Jev는 이러한 결정을 밀리초 단위에 훨씬 저렴한 비용으로 처리합니다. 작동 방식과 활용 범위를 살펴봅시다.
TypeSafe AI는 2026년 9월 15일 Jev를 출시했으며, 대화나 코드 작성, 유용한 문단 생성이 불가능한 모델임에도 불구하고 이례적으로 뜨거운 반응을 얻었습니다.
사실, 그 한계가 바로 핵심입니다.
대부분의 소프트웨어에는 또 다른 챗봇이 필요하지 않습니다. 수천 개의 작은 판단이 필요할 뿐입니다. 예를 들어: 이 티켓은 긴급한가? 이 요청은 어떤 모델이 처리해야 하는가? 이 셸 명령어는 위험한가? 검색된 지문이 질문에 대한 답을 포함하고 있는가?
팀들은 종종 각 판단을 범용 LLM에 보냅니다. 모델은 토큰 단위로 답변을 생성하고, 애플리케이션은 이를 파싱하고 검증하며, 형식이 잘못되면 재시도합니다. 이는 작동하지만, 다섯 가지 가능한 답변 중 하나를 선택하는 결정에는 느리고 비쌉니다.
Jev는 정확히 이러한 결정을 위해 설계되었습니다. TypeSafe는 이를 'System One' 모델이라고 부릅니다: 비구조화된 상태가 입력되면, 타입이 지정된 답변과 확률이 출력됩니다.
그 의미가 무엇인지, 어디에 적합한지, 그리고 마케팅에서 어느 정도의 절제가 필요한지 자세히 살펴보겠습니다.
Jev가 해결하려는 문제
툴 호출(tool calling)과 구조화된 출력(structured outputs)이 도입되면서 LLM을 소프트웨어에 연결하기가 훨씬 쉬워졌습니다.
툴 호출은 모델이 예측 가능한 형태로 함수를 요청할 수 있게 합니다. 구조화된 출력은 스키마를 따르는 JSON을 반환할 수 있게 합니다. 둘 다 취약한 파싱 작업의 상당 부분을 제거했습니다.
하지만 underlying model(기저 모델)은 여전히 생성형입니다. 답변이 "billing*"이라는 단어 하나뿐인 경우에도 토큰을 순차적으로 생성합니다. 입력 비용을 지불하고, 생성을 기다리며, 출력에 대해 더 많은 비용을 지불하는 경우가 많습니다.
이제 이를 에이전트 루프 안에 넣어보겠습니다.
1while not done:2 action = llm(context)3 result = run_tool(action)4 context += result
모델은 툴을 선택하고, 결과를 판단하고, 위험을 감지하고, 작업 완료 여부를 결정하고, 다음 모델을 선택하기 위해 다시 호출될 수 있습니다. 단일 에이전트 실행에는 산문(prose) 생성이 필요하지 않지만 판단이 필요한 여러 호출이 포함될 수 있습니다.
Jev는 이러한 호출을 목표로 합니다.
그들의 베팅은 간단하다: 코드가 이미 가능한 답변을 알고 있다면, 언어 생성은 잘못된 인터페이스다.
Jev의 실제 정체
가장 짧고 정확한 설명은 '의미적 의사결정 엔진(semantic decision engine)'입니다.
Jev에 두 가지를 보냅니다:
- State: 현재 상황을 설명하는 텍스트 또는 JSON.
- Questions: 해당 상태에 대해 내리길 원하는 결정들.
모든 질문은 사전에 답변 형태(answer shape)를 선언합니다. Jev는 세 가지 기본 요소(primitives)를 지원합니다:
- Choice: 사용자가 정의한 목록에서 하나의 옵션을 선택하고 모든 옵션에 대한 확률을 반환합니다.
- Score: low, medium, high와 같이 사용자가 정의한 순서화된 척도에 입력 값을 배치합니다.
- Noul: 참일 확률을 반환하여 예/아니오 질문에 답합니다.
Noul은 TypeSafe가 불리언(Boolean) 스타일 기본 요소를 부르는 이름입니다. 독특한 이름보다 출력 값(코드가 처리할 수 있는 0과 1 사이의 숫자)이 더 중요합니다.
1{2 "model": "jev-latest",3 "state": "The deploy failed twice and customers are seeing 500s.",4 "questions": {5 "urgent": {6 "type": "noul",7 "instructions": "Does this need attention right now?"8 },9 "owner": {10 "type": "choice",11 "instructions": "Which team should handle this?",12 "criteria": {13 "engineering": "Product failures and outages",14 "billing": "Charges, invoices, and refunds",15 "sales": "Pricing and new accounts"16 }17 }18 }19}
응답에는 긴급성 확률과 세 팀에 대한 확률 분포가 포함됩니다. 해석할 문단도 없고, 모델이 만들어낼 네 번째 팀도 없습니다.
프로그램이 제어권을 유지합니다:
1if urgent > 0.9 and owner == "engineering":2 page_on_call()3elif confidence < 0.6:4 send_to_human_review()5else:6 add_to_queue(owner)
이것이 사람들이 Jev를 '스마트 switch statement'라고 부르는 이유입니다. 이 표현은 폄하하는 것처럼 들릴 수 있지만, 디자인의 유용한 부분을 잘 포착합니다. 일반 코드는 분기(branch)를 소유합니다. 모델은 일반 코드가 신뢰성 있게 계산할 수 없는 모호한 판단(fuzzy judgment)을 제공합니다.
LLM과의 중요한 차이점
전통적인 LLM과 Jev 모두 지원 티켓을 분류할 수 있습니다. 하지만 도달하는 방식이 다르고 시스템의 서로 다른 부분에서 유용합니다.
TypeSafe는 Jev가 요청 내의 모든 질문을 병렬로 평가한다고 말합니다. 이는 워크플로우 설계 방식을 바꿉니다. 하나의 질문을 하고, 기다리고, 다음 질문을 결정하는 대신, 동일한 상태에 대한 모든 독립적인 질문을 한 번의 요청으로 보내고 코드가 필요한 답변만 사용할 수 있습니다.
회사는 엔드투엔드 지연 시간이 70~500밀리초이며, 입력 토큰 백만 개당 $0.042이고 출력은 무료라고 보고합니다. 주요 주장으로는 유사한 LLM 워크플로우 대비 약 200배 빠르고 400배 저렴하다고 합니다.
이러한 큰 배수 차이는 TypeSafe 자체의 워크플로우 평가에서 나온 것이며 비교의 유리한 끝에 위치합니다. 이를 모든 애플리케이션에 대한 약속이 아닌 상한선으로 간주하십시오. Jev가 제한된 의사결정을 위해 설계되어 긴 추론 추적(reasoning traces)과 생성된 출력을 피한다는 근본적인 이점은 여전히 신뢰할 만합니다.
확률이 중요한 이유
타입이 지정된 답변은 문제의 절반만 해결합니다.
Jev가 티켓을 billing으로 라우팅했다고 가정해 봅시다. 선택된 레이블은 무엇이 이겼는지 알려줍니다. 확률 분포는 경기가 얼마나 치열했는지 알려줍니다.
1{2 "choice": "billing",3 "probabilities": {4 "billing": 0.52,5 "technical": 0.46,6 "sales": 0.027 },8 "confidence": 0.189}
이 티켓을 자동으로 라우팅하는 것은 무모할 것입니다. Billing이 이겼지만, 근소한 차이였습니다. 낮은 신뢰도의 답변은 다른 분기를 트리거해야 합니다.
이는 개발자에게 실용적인 패턴을 제공합니다:
- 높은 신뢰도: 결과가 미미할 때 자동으로 조치.
- 중간 신뢰도: 확인을 요청하거나 더 강력한 모델을 호출.
- 낮은 신뢰도: 케이스를 사람에게 보내거나 추가 정보를 수집.
임계값(thresholds)은 검토하고 변경할 수 있는 코드에 있어야 합니다. 대시보드 레이블은 약한 예측을 용인할 수 있습니다. 데이터를 삭제하는 명령어는 훨씬 더 높은 기준을 요구해야 합니다.
TypeSafe는 RLCD(Reinforcement Learning for Calibrated Decisions)를 사용하여 Jev를 학습시킵니다. 목표는 수많은 예측에 걸쳐 신뢰도가 정확도를 반영하도록 하는 것입니다. 모델이 일련의 답변에 90퍼센트의 확률을 부여하면, 그 답변의 약 90퍼센트가 맞아야 합니다.
환각(hallucination) 주장은 정밀함이 필요하다
TypeSafe는 Jev가 환각을 일으킬 수 없다고 말합니다. 이 주장은 좁은 정의 하에서만 참입니다.
Jev는 스키마 밖의 옵션을 반환할 수 없습니다. billing, technical, sales를 정의했다면 응답은 legal을 만들어낼 수 없습니다. 또한 코드가 레이블을 예상한 곳에서 잘못된 산문을 생성할 수도 없습니다.
하지만 유효한 옵션 중 잘못된 것을 자신 있게 선택할 수는 있습니다.
타입 안전성은 잘못된 형태(invalid shapes)를 방지합니다. 올바른 판단을 보장하지는 않습니다. 스키마상 유효한 실수는 여전히 잘못된 고객에게 환불하거나, 사고를 잘못 라우팅하거나, 위험한 명령어를 승인할 수 있으므로 이 구분이 중요합니다.
더 안전한 표현은 "Jev는 선언된 출력 스키마를 깨뜨릴 수 없지만, 여전히 틀릴 수 있다"입니다.
에이전트 내부에서 Jev의 위치
Jev는 LLM을 대체하는 것이 아니라 함께 사용될 때 가장 잘 작동합니다.
LLM은 언어가 필요하거나 더 깊은 추론이 필요한 작업을 처리합니다. 계획 수립, 작성, 설명, 툴 사용을 담당합니다. Jev는 그 작업을 둘러싼 빈번한 의사결정을 처리합니다.
세 가지 배치 방식이 특히 매력적입니다.
모델 라우팅
간단한 조회는 아키텍처 리뷰와 같은 모델을 필요로 하지 않습니다. Jev는 요청을 점수화하고 완성에 필요한 가장 저렴한 모델을 선택할 수 있습니다.
1route = jev.choice(2 state=user_request,3 options={4 "fast": "Lookups, extraction, and small local edits",5 "powerful": "Architecture, ambiguity, and high-stakes work",6 },7)89model = fast_model if route == "fast" else powerful_model
라우터는 요청에 답하지 않습니다. 어떤 모델이 답해야 할지 결정합니다.
툴 리스크 게이팅
에이전트가 셸 명령어를 실행하기 전에, Jev는 이를 읽기 전용(read-only), 되돌릴 수 있음(reversible), 파괴적(destructive)으로 분류할 수 있습니다. 별도의 질문으로 파일 삭제 여부, Git 히스토리 변경 여부, 프로덕션 환경 접촉 여부, 저장소 이탈 여부를 확인할 수 있습니다.
높은 신뢰도의 읽기 전용 작업은 계속 진행할 수 있습니다. 파괴적이거나 불확실한 작업은 인간 승인을 위해 일시 중지할 수 있습니다. LangChain의 Jev 통합은 실행 전 툴 호출을 확인하는 미들웨어를 통해 이 패턴을 적용합니다.
검증 및 감독
에이전트는 테스트가 아직 실패하고 있는데도 작업이 완료되었다고 주장할 수 있습니다. Jev는 상태를 검사하고 제한된 질문에 답할 수 있습니다: 테스트가 통과했는가? 에이전트가 같은 행동을 반복하고 있는가? 출력이 정책을 따르는가? 이 결과는 검토되어야 하는가?
하드 테스트가 존재할 때 이를 대체하지는 않습니다. 규칙이 의미에 의존하는 곳에서 시맨틱 체크를 추가합니다.
오늘날 Jev가 해결할 수 있는 문제들
최적의 사용 사례는 세 가지 특성을 공유합니다. 가능한 답변을 명명할 수 있고, 신중한 인간이 입력을 빠르게 판단할 수 있으며, 지연 시간이나 비용이 중요해질 만큼 의사결정이 자주 발생합니다.
지원 및 운영
- 의도, 긴급성, 부서, 스팸, 고객 불만을 분류.
- 몇 가지 작은 검사를 통해 환불 및 정책 예외 처리 라우팅.
- 사람이 읽기 전에 로그와 사고를 시맨틱 심각도로 순위 매기기.
단일 요청으로 동일한 티켓에 대해 이 모든 질문을 할 수 있습니다. 코드는 이후 답변을 회사의 실제 라우팅 정책에 결합합니다.
검색 및 검색 증강(RAG)
- 쿼리에 답하는지에 따라 검색된 지문을 재정렬(rerank).
- 인용문이 주장을 뒷받침하는지 확인.
- 비싼 LLM에 컨텍스트를 보내기 전에 관련 없는 청크(chunk) 필터링.
임베딩(embeddings)은 시맨틱하게 관련된 텍스트를 찾는 데 탁월합니다. Jev는 특정 지문이 이 질문에 유용한지라는 더 좁은 의사결정을 내릴 수 있습니다.
품질 및 안전성
- 탈옥(jailbreak)이나 프롬프트 인젝션을 위해 프롬프트 스크리닝.
- 정책이나 채점 기준(rubric)에 대해 생성된 콘텐츠 확인.
- 실행 전에 위험한 코드 변경 사항이나 툴 호출 플래그 지정.
이러한 검사는 결정적 통제(deterministic controls) 옆에 있어야 합니다. 시맨틱 분류기는 모호한 위험에 유용한 반면, 권한, 샌드박스, 테스트는 소프트웨어가 정확히 검증할 수 있는 규칙을 강제합니다.
대량 분류
- 문서, 연구 논문, 제품 목록, 고객 메시지 라벨링.
- 자유 텍스트를 전통적인 머신러닝 모델용 기능(features)으로 변환.
- 대규모 코퍼스(corpus)의 모든 항목을 동일한 채점 기준으로 점수화.
여기서 낮은 호스팅 비용은 벤치마크 수치 이상으로 중요해집니다. 모든 행에 대해 실행하기에 너무 비쌌던 판단이 일반적인 데이터 파이프라인으로 이동할 수 있습니다.
실시간 인터페이스
- 알려진 페이지 요소에서 다음 브라우저 동작 선택.
- 사람이 작성하는 동안 어조(tone)나 명확성 점수화.
- 구조화된 게임 또는 시뮬레이터 상태에서 동작 선택.
Jev는 현재 텍스트 전용이므로 이러한 시스템은 먼저 환경을 텍스트나 JSON으로 변환해야 합니다. 화면을 보거나 픽셀로부터 플레이하는 것이 아닙니다.
Jev가 부적절한 선택인 경우
답변 공간이 더 이상 알려져 있지 않으면 Jev의 유용성은 급격히 떨어집니다.
- 응답 작성, 문서 요약, 코드 생성, 추론 설명을 할 수 없습니다.
- 산술, 카운팅, 날짜 비교, 정확한 문자열 조작에는 신뢰성이 낮습니다. 이러한 연산은 코드에 남겨두십시오.
- 결정에 여러 단계의 숨겨진 추론이 필요할 때 어려움을 겪습니다. 판단을 더 작은 질문으로 나누거나 추론 모델을 사용하십시오.
- 알 수 없는 값을 직접 추출할 수 없습니다. 후보 값을 먼저 찾은 후, Jev가 그중에서 선택하게 하십시오.
- 관련 없는 컨텍스트는 정확도를 떨어뜨릴 수 있습니다. 결정에 필요한 최소한의 상태만 보내십시오.
- 클로즈드 웨이트(closed weights), 얼리 액세스(early access), 텍스트 전용 입력, 제한된 독립적 캘리브레이션 데이터는 맹목적 신뢰를 하기에는 시기상조임을 시사합니다.
더 간단한 규칙도 있습니다: 결정적 코드가 이미 문제를 올바르게 해결한다면 코드를 유지하십시오. 일반적인 if 문은 어떤 모델보다 빠르고 저렴하며 테스트하기 쉽습니다.
새로운 실패 모드를 만들지 않고 Jev 사용하는 법
저렴한 모델이라도 실수가 재시도, 수동 검토, 프로덕션 사고를 유발하면 여전히 비쌀 수 있습니다. 토큰 가격이 아닌 전체 워크플로우를 측정하십시오.
합리적인 롤아웃은 다음과 같습니다:
- 명확한 가능한 답변을 가진 제한적이고 저위험인 의사결정 하나를 선택하십시오.
- 모델을 호출하기 전에 채점 기준(rubric)을 작성하십시오. 모든 옵션에 무엇이 속하는지 정의하십시오.
- 모호하고 적대적인(adversarial) 케이스를 포함하여 기대 답변이 있는 대표 예제를 수집하십시오.
- 현재 워크플로우 옆에서 Jev를 그림자 모드(shadow mode)로 실행하되, 동작을 변경하지 마십시오.
- 정확도와 신뢰도를 플롯(plot)하고 데이터에서 임계값을 설정하십시오.
- 가장 안전한 분기를 먼저 자동화하고 불확실한 케이스에는 사람이나 더 강력한 모델을 유지하십시오.
- 모델 버전, 질문, 기준, 임계값을 고정(pin)하거나 로깅(logging)하여 변경 사항을 동일한 평가 세트에 대해 재생(replay)할 수 있도록 하십시오.
질문은 프로그램의 일부입니다. 코드처럼 취급하십시오: 버전을 관리하고, 검토하고, 모델이나 채점 기준이 변경될 때마다 테스트하십시오.
실제 변화
Jev가 흥미로운 이유는 LLM을 글쓰기에서 이기기 때문이 아닙니다. 글쓰기를 거부하기 때문입니다.
그 공헌은 소프트웨어 모양으로 형성된 모델 인터페이스입니다: 고정된 답변 유형, 명시적 불확실성, 병렬 질문, 코드 제어 분기.
이로 인해 생성형 모델의 유용한 동반자가 됩니다. LLM은 계획, 설명, 코드를 생성합니다. Jev는 요청을 라우팅하고, 위험한 동작을 게이트(gate)하며, 결과를 확인하고, 불확실성이 에스컬레이션할 정도로 높은지 결정합니다.
다른 모델이 결국 Jev를 대체하더라도 더 넓은 아이디어는 중요합니다. 우리는 수년간 생성형 모델에게 텍스트를 통해 모든 종류의 지능을 수행하도록 요구해 왔습니다. 많은 프로덕션 시스템에는 더 많은 단어가 필요하지 않습니다. 일반 소프트웨어가 안전하게 사용할 수 있는 작고 빠른 판단이 필요합니다.
Jev가 구축하려고 하는 카테고리가 바로 이것입니다.
시작 위치
Jev 중심으로 에이전트를 재구축하는 것부터 시작하지 마십시오. 현재 느린 LLM 호출이나 계속 깨지는 정규식(regex)이 필요한 의사결정 하나를 찾으십시오.
Jev에 최소한의 상태를 주고, 가능한 답변을 정의하며, 현재 결과 옆에 확률을 로깅하십시오. 전체 워크플로우를 맡기기 전에 하나의 분기를 받을 자격이 있음을 증명하게 하십시오.
가장 유용한 멘탈 모델은 여전히 가장 단순한 모델입니다 → Jev는 일반 if 문이 값은 이해하지만 그 의미를 이해하지 못하는 곳에 판단을 추가합니다.
출처 및 추가 자료
읽어주셔서 감사합니다.
다음 글에서 뵙겠습니다.
건승! :)
