TypeSafe Jev 시리즈 1/10 — 텍스트 생성 대신 구조화된 판단을 쓰는 이유 | DAKER 커뮤니티
TypeSafe의 Jev를 이해하려면, 먼저 LLM이 잘하는 일과 코드가 실제로 필요로 하는 결과가 어떻게 다른지부터 짚어볼 필요가 있습니다. 이 차이를 이해하면 왜 Jev가 텍스트 생성 모델과 다른 방식으로 설계됐는지도 자연스럽게 보입니다.
이번 글은 TypeSafe 문서의 도입부를 바탕으로, Jev가 어떤 문제를 겨냥하는지 간단히 정리한 시리즈 1/10입니다.
LLM이 만드는 것과 코드가 필요한 것의 차이
문서에 따르면 LLM은 기본적으로 사람이 읽을 텍스트를 만들도록 설계된 시스템입니다. 그래서 코드가 바로 소비할 판단 결과를 얻으려면, 먼저 텍스트 생성 시스템에 구조화된 출력을 억지로 맞춘 뒤 다시 파싱하는 단계를 거치게 됩니다.
이 과정에서는 파싱 실패, 형식 불일치, 분기 불안정 같은 문제가 자주 생깁니다. 사람이 읽기에는 자연스러운 답변이어도, 프로그램이 안정적으로 처리하기에는 불편한 경우가 많기 때문입니다.
코드가 바로 써야 하는 판단을 텍스트로 생성한 뒤 다시 파싱하는 구조에서는 실패 지점이 늘어납니다.
Jev는 무엇을 다르게 만들었나
Jev는 TypeSafe의 플래그십 모델이자 첫 System One 모델입니다. 문서에서는 System One 모델을 소프트웨어가 바로 사용할 수 있는 빠르고 구조화된 결정을 만들기 위해 설계된 모델로 설명합니다.
상태(state)와 타입이 있는 질문을 보내면, Jev는 텍스트를 생성하고 다시 파싱하는 과정을 거치지 않고 타입 있는 값과 확률 분포를 반환합니다. 즉, 사람이 읽기 좋은 문장을 만드는 대신 코드가 바로 분기와 계산에 활용할 수 있는 형태로 답을 돌려주는 방식입니다.
Jev는 텍스트 생성이 아니라 소프트웨어가 바로 쓸 수 있는 구조화된 결정을 목표로 합니다.
모델의 답보다 중요한 다음 단계
한 요청 안에 상태와 질문을 넣으면, 모델은 각 질문을 그 상태에 대해 병렬로 평가합니다. 그리고 타입 있는 답, 확률, 그리고 Choice와 Score의 경우 confidence를 반환합니다.
여기서 중요한 점은 그다음 단계가 문서가 강조하듯 여러분의 코드라는 점입니다. 실제 서비스 로직은 모델이 대신하지 않습니다. 반환된 값을 바탕으로 분기하고, 정렬하고, 라우팅하는 일은 애플리케이션 코드가 맡습니다.
답을 받은 뒤 분기와 정렬, 라우팅을 수행하는 주체는 모델이 아니라 코드입니다.
Jev의 세 가지 프리미티브
문서에서 소개하는 기본 단위는 세 가지입니다. 각각은 서로 다른 종류의 판단을 구조화된 형태로 반환합니다.
Choice — 목록에서 옵션을 고릅니다. 반환값은
choice,probabilities,confidence입니다.Score — 루브릭으로 상태를 점수화합니다. 반환값은
score,probabilities,confidence입니다.Noul — 문장이 참인지 묻습니다. 반환값은
noul(0–1)입니다.
이 세 유형은 한 API 호출 안에 함께 섞어 넣을 수 있고, 같은 상태에 대해 병렬적이고 독립적으로 평가됩니다. 문서 설명에 따르면 질문 수를 늘려도 응답 시간은 거의 늘지 않으며, 질문끼리 서로의 컨텍스트를 오염시키지 않습니다.
질문은 작게 나누고, 조합은 코드에서
문서의 방향은 분명합니다. 각 질문은 한 가지를 잘 묻도록 좁히는 편이 좋습니다. 여러 독립 요인을 한 질문에 한꺼번에 넣기보다, 요인별로 나눠 묻고 코드에서 가중치를 합치는 방식이 더 적합합니다.
예를 들어 문서의 설명처럼 스타트업 피치를 한 번에 평가하라고 하기보다, 시장 규모, 기술 실현성, 차별화를 각각 따로 묻는 편이 낫습니다. 이후 우선순위가 바뀌면 프롬프트를 다시 손보기보다 코드의 계수를 조정하면 됩니다.
질문은 원자적으로 나누고, 최종 조합 로직은 코드에 두는 것이 Jev의 설계와 잘 맞습니다.
이번 글에서 기억할 점
TypeSafe 문서의 도입부는 Jev를 단순히 또 하나의 모델로 소개하지 않습니다. 오히려 텍스트 생성 중심의 흐름에서 벗어나, 코드가 직접 사용할 수 있는 판단 단위를 어떻게 만들 것인지에 초점을 맞춥니다.
그래서 Jev를 이해하는 가장 좋은 출발점은 모델 성능 비교보다도, 지금 사용 중인 텍스트 생성 → 파싱 구조가 어디에서 불안정한지 돌아보는 일일 수 있습니다.
참고 자료
인덱스: https://docs.typesafe.ai/llms.txt
시리즈 1/10 · 다음: 2/10 텍스트가 아니라 교정된 확률
지금 다루는 판단 로직 가운데 텍스트 생성 대신 Choice, Score, Noul로 바꿔볼 만한 지점이 있는지 떠오르는 사례가 있으신가요?