Jev

안녕하세요, 여러분. 니꼬입니다.

요즘 Jev라는 새로운 AI 모델을 살펴보고 있습니다. 이 모델과는 대화할 수 없습니다.

이메일을 써 달라거나, 농담을 설명해 달라거나, React 컴포넌트를 만들어 달라거나, PDF를 요약해 달라고 할 수 없습니다. Jev는 텍스트를 생성하지 않거든요.

대부분의 기능이 빠진 AI 모델처럼 들릴 수 있습니다. 대화와 AI는 너무 밀접하게 연결돼 있어서, 답을 돌려주지 않는 모델로 뭘 할 수 있을지 상상하기 어렵죠. 그런데 저는 바로 그 대화의 부재가 Jev를 흥미롭게 만든다고 생각합니다.

TypeSafe AI는 Jev를 최초의 "System One" 모델이라고 부릅니다. 소프트웨어가 곧바로 쓸 수 있도록 빠르고 구조화된 결정을 내리게 설계된 모델이죠.

LLM은 텍스트 기계입니다

LLM은 다음 토큰을 예측하도록 만들어집니다. 텍스트를 받아 다음에 올 내용을 예측하고, 그 토큰을 시퀀스에 더한 뒤, 응답이 끝날 때까지 같은 일을 반복하죠.

그 응답은 에세이일 수도, 코드일 수도, JSON 객체일 수도 있습니다. 하지만, 모델에게는 모두 텍스트일 뿐입니다.

요즘 LLM API도 구조화된 출력을 지원합니다. 모델에 JSON 스키마를 주거나, 도구를 정의하거나, 특정 응답 형식을 요구할 수 있죠. 이제는 꽤 신뢰할 만해졌고요.

그래도 구조화된 출력은 텍스트 생성 모델에 덧붙인 부가 기능입니다.

모델은 시퀀스를 생성하고, API는 완성된 응답이 스키마와 일치하도록 선택 가능한 토큰을 제한합니다. 그 제한을 풀면 마크다운 코드 펜스를 붙이거나, 필드를 지어내거나, "물론입니다!"로 시작할 수도 있죠.

그러니까 텍스트를 만들도록 설계된 거대한 범용 모델에서 생성할 수 있는 텍스트 대부분을 막고, 남은 것을 읽은 뒤, 검증하여 코드에 넘기는 셈입니다.

구조화된 출력은 작동합니다. 하지만 여전히 텍스트가 필요 없는 일에 텍스트 기계를 억지로 맞추고 있는 거죠.

Jev는 타입에서 시작합니다

Jev에서 구조화된 출력은 끄고 켜는 옵션이 아닙니다. 모델이 낼 수 있는 유일한 출력이죠.

텍스트나 구조화된 애플리케이션 데이터로 된 상태와, 타입이 정해진 질문 묶음을 Jev에 보냅니다. 그러면 Jev는 타입이 정해진 답과 확률을 돌려줍니다.

질문은 세 가지입니다.

• Choice는 목록에서 하나의 선택지를 고릅니다.
• Score는 어떤 대상을 척도 위에 놓습니다.
• Noul은 명제가 참일 확률을 반환합니다.

고객이 이렇게 보냈다고 해 봅시다.

같은 주문 건으로 두 번 청구됐는데, 오늘 이 문제를 해결해야 해요.

애플리케이션은 Jev에게 어느 팀이 이 티켓을 맡아야 하는지, 얼마나 긴급한지, 고객에게 두 번 이상 청구됐는지를 물을 수 있습니다.

Jev는 담당 부서, 긴급도 점수, 그리고 나머지 질문에 대한 확률을 반환할 것입니다. TypeSafe의 Python SDK를 사용하면 호출은 이렇게 생겼습니다.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

response = TypeSafeClient().system_one(
    state="I was charged twice for the same order and I need this fixed today.",
    questions={
        "department": Choice(
            instructions="Which team should handle this?",
            criteria={
                "billing": "Payment and charge issues",
                "support": "Product help and troubleshooting",
            },
        ),
        "urgency": Score(
            instructions="How urgent is this request?",
            criteria=["Can wait", "Needs attention soon", "Needs attention now"],
        ),
        "duplicate_charge": Noul(
            instructions="The customer was charged more than once.",
        ),
    },
)

answers = response.answers

if answers["department"].confidence < 0.5:
    request_human_review()
elif answers["department"].choice == "billing":
    route_to_billing()

한 번 요청하면 세 가지 답변을 모두 함께 반환합니다. Jev는 동일한 상태에 대해 각 질문을 병렬로, 독립적으로 평가하죠.

해석해야 할 문장은 없습니다. Jev가 모호한 판단을 처리하고, 프로그램이 실행을 담당합니다.

TypeSafe는 Jev를 "프런티어 지능 함수 호출"이라고 부릅니다. 저는 이 표현이 마음에 듭니다. Jev는 언어 모델처럼 지저분한 입력을 이해할 수 있지만, 작동 방식은 함수에 더 가까워서 여러분의 소프트웨어가 처리할 수 있는 결과를 반환합니다.

대화는 없습니다

왜 청구 담당 팀을 골랐는지 물을 수 없습니다. "확실해?"라고 되물을 수도 없죠. 고객의 메시지를 다시 쓰거나 답장을 작성해 달라고 요청할 수도 없습니다. 설명이나 코드, 그 밖의 어떤 자유 형식 문자열도 만들어낼 수 없습니다.

사람을 직접 돕는 용도라면 이는 엄청난 제약입니다. 하지만 대부분의 소프트웨어는 결정을 내릴 때마다 대화가 필요하지는 않습니다.

사기 탐지 시스템에는 위험 점수가 필요하고, 지원 시스템은 티켓을 담당 부서로 보내야 합니다. 모더레이션에는 분류가 필요하죠. 관측성 시스템은 알림을 닫아도 되는지, 아니면 누군가를 깨워야 하는지 알아야 합니다.

지금까지는 사용할 수 있는 지능형 모델이 대화 모델뿐이었기에 이런 시스템에 대화 모델을 넣어왔습니다. TypeSafe는 처음부터 이러한 종류의 자동화를 위해 Jev를 설계했습니다.

병렬로 작동하는 지능

LLM은 토큰을 순차적으로 생성합니다. 모든 토큰이 앞선 토큰에 의존하므로 답이 길어질수록 더 오래 걸립니다.

Jev에는 작성할 답변이 없습니다. TypeSafe에 따르면 요청 내의 모든 질문을 병렬로 평가하므로, 독립적인 분류를 추가해도 응답 시간이 거의 변하지 않습니다.

고객 지원 티켓을 살펴보고 모든 것을 결정하라는 거대한 프롬프트 하나를 던지는 대신, 정책을 작은 질문으로 나눌 수 있습니다. 어느 부서가 맡아야 하는가? 얼마나 긴급한가? 조치를 취할 만한 증거가 충분한가?

일반 코드는 그 답변들을 조합합니다. 에이전트에게 전체 일을 맡기는 것보다는 덜 마법 같지만, 저는 그게 장점이라고 생각합니다.

비즈니스 규칙은 코드에 남아 있어서 읽고 테스트할 수 있습니다. 모델은 if 문으로 표현하기 어려운, 모호한 판단을 처리합니다.

TypeSafe는 Jev가 설계된 작업에서 프런티어 모델보다 40배에서 200배 빠르고, 응답 시간은 대략 70~500밀리초라고 주장합니다. 이는 초기 제품에 대한 TypeSafe 자체 벤치마크이므로, 이 수치를 확정된 것으로 보기는 아직 이르죠. 하지만 속도 차이는 타당해 보입니다. Jev는 더 좁은 범위의 문제를 해결하며, 아무도 필요로 하지 않는 응답을 생성하는 데 시간을 쓰지 않으니까요.

불확실성도 출력입니다

LLM에게 얼마나 확신하는지 물을 수는 있지만, 그 답 역시 생성된 텍스트일 뿐입니다. 모델은 확신에 찬 것처럼 말하면서도 틀릴 수 있습니다.

Jev는 보정된 확률을 반환하도록 훈련됐습니다. 비슷한 결정들에 80%의 확률을 부여한다면, 그 결정의 정확도가 약 80%를 넘어서도록 하는 것이 목표입니다.

개별 답변은 여전히 틀릴 수 있습니다. 보정(calibration)은 주변 소프트웨어가 불확실성에 대응할 수 있는 방법을 제공합니다. 신뢰도가 높은 결정은 자동으로 처리하고, 신뢰도가 낮아지면 확인을 요청하거나, 사람 또는 더 느리지만 정교한 추론 모델에 넘길 수 있습니다.

TypeSafe는 Jev가 "환각을 일으킬 수 없다"고 주장합니다. 이 표현은 조금 조심해서 볼 필요가 있어요.

Jev는 스키마에 없는 필드를 지어내거나, 분류 질문에 시를 지어 답할 수 없습니다. 임의의 문자열은 불가능하니 그런 종류의 실패는 사라지죠.

하지만 여전히 틀릴 수 있습니다. 선택지가 billing, sales, support일 때, 정답이 billing인데도 Jev가 확신을 갖고 sales를 고를 수 있죠.

출력의 유효성은 보장되지만, 결정의 정확성이 보장되는 것은 아닙니다. 둘을 혼동하지 않는 한 첫 번째 보장만으로도 충분히 유용합니다.

사람이 아니라 소프트웨어를 위한 모델

Jev는 LLM을 대체하는 도구가 아닙니다. 리서치, 글쓰기, 코드, 설명, 대화가 필요하다면 여전히 언어 모델이 필요합니다. 신중한 다단계 추론에도 Jev는 아마 적합하지 않은 도구일 것입니다. TypeSafe는 지식이 있는 사람이라면 빠르게 내릴 수 있는, 초점이 분명한 판단에 사용할 것을 권장합니다.

이는 왜 모든 지능형 기능이 대화 모델로 시작하는지에 대해 다시 생각해 보게 합니다.

어려운 경우에는 LLM이 추론하고 응답을 작성하되, 분류·점수 매기기·라우팅·언제 값비싼 모델을 실행할지 결정하는 등의 작업은 빠른 결정 모델이 처리하는 시스템을 상상해볼 수 있습니다.

우리가 일반 소프트웨어를 만드는 방식도 이미 그렇습니다. 모든 일에 하나의 함수를 쓰지 않죠. 입출력이 명확한 작은 도구를 만들고 연결합니다.

Jev는 아직 초기 단계이며, 가장 인상적인 평가는 TypeSafe 자체에서 나온 것이고, 실제 운영 환경에서 얼마나 잘 버텨낼지는 아직 알 수 없습니다. 그래도 저는 이 아이디어가 꽤 설득력 있다고 느낍니다.

지난 몇 년간 우리는 사람처럼 말하는 모델에 맞춰 소프트웨어를 바꿔왔습니다. Jev는 처음부터 소프트웨어에 말하도록 만들어졌습니다.

다음 주에 뵙겠습니다!

— 니꼬