Jev의 System One Model ~ Giljae Joo (주길재)

System One Model은 상황을 분석하여 텍스트가 아닌 결정을 내리는 AI 모델이다.
온라인 쇼핑몰을 운영한다고 가정해보자. 고객이 카드 결제가 두 번 되었다고 고객 센터에 문의를 했다. 고객이 문의한 내용을 내부의 어떤 팀에서 처리해야 하는지 알고 싶다고 할때 사용될 수 있다. 어떤 팀에서 처리하는지만 결정을 내린다. 고객에게 답장을 보내지도 않고, 생각을 설명하지 않는다. 그냥 결정을 내릴 뿐이다.

System One Model = System One + Model

'System One'은 인간 두뇌의 사고방식에 대한 개념에서 유래되었다. 'Model'은 AI 모델을 의미한다. 즉, 'System One Model'은 우리 두뇌 시스템처럼 사고하는 AI 모델이다.

Jev를 살펴보기 전에, System One 사고 방식과 System Two 사고 방식에 대해서 알아야 한다.

System One 사고 방식 vs System Two 사고 방식

노벨 심리학상을 수상한 대니얼 카네만은 우리 뇌에는 두 가지 사고 방식이 있다고 설명했다.

System One은 빠르고, 자동적이며, 유연하다고 한다. "1+1은?"이라고 질문하면 생각 없이 "2"라고 대답한다. 지인의 얼굴을 보면 바로 알아볼 수 있다. 계산할 필요가 없다. 머리속에 답이 그냥 떠오른다.

System Two는 느리고 신중하며 생각(계산)을 한다. "21x12는?" 라고 질문하면, 바로 답을 하지 못하고 단계별로 계산을 하게 된다. 이런 과정에서는 시간과 에너지가 소모된다.

System One은 매일 수천 건의 작은 결정들을 처리하고, System Two는 어려운 결정을 처리한다.

LLM(Large Language Model)은 ChatGPT와 같은 챗봇의 기반이 되는 AI 모델이다. LLM은 한 번에 작은 텍스트 조각들을 생성하도록 설계되었다. 간단한 Yes/No 질문을 하더라도 느린 텍스트 생성 과정을 거치게 된다.

실제 소프트웨어 개발 과정에서 이루어지는 대부분의 결정은 사소하고 반복적이다.

'내가 받은 이메일이 스팸인가? 아닌가?'
'이 일은 어느팀이 처리해야 하지?'
'이 사용자 리뷰는 긍정적인가? 부정적인가?'

위의 질문들은 System One 유형의 결정이 필요하다. 즉각적인 답을 필요로 하며, 하루에도 여러번 이런 질문에 답을 해야 한다.

지금 상황은 참 아이러니한 상황이다. System One의 빠른 의사결정을 System Two 방식의 모델(LLM)을 사용하고 있기 때문이다.
이것이 System One 모델이 해결하고자 하는 문제이다.

LLM을 의사 결정에 사용하게되면 생기는 문제점

고객 문의를 처리하는 티겟 시스템이 있고, 모든 접수 티켓을 담당팀으로 보내고 싶다고 가정해봅시다. 대부분 기업은 아래처럼 이를 수행한다.

prompt = "두 번 결제가 발생했습니다."
response = llm.generate(prompt)
category = response.text.strip()

위 예시 코드는 LLM에게 티켓 내용을 읽고 카테고리 이름을 회신해달라는 요청이다.

문제 1: 답을 토큰 하나씩 순차적으로 입력한다.

토큰은 작은 텍스트 조각이다. LLM은 토큰 하나씩 순차적으로 답을 작성하고 단어 하나로 된 답을 작성하는데에 여러 단계가 필요하다. 모델이 설명을 추가하면 더 많은 단계 및 토큰이 필요하게 된다.

문제 2: 출력 형식을 신뢰할 수 없다.

위 코드에서는 카테고리 이름만 요청했다. 그러나 모델은 "카테고리는 청구입니다. 다른 필요 사항이 있으면 알려주세요."라고 답변을 하면서 "환불"과 같은 단어도 답변에 포함시킬 수 있다. LLM에게 받은 답변을 정리하기 위한 추가 코드 작성이 필요하다. 정리 과정에서 실수를 저지르기 쉽고, 예상치 못한 방식의 오류가 발생할 수 있다.

문제 3: 확실한 정보인지 알 수 없다.

모델이 "청구"라고 답변을 했지만, 99% 확신하는 것인지, 혹은 51% 확신하는 것인지 알 수 없다. 따라서 모델을 신뢰하고 담당팀에게 문의해야 할지 결정하기가 어렵다.

문제 4: 속도가 느리고 비용이 많이 든다.

프론티어 LLM와 같이 현재 가장 성능이 뛰어난 모델을 사용하면 결과를 받는데까지 몇 초 걸리지 않는다. 그러나 하루에 50만건 이상의 티켓이 발생한다면 대기 시간과 비용이 순식간에 늘어나게 된다.

이 문제를 해결하기 위해 Jev가 나온다.

Jev?

앞서 포스팅에서 설명 했지만, 다시 한번 설명을 한다.

Jev는 TypeSafe AI라는 회사가 개발한 System One 모델이다. Jev의 놀라운 점은 텍스트를 생성하지 않는다는 점이다.
우리는 Jev와 채팅을 할 수 없다. 이메일을 쓰거나 코드를 작성하라고 요청할 수도 없다. Jev는 상황을 입력받아 확률과 함께 지정된 선택지를 출력할 뿐이다.

Jev의 동작 원리

Jev는 두 가지를 입력 받는다.

상태(State): 상황에 대한 정보다. 상태는 모델이 현재 상황에 대해 알아야 할 모든 것을 나타내는 단어다. 텍스트 형식이며, 일반 문자열, 텍스트 목록 또는 JSON 객체일 수 있다. 예를 들어서 고객의 메시지, 거래 내역, 환불 정책 등이 있다.
답변이 허용되는 질문: 결정하고자 하는 것과 유효한 답변을 알려줘야 한다. 예를 들어 "어느 담당팀을 선택하겠습니까?" 라는 질문에 대한 답변은 "결제", "청구" 등이 있다.

특이한 점은 아래와 같다.

답변은 직접 입력해야 한다.
각 답변에 대해 모델의 확신도를 나타내는 0에서 1사이의 확률도 포함된다.

코드로 살펴보자. 아래 코드는 간단한 개념 코드이며 실 코드는 아니다.

result = dev.decide(
state={
"message": "두 번 결제되었어요.",
"recent_transactions": ["9월 10일 5만원", "9월10일 5만원"]
},
questions={
"team": ["결제", "청구"],
"is_urgent": "yes_no",
"frustration": {"min":0, "max":2}
}
)

결과는 다음과 같다.

{
"team": {"answer":"결제", "probability":0.97},
"is_urgent": {"answer":true, "probability":0.88},
"frustration": {"answer":1, "probability":0.74}
}

몇 가지 사항을 확인할 수 있다.

한 번 요청에서 세 가지 질문을 했고, 세 개의 답변을 받았다.
답변은 허용된 답변 중 하나이다. team에 대한 가능 답변은 결제, 청구 뿐이다. 다른 문장이나 단어는 올 수 없다.
모든 답변에는 확률이 포함된다.

이제 가장 중요한 부분은 병렬 처리다. Jev는 모든 질문에 대해 단 한 번 병렬적으로 답변한다. 병렬 처리는 모든 작업을 동시에 수행하는 것을 의미한다.

LLM은 마치 펜으로 에세이를 쓰는 사람과 비슷하다. 각 단어는 이전 단어 뒤에 온다. 7번째 단어를 쓰기전에는 8번째 단어를 쓸 수 없다.

Jev는 체크 박스가 있는 양식을 작성하는 사람과 비슷하다. 전체 상태를 한 번에 읽고 모든 항목에 대해 동시 체크를 한다. 다음 단어를 기다릴 필요가 없다. 이 점이 바로 System One의 장점이다.

위의 매커니즘으로 동작되기에 Jev는 빠르다. 일반적인 LLM이 3초에서 몇 분 걸리는 결정을 Jev는 1초도 안되는 시간에 처리한다.

이 방법은 즉시 결정을 내리고, 유효한 답을 반환하며, 정확도도 알려주고, 비용도 매우 저렴하다. LLM 접근 방식에서 발견한 4개의 문제점을 해결한 것이다.

입력 답변: 선택, 점수, Yes/No

프로그래밍을 할때 타입은 어떤 값이 어떤 종류의 값을 가질 수 있는지를 알려준다. Boolean 타입의 변수는 true or false만 가질 수 있다. 다른 값은 가질 수 없다. 이것을 타입 안정성이라고 부른다. 프로그램은 잘못된 종류의 값을 표현할 수 없다. 그래서 회사 이름이 TypeSafe인듯 하다.

Jev는 AI 답변에도 동일한 아이디어를 적용한다. 우리가 하는 모든 질문에는 유형이 있고, 답변은 해당 유형에 맞아야 한다. Jev는 세 가지 유형의 답변을 지원한다. 이 부분은 앞서 포스팅했으니, 여기서는 생략하겠다.

교정 및 RLCD

우리는 Jev가 모든 답변에 확률을 함께 제시한다는 것을 알고 있다. 그 확률을 신뢰할 수 있을까?

바로 이 부분에서 보정 작업이 중요해진다.

모델은 확률이 현실과 일치할 때 보정된다. 쉽게 말해서 모델이 90% 확신한다라고 말한 답변을 고려했을 때, 90%가 실제도 맞다는 의미다.

날씨 앱이 100일 동안 "비 올 확률 70%"라고 예보했다고 가정하자. 만약 70일 동안 비가 왔다면 앱은 제대로 보정된 것이다. 그러나 30일 동안만 비가 왔다면 앱은 제대로 보정되지 않은 것이고, 70%라는 예보는 아무 의미가 없게 된다.

대부분의 LLM은 이런 훈련을 받지 않았다. LLM은 사람들이 좋아할 만한 글을 쓰도록 훈련받았다. 따라서 LLM이 "나는 자신 있다"고 말할 때는 자신감 있게 들리는 단어를 쓴 것이라 판단하면 된다.

Jev는 TypeSafe에서 RLCD라고 부르는 방법을 사용하여 다른 방식으로 학습된다.

RLCD = 보정된 결정을 위한 강화 학습

강화 학습은 모델이 결정을 내리고, 그 결정이 맞으면 보상을 받고, 틀리면 벌점을 받는 훈련 방식이다. 여러 번의 시도를 통해 모델은 더 나은 결정을 내리는 방법을 학습한다.

"보정된 결정(Calibrated Decisions)"이란 단순히 정답을 맞추는 것만으로 보상받는 것이 아니다. 정답을 맞추는 동시에 그 확신의 정도를 솔직하게 밝히는 것에 대한 보상이다.

모델 예측대로라면 99% 확률로 큰 보상을 받을 수 있다.
모델 예측이 99%인데 틀렸다. 큰 불이익을 받을 것 같다.
모델은 55%라고 예측했고, 그 예측이 맞았다. 보상은 적다.
모델에서는 55%라고 하는데 틀렸다. 벌금이 약간 더 클 뿐이다.

모델이 좋은 점수를 받으려면 실제로 맞을 가능성이 높을 때는 높은 확률을, 그렇지 않을 때는 낮은 확률을 제시해야 한다. 그래야 확률이 정직해진다. 이런 정확한 확률은 우리에게 매우 유용하다.

if result["team"]["probability"] > 0.9: route_to(result["team"]["answer"]) else: send_to_human()`

Jev의 의견이 확실할 때는 믿고, 확실하지 않을 때는 담당자에게 문의하도록 전달한다. 일반적인 LLM으로는 이런 코드를 작성할 수 없었다. 그 이유는 정확한 수치를 제공하지 않았기 때문이다. 이 시스템 덕분에 작업이 훨씬 수월해졌다.

참고로 보정은 모든 답이 정확하다는 것을 의미하지 않는다. 90%의 정확도를 보이더라도 10%는 틀릴 수 있다. 보정은 단지 수치가 정확하다는 것을 의미하며, 이를 통해 어느 정도까지 신뢰할 수 있는지 알 수 있다.

Jev가 환각을 경험하지 못하는 이유는 무엇일까?

LLM 모델이 환각을 일으키는 것은 알고 있을 것이다. 환각이란 모델이 사실이 아니거나 존재하지 않는 것을 확신에 차서 말하는 것을 의미한다. 존재하지 않는 책을 만들어내거나, 목록에 없는 범주를 만들어낼 수도 있다.

TypeSafe는 Jev가 환각을 경험할 수 없다고 주장한다. 이 주장을 이해해보자.

모델에게 어떤 결정을 내리도록 요청할 때 모델이 실수할 수 있는 오류에는 두 가지 유형이 있다.

타입 오류: 답변이 유효한 답변 유형이 아닌 경우다. "결제", "청구"를 요청했는데 "환불" 을 답하는 경우다.
잘못된 답변: 답변은 유효하지만, 틀린 답변이다. 해당 티켓은 로그인 문제에 관한 것이다.

Jev는 절대 타입 오류를 범할 수 없다. 이것은 수학적으로 보장된 사실이지, 약속이 아니다. 모델은 허용된 옵션만 평가하기 때문에 답은 항상 허용된 옵션 중 하나이다. 모델 내부에는 그 외의 다른 결과를 생성할 수 있는 경로가 없다. TypeSafe는 단 하나의 반례만으로도 이 주장이 틀렸음을 증명할 수 있다고 말한다.

그러나 Jev는 잘못된 답을 줄 수 있다. 하지만 확신이 없을 때는 보정 덕분에 오답 확률이 낮아진다. 따라서 확률을 살펴보면 대부분의 오답을 잡아낼 수 있고, 그런 경우는 사람이 검토하도록 넘길 수 있다.

즉, "환각을 일으킬 수 없다." 라는 말의 의미는 존재하지 않는 답을 절대 만들어낼 수 없으며, 확신이 서지 않을때는 확률로 우리에게 알려준다. 라고 해석할 수 있다.

일반적으로 우리는 System One은 빠르지만 오류 발생 가능성이 높고, System Two는 느리지만 신뢰할 수 있다고 생각했다. 그러나 TypeSafe는 이 고정관념을 깨드린것이다.

의사결정 작업에서 System One 모델은 설계상 허용된 옵션으로 답변이 제한되고, 학습을 통해 신뢰도가 높아지기 때문에 느린 대안보다 더 신뢰할 수 있게 만들 수 있다.

Jev vs LLM

Jev와 LLM의 차이를 표로 정리해보자.

측면	Jev	LLM
어떻게 답변하는가?	모든 답변을 한 번에 병렬로 처리	한 번에 토큰 하나씩
텍스트, 코드, 답글을 작성할 수 있다.	No	Yes
단계별로 추론할 수 있다.	No	Yes
출력 형식을 보장한다.	Yes	지시어를 지정하면 가능하지만, 상황에 따라 달라질 수 있음
신뢰	모든 답변에 대한 보정된 확률	환각이 발생할 수 있음
속도	70~500ms	초~분
비용	입력 토큰 1M당 0.042달러, 출력 수수료 없음	훨씬 더 비싸고, 출력 토큰은 추가 비용이 발생
입력	텍스트, JSON	텍스트, 이미지, 오디오 등
적합한 곳	분류, 경로 설정, 점수 매기기, 확인, 결정	채팅, 글쓰기, 코딩, 추론, 설명

Jev가 잘 작동하는 부분과 그렇지 못한 부분

효과가 좋은 경우는 아래와 같다.

라우팅: 어떤 팀, 어떤 모델, 어떤 워크플로우가 이를 처리해야 할까?
분류: 스팸인지 아닌지, 긍정인지 부정인지, 어떤 범주에 속하는지?
평가: 이 문서의 우수성을 1점에서 5점까지 평가해달라
가드레일: Jev는 사용자가 결과를 보기전에 짧은 시간내에 LLM의 답변을 확인 할 수 있음
실시간 결정: 사용자가 직접 사용하는 앱 내에서 몇 초라도 기다릴 수 없는 모든 상황
대규모 데이터 세트: 수백만 개의 행에 대해 동일한 의사결정을 실행해야 하는 경우에 비용과 속도가 중요함

효과가 좋지 않은 경우는 아래와 같다.

글쓰기: Jev는 이메일 요약, 코드 작성 등 텍스트 출력이 없다.
추론: 수학 문제를 푸는 것처럼 여러 단계의 사고가 필요한 작업이라면 Jev는 적합하지 않다.
설명: Jev는 답과 확률만 제시할 뿐, 그 이유는 설명하지 않는다.
이미지 및 오디오: Jev는 텍스트만 허용한다.

어떤 상황에서 사용해야 할까?

가장 간단한 규칙은 다음과 같다.

답변이 결정된 상황이면 Jev를 사용하고, 답변이 문장(텍스트)인 경우는 LLM을 사용하면 된다.

일반적인 시스템에서는 이 두 가지를 함께 사용하게 된다. 예를 들어 고객에게 자동으로 응답하는 고객 지원 시스템을 만든다고 하면,

Jev는 티켓을 읽고 담당팀, 긴급도 그리고 자동 응답 가능 여부를 결정한다. 이 과정은 순식간에 끝난다.
이 후, Jev의 결과가 안전하다고 확신하면 LLM이 답장을 작성한다.
답장에 대해 Jev는 안전한 내용인지, 매너있게 작성되었는지 판단 후 전송한다.

위에서 LLM은 System Two에 대한 작업(글쓰기와 추론)을 담당하고, Jev는 System One 작업(빠르고, 여러 번 결정을 내리는 작업)을 담당한다. 즉, 각자 자신이 잘하는 일을 하는 것이다.

한 단계에서 경로를 결정하고 다른 단계에서 작업을 수행하는 이런 흐름은 흔히 볼 수 있는 패턴이다.

우리는 Jev의 System One 모델에 대해서 알게되었다. 오늘 이해한 내용을 토대로 현실에 적용하면 된다.

Source:

Giljae Joo (주길재)

9/22/2026

Jev의 System One Model