Jev의 아키텍처가 보여주는 것: 생성하지 않고 결정하는 AI

AI를 소프트웨어에 연결할 때 꼭 자연어 답변이 필요한 것은 아닙니다. 고객 문의를 어느 팀으로 보낼지, 거래가 위험한지, 사람이 검토해야 할지처럼 많은 업무는 문장보다 정해진 선택지와 그 확률이 더 유용합니다.

TypeSafe AI의 Jev는 이 지점을 겨냥한 early access 모델입니다. 공식 소개 ↗는 자유 텍스트를 생성하는 대신, 입력 state에 대해 미리 정의한 질문의 타입 안전한 결정을 확률과 함께 반환한다고 설명합니다. 최근 외부 API 관측 기반 분석 ↗은 이 제품이 왜 빠를 수 있는지에 대한 흥미로운 재구성도 제시했습니다.

먼저 결론부터 말하면, Jev에서 중요한 것은 “LLM보다 빠른 분류기”라는 한 줄이 아닙니다. 텍스트 생성·파싱·재시도를 줄이고, 불확실성을 명시적인 정책 입력으로 바꾸는 설계입니다. 다만 이 구조가 자동화를 안전하게 만들어 주지는 않습니다. 실제 업무 데이터에서 확률 보정과 선택지 변화에 대한 회귀 테스트가 먼저 필요합니다.

이 글에서 다루는 내용:

• 텍스트 생성 모델과 확률 기반 의사결정 API의 차이
• 공개 문서가 보장하는 인터페이스와 외부 관측이 시사하는 구조
• 확률을 자동 실행 임계값으로 사용할 때 필요한 검증

문장을 만들지 않는 모델은 무엇을 반환할까

Jev의 API reference ↗는 하나의 state와 이름 붙인 questions 맵을 받아 각 질문의 구조화된 답을 반환하는 형태를 설명합니다. API는 예/아니요(noul), 선택지 하나를 고르는 choice, 순서형 척도를 평가하는 score를 제공합니다.

flowchart TD
    A[애플리케이션 state] --> B[공통 문맥 처리]
    B --> C[질문: 긴급한가?]
    B --> D[질문: 담당 팀은?]
    B --> E[질문: 위험도는?]
    C --> F[확률 기반 정책]
    D --> F
    E --> F
    F --> G[사람 검토·라우팅·후속 코드]

예를 들어 고객 지원 메시지를 받았을 때, 모델이 “빠르게 확인해 보겠습니다”라는 문장을 쓰는 대신, 긴급성의 확률과 담당 부서 선택지를 반환합니다. 호출하는 코드는 그 값을 기준으로 Slack 알림, 담당팀 라우팅, 사람 검토 큐 같은 후속 동작을 명시적으로 결정합니다.

공식 문서의 choice는 선택된 값뿐 아니라 모든 선택지의 확률 분포와 confidence를 반환합니다. 따라서 애플리케이션은 단일 라벨만 받는 기존 분류기보다 더 많은 정보를 얻지만, 그 숫자를 곧바로 사실로 받아들이면 안 됩니다.

API는 결정의 모양을 먼저 고정합니다

공식 문서의 예시를 바탕으로 단순화하면, 요청은 다음처럼 구성합니다. state는 평가 대상 데이터이고, questions에는 질문과 허용 가능한 출력을 둡니다.

{
  "state": "고객의 지급이 3일째 실패하고 있습니다.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "이 요청은 긴급성을 표현하는가?"
    },
    "department": {
      "type": "choice",
      "instructions": "어느 팀이 처리해야 하는가?",
      "criteria": {
        "billing": "결제, 청구, 환불",
        "technical": "버그, 장애, 연동",
        "sales": "가격, 업그레이드, 신규 계정"
      }
    }
  }
}

이 인터페이스의 장점은 출력 파싱이 아니라 결정 공간 자체를 코드가 제한한다는 데 있습니다. choice에는 최대 255개 선택지를 넣을 수 있고, score에는 순서가 있는 척도를 정의할 수 있습니다. 반면 고객에게 보내는 자연스러운 설명, 열린 질문의 탐색, 코드 작성처럼 답의 형태가 열려 있는 작업은 여전히 생성 모델이 더 적합합니다.

외부 관측은 공유 문맥과 병렬 질문을 시사합니다

Archer Hume의 분석 글 ↗은 약 1만 회 API 호출을 통해 응답 지연, 토큰 집계, 질문 간 정보 전달을 관찰했습니다. 분석은 공통 state를 한 번 처리하고, 개별 질문은 서로 격리된 분기로 평가해 병렬 결과를 돌려주는 구조가 유력하다고 봅니다.

이 해석이 맞다면, 같은 고객 메시지를 바탕으로 긴급성·담당팀·위험도를 묻는 경우 공통 문맥을 매번 새로 만들 필요가 없습니다. 또한 토큰을 한 개씩 생성하는 자동회귀 디코딩을 생략하고 수치 확률을 직접 읽어내면, 긴 출력이 늘어날 때의 생성 지연도 피할 수 있습니다.

하지만 여기에는 중요한 경계가 있습니다. 공유 state, 질문별 분기, 직접적인 수치 출력은 관측 결과를 설명하는 재구성입니다. TypeSafe가 실제로 어떤 Transformer backbone, attention mask, 캐시, MoE 구조를 쓰는지는 공개되지 않았습니다. 가능한 구현과 실제 구현을 혼동하지 않는 것이 이 분석을 읽는 첫 번째 규칙입니다.

확률은 자동화의 끝이 아니라 정책의 시작입니다

확률을 제공하는 모델은 “90% 이상이면 자동 처리”처럼 단순한 규칙을 만들기 쉬워 보입니다. 그러나 공식 소개 ↗는 보정된 확률을 핵심 목표로 제시할 뿐, 특정 팀의 데이터 분포에서도 같은 보정 품질을 보장하지는 않습니다.

특히 외부 분석은 선택지 순서를 바꾸거나 무관해 보이는 선택지를 추가했을 때 기존 선택지의 확률도 바뀌는 관측을 보고합니다. 어떤 업무에서는 정상적인 상대 비교일 수 있지만, 임계값 부근에서 자동 실행 여부가 달라질 수 있다는 뜻이기도 합니다.

OpenAI와 Codex의 워크플로 수렴에서 다룬 것처럼, 모델이 잘하는 해석과 코드가 잘하는 검증을 분리하는 원칙이 여기에도 적용됩니다. Jev는 모델의 출력 형식을 좁히지만, 임계값·승인·재시도·감사 로그는 여전히 애플리케이션이 설계해야 합니다.

에이전트를 대체하기보다 한 단계를 좁힙니다

Jev는 장기 계획을 세우거나 코드베이스를 탐색하는 에이전트를 대체하는 모델이 아닙니다. 에이전트가 수집한 상태를 바탕으로 여러 독립 판단을 빠르게 내리거나, 사람이 매번 같은 기준으로 분류하던 구간을 자동화하는 쪽에 가깝습니다.

이 역할 분리는 장기 실행 앱의 harness 설계와도 연결됩니다. 시스템이 오래 실행될수록 “무엇을 결정했는가”보다 “어떤 근거와 임계값으로 다음 행동을 허용했는가”를 남기는 일이 중요해집니다. 여러 작업을 나눠 처리할 때도 Claude Code Agent Teams처럼 결과를 모으는 구조와 사람이 검토할 경계를 함께 설계해야 합니다.

Jev의 흥미로운 지점은 AI를 대화 상대로만 두지 않고, 소프트웨어 안의 확률적 if 문으로 취급한다는 데 있습니다. 그 전환이 효과를 내는 곳은 답이 열려 있는 작업이 아니라, 상태는 복잡하지만 행동 선택지는 제한된 작업입니다.

마무리

Jev와 그 아키텍처 분석은 생성형 AI의 반대편에 있는 설계를 보여 줍니다. 공통 문맥을 읽고, 여러 구조화된 질문에 확률로 답하며, 코드가 그 확률을 받아 정책을 실행하는 방식입니다.

도입 판단의 기준은 “얼마나 빨리 답하는가”만이 아닙니다. 해당 업무의 정답을 측정할 수 있는지, 선택지 설계가 안정적인지, 낮은 확신을 사람이 흡수할 수 있는지까지 확인해야 합니다. 모델의 구조가 아무리 효율적이어도, 운영 정책이 불분명하면 빠른 자동화는 빠른 실수가 될 수 있습니다.

참고 자료

• TypeSafe AI: Introducing System One Models & Jev ↗ — Jev의 공개 목표와 early access 설명
• TypeSafe API reference ↗ — state, questions, choice·score·noul 인터페이스
• Jev’s Architecture Unmasked ↗ — API 관측 기반 재구성과 한계
• GeekNews 소개 ↗ — 한국어 요약