Jev로 무엇을 만들 수 있을까? 작은 판단을 자동화하는 방법

메일이 수십 통 쌓여 있다면 무엇부터 읽어야 할까요? “이 메시지는 바로 답해야 할까?”, “단순 안내일까?”, “다른 담당자에게 넘겨야 할까?”를 정하는 데도 생각보다 시간이 듭니다.

TypeSafe의 Jev는 이런 판단을 프로그램에 넣을 때 사용할 수 있는 AI 모델입니다. 글을 읽고 미리 정한 보기 중 하나를 고르거나, 기준에 따른 점수와 확률을 반환합니다. 프로그램은 그 값을 받아 메일에 표시를 붙이고, 검토 순서를 바꾸고, 필요한 경우 다른 AI를 호출할 수 있습니다.

그런데 여기서 한 가지 의문이 생깁니다. 답이 예·아니오로 짧아진다고 해서 판단까지 쉬워지는 걸까요? ‘긴급한 메일’이나 ‘믿을 만한 리뷰’의 기준은 여전히 모호합니다.

Jev를 활용하려면 바로 이 문제를 먼저 풀어야 합니다. 이 글에서는 답장이 필요한 메일을 정리하는 도우미를 예로 들어, 무엇을 AI에 묻고 무엇을 코드로 정해야 하는지 살펴보겠습니다. 이어서 API 사용 방식과 비용, 실제 공개된 예제까지 연결해 보겠습니다.

Jev 자체가 처음이라면 Jev는 에이전트가 아닙니다: 판단 전용 모델 이해하기도 참고하세요. 아래 메일과 판단 결과는 설명을 위한 가상 예시이며, 직접 API를 호출한 실험 결과는 아닙니다.

처음 만들어볼 기능: 답장이 필요한 메일 정리하기

받은 메일을 다음 네 그룹으로 나누는 도우미를 만든다고 해보겠습니다.

• 우선 확인
• 일반 답장
• 답장 불필요
• 직접 검토

가령 다음과 같은 메일이 들어왔습니다.

결제 연동이 사흘째 안 됩니다. 지금도 주문을 받지 못하고 있습니다. 언제 복구되는지 알려주세요.

사람이 읽으면 장애가 계속되고 있고 답변도 필요하다는 것을 알 수 있습니다. 하지만 ‘결제’라는 단어만 찾는 코드로는 이중 결제 문의인지, 사용법 질문인지, 현재 진행 중인 장애인지 구분하기 어렵습니다.

이럴 때 Jev에게 문장의 의미를 판단하도록 맡길 수 있습니다. 프로그램은 그 판단을 받아 메일을 ‘우선 확인’ 그룹에 표시합니다. 답장 초안까지 필요하다면 이후에 GPT나 Claude를 호출하는 단계를 추가하면 됩니다.

첫 버전은 이 정도로도 충분합니다. 메일을 입력하고, 어떤 항목이 감지됐는지 보여주고, 분류 결과를 사람이 수정할 수 있게 만드는 것입니다.

예·아니오로 물어도 기준은 사람이 정해야 합니다

“이 메일은 긴급한가?”라는 질문은 간단해 보입니다. 하지만 급하다는 말투, 가까운 마감, 현재 발생 중인 피해 중 무엇을 중요하게 볼지에 따라 답이 달라집니다.

“바쁘시겠지만 확인 부탁드립니다”처럼 정중한 메일에도 심각한 장애가 담길 수 있습니다. 반대로 “급해요!”라고 썼어도 이미 해결된 일을 재확인하는 내용일 수 있습니다.

따라서 먼저 판단하려는 내용을 구체적으로 나눕니다.

여기서 묻는 것은 메일에 어떤 내용이 담겨 있는지입니다. 고객이 “매출 손실이 발생했다”고 썼다고 해서 실제 피해가 확인된 것은 아닙니다. 사실 확인이 필요하다면 주문 기록이나 장애 로그를 따로 조회해야 합니다.

Jev는 문장에서 이런 신호를 읽고, 프로그램은 회사의 대응 기준에 따라 신호를 조합합니다. 예를 들어 현재 장애가 언급되면 우선 확인하고, 답변 요청만 있으면 일반 답장 목록으로 보내는 식입니다. 이 규칙은 팀마다 달라질 수 있습니다.

TypeSafe의 질문 설계 문서도 여러 요인이 섞인 판단은 작은 질문으로 나누고, 결과는 코드에서 결합하도록 안내합니다.

Jev가 반환하는 값은 세 가지입니다

질문의 목적에 따라 Choice, Score, Noul 중 하나를 선택합니다.

Choice와 Score에는 보기별 확률과 confidence가 포함됩니다. confidence는 확률 분포가 얼마나 한쪽으로 모였는지를 요약한 지표이며, 가장 높은 보기의 확률과 같은 값은 아닙니다.

Noul은 예일 확률을 0부터 1 사이의 값으로 반환하고, 별도의 confidence 필드는 없습니다. 0.5에 가까운 결과는 예와 아니오 사이에서 불확실하다는 의미이지, 문제가 ‘중간 정도’라는 뜻이 아닙니다.

또한 반환값의 형태가 정해져 있어도 의미 판단은 틀릴 수 있습니다. 높은 확률을 곧바로 정답이나 실행 허가로 취급해서는 안 됩니다.

메일 한 통에 여러 질문을 할 수 있습니다

앞의 메일에서 다음 세 가지를 따로 묻는다고 해보겠습니다. 숫자는 실제 응답이 아닌 설명용입니다.

프로그램은 이 값을 기준으로 ‘우선 확인’ 표시를 붙일 수 있습니다. 다만 얼마 이상을 충분한 근거로 볼지는 실제 메일로 시험해 정해야 합니다. 판단이 애매하거나 API 호출이 실패하면 ‘직접 검토’로 보내는 경로도 필요합니다.

같은 메일에 대한 독립적인 질문은 한 요청에 함께 보낼 수 있습니다. 이때 앞 질문의 답이 다음 질문으로 자동 전달되지는 않습니다. 결과를 결합하는 단계는 프로그램에 둡니다.

GPT도 할 수 있는데 Jev를 따로 쓰는 이유는 뭘까요?

GPT나 Claude에 메일 분류를 맡기는 것도 가능합니다. 결과를 정해진 JSON 형식으로 받도록 구성할 수도 있습니다.

Jev를 검토할 만한 상황은 같은 종류의 분류나 점수화를 반복해서 수행하고, 그 결과를 프로그램이 바로 사용해야 할 때입니다. 예를 들어 매일 들어오는 문의를 분류하거나, 에이전트가 선택할 스킬 후보를 매번 좁히는 작업입니다.

반면 복잡한 사정을 종합해 대응 전략을 설명하거나 고객에게 보낼 답장을 작성해야 한다면 언어 모델의 역할이 큽니다. 메일 도우미에서는 다음처럼 나눌 수 있습니다.

1. Jev가 메일의 종류와 답변 요청 여부를 판단합니다.
2. 프로그램이 처리 순서와 담당 팀을 정하고 필요한 자료를 가져옵니다.
3. GPT나 Claude가 회사 정책과 도움말을 참고해 답장 초안을 작성합니다.
4. 담당자가 원문과 초안을 확인하고 발송합니다.

모든 서비스에 이 단계를 추가할 필요는 없습니다. 기존 분류가 충분히 정확하고 비용도 작다면, Jev 호출을 추가하는 편이 오히려 복잡할 수 있습니다. 같은 데이터로 정확도, 응답 시간, 전체 처리 비용을 비교한 뒤 선택하면 됩니다.

입력은 얼마나 길게 넣어야 할까요?

‘몇 글자가 적당한가’보다 먼저 볼 것은 그 질문에 답하는 데 어떤 정보가 필요한가입니다.

답변 요청 여부를 판단하는 데는 현재 메일만으로 충분할 수 있습니다. 하지만 “아까 말씀드린 건 취소할게요”라는 메시지는 이전 대화가 없으면 무엇을 취소한다는 것인지 알 수 없습니다. 무조건 짧게 만드는 것도 좋은 방법은 아닙니다.

메일 도우미라면 다음처럼 입력을 구성할 수 있습니다.

불필요한 서명, 무관한 과거 메일, 전체 홈페이지 HTML까지 함께 넣을 이유는 없습니다. TypeSafe의 State 문서도 판단에 필요한 맥락을 구성하는 방법을 설명합니다.

긴 문서라면 검색이나 코드로 관련 부분을 먼저 추리는 방식을 고려할 수 있습니다. 다만 질문의 의미를 바꾸는 예외 조항이나 앞뒤 문맥까지 잘라내지 않도록 해야 합니다.

날짜 계산도 구분하면 좋습니다. 메일에 마감 표현이 있는지 해석하는 일과 실제로 몇 시간이 남았는지 계산하는 일은 다릅니다. 날짜가 확정되면 시간대와 현재 시각을 반영한 계산은 코드가 담당합니다. 제품의 최대 입력 한도를 권장 입력량으로 받아들일 필요도 없습니다.

Jev를 쓰려면 TypeSafe 서비스를 이용하나요?

이 글에서 설명하는 방식은 TypeSafe가 제공하는 API를 호출하는 것입니다. 직접 GPU를 마련하는 대신, 내 서비스가 텍스트와 질문을 보내고 Jev의 판단값을 돌려받습니다.

웹 서비스에서는 다음 순서로 연결할 수 있습니다.

1. 사용자가 화면에 메일을 입력합니다.
2. 내 서버가 TypeSafe API에 필요한 내용과 질문을 보냅니다.
3. 서버가 반환값에 분류 규칙을 적용합니다.
4. 화면에 분류 결과와 검토할 항목을 표시합니다.

API 키는 서버에 보관합니다. 또 입력한 내용이 외부 API로 전송된다는 점을 고려해, 판단에 필요하지 않은 개인정보는 제외하는 편이 좋습니다. 먼저 TypeSafe Playground에서 예시 텍스트를 시험해볼 수도 있습니다.

Claude Code나 Cursor로 이 연동 코드를 작성할 수는 있지만, 모델 설정에 Jev를 선택한다고 기존 코딩 에이전트가 그대로 작동하는 것은 아닙니다. TypeSafe의 에이전트용 스킬은 API 연동을 돕는 지침입니다. 이 차이는 공식 코딩 에이전트 안내에서도 설명합니다.

비용은 어느 정도인가요?

TypeSafe가 2026년 9월 15일 발표문에 공개한 가격은 입력 100만 토큰당 0.042달러이며, 출력 토큰은 무료입니다. 실제 사용 전에는 계정에 적용되는 최신 요금을 확인해야 합니다.

전체 과금 입력이 요청당 1,000토큰이라고 가정하면 단순 계산은 다음과 같습니다.

토큰은 글자 수와 같지 않습니다. 이 계산에서 말하는 입력은 메일 본문만이 아니라 질문과 보기 등을 포함한 전체 과금 입력을 가정합니다. 재시도나 여러 단계 호출, 답장 작성용 LLM과 서버 비용도 별도입니다.

따라서 메일 한 통의 API 비용뿐 아니라, 오분류 때문에 사람이 다시 처리하는 시간까지 함께 봐야 합니다. 같은 데이터에서 원하는 정확도를 얻을 수 있는지가 비용 판단의 전제가 됩니다.

실제로 구현된 사례도 있나요?

공개된 코드 예제와 실험은 있습니다. 다만 예제가 있다는 것과 여러 회사의 운영 환경에서 효과가 검증됐다는 것은 구분해서 읽어야 합니다.

가령 TypeSafe의 스킬 추천 예제는 Hermes의 스킬 182개를 대상으로 후보를 평가하고, 상위 세 개의 상세 내용을 다시 읽어 최대 하나를 추천합니다. 맞는 스킬이 없으면 추천을 하지 않을 수도 있습니다.

예제에는 특정 모델과 요청 집합으로 비교한 결과가 공개되어 있습니다. 이것은 스킬 추천을 실제로 구현하고 시험했다는 근거지만, 다른 에이전트나 내 스킬 목록에서도 같은 효과가 난다는 보장은 아닙니다.

이 밖에도 공식 문서에는 검색 문단 분류와 인용 검증 예제가 있습니다. 이 글의 메일 도우미는 이런 판단 구조를 이해하기 쉽게 조합한 설계 예시입니다. 직접 운영하며 검증한 제품 사례는 아닙니다.

메일 분류에서 다른 기능으로 확장하기

판단 범위를 정하는 방법을 이해했다면 다른 기능에도 적용할 수 있습니다.

리뷰의 광고성 표현을 찾는 것과 리뷰가 가짜라고 단정하는 것은 다릅니다. 도구의 위험성을 분류하는 것만으로 실행 권한이나 보안 정책을 대체할 수도 없습니다. 입력에서 판단할 수 있는 범위와, 그 판단으로 허용할 행동을 따로 정하는 것이 중요합니다.

첫 버전에서는 판단 기준부터 검증해보세요

메일 도우미를 만든다면 분류 결과 옆에 사람이 고칠 수 있는 버튼을 두는 것부터 시작해 보세요. 모델이 틀린 사례를 모으면 질문이 모호한지, 입력이 부족한지, 분류 기준이 현실과 맞지 않는지 살펴볼 수 있습니다.

1. 실제 메일 30~50개 정도에 사람이 기대하는 분류를 붙입니다.
2. Jev의 결과와 비교하고, 잘못 분류된 메일을 읽어봅니다.
3. 사람끼리도 답이 갈리는 사례는 먼저 분류 기준을 정리합니다.
4. 수정한 기준을 아직 사용하지 않은 메일에도 적용해봅니다.
5. 처음에는 추천만 표시하고, 결과가 충분히 확인된 작업부터 자동 처리합니다.

30~50개는 초기 문제를 발견하기 위한 출발점이지 운영 정확도를 보장하는 표본 수는 아닙니다. 특히 긴급한 메일을 놓친 경우와 일반 메일을 긴급하게 분류한 경우는 따로 세어보는 것이 좋습니다. 두 실수의 비용이 다르기 때문입니다.

Jev로 무엇을 만들지 고민된다면, 평소 반복해서 읽고 분류하는 글부터 찾아보세요. 그다음 “이 글을 보고 구체적으로 무엇을 알아야 하나?”, “그 답에 따라 프로그램이 무엇을 해야 하나?”를 적어보면 됩니다.

좋은 첫 프로젝트는 판단 기준을 설명할 수 있고, 잘못된 결과를 사람이 쉽게 확인하고 수정할 수 있는 작은 기능입니다. 메일을 정리하는 도우미도 그 조건을 갖춘 출발점이 될 수 있습니다.