2년간 스텔스 모드에 있던 TypeSafe가, RLCD(Reinforcement Learning from Calibrated Decision)이라는 새로운 이름의 방법론으로 훈련한 'System One 모델', Jev를 새로 내놨습니다. 이게 인터넷에서 확 터지면서, TechCrunch는 "ChatGPT를 만든 사람이 내놓은 새로운 종류의 AI가 개발자들을 열광시키고 있다"라는 요란한 제목으로 기사까지 냈구요.

오늘 이 글에서 한 번 RLCD를 들여다볼 텐데, 먼저 말씀드리면, 솔직히 TypeSafe의 창업자 Diogo(ChatGPT를 만든 사람 중 한 명이죠)와 TypeSafe 팀에게 감탄의 박수를 보내고 싶습니다 - 단, 이 친구들이 사용한 방법론이 ‘새롭기 때문이 아니’예요. 이 팀이 정말 잘 한 건, 지난 수년간 수많은 연구논문들 사이에 묵혀있던 아이디어 여러 개를 엮어서, 아주 깔끔한 시스템 활용 사례를 붙이고, 거기서 새로운 멋진 용어를 입혀서, 많은 개발자들과 기업에서 ‘자잘한 판단 하나하나에까지 거대한 생성 모델을 갖다 쓰느라 지칠대로 지쳐있는 딱 그 시점에 내놨다는 겁니다. 바로 이게 지금의 Jev 현상에서 눈여겨보고 배울 대목이라고 봅니다.

자, 그럼 이 Jev는 그냥 몇몇 사람들이 이야기하듯이 BERT(구글이 2018년 내놓은, 문장을 읽어 분류하는 인코더 모델이죠)와 비슷한 것 뿐일까요, 그냥 분류기일까요, 아니면 TypeSafe가 정말로 낡은 생각들을 잘 합쳐서 앞으로 AI 씬의 기본적 요소가 될 정말 새로운 뭔가를 만들어낸 걸까요? 하나씩 뜯어봅시다.

Jev의 출시 소식과 간단한 테스트, 그리고 이 모델이 갖는 의미에 대해서는 이미 한 번 짚어드린 바 있습니다:

이번 글은 거기서 한발 더 들어가는 이야기예요. Jev와 그 밑에 깔린 RLCD가 대체 무엇인지, 어떤 오래된 아이디어들 위에 서 있는지, 그리고 굳이 Jev가 아니어도 지금 당장 만들어볼 수 있는 건 무엇인지까지 - 하나하나 차근차근 뜯어보겠습니다.

오늘 다뤄 볼 내용은 아래와 같습니다:

우선 TypeSafe가 Jev를 출시하면서 등장한 여러가지 요란한, 뒤죽박죽인 용어들부터 나눠서 정리해 보죠.

TypeSafe는 회사 이름, Jev는 그 회사가 처음 공개한 모델, RLCD는 그 회사가 훈련 방식에 붙인 이름이고, 'System One 모델'은 이 팀이 Jev가 속한다고 이야기하는 모델의 범주입니다.

‘이름 하나하나’가 다 의도적입니다. TypeSafe는 프로그래밍의 타입 안전성(type safety), 즉 출력이 소프트웨어가 기대하는 타입 안에 머문다는 걸 가리키구요. Jev는 제번스의 역설(Jevons paradox), 즉 자원이 싸지면 오히려 총소비가 늘 수 있다는 아이디어에서 따왔는데, 이 팀이 바로 이 '값싼 지능'에 승부를 건 팀이라는 뜻이죠. 그리고 System One은 다니엘 카너먼의 'System 1', 그러니까 느리고 숙고하는 사고('System 2')와 대비되는 빠르고 자동적인 판단에서 따 왔습니다.

셋 다 차차 다루겠지만, 우선, 저는 이번 Jev 출시에서 다른 모든 요소보다도 ‘타이밍’이 가장 중요한 요소였다고 봅니다. 왜 그럴까요?

지난 몇 년간 프런티어 AI 연구소들은 AI 모델을 더 크고 더 강력하게 만드는 데 집착해 왔고, 지난 한 해 동안은 그 모델들을 중심으로 에이전트 워크플로우며, 모델을 감싸 실제 일을 시키는 실행 장치(하네스)며 온갖 걸 만들어 배포하기 시작했습니다.

그런데 이런 도구들을 실제 사용하는 과정에서는 ‘자잘한 내부적인 판단’을 어마어마하게 많이 내려야 합니다. 실제로 업무용으로 AI 에이전트를 만들어보신 분이라면 공감하실 거예요. 맥락을 더 가져올까? 이 결과면 충분한가? 어떤 도구를 부를까? 이게 규칙을 어기나? 계속할까 멈출까? 어떤 건 그냥 if 문에 들어갈 예/아니오 형태의 질문이고 어떤 건 몇 개의 선택지 중 고르는 것 뿐인데, 그런데도 우리는 이걸 다른 모든 일에 쓰는 그 똑같은 ‘거대한 생성 모델’을 사용해서 해 왔던 겁니다. 다시 말하면, 토큰을 엄청나게 낭비하고 있는 겁니다.

이런 자잘한 판단들이 에이전트의 긴 루프 곳곳에서 불어나기 시작하면 비용도 쌓이고 지연 시간도 늘어나는 데다, 모델의 응답을 자유 형식으로 생성하다 보면 일이 틀어질 가능성도 더 높아지죠. TypeSafe가 Jev를 내놓은 건, 개발자들이 이 모든 상황을 살펴보면서 이런 생각을 하기 시작한 바로 그 시점이었던 거죠: "내가 지금 토큰을 물 쓰듯 미친 듯이 써대고 있는데(이른바 토큰맥싱), 이 판에 박힌 판단들 중에 정말로 거대 생성 모델이 필요한 건 얼마나 될까?" 하는 생각이요.

뭐, 당연히 개발자들이 이 문장을 토씨 그대로 떠올린 건 아니겠죠. 만약 그랬다면, 자기들이 먼저 Jev를 만들었을 테니까요. 근데 Diogo는 분명 이 생각을 하고 있었습니다.

그럼 Diogo는 답을 어디서 찾았을까요? 우리도 거길 한 번 들여다 봅시다. Jev에서 무엇이 TypeSafe가 발명한 것이고 무엇이 훌륭하게 재포장을 한 것인지 살펴보면, 그 곳에는 Jev를 훌쩍 넘어서 우리가 다양한 목적으로 두루 재활용할 수 있는 연구의 보물창고가 있거든요.

머신러닝이 아주 오래전부터 줄곧 씨름해 온 질문이 하나 있습니다. 모델이 확률을 내놓을 때, 그 확률을 실제로 판단에 써도 되는가? 이 질문이 RLCD의 진짜 뿌리인데, 강화학습보다 훨씬 오래됐습니다. 하나씩 따라가 봅시다.

1950년, Glenn Brier는 확률 예측이 실제로 일어난 일과 얼마나 맞는지를 평가하는 방법, 오늘날 우리가 브라이어 점수(Brier score)라 부르는 걸 내놨어요. 기본 발상은 단순합니다. 어떤 예측자가 특정 사건에 70% 확률을 반복해서 매긴다면, 비슷한 사례를 쭉 모아 보면 그 사건이 대략 70%쯤 실제로 일어나야 한다는 거죠. 이게 바로 캘리브레이션(calibration, 확률 보정)의 토대 중 하나입니다.

확률 자체를 믿을 수 있게 되면, 다음 질문은 시스템이 그 확률로 무엇을 해야 하느냐입니다.

1970년, C. K. Chow는 여기에 중요한 선택지를 하나 더했습니다. 분류기가 무슨 입력이든 무조건 답을 고르게 하는 대신, 확신이 없으면 아예 판단하지 않아도 되게 한 거죠. 그러니까 확실할 때만 답을 내고, 애매하면 "이건 내가 판정 안 하겠다"며 넘기는 겁니다. Chow는 이 '언제 답하고 언제 물러설지'의 트레이드오프를 수학으로 정리했어요. 이 발상은 지금도 상황에 따라 기권(abstention), 선택적 예측, 신뢰도 게이팅, 에스컬레이션, 사람 검토처럼 여러 가지로 불리는데, 이름만 다를 뿐 원리는 하나입니다 — 불확실성을 보고, 시스템이 직접 행동할지·기다릴지·남에게 넘길지 정한다는 것. Jev도 바로 이 원리 위에서 작동합니다.

그런데, 신경망이 들어오면서 이 얘기가 좀 복잡해집니다.

문제가 뭐냐 하면, 모델이 정답을 잘 고르면서도 그 답이 맞을 확률은 엉망으로 추정할 수 있다는 거예요. 2017년, Chuan Guo와 동료들은 현대 신경망이 정확도는 높아지면서도 캘리브레이션은 여전히 엉망인 상태로 될 수 있다는 걸 보여줬습니다. 게다가 온도 스케일링(temperature scaling)이라는 간단한 방법을 훈련이 다 끝난 모델에 나중에 덧붙이면, 모델이 고르는 답 자체는 그대로 둔 채 거기 붙는 확률 숫자만 더 정확하게 손볼 수 있다는 것도 함께 보여줬고요.

여기서 문제가 사실 두 갈래로 나뉜다는 걸 짚고 가야 하는데, 이게 RLCD를 이해하는 열쇠입니다. 하나는 '좋은 판단을 내리는 것', 다른 하나는 '그 판단에 쓸모 있는 확률을 붙이는 것'이에요. 둘은 서로 관련은 있지만 같은 문제가 아니고, 두 번째를 푸는 길이 꼭 강화학습만 있는 것도 아닙니다.

그리고 2018년, Google AI Language의 Jacob Devlin과 동료들이 BERT를 내놨습니다.

BERT가 나오면서, 인코더 계열 모델은 글 한 편을 통째로 읽어 그 의미를 '분류하기 좋은 표현(representation)'으로 압축하는 일을 아주 잘하게 됐어요. 그렇게 잘 압축된 표현 위에 간단한 판정기만 얹으면, 리뷰가 긍정인지, 두 문장이 서로 모순인지, 문서가 어느 범주에 드는지를 가려낼 수 있죠. 굳이 문장을 새로 생성하지 않고도요.

이후 연구자들은 이 아이디어를 더 밀고 나갔습니다. 자연어 추론(NLI) 모델에 오면, 레이블을 미리 학습해 두지 않고도 분류하는 제로샷 분류까지 됩니다. 분류할 후보 레이블조차 그때그때 말로 적어주기만 하면 되죠. Stepanov 등의 GLiClass 같은 더 최근 모델은, 이렇게 실행하는 순간 주어지는 레이블에 맞춰 분류하는 가벼운 방향으로 한발 더 나아갔고요.

그러니까 문장을 새로 생성하지 않고도 정해진 판단을 내린다는 아이디어는 이미 탄탄하게 자리 잡혀 있었던 겁니다. LLM이 새로 던진 문제는 '신뢰도'였어요. 모델이 이제 거의 뭐든 답할 수 있게 되고 나니, 그런 모델이 "70% 확신한다"고 말할 때 그게 대체 무슨 뜻이냐는 거죠.

예전 분류기에는 이런 고민 자체가 없었습니다. 출력이 처음부터 "사기일 확률 0.87"처럼 확률 하나로 딱 떨어져 나왔거든요. 그 확률값이 곧 신뢰도이고, 신뢰도라고 부를 만한 후보가 그것 하나뿐이니, 따질 것도 "이 0.87을 믿어도 되나" 하나뿐이었죠.

문제는 LLM입니다. LLM은 애초에 확률이 아니라 글을 뱉도록 만들어진 물건이라, "이 모델이 지금 얼마나 확신하나"를 알려면 그 값을 바깥에서 따로 끄집어내야 합니다. 그런데 끄집어내는 방법이 하나가 아니라 넷이나 돼요.

여기서 핵심은, 이 넷이 전부 뭉뚱그려 '신뢰도'라 불리지만 실제로는 서로 다른 값이라는 겁니다. 토큰 확률이 0.9인 것과 모델이 "90% 확신한다"고 말하는 건 같지 않고, 답이 일관되다고 해서 그 답이 맞다는 뜻도 아니에요. 그러니 예전 분류기처럼 "신뢰도를 잘 맞춰라"라고 말하려 해도, LLM에서는 그 '신뢰도'가 넷 중 무엇을 가리키는지부터 정해야 하고, 캘리브레이션은 그만큼 더 까다로워지는 거죠.

2022년 무렵, 연구자들은 아예 대놓고 언어 모델에게 불확실성을 더 쓸모 있게 표현하는 법을 가르치기 시작했습니다. Stephanie Lin, Jacob Hilton, Owain Evans는 GPT-3가 답과 함께 '저는 70% 확신합니다' 같은 식으로 확률을 말로 뱉도록(verbalized probability) 훈련될 수 있음을 보였고, 비슷한 시기 Anthropic의 「Language Models (Mostly) Know What They Know」는 모델이 자기가 내놓으려는 답이 참인지 스스로 가늠할 수 있는지, 나아가 아예 시도하기 전에 자기가 그 답을 아는지 모르는지까지 알 수 있는지를 파고들었습니다.

결과는 꽤 희망적이었지만, 동시에 Jev 입장에서 아주 유의미한 한계가 드러났어요. 모델이 어떤 과제에서는 캘리브레이션이 잘돼 있어도, 다른 과제로 넘어가면 엉망이 될 수 있다는 겁니다.

여기서부터 연구자들은 강화학습을 실험하기 시작합니다. 답을 맞히는 것뿐 아니라, 신뢰도를 제대로 매기는 것에도 보상을 주는 방식으로요.

2024년, 「Linguistic Calibration of Long-Form Generations」는 강화학습을 써서, 그 모델의 출력을 받아 쓰는 사람이 더 잘 보정된 예측을 하도록 돕는 모델을 훈련했습니다. SaySelf는 지도 학습과 RL을 결합해 신뢰도 추정을 개선했고요.

그리고 2025년, 「Beyond Binary Rewards: Training LMs to Reason About Their Uncertainty」가 나오면서 RLCR(캘리브레이션 보상 강화학습, Reinforcement Learning with Calibration Rewards)을 선보였습니다. 이 모델은 답을 맞히면 보상을 받는 것은 물론, 자기가 매긴 신뢰도가 얼마나 잘 맞았는지를 브라이어 점수로 채점해 거기에도 보상을 받았어요.

자, 여기까지 오면 RLCD 뒤에 깔린 핵심 재료가 이미 다 보입니다. 잘 보정된 확률, 확신에 따라 행동을 고르는 방식, 문장을 생성하지 않는 분류, 그때그때 유연하게 정의되는 판단 과제, 그리고 신뢰도의 품질에까지 대놓고 보상을 주는 강화학습.

TypeSafe가 한 일은, 이 재료들을 '에이전트는 자잘한 판단을 엄청나게 많이 내려야 하는데, 그 판단 대부분은 굳이 텍스트 한 문단을 새로 생성할 필요가 없다'는 아주 구체적인 문제 하나에 딱 맞춰 한데 엮은 것으로 보입니다.

바로 이 점이 RLCD가 흥미로운 이유입니다. TypeSafe는 오래된 통계 문제, 탄탄히 쌓인 분류 연구, 그리고 비교적 새로운 RL 아이디어를 가져다가, 그 조합을 요즘 에이전트 시스템을 만드는 방식에 정확히 겨눴거든요.

그리고 이게 Jev에 대한 진짜 질문으로 이어집니다.

그냥 "그래서 Jev는 캘리브레이션에다 마케팅을 기가 막히게 갖다 붙인 분류기일 뿐이잖아"라고 시큰둥하게 넘기고 싶은 유혹도 생길 수 있습니다. 근데 전 그건 좀 부당한 주장이라고 생각합니다.

첫 번째 이유는, Jev가 특정한 질문 하나에 답하도록 훈련된 단일 분류기가 아니라는 점입니다. TypeSafe의 설명을 보면, 먼저 여러분이 상태(state), 그러니까 검사시키고 싶은 정보를 뭐든 넣어줍니다. 그런 다음에 원하는 판단을 그 자리에서 정의하는데, 판단은 세 가지 형태로 나와요. Noul은 예/아니오 질문에 확률을 매기고, Choice는 여러 선택지에 저마다 확률을 매기고, Score는 순서가 있는 척도나 채점 기준표(루브릭)의 각 눈금에 확률을 매깁니다.

그래서 같은 모델 하나가 고객 상담 대화를 보고 이 사람이 환불을 원하는지, 어느 부서가 처리해야 하는지, 이 대화가 특정한 기준에 얼마나 부합하는지를 한꺼번에 판단할 수 있다는 거예요. 이 질문들을, 질문마다 전용 분류기를 새로 붙여서 훈련하는 대신 그냥 말로 적어서 정의하는 겁니다.

사실 이 요소들 중에 완전히 새로운 건 하나도 없습니다. 문장을 생성하지 않고 분류하는 건 BERT에서, 레이블을 그때 그때 말로 주는 건 제로샷 분류와 GLiClass에서, 확률을 믿을 수 있게끔 해 주는 건 캘리브레이션 연구에서 — 방금 우리가 쭉 훑어본 그대로죠. TypeSafe가 진짜 잘한 건 따로 있습니다. 여기저기 흩어져 있던 이 조각들을, '소프트웨어가 자잘한 판단을 수없이 내려야 한다'는 딱 하나의 구체적인 문제에 겨눠 한 덩어리로 합쳤다는 거예요.

두 번째로, 그 쓰임새에 맞춰 답을 뽑아내는 방식(추론)까지 바꿨어요. Jev는 답을 한 토큰씩 이어 붙여서 문장으로 만들어내지 않습니다. TypeSafe의 말로는, 같은 상태를 두고 던지는 여러 질문을 서로 상관없이 동시에 평가할 수 있고, 나올 수 있는 답은 아예 미리 정해둔다고 해요. '타입 안전성(type safety)'을 내세우는 근거가 바로 이겁니다. Choice에 선택지를 세 가지 넣어두면, Jev가 갑자기 네 번째를 만들어내는 일은 없거든요. 다만 세 가지 중에서 틀린 걸 고르는 건 얼마든지 가능하죠. 그러니 조심해야 합니다. Jev가 실제로 보장하는 건 "정해둔 틀을 벗어난 답은 안 나온다"까지고, 마케팅에 적힌 "환각이 없다"는 건 그것보다 훨씬 크고 대담한 - 또는 무리한 - 약속이거든요.

세 번째는 RLCD입니다. 여기서 노리는 건, 훈련이 끝난 분류기 하나를 사후에 손봐서 확률을 맞추는 수준을 넘어섭니다. 같은 모델이 그때 그때 새로 정의되는 판단을 여러 번 내리면서도, 소프트웨어가 믿고 자동으로 실행해도 될 만큼 쓸모 있는 확률을 매번 돌려주길 바라는 거죠. 알려진 바로는 Jev는 오로지 합성 데이터로만 훈련됐는데, Diogo는 이 데이터를 만들 때 '어떤 답이 실제로 얼마나 자주 참인지를 처음부터 아는' 데이터를 뽑아내는 데 공을 많이 들였다고 했습니다. 이게 Jev가 잘 통하는 비결의 핵심일 수 있어요. 어떤 상황에서 정답이 실제로 몇 번에 몇 번꼴로 맞는지를 미리 알고 있으면, 모델에게 그 확률을 그대로 맞추도록 가르치기가 훨씬 쉬워지거든요.

우리가 아직 모르는 건, 이 조각들이 안에서 정확히 어떻게 맞물리느냐입니다. TypeSafe는 Jev에 새 아키텍처, 하드웨어에 맞춰서 답을 여러 개 동시에 뽑아내는 장치(병렬 샘플러), 그리고 RLCD가 들어 있다고 합니다. 그런데 정작 Jev의 성능이 나오는게 이것들 중에 진짜로 무엇 덕분인지 — 아키텍처인지, 데이터인지, 훈련법인지, 아니면 모델을 실제로 돌려 응답을 내주는 부분(서빙)인지 — 갈라 볼 수 있을 만큼은 공개하지 않았어요.

물론 이렇게 속을 감춰둔다고 해도, 기어이 들쑤셔 보는 사람들이 있죠? 호주 멜버른의 개발자 Archer Hume이 그걸 했어요. API를 수천 번 호출해 가면서 Jev를 바깥에서 거꾸로 뜯어본 결과를 공개했거든요. 두 가지가 눈에 띕니다. 하나는, 한 질문에 준 지시를 다른 질문이 엿보지 못한다는 것 — 즉 질문끼리 서로 독립적으로 처리된다는 거죠. 다른 하나는, 응답에 걸리는 시간을 재보니 같은 상태를 두고 던진 여러 질문이 계산을 한 번만 하고 나눠 쓴다고 봐야 앞뒤가 맞는다는 겁니다. 이걸로 시스템이 어떻게 돌아가는지 대략 감은 잡히죠. 다만 그 밑에 깔린 모델이 정확히 뭔지, RLCD가 그 모델을 어떻게 훈련하는지는 여전히 알 수 없습니다.

그 중에서도 정말 흥미로운 건 Hume이 확률 자체를 뜯어본 부분인데, 여러 분야의 지식을 묻는 벤치마크 MMLU에서 문제 1,200개를 뽑아 재봤더니 캘리브레이션 오차가 약 0.031로 나왔어요. 쉽게 말해 "70% 확신한다"고 할 때 실제 정답률과 3%포인트 남짓 밖에 안 어긋난다는 뜻이니 숫자만 보면 꽤 훌륭하지만, 여기엔 함정이 하나 있습니다. Jev의 예측이 대부분 "거의 확실함" 쪽에 쏠려 있었다는 건데, 정작 확률을 얼마나 잘 맞히는지가 진짜 관건인 애매한 구간(50~70%쯤)은 표본에 별로 없었던 거죠. 게다가 벤치마크 하나만으로는, 이 확률이 여러분의 고객 지원 대기열이나 에이전트 워크플로우에서도 똑같이 버텨줄지 알 길이 없습니다.

그리고 아주 현실적인 골칫거리가 하나 더 있어요. 어느 고객 지원 분류 테스트에서 보기의 순서만 위아래로 바꿨을 뿐인데 확률이 0.84~0.89에서 0.93~0.96으로 훌쩍 뛰었거든요. 앞에서 Jev는 "정해둔 틀을 벗어난 답은 안 낸다"고 했지만, 정작 그 틀 안에서 확률을 매기는 일은 이렇게 흔들립니다. 여러분의 소프트웨어가 "0.9 넘으면 자동 실행"으로 짜여 있다고 해보면, 똑같은 증거에 똑같은 보기인데 순서만 바뀌었다고 어떤 건 실행되고 어떤 건 안 되는 셈이죠. 캘리브레이션은 반드시 실제로 쓸 바로 그 워크플로우 안에서 직접 확인해야 한다는 걸, 이 한 사례가 그대로 보여줍니다.

정리하면, TypeSafe 외부에서 나온 쓸 만한 단서가 좀 있긴 해도 답하지 못한 질문이 여전히 잔뜩 남아 있는 셈이라, 저는 TypeSafe가 연구를 제대로 공개해 주길 바랍니다. 다른 팀들이 이미 우리가 다 아는 재료만 가지고 Jev 비슷한 걸 공개적으로 만들기 시작한 지금은 더더욱요. 그리고 그게 반년씩 걸리는 일도 아닌 모양이던데, 빠르면 이틀이면 되니까요.

개발자들이 Jev의 그럴듯한 겉모습에 혹해서 넘어갈 거라고 보지 않으시죠? 이 양반들은 뭔가 제대로 작동하기만 하면, 번드르르한 웹사이트가 있든 없든 GitHub에서 냉큼 집어다 쓰는 사람들입니다. 사실 이쪽을 더 좋아하죠 — 코드를 직접 열어 뜯어보고, 고치고, 돌려볼 수 있으니까요. 물론 추론을 직접 돌리기 번거로울 땐 API로 갖다 쓰는 편리함도 무시할 순 없습니다. 그러니 이렇게 한번 따져보죠. TypeSafe가 Jev를 내세우며 파는 그 능력들, 그중 얼마나 많은 부분을 이미 공짜 오픈소스로도 얻을 수 있을까요? 그리고 그래도 남는, Jev만의 진짜 차이는 어디에 있을까요?

사실 "하루 만에 만들었다"는 말 자체가, 남이 이미 훈련해 둔 모델에서 출발한다는 뜻이기도 합니다. 진짜 품이 드는 부분은 그 모델에서 답을 다르게 뽑아내거나, 더 알맞은 예시로 미세조정하거나, 확률을 손보는 대목이니까요. 그럼에도 불구하고, 방금 살펴본 이 프로젝트들 덕분에, 우리는 (Jev처럼 속을 감춘 게 아니라) 실제로 뜯어보고 시험해 볼 수 있는 대안을 손에 쥐게 되는 것이죠.

그래서 이제 이렇게 되물어 볼 수 있게 되는 거죠 - Jev가 이런 오픈소스 대안들보다 낯선 과제를 정말로 더 잘 다루는 걸까요? 그리고 Jev가 내놓는 확률은, 이 단순한 방법들로 얻는 것보다 정말로 더 믿을 만한 걸까요?

이것저것 따지지 말고 그냥 Jev를 쓰고 싶으시다면 - 어떤 코딩 에이전트에도 붙이기 쉬우니 사실 그게 편하기도 하죠 - 이미 참고할 만한 공개 빌드가 꽤 많이 나와 있습니다. 대부분 아직 실제 서비스라기보단 실험 수준이지만, Jev가 어디에서 진짜 쓸모가 있을지 감을 잡기엔 오히려 이런 사례들이 딱 좋거든요. 하나씩 살펴보시죠.

쭉 훑어보면 공통점이 하나 뚜렷하게 보입니다. Jev는 늘 더 큰 시스템이 무언가를 반복해서 고르고, 거르고, 줄 세우고, 검증하고, 넘기고, 계속할지 말지를 정해야 하는 바로 그 길목에 끼어든다는 겁니다. 정작 흥미로운 사례들 가운데 Jev가 일을 통째로 혼자 다 해내는 경우는 거의 없다는 것도요.

여기서 마무리해도 되겠지만, 연구 쪽으로 더 파고들고 싶은 분들을 위해 이야깃거리를 조금 더 남겨두려고 합니다.

제가 보기에 Jev는 단순한 분류기 한 종류에 그치지 않고, 하나의 연구 방향을 가리키는 이정표에 가깝습니다. 값싸고 형식이 정해진 판단을 내리도록 훈련된 모델, 그 판단을 얼마나 믿어도 되는지 가늠하는 방법, 그리고 다음에 무슨 일을 할지에 대한 결정권을 계속 손에 쥐고 있는 소프트웨어 - 이 셋을 한데 아우르는 방향이라고 할 수 있죠.

지금 가장 들여다볼 만한 세 가지 방향

출발점으로 삼을 만한 논문들

읽어주셔서 감사합니다!

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!