Jev 이해하기 / 예시로 이해하기LLM × JEV 00

00 · Jev 이해하기

내 업무를 나누고,
판단할 자리에 Jev를 넣으세요.

Jev는 TypeSafe의 판단 전용 AI입니다. 업무 중 문맥을 읽어야 하는 판단을 골라, 기준과 답의 형태를 미리 정할 수 있을 때 활용을 검토해 보세요.

업무 입력과 판단 기준을 Jev에 전달하면 예·아니오, 점수, 선택지 형태로 판단합니다. 코드가 이 결과와 업무 규칙에 따라 정해진 안내, LLM 글쓰기, 사람 검토로 연결합니다. 세 출력 형태는 순차 단계가 아닙니다.
입력과 기준은 내가, 판단은 Jev, 다음 행동은 코드가.AI 생성 개념도 · 설계 예시, 실제 응답·측정값 아님 · 눌러서 크게 보기 ↗

이 단계의 답을 ‘예·아니오 / 점수 / 선택지’로 정할 수 있나요?

  1. 1업무 나누기

    접수 → 판단 → 처리
    어디에서 판단이 필요한가?

  2. 2기준·출력 정하기

    무엇을 보고 판단할까?
    어떤 값으로 답을 받을까?

  3. 3다음 행동 연결하기

    값에 따라 코드가 연결
    담당자·정해진 안내·LLM으로

Boolean · 예·아니오

환불을 요청했나요?

기준: 돈을 돌려달라는 의사 표현이 있는가?

예 / 아니오→ 환불 문의인지 구분
Score · 정도

불만이 어느 정도인가요?

기준: 0 차분함 · 1 불만 · 2 매우 강한 불만

0 ─── 1 ─── 2→ 검토 순서를 정하는 참고값
Choice · 목록 선택

어떤 문의인가요?

기준: 고객이 해결을 요청한 주제로 구분

결제 / 배송 / 계정 / 기타→ 해당 담당 팀으로 배정

업무 전체를 맡기기보다, 반복되는 ‘판단 단계’를 맡기는 도구입니다.
모든 단계를 AI로 바꿀 필요는 없습니다. 계산은 코드, 글쓰기는 LLM, 애매하거나 중요한 처리는 사람이 맡습니다.

위는 설계 예시이며 현재 실험 기능이나 실제 출력이 아닙니다. Boolean은 업무에서 쓸 답의 형태입니다. API에서는 예·아니오를 Choice로 고르거나, Noul의 ‘예’일 확률을 받아 앱이 정한 기준으로 처리합니다. Score의 정도 점수는 정답 확률이 아닙니다. 공식 출력 유형 ↗

기준에는 선택지·점수의 의미와 정보 부족 시 처리도 포함하세요. 기준을 정할 수 있다는 것은 도입 후보라는 뜻이지, 정확도·속도·비용 개선을 보장하지는 않습니다.

결국 답장을 쓸 건데, Jev는 왜 필요할까요?

고객 문의로 보겠습니다. 판단 다음에 답장이 필요하다면 LLM이나 사람이 씁니다.

문의를 바꿔보세요
설명용 예시 · 실제 AI 호출 없음
고객이 보낸 문의
“주문한 컵이 깨져서 왔어요. 환불받고 싶어요.”
LLM 단독이 설계는 1회 호출

문장으로 풀어 보면

01
LLM · 원문과 안내 기준 읽기

고객이 무엇을 요청하는지 파악

02 · 내용을 문장으로 정리하면작성자가 만든 요약 · 내부 사고 기록 아님
  • 환불을 요청한 문의입니다.
  • 상품이 파손됐다고 합니다.
  • 주문번호는 적혀 있지 않습니다.
03
LLM · 안내할 답장 작성

원문과 안내 기준에 맞춰 문장을 완성

최종 답장 초안 · 설명용

불편을 겪으셨겠어요. 파손된 상품 사진과 주문번호를 알려주시면 확인에 도움이 됩니다.

문장을 생성하는 모습을 설명 순서로 나눠 보았습니다.

Jev + LLM이 설계는 2회 호출

정해둔 답에서 고르면

01
Jev · 같은 원문과 판단 기준 읽기

Jev도 문장의 뜻을 읽어 판단합니다.

02 · 예·아니오 / 목록에서 선택세 질문을 한 요청에 묶는 예시 · 실제 응답 아님
환불 요청인가요?
  • ✓ 예
  • 아니오
어떤 문의인가요?
  • ✓ 상품 파손
  • 배송 지연
  • 기타
원문에 주문번호가 있나요?
  • 예
  • ✓ 아니오
03
LLM · 선택값을 받아 답장 작성

선택값·원문·안내 기준을 함께 확인

최종 답장 초안 · 설명용

불편을 겪으셨겠어요. 파손된 상품 사진과 주문번호를 알려주시면 확인에 도움이 됩니다.

앱은 짧은 선택값을 받아 씁니다. 답장은 LLM이 작성합니다.

고객이 보낸 문의
“주문한 컵이 아직 안 왔어요. 언제 도착하나요?”
LLM 단독이 설계는 1회 호출

문장으로 풀어 보면

01
LLM · 원문과 안내 기준 읽기

고객이 무엇을 요청하는지 파악

02 · 내용을 문장으로 정리하면작성자가 만든 요약 · 내부 사고 기록 아님
  • 환불 요청은 아닙니다.
  • 도착 일정을 묻는 배송 문의입니다.
  • 주문번호는 적혀 있지 않습니다.
03
LLM · 안내할 답장 작성

원문과 안내 기준에 맞춰 문장을 완성

최종 답장 초안 · 설명용

상품을 기다리고 계시는군요. 주문번호를 알려주시면 배송 상태를 확인하는 데 도움이 됩니다.

문장을 생성하는 모습을 설명 순서로 나눠 보았습니다.

Jev + LLM이 설계는 2회 호출

정해둔 답에서 고르면

01
Jev · 같은 원문과 판단 기준 읽기

Jev도 문장의 뜻을 읽어 판단합니다.

02 · 예·아니오 / 목록에서 선택세 질문을 한 요청에 묶는 예시 · 실제 응답 아님
환불 요청인가요?
  • 예
  • ✓ 아니오
어떤 문의인가요?
  • 상품 파손
  • ✓ 배송 지연
  • 기타
원문에 주문번호가 있나요?
  • 예
  • ✓ 아니오
03
LLM · 선택값을 받아 답장 작성

선택값·원문·안내 기준을 함께 확인

최종 답장 초안 · 설명용

상품을 기다리고 계시는군요. 주문번호를 알려주시면 배송 상태를 확인하는 데 도움이 됩니다.

앱은 짧은 선택값을 받아 씁니다. 답장은 LLM이 작성합니다.

최종 답장만 보면 차이가 거의 없을 수도 있습니다.

같은 문장을 양쪽에 놓은 것은 역할을 설명하기 위한 예시입니다. 실제 두 모델이 같은 답장을 내거나, Jev를 넣으면 품질이 좋아진다는 뜻은 아닙니다.

매번 LLM을 다시 부른다면 Jev 때문에 전체 시간이 더 길어질 수도 있어요. 위 오른쪽 경로는 Jev 판단 시간 + LLM 작성 시간 + 연결·검사 시간이 필요합니다. 도식의 높이는 걸리는 시간을 뜻하지 않습니다.

LLM도 이런 판단을 할 수 있어요. LLM도 분류 값과 답장을 함께 반환할 수 있습니다. Jev는 자유로운 글쓰기 대신 정해진 답과 확률을 반환하는 데 집중합니다. 공식 역할 설명 ↗

차이가 생길 수 있는 지점

모든 건에 새 답장이 필요한 건 아니에요.

판단 뒤 코드가 다음 행동을 나누면, 일부 요청에서는 LLM 글쓰기를 생략할 수 있습니다.

Jev가 의미를 판단 → 코드가 기준 확인

어떤 처리가 필요한 문의인가?

설계 예시 · 현재 실험에는 미구현
준비된 안내로 충분

승인된 문구 사용

“주문번호를 알려주세요.”
새 문장을 만들지 않아도 되는 안내

이 단계의 LLM 호출 없음
상황별 설명이 필요

LLM이 답장 작성

여러 문제가 섞인 문의처럼
원문에 맞춰 설명할 필요가 있는 경우

이 경우에만 LLM 추가 호출
애매하거나 승인 필요

담당자 검토

정책 예외·정보 부족은 보류
환불을 승인하거나 거절하지 않음

사람이 확인 후 최종 처리

위 환불 문의에 적용하면Jev: 환불 요청 예코드: 환불 담당자에게 검토 요청고객에게는 준비된 접수 안내

위 배송 문의에 적용하면Jev: 환불 요청 아니오코드: 일반 상담으로 접수고객에게는 준비된 접수 안내

‘환불 요청’이라는 판단이 곧 환불 승인은 아닙니다. 주문 조회·금액·기한·권한 확인은 코드와 업무 절차가 맡습니다. LLM도 이런 분류·분기 구조에 사용할 수 있으므로, 같은 처리 규칙 아래에서 비교해야 합니다.

위 문의를 바꾸면 담당 경로 예시도 바뀝니다. 실제 조회·전달·발송·환불은 하지 않습니다. 이 설계의 절감 효과는 아직 측정하지 않았습니다.

내 업무에 적용해 보기

업무 속 ‘판단할 자리’를 찾아보세요.

자연어의 뜻을 읽어야 하고, 답의 종류를 미리 정할 수 있고, 같은 판단이 반복될 때 후보가 됩니다. 핵심은 JSON을 만드느냐가 아니라 필요한 정확도를 지키면서 판단 시간·비용을 줄일 수 있느냐입니다.

아래는 활용 아이디어이며 도입 효과를 검증한 사례는 아닙니다.

문의함의 담당 팀 정하기

“접속이 안 돼요” 같은 문장

Jev: 기술 문의 → 코드: 지원팀 대기열
완료 기준은 올바른 배정. 새 답장이 없어도 업무 한 단계가 끝납니다.

설문·리뷰를 주제별로 묶기

“설명은 좋았지만 따라가기 빨랐어요”

Jev: 진행 속도 → 코드: 주제별 집계
문장의 주제는 AI가, 건수·비율 계산은 코드가 담당합니다.

읽을 자료 먼저 추리기

모아둔 글 중 “초보자 실습 안내인가?”

Jev: 관련 있음 / 없음 → 후보 목록
검색은 별도 도구가 담당. 고른 자료의 요약이 필요하면 그때 LLM을 씁니다.

수업 제출물의 검토 보조

“이 설명이 과제 요구에 관련되는가?”

Jev: 관련 / 무관 / 검토 필요 → 교수자 확인
파일 유무·경로는 코드로 확인. 원문과 함께 검토하며 최종 성적을 자동 결정하지 않습니다.

공급자가 제안하는 분류·검색 후보 선별·상담 배정을 바탕으로 만든 교육용 설계입니다. 공식 활용 아이디어 ↗

매번 새 글이 필요하면

LLM 단독부터

메일·강의안·긴 설명처럼 작성 자체가 목적이라면, Jev를 앞에 넣는 이득이 작을 수 있습니다.

정확한 계산·조건이라면

일반 코드로

예산·날짜·정원·시간표 충돌은 모델 판단이 아닌 명확한 계산으로 처리합니다.

복잡하거나 틀리면 큰일이면

자료 확인 + 사람 검토

여러 단계의 추론, 승인·평가처럼 중요한 처리를 Jev 판단 하나에 맡기지 않습니다.

Jev 1.13은 숫자·날짜 비교, 복잡한 간접 추론 등에 알려진 한계가 있습니다. 확률이 높아도 개별 정답을 보장하지 않습니다. 공식 한계 ↗

그럼 시연에서는 무엇을 볼까요?

‘판단 완료’와 ‘업무 완료’를 나눠 보세요.

01 · 문의 분류

판단만 필요할 때

두 경로 모두 유형·우선순위를 고릅니다.

비교: 분류 값 + 기준 라벨 일치 + 시간기본 예제 라벨은 제한된 기준입니다. 여러 다른 문의에서도 확인해야 합니다.
02 · 항공편 선택

선택이 결과일 때

코드로 예산·직항을 확인한 뒤 같은 후보에서 고릅니다.

비교: 선택한 편 + 취향 적합성 + 시간선호는 사람이 평가합니다. 실시간 검색·예약·설명문 작성은 포함하지 않습니다.
03 · 답장 작성

끝까지 글을 써야 할 때

LLM 1회와 Jev → LLM 2회의 최종 답장을 비교합니다.

비교: 최종 문장 + 사실·정책 준수 + 전체 시간현재는 모든 건에서 LLM을 호출합니다. ‘필요한 경우만 생성’하는 분기는 아직 없습니다.

빠른 판단이 곧 빠른 답장은 아닙니다.

같은 원문·업무 기준·완료 지점으로 비교하세요. 03에서는 Jev 첫 응답이 아니라 최종 답장까지의 시간을 봅니다.

  • 틀린 분류·답장은 몇 건?
  • 최종 결과까지 얼마나?
  • 전체 비용·검토 부담은?
비용은 모든 단계의 합계이며 단가가 없으면 미산정입니다. 직접 평가 외에 수정 시간·사람의 검토 부담은 현재 자동 측정하지 않습니다.

조건부 분기의 효과를 보려면 다음 실험이 필요합니다. 동일한 문의 묶음·템플릿·검토 규칙을 두고, LLM 분류기와 Jev 분류기가 각각 글쓰기 호출을 얼마나 줄였는지, 잘못 생략한 답장은 없는지 확인해야 합니다. 호출 수가 줄어도 비용·시간이 반드시 줄지는 않습니다.

비교 화면에서는 수업 문의·항공편·답장 예시를 사용합니다. LLM의 예로 Gemini를 사용하며, 한 모델의 결과가 모든 LLM의 성능을 뜻하지는 않습니다.

더 궁금하다면

개발자는 어떤 값을 받나요?

위 예시는 예 / 아니오 중 하나를 고르는 방식(Choice)입니다. 이 값을 앱이 읽어서 담당자에게 전달할지 정합니다. JSON은 이처럼 값을 주고받는 표기법입니다.

하나 고르기Choice

예 / 아니오, 담당 부서 등

정도 판단하기Score

정해둔 척도에서 불만 정도 등

‘예’일 확률Noul

0~1 사이 숫자로 반환

위 화면은 사람이 이해하기 쉽게 그린 고정 예시이며, 실제 API 응답을 보여주는 화면은 아닙니다.

LLM과 동작 방식도 다른가요?
일반적인 LLM의 출력
문의→를→확인→…

다음 토큰(글의 조각)을 이어서 출력합니다. JSON도 만들 수 있습니다.

TypeSafe가 설명하는 Jev의 출력
환불 요청?불만 정도?담당 부서?

미리 정한 질문들의 답과 확률을 병렬로 출력하도록 설계됐습니다.

TypeSafe는 결정을 내릴 때의 확률을 실제 결과와 맞추는 학습 방식 RLCD를 설명합니다. 이 그림은 공개된 원리의 요약이지, 신경망 세부 구조나 성능을 보장하는 그림은 아닙니다.

판단이 틀릴 수도 있나요?

네. 정해진 답 안에서도 잘못 고를 수 있습니다. 확률·confidence 수치가 높아도 한 건의 정답을 보장하지는 않습니다. 실제 사례로 평가하고, 중요한 처리는 사람이 확인해야 합니다.

Choice·Score의 confidence는 답의 확률이 얼마나 한쪽에 몰려 있는지를 요약한 값입니다. Noul에는 별도의 confidence가 없습니다. 정확한 계산은 코드에, 답장 작성은 LLM에 맡기세요.

Jev 다음에 LLM을 추가하면 호출이 늘어 전체 시간이 더 길어질 수도 있습니다. 처리 정확도·전체 시간·비용을 함께 봐야 합니다.

설명의 근거와 예시 안내

이 페이지의 문의·답장·판단은 설명을 위해 작성한 예시입니다. 실제 API 호출·속도·정확도 측정 결과가 아닙니다.

기존 원리 설명 확인일: 2026-09-24. 역할·활용 아이디어·Jev 1.13 한계는 2026-09-26 재확인했습니다. 공급자의 제안과 직접 검증한 도입 효과는 구분합니다.