Jev(TypeSafe AI) 사용법 AI에게 긴 답변 대신 ‘판단’만 받는 법

Jev는 무엇을 하는 모델인가

Jev(TypeSafe AI)는 글을 쓰지 않습니다. 대신 미리 정해 둔 선택지 중 하나를 고르거나, 정도를 점수로 매기거나, 조건이 참일 확률을 돌려줍니다. 응답은 언제나 코드가 바로 받아 쓸 수 있는 타입이라, 형식이 어긋나는 일은 구조적으로 생기지 않습니다.

다만 형식이 맞는 답과 내용이 맞는 판단은 다른 이야기입니다. Jev가 목록 안의 선택지를 정확한 형식으로 돌려줘도, 고른 답 자체는 틀릴 수 있습니다. 그래서 결과를 실제 데이터로 채점해 보는 과정은 여전히 필요합니다.

Jev는 챗봇이나 코딩 어시스턴트의 자리를 넘보지 않습니다. 대신 프로그램이 갈림길에서 방향을 정해야 하는 지점에 들어갑니다.

이제 이런 ‘판단 전용’ AI가 Jev 하나만은 아닙니다. OpenAI는 9월 29일 GPT-6 Luna를 바탕으로 한 Decisions API를 한정 프리뷰로 내놓았고, 10월 6일에는 모든 개발자에게 공개 베타로 열었습니다. AWS는 10월 1일 직접 내려받아 돌릴 수 있는 오픈소스 모델 Strands Decider 2B를 공개했습니다. 세 회사의 차이는 ‘말하지 않는 AI가 뜬다’ 글에서 비교했고, 이 글은 Jev 공식 문서를 기준으로 사용법만 다룹니다.

세 가지 질문 타입

질문 타입마다 돌려받는 값의 모양이 다릅니다.

Choice: 정해진 후보 중 하나

순서 없는 선택지 중 하나를 고를 때 씁니다. 티켓을 담당 부서로 보내거나, 문서 종류를 가려내거나, 어떤 프로그래밍 언어인지 알아내는 일이 여기에 해당합니다.

어느 후보에도 들어맞지 않는 경우가 있을 수 있다면 반드시 ‘기타’나 ‘해당 없음’을 넣으세요. Jev는 목록에 없는 답을 지어낼 수 없습니다.

Score: 정도를 재는 눈금

버그 심각도, 고객 불만 정도, 숙련도처럼 ‘얼마나’를 잴 때 씁니다. 단계는 직접 정하고, 모델은 그 눈금 위 어디쯤인지를 돌려줍니다. 그래서 1.43처럼 두 단계 사이의 소수가 나오기도 합니다.

N단계를 정의하면 결과는 0부터 N-1 사이로 나옵니다. 0~1로 정규화하려면 코드에서 score / (N - 1)을 계산하세요.

Noul: 예/아니오의 확률

0에 가까우면 아니오, 1에 가까우면 예입니다. 0.5는 ‘중간 정도’가 아니라 ‘판단하기 어렵다’는 뜻입니다. 정도를 재고 싶다면 Noul이 아니라 Score를 써야 합니다.

“이 후보자가 파이썬을 잘하는가?”는 ‘잘한다’의 기준이 모호해서 Noul에 맞지 않습니다. “이력서에 업무에서 파이썬을 썼다고 적혀 있는가?”처럼 조건을 분명히 하거나, 숙련도 단계를 정한 Score 질문으로 바꾸세요.

state와 questions 나누기

요청은 두 부분으로 나뉩니다. state에는 판단할 재료를, questions에는 물어볼 내용을 넣습니다.

질문 ID는 모델에게 전달되지 않습니다

많이들 하는 실수입니다. refund_requested라는 ID를 붙였다고 모델이 그 뜻을 알아듣지는 않습니다. ID는 응답을 찾을 때 쓰는 키일 뿐이고, 질문 내용은 instructions에 빠짐없이 적어야 합니다.

질문을 쪼개야 하는 이유

“이 고객이 이탈할 위험이 높으며 어느 팀이 응대해야 하는가?”는 나쁜 질문입니다. 이탈 위험과 담당 팀, 두 가지 판단이 한 질문에 뒤섞여 있어 어느 쪽 답도 믿기 어렵습니다.

이렇게 나누세요.

• Score: 이탈 위험은 어느 정도인가?
• Choice: 어느 팀으로 보내야 하는가?

두 답은 코드에서 조합합니다. 나중에 우선순위 가중치를 바꾸고 싶어도 프롬프트를 다시 쓸 필요 없이 코드의 숫자만 고치면 됩니다.

같은 state를 보는 질문은 한 번에 묶어 보내세요

같은 state를 보는 질문은 한 요청에 모두 묶는 것이 기본입니다. Jev는 한 요청 안의 질문들을 병렬로 평가하기 때문입니다. 공식 문서는 질문을 더해도 응답 시간이 거의 늘지 않고, 늘어나는 비용도 추가한 질문의 토큰값뿐이라고 설명합니다. 실제 지연 시간과 비용은 내 입력과 질문 구성으로 직접 재 보세요.

특정한 경우에만 쓰일 답이라도 미리 함께 물어 두는 편이 낫습니다. 공식 문서는 이를 speculative fan-out(일단 함께 물어보기) 패턴이라고 부릅니다. 예를 들어 문의가 버그 신고가 아니면, 함께 받은 심각도 답은 코드에서 버리면 그만입니다.

confidence로 분기 설계하기

Choice와 Score는 답과 함께 confidence도 돌려줍니다. 확률 분포가 얼마나 한쪽으로 쏠려 있는지를 0~1 사이 숫자 하나로 요약한 값입니다. 분포가 고르게 퍼져 있으면 낮고, 한 후보에 몰려 있으면 높습니다. (Noul에는 별도 confidence가 없습니다.)

임계값은 하나가 아닙니다

같은 시스템 안에서도 행동의 위험도에 따라 기준을 다르게 잡아야 합니다. 잔액 조회 화면을 잘못 띄우는 실수와 이체를 잘못 승인하는 실수는 무게가 전혀 다릅니다.

• 읽기 전용 작업 → 오류의 영향과 검증 결과에 따라 임계값을 낮출 수 있습니다
• 되돌릴 수 없는 작업(전송, 결제, 삭제) → 높은 임계값 + 사용자 확인
• 어느 쪽이든 confidence가 바닥이면 → 사람에게

“0.8이면 자동 처리” 같은 만능 기준은 없습니다. 실제 데이터로 시험한 뒤 오탐과 미탐의 비용을 따져 정해야 합니다.

처음부터 끝까지: 고객 문의 하나를 분류해 보기

지금까지 본 개념을 한 줄로 꿰어 보겠습니다. 쇼핑몰 고객센터에 들어온 문의 하나를 Jev로 분류하고, 어디까지 자동으로 처리할지 정하는 과정입니다. 아래 숫자는 흐름을 보여 주려고 만든 예시 값이며, 실제 API 호출 결과가 아닙니다.

정리하면 Jev는 ②~③의 판단만 맡고, ④~⑤의 기준과 권한은 코드와 사람이 쥡니다. 기준 숫자 0.8은 예시일 뿐이고, 실제 값은 내 데이터에서 오탐과 미탐의 비용을 따져 정해야 합니다.

한국어로 쓸 때 반드시 확인할 것

공식 문서는 Jev의 주 학습 언어가 영어라고 밝힙니다. 한국어를 포함한 CJK 문자 언어도 입력은 받지만, 지금은 정확도가 더 낮다고 합니다.

그러니 한국어 서비스에 넣기 전에 아래 순서로 직접 검증해 보세요.

자주 걸리는 함정

라벨은 구체적으로

Score 단계를 이렇게 쓰면 안 됩니다.

낮음 / 중간 / 높음

이렇게 바꾸세요.

활동이 기존 계정 기록과 일치함 / 평소와 다른 접속이 한 건 확인됨 / 계정 도용 지표가 여러 건 확인됨

단계마다 어떤 상황인지 문장으로 적어 줘야 모델이 덜 헷갈립니다.

운영에서 지킬 것

• 서버에서만 호출합니다. API 키는 환경 변수나 시크릿 저장소에 두고, 브라우저 번들이나 소스에 넣지 않습니다.
• 질문과 임계값은 설정 파일로 모읍니다. 코드 곳곳에 흩어져 있으면 숫자 하나 바꿀 때마다 코드 전체를 뒤져야 합니다.
• 모델 버전을 기록합니다. 탐색 단계에서는 최신 별칭(jev-latest)을 쓰되, 임계값을 검증한 뒤에는 버전(10월 6일 현재 jev-1.13.0)을 고정하고 응답에 담긴 실제 모델명을 로그에 남깁니다.
• 재시도는 SDK 기본값을 씁니다. 직접 구현한다면 429·529에만 제한적 백오프를 적용하고, 401·422는 재시도하지 않습니다.
• 개인정보는 최소한만 보냅니다. 원문과 키를 기본 로그에 남기지 않습니다.
• 외부 작업은 별도로 보호합니다. 허용 목록, 인자 검증, 권한 검사를 거치고, 필요하면 사용자 승인까지 받습니다. 모델의 판단과 실행 권한은 따로 떼어 둬야 합니다.

이 글에 나온 용어

정리

Jev를 잘 쓰는 방법은 결국 판단과 실행을 분리하는 것입니다. 모델은 좁은 질문에 타입이 정해진 답을 내놓고, 흐름 제어와 정확한 계산, 권한은 코드가 책임집니다.

시작은 작게 하세요. 지금 생성형 AI에게 프롬프트로 분류를 시키고 그 답을 다시 파싱하고 있는 곳, 딱 한 군데만 찾아 Jev로 바꿔 보면 충분합니다.