Jev 활용법 — 생성은 Claude에, 반복 판단은 전용 모델에 맡기는 설계

고객 문의 200건을 읽고 담당 부서를 정하는 작업을 생각해 보겠습니다. 필요한 결과는 대부분 짧습니다. ‘결제팀’, ‘기술지원팀’, ‘사람 검토’처럼 다음 처리 경로를 정하면 됩니다.

이런 작업에서도 매번 긴 설명을 생성해야 할까요? 결과물을 만드는 일과, 정해진 기준으로 분류하고 선택하는 일을 나누면 다른 설계를 시도할 수 있습니다.

Claude Code로 분류 앱을 만들고, 앱 안에서 반복되는 판단은 Jev에 맡기는 방식입니다. 여기서 살펴볼 부분은 모델 조합 자체보다 어떤 판단을 자동화하고, 어떤 경우에 사람이 확인하도록 할 것인가입니다.

Jev는 어떤 결과를 반환하나요

Jev는 TypeSafe AI의 판단 모델입니다. 주어진 자료와 질문을 바탕으로 선택지, 평가 점수, 참·거짓에 대한 확률처럼 애플리케이션이 처리할 수 있는 구조화된 결과를 반환합니다. Vercel 공식 문서에서는 이를 Choice·Score·Boolean 질문으로 설명합니다. Vercel — Jev 소개

예를 들어 고객 문의 하나를 두고 다음 질문을 나눌 수 있습니다.

질문	필요한 결과
어느 부서가 처리해야 하는가?	정해진 부서 중 하나 선택
업무에 미치는 영향은 어느 정도인가?	기준에 따른 심각도 평가
고객이 환불을 요청했는가?	참·거짓에 대한 확률

답변 문장이 필요한 경우에는 생성형 모델을 사용하고, 분류 결과가 필요한 경우에는 판단 모델을 검토하는 것입니다. 생성형 모델도 분류를 수행할 수 있으므로, 실제 선택은 같은 자료에서 품질·지연·비용을 비교해 결정해야 합니다.

생성과 판단 및 실행 규칙을 나누세요

실무에서는 두 모델의 역할뿐 아니라, 일반 코드가 책임질 부분도 함께 구분하는 편이 좋습니다.

담당	맡길 일	예시
Claude 같은 생성형 모델	글·코드·설명 작성	분류 앱 구현, 고객 답변 초안
Jev 같은 판단 모델	문맥을 해석해 분류·평가	담당 부서, 요청 의도, 누락 항목 판단
애플리케이션 코드	확정된 조건과 실행 규칙 적용	허용 부서 확인, 중복 처리 방지, 권한 검사

“고객이 화가 났는가?”는 문맥 해석이 필요합니다. 반면 “요청 금액이 내부 한도를 초과했는가?”는 금액과 한도가 있다면 코드로 비교할 수 있습니다.

이처럼 해석이 필요한 질문만 모델에 맡기고, 명확한 규칙은 코드로 처리하는 구조가 문제 원인을 찾기에도 유리합니다. Vercel — Jev·일반 코드·생성형 모델의 역할 구분

고객 문의를 분류하고 애매한 건 검토로 보내기

영상의 고객 문의 사례에서는 이메일 200개를 대상으로 담당 팀, 긴급도, 환불 요청 여부를 판단합니다.

이때 질문을 하나로 합치지 않는 것이 중요합니다. 담당 부서가 명확하더라도 긴급도는 불분명할 수 있고, 환불 요청과 기술 문제가 한 문의에 함께 들어올 수도 있기 때문입니다.

다음은 업무에 맞게 수정해 사용할 수 있는 질문 설계 예시입니다.

[담당 부서]
이 문의의 주된 문제를 해결할 부서를 선택한다.

- 결제: 청구 금액, 중복 결제, 결제 수단 문제
- 기술지원: 오류, 기능 장애, 접속 문제
- 계정: 계정 정보, 이용 권한, 계정 복구
- 기타: 위 범주에 속하지 않는 문의
- 정보 부족: 담당 부서를 정할 근거가 부족한 문의

[환불 요청]
고객이 실제로 환불을 요구하는가?
환불 정책을 단순히 질문하는 경우와 구분한다.

[업무 영향]
고객의 업무가 중단됐는가?
가능한 우회 방법이 있는지도 함께 평가한다.

‘기타’는 분류 체계 밖의 요청이고, ‘정보 부족’은 판단할 자료가 부족한 상태입니다. 두 결과를 나누면 새로운 부서가 필요한지, 추가 질문이 필요한지 구분하기 쉽습니다.

처리 흐름은 다음처럼 구성할 수 있습니다.

문의 접수
→ 담당 부서·업무 영향·환불 요청을 각각 판단
→ 질문별 수용 기준 확인
→ 허용된 범위에서 자동 배정
→ 정보 부족·분류 충돌·평가 실패는 사람 검토

환불 요청을 감지했다고 실제 환불까지 실행할 필요는 없습니다. 분류 결과를 담당자가 검토할 표시로 활용하는 것부터 시작할 수 있습니다.

이미지와 영상 프롬프트의 누락 항목 찾기

프롬프트 점검 사례는 조명·렌즈 등 필요한 요소가 프롬프트에 포함됐는지 확인합니다.

이 방식의 장점은 작성자가 정한 기준을 여러 프롬프트에 반복 적용할 수 있다는 점입니다.

점검 항목	구체적인 질문
피사체	무엇을 보여줄지 식별할 수 있는가?
조명	광원이나 조명의 방향·분위기가 명시됐는가?
구도	카메라 위치나 화면 배치가 설명됐는가?
움직임	영상에서 필요한 움직임이 지정됐는가?

“좋은 프롬프트인가?”처럼 넓게 묻기보다, 관찰할 수 있는 조건으로 질문을 나누세요.

모든 프롬프트에 같은 체크리스트를 강제할 필요도 없습니다. 제품 사진, 인물 사진, 추상 이미지, 영상은 필요한 정보가 다릅니다. 작업 유형에 맞는 점검표를 먼저 선택하도록 설계하는 편이 좋습니다.

또한 요소가 모두 들어 있다는 사실만으로 결과물의 품질이 보장되지는 않습니다. 누락 점검과 실제 생성 이미지·영상의 검수는 별도 단계로 둡니다.

긴 영상에서 쇼츠 후보 구간 추리기

쇼츠 후보 탐색 사례는 긴 콘텐츠를 약 30초 단위로 나누고, 기준별 평가를 통해 상위 구간을 고릅니다.

실제 도구를 설계할 때는 모델이 무엇을 읽고 평가하는지부터 정해야 합니다. 전사문을 입력했다면 평가 가능한 것은 발언의 내용과 문맥입니다. 표정, 화면 전환, 음향까지 판단한 결과로 해석해서는 안 됩니다. Jev의 입력 범위와 전처리 조건은 공식 문서에서 확인해야 합니다. TypeSafe — System One의 기능과 범위

전사문 기반 후보 탐색이라면 다음과 같은 기준을 시험할 수 있습니다.

도입부에 관심을 끌 만한 질문이나 주장이 있는가?
앞부분을 보지 않아도 내용을 이해할 수 있는가?
구간 안에서 하나의 메시지가 마무리되는가?
원래 발언의 의미를 바꾸지 않고 잘라낼 수 있는가?

고정 길이로만 나누면 문장이 잘릴 수 있습니다. 후보 구간과 함께 앞뒤 문맥을 제공하고, 사람이 원본 영상을 확인하면서 시작·종료 지점을 조정하도록 구성하세요.

평가 점수는 검토 순서를 정하는 도구로 활용합니다. 조회수나 흥행 가능성을 검증한 수치로 받아들이기는 어렵습니다.

많은 기업 중 지원할 후보 좁히기

기업 탐색 사례는 YC 기업 4,322곳을 먼저 평가하고, 상위 100곳을 정밀 검토한 뒤 최종 25곳을 추립니다.

여기서 응용할 만한 부분은 전체 후보를 가볍게 살펴본 뒤 유력 후보에 검토 시간을 집중하는 방식입니다.

다만 필수 조건과 선호 조건은 나눠야 합니다.

조건 종류	예시	처리 방법
필수 조건	반드시 충족해야 하는 근무 지역	불일치 여부를 먼저 확인
선호 조건	관심 산업, 기술 스택	가중치로 순위 조정
미확인 조건	실제 채용 여부, 원격근무 범위	추가 조사 대상으로 표시

원격근무가 필수인데 다른 점수가 높다는 이유로 최종 후보에 포함되면 선별 목적이 흐려집니다. 반대로 정보가 없다는 이유만으로 부적합하다고 확정하면 좋은 후보를 놓칠 수 있습니다.

공개 기업 소개와 실제 채용 공고도 구분해야 합니다. 최종 후보는 회사의 채용 페이지에서 모집 직무, 지역, 지원 조건을 다시 확인해야 합니다.

1차 선별에서 제외한 기업도 일부 표본 검토하세요. 앞 단계에서 놓친 후보는 정밀 평가 단계로 넘어가지 못하므로, 최종 25곳만 검토해서는 누락을 발견하기 어렵습니다.

확률과 confidence를 구분하세요

영상의 ‘60% 이상이면 자동 배정’ 같은 규칙을 적용하려면, 먼저 어떤 값에 기준을 적용하는지 확인해야 합니다.

TypeSafe 공식 문서에서 선택지별 확률과 confidence는 서로 다른 값입니다. 선택지별 확률은 각 선택지에 부여한 값이고, confidence는 그 분포를 요약한 통계입니다. 평가 기준상의 위치를 나타내는 Score 역시 성공 확률과 다릅니다. TypeSafe — Confidence

따라서 기준을 다음처럼 구체적으로 기록하세요.

질문: 담당 부서 선택
사용할 값: 선택된 부서의 확률 또는 Choice confidence 중 하나를 명시
자동 배정 기준: 실제 평가 결과로 결정
검토 경로: 기타·정보 부족·기준 미달
실패 경로: 시간 초과·응답 오류·필수 값 누락

높은 값이 나왔다는 사실만으로 실제 정확도가 보장되지는 않습니다. 사람이 정답을 붙인 별도 표본에서 자동 처리 오류와 검토량을 함께 측정해야 합니다. 질문이나 선택지를 수정한 뒤에도 다시 평가합니다. Vercel — 확률과 임계값 설정 방법

호출료와 검수 시간을 함께 비교하세요

영상 요약에서 소개된 비용 비교는 이메일 200개 처리에 Jev 약 0.005달러, Claude Haiku 약 0.20달러입니다. 이는 제작자가 제시한 사례 수치이며, 현재 요금이나 동일 조건의 성능을 검증한 비교값은 아닙니다.

실제 도입에서는 다음 비용을 합산하는 편이 좋습니다.

전체 처리 비용
= 1차 판단 호출 비용
+ 추가 모델 호출 비용
+ 실패·재시도 비용
+ 사람 검토 시간 × 시간당 비용
+ 잘못된 분류의 수정 비용

호출료가 줄어도 잘못된 배정이 늘어나면 담당자의 일이 많아질 수 있습니다. 현재 가격과 이용 조건은 Vercel Jev 모델 페이지에서 확인하고, 실제 업무 자료로 전체 처리 비용을 비교하세요. 사람 검토 시간과 수정 시간은 중복 합산하지 않도록 기록합니다.

기존 AI API 비용 계산법에서 설명한 모델 라우팅도 같은 관점으로 볼 수 있습니다. 저렴한 단계에서 충분히 처리되는 비율과, 다음 단계로 넘기는 비용을 함께 계산해야 합니다.

작은 시험에서 기록할 항목

직접 기준을 바꿔 보고 싶다면 AI 판단 실습실에서 가상 문의 분류와 사람 검토를 체험해 보세요. 미리 정한 학습용 예제이며 Jev나 다른 실제 모델을 호출하지 않습니다.

처음에는 가상 자료나 비식별 자료로 범위를 좁혀 시험해 보세요. 사람이 먼저 정답과 검토 필요 여부를 표시하고, 모델의 제안과 비교합니다.

최소한 다음 항목은 남기는 것이 좋습니다.

기록 항목	확인하려는 것
자동 처리 비율	전체 업무 중 얼마나 자동화했는가?
자동 처리 오류율	자동 처리한 결과 중 얼마나 틀렸는가?
중요 요청 누락 수	반드시 발견해야 할 사례를 놓쳤는가?
사람 검토 시간	검토 부담이 실제로 줄었는가?
전체 처리 비용	추가 호출과 수정 비용까지 줄었는가?
평가 실패 건수	오류·시간 초과를 어떻게 처리했는가?

자동 처리된 결과에서도 일부를 표본 검토해야 합니다. 검토 대기열에 들어온 사례만 확인하면, 자신 있게 잘못 분류한 결과가 기록에서 빠질 수 있습니다.

판정 기준을 작성하는 방법은 기존 AI 답변 평가표 만들기와 연결해 사용할 수 있습니다.

AI 업무를 설계할 때는 먼저 필요한 결과를 적어 보세요. 문장인지, 분류값인지, 정확한 조건 검사인지 구분하면 맡길 도구도 선명해집니다. Jev는 그중 반복되는 해석과 선택을 시험할 수 있는 도구입니다. 자동 처리할 범위와 사람이 확인할 경로를 함께 정하고, 실제로 줄어든 시간과 오류를 근거로 적용 범위를 넓혀 가세요.

자주 묻는 질문

Q1. Jev를 쓰려면 Claude Code로 앱을 만들어야 하나요?

아닙니다. Claude Code는 이 글에서 앱을 만드는 도구의 예시입니다. 기존 폼 처리나 문서 분류 서비스에서도 Jev를 호출할 수 있습니다. 앱을 만드는 도구와 운영 중 판단을 수행하는 모델은 따로 선택할 수 있습니다. Vercel — Jev 활용 사례

Q2. 환불 요청의 Boolean 확률이 낮으면 무조건 검토해야 하나요?

낮은 값은 질문에 대한 거짓 쪽 판단을 뜻합니다. 예를 들어 ‘환불을 요구하는가?’의 확률이 0에 가까우면 환불 요청이 아니라는 쪽이고, 0.5 근처는 불확실한 상태입니다. 단순히 낮은 값만 검토 대상으로 삼지 말고 참·거짓 양쪽의 오류를 평가하세요. Vercel — 확률과 임계값 설정

Q3. Jev의 분류 결과에서 자세한 판단 이유도 받을 수 있나요?

Jev는 문장이나 추론 설명을 생성하는 모델이 아닙니다. 설명이 필요한 업무라면 원자료와 판정 기준을 검토자가 확인할 수 있게 제공해야 합니다. 별도 생성형 모델로 설명을 작성하더라도 그 문장을 Jev의 실제 판단 과정으로 제시해서는 안 됩니다. Vercel — Jev와 생성형 모델의 역할 구분

Q4. 기업 선별에서 상위 후보만 확인하면 충분한가요?

상위 후보의 적합성과 1차 선별의 누락은 별개입니다. 제외된 후보에서도 표본을 검토하고, 필수 조건이 확인되지 않은 후보는 부적합과 구분하세요. 최종 후보의 실제 채용 공고는 별도로 확인해야 합니다.

공식 자료와 확인 기준일

확인 기준일: 2026-10-15 — 영상 사례는 제공된 요약을 바탕으로 재구성했고, 기능과 반환값 설명은 공식 문서와 대조했습니다. 직접 API를 호출해 성능·비용을 측정한 사용 후기는 아닙니다.