Jev 대기열 앞에서 Luna와 오픈소스로 먼저 검증하는 법

TypeSafe AI의 Jev가 등장하자 개발자들의 질문은 기능보다 접근법에 쏠렸다. 초대를 기다려야 할까. 아니면 Luna나 오픈소스 모델로 같은 구조를 먼저 만들 수 있을까. 답은 모델 교체가 아니라 ‘결정 계층’을 먼저 분리하는 데 있다.

Jev는 답변 생성 대신 제한된 결정을 반환한다

TypeSafe AI는 2026년 9월 중순 Jev를 초기 공개했다. 회사는 Jev를 소프트웨어 내부 판단에 특화한 첫 ‘System One Model’로 설명한다. 입력 상태와 질문을 보내면 문장 대신 타입이 정해진 값과 확률을 돌려준다.

인터페이스는 세 가지다. Choice는 지정된 후보 중 하나를 고른다. Score는 단계별 기준에 점수를 매긴다. Noul은 어떤 명제가 참일 확률을 0과 1 사이 값으로 반환한다. 여러 질문을 한 요청에 넣어 병렬 평가할 수도 있다.

가령 Claude Code 에이전트의 실행 기록을 검사한다고 하자. 상태에는 사용자 요구, 도구 호출, 수정 파일, 테스트 결과를 넣는다. 질문에는 “사람 검토가 필요한가”, “실패 수준은 몇 단계인가”, “실패 유형은 무엇인가”를 각각 Noul, Score, Choice로 지정한다.

{
  "model": "jev-latest",
  "state": {
    "task": "결제 오류 수정",
    "tool_calls": ["read_file", "apply_patch", "test"],
    "test_result": "2 failed"
  },
  "questions": {
    "needs_review": {
      "type": "noul",
      "instructions": "사람이 결과를 검토해야 하는가"
    },
    "failure_mode": {
      "type": "choice",
      "instructions": "가장 가까운 실패 유형은 무엇인가",
      "criteria": {
        "none": "실패 없음",
        "test": "테스트 실패",
        "scope": "요청 범위를 벗어남"
      }
    }
  }
}

Jev의 역할은 코드를 작성하는 에이전트를 대체하는 것이 아니다. 에이전트 앞에서는 작업을 분류하고 뒤에서는 결과를 판정한다. TypeSafe 문서도 라우팅, 복합 점수, 신뢰도 기반 분기를 핵심 패턴으로 제시한다.

Claude Code에서는 평가 하네스부터 붙일 수 있다

TypeSafe는 Python·JavaScript SDK와 Claude Code용 Agent Skill을 제공한다. 플러그인 마켓을 추가한 뒤 typesafe@typesafe-ai를 설치하면 API 구조와 질문 작성법을 에이전트 문맥에 넣을 수 있다. 직접 호출할 때는 POST /v1/systemone에 상태와 질문을 보낸다.

실전 순서는 짧다. 먼저 성공과 실패가 분명한 과거 실행 기록을 JSONL로 모은다. 다음으로 한 질문에 한 판단만 담아 사람이 붙인 정답과 모델 결과를 비교한다. 마지막에는 신뢰도 구간별 행동을 코드로 고정한다.

예를 들어 0.85 이상이면 자동 통과시키고 0.55부터 0.85까지는 검토 대기열로 보낼 수 있다. 그보다 낮으면 재질문하거나 다른 모델로 넘긴다. 기준값은 Jev의 예시를 복사하지 말고 자체 데이터로 정해야 한다.

써본 사람들 사이에서는 질문을 잘게 나눌수록 결과를 다루기 쉬웠다는 반응이 나온다. 반대로 긴 로그 전체를 넣으면 중요한 단서가 묻힌다는 불만도 있다. 에이전트 기록을 요약하거나 관련 구간만 골라 상태로 전달하는 전처리가 필요하다.

Luna는 당장 쓸 수 있지만 같은 제품은 아니다

OpenAI의 GPT-5.6 Luna는 저비용·대량 처리용 범용 모델이다. 공식 문서 기준으로 Structured Outputs를 지원하며 입력 100만 토큰당 0.20달러와 출력 1.20달러다. 문장 생성, 추론, 도구 호출까지 맡길 수 있다는 점이 Jev와 다르다.

Luna로 Jev형 흐름을 만들려면 JSON Schema에 decision, confidence, reason 같은 필드를 선언한다. Claude Code에는 작업 로그를 읽고 스키마에 맞춰 판정하는 스크립트를 만들도록 요청한다. 처음에는 Luna나 Gemini 계열로 데이터와 임계값을 검증한 뒤 Jev 호출부로 교체할 수 있다.

다만 LLM이 스스로 적은 confidence: 0.9는 Jev가 반환하는 선택지 분포와 같지 않다. 스키마 준수는 출력 형태를 보장하지만 확률의 보정까지 보장하지 않는다. Luna는 판단 이유가 필요하거나 후보를 동적으로 만들어야 할 때 유리하다. Jev는 후보가 이미 정해진 반복 판단에 더 가까운 도구다.

초기 접근권을 기다릴 필요도 줄었다. Langfuse가 확인한 경로에 따르면 Jev는 TypeSafe 대기열 외에 OpenRouter와 Vercel AI Gateway에서도 시험할 수 있다. 다만 운영에 넣기 전에는 모델 버전을 고정해야 한다. 임계값을 쓰는 평가기는 모델 변경만으로 통과 비율이 달라질 수 있다.

SemIf와 Needle 3는 다른 방식의 대안을 보여준다

Jev 공개 직후 독립 프로젝트 SemIf가 등장했다. 처음에는 OpenJev라는 이름을 썼지만 현재는 TypeSafe와 무관한 실험임을 밝히고 있다. Qwen3, MiniCPM 같은 로컬 모델의 선택지 로짓을 읽어 브라우저에서 확률 분포를 만드는 방식이다.

재료는 상태 문장, 질문, 허용된 선택지다. 모델을 브라우저에 내려받아 선택지별 로짓만 정규화하면 토큰 단위 JSON 생성 없이 결과를 얻는다. 입력이 외부 서버로 나가지 않고 대기열도 없다.

그러나 SemIf가 반환하는 값은 화면에 제시된 선택지 사이의 조건부 확률이다. 프로젝트도 이를 보정된 신뢰도로 주장하지 않는다. Jev 품질과 동등하다고 내세우지도 않는다. 로컬 분류기의 가능성을 검증하는 실험대에 가깝다.

Cactus의 Needle 3도 주목할 만하다. 8~29MB 바이너리로 도구 선택과 구조화 추출을 기기 안에서 처리한다. Python 함수의 타입과 설명을 도구 정의로 쓰며 결과의 신뢰도가 기준보다 낮으면 호출을 보류할 수 있다. Jev의 범용 판정 API와 같지는 않지만 정해진 도구를 빠르게 고르는 에이전트에는 현실적인 대안이다.

모델보다 거부 경로를 설계해야 한다

Jev는 정해진 선택지 밖으로 답할 수 없다. unknown이나 needs_review를 만들지 않으면 가장 덜 틀린 후보를 고르게 된다. 이유를 생성하지 않으므로 감사 기록이나 고객 설명이 필요한 단계에는 범용 LLM을 함께 둬야 한다.

TypeSafe의 속도와 비용 수치는 회사가 정한 System One 작업 기준이다. 독립된 장기 운영 자료는 아직 많지 않다. 빠른 분류가 필요한 개인 개발자라면 같은 데이터셋을 Jev, Luna, 로컬 모델에 돌려 정확도와 지연 시간을 직접 기록해야 한다.

대기열은 핵심 장애물이 아니다. 오늘 만들 수 있는 부분은 state → typed decision → confidence gate → human review라는 네 단계다. 이 경계를 코드로 고정해 두면 Jev를 쓰든 Luna를 쓰든 다음 오픈소스 모델이 나오든 에이전트의 안전장치는 그대로 남는다.