무엇이 바뀌었나
대화형 AI에 고객 문의를 넣으면 보통 답변 문장이 돌아온다. 2026년 9월 15일 TypeSafe AI가 공개한 Jev는 이 흐름을 바꾼다. 문장을 쓰는 대신 입력된 상태와 개발자가 정의한 질문을 바탕으로 정해진 형식의 판단을 반환한다. TypeSafe AI의 공식 발표에 따르면 Jev는 회사가 ‘System One 모델’이라고 부르는 계열의 첫 모델이다.
핵심은 AI가 사람에게 보여줄 글을 만드는 데 있지 않다는 점이다. 고객 문의를 어느 부서로 보낼지, 문서가 특정 조건을 만족하는지 다음 단계로 진행해도 되는지를 코드가 바로 읽을 수 있는 값으로 돌려준다. 현재는 얼리 액세스 단계로 제공되고 있다.
왜 지금 중요한가
AI를 제품 안에 넣을 때 가장 번거로운 부분은 모델의 답변을 다시 프로그램이 이해해야 한다는 데 있다. 자유로운 텍스트를 JSON으로 유도하더라도 형식 오류와 애매한 표현을 검사하는 코드가 필요하다. Jev는 선택지를 미리 정해 결과 범위를 제한하고 그 안에서 선택값과 확률을 반환한다.
예를 들어 고객이 “카드에서 같은 금액이 두 번 빠져나갔다”고 문의했다고 하자. 애플리케이션은 문의 내용, 결제 기록, 환불 정책을 하나의 상태로 묶고 ‘환불을 요청했는가’, ‘중복 결제인가’, ‘어느 팀이 처리할 것인가’를 각각 물을 수 있다. Jev가 부서와 확률을 제시하더라도 실제 환불이나 담당자 배정은 애플리케이션의 규칙과 사람의 검토가 맡는다.
Jev는 어떻게 작동하나
Jev의 입력인 state는 판단에 필요한 자료다. 짧은 문자열 하나를 넣어도 되고 메시지·거래 기록·정책처럼 이름이 붙은 JSON 객체나 텍스트 배열을 넣어도 된다. 공식 문서는 상태와 질문을 분리하라고 안내한다. 상태에는 근거를 질문에는 알고 싶은 판단을 담는 방식이다.
질문 형식은 세 가지다. Choice는 정해진 선택지 중 하나를 고르고 Score는 순서가 있는 기준에서 정도를 매기며 Noul은 어떤 문장이 참일 가능성을 0에서 1 사이 값으로 나타낸다. 여러 질문은 한 요청에 함께 보내며 각 질문은 같은 상태를 독립적으로 평가한다.
복잡한 판단을 한 문장으로 몰아넣는 방식은 잘 맞지 않는다. ‘이 고객의 최선의 해결책은 무엇인가’라고 묻기보다 긴급성, 문의 유형, 환불 조건 충족 여부를 나눠 묻고 결과를 코드에서 조합하는 편이 적합하다. TypeSafe는 이런 구조가 정책이나 가중치를 바꿀 때 프롬프트 전체를 다시 쓰지 않아도 된다는 점을 강조한다.
처음에는 공식 Playground에 로그인해 상태를 붙여 넣고 질문을 추가하면 된다. 개발자는 대시보드에서 API 키를 받은 뒤 POST https://api.typesafe.ai/v1/systemone으로 요청할 수 있다. 요청에는 state, model의 jev-latest, questions를 넣고 Python SDK를 사용할 경우 pip install typesafe-sdk로 시작할 수 있다.
기존 LLM과 무엇이 다른가
두 방식의 차이는 목적과 출력 형식에서 가장 분명하다.
| 비교 항목 | Jev | 일반적인 LLM |
|---|---|---|
| 주된 목적 | 소프트웨어가 사용할 구조화된 판단 | 대화, 작성, 설명, 추론, 코드 생성 |
| 입력 | 상태와 타입이 지정된 질문 | 프롬프트와 대화 문맥 |
| 출력 | Choice·Score·Noul 결과와 확률 | 자유 형식의 생성 텍스트 |
| 애플리케이션 연결 | 결과를 바로 분기·정렬·라우팅 | 결과 파싱과 형식 검증이 필요할 수 있음 |
| 적합한 장면 | 분류, 라우팅, 점수화, 검증 | 보고서 작성, 답변 생성, 복잡한 설명 |
따라서 Jev는 일반 LLM을 전부 대체하는 제품이라기보다 역할이 다른 도구에 가깝다. LLM이 계획을 세우거나 문장을 작성하고 Jev가 특정 단계의 선택과 검증을 맡는 조합도 가능하다.
사용자·개발자·기업에 미치는 영향
개발자에게 가장 큰 변화는 모델의 답변을 해석하는 코드보다 판단 구조를 설계하는 일이 중요해진다는 점이다. 선택지에 ‘기타’나 ‘근거 부족’을 넣을지, 어느 확률에서 사람에게 넘길지, 여러 점수를 어떤 가중치로 합칠지를 먼저 정해야 한다.
사용자 화면은 크게 달라지지 않을 수 있다. 다만 문의가 적절한 부서로 가고 위험한 자동 처리가 보류되며 반복적인 분류가 빨라지는 식으로 간접적인 변화가 생긴다. 기업 입장에서는 고객지원 라우팅, 콘텐츠 검토, 에이전트의 도구 선택처럼 빈도가 높고 결과 범위가 제한된 업무부터 검토할 만하다.
반대로 결정의 책임까지 모델에 넘길 수는 없다. 확률과 신뢰도는 애플리케이션이 자동 실행과 사람 검토를 나누는 신호일 뿐이다. 실제 운영에서는 기록을 남기고 잘못된 분류가 초래할 비용을 기준으로 보수적인 임계값을 설정해야 한다.
한계와 주의할 점
타입이 맞는 결과가 나온다고 해서 판단 내용이 항상 옳은 것은 아니다. ‘billing’이라는 선택지가 반환됐다는 것은 형식에 맞는다는 뜻이지 실제 원인이 결제 시스템이라는 뜻은 아니다. 공식 문서도 확률 보정은 여러 예측 집단의 특성을 다루며 개별 답변의 정답을 보장하지 않는다고 설명한다.
현재 Jev는 텍스트 입력만 지원한다. 문자열, JSON 객체, 텍스트 배열은 받을 수 있지만 이미지·음성·영상은 지원하지 않는다. 또 TypeSafe 문서에 따르면 영어가 주요 학습 언어이며 한국어를 포함한 CJK 문자 입력은 가능하지만 정확도가 낮을 수 있다. 한국어 서비스라면 실제 문의 데이터로 별도 평가해야 한다.
Jev는 글, 코드, 설명을 생성하지 않는다. 고객에게 보낼 답변이나 사건 보고서를 작성해야 한다면 생성형 모델이 필요하다. Jev의 결과를 그대로 고객에게 보여주기보다 코드의 분기 조건이나 사람이 검토할 큐를 결정하는 내부 단계에 두는 편이 안전하다.
앞으로의 관전 포인트
앞으로는 회사가 제시한 속도·비용 비교보다 독립적인 평가가 중요하다. 특히 한국어 문의, 도메인별 용어, 모호한 사례에서 확률이 실제 오류 가능성을 얼마나 잘 반영하는지 확인해야 한다. 낮은 확률 사례를 사람에게 넘겼을 때 전체 운영 비용이 줄어드는지도 함께 봐야 한다.
접근 경로도 변할 수 있다. Jev는 자체 API와 SDK 외에 Vercel AI Gateway 같은 개발 플랫폼에서도 제공되기 시작했다. 모델 버전, 가격, 지역별 지연시간, 데이터 보관 정책이 초기 서비스 단계에서 어떻게 정리되는지가 실제 도입 여부를 가를 전망이다.
자주 묻는 질문
Jev AI는 챗GPT 같은 서비스인가요?
일반적인 채팅 서비스와는 다르다. Jev는 긴 답변을 만들어 주는 모델이 아니라 애플리케이션이 다음 행동을 정할 수 있도록 제한된 선택·점수·참값 확률을 반환하는 개발자용 모델이다.
Jev는 무엇을 입력하고 무엇을 반환하나요?
고객 메시지나 문서 같은 텍스트, 또는 관련 정보를 담은 JSON 상태를 입력한다. 그 상태에 대해 선택지 중 하나를 고르는 Choice, 기준에 따라 점수를 내는 Score, 참일 확률을 내는 Noul 질문을 보내면 타입이 정해진 결과와 확률을 받는다.
지금 바로 써볼 수 있나요?
공식 문서에는 Playground 로그인과 API 키 발급을 통한 시작 방법이 안내돼 있다. 다만 서비스가 얼리 액세스 단계인 만큼 계정 승인이나 제공 범위가 달라질 수 있으므로 실제 사용 전 공식 콘솔에서 현재 접근 조건을 확인해야 한다.
한국어로 사용할 수 있나요?
한국어를 포함한 CJK 문자 입력은 가능하지만 공식 문서는 영어 외 언어의 정확도가 낮을 수 있다고 밝히고 있다. 한국어 고객지원에 적용하려면 실제 업무 데이터를 익명화해 테스트하고 영어 사례의 결과를 그대로 한국어 성능으로 간주하지 않아야 한다.
확률이 높으면 자동 실행해도 되나요?
그 자체로는 충분하지 않다. 확률은 자동 처리와 사람 검토를 나누는 기준으로 활용할 수 있지만 과거에 검증된 사례와 비교해 임계값을 정하고 오답 비용이 큰 업무에는 승인 단계를 남겨야 한다.
한눈에 정리
Jev AI의 핵심은 ‘상태를 넣고 제한된 질문에 대한 결정을 받는 것’이다. 글쓰기나 대화보다 분류·라우팅·검증처럼 결과의 범위를 미리 정의할 수 있는 업무에 맞으며 일반 LLM과 함께 사용할 수도 있다.
관심이 있다면 먼저 작은 업무 하나를 골라 Playground에서 선택지와 질문을 설계해 보면 된다. 이후 한국어 실제 데이터로 정확도와 확률의 신뢰성을 확인하고 불확실한 결과는 사람에게 넘기도록 애플리케이션 규칙을 만든 뒤 도입 범위를 넓히는 순서가 현실적이다.