Jev는 대화 생성에 특화된 LLM과 달리, 주어진 상황과 선택지 사이에서 확률을 포함한 판단을 내리도록 설계된 범용 의사결정 모델이다. TypeSafe는 이를 통해 자동화의 비용과 지연을 크게 낮추려 하지만, 실제 시험에서는 높은 확률의 오답, 질문 표현에 따른 확률 불일치, 호출마다 달라지는 결과도 확인됐다. 따라서 Jev의 핵심 가치는 모든 결정을 대체하는 데 있기보다, 좁고 반복적인 판단을 빠르게 처리하되 코드와 사람의 검증 체계 안에서 활용하는 것에 있다.

1. Jev가 던지는 질문: 왜 뛰어난 대화 모델은 자동화로 이어지지 않았나

Jev를 만든 Diogo Almeida는 ChatGPT 공동 개발자이자 OpenAI의 InstructGPT 연구 참여자, GPT-4 저자 중 한 명으로 소개된다. 그는 오늘날 LLM 흐름의 중심에 있었지만, 지난 약 4년 동안 오히려 LLM이 실무 자동화에 충분히 쓰이지 못하는 이유를 고민해 왔다.

그가 던진 질문은 단순하다.

"모델은 이미 오래전부터 대화에서 사람을 능가하는데, 왜 실제 자동화는 거의 일어나지 않는가."

Almeida의 답은 모델의 능력 자체보다 최적화 목표가 잘못되었다는 데 있다. 기존의 RLHF, 즉 사람이 선호하는 답변을 하도록 모델을 조정하는 방식은 모델이 사실에 맞는 답보다 그럴듯하고 자신감 있어 보이는 답을 내놓게 만들 수 있다는 것이다.

특히 보상 모델은 "잘 모르겠다"는 망설임을 확신에 찬 오답보다 더 나쁘게 평가하기 쉽다. GPT-4 기술 보고서에서도 사전학습 단계의 GPT-4는 자신의 확신도와 실제 정답률이 거의 맞았지만, 사후학습 이후에는 그 일치도가 크게 나빠졌다고 언급된다. 본문은 이를 ECE 기준으로 다음처럼 설명한다.

• 사전학습 GPT-4의 ECE: 약 0.007
• 사후학습 뒤 ECE: 약 0.074

즉, 모델이 "95% 확신한다"고 말해도 정말 95% 확률로 맞는지 믿기 어려워진다면, 자동화에 쓰기 곤란하다. 95%를 맞히더라도 어느 5%가 틀릴지 알려주지 못하면, 결국 사람이 모든 결과를 다시 확인해야 하기 때문이다.

2. 기존 LLM 자동화 방식에 대한 비판

그동안 개발자들은 LLM을 실제 소프트웨어에 넣기 위해 여러 안전장치를 덧붙여 왔다. 대표적으로 구조화 출력, JSON 스키마 강제, 파서, 재시도, 가드레일 등이 있다.

하지만 Almeida는 이런 방법이 근본 해결책이 아니라고 본다. 모델이 잘못된 형식의 토큰을 생성하지 못하도록 로짓을 마스킹하는 것은 겉으로 드러난 문제를 막는 일일 뿐이며, 애초에 모델이 잘못된 토큰에도 확률을 부여하고 있다면 내부적으로는 이미 혼란스러운 상태라는 주장이다.

Jev는 이와 다른 방향을 택한다. 긴 문장을 자연스럽게 생성하는 대신, 특정 상황에서 가능한 선택지 중 무엇이 적절한지 판단하고, 그 판단에 확률을 붙여 반환하는 데 초점을 둔다.

이름은 제번스 역설(Jevons paradox)에서 따왔다. 증기기관 효율이 높아지자 석탄 사용량이 줄어들기는커녕 오히려 증가했던 것처럼, 지능을 쓰는 비용이 크게 낮아지면 AI를 사용할 수 있는 업무 영역은 더 넓어질 것이라는 기대를 담고 있다. ⚙️

3. Jev가 해결하려는 문제와 기본 인터페이스

실제 업무 자동화는 거대한 판단보다 작은 판단에서 자주 멈춘다. 예를 들어 다음과 같은 질문들이다.

• 고객이 실제로 환불을 신청한 것인가, 아니면 절차만 물어본 것인가?
• 검색한 문서가 현재 업무와 관련 있는가?
• 지금 다음 단계로 진행해도 되는가?
• 게임이나 브라우저에서 다음 행동은 무엇이어야 하는가?

사람은 문맥을 읽고 자연스럽게 구분하지만, 소프트웨어는 이런 작은 판단을 맡길 대상이 필요하다. 기존 LLM도 가능은 하지만, 애초에 의사결정을 위해 만들어진 모델이 아니므로 비효율이 있다는 것이 본문의 관점이다.

TypeSafe의 Jev는 상황(state), 질문(questions), 가능한 답과 판단 기준(Choice)을 입력받는다. 그리고 정해진 형식으로 선택 결과와 확률을 반환한다.

답의 분포 = Jev(상황, 질문, 가능한 답과 판단 기준)

업무가 바뀌어도 매번 새 모델을 학습시키는 것이 아니라, 입력으로 전달하는 상황과 질문, 선택지 설명을 바꾼다. 예를 들면 고객 메시지가 다음과 같다고 하자.

"신발이 작아서 교환 절차만 알려 주세요. 아직 신청하지는 않을게요."

이 문장에 대해 "현재 의도가 무엇인가?"라고 물으면, 선택지는 절차 문의, 교환 신청, 신청 취소처럼 구성할 수 있다. 반대로 "어느 부서가 담당해야 하는가?"라고 묻고 각 부서의 역할을 설명하면, 같은 고객 메시지도 다른 판단 문제가 된다.

핵심은 모델에 단순한 라벨만 주는 것이 아니라, 이번 호출에서 사용할 분류 체계와 각 선택지의 의미까지 함께 전달한다는 점이다.

4. 제로샷 판단과 RLCD 학습 방식

Jev는 새 업무마다 정답 예시를 여러 개 제공하거나 추가 학습을 요구하지 않는다. 업무 설명과 판단 기준만으로 새 사례를 처리하는데, 이를 제로샷(zero-shot) 방식이라고 한다.

이 방식은 모델이 이미 갖춘 언어 이해 능력에 기반한다. 사람의 말에서 의도를 읽고, 규정 조건을 이해하며, 현재 상황과 선택지를 연결하는 능력을 새로운 업무에 옮겨 쓰는 것이다. 고객 상담에서 문서 평가로 업무가 바뀌더라도, 모델은 새롭게 전달된 질문과 기준을 해석해 기존 능력을 적용한다.

모델 개발 단계에서 TypeSafe는 사전학습 언어모델을 바탕으로 RLCD라는 방식으로 Jev를 훈련했다고 설명한다.

• RLCD: Reinforcement Learning for Calibrated Decisions
• 뜻: 모델이 내린 결정과 그 결정에 붙인 확률이 실제 결과와 잘 맞도록 학습하는 강화학습 방식

다만 구체적인 학습 데이터, 손실 함수, 내부 아키텍처는 공개되지 않았다. 사용자는 이미 학습된 모델 가중치를 바꾸지 않고, 자신의 자료와 판단 기준만 입력한다. TypeSafe는 고객별 추가 학습을 하지 않으며, 요청과 응답을 학습에 사용하지 않는다고 밝힌다.

여러 단계로 이어지는 업무에서는 이전 판단 결과를 다음 요청의 state에 넣을 수 있다. 하지만 이력을 저장하고, 필요한 정보를 고르고, 다음 입력으로 정리하는 일은 Jev가 아니라 주변 시스템이 담당한다.

5. 직접 시험한 결과: 짧은 언어 판단에서는 좋은 성적

본문은 Jev의 범용성을 검증하기 위해, 가상의 고객 문의와 쇼핑몰 주문 기록을 이용한 작은 시험을 진행했다. 모든 데이터는 이번 평가를 위해 새로 만든 가상 데이터이며, 다른 모델의 답변을 정답으로 삼지 않고 사전에 직접 정답을 정했다.

시험은 다음과 같이 구성됐다.

• 한국어 10개와 영어 10개 문장에 대해, 사례별 5개 질문을 던진 총 100개 판단
• 가상 환불 업무 8건에 대해, 원본 기록과 코드로 정리한 상태를 각각 전달한 시험
• 동일 입력을 반복하거나 질문 수를 1개·4개·16개로 바꾼 속도 시험

모든 호출은 서로 다른 요청 ID를 사용했고, 응답 모델 버전은 모두 jev-1.13.0이었다.

짧은 언어 판단에서는 한국어 50개, 영어 50개로 구성된 100개 판단을 모두 맞혔다. 특히 단순한 키워드 매칭으로는 헷갈릴 수 있는 부정 표현과 조건문도 구분했다.

예를 들어 모델은 다음과 같은 차이를 처리했다.

• "환불해 달라는 게 아닙니다"
• "환불을 원하지 않는다는 뜻은 아닙니다"
• 이미 요청했던 환불을 취소한 경우
• "내일까지 해결되지 않으면 그때 환불을 요청하겠다"라는 미래 조건부 요청
• "환불 절차만 알려 달라"는 정보 문의
• "그거 좀 처리해 주세요"처럼 정보가 부족한 표현

특히 마지막처럼 판단 근거가 부족한 문장을 한국어와 영어 모두에서 unknown으로 분류했다. 다만 이는 애초에 unknown이라는 선택지를 제공한 상태에서 나온 결과다.

본문은 이 성적만으로 "한국어 실무 처리에 충분하다"는 결론을 내릴 수는 없다고 선을 긋는다. 실제로는 독립적인 의미가 열 가지뿐이었고, 오탈자, 긴 대화, 도메인 전문용어 등 현실의 복잡한 조건은 포함되지 않았기 때문이다.

6. 복합 환불 업무에서 드러난 입력 설계의 중요성

환불 승인 여부는 단순한 문장 의도 파악보다 어렵다. 고객이 환불을 요청했는지 확인하는 것뿐 아니라, 주문 기록을 연결하고 날짜와 금액도 계산해야 하기 때문이다.

가상 환불 정책은 다음 네 가지 조건을 모두 만족할 때만 승인하도록 정해졌다.

1. 고객이 현재 환불을 요청하고 있을 것
2. 상품 수령일부터 30일 이내일 것
   • 정확히 30일째도 허용
3. 상품이 미개봉일 것
4. 결제 완료 금액에서 이미 환불된 금액을 뺀 잔액이 0원보다 클 것

입력에는 주문 세 건, 청구서, 결제 기록, 다수의 환불 기록이 포함됐고, 일부는 현재 처리와 관계없는 다른 주문 기록도 섞여 있었다.

처음 비교에서는 질문 문구와 질문 수가 달라 대조가 불완전했기 때문에, 본문은 동일한 Choice 질문 하나를 사용한 추가 실험을 했다. 그 결과는 다음과 같았다.

• 원본 기록 입력: 8건 중 5건 정답
• 코드로 정리한 상태 입력: 8건 중 8건 정답

정리된 입력의 총 토큰 수는 4,599개였고, 원본 기록은 8,543개였다. 즉, 정리된 입력은 약 46.2% 더 짧았으면서도 더 좋은 결과를 보였다.

다만 본문은 이것을 단순히 "토큰이 적어서 좋아졌다"고 해석하지 않는다. 상태 길이, 정보 구성, 코드 계산 여부가 한꺼번에 바뀌었기 때문에 어떤 요소가 가장 큰 영향을 줬는지 분리하기 어렵다는 것이다.

이 시험이 보여주는 실용적 교훈은 명확하다. 날짜 계산, 금액 계산, 데이터 연결처럼 코드가 확실히 할 수 있는 일은 코드가 먼저 처리하고, Jev에는 좁은 의미 판단을 맡기는 편이 좋다.

7. 실제로 틀린 세 가지 환불 판단

복합 환불 시험에서는 Jev가 틀린 사례도 세 가지 있었다. 이는 Jev가 확률을 반환한다고 해서 판단이 항상 정확하거나 논리적으로 일관된다는 뜻은 아니라는 점을 보여준다.

반품 기한이 하루 지난 주문

첫 사례는 수령 후 31일이 지난 주문이었다. 정책상 30일 이내만 환불 가능하므로 거절이 맞다.

하지만 Jev는 처음에 최종 승인 확률을 80%로 반환했다. 같은 요청 내부의 개별 질문에서는 "30일 이내인가?"에 대해 충족 확률을 34%로 답했다. 개별 조건을 조합하면 거절이 맞는데도 최종 결론은 승인으로 나온 것이다.

질문 문구를 고정한 대조 실험에서도 다음과 같은 결과가 나왔다.

• 승인 확률: 92%
• confidence: 0.85
• 같은 입력 반복 호출: 승인 확률 88%, 89%

즉, 단순한 우연이 아니라 같은 잘못된 판단이 반복됐다.

이미 전액 환불된 주문

두 번째 사례는 결제액이 129,900원이고, 이미 69,900원과 60,000원이 환불되어 잔액이 정확히 0원인 주문이었다. 따라서 환불할 돈이 남아 있지 않아 거절해야 한다.

그런데 Jev는 잔액이 양수일 확률을 76%로 판단했고, 최종 승인도 67%로 선택했다. 질문을 세분화해도 모델이 금액 계산을 틀리면 오류가 남았다.

반면 코드가 잔액을 계산해 "잔액은 0원"이라는 사실을 상태에 직접 넣자 결과는 거절로 바뀌었다. 이는 계산형 판단을 모델에 전적으로 맡기지 말아야 하는 이유를 잘 보여준다.

정확히 30일이 된 주문

세 번째 사례는 수령 후 정확히 30일이 지난 주문이었다. 정책상 허용되는 사례다.

개별 질문에서는 조건 충족 확률이 비교적 높게 나왔다.

• 현재 환불 요청: 90%
• 기간 충족: 93%
• 미개봉: 97%
• 양수 잔액: 83%

그런데 최종 질문에서는 오히려 거절 58%가 선택됐다. 개별 조건을 코드로 조합하면 승인인데, 모델이 종합 판단에서는 반대 결론을 낸 것이다.

이는 병렬로 나온 여러 답변이 자동으로 하나의 일관된 논리 체계를 이룬다고 볼 수 없다는 뜻이다.

8. 확률·신뢰도·반복성: 자동화 규칙에서 조심할 점

Jev는 보통 선택 결과, 선택지별 확률, 그리고 별도의 confidence를 함께 반환한다.

choice: "승인"
probabilities: { 승인: 0.92, 거절: 0.06, 보류: 0.02 }
confidence: 0.85

본문은 이 숫자를 자동화 분기 조건에 활용할 때 세 가지 주의점이 있다고 설명한다.

높은 확률이 정답을 보장하지 않는다

31일이 지난 주문은 분명 거절해야 했지만, Jev는 승인에 0.92를 부여했다. 만약 시스템이 "승인 확률이 0.9를 넘으면 사람 검토 없이 자동 승인한다"는 규칙을 썼다면, 이 오답은 그대로 처리됐을 것이다.

다만 한 번의 고확률 오답만으로 Jev의 확률 보정이 실패했다고 단정할 수는 없다. 예를 들어 0.9라고 표시한 답들이 실제로 90% 확률로 맞는지 보려면, 그 구간의 사례를 수백 건 이상 모아 실제 정답률을 비교해야 한다.

또한 confidence는 선택지 확률과 별개다. 선택지 확률은 각 답에 붙는 값이고, confidence는 전체 확률 분포가 한쪽으로 얼마나 쏠렸는지를 요약한 수치다. 따라서 "0.9 이상이면 자동 처리"라는 기준을 어느 값에 적용할지에 따라 결과가 달라진다.

긍정과 부정 질문이 서로 보완되지 않는다

같은 문장에 대해 다음 두 질문을 각각 던졌다고 하자.

• "지금 환불을 요청하고 있는가?" → 0.63
• "지금 환불을 요청하고 있지 않은가?" → 0.07

두 번째 답을 뒤집으면, 환불을 요청하고 있을 확률이 0.93이라는 뜻이 된다. 결국 같은 사실을 물었는데도 0.63과 0.93이라는 서로 다른 값이 생긴다. 두 값의 합이 1이 아니라 0.70인 점이 문제를 드러낸다.

Jev는 각 질문을 독립적으로 채점하며, 여러 답변을 하나의 일관된 확률 체계로 맞추지 않는다. 따라서 반대 질문의 확률을 단순히 더하거나 빼서 사용하면 안 된다. 반대 확률이 필요하다면 한 방향만 질문한 뒤 코드에서 1을 빼는 방식이 더 안전하다.

같은 입력도 약간씩 다른 결과를 낸다

동일한 문장을 세 번 보냈을 때 확률이 0.63, 0.64, 0.65로 조금씩 달라졌다. 전액 환불 주문의 잘못된 승인 확률은 0.60, 0.65, 0.78처럼 더 크게 흔들리기도 했다.

이번 시험에서는 선택 자체가 뒤집히지는 않았지만, 임계값 근처의 사례라면 문제가 된다. 자동 처리 기준이 0.7일 때 결과가 0.69와 0.71 사이를 오간다면, 같은 요청이 어떤 때는 자동 처리되고 어떤 때는 사람 검토로 넘어갈 수 있다.

따라서 애매한 확률 구간은 처음부터 사람 검토 대상으로 두거나, 한 번 내린 결정을 일정 시간 유지하는 장치가 필요하다.

"어떤 숫자를 어떤 기준으로 쓸지, 애매한 구간은 어떻게 처리할지는 모델 바깥에서 정하고 직접 검증해야 한다."

9. 속도와 비용: 여러 판단을 한 번에 묻는 장점

총 68회 호출의 서버 처리 시간은 다음과 같았다.

• 중앙값: 113.6ms
• 95백분위: 484.3ms
• 최솟값: 62.9ms
• 최댓값: 1,263.8ms

응답의 evaluation_time_ms를 기준으로 측정한 값이다. 화면에 표시된 네트워크 시간 중앙값은 약 566ms였고, 둘을 합한 중앙값은 약 672ms였다. 다만 네트워크 시간은 화면의 반올림된 수치라 엄밀한 종단 간 측정으로 보기는 어렵다.

같은 상태에서 질문 수만 바꾼 속도 실험도 진행됐다.

• 질문 1개: 87.4ms
• 질문 4개: 106.4ms
• 질문 16개: 113.5ms

각 조건은 세 번씩 실행됐으며 순서는 섞었다. 질문 수가 16배가 되어도 지연 시간이 비례해서 늘지 않았기 때문에, 여러 판단을 한 번에 요청하는 방식의 장점이 관찰됐다. 다만 조건별 표본이 세 번뿐이므로, 대규모 부하나 긴 문서 환경까지 일반화할 수는 없다.

총 입력량은 52,974토큰이었다. 공개 요금인 입력 100만 토큰당 0.042달러를 적용하면 약 0.22센트 수준이며, 출력 5,577토큰은 해당 요금제에서 무료다. 다만 이는 공개 단가와 사용량으로 계산한 추정치일 뿐, 실제 청구서를 검증한 값은 아니다.

본문은 다른 모델을 동일한 조건에서 함께 비교하지 않았으므로, Jev가 몇 배 더 빠르거나 싸다고 단정하는 수치는 제시하지 않는다.

10. 실제 활용 사례와 선택지의 제약

Jev의 공개 사례는 크게 세 방향으로 나뉜다.

1. 게임과 브라우저에서 다음 행동을 선택하는 사례
2. 문서와 코드를 여러 기준으로 평가하는 사례
3. 생성 모델의 결과를 검사하고 다음 처리 경로를 정하는 사례

각 사례에서 주변 프로그램은 상태와 후보 행동을 준비하고, Jev가 내린 판단을 실제 실행으로 연결한다. 이런 실행 틀은 흔히 하네스(harness)라고 불린다. 따라서 데모를 볼 때는 Jev 자체가 내린 판단과, 하네스가 제공한 기능을 구분해 봐야 한다.

공개된 커뮤니티 목록에는 9월 18일 기준으로 빌드 133개와 가이드 45개가 올라와 있으며, 에이전트·브라우저·도구·앱·게임·실시간 분야 순으로 사례가 많다고 소개된다.

Jev의 행동 공간은 실행 중에 구성된다. "선택지를 미리 정한다"는 말은 개발 단계에서 모든 후보를 고정한다는 뜻이 아니다. 호출 직전, 프로그램이 현재 상황에 맞는 후보를 만들어 요청에 실어 보낸다는 의미다.

체스에서는 현재 판에서 가능한 합법 수를 코드가 만들고, 브라우저 에이전트에서는 DOM에서 조작 가능한 요소를 추린다. 고객 상담에서는 시스템에 등록된 부서 목록을 선택지로 넣을 수 있다.

"후보를 만드는 쪽은 언제나 코드다."

Jev는 텍스트를 생성하지 못하므로, 존재하지 않는 행동을 스스로 만들어낼 수 없다. 대신 전달받은 후보 각각에 점수를 매기고 하나를 선택한다. 이는 제약이면서 동시에 장점이다. 후보 집합 밖의 행동은 할 수 없으므로, 화면에 없는 버튼이나 존재하지 않는 체스 수를 고르는 위험도 줄어든다.

다만 한 Choice에 담을 수 있는 후보는 최대 255개다. 조향각처럼 연속적인 값, 후보 목록에 없는 새 행동은 다루기 어렵다. 링크가 수천 개인 위키 탐색처럼 후보가 많은 경우에는 먼저 점수를 매겨 후보를 줄인 뒤, 다시 선택하는 2단계 방식을 써야 한다.

TypeSafe의 보험 청구 예시에서는 같은 요청을 15번 보내자 보장 여부 확률이 0.43에서 0.53 사이를 오갔다. 0.5만 넘으면 자동 승인하는 규칙이었다면, 같은 청구 건이 어떤 호출에서는 승인되고 다른 호출에서는 거절될 수 있다.

그래서 해당 예시는 단일 경계선으로 자르기보다, 0.30~0.70 구간을 사람 검토 영역으로 비워 두라고 권한다.

11. Jev와 에이전틱 프레임워크의 역할 분담

Jev는 호출 한 번에 현재 순간의 판단 하나를 내릴 뿐이다. 여러 판단을 이어 장기적인 업무를 완수하려면 별도의 시스템이 필요하다. 이 시스템은 일반적으로 에이전틱 프레임워크라고 불린다.

에이전틱 프레임워크는 다음 일을 맡는다.

• 목표와 처리 중인 업무의 상태를 기억하기
• 필요한 사실과 대화 이력을 수집하기
• 최신 정보를 정리해 Jev의 입력으로 만들기
• 현재 단계의 질문과 선택지를 구성하기
• Jev의 답을 실제 행동으로 옮기기
• 실행 결과를 다음 상태에 반영하기

가장 실용적인 구조는 다음과 같이 역할을 나누는 방식이었다.

1. 프레임워크가 주문 정보와 대화 이력을 유지한다.
2. 코드가 날짜, 금액, 환불 잔액처럼 명확히 계산 가능한 사실을 계산한다.
3. Jev는 고객 발화가 환불 신청인지, 취소인지, 절차 문의인지처럼 좁은 의미 판단을 한다.
4. 코드가 정책 조건과 실행 권한을 최종 확인한다.
5. 처리 결과를 상태에 기록하고, 필요하면 다음 판단으로 넘긴다.

이 구조에서 Jev는 경우에 따라 정책(policy)의 일부가 될 수 있다. 현재 관찰, 목표, 이력을 바탕으로 허용된 행동들에 대한 분포를 내놓기 때문이다. 반대로 글을 채점하거나 오류를 검사하는 업무에서는 평가기 역할을 한다.

중요한 점은 Jev가 짧은 범위의 판단을 담당한다는 것이다. 브라우저의 다음 클릭 한 번, 로봇의 짧은 동작 묶음처럼 시간 단위는 달라도, 더 큰 목표를 이루기 위한 일부 행동이라는 점에서는 같다. 장기 과제를 수행하려면 Jev 외부에서 목표 관리, 상태 갱신, 행동 실행, 피드백 처리가 계속 이루어져야 한다.

12. 마무리: Jev는 만능 의사결정기가 아니라 판단 부품이다

Jev를 범용 의사결정 모델이라 부를 수 있는 이유는, 단순히 상황만 받는 것이 아니라 판단 기준과 허용된 선택지까지 입력으로 받기 때문이다. 고객 요청과 분류 기준을 주면 문의를 분류하고, 현재 웹페이지와 조작 가능한 요소를 주면 다음 행동을 선택할 수 있다.

업무마다 모델을 새로 학습시키지 않고도, 사전학습으로 얻은 이해 능력을 현재의 상황과 기준에 적용할 수 있다는 점은 분명한 장점이다. 결국 Jev를 실제 업무에 붙이는 일은 모델을 재훈련하는 것보다 다음을 설계하는 일에 가깝다.

• 무엇을 상태로 보여줄 것인가
• 무엇을 질문할 것인가
• 어떤 선택지를 허용할 것인가
• 어떤 결과를 자동 처리하고, 어디서 사람에게 넘길 것인가

하지만 본문이 강조하듯, Jev가 의사결정 문제 자체를 해결한 것은 아니다. 테스트에서는 고확률 오답, 논리적 불일치, 질문 표현에 따른 확률 차이, 동일 입력의 결과 변동이 실제로 나타났다.

"Jev의 가치는 '의사 결정을 저렴하고 빠르게' 하는 것이다."

따라서 Jev가 곧바로 컴퓨팅 자원 활용 문제나 자율주행 같은 고위험 자율 시스템을 해결해 주는 것은 아니다. 지금 확실한 활용처는 선택지가 좁고, 반복 건수가 많으며, 코드와 사람의 검증 체계가 함께 있는 판단 업무다.

Jev가 앞으로 더 정확해지더라도, 무엇을 보여주고 어떤 후보를 만들지 결정하는 주변 시스템의 중요성은 사라지지 않는다. 결국 Jev는 모든 것을 대신하는 지능이라기보다, 잘 설계된 시스템 안에서 빠르고 저렴하게 판단을 제공하는 의사결정용 부품으로 이해하는 것이 가장 적절하다.