Jev System One 모델: 확률을 읽는 법과 에이전트 도입 실험

9월 18일과 20일, 클립 피드에 Jev 영상이 두 개 들어왔다. 채팅보다 판단에 초점을 둔 모델이라는 설명이 눈에 들어왔다. 내 블로그 자동화에도 글을 쓰는 일과 공개해도 되는지 검사하는 일이 섞여 있다. 두 작업에 같은 방식으로 모델을 호출할 필요가 있는지 궁금했다.

이번에는 TypeSafe와 LangChain의 공식 문서를 읽고 응답 구조와 적용 범위를 확인했다. 9월 20일 TypeSafe 웨이트리스트에 등록했고, 아직 API 실험은 하지 않았다. 아래의 뉴스 필터와 라우팅 설계는 앞으로 비교할 계획이다. 업체가 공개한 성능과 내가 얻은 성과를 섞지 않으려 한다.

Jev에 주는 입력과 코드가 받는 답

TypeSafe는 Jev를 System One 모델로 소개한다. 개발자는 판단에 필요한 상태인 state와 질문을 보내고, 코드에서 분기할 수 있는 답을 받는다. 사용자에게 보여 줄 설명문을 쓰는 용도로는 별도의 생성 모델이 필요하다. TypeSafe 소개 문서는 한 상태에 여러 질문을 보내되 각 질문을 독립적으로 평가한다고 설명한다.

내가 붙여 보고 싶은 뉴스 필터를 예로 들면, 상태에는 기사 제목과 요약, 발행 시각, 출처를 넣을 수 있다. 질문은 “내 관심 주제와 관련이 있는가”, “어느 검토함으로 보낼까”, “후속 확인이 얼마나 필요한가”로 나눈다. 이는 설명을 위한 설계 예시이며 실제 Jev 응답을 기록한 사례가 아니다.

질문을 나누면 규칙을 바꿀 위치도 드러난다. 관련성이 낮아도 보안 공지라면 사람이 확인하게 할 수 있다. 중요한 기사와 새로운 기사를 구분하면 이미 읽은 중요한 기사가 매일 다이제스트를 차지하는 일도 줄일 수 있다. 모델이 여러 조건을 한 번에 압축한 점수 하나를 반환하게 하기보다, 운영자가 합치는 규칙을 관리하는 편이 내 작업에는 맞는다.

질문 형식에 따라 숫자의 의미가 달라진다.

형식	질문 예시	읽어야 할 값
Noul	내 관심 주제와 관련이 있는가	참일 확률인 `noul`
Choice	읽기·보류·제외 중 어디로 보낼까	선택값, 보기별 확률, `confidence`
Score	후속 확인이 얼마나 필요한가	단계별 확률, 단계 위치를 나타내는 점수, `confidence`

Noul 문서에서 말하는 0.5는 참과 거짓 사이의 불확실성이다. 관련성이 중간 정도라는 뜻으로 쓰면 안 된다. 관련성의 정도가 필요하면 기준을 나눈 Score를 검토한다. Choice에는 순서가 없는 선택지를 넣는다. Choice 문서를 기준으로 읽으면 선택값만 저장하는 것보다 각 후보의 확률을 함께 남겨야 경계 사례를 다시 볼 수 있다.

Score도 백분율로 읽지 않는다. Score 문서에 따르면 세 단계를 정의했을 때 점수 범위는 0에서 2다. 예를 들어 내가 정한 단계가 “추가 확인 없음, 원문 대조 필요, 사람 판단 필요”이고 확률이 각각 0.2·0.6·0.2라면 가중 평균은 1이다. 가운데 단계에 확률 1이 몰려도 평균은 1이다. 이 두 가상 결과는 점수가 같지만 불확실성이 다르다. 로그에 분포를 남겨야 구분할 수 있다.

confidence를 정답률로 읽으면 생기는 문제

공식 confidence 설명에서 신뢰도는 Choice·Score의 확률 분포로 계산한 요약값이다. 별도의 검증자가 채점한 점수가 아니다. Noul에는 이 필드가 없다. 따라서 confidence=0.9를 보고 이번 답이 90% 확률로 맞는다고 단정할 수 없다.

내 과제에서 확률이 유용한지는 정답을 붙인 기록으로 확인해야 한다. 가령 관련성 확률이 0.8 안팎인 기사들을 모았을 때 사람이 관련 있다고 판단한 비율도 비슷한지 살펴본다. 이는 평가 방법의 예시다. 이런 표본을 아직 수집하지 않았으므로 Jev의 한국어 뉴스 판단이 잘 보정돼 있다고 말할 근거는 없다.

같은 기사라도 제목만 보낼 때와 본문 일부를 보낼 때 결과가 달라질 수 있다. “AI 도입으로 비용 절감”이라는 제목에 광고성 보도자료와 실제 측정 보고서를 구분할 정보가 없다면 확률만으로 해결하지 못한다. 입력에 원문 근거가 있는지 먼저 확인하고, 모호한 항목은 검토함으로 보내야 한다.

읽기·제외만 제공하는 Choice에도 문제가 있다. 둘 중 어느 쪽도 맞지 않는 항목을 처리할 방법이 없다. 내 필터에는 보류 경로를 두고, 보류 비율과 사람이 되돌린 비율을 함께 기록할 계획이다. 자동 처리 비율을 높이려고 보류를 없애면 누락을 발견하기 어려워진다.

소프트웨어 파이프라인에 낀 자연어의 문제

블로그 발행 코드에는 형식으로 검사할 조건이 많다. 원고에 제목이 있는지, 날짜가 유효한지, 대표글 목록에 slug가 들어 있는지는 코드가 판정한다. 여기에는 확률 모델을 붙일 이유가 적다. 반면 원고가 출처를 과장했는지, 독자 질문에 답했는지는 문맥을 읽어야 한다. 나는 이 두 부류를 나눠 보고 싶다.

기존 LLM에도 구조화 출력과 도구 호출이 있다. “LLM은 자연어만 반환해서 코드에 붙일 수 없다”는 비교는 부정확하다. 내 선택 기준은 같은 판단 과제에서 출력 계약을 지키는지, 틀린 결정을 얼마나 내리는지, 비용과 대기 시간이 얼마인지다. 간단한 규칙, 기존 분류기, 구조화 출력 LLM도 함께 비교해야 한다.

TypeSafe는 출시 글에서 RLCD라는 학습 방식을 소개하고 워크플로 평가의 속도·비용 우위를 주장한다. 여기서 타입을 지키는 출력과 사실에 맞는 판단을 구분해야 한다. 읽기라는 허용된 선택값을 반환해도 읽을 필요가 없는 기사를 고를 수 있다. 스키마 검사 통과를 의미상 오류가 없다는 보증으로 해석하지 않는다.

업체 벤치마크를 내 비용표로 옮기기 전

출시 글은 193.6배 빠르고 444.6배 저렴하다는 비교를 제시하면서 실제 이득의 높은 쪽에 해당할 수 있다고 적었다. 평가팀이 만든 워크플로를 사용했고, 외부 대형 모델들의 예측을 기준 답으로 삼았다. 이는 사람이 확인한 업무 정답과의 일치율을 그대로 뜻하지 않는다. 비교 모델에 확률까지 출력하게 했다는 조건도 비용 차이에 영향을 준다.

같은 글에 적힌 입력 가격은 100만 토큰당 0.042달러, 출력은 무료다. 이는 2026년 9월 20일 열람한 출시 발표의 가격이며 장기 견적이 아니다. 입력 토큰에는 상태 외에 질문과 기준도 들어갈 수 있으므로, 기사 본문 길이만으로 청구액을 계산하지 않을 생각이다. API 접근 후 실제 usage와 청구 기록을 대조해야 한다.

TypeSafe는 Doom 데모에 화면 이미지가 아닌 구조화된 게임 상태를 사용했다고 밝혔다. 위키 링크 탐색 데모도 공개했다. 이런 시연으로 가능한 입력과 판단 흐름은 볼 수 있지만, 내 뉴스 필터의 누락률이나 한국에서의 응답 시간을 대신 측정할 수는 없다. 이번 글에서는 데모의 초 단위 수치를 내 운영 성능처럼 인용하지 않는다.

내 비교표에는 API 호출 비용 외에 재시도, 다음 모델 호출, 사람이 되돌리는 시간도 넣으려 한다. 예를 들어 다음은 실측이 아닌 월 비용 계산식이다.

전체 비용 = 분류 호출 비용
          + 분류 뒤 생성·검수 모델 비용
          + 실패·재시도 비용
          + 수동 복구에 드는 시간 비용

싼 모델로 보낸 요청을 비싼 모델이 다시 처리한다면 첫 호출 가격만 비교해서는 손해를 놓친다. 분류기를 추가하기 전후에 같은 과제를 완료하는 데 든 전체 비용을 비교하고, 사람 시간을 금액으로 환산하기 어렵다면 분 단위로 따로 기록할 계획이다. 평균 응답 시간과 느린 구간인 p95도 나눠서 본다. 빠른 평균에 가려진 타임아웃을 확인하기 위해서다.

하네스의 빈자리를 찾아가다

LangChain은 Jev 소개 글에서 모델 라우팅과 위험 도구 호출 검사를 설명한다. Browserbase 관계자의 브라우저 에이전트와 이메일 분류 같은 활용 사례도 소개하지만, 이 글에서 해당 서비스의 운영 지표를 독립 검증한 것은 아니다.

LangChain 통합 문서의 TypeSafeClassifier로 판단을 연결할 수 있다. 다만 모델 라우터와 AutoMode 미들웨어는 experimental로 표시돼 있다. 실제 도입 시 패키지 버전을 고정하고 업데이트 전 회귀 검사를 해야 할 이유다.

ModelRouterMiddleware는 최신 사용자 메시지를 분류하고 그 실행 동안 선택한 모델을 사용한다. 매 도구 결과마다 자동으로 재판정하는 구조로 오해하면 안 된다. 나는 생성과 검수에 다른 모델을 쓰고 있는데, 검수 단계를 생략하지 않은 채 생성 요청의 난도를 나누는 실험부터 해볼 수 있다. 라우터 때문에 기존 검수 품질이 떨어지면 절약액과 별개로 도입을 멈춘다.

AutoModeMiddleware는 지정한 도구의 호출을 검사해 위험하다고 판단하면 실행을 거부한다. 사람에게 승인 요청을 보내는 기능은 별도로 연결해야 한다. 도구 목록에 넣지 않은 경로까지 보호한다고 생각해서도 안 된다. 블로그에서는 배포 명령을 검사해도 다른 API 클라이언트가 DB에 직접 쓰면 통제가 빠질 수 있다.

여기서부터는 내 워크플로에 적용할 설계 원칙이다. 명시적인 발행 승인, 허용된 저장소·파일 범위, 접근 자격은 기존 코드로 검사한다. 그 위에 문맥상 위험을 찾는 보조 판단을 더한다. 모델이 안전하다고 답해도 승인 없는 외부 쓰기를 허용하지 않는다. 분류 API가 실패하거나 시간 제한을 넘으면 외부 쓰기를 멈추고 검토 대상으로 남긴다.

검사할 상태를 외부 API로 보낸다는 점도 고려해야 한다. 비공개 원고 전체, 토큰이 섞인 명령, 고객 정보가 판단 입력에 들어갈 수 있다. 필요한 필드만 추려서 보내고 비밀 값을 제거해야 한다. 내용이 줄어서 판단 근거가 부족해지면 안전하다고 추정하는 대신 사람이 확인한다. 기존 하네스 운영 글의 승인·범위 검사와 함께 사용할 장치다.

내 자동화에 붙일 실험 세 가지

첫 순서는 아침 뉴스 필터다. 웨이트리스트에도 이 용도를 적었다. 접근 권한을 받더라도 바로 자동 제외를 켜지 않고, 기존 결과 옆에 Jev의 판단만 기록하는 그림자 실행부터 하려 한다. 아래 기간과 표본은 내 실험안이며 성능을 보장하는 권장 기준이 아니다.

뉴스 필터에서는 누락부터 센다. 수집한 헤드라인에 관련성 Noul과 중요도 Score를 붙인다. 사람이 읽어야 한다고 고른 기사 중 필터가 제외한 수를 전체 관련 기사 수로 나누면 누락률을 볼 수 있다. 필터가 읽으라고 한 목록 중 불필요한 기사가 얼마나 섞였는지도 센다. 한쪽 숫자만 좋아져서는 부족하다. study-clipper의 짧은 요약과 깊이 읽기 분기도 후속 후보로 둔다.

발행 검수에서는 놓친 위험을 따로 센다. 삭제, 원격 쓰기, 외부 발송 사례와 정상적인 읽기 작업을 테스트 입력으로 준비한다. 위험한 요청을 놓치는 비율과 정상 요청을 막는 비율을 구분한다. 실제 외부 작업은 실행하지 않는 테스트 도구로 먼저 평가하고, 한 달 기록을 검토할 계획이다. 잘못 차단하는 횟수만 줄이면 위험한 작업을 더 많이 통과시킬 수 있다.

모델 라우팅에서는 같은 요청을 비교한다. 두 달 총 청구액만 보면 글 수나 난도가 달라진 효과가 섞인다. 동일한 저장 요청 묶음에 기존 고정 경로와 새 라우터를 각각 적용하고, 결과를 어느 경로에서 만들었는지 가린 상태로 검토한다. 원문 근거 누락, 재작성 필요, 최종 검사 실패를 기록한다. 운영 비용은 이 비교 후 추가로 추적한다.

초대를 받으면 남길 평가 기록

처음에는 한국어 헤드라인 100개 정도를 사람이 분류하는 소규모 점검을 생각하고 있다. 실제 피드에서 연속 수집한 표본과 일부러 만든 경계 사례를 나눠 기록한다. AI라는 단어만 들어간 광고, 같은 사건의 재전송 기사, 출처 없는 수치, 제목과 본문이 다른 기사를 별도로 넣는다. 경계 사례를 많이 넣은 결과를 실제 피드 전체의 발생 비율처럼 보고하지 않는다.

규칙을 조정할 묶음과 마지막에 평가할 묶음도 나눈다. 같은 기사를 계속 보면서 기준을 고치고 그 기사에서만 좋은 점수를 얻으면 새 입력에서 통할지 알 수 없다. 표본 100개로 보안이나 일반 성능을 입증할 수는 없다. 초반에는 큰 실패 유형을 찾는 데 쓰고, 발견한 오류를 다음 평가에 남긴다.

기록 항목	내 비교 목적
입력 ID·수집 시각·원문 출처	중복과 최신성 차이 확인
모델·질문·기준 버전	변경 전후 결과 재현
반환 확률·신뢰도·최종 경로	낮은 확신과 잘못된 확신 구분
사람 판정·수정 이유	모델 답과 운영 판단의 차이 확인
지연·usage·재시도	성공 호출만으로 비용을 낮게 잡지 않기

공개 로그에는 원문 전체나 비밀 값을 남기지 않는다. 필요한 상태는 접근을 제한한 저장소에 두고 공개 결과에는 집계와 비식별 사례를 쓴다. 같은 입력 ID를 반복 실행했을 때 판단이 얼마나 흔들리는지도 기록할 예정이다.

도입 중단 조건도 먼저 정한다. 중요한 기사 누락이 기존보다 늘거나, 사람이 고치는 시간이 절약한 비용보다 커지면 기존 경로를 유지한다. 발행 검수에서 승인 없는 쓰기를 허용하는 설계 오류를 발견하면 모델 점수와 관계없이 연결을 중단한다. 나중에 임계값을 바꾸더라도 이전 버전의 결과를 덮어쓰지 않고 비교 기록을 남긴다.

지금은 뉴스 필터부터 확인한다

공식 문서에서 출력 구조와 LangChain 연동 방식은 확인했다. 한국어 입력의 판단 품질, 내 환경의 지연, 실제 월 비용은 아직 확인하지 못했다. 이번 검토에서 독립 성능 평가를 근거로 삼지 않았고, 다른 제공 경로의 현재 지원 여부도 확인하지 않았으므로 이 글에서 이용 가능하다고 안내하지 않는다.

한 업체 API에 판단 코드를 묶는 비용도 남는다. 내 코드에서는 기사 상태를 만드는 부분, 모델을 부르는 부분, 확률로 다음 경로를 정하는 부분을 분리하려 한다. 타임아웃 때 기존 검토함으로 돌려보내고, 공급자를 바꿔도 사람이 확인한 평가 묶음은 다시 사용할 수 있게 한다.

Jev를 써볼 이유는 반복 분류에서 비교할 선택지가 생겼다는 데 있다. 내 첫 확인 항목은 뉴스 누락과 검토 시간이다. 그 결과를 얻기 전까지 글 생성과 발행 승인은 현재 절차를 유지한다. 초대 후에는 입력 조건과 실패 사례까지 함께 공개해야 다음 도입 여부를 판단할 수 있다.

참고자료

아래 영상은 관심을 갖게 된 계기로 남긴다. 이 글의 기술 설명과 수치는 위 공식 자료를 기준으로 검토했으며 영상 속 데모 수치를 재현하지 않았다.

읽기 전 요약