고객 문의를 교환 담당자에게 보낼지 배송 담당자에게 보낼지 정하는 기능에 긴 AI 답변은 필요 없다. 프로그램이 쓸 것은 담당 부서 하나다. TypeSafe가 9월 15일 얼리 액세스로 공개한 Jev는 이런 판단을 겨냥한다. 상황과 미리 정한 질문·선택지를 받아, 문장을 생성하는 대신 코드가 바로 읽을 수 있는 값과 확률을 반환하는 모델이다.
개발자 Sean Goedecke는 9월 16일 분석에서 Jev의 가능성을 챗봇 밖에서 찾았다. 소프트웨어가 갈림길을 만날 때마다 짧고 저렴한 판단을 끼워 넣자는 것이다. 동시에 그는 속도 향상 중 얼마가 새 모델의 성능이고 얼마가 출력 방식을 바꾼 효과인지 나눠 봐야 한다고 지적했다. AI 제품팀은 새 모델 도입을 검토할 때 기존 모델의 출력 방식도 바꿔 비교해 볼 수 있다.
게임을 조작하는 AI는 무엇을 입력받을까
TypeSafe의 Doom 시연은 쓰임을 이해하기 쉽다. 모델은 현재 상황에서 발사할지, 어떤 목표를 우선할지, 어느 방향으로 움직일지를 판단한다. 시연의 판단 패널에는 각 질문의 선택지와 판단 결과가 나타난다. 이 시연에서 모델에 들어가는 것은 게임 화면 이미지가 아니라 텍스트로 표현한 구조화된 게임 상태다. Jev가 화면을 보고 적을 찾아내는 영상 인식 시연과는 구별해야 한다.
업무용 제품으로 옮기면 문의 담당 부서 배정, 문서 분류, 다음 처리 경로 선택 같은 기능이 된다. 사람이 작성한 규칙만으로는 다양한 표현을 다루기 어렵지만, 결과로 허용할 행동은 몇 가지로 정해져 있는 자리다. 예컨대 “다른 사이즈로 바꾸고 싶다”는 문의를 교환으로 분류한 뒤, 주문 조회와 교환 가능 기간 확인은 기존 코드가 맡을 수 있다. 이때 AI는 고객에게 설명문을 쓰는 역할과 분리된다.
긴 JSON을 없애면 기존 모델도 빨라질까
일반적인 언어모델은 출력 토큰을 순서대로 만든다. JSON 형식을 강제해도 긴 객체를 생성하는 동안에는 중괄호와 필드명, 값 등을 출력하는 과정이 이어진다. Jev는 같은 상태에 대한 여러 질문을 병렬로 평가하고 구조화된 결과를 반환한다. API 응답을 JSON으로 받는 것과 모델이 JSON 문자열을 토큰마다 생성하는 것은 다른 문제다.
Goedecke가 제시한 대조군은 기존 언어모델의 출력을 미리 채워 두고 허용된 선택지에 해당하는 토큰 하나만 생성하게 하는 방식이다. 여러 판단은 일반적인 추론 배치 처리로 묶을 수 있다는 설명도 덧붙였다. 긴 선택지 이름은 한 토큰짜리 식별자로 대응시키는 등의 처리가 필요하므로, 아무 JSON 출력에나 그대로 적용하는 요령은 아니다.
그는 Qwen2.5-1.5B-Instruct로 직접 시도했을 때 응답을 미리 채우지 않은 구조화 출력보다 2~3배 빨랐다고 각주에 적었다. 이는 저자의 실험 보고이며 Jev와의 직접 대결 결과가 아니다. 전용 학습과 최적화가 Jev에 이점을 줄 수 있다는 점도 그의 분석에 포함돼 있다. 따라서 “기존 모델로 완전히 대체된다”거나 “새 아키텍처만이 이 속도를 낸다”는 결론 모두 이 실험에서 나오지 않는다.
TypeSafe는 종단 간 응답시간 70~500ms와 System One 형태의 질의에서 40~200배 속도 향상을 내세운다. 공식 발표는 평가를 주로 서비스가 있는 미국 서부의 노트북에서 실행했다고 설명한다. 나란히 보여 준 시연은 짧고 밀도 높은 입력과 기본 추론 설정의 GPT-5.6 Terra를 사용했다. 별도 워크플로 평가에서 나온 193.6배 빠름·444.6배 저렴함은 회사도 실제 개선 폭의 높은 쪽에 해당할 것으로 예상한다. 한국 서비스의 긴 입력·망 지연·동시 요청을 포함한 수치로 옮겨 쓸 수는 없다.
“환각이 없다”는 말이 막아 주지 못하는 오류
TypeSafe는 Jev가 환각을 만들 수 없다고 홍보한다. 공식 설명에서 보장하는 것은 미리 정한 스키마에 맞는 출력이다. 발표의 오류율 도표에 들어간 Jev의 0%도 실험에서 모든 판단이 맞았다는 값이 아니라 스키마 일치 보장에서 온 값이라고 회사는 명시했다. “교환·배송·결제” 중에서만 고르는 모델도 교환 문의를 결제로 잘못 보낼 수 있다. Goedecke가 비판한 지점도 이 차이다. 선택지 밖의 답을 만들지 않는 것과 맞는 선택지를 고르는 것은 별개의 성질이다.
공식 Choice 문서에도 판단이 갈리는 사례가 나온다. 신발이 늦게 도착했고 사이즈가 틀렸으며 이중 결제까지 됐다는 고객은 원하는 해결책을 명확히 말하지 않는다. 문서의 응답 예시에서 모델은 환불에 0.40, 같은 상품 재배송에 0.34, 교환에 0.24, 정보 안내에 0.02의 확률을 부여한다. 가장 높은 값은 환불이지만, 예시 코드는 바로 환불하지 않고 고객에게 무엇을 원하는지 묻는다.
여기서 confidence는 선택지 확률분포의 모양을 요약한 별도 값이다. 위 예시에서는 0.20이며, 이를 곧바로 “정답일 확률 20%”로 읽으면 안 된다. 문서의 확인 기준 0.50도 해당 예시의 설정이다. 실제 제품에서는 검증 데이터의 정답과 대조해 자동 처리할 범위를 정해야 한다. 목록에 맞는 답이 없을 때를 위한 “기타·해당 없음”도 필요하다. 정답이 목록에서 빠진 요청을 기존 부서 중 하나로 강제 배정하지 않도록 해야 한다.
제품팀은 어떤 비교를 해야 도입을 결정할 수 있을까
첫 실험은 기존의 긴 JSON 생성, 같은 언어모델의 제한된 선택 출력, Jev를 같은 업무 데이터로 비교하는 편이 낫다. 확률이 필요한 기능이라면 세 경로 모두 확률까지 반환하게 하고, 담당 부서 하나만 필요한 기능이라면 그 조건으로 맞춘다. TypeSafe도 확률을 포함하도록 만든 자사 LLM 비교 래퍼가 확률 없이 결정만 받는 방식보다 느리고 비싼 경향이 있다고 설명한다.
지연시간은 평균만 보지 말고 느린 요청이 얼마나 늦어지는지도 확인해야 한다. 같은 입력 길이와 동시 요청 수에서 p95, 즉 요청의 95%가 끝나는 시간까지 재면 고객이 기다리는 상황을 비교하기 쉽다. 정확도는 형식 오류와 오선택을 분리하고, 확신이 높다고 자동 처리한 요청에서 얼마나 틀렸는지 따로 센다. 한국어 문의를 다룬다면 한국어 평가 묶음을 써야 한다. 공식 모델 문서는 영어에서 정확도가 가장 높고 다른 언어는 같은 수준이 아니라고 밝힌다.
비용도 호출 단가에서 끝나지 않는다. 9월 20일 공식 문서의 Jev 입력 가격은 100만 토큰당 0.042달러이고 출력 토큰은 무료다. 질문과 선택지를 늘리면 입력 토큰이 늘어난다. 재시도, 추가 확인, 사람에게 넘긴 건까지 합쳐 업무 한 건을 처리하는 비용을 비교해야 한다. 분류 결과로 실제 환불이나 권한 변경을 실행한다면 모델의 높은 확신과 별개로 승인·권한 검사를 유지해야 한다.
시작할 곳은 답이 정해져 있고 잘못 보냈을 때 되돌리기 쉬운 기능이다. 문의 배정 한 곳에서 선택 오류와 대기시간을 함께 줄일 수 있는지 먼저 측정하면 된다. 긴 설명이나 복잡한 추론이 필요한 작업은 그대로 두고, 짧은 판단을 맡길 부분부터 분리하는 접근이다.
출처: Sean Goedecke, Jev means structured output is interesting again · TypeSafe Jev 발표 · 개요 · Choice · Confidence · 모델·가격