JEV: How It Works and What You Can Build

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

JEV는 문장을 생성하는 대신 선택·점수·확률 형태로 판단을 반환하며, 영상은 이를 활용한 이메일 분류, 모델 라우팅, 브라우저 자동화의 작동 방식과 구현 사례를 소개한다.

📌 핵심 요점

1. Typesafe의 JEV는 언어를 읽고 사전에 정의한 선택지나 척도에 따라 판단하는 모델로 소개된다. 답변 문장을 작성하는 챗봇과 역할이 다르다.
2. 출력은 choice·score·null 세 가지다. 영상에서는 각각 범주 선택, 사용자 정의 척도 평가, 질문에 대한 긍정 확률로 설명한다.
3. 이메일 앱은 500개 메일의 유형, 협찬 가능성, 중요도, 사기 의심 여부를 분석한다. 모델 라우터는 요청에 따라 작은 모델이나 균형형 모델을 선택한다.
4. 공급사 자체 벤치마크로 판단당 약 0.4초와 0.00004의 비용 수치가 제시된다. 속도·비용의 장점은 강조되지만 비교 조건과 실제 정확도는 충분히 제시되지 않는다.
5. 입력 컨텍스트는 64,000토큰으로 소개되며, 후반부에는 주행 의사결정 데모, 거래 판단, 항공편 예약 화면 조작과 모델 접근 방법까지 다룬다.

🧩 배경과 문제 정의

영상은 AI의 활용을 문장 생성에서 반복적인 판단으로 확장하는 문제를 다룬다. 이메일의 유형과 중요도를 구분하거나 요청에 맞는 모델을 고르는 업무는 긴 답변보다 정해진 형식의 결정이 필요하다. 발표자는 Typesafe의 JEV가 이런 판단에 특화됐다고 설명하며, 직접 만든 이메일 앱과 모델 라우터를 중심으로 작동 방식을 보여준다.

핵심 설계 과제는 입력을 어떤 질문으로 평가하고, 어떤 선택지나 척도로 결과를 받을지 정하는 것이다. 영상은 출력 방식과 구조화의 이점, 속도·비용 주장, 컨텍스트 제한을 설명한 뒤 다른 개발자의 사례와 접근 방법으로 마무리한다.

🕒 시간순 섹션별 상세정리

1. 판단에 특화된 JEV와 첫 이메일 데모

• Typesafe가 공개한 JEV를 문장을 쓰지 않고 빠르고 저렴하게 판단하는 모델로 보여준다. 이어 이메일 500개를 분류하고 응답 필요성을 평가하는 앱을 시연한다. [00:58]
• 앱은 500개 처리를 마치고 이메일 유형별 원형 차트를 표시한다. 이는 모델의 판단을 업무 화면으로 구성한 첫 사례다. [01:19]

2. 출시 주장과 모델 라우터의 작동

• 출시 발표를 인용해 RLCD라는 훈련 방식과 판단에 최적화된 모델을 소개하며, 20~200배 빠르고 40~400배 저렴하다는 주장을 전달한다. [02:02]
• JEV가 입력에 따라 사용할 모델을 고르는 에이전트를 시연한다. 단순 인사에는 nano, 앱 제작 방법을 묻는 요청에는 Claude Sonnet 5가 선택된다. [03:12]
• 추가 코드 작성 요청에서도 균형형 모델을 선택하며 신뢰도 95%가 표시된다. 발표자는 자신의 시연에서 frontier 선택을 아직 보지 못했다고 드러낸다. [03:46]

3. 분류의 의미와 언어 모델과의 차이

• 분류는 입력을 미리 이름 붙인 범주에 배치하는 작업이다. 이메일을 고객 질문·협찬·스팸으로 나누는 예를 들어 보여준다. [04:28]
• Typesafe는 회사, JEV는 모델로 구분한다. JEV는 언어를 읽지만 문장을 생성하지 않고 판단과 신뢰도를 반환하므로 출력 토큰 비용이 없다고 보여준다. [05:17]

4. 세 가지 출력과 협찬 가능성 판단

• 출력 유형을 choice·score·null로 보여준다. choice는 사전 선택지, score는 사용자 정의 척도, null은 질문에 대한 긍정 확률로 드러난다. [06:22]
• 이메일에 협찬 기회가 언급됐는지를 묻는 항목을 추가한다. 앱은 긍정 확률을 표시하고, 특정 메일에서 약 90%의 신뢰도를 보여준다. [07:34]

5. 선택지를 이용한 이메일 범주 분류

• 협찬·구독 업데이트·콜드 피치·뉴스레터·agent native라는 다섯 가지 범주를 설정해 choice 출력을 구성한다. [08:10]
• 다시 실행하면 이메일마다 범주와 신뢰도가 표시된다. 앞서 만든 협찬 가능성 항목과 범주 분류가 함께 나타난다. [08:50]

6. 중요도 척도와 이메일 우선순위

• 사용자가 직접 봐야 할 중요도를 평가하도록 질문과 배경 정보를 설정한다. 무시부터 긴급 대응 단계까지 척도를 만들고 각 단계의 의미를 정의한다. [10:04]
• 세 가지 판단을 실행한 뒤 발표자는 약 12~13초 만에 500개 분석이 끝났다고 드러낸다. 결과에는 critical 6개가 표시되며 해당 항목을 눌러 메일을 확인한다. [11:03]

7. 구조화된 출력의 역할

• 기존 LLM도 구조화된 출력을 만들 수 있지만 텍스트 생성과 JSON 형식화가 필요하다고 보여준다. JEV는 구조화된 결과만 반환하도록 만들어졌다는 점을 강조한다. [11:43]
• 발표자는 출력 형식을 맞추기 위한 텍스트 토큰을 쓰지 않는 것이 효율성의 이유라고 주장한다. 이 설명은 출력 구조에 관한 것으로, 개별 판단의 정답 여부를 검증한 결과는 아니다. [12:13]

8. 성능 수치와 상시 정보 분류 구상

• 공급사 자체 벤치마크로 판단당 약 0.4초와 0.00004의 비용 수치를 제시하며, 기존 LLM의 약 10초·3센트와 비교한다. 반복 요청이 많을수록 차이가 커진다고 보여준다. [13:01]
• 이메일뿐 아니라 소셜미디어 메시지·댓글·협찬 제안에도 태그를 붙이고 회사 내 담당자에게 전달하는 활용을 구상한다. [13:38]
• 영상까지 분석하는 멀티모달 모델로 저품질 콘텐츠를 걸러내는 가능성을 언급한 뒤, 이메일 사기 탐지 항목을 직접 추가하기 시작한다. [14:15]

9. 사기 의심 탐지와 개인화 알림

• 사기 또는 신뢰하기 어려운 이메일인지를 묻는 항목을 실행하자 500개 중 55개가 사기로 표시된다. 이는 앱의 판정 결과이며 실제 사기 여부를 따로 검증하는 과정은 나오지 않는다. [15:06]
• 결과별로 54%·71% 등 서로 다른 신뢰도를 확인한다. 발표자는 개인화된 필터가 사기나 콜드 이메일을 걸러주는 알림 방식을 기대한다. [15:35]

10. 컨텍스트 제한과 주행 선택 데모

• 입력 컨텍스트는 64,000토큰으로 묶인다. 발표자는 더 많은 사업 배경을 넣기 위해 컨텍스트가 커질 가능성을 궁금해한다. [16:18]
• 다른 개발자의 주행 데모를 보며 직진·좌회전·우회전 등 미리 정한 선택지에서 행동을 고르는 방식으로 해설한다. 신호등과 보행자를 고려하는 장면도 묶인다. [17:34]

11. 거래 판단과 브라우저 조작 사례

• 주식 입력을 분석해 매수·매도 판단과 신뢰도를 내고 거래하는 사례를 보여준다. 발표자는 매수·매도·보유처럼 출력 선택지가 적고 반복 판단이 필요한 업무와 연결한다. [18:22]
• 브라우저 에이전트가 항공편 예약 화면을 빠르게 채우는 데모를 보여주며, 소개된 화면을 통과하는 데 약 7초가 걸렸다고 보여준다. [18:57]

12. 모델 접근 방법과 실험 권유

• Typesafe 대기 명단과 AI Gateway를 이용하는 접근 경로를 안내한다. Gateway API 키를 확보해 JEV를 사용하는 앱을 만들 수 있다고 보여준다. [19:30]
• 코딩 도구에 JEV 문서를 찾아 앱을 만들도록 요청하는 방식을 제안한다. 마지막에는 직접 시험해 보고 활용 아이디어와 과장 여부에 대한 의견을 남겨 달라고 요청한다. [20:16]

🧾 결론

• JEV의 핵심 활용처는 자유로운 문장 작성보다 반복적인 분류·평가·행동 선택이다.
• 사용자는 판단할 질문, 선택지, 척도와 필요한 배경 정보를 구체적으로 정의해야 한다. 영상의 이메일 앱은 이 설정이 결과를 어떻게 바꾸는지 보여준다.
• 구조화된 출력이 나온다는 설명과 판단 내용이 정확하다는 주장은 구분해야 한다. 데모의 신뢰도 수치만으로 실제 정답률을 확인할 수는 없다.

📈 투자·시사 포인트

• 반복 판단의 단가와 지연시간이 낮아진다면 이메일·댓글·메시지를 지속적으로 분류하고 담당자에게 전달하는 자동화의 적용 범위가 넓어질 수 있다.
• 모델 라우팅은 요청마다 사용할 모델을 선택하는 비용 관리 수단으로 제시된다. 경제성은 라우터 비용과 선택된 모델의 품질을 함께 확인해야 판단할 수 있다.
• 거래 사례는 매수·매도·보유처럼 제한된 선택지를 반복 평가하는 활용 가능성을 보여준다. 영상에는 수익률이나 손실 검증 결과가 없어 투자 성과의 근거로 삼기는 어렵다.
• 브라우저 조작 사례는 빠른 행동 선택의 가능성을 보여주지만, 약 7초라는 수치는 소개된 예약 화면을 통과한 시간이며 전체 예약 업무의 성능을 입증하지는 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 속도·비용 수치는 공급사 자체 벤치마크 인용이다. 비교 모델, 입력 길이, 병렬 처리 조건, 동일 정확도 충족 여부와 판단당 0.00004라는 비용의 통화 단위는 전사만으로 명확하지 않다.
• 이메일 500개 중 55개가 사기로 표시됐지만, 사람이 검증한 실제 사기 건수는 제시되지 않는다. 화면에 표시된 54%·71% 등의 신뢰도가 실제 발생 확률과 얼마나 일치하는지도 알 수 없다.
• 영상에서 null은 긍정 확률을 반환하는 방식으로 설명된다. 정확한 API 명칭과 반환 자료형은 별도 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 이메일 분류나 요청별 모델 선택 중 하나를 골라, 필요한 입력과 반환할 선택지를 먼저 정의한다.
• choice·score·null을 각각 작은 표본에 적용하고, 결과를 사람이 매긴 정답과 비교한다.
• 동일한 입력과 품질 기준으로 기존 LLM 방식과 JEV의 지연시간·비용·오분류를 측정한다.
• 사기 의심이나 중요도 판단은 신뢰도별 실제 오류를 확인한 뒤 자동 처리 기준을 정한다.

❓ 열린 질문

• 표시되는 신뢰도는 실제 정답률과 얼마나 잘 일치하며, 애매한 입력에서는 어떤 기준으로 추가 검토를 요청해야 할까?
• 모델 라우터가 상위 모델을 거의 선택하지 않는 현상은 요청 특성 때문일까, 선택 기준이나 설정 때문일까?
• 사용자와 회사에 관한 배경 정보가 늘어날 때 64,000토큰 안에서 분류 품질을 유지할 수 있을까?