Jev는 어떤 서비스이고 어떻게 활용할 수 있는지 사례까지 공유합니다!

강의나 컨설팅 문의가 들어오면 제가 고려할 사항들이 있습니다. 이 문의에 범용 제안서를 보내면 되는 건지 전화를 먼저 걸어야 하는 건지 정하려면 결국 제 결정이 들어가야 합니다. 접수와 기록까지는 자동으로 도는데 그다음 결정이 매번 제가 해야 하는 영역이라 제가 움직이지 않으면 진행이 안됩니다.

요즘 Jev가 아주 핫하길래 살펴보니 정확히 이 부분을 해결해주는 모델이더라고요. 실제 적용을 해보았습니다.

Jev는 어떤 모델인가요?

Jev는 TypeSafe AI가 내놓은 판정 전용 모델입니다. 클로드나 챗GPT와 가장 다른 점은 글을 아예 쓰지 못한다는 겁니다.

클로드가 읽고 생각하고 문서를 써 주는 직원이라면, Jev는 서류를 받아 도장만 찍는 심사 담당자입니다. 설명도 없고 보기 중에서 하나 고르기, 기준표를 놓고 점수 매기기, 맞는지 아닌지 확률로 답하기예요. 값과 확률을 통해 수치화해주는 것이 기존 모델과 다른 점이었습니다.

질문을 여러 개 넣어도 한꺼번에 평가돼서 응답 시간이 거의 늘지 않습니다.

가격은 입력 100만 토큰당 0.042달러이고 출력 토큰은 무료입니다. 토큰은 글자 수를 세는 단위인데요, 한글 한 글자가 대략 한두 토큰이라고 보시면 됩니다.

왜 이렇게 화제가 됐나요?

싸고 빠르다는 말만으로는 핫하기 힘들죠. 원래 AI를 쓰기 아까웠던 단계에 JEV가 파고들었습니다.

문의 한 건을 분류하려고 클로드를 부르면 몇 초가 걸리고 돈도 듭니다. 그런데 메일 6만 통, 광고 2천 건, 페이지 586개처럼 건수가 늘어나면 그 방식은 쓸 수가 없어요. 사람들이 올린 결과를 보면 이런 숫자가 나옵니다.

TypeSafe도 같은 비교를 공개해 뒀습니다. 자사 워크플로우 기준으로 프런티어 모델보다 193.6배 빠르고 444.6배 저렴하다고 밝혔다고 해요. 자체 측정치라는 건 같이 보셔야 합니다.

사례를 모아 둔 jevable.com에는 지금 194건이 올라와 있는데요, 그중 152건이 9월 18일 하루에 등록됐습니다. 출시 나흘 만에 이만큼 쌓였다는건 그만큼 핫하다는 의미겠죠.

네버슬립 문의 흐름에 어떻게 연결했나요?

기존 흐름은 그대로 뒀습니다. Tally 폼이 제출되면 슬랙, 노션, 디스코드, 구글 시트에 동시에 기록되는 연동은 이미 돌고 있었어요.

여기에 Cloudflare Worker 하나를 추가했습니다. Worker는 제 컴퓨터가 아니라 Cloudflare 서버에서 필요할 때만 실행되는 작은 프로그램인데요, 전용 인터넷 주소가 하나 생기고 그 주소로 데이터가 들어오면 깨어나서 일을 합니다. 슬랙에 새 문의 메시지가 올라오면 Worker가 그 신호를 받아서 Jev에게 판정을 요청하고, 같은 스레드에 답글을 답니다.

Tally 문의 제출
  → (기존) 슬랙·노션·디스코드·시트 기록
  → 슬랙이 새 메시지 이벤트를 Worker에 전달
  → Worker가 개인정보를 뺀 업무 항목만 Jev에 전달
  → Jev가 질문 7개에 확률로 답함
  → Worker의 규칙이 최종 경로 확정
  → 같은 스레드에 봇이 판정 댓글 작성

슬랙 봇 이름은 해석으로 정했습니다. 권한은 채널 메시지 읽기와 쓰기 두 개만 줬고, 대상 채널도 문의 알림 채널 하나로 고정했어요.

노트북 대신 Cloudflare에서 도는 구조로 만들었습니다. 이동시 오는 문의에도 작동되야 하니까요.

Jev에게 맡기는 일곱 개 질문

Jev에게는 미리 정해 둔 질문지를 줘야 해요.

각 질문에는 어떤 경우에 어느 답을 골라야 하는지 기준 문장을 같이 넣었습니다. 예를 들어 owner_review에는 맞춤 커리큘럼, 컨설팅, 구축, 연동, 보안, 조달, 협상 조건이 있으면 참이라고 적어 뒀어요.

Jev가 준 확률을 그대로 따르지도 않습니다. 최종 경로는 Worker 안의 규칙이 정해요.

• 직접 검토를 확신도 0.6 이상으로 골랐으면 바로 직접 검토
• 통화 필요를 확신도 0.6 이상으로 골랐고 통화 필요 확률도 0.65 이상이면 통화 필요
• 범용 제안서는 확신도 0.85 이상에 정보 충족도 1.5 이상, 맞춤화 0.5 이하, 위험 0.8 미만을 전부 만족할 때만 허용
• 어디에도 해당하지 않으면 직접 검토

자동으로 내보낼 수 있는 경우만 조건을 빡빡하게 걸어 두고, 애매하면 무조건 사람에게 넘기는 구조입니다. 개인정보도 Jev에 보내지 않습니다. 성함, 회사명, 전화번호, 이메일은 빼고 조직 규모나 도입 상태 같은 업무 항목만 전달해요.

실제 문의 스레드에 판정 댓글이 달렸어요!

월요일 아침에 들어온 그 문의를 실제로 넣어봤습니다. 결과는 이렇게 나왔어요.

• 최종 경로: 통화 필요
• 통화 필요 확률: 87%
• 맞춤화 수준: 1.55 / 2
• 정보 충족도: 0.99 / 2
• 다음 단계: 목적·대상·범위·일정을 짧은 통화로 확인하세요

문의에 적힌 필요 교육이 자체 웹·앱 개발 사용법이었는데, Jev는 이걸 표준 입문 커리큘럼이 아니라 맞춤 범위로 읽었습니다. 범용 제안서로 바로 나갔으면 안 맞았을 확률이 높은 건이에요.

이 판정 한 번에 들어간 입력은 1,037토큰이었습니다. 원화로 1원이 안 됩니다.

같은 문의를 앞서 단독으로 돌렸을 때는 직접 검토가 나왔고, 이번 실시간 재판정에서는 통화 필요가 나왔습니다. 확률 모델이라 경계에 걸친 건에서는 결과가 흔들려요. 두 경로 모두 자동 발송을 막고 사람이 확인하는 쪽이라 위험하진 않지만, 판정이 항상 같다고 기대하면 안 됩니다.

설치 이후로 아직 새 문의가 들어오지 않아서, 신규 문의가 자동으로 들어오는 경로는 실측을 못 했습니다. 위 댓글은 같은 슬랙 이벤트를 Worker에 다시 흘려보내 전체 흐름을 확인한 결과예요.

Jev 사례 194건은 어떤 일에 쓰이고 있나요?

194건을 카테고리별로 세어 보면 이렇습니다.

게임이 39건으로 가장 많은데 이건 재밌어서 만든 데모에 가깝죠. 업무로 옮길 만한 것만 묶어 보면 아래처럼 나뉩니다.

건수가 많고 기준이 같은 일

이메일 1,500통 분류, 이력서 360장을 24.2초에 스크리닝하고 0.0212달러, 건설 도면 26장 세트를 2.9초에 분류하고 0.0052달러 같은 사례가 여기 들어갑니다.

워크플로우는 대체로 비슷합니다. 코드가 대상 목록을 만들고, 항목마다 판정 질문 두세 개를 던지고, 확신도가 낮은 것만 사람이 확인하도록 넘깁니다. 회사 400곳과 지원자 프로필 한 건을 12초에 대조해 합격 가능성과 미스매치를 뽑은 사례도 같은 구조예요.

다음 담당자를 고르는 라우팅

들어온 일을 어느 모델, 어느 도구, 어느 사람에게 보낼지 정하는 용도입니다. 클로드 코드 스킬이 90개인데 실제로 쓰는 건 다섯 개뿐이라 스킬 라우터를 만든 사례가 있고, 사용자가 프롬프트를 다 치는 순간 난이도를 분류해 빠른 모드를 제안하는 사례도 있습니다.

PDF를 페이지 단위로 보고 OCR이 필요한 페이지만 골라내고 나머지는 로컬에서 추출하는 방식도 라우팅입니다. 비싼 처리를 필요한 곳에만 쓰는 게 목적이에요. 저희 해석도 이 묶음에 들어갑니다.

에이전트 속도 올리기

브라우저나 컴퓨터를 조작하는 에이전트는 매 단계마다 "다음에 뭘 클릭할까"를 정해야 하는데, 그 판단을 Jev가 맡습니다. Browser Use에 연결해 항공권 검색을 7초에 0.0039달러로 끝낸 사례, 음성 지시를 300ms 만에 브라우저 동작으로 바꾼 사례가 있어요.

조회수가 가장 높았던 건 컨텍스트 압축이었습니다. 대화가 길어지면 요약 프롬프트를 돌려 줄이는 게 보통인데, 툴 호출마다 점수를 매겨 필요 없는 것만 버리는 방식으로 바꾼 겁니다.

발행 전 품질 검사

만들어진 결과물이 기준을 지켰는지 1차로 거르는 용도입니다. PR 하나에 하드코딩된 비밀키, SQL 위험 같은 검사 14종을 한 번의 호출로 돌리는 사례, AI가 쓴 티가 나는 문장을 문장 단위로 잡아내는 사례가 올라와 있습니다.

제 다음 프로젝트는 이걸로 하려고요. 네버슬립 글쓰기 검수는 지금 정규식으로 금지 표현을 잡고 있는데, 정규식이 못 잡는 건 번역투 냄새나 어색한 마무리 같은 판정입니다. 매번 마지막 수정을 제가 보고 있어요.

화면에서 바로 반응하는 기능

응답이 100ms대라 사용자가 타이핑하는 동안에도 돌릴 수 있습니다. 스프레드시트 열 제목에 "Urgency"를 치면 입력하는 도중에 각 행을 등급으로 채우는 사례, 답변에 따라 다음 질문이 바뀌는 폼, 다운로드 폴더를 감시하다가 받은 파일이 청구서인지 판정해 폴더와 파일명을 정리하는 맥 앱이 여기 있어요.

쓰기 전에 알아야 하는 것

TypeSafe 문서가 못하는 일을 솔직하게 적어 놨습니다. 저도 만들면서 그대로 겪었어요.

우선 한국어입니다. 문서는 영어가 주 학습 언어이고 CJK를 포함한 다른 언어는 처리는 되지만 동등하지 않으니, 비영어 업무에 쓰기 전에 본인 콘텐츠로 직접 테스트하고 확신도를 주의해서 보라고 적어 뒀습니다. 저는 그래서 질문과 기준 문장을 전부 영어로 쓰고 문의 내용만 한국어로 넣었습니다.

다음은 숫자와 날짜입니다. 개수 세기, 금액 계산, 어느 날짜가 먼저인지 비교하는 일은 코드로 하라고 문서가 직접 권고합니다. 저희 판정기도 확률 비교와 문턱값 계산은 전부 Worker 코드에서 합니다.

질문을 문자 그대로 읽는 것도 알아 둬야 합니다. 의도를 넣지 말고 조건을 그대로 써야 해요. 답이 이상하게 나왔을 때 "내 말은 그게 아니라"라고 설명하고 싶어지면, 그 설명이 빠진 기준 문장입니다.

그리고 넘기는 데이터가 많을수록 정확도가 떨어집니다. 문의 전문을 통째로 던지지 말고 판정에 필요한 항목만 골라 보내는 편이 낫습니다. 개인정보를 빼는 것과 정확도를 올리는 게 같은 방향이라 다행이었어요.

마지막으로 텍스트 생성은 아예 안 됩니다. 제안서 초안이나 회신 문구는 계속 클로드가 씁니다. Jev는 그 앞에서 누구에게 보낼지만 정해요.

어디부터 시작하면 되나요?

반복해서 들어오는 것 중에 매번 같은 기준으로 나누고 있는 일을 하나 찾아보세요. 문의, 이메일, 리드, 주문서, 후기 같은 것들이요. 그다음 그 판단을 예 아니오 질문 두세 개로 쪼개서 적어 보시면 됩니다. 쪼개지지 않으면 Jev에 넣어도 잘 안 됩니다.

질문이 정리되면 과거 데이터 스무 건 정도로 먼저 돌려 보세요. 비용은 몇 원 안 나오고, 한국어에서 쓸 만한지와 어디부터 사람이 봐야 하는지가 확신도 분포에서 바로 보입니다. 그게 맞으면 그때 실제 흐름에 연결하는 순서로 가시면 됩니다.

저는 아직 자동 발송까지 연동하진 않았습니다. 판정 댓글만 달게 해 두고 실제 문의 몇 건을 더 본 뒤에 기준을 고칠 생각이에요! 해보면서 자기만의 워크플로우에 맞게 최적화하는 과정이 필요합니다.