우리가 이제까지 AI를 사용하는 패턴을 보면 질문에 답하고, 글을 쓰고, 코드를 만들어주는 것이 떠오른다. ChatGPT나 Claude 같은 LLM은 사람과 대화하는데 매우 강하다. 그러나 소프트웨어는 항상 대화가 필요한 것은 아니다.
예를 들어서 고객 문의를 어느 부서로 보낼지, 이 문서가 어떤 종류인지를 판단하는 것처럼 프로그램이 매번 의사결정을 해야 하는 것들이 많다. 이런 작업에 LLM을 사용하게 되면 답변을 읽고 판단하는 과정이 필요하다. 잘못 이해했을때는 프로그램 전체가 오작동 할 수 있다.
Jev AI는 이 문제를 해결하기 위해 나온 AI 모델이다. LLM과 다르게 구조화된 판단 결과를 반환한다. Typesafe AI가 만든 Jev는 2026년 9월 15일에 공개되었고, 현재는 얼리 액세스 형태로 제공되고 있다.
Jev AI는 챗봇이 아니다
Jev를 가장 쉽게 이해하는 방법은 챗봇과 반대되는 모델이라고 생각하는 것이다. 챗봇은 질문을 받으면 문장으로 답하는데, Jev는 소프트웨어가 판단에 사용할 수 있는 제한된 결과를 반환한다.
예를 들어서 고객이 "구독을 해지 했는데도 요금이 또 청구되었어요."라고 문의를 했다면, LLM은 이 내용을 해석 한 뒤 "결제 문제로 보입니다. 담당 부서에 문의하세요." 라는 문장을 답변할 수 있다.
Jev의 경우에는 아래처럼 질문을 정의할 수 있다.
"이 문의는 어느 팀이 처리해야 하는가?"
답변 선택지를 결제, 기술지원, 영업, 기타로 미리 정의해두면 Jev는 이 중 하나를 선택하고, 각 선택지의 확률과 신뢰도를 함께 반환한다. 소프트웨어는 답변 문장을 해석할 필요없이 결과에 따라 담당 팀을 정하면 된다.
TypeSafe의 공식 문서에서 Jev의 입력은 "state", 즉 판단에 필요한 상태 정보라고 설명한다. 상태에는 고객 메시지, 로그, 사용자 정보, 주문 정보, 정책 문서 등 여러가지가 들어갈 수 있다. 여기에 개발자가 정의한 질문을 함께 보내면 Jev가 구조화된 결과를 돌려주게 된다.
세 가지 방식으로 질문한다
Jev의 질문은 크게 세 가지 종류로 나뉜다. Choice, Score, Noul이다.
Choice는 정해진 선택지 중 하나를 고르는 방식이다. 고객 문의 분류, 담당 부서 라우팅, 다음에 실행할 도구 선택 등에 사용할 수 있다. 선택지가 환불, 재예약, 정보 요청이라면 Jev는 이 중 가장 적합한 항목을 고른다.
Score는 기준에 따라 상태를 점수화하는 방식이다. 예를 들어 고객의 불만 정도를 차분함, 우려를 표시함, 매우 화남 같은 단계로 평가할 수 있다. 버그의 심각도, 문서의 품질, 위험 수준, 구매 가능성 등도 점수를 다룰때 적합하다.
Noul은 어떤 문장이 참일 가능성을 0과 1 사이의 값으로 반환한다. "고객이 환불을 요청했는가?", "이 문장에는 개인정보가 포함되어 있는가?", "이 요청이 긴급한가?" 같은 질문에 사용할 수 있다. 응답이 0.9라면 그렇다고 볼 가능성이 높고, 0.5 아래라면 판단하기 어렵다는 뜻으로 해석할 수 있다.
위 세 가지 질문 타입은 한번에 사용할 수 있다. 같은 상태를 기준으로 여러 질문을 병렬 처리하기 때문에 고객 문의 하나에 대해서 문의 유형, 긴급도, 감정 수준, 환불 요청 여부를 한꺼번에 확인하는 방식으로 사용할 수 있다. 공식 문서에는 질문을 작고 명확하게 나누고, 여러 결과를 최종적으로 조합하는 작업은 코드로 담당하도록 권장한다.
환각이 없다라는 말의 의미
Jev를 소개하는 자료에는 환각이 없다라는 표현이 자주 등장한다. 이 말의 의미에 대해 생각해볼 필요가 있다.
Jev가 환각에 강하다는 주장은 출력 공간이 제한되어 있다는 의미이다. 개발자가 선택지를 미리 정했기 때문에 Jev가 존재하지 않는 선택지를 새로 만들어 내거나, 답변 형식을 마음대로 변경하는 일은 구조적으로 어렵다. 즉, 자유롭게 문장을 생성하지 않기에 LLM에서 나타나는 오류가 줄어든다.
그러나 Jev의 판단이 항상 맞는 것은 아니다. 잘못된 정보를 입력했거나, 선택지를 잘못 설계했거나, 질문이 모호하면 Jev는 제한된 선택지 안에서 틀린 답을 고를 수 있다. 즉, 없는 답을 만들어내지 않는다는 것과 항상 정답을 고른다는 것은 다른 문제이다.
위에서 언급한 차이를 이해하는 것이 매우 중요하다. Jev는 환각을 완전히 없앤 만능 판정기가 아니라, 출력 형식을 통제할 수 있는 판단 모델이다. 최종적으로 어떤 결과를 실행할지 등은 여전히 Jev를 이용하는 소프트웨어가 결정해야 ㅎ한다.
확률과 신뢰도를 함께 제공
Jev의 특징은 답변과 함께 확률 정보를 제공한다는 점이다. Choice는 각 선택지의 확률 분포와 confidence 값을 반환하고, Score는 점수별 확률과 신뢰도를 반환한다. Noul은 참일 가능성을 0과 1 사이의 값으로 제공한다.
이 기능은 자동화에서 특히 중요하다. 모든 판단을 무조건 자동 실행하는 것이 아니라 확신의 정도에 따라 다른 경로를 만들 수 있기 때문이다.
예를 들어 고객 문의를 분류할 때 신뢰도가 0.95 이상이면 자동으로 담당 부서에 보낼 수 있다. 0.7 정도라면 고객에게 추가 정보를 요청하거나 검토 대기열에 넣을 수 있다. 0.5 이하라면 사람이 직접 확인하도록 만들 수 있다.
다만 신뢰도 역시 정답 보증서가 아니다. 신뢰도가 높다고 해서 개별 답변이 반드시 맞는 것은 아니다. 여러 사례를 모았을 때 높은 확률을 받은 결과가 실제로도 비슷한 비율로 맞아야 한다는 것이 ‘확률 보정’의 핵심이다. 따라서 실제 서비스에 적용할 때는 자체 데이터로 테스트하고, 결제 승인이나 계정 정지처럼 위험한 작업에는 더 높은 기준을 적용해야 한다.
TypeSafe의 문서도 모든 상황에 하나의 기준값을 적용하지 말고, 실수했을 때의 위험도에 따라 임계값을 다르게 설정하라고 설명한다. 단순한 화면 이동은 낮은 기준으로 자동화할 수 있지만, 송금이나 환불처럼 되돌리기 어려운 작업은 사람의 확인을 거치는 방식이 적절하다.
기존 LLM보다 빠르고 저렴할까?
TypeSafe는 Jev의 응답 시간이 약 70ms~500ms라고 소개한다. 입력 토큰 가격은 100만 개당 0.042달러이며, 일반적인 문장 생성 토큰을 만들지 않기 때문에 출력 토큰은 무료라고 설명한다. 공식 홈페이지는 특정 System One 작업을 기준으로 기존 LLM보다 193.6배 빠르고 444.6배 저렴했다는 비교도 제시한다.
이 수치는 흥미롭지만 그대로 모든 상황에 적용되는 것은 아니다. TypeSafe가 공개한 비교는 특정 워크플로와 비교 모델, 입력 구성, 실행 환경을 기준으로 한 결과다. 회사 스스로도 공개 평가가 자사 팀이 만든 워크플로를 사용했고, 비교 기준에는 다른 대형 모델의 응답이 활용됐으며, 결과가 실제 환경의 모든 작업을 대표하지는 않는다고 설명한다.
따라서 “모든 AI보다 400배 싸다”라고 이해하기보다는, 짧고 반복적인 판단을 대량으로 처리하는 작업에서 비용과 지연시간을 크게 낮출 수 있다는 의미로 보는 편이 정확하다. 긴 글을 생성하거나 복잡한 추론을 여러 단계 수행하는 작업이라면 일반 LLM이 더 적합할 수 있다.
어떤 곳에 활용할 수 있을까?
Jev가 가장 잘 맞는 분야는 소프트웨어 안에서 반복되는 작은 의미 판단이다.
첫 번째는 고객지원 자동화다. 문의 내용을 결제, 배송, 환불, 기술지원 등으로 분류하고, 긴급도나 고객의 불만 수준을 판단한 뒤 적절한 팀으로 보낼 수 있다. 상담원이 작성한 답변이 실제 계정 상태와 일치하는지도 검사할 수 있다.
두 번째는 AI 에이전트의 안전장치다. 에이전트가 환불, 삭제, 송금, 외부 메시지 발송 같은 도구를 호출하기 전에 해당 작업을 실행해도 되는지 확인하는 계층으로 사용할 수 있다. 신뢰도가 낮으면 사람에게 승인을 요청하도록 만들 수 있다. (내가 고민하는 활용 부분이다.)
세 번째는 문서와 데이터 처리다. 세금계산서가 실제 거래처에서 온 문서인지, 이미 결제된 문서인지, 사기 가능성이 있는지 확인하는 데 활용할 수 있다. TypeSafe가 공개한 송장 처리 예시도 문서를 여러 단계의 질문으로 나누고, 숫자 계산이나 날짜 비교는 일반 코드로 처리하는 구조를 사용한다.
네 번째는 실시간 서비스다. 사용자의 의도를 빠르게 분류해 화면을 바꾸거나, 스트리밍 콘텐츠를 검토하거나, 수많은 요청 중 추가 검토가 필요한 사례만 골라낼 수 있다. 이런 환경에서는 응답 시간이 짧고 결과 형식이 일정하다는 점이 장점이 된다.
Jev가 적합하지 않은 작업
Jev는 LLM의 대체품이 아니다. 이메일을 작성하거나, 글을 요약하거나, 코드를 만들어 내거나, 사람과 자연스럽게 대화하는 일에는 적합하지 않다. 설명이 필요한 답변이나 창의적인 결과물을 만들 때도 일반 LLM을 사용해야 한다.
복잡한 판단을 하나의 질문으로 몰아넣는 것도 좋은 방법이 아니다. “이 사업계획서를 종합적으로 평가하고 투자 여부를 결정해줘”와 같은 질문은 여러 요소를 동시에 고려해야 한다. Jev의 방식에서는 시장 규모, 기술 가능성, 경쟁력, 위험 요소를 각각 별도의 질문으로 나눈 뒤 코드에서 가중치를 적용하는 편이 적절하다.
또한 선택지 설계가 매우 중요하다. 실제 입력에 맞지 않는 선택지만 제공하면 Jev는 ‘기타’나 ‘판단 불가’ 같은 항목을 선택하지 못하고 억지로 가장 가까운 항목을 고를 수 있다. 그러므로 선택지를 만들 때는 ‘해당 없음’, ‘추가 검토’, ‘정보 부족’ 같은 탈출구를 포함하는 것이 좋다.
개인정보와 보안도 확인해야 한다. TypeSafe의 개인정보 처리방침은 서비스에 입력한 프롬프트와 데이터를 AI 모델의 학습이나 미세 조정에 사용하지 않는다고 밝히고 있다. 동시에 입력 데이터는 서비스 제공과 운영을 위해 처리되며, 서비스 제공업체와 공유될 수 있고, 서비스가 미국에서 호스팅된다고 설명한다. 민감한 데이터를 보낼 때는 회사의 보안 정책을 함께 검토해야 한다.
결론
Jev의 핵심은 더 똑똑한 챗봇을 만드는 데 있지 않다. AI를 소프트웨어 안에 넣는 방식 자체를 바꾸려는 시도에 가깝다.
기존 방식에서는 LLM에게 문장을 생성하게 한 뒤, 프로그램이 그 문장을 다시 해석해야 했다. Jev는 처음부터 프로그램이 사용할 결과를 정하고, 그 범위 안에서 판단하도록 만든다. 이 차이는 단순히 응답 형식의 차이가 아니다. 자동화 시스템을 설계할 때 AI의 역할과 일반 코드의 역할을 분리할 수 있다는 뜻이다.
AI는 애매한 의미 판단을 맡고, 코드는 계산과 규칙, 권한, 실행을 맡는다. 신뢰도가 낮은 경우에는 사람이나 더 강력한 LLM으로 넘긴다. 이런 구조라면 모든 작업을 하나의 거대한 모델에 맡기지 않고, 필요한 곳에 필요한 수준의 지능을 배치할 수 있다.
현재 Jev는 공개된 지 얼마 되지 않은 얼리 액세스 제품이다. 회사가 제시하는 속도와 가격은 분명 매력적이지만, 실제 서비스에 도입하기 전에는 자체 데이터로 정확도와 확률 보정을 확인해야 한다. 특히 금융, 의료, 보안처럼 실수의 비용이 큰 분야에서는 낮은 신뢰도 결과를 자동 실행하지 않는 안전장치가 필수다.
결국 Jev는 ‘말을 잘하는 AI’가 아니라 ‘소프트웨어가 다음 행동을 선택하도록 돕는 AI’다. 글쓰기와 대화는 기존 LLM이 담당하고, 분류, 라우팅, 점수화, 검증처럼 반복되는 판단은 Jev가 담당하는 식으로 함께 사용할 수 있다.
Jev의 가능성은 LLM을 대체하는 데 있지 않고, 지금까지 사람이 일일이 작성한 복잡한 if문과 비효율적인 LLM 호출 사이에 새로운 선택지를 제공하는 데 있다고 생각한다.
0 Comments:
댓글 쓰기