Jev는 답을 쓰지 않고 고른다, 강화학습으로 본 사용법

TypeSafe AI의 모델 Jev(제브)가 9월 15일 공개된 지 2주 가까이 지났지만, 어디에 어떻게 쓰느냐는 질문은 여전히 많습니다. Jev는 글을 쓰지 않습니다. 사람이 미리 정해 둔 보기에 확률을 나눠 배정할 뿐입니다. 강화학습(Reinforcement Learning)에서 말하는 '정책'과 같은 구조이고, 이렇게 이해하면 활용법도 따라 나옵니다. AIGeek은 같은 방식을 공개 모델 세 개로 직접 실험했습니다. 답의 형식은 큰 모델이라면 이미 지켰습니다. 하지만 확률은 믿기 어려웠습니다. Jev가 훈련 방식의 이름에 '보정(calibration)'을 넣은 이유가 여기에 있습니다.

Jev의 입출력은 강화학습의 '정책'과 같은 구조다

강화학습에서는 에이전트가 보는 정보 전체를 상태(State), 고를 수 있는 선택지를 행동(Action)이라고 부릅니다. 훈련된 에이전트는 상태마다 각 행동에 확률을 부여하고, 좋은 결과를 낸 행동의 확률을 높여 갑니다. 이 대응 관계가 정책(policy)입니다. 수식으로는 π(A|S)라고 표기합니다. π(파이)는 정책을 가리키는 기호이고, 전체는 '상태가 S일 때 행동 A를 고를 확률'이라는 뜻입니다.

Jev의 입출력이 바로 이 구조입니다. TypeSafe의 공식 발표문↗에 따르면 Jev는 문장을 생성하지 않습니다. 가능한 답과 구조를 미리 정해 두면 그 가운데서 결정을 고르고, 모든 답에 확률과 확신도를 붙여 한 번에 내놓습니다. 훈련 방식의 이름은 RLCD, '보정된 결정을 위한 강화학습'입니다. 공식 문서↗는 보정을 이렇게 설명합니다. 0.8이라고 답한 예측들을 모아 보면 실제로 80% 안팎이 맞아야 한다는 것입니다. 답 하나하나를 보장한다는 뜻은 아닙니다.

문서는 ChatGPT를 만든 RLHF(사람 피드백 기반 강화학습, Reinforcement Learning from Human Feedback)와 이 방식을 대비합니다. RLHF는 사람이 더 선호하는 답을 내도록 훈련하는 방법이라 아첨(sycophancy)이나 그럴듯한 환각(hallucination)까지 보상할 수 있다는 것입니다. 창업자 디오고 알메이다(Diogo Almeida)는 RLHF로 ChatGPT의 토대를 만든 인스트럭트GPT(InstructGPT) 논문↗의 네 번째 저자입니다. 사람이 읽기 좋은 답을 만드는 훈련법에 참여했던 연구자가, 이번에는 소프트웨어가 읽을 답을 만드는 방향으로 전환한 셈입니다.

작은 모델은 글로 답하게 하면 지시한 형식부터 벗어났다

'쓰게 하는 것'과 '고르게 하는 것'이 실제로 얼마나 다른지 확인하기 위해 AIGeek이 직접 코드를 작성해 실험했습니다. Jev는 초기 접근 단계라 이번 실험 대상은 Jev가 아니라 공개 모델 세 개입니다. 일반 PC의 CPU(인텔 i7-11700)에서 실행한 5억 파라미터짜리 Qwen2.5-0.5B, 그리고 필자의 LLM 서버에서 운영하는 Gemma 4 26B와 Qwen3.8-27B입니다.

고객 문의는 여섯 건을 만들었습니다. 배송 일정 문의, 카드 이중 결제, 앱 로그인 오류, 2주째 환불이 안 돼 소비자원 신고를 예고한 항의, 결제 버튼 먹통, 재구매 문의입니다. 문의마다 세 가지를 물었습니다. 담당 팀(결제·기술·배송·영업), 당일 처리가 필요할 만큼 긴급한지(예·아니오), 고객의 감정(차분함·답답하지만 정중함·매우 분노)입니다. 모범 답은 실험 전에 정해 두었고, 채점은 각 모델의 원래 출력을 직접 확인해 했습니다.

먼저 기존 방식대로, 보기 중 하나를 그대로 쓰라고 지시하고 JSON으로 답하게 했습니다. 작은 모델은 JSON 자체는 여섯 건 모두 읽을 수 있게 냈지만, 지시대로 보기 안에서만 답한 것은 한 건뿐이었습니다. 담당 팀을 하나 고르라 했는데 다섯 건을 목록으로 답했고, 그중 네 건에는 팀을 둘씩 적었습니다. 예·아니오로 물은 긴급도에는 네 건이 false라고 답했습니다. 감정은 여섯 건 모두 '차분함'이었습니다. 소비자원 신고를 예고한 항의까지 차분하다고 판단한 것입니다.

같은 지시를 받은 두 큰 모델은 달랐습니다. Gemma 4 26B와 Qwen3.8-27B 모두 여섯 건 전부 보기 안에서 형식에 맞게 답했습니다. 모범 답과 달랐던 곳은 모델마다 두 곳씩이었습니다. 특히 배송 문의에서 두 모델 모두 긴급하고 답답한 상태라고 봤는데, 사람이 판단해도 의견이 나뉠 만한 문항이었습니다. 형식 문제는 모델이 충분히 크면 이미 해결되어 있었습니다.

보기에서 고르게 하자 확률의 신뢰성이 문제로 남았다

다음으로 모델에 아무것도 쓰게 하지 않고 고르게만 했습니다. 보기에 A·B·C를 붙여 제시하고, 모델이 다음 글자로 무엇을 낼지 계산한 점수에서 보기 글자의 확률만 읽었습니다. Jev가 내놓는 것과 같은 형태, 즉 보기별 확률입니다. 형식이 어긋날 여지는 구조적으로 없습니다. 작은 모델은 세 질문을 2.0~2.5초에 처리해, 같은 PC에서 JSON을 쓰게 할 때(5.3~6.6초)보다 두 배 넘게 빨랐습니다. 담당 팀은 여섯 건 모두 모범 답과 같은 팀을 1순위로 골랐습니다.

문제는 확률 값이었습니다. 작은 모델은 긴급도를 여섯 건 모두 '예'로 판단했고, 재고를 묻는 문의에도 78%를 부여했습니다. 감정은 여섯 건 모두 '답답하지만 정중함'이었고, 소비자원 신고를 예고한 항의에 '매우 분노'는 3.8%에 그쳤습니다. 보기 순서를 뒤집어 다시 묻자 긴급 '예'의 확률이 78~91%에서 45~60%로 내려갔고, 로그인 오류 문의는 긴급도와 담당 팀 답이 모두 바뀌었습니다. 내용이 아니라 보기의 위치가 답을 움직인 것입니다.

큰 모델은 반대 방향의 문제를 보였습니다. Gemma 4 26B는 18개 답 전부에 사실상 100%를 부여했습니다. 모범 답과 다른 두 답에도 100%였습니다. 보기 순서를 뒤집어도 답은 바뀌지 않았으니 흔들림은 없었지만, 확률로 '확실하지 않다'는 신호를 전혀 주지 않은 것입니다. 이 확률로는 어떤 문의를 사람에게 넘겨야 할지 판단할 수 없습니다.

Qwen3.8-27B는 가장 쓸모 있는 확률을 냈습니다. 로그인 오류의 긴급도에는 53%, 결제 버튼 문의의 담당 팀에는 결제팀 65%·기술팀 35%처럼, 사람이 봐도 애매한 문항에서 중간 값을 부여했습니다. 다만 보기 순서를 뒤집자 18개 답 중 3개가 바뀌었습니다. 카드 이중 결제의 긴급도는 '아니오' 73%에서 '예' 85%로 뒤집혔습니다.

여섯 건으로 보정 수준을 통계적으로 측정할 수는 없습니다. 그래도 방향은 분명했습니다. 보기에서 고르게 하면 형식 문제는 사라지고, 형식은 큰 모델이면 쓰게 해도 이미 지킵니다. 세 모델 모두 해결하지 못한 것은 확률이 정답일 가능성과 실제로 맞아떨어지게 하는 일이었습니다. TypeSafe가 RLHF도, 검증 가능한 보상 기반 강화학습(RLVR, Reinforcement Learning with Verifiable Rewards)도 아닌 RLCD라는 이름을 붙인 지점이 이곳입니다. Jev의 확률이 실제로 그만큼 맞는지는 이번에 확인하지 않았고, 아직은 회사의 설명으로만 남아 있습니다.

보정된 확률이 있어야 '사람에게 넘길 답'을 가려낼 수 있다

보정이 중요한 이유는 확률을 받아 쓰는 코드에 있습니다. TypeSafe 문서↗가 권하는 설계는 세 단계입니다. 확신도가 높으면 바로 실행하고, 중간이면 사용자 확인을 거치고, 낮으면 사람에게 넘깁니다. 실행 기준값은 하나로 정하지 않고 작업의 위험도에 따라 다르게 둡니다. 문서의 예시 코드에서 잔액 조회는 잘못 골라도 되돌릴 수 있어 곧바로 실행합니다. 출금 승인은 확신도가 0.9를 넘을 때만 확인을 거쳐 실행하고, 확신도가 0.5 미만이면 어떤 요청이든 사람에게 넘깁니다.

이 설계는 확률이 실제 가능성과 맞을 때만 작동합니다. 모든 답에 100%를 부여하는 모델이라면 기준값을 어떻게 정하든 전부 자동 실행으로 흘러가고, 한가한 문의에 긴급 78%를 부여하는 모델이라면 엉뚱한 작업이 자동으로 실행됩니다. 반대로 애매한 문의에 중간 값이 나온다면, 그 문의만 사람에게 돌리면 됩니다. 모델이 '확실하지 않다'를 숫자로 알려 주면 위험을 얼마나 감수할지는 코드에서 정할 수 있게 됩니다.

큰 판단은 작은 질문으로 나눠 코드에서 합친다

그렇다면 질문은 어느 단위로 나눠야 할까요. 공식 문서↗는 질문 하나를 '잘 아는 사람이 몇 초 만에 내릴 수 있는 직관적 판단' 크기로 두라고 권합니다. '이 스타트업 피치를 평가하라'고 묻지 말고 시장 규모, 기술 실현 가능성, 차별성을 따로 묻습니다. 점수를 합치는 공식은 코드에 둡니다. 우선순위가 바뀌면 프롬프트를 다시 쓰는 대신 코드의 가중치 하나만 조정하면 됩니다.

질문을 늘리는 부담은 크지 않습니다. 한 번의 호출에 선택형(Choice), 점수형(Score), 예·아니오형(Noul) 질문을 함께 넣을 수 있습니다. 각 질문은 같은 상태를 두고 병렬로, 서로 영향 없이 평가됩니다. 문서는 질문을 추가해도 응답 시간이 거의 늘지 않는다고 설명합니다. 한 요청에 들어가는 상태와 질문은 합쳐서 6만 4천 토큰까지이고, 보기는 최대 255개입니다. 무엇을 묻고 보기를 어떻게 나눌지는 결국 사람이 설계합니다. 이번 실험에서 세 모델이 가장 크게 달랐던 질문도 '긴급한가'를 예·아니오 하나로 물은 문항이었습니다.

193배 빠르다는 수치는 자체 평가에서 나왔다

홈페이지에 걸린 '193.6배 빠르고 444.6배 싸다'는 측정 조건을 함께 봐야 하는 수치입니다. 발표문에 따르면 TypeSafe의 모델 역량팀이 만든 네 가지 업무 흐름으로 속도와 비용을 비교해 나온 배수입니다. 정답 대신 GPT-6 Astra와 Fable 5.1이 낸 답의 평균을 기준으로 삼았습니다. 회사는 편향이 있을 수 있다고 스스로 밝혔고, 이 수치가 실제로 얻을 이득의 상단에 가까울 것이라고 적었습니다. 공개 벤치마크 점수는 일부러 발표하지 않았습니다. 입력에도 제약이 있습니다. 모델 문서↗에 따르면 Jev는 텍스트만 받습니다. 발표문의 둠 게임 데모도 화면 이미지가 아니라 텍스트로 정리한 게임 상태를 입력한 것이었습니다.

국내 사용자에게는 언어 문제도 있습니다. 같은 문서에 따르면 주 학습 언어는 영어입니다. 한국어·중국어·일본어도 처리하지만 영어만큼 정확하지는 않으므로, 한국어 업무에 쓰기 전에 자체 데이터로 검증하고 확신도를 특히 주의해서 보라고 권합니다. 이번 실험도 한국어 문의였지만 Jev가 아닌 공개 모델로 진행한 것이어서, Jev의 한국어 성능을 보여 주지는 않습니다.

실험 결과를 보면 반문이 나올 수 있습니다. 공개 모델로도 같은 형태를 구현할 수 있다면 Jev가 새로운 것이 맞느냐는 것입니다. AI 모델 평가 플랫폼 아레나(Arena)의 아나스타시오스 안젤로풀로스(Anastasios Angelopoulos) CEO도 파이낸셜타임스(Financial Times)에 이미 알려진 제로샷 분류기(zero-shot classifier)와 무엇이 다른지 불분명하다고 말했습니다. 이번에 실험한 방식이 바로 그 제로샷 분류기입니다. TypeSafe는 발표문의 질의응답에서 "Jev is neither small nor an LLM"이라고 답했습니다. 작은 모델도, 언어 모델도 아니라는 것입니다. 다만 학습 데이터를 전부 직접 만들었다고만 밝혔을 뿐 구조와 학습법은 공개하지 않았습니다. 세 모델이 흉내 내지 못한 것은 형식이 아니라 확률이 실제 가능성과 맞는 정도였습니다. Jev가 그 확률까지 실제 가능성에 맞게 내놓는지가 기존 제로샷 분류기와 Jev를 구분할 기준입니다.