[AI] Jev와 jgrep: 텍스트를 쓰지 않는 결정 전용 모델로 테스트를 고르다

LLM에게 “이 diff가 이 테스트와 관련 있어?“라고 물으면 모델은 두세 문장짜리 설명을 만들어 낸 뒤에야 답을 준다. 우리가 필요한 것은 예/아니오 하나인데, 비용과 지연은 문장 전체에 대해 치른다. TypeSafe AI가 2026년 9월 15일 공개한 Jev는 이 낭비를 구조 자체에서 없애려는 시도다. 이 글은 Jev가 무엇을 포기하고 무엇을 얻었는지, 제3자 벤치마크에서 어느 위치인지, 그리고 이를 엔진으로 쓰는 CLI인 jgrep이 테스트 선택 문제를 어떻게 푸는지를 정리한다. 마지막에는 도입 여부를 판단하는 기준을 둔다.

System One Model: 생성을 포기한 모델

TypeSafe AI는 Jev를 “System One Model"이라는 새 범주의 첫 사례로 소개한다. 입력은 비정형 데이터(특히 프로그램의 구조화된 상태)이고, 출력은 미리 정의한 타입의 값에 보정된 확률과 신뢰도가 붙은 형태다. 대신 자유 형식의 문자열 생성은 포기한다(출처: TypeSafe AI, Introducing System One Models and Jev). 이름은 즉각적이고 직관적인 판단을 가리키는 System 1 사고에서 따온 것으로 보이지만, 해당 글이 그 대응을 어디까지 주장하는지는 확인하지 못했다. 여기서는 “빠른 결정 전용"이라는 의미로만 쓴다.

구조적으로 두 가지가 다르다. 첫째, 토큰을 하나씩 이어 붙이지 않고 병렬 샘플러가 한 번의 쿼리에서 모든 출력 필드를 동시에 낸다. 둘째, 학습 방식이 RLHF나 검증 가능한 보상 기반 강화학습이 아니라 RLCD(Reinforcement Learning for Calibrated Decisions)다. 선호나 정답 일치가 아니라 “정직한 확률"을 보상하는 방식이라고 설명되는데, 학습 알고리즘의 세부는 공개 문서에서 확인되지 않는다. 출력이 스키마로 고정되므로 타입 오류가 나지 않는다는 주장은 경험적 결과가 아니라 구조상의 보장으로 제시된다.

수치는 TypeSafe AI의 주장이다. 엔드투엔드 응답 시간은 70ms–500ms이고, 비교 대상인 프론티어 LLM은 3–329초다. 이를 근거로 “System One형 쿼리에서 같은 지능 수준 기준 40–200배 빠르다"고 한다. 가격은 입력 100만 토큰당 $0.042이고 출력은 무료다. 출력이 정해진 스키마라 길이가 사실상 의미가 없기 때문에 가능한 과금이다. 원문은 이 가격이 보조금 없이 지속 가능한지는 증명할 수 없다고 스스로 밝히고, 속도 측정이 창업자들의 노트북에서 이뤄졌다는 점과 기준 답안이 일부 LLM에 유리하게 만들어졌을 수 있다는 점도 한계로 적는다.

용도는 분류, 라우팅, 점수화, 추출, 분기, 가드레일, 탈옥 탐지처럼 “결정"이 필요한 곳이다. 원문은 챗봇이나 코딩 에이전트는 다른 모델의 몫이라고 선을 긋는다. 선택지 개수가 255를 넘는 경우는 지원하지 않고 두 단계 절차로 처리한다는 제약, 그리고 아직 얼리 액세스라는 점도 밝혀져 있다.

제3자 벤치마크에서의 위치

벤더 주장만으로는 판단할 수 없으니 독립 비교를 보자. Hugging Face 블로그에 올라온 “13개 답변 검증기” 비교는 참조 문서 없이 질문과 답변만 보고 오답을 가려내는 과제를 다룬다. 테스트셋은 2,018개 항목(오답 508개), 5개 도메인, 4개 모델이 생성한 답변이다(출처: Inside the JEV Ecosystem, Hugging Face 블로그). 지표는 AUC로, 0.5가 동전 던지기 수준이다. 일부 요약에서 이를 “정확도"라고 부르지만 AUC가 맞다.

읽을 점은 세 가지다. 먼저 Jev는 훨씬 큰 모델과 오차 범위 안에서 같은 수준이므로 “정확도에서 압도적"이 아니라 “비슷한 정확도를 훨씬 싸고 빠르게"가 정확한 요약이다. 다음으로 길이와 형식만 보는 단순 기준선을 못 넘는 시스템이 13개 중 8개라는 사실은, 이 과제 자체가 어렵고 기준선이 의외로 강하다는 뜻이다. 마지막으로 AUC가 높다고 에이전트 결과가 좋아지는 것은 아니다. 재시도 예산 20%를 준 종단 실험에서 ZTC는 게이트 없을 때보다 정확도가 1.34%p 올랐지만 Jev는 의미 있는 이득이 없었다. 한 번의 판정 점수와 “판정을 이용해 일을 더 잘하게 되는 정도"는 다른 양이다. ZTC가 은닉 상태를 읽어 같은 목적을 달성하는 방식은 이전 글인 Zero-Token Confidence 편에서 다뤘다.

jgrep: Jev를 엔진으로 쓴 개발자 도구

jgrep(npm 패키지명 jevgrep, MIT)은 “코드가 무엇이라 불리는지가 아니라 무엇을 하는지"를 찾는 grep이다(출처: kyu1204/jgrep). 세 가지 모드가 있다.

• 의미 검색: jgrep "catches an error and silently ignores it" src/처럼 영어 문장으로 코드 조각을 채점해 파일:줄 형태로 출력한다.
• --diff 게이트: git diff 조각을 “인증 검사 없이 HTTP 엔드포인트를 추가한다” 같은 영어 규칙에 대조한다. 종료 코드가 일치(0), 불일치(1), 실패(2)로 나뉘어 있어 CI가 서비스 장애와 정상 통과를 구분할 수 있다.
• --tests 선택: diff가 영향을 줄 만한 테스트 파일을 고른다.

테스트 선택이 흥미롭다. 비용이 싼 순서로 세 단계를 거친다. 1단계는 foo.ts와 foo.test.ts 같은 이름 매칭, 2단계는 변경된 모듈을 임포트하는 테스트 선택(패키지 진입 파일이 바뀌면 패키지 루트를 임포트하는 테스트), 3단계는 남은 테스트 파일에 대해 Jev가 압축된 diff와 해당 파일의 임포트·테스트 이름을 보고 판정하는 것이다. 기본 임계값은 0.5인데, README는 놓친 테스트가 더 비싸므로 일부러 낮게 잡았다고 설명한다. 그리고 이것은 빠른 1차 신호일 뿐이니 이후 전체 스위트를 돌리라고 권한다.

README의 수치는 저자 측정이다. hono, zod, fastify, flask, requests 5개 저장소에서 소스와 테스트를 함께 바꾼 60개 커밋을 대상으로 했을 때, 테스트 파일의 12%를 골라 커밋 작성자가 실제로 건드린 테스트의 93%를 잡았다. 이름·임포트 매칭만으로는 45%였고 전체 비용은 $0.11이다. 142개 파일 TypeScript 스위트에서는 전체 실행 18.9초 대비 선택 후 12.6초, 선택 자체에 $0.0024가 들었다. 3단계가 규칙 기반 단계가 놓친 테스트를 크게 늘렸다는 해석이 가능하지만, 표본이 60개 커밋이고 평가 기준이 “작성자가 건드린 테스트"라는 점은 감안해야 한다. 작성자가 건드리지 않았지만 깨질 수 있는 테스트는 이 기준으로는 보이지 않는다.

같은 문제, 반대 방향의 해법: Anthropic의 이력 기반 선택

“diff에서 돌릴 테스트를 고른다"는 문제는 Anthropic도 풀었다. 에이전틱 코딩으로 6개월 동안 CI 작업량이 약 25배 늘고 테스트 수는 10배 늘자, 테스트 영향 분석 서비스가 과부하 위험에 반복 노출됐다. 이 서비스는 결정론적이다. listener가 모든 CI 실행의 테스트 결과를 기록하고 selector가 그 이력과 패키지 관련성으로 PR마다 돌릴 테스트를 정한다. 코어를 늘리고(70일), 패키지별로 상태를 샤딩하고(29일), 매일 재시작하는(1일 미만) 세 번의 임시 패치로 번 시간이 점점 줄었고, 결국 상태를 인메모리 저장소로 옮기고 상태 없는 listener가 저널에 쓰면 별도 소비자가 몇 초마다 이력으로 집계하는 구조로 재설계했다(출처: Anthropic, Agentic coding is straining CI). 이 글은 자사 환경의 사례이고 성능 증거도 대부분 정성적이라는 한계가 있다.

두 접근을 같은 축에 놓으면 트레이드오프가 분명하다.

둘은 배타적이지 않다. 이력이 없는 구간은 의미 판단이, 이력이 풍부한 구간은 결정론적 선택이 맡는 조합이 자연스럽지만, 두 방식을 합친 사례는 확인하지 못했으므로 어디까지나 설계 가능성이다.

도입 판단 기준

Jev 같은 결정 전용 모델과 jgrep을 어디에 쓸지는 다음 질문으로 가를 수 있다.

1. 출력이 정해진 선택지인가? 라우팅, 분류, 점수화처럼 답이 스키마에 들어가면 후보다. 설명이나 코드를 써야 하면 대상이 아니다.
2. 놓침 비용과 불필요한 실행 비용 중 어느 쪽이 큰가? jgrep이 임계값을 낮게 잡은 이유와 같다. 놓침이 비싼 곳에서는 1차 필터로만 쓰고 전체 스위트를 뒤에 둔다.
3. 판정 결과를 재현해야 하는가? 감사나 회귀 분석이 필요하면 비결정성이 약점이다.
4. 외부 API 의존을 받아들일 수 있는가? 모든 실행이 TypeSafe 또는 OpenRouter 키와 네트워크 호출을 요구하고, 코드 조각이 외부로 나간다. 비공개 저장소라면 정책 검토가 먼저다.
5. 자기 데이터로 측정했는가? 위 수치는 벤더·저자·한 번의 독립 비교에서 나왔다. 자기 저장소의 최근 커밋 수십 개로 “놓친 테스트 비율"을 먼저 재 보는 편이 어떤 발표 수치보다 믿을 만하다.

정리하면, Jev의 핵심 아이디어는 “모든 문제를 가장 큰 모델로 푸는” 흐름과 반대로 결정이 필요한 자리에는 생성 능력이 필요 없다는 관찰이다. 제3자 비교는 그것이 정확도 면에서 터무니없는 주장은 아님을 보여 주지만, 에이전트의 최종 성과까지 끌어올린다는 증거는 아직 없다. jgrep은 아직 개인 프로젝트이므로, 도입은 작은 범위의 1차 필터로 시작하고 자기 데이터로 검증하는 순서를 권한다.

참고 자료

• TypeSafe AI, “Introducing System One Models and Jev” (2026-09-15)
• Hugging Face 블로그, “Inside the JEV Ecosystem: 13 Answer Verifiers on One Test Set”
• GitHub — kyu1204/jgrep
• Anthropic, “Agentic coding is straining CI” (2026-09-14)