Jev를 에이전트에 붙이는 법, 판단은 모델에 맡기고 행동은 코드로 정한다

Jev의 Choice·Score·Noul을 에이전트에 배치하는 방법과 확률·confidence의 차이, 스키마 보장의 한계, 안전한 도입 절차를 정리한다.

게시 2026/09/24

By 정섭

15 분읽는 시간

TL;DR

Jev는 상태와 질문을 받아 미리 정한 형태의 판단을 돌려준다. LLM이 계획과 문장을 만드는 동안 모델 선택이나 도구 실행 전 점검 같은 작은 결정을 맡는다. 가능한 답과 이후 행동은 애플리케이션 코드가 정한다.
Choice와 Score는 확률 분포와 confidence를 반환하고 Noul은 참일 확률을 반환한다. confidence는 분포의 모양에서 계산한 통계량이므로 특정 답의 확률이나 실측 정답률과 같지 않다. 자동 처리와 재확인, 사람 검토의 경계는 실제 데이터와 오판 비용을 보고 정한다.
출력 스키마를 지킨다는 보장은 판단의 정확성을 보장하지 않는다. 허용된 선택지 안에서도 틀릴 수 있고 높은 confidence로 위험한 명령을 잘못 분류할 수도 있다. 권한과 샌드박스, 테스트처럼 정확하게 강제할 수 있는 통제는 별도로 유지한다.
TypeSafe의 발표 가격은 입력 100만 토큰당 0.042달러이며 출력은 무료다. 70~500밀리초 응답과 큰 비용·속도 개선 폭은 회사의 비교 조건에 따른 수치다. 한 가지 저위험 판단부터 기존 흐름 옆에서 시험하고 재시도·검토·실패 비용까지 포함해 평가한다.

에이전트가 문장을 쓰지 않아도 되는 순간

고객 문의가 긴급한지 판단하고 담당 팀을 고르는 데 긴 답변은 필요하지 않다. 그런데 에이전트는 도구 선택과 결과 검토, 위험 점검과 종료 판단에도 범용 LLM을 부르곤 한다. 도구 호출과 구조화 출력으로 소프트웨어 연동은 쉬워졌지만 답을 토큰 단위로 생성하는 과정은 남는다. Akshay의 글은 이런 작은 결정을 반복하는 비용을 Jev의 출발점으로 삼는다.

TypeSafe가 2026년 9월 15일 공개한 Jev는 자유로운 문장 생성을 포기하고 정해진 형태의 의미 판단에 집중한다. 입력은 현재 상황을 설명하는 state와 그 상태에 관한 questions다. 같은 상태를 대상으로 한 독립 질문들을 한 요청에 묶으면 회사 설명상 병렬로 평가된다. 긴급성과 담당 팀처럼 함께 판단할 수 있는 항목을 나누고 그 결과를 코드에서 조합하는 설계가 여기에 맞는다.

세 가지 질문과 코드가 정하는 행동

Choice는 미리 정한 선택지 중 하나를 고르고 각 선택지의 확률을 반환한다. Score는 낮음·중간·높음처럼 순서가 있는 기준에 입력이 어디쯤 놓이는지 연속 점수와 분포로 표현한다. Noul은 예·아니요 질문에 대해 참일 확률을 0에서 1 사이로 반환한다. 담당 팀은 Choice로, 심각도는 Score로, 즉시 대응이 필요한지는 Noul로 묻는 식이다.

원문의 장애 예시는 배포가 두 번 실패하고 고객에게 서버 오류가 발생하는 상황을 사용한다. 모델은 긴급성과 담당 팀의 판단을 제공하며 호출 알림이나 사람 검토, 대기열 배치는 프로그램이 결정한다. 글에 등장하는 확률과 분기 임계값은 구조를 설명하기 위한 예시로서 그대로 운영 정책이 되지는 않는다. 실제 LangChain 연동에서는 TypeSafeClassifier.invoke()에 상태와 질문을 넘기며 채팅 응답 대신 분류 결과를 받는다.

확률과 confidence를 구분해야 하는 이유

원문은 결제 담당 확률이 0.52이고 기술 담당이 0.46인 예시를 든다. 가장 높은 선택지만 보면 결제 팀으로 보낼 수 있지만 두 후보의 차이는 작다. 확률 분포를 함께 읽으면 자동 배정 전에 추가 정보나 검토가 필요한 상황을 구분할 수 있다. 이것은 실제 고객 데이터를 평가한 결과가 아니라 분포를 버리고 승자만 읽을 때의 문제를 설명하는 예시다.

공식 문서에서 confidence는 Choice와 Score의 확률 분포를 하나의 숫자로 요약한 값이다. 확률이 한쪽에 집중될수록 높고 여러 선택지에 퍼질수록 낮아지며 Noul에는 별도의 confidence 필드가 없다. TypeSafe가 RLCD로 학습한다고 설명하는 보정 목표는 여러 예측에 부여한 확률이 실제 결과와 맞도록 하는 데 있다. 90% 확률을 부여한 답들의 집합에서 정답 비율도 대략 90%이기를 기대하는 것과 개별 답의 confidence를 정답률로 읽는 것은 다르다.

처리 기준은 오판의 결과에 따라 달라진다. 낮은 위험의 화면 분류와 데이터를 지우는 명령에 같은 임계값을 적용할 이유는 없다. 확신이 부족하면 확인을 요청하거나 더 강한 모델과 사람에게 넘기고 필요한 정보를 더 모은다. 공식 문서의 고위험 작업 예시도 높은 confidence에서 곧바로 무조건 실행하지 않고 확인 절차를 거친다. 실제 서비스에서는 자체 정답 데이터로 분포와 정답률의 관계를 확인해야 하며 출시 글의 보정 주장만으로 충분하지 않다.

형식 보장과 보안 통제는 서로 다른 문제다

선택지를 결제·기술·영업으로 정했다면 Jev가 목록에 없는 법무 팀을 새 답으로 만들어 내지 않는다는 것이 스키마 보장이다. 그 안에서 틀린 팀을 고르는 일은 여전히 가능하다. 형식에 맞는 오류도 잘못된 환불이나 사고 배정으로 이어질 수 있다. 원문이 환각 방지 주장을 좁게 해석하는 이유는 문법적으로 유효한 값과 업무상 올바른 판단을 구분하기 위해서다.

에이전트 안에서는 모델 라우팅과 도구 실행 전 점검, 작업 결과 검토에 이 판단을 배치할 수 있다. LangChain의 ModelRouterMiddleware는 최신 사용자 메시지를 보고 실행에 사용할 모델을 선택하며 AutoModeMiddleware는 도구가 실행되기 전에 호출을 검사해 차단할 수 있다. 모델이 완료를 선언했는지와 실제 테스트가 통과했는지는 다른 문제다. 의미 기반 검사는 정확한 테스트를 대체하지 않고 권한·격리·테스트로 강제하기 어려운 판단을 보완한다.

에이전트 밖에서도 비슷한 구조를 적용한다. 고객 문의의 의도와 긴급성을 함께 분류하거나 검색된 문서가 질문에 실제로 답하는지 재정렬하고 문서 집합을 같은 기준으로 평가할 수 있다. 검색에서는 의미상 관련된 텍스트를 찾는 일과 특정 질문의 답으로 쓸 만한지 판단하는 일을 구분한다. 브라우저나 게임의 다음 행동을 고르는 경우에도 현재 Jev는 텍스트 입력을 사용하므로 환경을 텍스트나 JSON으로 바꿔 전달해야 한다. 화면 픽셀을 직접 보고 판단하는 모델로 이해하면 적용 범위를 잘못 잡는다.

가격표보다 먼저 확인할 도입 조건

TypeSafe의 출시 자료는 입력 100만 토큰당 0.042달러와 무료 출력, 70~500밀리초의 종단 간 응답 시간을 제시한다. 약 200배의 속도와 약 400배의 비용 개선이라는 원문의 큰 수치는 회사 자체 워크플로 평가에서 나온 유리한 결과에 가깝다. 해당 평가는 사람의 정답 라벨 대신 대형 외부 모델의 평균 예측을 기준으로 사용하며 비교 LLM도 확률을 포함한 구조화 결정을 출력한다. 서비스 위치와 입력 길이, 비교 모델의 추론 설정이 달라지면 같은 개선 폭을 기대할 수 없고 출력이 무료여도 입력과 질문 토큰 비용은 남는다.

적합하지 않은 문제도 분명하다. 문장과 코드 생성이나 여러 단계의 숨은 추론이 필요한 작업에는 다른 모델이 필요하고 산술·개수 세기·날짜 비교·정확한 문자열 처리는 코드에 남기는 편이 맞다. 미리 모르는 값을 자유롭게 추출해야 한다면 후보를 먼저 확보한 뒤 선택하게 만드는 식으로 문제를 바꿔야 한다. 무관한 문맥을 많이 넣으면 정확도가 떨어질 수 있으며 폐쇄형 가중치와 초기 접근 단계, 제한적인 독립 보정 자료도 신뢰 범위를 판단할 조건이다. 일반 조건문으로 정확히 해결되는 일을 모델로 바꾸는 데는 별도 이익이 없다.

도입은 가능한 답을 명확히 정할 수 있는 저위험 판단 하나에서 시작한다. 모호하거나 적대적인 입력까지 포함한 대표 사례에 기대 답을 붙이고 기존 흐름을 바꾸지 않는 섀도 모드로 Jev의 결과를 나란히 기록한다. 그 데이터로 정확도와 confidence를 비교한 뒤 안전한 분기부터 자동화하고 재시도와 사람 검토, 사고 비용을 포함해 전체 흐름을 평가한다. 모델 버전과 질문·기준·임계값을 기록하고 어느 하나를 바꿀 때마다 같은 평가를 다시 실행한다. 질문을 프로그램의 일부로 관리하고 실제 행동 권한은 코드에 남기는 것이 이 도입 방식의 핵심이다.