실행 프로그램과 확장
Jev는 무엇인가: 답변을 쓰지 않고 결정을 내리는 System One 모델
Jev가 빠르다는 이야기를 들으면 작은 LLM이 답을 짧게 쓰는 모습부터 떠올리기 쉽습니다. 실제 방향은 다릅니다. 긴 설명을 생성하지 않고, 프로그램이 미리 정한 후보 가운데 무엇이 맞는지와 얼마나 확신하는지를 돌려줍니다. 그래서 상담 분류나 정책 확인처럼 같은 종류의 판단이 계속 쌓이는 곳에서 눈에 띕니다. 글을 쓰는 AI와 무엇이 다른지부터 차근히 보겠습니다.
질문을 던지는 방식부터 다릅니다
일반 챗봇에는 상황을 적고 무엇을 해야 하는지 물어봅니다. Jev에는 상황과 함께 판단 항목, 가능한 답을 프로그램이 정해서 보냅니다. 예를 들어 고객 문의 본문을 주고 담당 부서를 billing, access, security 가운데 고르게 하거나, 문장이 정책을 위반했는지 yes와 no로 판단하게 합니다. 출력은 자연어 설명이 아니라 선택값, 각 후보의 확률과 신뢰도입니다. 사람이 읽을 글보다 다음 코드가 바로 사용할 값을 만드는 데 초점을 둡니다.
빠른 이유는 말을 줄여서가 아닙니다
LLM이 JSON을 만들어도 중괄호와 키, 값과 설명을 앞 토큰에 이어 한 토큰씩 써야 합니다. 길이가 짧아도 여러 번의 순전파가 이어집니다. Jev는 가능한 출력 구조를 먼저 알고 있으며 여러 판단을 병렬로 계산합니다. TypeSafe는 자사 서비스의 종단 지연을 70~500ms 범위로 설명하지만, 이 숫자를 모든 지역과 모든 요청의 보장값으로 읽으면 안 됩니다. 입력 길이, 판단 개수와 네트워크를 포함한 조건을 맞춰야 비교가 됩니다.
잘못된 형식은 막아도 잘못된 판단은 남습니다
허용된 선택지 밖의 문자열이나 깨진 JSON이 나오지 않는 것은 자동화에 큰 장점입니다. 그렇다고 선택한 항목이 항상 맞는 것은 아닙니다. 모델은 모호한 문장이나 학습하지 못한 업무 규칙을 잘못 해석할 수 있고, 높은 확률을 틀린 후보에 줄 수도 있습니다. 실제 적용 전에는 틀렸을 때의 비용을 정하고 낮은 신뢰도의 결과를 사람에게 보내거나 기존 규칙으로 되돌리는 경로를 둬야 합니다. 타입 안전성과 업무 정확도를 같은 말로 쓰지 않는 것이 중요합니다.
일반 LLM보다 잘 맞는 일
분류, 라우팅, 위험 점수, 후보 순위, 내용 지원 여부처럼 답의 모양을 미리 정할 수 있는 일이 잘 맞습니다. 같은 문서를 읽고 여러 규칙을 확인하거나 한 요청을 어느 도구로 넘길지 고르는 장면도 후보입니다. 반대로 보고서를 쓰고 코드를 고치며 사용자와 이유를 주고받는 일은 자유로운 문자열 생성이 필요합니다. 이때는 Jev형 판단기를 LLM 앞뒤에 붙여 요청을 고르거나 결과를 검사하는 편이 자연스럽습니다. 하나가 다른 하나를 완전히 대체한다고 보면 용도를 놓칩니다.
로컬에서 보이는 것은 Jev 그 자체가 아닙니다
TypeSafe는 Jev의 가중치와 훈련 방식을 공개하지 않았습니다. 최근 로컬 프로젝트는 공개 Qwen 체크포인트에서 선택지 토큰의 점수를 읽거나, 공통 문서를 한 번 프리필한 뒤 질문 가지를 나누는 방법으로 비슷한 API와 사용 경험을 만듭니다. 아이디어와 인터페이스를 재현하는 실험이지 비공개 모델의 복제본은 아닙니다. 따라서 속도와 정확도, 확률 보정은 프로젝트마다 따로 검증해야 합니다. 다음 글에서는 어떤 구현이 작은 PC용이고 어떤 구현이 서버용인지 나눠봅니다.
