Jev는 에이전트가 아닙니다: 판단 전용 모델 이해하기

최근 TypeSafe가 공개한 Jev를 두고 그 정체를 생소하게 생각하는 분이 많습니다. Jev가 에이전트라는 용어와 혼용되는 경우가 많은데 TypeSafe가 설명하는 Jev의 역할은 조금 다릅니다. Jev는 글을 쓰거나 다음 행동을 고르는 에이전트가 아닙니다. 프로그램이 넘겨준 상태를 보고, 미리 정해 둔 질문에, 정해진 형태의 값과 확률로 답하는 모델입니다.

쉽게 말하면 Jev는 에이전트가 아니라 에이전트가 사용할 수 있는 판단 부품입니다. 이 글에서는 이 차이를 중심으로 Jev가 무엇인지 살펴보겠습니다.

Jev는 지금까지 보지 못했던 모델의 모습이지만, 이 모델을 활용하여 더 강력하고 효율적인 시스템을 만들기 때문에 이해하는 것이 중요합니다.

한 문장으로 이해하기

Jev는 문장을 만들지 않습니다. 프로그램이 넘겨준 상태를 보고, 미리 적어 둔 질문에, 미리 정한 형태의 값과 확률로 답합니다.

공식 모델 이름은 System One입니다. ‘판단 전용 모델’이라는 표현은 이 개념을 이해하기 쉽게 풀어 쓴 말입니다.

TypeSafe의 공식 문서는 System One을 다음과 같이 설명합니다.

System One은 에이전트를 만드는 모델이 아니라, 소프트웨어 안에 넣는 모델이다. 코드를 생성하지 않고, 다음 행동도 스스로 고르지 않는다.

정리하면 Jev는 판단 결과만 돌려줍니다. 그 결과를 이용해 메일을 보내거나 티켓을 옮기거나 명령을 실행하는 일은 코드가 담당합니다.

Jev는 모델이다

Jev는 모델입니다. "모델"의 잘 알려진 예시는 gpt, claude, llama 가 있습니다. 이런 모델들은 모두 질문을 하면 문장을 출력하는 것이 가장 기본적인 기능입니다. 그런데 Jev라는 모델은 글이나 문장을 출력해주는 모델이 아니라, 판단 결과만 출력하는 모델입니다. yes/no 혹은 숫자, 선택지 같은 형태의 출력만 제공합니다.

Jev는 에이전트가 아니다

Jev가 에이전트처럼 보이는 이유도 있습니다. 다른 도구와 연결하면 브라우저를 조작하는 데모를 만들 수 있기 때문입니다. 영상만 보면 모델이 화면을 보고 버튼을 누르는 것처럼 보입니다.

하지만 버튼을 누르는 쪽은 Jev가 아닙니다. 바깥 프로그램이 화면을 읽고 가능한 행동 목록을 만든 뒤, 선택된 행동을 실제로 실행합니다. Jev는 그 목록에서 어떤 행동이 적절한지 판단할 뿐입니다.

그래서 ‘Jev 에이전트’라는 말에는 두 가지가 섞여 있습니다.

• Jev: 정해진 보기 안에서 판단하는 모델
• 에이전트: 판단을 받아 도구를 호출하고 결과를 다시 읽으며 반복하는 프로그램

판단을 루프 안에 넣었다고 해서 판단 자체가 루프가 되는 것은 아닙니다.

에이전트와 Jev의 차이

에이전트는 목표를 받으면 보통 다음 과정을 반복합니다.

1. 지금 무엇을 해야 하는지 정합니다.
2. 검색, 클릭, 명령 실행 같은 도구를 부릅니다.
3. 실행 결과를 읽고 끝났는지 다시 판단합니다.
4. 일이 끝날 때까지 1번으로 돌아갑니다.

이 방식은 편리하지만 자유가 큰 만큼 주의할 점도 있습니다. 없는 도구를 부르거나, 요청과 다른 일을 하거나, 같은 행동을 반복할 수 있습니다. 그래서 중요한 작업에는 사람이 확인하는 장치가 필요합니다.

반면 Jev가 들어가는 자리는 더 좁습니다.

1. 코드가 상태와 질문을 넘깁니다.
2. Jev가 값과 확률을 돌려줍니다.
3. 코드의 if가 보낼지, 막을지, 사람에게 넘길지 결정합니다.
4. 문장이 필요하면 그때 별도의 글 생성 모델을 부릅니다.

Jev는 어떤 판단을 할까?

숫자가 10보다 큰지, 티켓이 이미 닫혔는지, 글자에 ‘환불’이 들어 있는지는 일반 코드로 충분히 판단할 수 있습니다. 하지만 “이 메일이 화난 말인가?”, “기술 문제인가 결제 문제인가?”처럼 문장의 의미를 봐야 하는 판단은 규칙만으로 처리하기 어렵습니다.

Jev는 이런 의미 판단을 맡습니다. 식당에 비유하면 에이전트는 주문을 듣고 주방에 들어가 요리까지 하려는 사람입니다. Jev는 주문지를 보고 파스타인지, 매운 정도가 어느 칸인지, 알레르기 언급이 있는지만 체크합니다. 실제로 요리할지는 주방의 규칙, 즉 코드가 정합니다.

시험으로 보면 객관식에 가깝습니다. 프로그램이 보기를 만들고 모델은 보기 안에서 하나를 고릅니다. 보기 밖의 답을 새로 쓸 칸은 없습니다. 다만 보기 안에서 잘못 고르는 오판은 여전히 가능합니다.

State와 질문 알아보기: 메일 한 통으로 살펴보기

다음과 같은 메일을 받았다고 상상해 봅시다.

Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.

안녕하세요. Stripe 계정을 3일째 연결하려고 하는데 계속 실패합니다. 이로 인한 매출 손실이 발생하고 있어서 가능하면 빨리 도움을 부탁드립니다.

이 메일이 모델에 전달되는 **상태(State)**입니다. 상태는 여기서는 이메일 한통이지만, 로그 한 줄이나 JSON일 수도 있습니다. 중요한 것은 상태와 질문을 분리하는 것입니다.

• 상태: 무슨 일이 있었나?
• 질문: 그중 무엇을 판단할까?

한 번의 호출에서 세 가지를 묻습니다. 어느 팀으로 보낼지, 얼마나 답답해 보이는지, 급한 말인지입니다. 문서에 소개된 예시 응답을 읽기 쉽게 정리하면 다음과 같습니다.

여기에는 답장 문장이 없습니다. “연동 로그를 보내 달라” 같은 문장을 Jev가 만들어 주지도 않습니다. 팀 이름도 모델이 새로 만든 것이 아니라, 질문할 때 미리 넣어 둔 technical, billing, sales 중 하나입니다.

또한 가장 높은 확률인 0.85와 confidence 0.78은 같은 숫자가 아닙니다. 임계값을 정할 때 둘을 섞어 쓰지 않는 편이 좋습니다.

문서에 실린 응답은 대략 다음과 같은 모양입니다.

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.78,
      "probabilities": { "technical": 0.85, "sales": 0.0, "billing": 0.15 }
    },
    "frustration": { "type": "score", "score": 1.0, "confidence": 1.0 },
    "is_urgent": { "type": "noul", "noul": 1.0 }
  }
}

세 가지 질문 유형 Choice, Score, Noul

TypeSafe가 설명하는 질문 형태는 세 가지 중 하나입니다. 여러 질문을 한 번에 넣을 수 있지만, 앞 질문의 답이 뒤 질문의 입력으로 이어지는 방식은 아닙니다. 각각 따로 묻고, 결과를 합치는 일은 코드가 담당합니다.

• Choice: 미리 주어진 선택지 중 하나
• Score: 순서를 결정하는 값
• Noul: Yes 또는 No 여부

Choice: 닫힌 보기 중 하나

순서가 없는 선택지 중 하나를 고릅니다. 선택된 값과 해당 내용별 확률, confidence가 돌아옵니다.

예를 들어 “이 메일은 결제 문제인가, 기술 문제인가, 영업 문의인가?”가 Choice입니다. 반대로 “얼마나 심한가?”처럼 정도에 순서가 있으면 Score가 더 적절합니다.

Score: 순서를 결정하는 점수 값

낮은 쪽에서 높은 쪽으로 미리 적어 둔 항목 중 어디에 가까운지 봅니다. 점수와 항목별 확률, confidence가 돌아옵니다.

“차분하다, 짜증은 나지만 정중하다, 매우 화나 있다”처럼 감정의 정도를 나누는 일이 예입니다. 다만 환불액을 계산하거나 항목 사이의 정확한 금액을 복원하는 계산기는 아닙니다.

Noul: Yes 또는 No 여부

어떤 문장이 맞는지, 예일 확률만 냅니다. 0에 가까우면 아니오, 1에 가까우면 예에 가깝습니다. 별도의 confidence는 없습니다.

“이 메일은 환불을 요구하는가?”, “급한 말인가?”가 Noul의 예입니다. 0.5는 ‘중간 정도로 급하다’는 뜻이 아니라 예와 아니오가 비슷해 보인다는 신호입니다.

JSON으로 답하는 것과 차이

챗 모델에게 JSON으로 답하라고 요청하고, 출력이 스키마에 맞는지 검사하는 방식도 널리 사용됩니다. 이미 이 방식으로 분류하고 있다면 Jev가 있어야만 가능한 일은 아닙니다.

차이는 출력이 만들어지는 방식입니다. 챗 모델은 글자를 하나씩 생성하고, 프로그램은 그 글자를 다시 값으로 읽습니다. 중괄호가 빠지거나 보기에 없는 팀 이름이 들어갈 가능성이 있습니다.

TypeSafe는 Jev가 문장을 만들지 않고 정해진 답의 확률을 한 번에 내므로 타입 오류가 구조적으로 발생하지 않는다고 설명합니다. 다만 이것은 설계에 대한 주장이지, 모든 의미 판단이 항상 맞는다는 뜻은 아닙니다. 보기 안에서 잘못 고르는 오판은 여전히 가능합니다.

‘환각을 못 한다’는 말의 의미

Jev가 환각을 할 수 없다는 설명을 “틀린 답을 하지 않는다”로 읽으면 안 됩니다.

못 한다는 것은 보기 밖의 값을 지어내는 일입니다. technical, billing, sales만 허용했는데 support를 반환하거나 JSON 구조 자체를 깨는 일은 모델의 역할에 포함되지 않습니다.

할 수 있는 것은 보기 안에서 잘못 고르는 일입니다. 기술 문의를 결제로 보내는 것이 그 예입니다. 이것은 환각이라기보다 오판에 가깝습니다. confidence가 높아도 오판일 수 있고, 낮다고 반드시 틀린 것도 아닙니다. 낮은 값은 자동 실행을 멈추고 사람에게 넘길 신호로 읽는 편이 안전합니다.

공식 문서의 임계값 예시는 시작점일 뿐입니다. 되돌릴 수 있는 잔액 조회는 낮은 확률에서도 처리할 수 있지만, 출금 승인처럼 위험한 작업은 훨씬 높은 확신과 사람의 확인을 요구해야 합니다. 같은 숫자라도 서비스의 위험도에 따라 정책은 달라집니다.

코드가 주인인 자리

지원 메일을 처리한다고 가정하면 역할은 다음처럼 나뉩니다.

1. 티켓이 이미 닫혀 있으면 모델을 부르지 않습니다. 코드로 충분한 판단입니다.
2. 열린 티켓만 상태로 만들고, 담당 팀·환불 요청 여부·화남·긴급함을 각각 묻습니다.
3. 확률이 애매하거나 confidence가 낮으면 사람에게 넘깁니다.
4. 분명한 경우에만 코드가 큐를 바꾸고, 답장 문장이 필요할 때 별도의 챗 모델을 부릅니다.

이 구조에서는 다음 단계가 모델의 기분에 따라 늘어나지 않습니다. 단계 목록은 개발자가 미리 그렸고, 모델은 그 목록 안의 칸만 채웁니다.

Jev가 잘 못하는 일

Jev 1.13의 한계 문서가 지적하는 내용을 초보자 관점에서 정리하면 다음과 같습니다.

입력도 텍스트 중심입니다. 문자열, JSON, 텍스트 배열은 사용할 수 있지만 이미지·음성·영상은 직접 처리하지 않습니다. 화면을 보는 에이전트에 Jev를 붙이려면 먼저 화면을 텍스트로 바꾸는 프로그램이 필요합니다.

Jev를 도입할 때 주의할 점

TypeSafe가 공개한 “193.6배 빠르고 444.6배 싸다”는 숫자는 일반적인 모든 상황의 보장이 아니라 회사의 평가 결과입니다. 발표문에 적힌 조건을 함께 읽어야 합니다.

숫자만 보면 강력해 보이지만, 실제 도입 판단에서는 내 데이터와 질문으로 다시 평가해야 합니다. 특히 정확도와 confidence 임계값은 서비스의 위험도에 맞춰 검증해야 합니다.

Jev와 System One의 유래

System One은 대니얼 카너먼의 『생각에 관한 생각』에서 빠른 직관을 뜻하는 System 1과 느린 숙고를 뜻하는 System 2의 구분에서 가져온 이름입니다. 이름만으로 모델의 신뢰성이 증명되는 것은 아닙니다.

Jev는 경제학자 William Stanley Jevons에서 왔습니다. 기술이 효율적이 되면 사용량이 줄어드는 대신 오히려 더 넓은 곳에서 사용될 수 있다는 비유와 연결됩니다.

이 비유가 맞으려면 조건이 있습니다. 판단이 빠르고 싸기만 해서는 부족합니다. 틀렸을 때 코드가 멈출 수 있어야 합니다. Jev의 자리는 에이전트를 더 자유롭게 만드는 곳이 아니라, 프로그램이 물어본 것만 답하게 범위를 줄이는 곳입니다.

마무리

Jev를 한 문장으로 정리하면 이렇습니다.

Jev는 에이전트가 아니라, 에이전트나 일반 프로그램이 사용할 수 있는 판단 부품입니다.

코드가 흐름과 규칙을 갖고, Jev가 의미 판단을 맡고, 별도의 LLM이 문장을 만들고, 사람이 위험한 결정을 검토합니다. 이 역할을 분리하면 “Jev가 무엇을 할 수 있나?”보다 “어떤 판단을 코드 안에 안전하게 넣을 수 있나?”라는 더 정확한 질문을 할 수 있습니다.

참고 자료

• Introducing System One Models & Jev
• 퀵스타트
• How to build with System One
• Intent Routing
• Confidence
• Jev 1.13 한계