Jev는 글을 안 쓰고 판단만 합니다 — 분류는 Jev, 확인은 사람, 초안은 고른 것만

들어가며

온라인으로 홈트레이닝 용품을 파는 작은 회사를 떠올려 보겠습니다. 주말이 지나면 고객 문의가 수백 건 쌓입니다. 매트 두께를 묻는 문의, 배송이 늦다는 항의, 반품 조건 질문, 스팸까지 섞여 있습니다.

담당자 한 명이 아침에 이걸 전부 읽습니다. 급한 것부터 답하고, 정책을 찾아보며 회신을 씁니다. 그러다 점심이 됩니다.

여기에 ChatGPT를 붙이면 어떻게 될까요. 문의를 한꺼번에 넣고 "분류하고 답변 초안까지 써 줘"라고 하면, 답장이 필요 없는 스팸이나 단순 확인 문의에도 초안이 붙을 수 있습니다. 그러면 읽고 버릴 초안이 늘고, 그만큼 시간이 갑니다.

모델이 그 일을 못 해서가 아니라, 모든 건에 초안을 요청했을 때 생기기 쉬운 결과입니다. "이 문의는 무슨 유형인가"라는 판단과 "그래서 뭐라고 답할까"라는 글쓰기를 나누면 이 불필요한 일을 줄일 수 있습니다.

Jev는 이 둘 중 앞쪽, 판단만 맡는 모델입니다. 이 글에서는 Jev가 어떤 모델인지, 분류 기준을 어떻게 정하고 언제 업무에 투입하는지를 정리했습니다. 공식 문서에서 확인한 비용·한계와, 사람이 어느 지점에서 확인해야 하는지도 함께 다룹니다.

먼저 이 글에 나오는 용어 다섯 개만 쉬운 말로 풀어 둡니다.

Jev는 객관식으로만 답하는 모델입니다

보통 AI에게 질문하면 문장으로 답이 옵니다. Jev는 다릅니다. 미리 만든 문항과 선택지를 주면, 그중 하나를 고르거나 단계를 매기거나 예·아니오 확률을 돌려줍니다.

문장은 한 줄도 쓰지 않습니다. TypeSafe 공식 문서는 "텍스트 생성 없음, 파싱 없음"이라고 못 박습니다.

문항은 세 가지 형태로 만듭니다.

Score는 한 단계를 콕 집어 주는 것이 아닙니다. 단계마다 순서대로 번호가 붙고, 답은 그 번호들의 확률 가중 평균입니다. 그래서 두 단계 사이의 소수점 값이 나올 수 있습니다. "보통에 가깝지만 복잡 쪽으로 조금 기울었다" 정도로 읽으시면 됩니다.

Choice는 선택지를 최대 255개까지 둘 수 있고, Score는 2단계에서 10단계 사이로 정합니다. 중요한 점이 하나 더 있습니다. 문의 한 건에 문항 여러 개를 한 번의 요청으로 묶어 보낼 수 있고, 각 문항은 서로 영향을 주지 않고 동시에 평가됩니다. 문의 하나를 넣으면서 "유형은?", "난이도는?", "주문번호가 있는가?", "정책 예외인가?"를 한꺼번에 묻는 식입니다.

같은 자료에 대한 문항을 따로따로 보내면 그 자료에 드는 요금을 문항 수만큼 냅니다. 묶어 보내면 한 번만 냅니다. 공식 문서 예제에서도 이 차이가 비용과 시간 양쪽에 그대로 나타납니다.

원리만 기억하시면 됩니다. 같은 자료에 대한 문항은 한 요청에 묶는다.

💡 GPT나 Claude도 분류하고 표로 정리할 수 있습니다. Jev만 객관식이 되는 것은 아닙니다. 차이는 문장을 만들지 않고 값만 돌려준다는 점, 문항 여러 개를 한 번에 평가한다는 점, 입력 토큰만 과금된다는 점입니다. 그래서 큰 모델을 빼는 것이 아니라 큰 모델 앞에 세우는 분류기로 씁니다.

비용은 어떻게 나가고, 어디까지 믿을 수 있나

문장을 만들지 않으니 단어를 하나씩 이어 붙이는 과정이 없습니다. 그래서 빠릅니다. 제조사도 판단형 문항에서는 기존 모델보다 훨씬 빠르다고 발표했습니다. 다만 그 수치는 제조사 조건에서 잰 것이고, 발표 글 스스로 실제 환경에서는 그보다 낮을 것이라고 적어 두었습니다.

공식 문서 기준 비용과 한도는 이렇습니다.

여기서 짚고 갈 것이 있습니다. 입력 토큰만 과금된다고 해서 비용이 문의 본문 길이로만 정해지는 것은 아닙니다.

문의 본문, 문항, 선택지 설명, 판단 기준까지 요청에 넣은 전체가 입력입니다. 거기에 호출 횟수가 곱해집니다. 기준을 고치고 다시 돌리면 그만큼 다시 과금됩니다.

그래서 비용은 계산으로 어림하지 말고 실제 값을 보셔야 합니다. Jev 응답에는 그 요청이 쓴 입력 토큰 수가 함께 옵니다. 실제 청구액은 TypeSafe 콘솔의 사용량과 청구 화면에서 확인합니다.

한 번에 넣을 수 있는 양에도 한도가 있어서, 긴 문서 수백 장을 통째로 넣는 용도는 아닙니다. 짧은 자료를 대량으로, 문항을 단순하게 만들어 돌리는 모델입니다.

confidence는 정답률이 아닙니다

Jev가 정해진 선택지 안에서만 답한다고 해서 그 답이 맞는다는 보장은 없습니다. Choice와 Score 답에는 0에서 1 사이의 confidence가 붙습니다. Noul에는 붙지 않고, 예일 확률 하나만 옵니다.

confidence는 "여러 선택지 중 하나에 확률이 얼마나 몰렸는가"를 요약한 값입니다. 확률이 한 선택지에 몰리면 높고, 고르게 퍼지면 낮습니다. 정답률이 아닙니다. 확률이 몰렸어도 틀릴 수 있습니다.

공식 문서는 confidence를 세 구간으로 나눠 다르게 다루라고 권합니다. 높으면 자동 처리, 중간이면 확인 후 진행, 낮으면 사람에게 넘기라는 것입니다. 다만 어디에 선을 긋느냐는 일이 잘못됐을 때의 결과에 따라 달라집니다. 같은 문서가 "되돌리기 어려운 일일수록 기준을 높이라"고도 적습니다.

업무에 옮기면 이렇습니다. 문의 유형을 매기는 일은 틀려도 다시 매기면 됩니다. 반면 정책 밖 요청, 정보가 부족한 건, 위험 신호가 있는 건, 환불 결정은 confidence가 높아도 사람이 봅니다.

confidence가 높다고 자동 발송으로 연결하지 않습니다. 높은 값은 "사람이 볼 순서를 뒤로 미뤄도 된다" 정도로만 씁니다.

자주 틀리는 영역

공식 문서는 이 모델이 자주 틀리는 영역을 따로 공개하고 있습니다. 실무에서 바로 부딪히는 것만 추리면 이렇습니다.

그래서 Jev에게는 쉬운 질문을 여러 개 주고, 어려운 계산은 코드에 넘기는 것이 맞습니다. 언어 조건도 있습니다. 공식 문서는 영어에서 정확도가 가장 높고, 한국어를 포함한 CJK 문자는 "처리는 되지만 같은 수준은 아니다"라고 안내합니다. 한국어 문의로 쓰실 거라면 남의 벤치마크가 아니라 내 자료 몇십 건으로 먼저 확인하셔야 합니다.

기본 흐름과 분류 기준을 정하는 법

Jev를 업무에 넣는 방식은 결국 하나의 순서로 정리됩니다.

1. Jev가 분류합니다. 쌓인 자료에 문항을 묶어 던지고, 유형·난이도·확인 필요 여부를 값으로 받습니다.
2. 사람이 표에서 확인하고 고릅니다. 답장이 필요한 건, 급한 건, 애매해서 직접 볼 건을 나눕니다.
3. 고른 건만 큰 모델이 초안을 씁니다. 단순한 건은 값싼 모델, 복잡하지만 정책 안에서 답할 수 있는 건은 상위 모델로 나눌 수 있습니다.
4. 보내기 버튼은 사람이 누릅니다. 초안을 읽고, 정책에 없는 약속이 들어가지 않았는지 보고 발송합니다.

영상에서는 이 흐름을 가상의 홈트 용품 회사 문의로 보여줍니다. Jev가 문의마다 유형과 난이도를 매기고, 단순 문의와 복잡 문의에 서로 다른 GPT 모델을 추천합니다. 매트 길이와 두께를 묻는 문의는 사양 문의라 저가 모델로 충분하고, 미사용 반품 조건 설명은 FAQ 범위를 벗어난 건이라 상위 모델을 추천하는 장면이 나옵니다. 어떤 모델을 짝지을지는 영상의 사례일 뿐입니다.

다만 이 글에서 권하는 순서는 다릅니다. 정책이나 FAQ 밖의 요청, 위험 신호가 있는 건, 정보가 부족한 건은 난이도와 상관없이 먼저 사람에게 갑니다. 앞의 confidence 절에서 사람이 봐야 한다고 한 묶음과 같습니다. 상위 모델이 없는 정책을 대신 채워 주지는 않습니다.

상위 모델이 맡는 것은 사람이 고른 뒤 남는 건 가운데, 복잡하지만 정책이나 FAQ에 근거가 있고 답에 필요한 정보가 갖춰진 건입니다. 정리하면 단순한 건은 싼 모델, 복잡하지만 정책 안에 있는 건은 상위 모델, 정책 밖이거나 정보가 빠진 건은 사람입니다.

이렇게 하면 큰 모델에 보내는 양은 줄어듭니다. 다만 그것만 보고 판단하면 안 됩니다. 분류에서 빠진 건은 없는지, 사람이 표를 검토하는 시간은 얼마나 드는지도 봐야 합니다.

메인 모델이 앞뒤에서 쓰는 시간과 Jev API 요금이 따로 얼마인지도 같이 봅니다. ChatGPT나 Codex 구독으로 쓰는 사용량과, 내가 만든 앱이 API로 부르는 사용량은 과금 방식이 다릅니다. Jev 요금도 기존 구독에 포함되지 않습니다.

분류 기준은 이렇게 정합니다

두 번째 단계를 빼면 안 되는 이유가 여기 있습니다. Jev의 분류가 처음부터 내 기준과 딱 맞지는 않습니다. 기준은 처음에 적고, 틀린 사례를 보며 고칩니다.

처음 기준은 지금 하는 일에서 꺼냅니다. 담당자가 문의를 볼 때 머릿속으로 이미 나누고 있는 갈래가 있습니다. 배송·환불·사용법·기타 같은 유형이 그것입니다.

거기에 "사람이 꼭 봐야 하는 조건"을 따로 문항으로 둡니다. 정책에 없는 요청인가, 주문번호가 빠졌는가, 위협이나 법적 언급이 있는가 같은 것입니다. 유형 문항 하나에 이 조건을 섞지 말고, 조건마다 예·아니오 문항으로 나눕니다.

선택지 설명에는 경계 사례를 적습니다. "환불"이라고만 쓰지 말고 "환불·교환·반품 조건 문의. 배송 지연으로 인한 환불 요구 포함"처럼 씁니다. Jev는 쓴 대로 읽기 때문에, 내가 당연하다고 여긴 조건이 빠지면 그대로 틀립니다.

틀린 사례를 고칠 때는 "현재 분류 / 원하는 분류 / 이유"로 적습니다. 예를 들어 "사용법만 묻는 문의인데 주문번호가 없다는 이유로 사람 확인에 걸렸다"면, 사용법 문의에는 주문번호가 필요 없다는 기준을 추가합니다. 특정 문의 하나만 맞추는 규칙이 아니라 비슷한 문의에도 통하는 규칙이어야 합니다.

이건 모델을 다시 학습시키는 일이 아니라 질문지를 고치는 일입니다. 그래서 비개발자도 채팅으로 할 수 있습니다. 코드를 잘 쓰는 것보다 자기 업무 기준을 문항으로 적고, 틀린 사례를 보며 고치는 일이 출발점입니다.

🎯 이 흐름에서 자동으로 일어나는 것은 분류까지입니다. 발송, 삭제, 환불 승인처럼 되돌리기 어려운 일은 사람이 확인하고 누릅니다. 밤새 혼자 출근하는 직원이 아니라, 아침에 출근했을 때 문의가 유형별로 정리돼 있는 상태를 만드는 도구입니다.

다른 업무로 옮길 때 바뀌는 것

같은 순서를 다른 업무에 옮기면, 바뀌는 것은 "Jev에게 무엇을 물을 것인가"와 "고른 뒤 무엇을 쓸 것인가" 두 칸뿐입니다.

몇 가지는 순서가 조금 다릅니다.

리뷰는 분류 전에 기준부터 만듭니다. 30건 정도를 큰 모델에게 읽혀 "배송, 매트 두께, 냄새, 미끄러움 같은 주제로 나뉜다"는 기준 초안을 받습니다. 담당자가 자기 도메인 지식으로 다듬어 승인한 뒤 그 기준으로 Jev가 전체를 분류합니다. 불만 개선점을 찾는 것이 목적이라면 부정과 혼합 리뷰부터 보고, 그중 고른 것만 큰 모델에게 "개선 과제 3개를 뽑아 줘"라고 시킵니다.

뉴스는 걸러내는 비율이 큽니다. 영상의 시연에서는 기사 500건 중 42건만 관심 기준을 통과했습니다. 그 시연 자료에서 나온 값이고, 기준을 얼마나 좁게 적느냐에 따라 달라집니다.

영상의 뉴스 자료는 실제 영어 기사 제목과 발췌 아카이브라, 한국어 기사에서 같은 정확도가 나온다는 증거는 아닙니다. 요약할 때는 발췌만 읽었는지 본문을 읽었는지 표시해 두어야, 나중에 요약만 보고 판단하는 실수를 막을 수 있습니다.

캡션 분류는 텍스트 파일로 한정합니다. 영상에서는 인스타그램 화면 위에서 캡션을 판정해 색 테두리로 표시하는 크롬 확장 프로그램을 보여줍니다. 이 확장은 Jev가 기본으로 주는 것이 아니라, 구씨가 코딩 에이전트로 따로 만든 예시입니다.

이 글에서는 본인 소유이거나 이용 허가를 받은 캡션 텍스트를 파일로 모아 분류하는 범위까지만 다룹니다. 이미지 이해나 화면 자동 수집은 별개의 일이고, 플랫폼 이용 조건도 따로 확인하셔야 합니다.

언제, 어떻게 업무에 투입하나

Jev를 부르는 방법은 세 갈래인데, 우선순위가 있습니다.

첫째, 반복 업무용 전용 앱. Codex나 Claude Code 같은 코딩 에이전트에게 "파일을 읽어 Jev에 문항을 묶어 묻고, 결과표를 보여주고, 고른 건만 큰 모델로 초안을 쓰는 작은 앱을 만들어 줘"라고 요청해 만듭니다. 영상에 나온 앱도 이렇게 만든 예시이지 Jev가 기본으로 주는 화면이 아닙니다. 앱이 제대로 Jev를 부르는지, 키가 화면이나 로그에 새지 않는지는 만든 뒤에 사람이 확인해야 합니다.

둘째, 에이전트의 스킬과 예약 실행. Hermes 같은 에이전트에 같은 흐름을 스킬로 저장해 두고, 크론으로 시간을 정해 돌립니다. 영상에서는 9시에 분류, 10시와 11시에 난이도별 초안을 따로 예약하는 구상을 보여줍니다.

다만 시간만 따로 잡는다고 앞뒤 작업이 이어지는 것은 아닙니다. 예약 작업은 각각 새 세션에서 돌아갑니다. 그래서 다음 작업이 "앞 단계가 끝났는가, 결과 파일이 있는가, 미리 승인한 범위 안인가"를 직접 확인하게 만들어야 합니다. 하나라도 아니면 멈춥니다.

기본 권장은 분류만 예약하고, 사람이 결과를 보고 고른 뒤 초안을 따로 요청하는 것입니다. 자동 발송은 넣지 않습니다.

셋째, 채팅에서 실시간으로 시키기. 되기는 합니다. 그런데 영상에서 실제로 돌려 보면 병목이 보입니다.

채팅창에 "문의 100건 분류해 줘"라고 하면 메인 모델이 요청을 이해하고, 스킬을 읽고, Jev를 호출하고, 결과를 정리하는 데 시간이 걸립니다. Jev 자체는 금방 끝나는데 앞뒤에서 큰 모델이 생각하는 시간이 그 이점을 덮습니다. 채팅은 스킬이 제대로 돌아가는지 확인하는 용도로 쓰고, 확인이 끝나면 앱이나 예약 실행으로 옮기는 편이 맞습니다.

연결 경로는 TypeSafe 콘솔에서 직접 API 키를 발급받는 것이 기본입니다. 이미 OpenRouter나 Vercel AI Gateway를 쓰고 있다면 그쪽 키로 같은 요청 형식을 보낼 수 있습니다. 어느 경로든 메인 모델 설정을 바꾸는 것이 아니라 Jev를 별도 도구로 하나 추가하는 것입니다.

다음 단계로 넘어가는 조건

처음부터 완성형 앱을 만들어 달라고 하지 마세요. 날수를 정해 두는 것보다, 각 단계에서 무엇이 확인되면 넘어가는지를 정해 두는 편이 낫습니다.

3단계에서 꼭 보실 것이 있습니다. 에이전트에게 "Jev로 분류해 줘"라고 했을 때, 메인 모델이 자기 판단으로 분류해 놓고 완료했다고 보고하는 경우가 있습니다. 응답에 Jev 모델명과 호출 건수가 찍혀 있어야 진짜 Jev 결과입니다. 호출하지 못한 건은 "미실행", 호출했지만 오류가 난 건은 "실패"로 구분해 달라고 미리 요청해 두면 나중에 헷갈리지 않습니다.

한국어 자료라면 4~6단계에서 반복이 더 필요할 수 있습니다. 문항 설명을 더 직설적으로 쓰고 애매한 사례를 더 많이 적어 줘야 원하는 분류가 나올 가능성이 높습니다.

⚠ 처음에는 개인정보를 지운 복사본이나 가상 데이터로 시작하세요. 실제 데이터를 붙일 때도 필요한 열만 소량 가져와 결과를 보고 범위를 넓히는 편이 안전합니다. 메일 연동이나 크롤링으로 자료를 가져오는 것은 계정 권한과 수집 범위를 따로 정해야 하는 별개의 작업입니다.

마무리

Jev는 글은 안 쓰고, 정해진 문항에 값으로만 답하는 분류기입니다. 그래서 큰 모델을 빼는 것이 아니라 큰 모델 앞에 세웁니다. Jev가 분류하고, 사람이 표에서 고르고, 고른 건만 큰 모델이 초안을 쓰고, 보내기는 사람이 누릅니다.

같은 종류의 자료가 반복해서 쌓이고, 판단을 객관식으로 적을 수 있고, 한 건이 짧고, 틀린 분류를 사람이 잡아낼 자리가 있다면 잘 맞습니다. 소량의 자료를 가끔 처리한다면 그냥 GPT나 Claude에 넣으셔도 됩니다.

시작은 작게 하세요. 문의 20건과 FAQ 문서 하나로 문항을 만들어 보고, 틀린 분류를 고쳐 가며 내 기준이 문항에 담기는지 확인하는 것이 첫 할 일입니다. 매일 쌓이는데 읽기만 하고 넘기는 자료가 있다면, 그게 첫 후보입니다.

실제 화면으로 다섯 가지 사례를 돌리는 과정은 영상에서, 단계별로 복사해 쓸 프롬프트는 상세 가이드에서 확인하실 수 있습니다.

• 영상: 요즘 가장 핫한 AI모델 Jev, AI 자동화에 적용하기!
• 상세 가이드: Jev 워크플로우 프롬프트 모음 (GitHub)

참고 자료 및 출처