코딩 에이전트가 수정을 마쳤다. 테스트 결과와 리뷰 코멘트를 읽고, 다시 수정할지, 접근을 바꿀지, 사람에게 넘길지 정해야 한다. 필요한 출력은 RETRY, REPLAN, HUMAN_REVIEW 중 하나다.

이 짧은 답을 얻으려고 다시 LLM을 호출한다. 코드 작성과 원인 분석뿐 아니라 다음 행동을 고르는 일에도 같은 모델을 쓰는 셈이다. 에이전트가 여러 차례 작업을 반복한다면, 이런 판단 호출에 드는 비용과 대기 시간도 함께 쌓인다.

이 판단을 범용 LLM과 다른 방식으로 처리할 수 있을까. Jev는 TypeSafe가 2026년 9월 15일 공개한 모델로, 회사는 이를 System One 모델이라고 부른다. 상태와 질문을 입력받아 정해진 형태의 판단과 확률을 반환한다. 개발자는 그 결과를 읽어 다음 동작을 결정한다. Introducing System One Models & Jev

이 글에서는 리뷰 코멘트 하나를 따라가며 Jev의 입력과 출력, 기존 classifier와의 차이, 병렬 샘플러의 역할을 살펴본다. 이어서 확률을 읽고 성능을 평가하는 기준을 정리하고, 코딩 밖의 공개 활용 사례를 살펴본 뒤 직접 호출하는 예제로 연결한다. 공식 자료를 바탕으로 한 설명이며, 도입 효과를 직접 측정한 후기는 아니다.

리뷰 처리에서 Jev에 맡길 판단 찾기

에이전트가 로그인 기능을 수정했다고 하자. 테스트 실행 결과와 함께 리뷰 코멘트가 도착했다.

요구사항에는 세션 만료 후 로그인 화면으로 이동해야 한다고 적혀 있습니다. 현재 구현에는 이 처리가 없습니다.

이 코멘트를 받은 시스템에는 여러 일이 남아 있다. 먼저 코멘트가 어떤 문제를 지적하는지 분류해야 한다. 지적한 내용이 실제 코드와 요구사항에 비춰 맞는지 확인해야 하고, 수정할 수 있다면 재작업을 요청해야 한다. 동일한 수정이 계속 실패했다면 다른 접근을 시도하거나 사람에게 넘길 수도 있다.

이 과정을 하나의 ‘리뷰 판단’으로 묶으면 모든 일을 LLM에 맡기기 쉽다. 하지만 나눠 보면 성격이 다르다. 테스트의 성공 여부와 재시도 횟수는 코드로 확인할 수 있다. 코멘트가 요구사항 누락을 지적하는지는 문맥을 읽어야 한다. 누락된 동작을 어떤 방식으로 구현할지는 코드와 실행 흐름에 대한 분석이 필요하다.

Jev를 검토할 지점은 이 중 범위가 좁고 출력 기준을 정할 수 있는 판단이다. 예를 들어 리뷰 코멘트를 다음 네 종류로 분류하는 일이다.

BUG                       잘못된 동작이나 예외를 지적함
MISSING_REQUIREMENT       명시된 요구사항의 미구현을 지적함
SUGGESTION                결함 지적 없이 개선을 제안함
INSUFFICIENT_INFORMATION   주된 문제를 분류할 정보가 부족함

이 글에서 Jev에 맡길 일은 코멘트가 주장하는 문제의 유형을 분류하는 것이다. 실제 코드에 그 문제가 있는지는 별도로 검증한다. 전체 흐름에서 Jev가 맡는 위치는 다음과 같다.

그림 1. 리뷰 처리의 개념도. 분류 결과를 받은 뒤 어떤 행동을 할지는 애플리케이션이 정한다.

Jev는 어떤 입력과 출력을 사용하는가

Jev 요청의 중심에는 state와 questions가 있다. state에는 판단할 상황을, questions에는 질문과 답변 기준을 넣는다. 질문마다 정해진 유형의 결과가 돌아온다. 그림 1의 분류에는 Choice를 쓰고, 같은 코멘트에 다른 질문을 추가할 수도 있다.

Score는 숫자의 의미도 기준과 함께 읽어야 한다. ‘문제가 불명확함 → 증상은 명확함 → 재현 조건까지 명확함’이라는 세 등급을 정의했다면, 점수는 그 등급들 사이의 위치다. 문제가 발생할 확률이나 실제 피해 규모를 직접 측정한 숫자가 아니다. 공식 문서는 점수를 등급 번호의 확률 가중 평균으로 설명한다. Primitives (Questions) Score

선택 가능한 행동도 미리 정할 수 있다. 구현 단계에서는 RETRY와 ABORT를, 검토 단계에서는 RETRY, REPLAN, HUMAN_REVIEW를 허용하는 식이다. 모델에는 현재 상태에서 허용되는 선택지만 전달한다. 선택 범위와 실제 실행은 애플리케이션이 소유한다.

이 구조에서는 응답을 코드의 분기에 바로 연결하기 쉽다. 다만 MISSING_REQUIREMENT인 코멘트를 SUGGESTION으로 분류할 수는 있다. 출력 형식의 보장과 판단의 정확도는 별개다. Choice

현재 Jev 1.13은 텍스트 입력을 받는다. UI 스크린샷이나 게임 플레이 영상을 그대로 전달하는 사용법과는 다르다. 그런 입력을 활용하려면 먼저 관찰 결과를 텍스트나 구조화된 필드로 바꿔야 하며, 그 과정의 비용과 정보 손실도 고려해야 한다. Models

기존 classifier와 비교하면 어떤 장점이 있나

리뷰 코멘트를 네 종류로 나누는 것만 보면 Jev도 분류기다. 그렇다면 이미 익숙한 classifier 대신 Jev를 검토할 이유는 무엇일까. 개인 개발자가 먼저 체감할 차이는 새로운 판단 작업을 추가하는 데 드는 준비다.

작업별로 지도학습한 분류기를 만든다고 생각해 보자. 리뷰 유형을 구분할 라벨 데이터를 모으고 학습한 뒤 평가한다. 이후 ‘재현 방법이 있는가’, ‘어느 팀으로 보내야 하는가’라는 판단이 필요해지면 그 작업에 맞는 데이터와 모델 구성을 다시 검토해야 한다. 하나의 모델을 여러 작업에 맞춰 학습할 수도 있지만, 새로운 업무를 정의하고 검증하는 과정은 남는다.

Jev에서는 같은 모델에 질문과 선택지 설명을 바꿔 전달하며 새 작업을 시험할 수 있다. 리뷰 유형을 분류하다가 담당 팀을 고르는 질문을 추가할 때, 개발자가 먼저 새 분류기를 학습시킬 필요가 없다. 모델은 공통으로 사용하고 판단 기준을 요청에 담는 방식이다. 현재 서비스는 사용자별 fine-tuning을 제공하는 방식이 아니라 동일한 모델 가중치를 사용하는 방식이다. Models Choice

예를 들어 팀 구성이 바뀌었다면 해당 요청의 선택지를 FRONTEND, BACKEND, PLATFORM으로 구성할 수 있다. 리뷰 단계와 배포 단계에서 허용하는 행동이 다르다면 단계마다 다른 선택지를 전달할 수 있다. 판단의 종류와 선택 공간을 실행 시점에 정의한다는 점이 에이전트와 잘 맞는다. 물론 선택지를 바꾸면 품질 평가도 다시 해야 한다. 학습을 직접 하지 않아도 된다는 것과 평가 데이터가 필요 없다는 것은 다르다.

이런 유연성은 기존 zero-shot 분류와도 비교해야 한다. zero-shot 분류는 해당 작업의 학습 예시 없이, 주어진 분류 기준으로 대상을 나누는 방식이다. 자연어로 표현한 새 라벨을 처리하는 분류는 Jev 이전부터 연구돼 왔다. 새 라벨을 처리하는 능력은 이 방식과 Jev가 공유하는 특성이다. Benchmarking Zero-shot Text Classification: Datasets, Evaluation and Entailment Approach

비교의 핵심은 기능 하나의 독점 여부가 아니라, 필요한 기능을 어떤 준비와 운영 비용으로 함께 얻는가다.

기존 classifier도 확률을 출력하고 보정할 수 있다. Jev에서 함께 볼 부분은 다양한 상태와 요청 시점의 판단 기준, 구조화된 확률 출력, 빠른 판단 호출을 하나의 인터페이스로 제공한다는 점이다. 이 조합이 자신의 작업에서 준비 비용과 운영 비용을 줄이는지가 비교의 기준이 된다.

이 관점에서 Jev가 특히 흥미로운 후보가 되는 상황은 판단 종류가 많고 자주 바뀌는데, 각 작업의 학습 데이터를 충분히 모으기 어려운 경우다. 반대로 안정된 분류 작업 하나를 대량 처리하고 있다면 기존 분류기를 교체해야 할 이유부터 확인하는 것이 맞다. 이제 이 사용상의 차이를 만드는 설계 방향을 살펴보자.

병렬 샘플러는 판단을 얻는 방식을 어떻게 바꾸나

TypeSafe는 Jev의 기술적 축으로 새 모델 아키텍처, parallel sampler, RLCD를 제시한다. 아키텍처는 어떤 출력을 계산할지, 샘플러는 그 출력을 어떻게 얻을지, 학습 방법은 어떤 결과를 잘 내도록 만들지에 해당한다. 회사가 밝힌 설계 방향을 이해하는 데 유용한 구분이다. Introducing System One Models & Jev

토큰을 순서대로 만드는 과정

먼저 일반적인 자기회귀 LLM의 출력 과정을 보자. 자기회귀 생성은 앞서 생성한 토큰을 바탕으로 다음 토큰을 순서대로 만드는 방식이다. 모델에 세 질문을 한꺼번에 보내고 JSON으로 답하도록 해도, 응답을 구성하는 토큰은 앞선 출력에 이어 생성된다. 출력 형식을 제한하는 것과 이 생성 과정을 바꾸는 것은 다른 일이다.

이를 간단히 쓰면 다음과 같다.

자기회귀 생성
입력 → 출력 토큰 1 → 출력 토큰 2 → … → 출력 토큰 T

Jev가 공개한 출력 방식
상태 + 질문들 → 질문별 확률분포를 병렬로 출력

TypeSafe는 Jev가 모든 확률을 병렬로 출력한다고 설명한다. 위 도식은 이 출력 방식을 비교한 것으로, 내부 연산 횟수를 뜻하지 않는다. 공개 자료만으로 ‘API 요청 한 번 = 신경망 forward pass 한 번’이라고 결론 내릴 수는 없다. Introducing System One Models & Jev

이 차이에서 주목할 것은 앞선 출력이 끝나기를 기다려야 하는 의존 관계다. 자기회귀 응답은 길이가 늘어나면 순차적으로 생성할 토큰도 늘어난다. Jev는 질문별 판단을 이런 긴 문자열로 작성하는 대신 병렬 출력하도록 설계됐다. 다만 질문과 선택지를 읽는 계산, 입력 길이, 서버 처리와 통신 시간은 여전히 존재한다. 질문을 무한히 늘려도 비용과 시간이 같다는 의미는 아니다.

또한 LLM API를 여러 번 병렬 호출하는 방식과도 구분해야 한다. 클라이언트의 동시 호출은 요청 사이의 대기를 줄이지만, 각 요청 안의 자기회귀 출력은 남는다. Jev의 발표는 모델의 출력 방식에 관한 설명이고, 한 상태의 질문을 한 요청에 묶는 것은 그 특성을 사용하는 API 패턴이다.

같은 상태에 대한 질문은 함께 묻는다

리뷰 예제에 적용해 보자. 코멘트 유형을 받은 뒤 설명의 구체성을 물어보고, 그 답을 받은 뒤 재현 방법의 유무를 묻는 세 번의 호출을 생각해 보자. 세 질문 모두 원래 코멘트만으로 답할 수 있다면 먼저 답을 기다릴 이유가 없다.

그림 2. 같은 코멘트에서 답할 수 있는 세 질문을 함께 평가한다. 코드에서는 필요한 결과만 사용한다.

여기서 함께 계산할 수 있다는 것은 앞선 답을 다음 질문의 입력으로 쓸 필요가 없다는 뜻이다. 질문들의 답이 통계적으로 독립이라는 의미는 아니다.

공식 문서는 이런 방식으로 여러 질문을 미리 평가하고 코드에서 필요한 답만 사용하는 패턴을 안내한다. 개선 제안으로 분류된 코멘트라면 재현 방법에 대한 답은 무시할 수 있다. 버그 지적이라면 그 답을 추가 정보 요청 여부에 활용할 수 있다. 답을 사용할지는 조건부여도, 답을 계산하는 데 필요한 정보는 이미 모두 주어진 경우다. Speculative fan-out

반면 첫 판단의 결과에 따라 새 파일을 읽어야 한다면 다음 질문에는 아직 없는 정보가 필요하다. 그때는 파일을 읽은 뒤 다시 호출해야 한다. 병렬 평가가 데이터 의존성을 없애 주지는 않는다.

이 특성은 개발 방식에도 영향을 준다. ‘이 변경을 승인할까?’라는 큰 질문 안에 여러 조건을 숨기는 대신, 확인할 기준을 드러내고 작은 질문으로 나눌 수 있다. 각 질문의 오류를 따로 평가하고, 어떤 조합일 때 다음 단계로 갈지는 코드로 정한다. 판단을 세분화하는 것이 호출 왕복의 증가로 곧바로 이어지지 않는다는 점이 실용적인 장점이다. 추가 질문도 입력 토큰 비용은 발생한다. Choice

RLCD는 어떤 결과를 학습하는가

병렬 샘플러가 출력을 얻는 방법이라면, RLCD(Reinforcement Learning for Calibrated Decisions)는 판단과 확률을 학습하는 목표에 관한 이야기다. TypeSafe는 사전학습된 언어 모델을 후속 학습하는 경로로 RLCD를 설명한다. 사람에게 선호되는 응답이나 검증 가능한 정답을 중심으로 설명하는 RLHF·RLVR과 비교해, 판단과 보정된 확률을 출력하도록 학습한다는 점을 강조한다. AI primer

세 축을 연결하면 설계 의도가 드러난다. 정해진 판단 공간을 다루고, 출력을 병렬로 얻으며, 확률의 품질까지 학습 목표로 삼는다. 다만 구체적인 레이어 구성과 손실함수는 공개 설명으로 확인할 수 없는 영역이다.

‘추론하지 않는다’는 표현 역시 구분해서 읽어야 한다. Jev도 입력을 처리하고 판단을 계산한다. 자연어로 긴 추론 과정을 생성하는 모델이 아니라는 설명이 적절하다. 그렇다면 이렇게 얻은 확률과 confidence는 실제로 무엇을 뜻할까.

확률과 confidence는 무엇을 뜻하나

앞의 코멘트를 분류했을 때 다음 분포를 받았다고 가정하자. 아래는 설명용 가상 수치다.

BUG                       0.08
MISSING_REQUIREMENT       0.83
SUGGESTION                 0.06
INSUFFICIENT_INFORMATION   0.03

가장 높은 항목은 MISSING_REQUIREMENT다. 이 질문의 choice는 요구사항 누락이 되고, 0.83은 모델이 그 분류에 부여한 확률이다. 질문은 코멘트의 유형에 관한 것이므로, 이 값을 수정의 성공 확률로 사용할 수는 없다.

가장 높은 항목과 확률값은 다르게 쓰인다

숫자를 어디에 사용할지도 중요하다. 사람이 검토할 항목을 순서대로 보여주는 작업에서는 상대적인 순위가 주된 관심사일 수 있다. 반면 ‘이 정도로 확실할 때만 자동 처리한다’는 정책에서는 확률값의 크기 자체가 중요하다. 순위가 같더라도 0.51과 0.99를 같은 행동 기준으로 취급하기 어려운 상황이 생긴다.

확률값을 자동 처리 기준으로 쓰려면 확률 보정(calibration)을 확인해야 한다. 확률 보정은 모델이 제시한 확률이 실제 결과의 빈도와 맞도록 조정하는 과정이다. 보정이 잘된 모델에서는 예측 확률과 실제 빈도가 비슷하게 나타난다. 충분한 평가 사례에서 80% 안팎의 확률을 받은 예측을 모았을 때 실제로도 약 80%가 맞는지 확인하는 것이다. 한 사례에서 답을 맞혔다고 보정이 잘됐다고 말할 수 없고, 여러 사례의 전체 정답률만으로도 판단할 수 없다. On Calibration of Modern Neural Networks

선택의 정확도와 확률의 품질은 따로 움직일 수 있다. 두 모델이 모두 같은 답을 골라도, 틀릴 때 얼마나 강한 확률을 부여했는지는 다를 수 있다. 자동화를 설계할 때는 맞히는 능력과 틀릴 가능성을 적절하게 표현하는 능력이 모두 필요하다.

confidence는 정답률이 아니다

Jev의 confidence는 확률분포를 요약한 별도 값이다. 공식 문서에 따르면 Choice와 Score의 확률분포가 얼마나 한쪽에 모였는지를 요약해 계산한 값이다. 가장 높은 선택지의 확률과 같은 값도, 실제 정답률을 측정한 값도 아니다. Noul에는 별도의 confidence 필드가 없다. Confidence

따라서 confidence = 0.9를 ‘이 답이 맞을 확률은 90%’라고 그대로 번역할 수 없다. 코드에서 분기 기준으로 쓸 수는 있지만, 어떤 기준값에서 실제 오류가 얼마나 발생하는지는 자신의 데이터로 연결해 봐야 한다.

질문을 바꿔도 같은 판단이 나오는가

확률 보정과 별개로 질문 사이의 일관성도 확인해야 한다. 공식 한계 문서에는 같은 내용을 Noul과 Choice로 표현했을 때 결과가 달라지는 사례, 서로 반대되는 내용을 별도 Noul로 물었을 때 두 값의 합이 1이 되지 않는 사례가 나온다. 이는 한 Choice 안에서 선택지 확률의 합이 1이 되는 것과 다른 문제다. Jev 1.13 jaggedness

실무에서는 같은 판단을 어떤 질문 유형과 기준으로 표현할지 고정하는 것이 중요하다. 한 질문에서 검증한 임계값을 다른 유형의 질문으로 옮기거나, 독립적으로 얻은 답들이 자동으로 논리적 관계를 만족한다고 가정해서는 안 된다. 반드시 성립해야 하는 조건은 코드가 관리해야 한다.

어느 정도의 판단을 자동화할 수 있을까

확률을 읽을 수 있게 됐다면, 다음 질문은 이 결과로 어느 범위까지 자동 처리할 수 있느냐다. 리뷰 분류 도구에서는 먼저 무엇을 정답으로 볼지 정해야 한다. 사람이 코멘트의 주된 의도를 읽고 분류 기준에 따라 라벨을 붙일 수 있다. 요구사항 누락과 버그가 겹치는 경우에는 무엇을 우선할지도 정해야 한다. 기준 자체가 모호하면 모델의 오판과 라벨의 불일치를 구분하기 어렵다.

라벨은 학습 전용이 아니다. 학습에 쓰지 않은 별도의 사례에 라벨을 붙이면 평가 데이터가 된다. 질문을 조정하는 데 사용한 사례와 마지막 품질을 확인할 사례도 분리해야 한다. 같은 사례를 반복해서 보며 기준을 고치면 그 사례에서 잘 맞는다는 사실만 확인하게 될 수 있다.

공식 평가가 보여주는 범위

TypeSafe의 공개 평가는 강한 모델의 판단을 참조값으로 사용하는 접근을 택한다. 보안 사고, 에이전트 실행 기록, 청구서 처리, 고객 지원이라는 네 workflow를 구성하고, 각 workflow의 좁은 질문에 대한 강한 모델들의 응답을 참조값으로 삼는다. 공식 설명상 참조 모델은 고추론 설정의 GPT-6 Astra와 Claude Fable 5.1이며, 비교 대상 모델은 제공자의 기본 추론 설정으로 평가한다. Workflow evals

이 결과로 알 수 있는 것은 정해진 workflow와 참조값을 기준으로 한 일치도, 비용, 처리 시간이다. 실제 고객 문의가 해결됐는지나 잘못된 청구서가 지급되지 않았는지를 직접 관찰한 결과와는 구분해야 한다. 참조 모델의 판단이 틀리거나 편향될 가능성도 남는다. 또한 평가에 쓰였다는 사실만으로 그 모델이 Jev의 학습 데이터를 만든 교사 모델이었다고 결론 낼 수는 없다.

자신의 리뷰 데이터에서 확인할 세 가지

공식 평가를 참고한 뒤에는 자신의 작업에서 다음 세 질문에 답해야 한다.

확률 예측의 전반적인 품질은 Brier score와 log loss로 함께 평가할 수 있다. 두 지표는 보정만을 따로 측정하지 않으므로, 확률 구간별 실제 빈도도 함께 확인한다. 선택만 맞으면 같은 점수를 주는 정답률과 달리, 틀린 결과에 지나치게 높은 확률을 부여한 경우도 구분할 수 있다. 이런 확률 예측 평가법은 Jev 이전부터 연구돼 왔다. Strictly Proper Scoring Rules, Prediction, and Estimation (Revised)

업무에 적용할 때는 오류의 종류도 중요하다. 개선 제안을 필수 수정으로 보내면 불필요한 작업이 생긴다. 요구사항 누락을 개선 제안으로 보내면 필요한 수정이 빠질 수 있다. 정답률이 같아도 어느 쪽을 자주 틀리는지에 따라 도입 판단은 달라진다.

자동 처리 범위와 오류율은 함께 봐야 한다. 다음은 Jev의 실측 성능이 아닌 가상의 운영 결과다.

여기서 판단할 것은 80%를 자동 처리하면서 발생한 오류 비용과, 20%를 검토하는 비용을 감당할 만한가다. 임계값을 바꿔 자동 처리 비율을 줄였을 때 실제 오류도 줄어드는지 비교한다. 전체 요청을 처리한 모델의 정확도와 일부만 자동 처리한 시스템의 오류율은 분모가 다르므로 직접 비교할 수 없다. 이런 처리 비율과 위험의 관계 역시 기존 선택적 예측 연구의 주제다. SelectiveNet: A Deep Neural Network with an Integrated Reject Option

이 평가 방식은 다른 분야에도 적용할 수 있다. 다만 무엇을 성공으로 볼지는 각 업무에서 다시 정해야 한다. 코딩에서는 테스트 통과가 유용한 관측값이지만 모든 요구사항 충족을 뜻하지는 않는다. 모델의 판단, 뒤에 실행한 행동, 실제 결과를 각각 기록해야 어디에서 문제가 생겼는지 알 수 있다.

판단 호출이 저렴해지면 전체 비용은 얼마나 줄까

2026년 9월 24일 공식 문서에서 Jev 1.13의 가격은 입력 100만 토큰당 0.042달러이며 출력은 무료다. TypeSafe는 공개 발표에서 70~500ms의 응답시간도 제시했다. 가격은 공식 요금이고, 응답시간은 회사가 제시한 측정치다. 입력 길이와 네트워크 조건이 다른 자신의 환경에서도 동일하게 나온다고 전제할 수는 없다. Models Introducing System One Models & Jev

리뷰 분류를 Jev로 바꾸면 이 단가 차이가 전체 비용에도 그대로 반영될까. 먼저 전체 작업에서 교체 가능한 판단 비용이 차지하는 비중을 알아야 한다. 기존 비용이 100이고 그중 판단 작업이 35라고 가정하자. 판단 작업의 비용이 100분의 1이 되더라도 총비용은 다음처럼 계산된다.

변경하지 않은 작업     65
교체한 판단 작업       35 × 0.01 = 0.35
전체 비용             65.35
절감률                약 34.7%

판단 호출만 크게 저렴해졌고, 생성과 복잡한 분석 비용은 그대로 남아 있기 때문이다. 이 계산은 가정에 따른 예시다. 실제로 얼마를 줄일 수 있는지는 호출 로그에서 판단 작업의 비중을 확인하고 계산해야 한다. 호출 횟수의 비중과 비용의 비중도 같지 않다.

분류 오류 때문에 상위 모델을 다시 호출했다면 그 비용을 더해야 한다. 사람의 검토, 재시도, 입력을 정리하는 전처리도 포함된다. 입력 토큰 수가 같아도 단가가 달라 비용은 줄 수 있으므로, ‘토큰을 줄였다’와 ‘비용을 줄였다’는 별도로 기록하는 편이 정확하다.

절감 방법이 기존 호출 교체에만 있는 것은 아니다. 검색 결과를 먼저 평가해 필요한 문서만 LLM에 전달하면 뒤의 모델이 읽는 입력을 줄일 수 있다. TypeSafe도 문서 선별 예제를 제공한다. 다만 필요한 근거를 걸러내면 뒤의 모델은 그 정보를 복구할 수 없다. 입력량뿐 아니라 최종 답변의 품질도 함께 비교해야 한다. Classifying RAG passages

같은 상태에 대한 질문을 하나의 요청에 묶는 방법도 있다. 반복해서 상태를 보내는 양과 요청 왕복을 줄일 수 있다. 하지만 추가 질문의 텍스트까지 무료가 되는 것은 아니다. 병렬 처리의 효과와 입력 과금은 별개의 문제다. Choice

반복 실행하는 에이전트에서는 최종 완료 시간도 측정할 필요가 있다. 개별 판단 호출이 빨라져도 재작업이 늘어나면 전체 시간은 길어질 수 있다. 도입 전후를 비교할 때는 같은 작업을 어떤 품질로, 얼마의 비용과 시간에 끝냈는지를 기준으로 삼는 것이 좋다.

코딩 밖에서는 어디에 쓸 수 있을까

리뷰 코멘트는 판단의 입력과 출력을 설명하기 위한 예제다. 같은 구조를 고객 문의, 검색 결과, 문서 묶음, 상품 데이터에도 적용할 수 있다. 중요한 것은 분야보다 문맥을 읽어 정해진 후보를 고르거나 기준에 따라 평가하는 단계가 있는가다.

2026년 9월 28일 기준으로 공식 문서의 구현 예제와 공개 프로젝트를 살펴보면 다음과 같이 정리할 수 있다. 공식 예제는 사용법을 보여주는 자료이고, 공개 프로젝트는 구현을 확인할 수 있는 사례다. 어느 쪽도 곧바로 대규모 운영 성과를 입증하지는 않는다. RAG와 상품 비교 예제에는 Jev 1.12로 기록한 결과가 포함돼 있으므로, 이 글의 1.13 실습과 동일 조건의 성능 자료로 보지 않는다. 아래의 구체적인 업무 상황은 이를 이해하기 위한 응용 예시이며, 별도로 표시한 프로젝트를 직접 실행해 성능을 측정한 것은 아니다.

고객 문의는 답변 작성 전에 나눌 수 있다

고객이 “결제가 두 번 됐는데 하나 취소해 주세요”라고 보냈다고 하자. 문의의 의도를 파악하는 일, 실제 중복 결제 여부를 확인하는 일, 환불을 실행하는 일은 서로 다르다. Jev에는 메시지와 필요한 계정 상태를 보여주고 처리 경로를 고르게 할 수 있다. 거래 내역 확인은 기존 API가, 환불 가능 여부와 승인 절차는 서비스 정책이 맡는다. 답변 문장은 템플릿이나 LLM으로 작성한다.

공식 intent routing 문서는 들어온 요청을 코드, 전문 LLM, 사람에게 나누는 패턴을 제시한다. 이를 메일함에 응용하면 문의·알림·답장 필요 항목을 구분하는 기능부터 시험할 수 있다. 여기서 기대하는 것은 챗봇 전체의 대체보다, 모든 요청을 같은 모델과 같은 처리 절차로 보내지 않는 것이다. Intent routing

검색한 문서 중 무엇을 읽힐지 고른다

검색 결과가 질문과 비슷한 단어를 포함한다고 해서 답변의 근거가 되는 것은 아니다. 질문의 전제가 틀렸음을 알려주는 문서도 있고, 겉보기에는 관련 있어도 실제 답은 없는 문서도 있다.

공식 RAG 예제는 질문과 문서 조각을 함께 보내 관련성, 답변 근거, 질문 전제와의 충돌, 모델을 조종하려는 지시문 포함 여부를 각각 묻는다. 코드는 결과를 근거·상충 정보·제외 대상으로 나누고, LLM은 선별된 자료로 답변을 쓴다. 검색 자체를 Jev로 바꾸는 것이 아니라 검색과 생성 사이에 검토 단계를 넣는 구성이다. Classifying RAG passages

개인 블로그의 글 추천이나 북마크 검색에도 이 구조를 응용할 수 있다. 먼저 키워드나 임베딩으로 후보를 줄인 뒤, “이 글이 사용자가 묻는 문제를 실제로 다루는가”를 평가하는 식이다. 다만 필요한 문서를 놓치면 최종 답변도 나빠지므로, 선별 단계의 점수뿐 아니라 답변에 필요한 근거가 남았는지 확인해야 한다. 지시문 탐지 역시 보조 필터이며, 통과한 문서를 신뢰할 수 있는 명령으로 취급해서는 안 된다.

문서를 읽는 일과 분류하는 일을 나눈다

DocJev는 PDF·DOCX·PPTX에서 추출한 페이지 텍스트를 바탕으로 문서를 분류하거나, 여러 문서가 합쳐진 묶음의 경계를 판단하는 공개 프로젝트다. 문서 텍스트 추출에는 LiteParse를 사용하며, 어려운 입력에는 선택적으로 LlamaParse를 연결한다. Jev는 추출 이후의 분류와 경계 판단을 맡는다. DocJev

예를 들어 여러 자료가 한 파일로 들어오면 페이지마다 종류를 붙이는 것만으로는 부족할 수 있다. 같은 종류의 문서가 연달아 붙어 있어도 서로 다른 문서일 수 있기 때문이다. DocJev는 분류와 분리를 별도 기능으로 제공한다. 이 구조는 첨부파일을 종류별 보관함으로 보내거나 후속 추출기로 전달하는 작업을 설계할 때 참고할 수 있다.

문서 이미지를 Jev가 직접 읽는 것은 아니다. OCR의 누락과 페이지 분리 오류는 뒤의 판단에도 영향을 주며, 로컬에서 텍스트를 추출하더라도 Jev를 호출하는 추론까지 로컬에서 끝나는 것은 아니다.

이름이 다른 데이터가 같은 상품인지 판단한다

데이터를 합칠 때는 같은 상품이 사이트마다 다른 이름으로 등록된 경우가 있다. 반대로 이름은 비슷해도 용량이나 버전이 다른 상품일 수 있다. 문자열 일치만으로 해결하기 어려운 부분이다.

공식 entity alignment 예제는 두 맥주 카탈로그에서 미리 추린 후보 쌍을 비교한다. Score로 서로 다른 상품·추가 검토가 필요한 관계·동일 상품을 평가하고, 별도 Noul 질문으로 이름과 제조사 등의 일치 여부도 확인한다. 모든 레코드 조합을 Jev에 보내는 방식이 아니라, 앞 단계에서 좁힌 후보를 자세히 보는 방식이다. Knowledge graph entity alignment

이를 상품 카탈로그나 수집 데이터 정리에 응용할 수 있다. 다만 잘못 합치면 서로 다른 정보가 한 대상에 붙으므로, 처음에는 자동 병합보다 중복 후보와 검토 목록을 만드는 용도가 적절하다. 숫자 비교나 고유 ID 일치는 코드로 처리하고, 설명과 이름의 문맥을 읽어야 하는 부분을 분리하면 된다.

콘텐츠와 생성된 답변을 별도로 검토한다

공식 guardrails 예제는 LLM 앱에 들어오고 나가는 메시지에 여러 위험 질문을 적용하고, 확률과 심각도에 따라 통과·검토·차단 등의 경로를 고른다. 인용 검증 예제는 주장과 출처 문맥을 비교해 인용이 주장을 뒷받침하는지 확인한다. 둘 다 결과물을 새로 쓰는 호출과 결과물을 평가하는 호출을 나누는 구성이다. Guardrails for LLMs Double-checking citations

이를 응용하면 커뮤니티 게시물의 검토 우선순위를 정하거나, 자동 작성한 요약에서 출처 확인이 필요한 항목을 고를 수 있다. 필터를 통과했다는 사실이 안전성이나 사실성을 보장하지는 않는다. 특히 출처가 주장을 지지하는지와 출처 자체가 사실인지는 다른 질문이다. 잘못 통과시키는 경우와 정상 콘텐츠를 막는 경우를 나눠 평가해야 한다.

브라우저와 게임에서는 다음 행동을 고른다

공개 프로젝트 Jev Ultrafast는 페이지를 관찰할 때마다 조작 가능한 요소 목록을 만들고, Jev가 동작과 대상을 고르게 한다. 클릭이나 스크롤은 브라우저 코드가 실행하고, 입력할 문장이 필요할 때만 작은 LLM을 사용한다. 기본 판단 루프에 들어가는 것은 스크린샷이 아니라 구조화한 페이지 상태다. Jev Ultrafast

게임에서도 비슷한 분리가 가능하다. Anahadd의 Jev Minecraft 프로젝트는 목표, 체력, 인벤토리, 보이는 블록과 주변 상황을 텍스트로 전달하고 현재 허용된 행동 중 하나를 고르게 한다. 실제 채집·제작·이동은 게임 제어 코드가 수행한다. 이 프로젝트는 공개 구현의 예이며, 이 글에서 플레이 성공률을 검증한 사례는 아니다. Jev plays Minecraft

두 사례에서 눈여겨볼 부분은 모델이 임의의 실행 코드를 만드는 대신, 환경이 제공한 행동 후보를 선택한다는 점이다. 가능한 행동이 바뀌면 선택지도 다시 만든다. 브라우저에서 완료를 골랐더라도 목표 페이지에 도달했는지 확인해야 하고, 게임에서도 API 응답 속도와 실제 게임 제어 주기는 구분해야 한다.

이 사례들을 개인 프로젝트로 옮긴다면 메일 분류, 북마크 선별, 문서 정리처럼 결과를 직접 확인하기 쉬운 작업부터 시작할 수 있다. 처음에는 분류와 추천 결과만 기록하고, 기존 방법과 비교한 뒤 실제 행동을 연결한다. Jev가 맡는 것은 업무 전체가 아니라 그 안의 판단 단계다. 나머지 처리를 어디에 둘지 정하는 문제가 다음의 Jev Engineering과 이어진다.

Jev Engineering은 무엇을 설계하는 일인가

커뮤니티에서는 생성·판단·실행을 분리하는 구성을 ‘Jev Engineering’이라는 이름으로 소개하기도 한다. Made with Jev의 소개 글은 LLM에 작성, Jev에 판단, 코드에 실행을 맡기는 방식으로 이를 설명한다. 여기서는 이 표현을 생성·판단·실행의 역할을 나누는 커뮤니티의 설계 관점으로 사용한다. What is Jev Engineering?

이 관점에서 개발자가 먼저 설계할 것은 모델이 판단할 문제다. 리뷰 처리라면 다음 세 가지를 정해야 한다.

분류 결과가 기대와 다르면 이 세 부분을 따로 살펴볼 수 있다. 근거가 빠졌다면 상태를 보완하고, 여러 일을 한꺼번에 물었다면 질문을 나누고, 선택지가 겹친다면 기준을 고친다. 수정한 질문은 남겨 둔 평가 사례로 다시 확인한다.

이렇게 Jev Engineering을 모델에 보여줄 정보와 판단 기준을 설계하는 작업으로 이해하면, API 호출 이후에 남는 개발자의 역할이 구체적으로 보인다. 그 판단을 어디에 사용하고 어떤 행동으로 연결할지는 다음 단계의 설계다.

에이전트 안에서 누가 무엇을 결정할 것인가

판단 모델을 추가하면 한 가지 질문이 더 생긴다. 어떤 일은 코드로 처리하고, 어떤 일은 Jev로 보내고, 어떤 일은 더 강한 LLM에 맡길지 누가 결정할까.

처음에는 개발자가 결정해야 한다. 기존 호출을 보고 정확히 계산할 수 있는 일, 좁은 문맥 판단, 복잡한 분석과 생성으로 나눈다. Jev의 후보 작업은 실제 데이터로 평가하고, 그 결과를 바탕으로 운영 정책을 정한다. 모델이 자신의 업무 적합성까지 언제나 정확하게 판단한다고 가정할 필요는 없다.

그림 1의 처리 정책을 펼쳐 보면 다음과 같다. 실제 제품의 구현이 아닌, 리뷰 처리의 역할 분담을 나타낸 설계 예시다.

그림 3. 분류 이후의 처리 경로. 코드가 정책을 적용하고, 추가 분석·수정·사람 검토로 연결한다.

이 구조에서 모델이 판단에 참여해도 상태 전환의 조건은 코드에 남는다. 테스트가 실패하면 다음 단계로 보내지 않기, 같은 수정을 일정 횟수 이상 반복하지 않기, 특정 변경은 사람 검토를 거치기 같은 조건이다. 모델의 선택을 실행하기 전에 현재 상태에서 허용되는 행동인지 확인한다.

선택지가 적다는 사실만으로 Jev에 적합한 문제인 것은 아니다. “이 변경에 보안 취약점이 있는가?”는 yes 또는 no로 답할 수 있지만 여러 파일과 실행 경로의 분석을 요구할 수 있다. 반대로 “이 코멘트가 보안 문제를 지적하는가?”는 코멘트에 표현된 의도를 분류하는 일이다. 답변의 길이보다 답을 얻는 데 필요한 작업이 중요하다.

공식 한계 문서도 산술, 날짜 비교, 여러 단계의 간접 조건, 불필요한 문맥, 적대적으로 작성된 입력에서 문제가 생길 수 있다고 설명한다. 정확한 계산은 코드에 두고, 모델에는 판단에 필요한 정보를 명확히 전달하는 이유다. Jev 1.13 jaggedness

정보 부족이나 사람 검토를 선택지에 추가하는 것만으로 모든 실패를 처리할 수는 없다. 낯선 입력에서도 모델은 자신 있게 틀릴 수 있다. 낮은 confidence만 기다리는 정책은 그런 오류를 놓친다. 명확한 사례 외에 맥락이 빠진 사례, 기준이 겹치는 사례, 표현이 달라진 사례를 평가에 넣어야 한다.

오류를 조사할 방법도 필요하다. Jev는 판단의 이유를 자연어로 작성하는 모델이 아니다. 다른 LLM에 결과를 설명하게 할 수는 있지만, 그 설명이 Jev가 실제로 판단한 내부 근거라는 보장은 없다. 원래 상태와 질문, 모델 버전, 반환된 값, 코드가 실행한 행동을 연결해 기록하는 것이 더 직접적인 출발점이다.

이런 역할 분담이 Jev 때문에 처음 가능해진 것은 아니다. 기존 에이전트 설계에서도 분류와 라우팅, 코드가 정한 workflow가 사용됐다. Jev는 그중 판단을 수행할 모델의 선택지를 추가한다. Building effective agents

최종 사용자에게는 이 구성이 보이지 않을 수도 있다. 사용자는 코딩 도구나 서비스를 그대로 사용하고, 개발자는 내부에서 생성·분류·검증에 서로 다른 방법을 배치할 수 있다. Jev가 반드시 이 자리를 차지한다는 예측보다, 하나의 에이전트가 반드시 하나의 모델과 대응할 필요는 없다는 설계 관점이 중요하다.

개인 개발자가 직접 시도하는 방법

가장 작은 시작점은 앞에서 사용한 리뷰 코멘트 분류다. 출력 기준을 정하기 쉽고, 코멘트 원문을 읽으며 결과를 비교할 수 있다. 처음에는 자동 수정이나 승인까지 연결하지 않고 분류 결과를 확인하는 도구로 시작한다.

작성 시점의 접근 제한도 있다. 실습을 준비하던 2026년 9월 24일 콘솔에서 수용 인원 초과 안내가 확인돼, 이 글에는 직접 호출한 응답을 싣지 않았다. 아래는 접근 권한을 얻었을 때 실행할 수 있는 예제다.

공식 SDK는 OpenRouter와 Vercel AI Gateway를 통한 연결도 안내한다. TypeSafe 콘솔을 이용하기 어렵다면 해당 제공자에서 Jev를 사용할 수 있는지 확인할 수 있다. 제공자별 접근 권한·요금·지원 모델은 별도로 확인해야 하며, 이 경로 역시 직접 호출해 검증하지 않았다. Usage

접근을 기다리는 동안에는 TypeSafe가 공개한 System One Adapter로 다른 LLM을 사용해 같은 형태의 질문과 workflow를 시험할 수 있다. 별도의 모델 제공자 API 인증이 필요하며, 그 결과는 해당 LLM의 출력이다. Jev의 응답 품질·확률 보정·속도를 검증한 결과로 사용할 수는 없다.

1. Playground에서 질문과 기준 정하기

먼저 공식 Playground에서 텍스트를 상태로 넣고 Choice 질문을 만든다. 네 선택지와 각 선택지의 기준을 입력한 다음, 명확한 코멘트와 애매한 코멘트를 번갈아 넣어 본다. 입력 순서와 질문 작성법은 공식 Quick start에서 확인할 수 있다.

한국어 코멘트를 처리할 계획이라면 한국어 사례로 시험해야 한다. 공식 문서는 영어를 주된 학습 언어이자 현재 성능이 가장 좋은 언어로 설명한다. 영어 예제가 잘 된다는 사실로 한국어 작업의 품질을 대신 판단할 수는 없다. Models

2. 같은 질문을 코드에서 호출하기

질문을 정리한 뒤에는 API 키를 발급받아 코드에서 같은 요청을 보낸다. 다음은 Python 3.10 이상에서 실행할 수 있도록 공식 SDK 문서를 바탕으로 작성한 예제다. 이 글에서 실제 API 호출을 실행하거나 응답 품질을 측정한 것은 아니다.

python -m pip install typesafe-sdk

발급받은 키를 TYPESAFE_API_KEY 환경변수로 설정하고, 아래 코드를 try_jev.py로 저장한다. SDK는 이 환경변수에서 키를 읽는다. 키를 코드나 Git 저장소에 넣지 않는다.

from typesafe_sdk import Choice, TypeSafeClient

comment = (
    "요구사항에는 세션 만료 후 로그인 화면으로 이동해야 한다고 "
    "적혀 있습니다. 현재 구현에는 이 처리가 없습니다."
)

question = Choice(
    instructions=(
        "리뷰 코멘트가 주장하는 주된 문제를 분류하세요. "
        "주장의 사실 여부를 검증하지는 마세요. "
        "명시된 요구사항의 미구현은 BUG보다 MISSING_REQUIREMENT를 "
        "우선하고, 분류 근거가 부족하면 INSUFFICIENT_INFORMATION을 선택하세요."
    ),
    criteria={
        "BUG": "잘못된 동작이나 예외 발생을 지적한다.",
        "MISSING_REQUIREMENT": "명시된 요구사항의 미구현을 지적한다.",
        "SUGGESTION": "명시적 결함 없이 가독성이나 구조 개선을 제안한다.",
        "INSUFFICIENT_INFORMATION": "주된 문제를 분류할 정보가 부족하다.",
    },
)

with TypeSafeClient(model="jev-1.13.0") as client:
    result = client.system_one(
        state={"review_comment": comment},
        questions={"review_type": question},
    )

answer = result.choices["review_type"]
print("choice:", answer.choice)
print("probabilities:", answer.probabilities)
print("confidence:", answer.confidence)
print("usage:", result.usage)

python try_jev.py

3. 입력을 바꾸며 응답 비교하기

응답에서는 choice만 보지 말고 probabilities와 confidence를 함께 읽는다. 명확한 입력을 “이 부분은 다시 봐야 할 것 같습니다”처럼 바꿨을 때 정보 부족을 고르는지, 여러 항목에 확률을 나누는지, 한 항목으로 강하게 몰리는지 확인한다. 원하는 결과가 나올 것이라고 가정하지 말고 실제 응답을 남긴다. Usage

예제는 결과 비교를 위해 모델 버전을 고정했다. 최신 버전을 가리키는 이름을 사용할 수도 있지만, 모델이나 질문을 바꾼 뒤에는 이전에 정한 기준이 여전히 유효한지 다시 평가해야 한다.

처음 비교할 데이터는 자신이 이해할 수 있는 리뷰 20~30개 정도면 된다. 명확한 사례와 애매한 사례를 섞고, 모델의 답을 보기 전에 기대 분류를 붙인다. 일부 사례로 질문을 조정하고 남겨 둔 사례에서 다시 확인한다. 같은 기준을 기존 LLM에도 적용해 유형별 오류, 요청 시간, 사용량을 비교하면 된다. 이 표본은 초기 오류를 찾는 용도이며, 확률 보정이나 일반 성능을 입증할 규모는 아니다.

4. 검증한 결과를 코드의 분기에 연결하기

비교 결과를 확인한 뒤 코드의 분기를 붙인다. 예를 들어 검토가 끝난 요구사항 누락 코멘트를 재작업 목록에 넣고, 정보가 부족한 코멘트는 사람이 확인할 목록에 보낸다. 모델 결과와 정책을 구분하면 분류 기준을 바꿀 때와 실제 행동을 바꿀 때를 따로 관리할 수 있다. API 오류는 정상적인 ‘정보 부족’ 분류와 구분해 처리한다.

실험 비용도 대략 계산해 볼 수 있다. 질문과 선택지를 포함해 호출당 입력이 1,000토큰이고 이를 100회 호출한다면 총 입력은 10만 토큰이다. 현재 공식 단가로는 약 0.0042달러다. 재시도나 추가 질문에 사용한 입력은 별도로 포함하며, 무료 크레딧과 결제 조건은 콘솔에서 확인한다.

코딩 에이전트로 실습 코드를 작성할 수도 있다. TypeSafe는 API 사용법과 패턴을 제공하는 공식 agent skill을 안내한다. 이는 코딩 에이전트가 Jev 연동 코드를 작성하는 데 쓰는 자료다. 스킬을 설치한다고 기본 생성 모델이나 기존 내부 판단이 자동으로 Jev로 교체되는 것은 아니다. Jev with coding agents

다시, 리뷰 코멘트 하나에서 시작하기

처음에는 짧은 판단 하나를 얻으려고 LLM을 호출하는 문제에서 출발했다. 리뷰 처리를 나누면 테스트 결과 확인은 코드에, 코멘트의 유형 분류는 Jev에 맡기는 구성을 생각할 수 있다. 실제 결함의 분석과 수정에는 그에 맞는 모델과 도구가 필요하다.

Jev의 의미는 이런 역할 분담을 직접 시험할 수 있는 선택지를 제공한다는 데 있다. 요청마다 판단 기준을 정의하고, 여러 질문을 함께 평가하고, 반환된 확률을 코드의 정책에 연결한다. 개발자는 모델을 호출하는 것에 더해 어떤 정보를 보여주고 어떤 결과에서 행동할지를 설계하게 된다.

도입 여부는 같은 리뷰 데이터로 확인하면 된다. 필요한 품질을 내는지, 잘못된 판단을 어떻게 처리할지, 재검토와 재시도까지 포함한 비용과 시간이 줄어드는지를 비교한다. 앞으로도 독립적인 평가, 한국어 품질, 표현 변화에 대한 일관성, 실제 업무 결과가 쌓일수록 맡길 수 있는 범위가 분명해질 것이다.

개인 개발자가 시작할 지점도 여기다. 리뷰 분류, 메일 정리, 검색 문서 선별 중 자신이 결과를 검증할 수 있는 판단 하나를 고른다. 입력과 선택 기준을 적어 같은 사례를 Jev와 기존 방법으로 처리해 본다. 그 결과를 비교하는 작은 실험이 자신의 에이전트에 판단 모델이 필요한지 알려줄 것이다.