제브를 만지르기 전에 떠올랐던 생각 — — “판단”을 AI로부터 분리한다는 개념.
최근 TypeSafe AI의 “Jev”라는 서비스가 관심을 받고 있다.
처음 봤을 때에는 솔직히 “빠른 분류 모델이라고 생각했었어” 정도로 생각했었어.
그러나 조사해 나가는 과정에서 조금 다른 모습으로 보이기 시작했다.
이번에 조기 액세스 권한을 얻어 실제로 Jev를 시험해 볼 수 있었다. 이 글에서는 왜 Jev에 관심을 갖게 되었는지 정리한うえ로, 실측하면서 확인된 내용까지 정리하고자 한다.
처음에는 ‘모델’이라고 생각했다.
AI에 대해 이야기할 때, 늘 “어떤 모델인지”라는 관점에서 시작하게 된다.
LLM은 문장을 생성한다.
분류 모델이라면 분류한다.
작은 모델의 경우, 큰 모델보다 가볍게 작동할 수 있지만 어느 정도 성능은 포기해야 합니다.
제브 대해서도 처음에는 그 연장을 보아서 보았다.
그러나 TypeSafe에 대한 설명을 읽어 내려갈수록 뭔가 조금 달랐다.
제브는 생성형 챗봇이 아니다.
또한, 수학이나 체스처럼 높은 추론 능력을 필요로 하는 시스템 2형의 작업에서는 대규모 Reasoning 모델보다 약한 점도 명시되어 있다.
즉, “모든 것을 할 수 있는 새로운 LLM”을 목표로 하고 있는 것은 아니다.
사실, 상당히 의도적으로 일을 줄이고 있습니다.
판단만 추출한다
제브의 프리미티브에는 Noul, Choice, Score 등이 있다.
대략적으로 말하자면,
조건을 충족하는지
여러 가지 선택지 중에서
어떤 기준으로 어느 정도인지
이러한 판단을 구조화된 결과로 반환한다.
여기서 재미있는 점은, 분류 대상 자체를 모델에 고정하지 않는다는 것이다.
소프트웨어 측에서,
이 상태에 대해 이 질문을 이 선택지에서 판단해 주세요.
다음 문제는 다음과 같은 형태로 제시됩니다.
즉, 모델이 “청구서 분류기”나 “문서 분류기”로 작동하는 것이 아니라, 즉석에서 정의된 판단 문제를 해결한다.
이 차이는 꽤 크다.
왜 작은 분류 모델이 좋은 결과가 나올까?
작은 모델은 학습 데이터가 부족하거나, 데이터의 복잡도가 높을 때 오히려 더 잘 작동하는 경우가 많다. 모델이 너무 크면 과적합될 가능성이 높아지는데, 이는 학습 데이터에는 잘 맞지만 새로운 데이터에는 제대로 작동하지 않는 현상을 말한다.
예를 들어, 딥러닝 모델을 사용하여 고품질의 자동차 이미지를 수만 장 학습시킨다고 가정해 보자. 이 경우, 매우 복잡한 딥러닝 모델이 과적합되어 자동차 이미지의 특정 특징(예: 특정 브랜드의 헤드라이트)에만 지나치게 민감하게 반응할 수 있다. 반면, 비교적 단순한 모델은 이러한 과적합을 피하고 일반적인 자동차 특징을 더 잘 학습하여 더 정확하게 새로운 자동차 이미지를 분류할 수 있다.
이러한 현상은 ‘단순성’이라는 원칙과 관련이 있다. 복잡한 모델은 더 많은 파라미터를 가지므로, 학습 데이터의 노이즈까지 학습할 가능성이 높다. 반면, 단순한 모델은 노이즈에 덜 민감하고, 데이터의 핵심적인 특징에 집중하여 더 강력한 일반화 성능을 보일 수 있다.
여기서 제가 로컬 AI를 여러 가지로 시험해 본 경험이 뜻밖의 결과로 나타났습니다.
작은 모델을 실제로 작동시켜 보면
정답을 제시하는 것과 판단하는 것은 동일하지 않습니다.
점차 그 의미가 분명해지고 있습니다.
4B 미만의 모델이라도 간단한 문제의 경우 정확한 답을 반환할 수 있다.
하지만 그것이 진정으로 판단할 수 있다고 보기는 어렵고 의심스럽다.
잘못할 때, 자신이 잘못하고 있음을 인지하지 못한다.
제 경험으로는 명확하게 “판단하고” 있다는 느낌을 받기에는 더 큰 모델이 필요합니다.
또한, 판단력이 발현된 이후에도 모델 사이즈가 커질수록 판단 정확도는 향상된다.
그러므로,
판단만으로는 1B 정도로 줄여도 충분합니다.
이건 단순한 이야기가 아니다.
여기 제프의 설계가 더욱 흥미로워지기 시작한다.
모델을 작게 만드는 대신, 모델에 요구하는 업무를 좁히는 것이다.
생성을 버리고 판단에 집중하십시오.
일반적인 LLM은,
이해한다. 생각한다. 판단한다. 설명한다. 문장을 만든다.
단일 모델로 엄청난 양의 업무를 처리하고 있습니다.
제브는 그 중에는 “판단”에 상당히 가까웠다.
그러므로, 출력 토큰에 대한 과금 요금 체계도 이해하기 쉬워집니다.
제브의 출력은 장대한 답변이 아니다.
소프트웨어가 다음 처리에 필요한 판단 결과를 반환하면 된다.
그 이후 처리는 코드가 담당한다.
이는 “LLM을 소형화한다”는 발상과는 조금 다르다.
LLM의 지능을 소프트웨어가 쉽게 활용할 수 있는 기본적인 요소로 해석한다.
그런 설계가 보이기 시작했다.
라우터와는 차이가 있습니다.
여기에서 한 번, 라우터와의 차이점도 정리하고 싶다.
라우터는
이 일은 어디로 보내야 할까요?
결정을 내릴 자대는 당신에게 달려 있다.
한편, Decision Layer는
이 상태는 어떻게 판단해야 할까요?
보세요.
물론 라우터가 판단 결과를 활용할 수 있습니다.
하지만 Decision Layer 자체가 라우터라는 의미는 아니다.
예를 들어,
생성한 문장을 검증한다.
툴의 실행 결과가 기대하는 대로 확인한다.
인간의 확인이 필요한지 판단합니다.
후보 중에서 다음으로 나아갈 자격을 가진 것을 선택한다.
이러한 처리는 라우터와는 별개의 판단 문제이다.
그러면서 “LLM을 판사처럼 활용하는” 방식이 나타나기 시작합니다.
이러한 점을 고려하면, Jev의 용도로서 판사가 상당히 자연스럽게 보입니다.
지금까지 LLM에 무엇을 생성하게 했는지에 따라,
이렇게 맞으신가요?
다른 큰 LLM에 질문하는 경우가 있습니다.
하지만 이건 꽤 무겁다.
단순히 판단하는 것인데, 거대한 모델을 호출하여 긴 출력을 생성하도록 한다.
그래서, 검증을 자주 추가하려고 해도 비용이나 지연 시간이 문제가 됩니다.
만약 판단만이라도 매우 빠르고 저렴하게 실행할 수 있다면 상황이 달라진다.
생성↓판정↓도구↓결과↓판정↓다음 처리
이러한 루프를 지금까지보다 훨씬 쉽게 만들 수 있습니다.
즉, 제프의 가치는
거대한 언어 모델을 호출할 필요가 없다
그것뿐만이 아니다.
지금까지 비용적인 이유로 생략했던 판단을 워크플로우 안에 대량으로 추가할 수 있는 가능성이 있다.
이 부분이 재미있네.
가격도 상당히 특징적입니다.
현재 공개된 Jev의 가격은,
1B 입력 토큰당 42달러(0.042달러/MTok)
되어 있습니다.
그리고 출력 토큰은 무료입니다.
이 가격을 보면 단순한 “저렴한 AI API”라는 것보다는 판단을 많이 내리도록 의도한 설계로 보입니다.
TypeSafe는 Jev라는 이름을 Jevons의 역설에서 유래한 것으로 설명하고 있다.
그러므로, 특정 처리가 간편해졌을 때,
그러면 사용량을 줄여보자.
그 대신
가격이 인하되었으니, 이전에 사용하지 못했던 곳에도 사용해 보려 합니다.
그 방향이다.
이는 의사결정 레이어라는 개념과 매우 잘 어울린다.
판단이 고가이기 때문에 생략했던 부분에 저렴한 판단을 대량으로 채우는 것이다.
그렇다면 단순한 비용 절감과는 다른 가치가 창출된다.
그래도 아직은 모르겠습니다.
이까지 쓰고 보니 중요한 것이 있습니다.
아직 스스로 Jev를 충분히 테스트하지 않았다.
지금까지 공개된 정보와 문서, 다른 이용자들이 수행한 실험을 통해 파악한 단계였습니다.
그리고 이번에야 드디어 콘솔에 접속할 수 있게 되었다.
게다가 테스트 목적으로 5달러 상당의 크레딧이 지급되었습니다.
이건 딱 좋네.
5달러라면, 가끔 실험용으로 써도 괜찮을 것이다.
그러므로,
실제 레이턴시
입력 토큰 수
1. 판단 비용 측정
동일한 문제를 대규모 언어 모델에 판단하도록 요청했을 때와 비교했을 경우
판단 결과의 정확도
동일 조건에서 대량으로 던지는 경우의 안정성
그것들을 실제로 측정해 보았다.
특히 걱정되는 것은 “저렴하다”는 점 자체 때문이 아닙니다.
이 가격과 속도라면, 지금까지는 들어올 수 없었던 판단들을 정말로 워크플로우에 대량으로 추가할 수 있을까요.
그곳을 확인하고 싶다.
먼저 작은 테스트부터 시작해 봅시다.
갑자기 대규모 벤치마크를 진행하는 대신, 먼저 판단 문제를 몇 가지 준비하여 동일한 입력을 반복적으로 제공했다.
확인된 내용은 다음과 같습니다.
얼마나 빠른지
얼마나 정확하게 판단할 수 있을까요.
1달러로 얼마나 많은 결정을 내릴 수 있을까?
이 세 가지 점이다.
그 결과들을 토대로 실제 에이전트 워크플로우에 적용했을 때 어떤 일이 벌어질지 고려해 보았다.
최저한으로 현재 시점에서는 Jev를 “새로운 LLM”이라고 보는 것보다
AI의 판단 능력을 소프트웨어에서 호출 가능한 부품으로 접근했습니다.
생각해 보면 훨씬 이해하기 쉬울 거예요.
그렇다면 실제로는 어떤 모습이었을까요?
5달러 상당의 크레딧을 사용하여 확인해 보았다.
실제로 측정해 보았습니다.
결론적으로, 5달러 중 0.4%밖에 사용하지 않으면서, 여기에 적은 것만으로도 실측이 이루어졌습니다.
콘솔에 나타난 성과는 다음과 같습니다.
요청: 33회
토큰: 401,707
요청: 0.02달러
이 중 실제 작업으로 던진 판단은 509문제였습니다. 나머지는 측정(같은 질문을 5회 반복하고, 입력을 단계적으로 확대하는 등)에 활용했습니다.
가장 먼저 놀란 것은 속도였다.
가장 먼저 나타난 숫자는 이것입니다.
1회의 요청에 40개의 판단을 묶어 0.87초(5회 시도 결과 0.74초에서 1.00초 사이)를 기록했습니다.
동일한 요청을 5번 반복한 결과, 이는 “40문제를 병렬로 처리한 시간”에 해당하며, 1문제씩 처리하는 것보다 훨씬 빠르다.
그리고 입력 크기를 바꾸어도 크게 변하지 않았다.
1,000자 입력 → 0.63초
10,000자 → 0.74초
40,000자 → 1.16초
즉, 지연의 원인은 입력의 크기가 아니다. 기초적인 고정 시간이 먼저 주어진 후, 거기에 약간 추가되는 것으로 보인다.
출력 측 모습 또한 특징적이었다.
질문 3 → 출력 77 토큰
40문항 → 출력 1,445 토큰
출력 78 토큰
입력과 출력을 10.8:1의 비율로 하고 있으며, 출력에 대한 과금 체제가 적용되지 않아 그 결과가 그대로 숫자로 나타나고 있습니다. 반대로 말하면, 비용을 결정하는 것은 입력만 하므로, 동일한 입력을 반복적으로 보내지 않도록 묶어서 관리하는 것이 효과적입니다.
같은 입력을 5번 던져도 결과는 거의 변하지 않습니다.
안정성도 확인하고 싶어 같은 요청을 5번 던졌다 (40문제).
5회 모두 똑같은 답변이었던 질문: 17/20 (85%)
흔들린 3개의 질문의 신뢰도: 0.16 ~ 0.60
수치로 반환된 Noul의 진폭은 평균 0.05, 0.5를 포함하여 3번의 반전이 있었다.
여기서 재미있는 점은, 흔들린 부분은 스스로 흔들릴 가능성이 있다고 밝혔다는 점입니다. 자신감 없는 질문에만 답변의 흔들림이 집중되어 있습니다.
자신감은 겉으로 보이는 장식이 아니라, 실제로 작동하는 지표라고 생각한다.
인간이 무엇을 확인해야 하는지에 대한 수치적 결과가 나타났다.
이것이 제 개인적인 용도에서는 가장 효과적입니다.
14건의 판단 결과를 자신의 판단과 대조해 보았다.
일치 완료: 2023년 12월 14일 (86%)
오류는 신뢰도 0.4에서 0.8 사이의 범위에 집중되는 경우 발생합니다.
0.4 미만과 0.8 이상은 모두 일치했습니다.
또한 오류는 심각하게 나타났고, “아직 살아있다”라는 표현을 자주 사용했다.
즉, 인간이 무엇을 확인해야 하는지에 대한 지시사항을 명확히 할 수 있다.
그리고 또 하나. 이 임계값은 코드 측에 있다. 따라서 기준을 바꾸어도 모델에 다시 던져줄 필요가 없다. 실제로 36건의 분류 작업을 API를 한 번도 호출하지 않고 다시 수행할 수 있었다. 프롬프트를 다시 작성하여 모든 항목을 다시 흘려보내는 작업이 필요 없다는 점이 크다.
실무에 적용해 본 결과, 가장 효과가 좋았던 형태가
동일한 입력을 공유하여 한 번에 많은 질문을 던지는 방식이 효과적입니다.
36개의 디렉터리에게 “이것은 무엇인가?” “여전히 존재하는가?”라는 질문을 던졌을 때, 78개의 질문을 한 번에 던졌다. 입력 토큰 수는 29,831개였다. 1개씩 던졌다면 같은 입력을 78번 보내게 된다.
또 다른 차이점 검토를 위해 사용해 보았다. 18개의 파일, 2,103줄의 변경 사항을 파일별로 4가지 질문으로 분해했다.
어떤 계층에 접근해야 할까요.
얼마나 위험한지
기존 호출 방식을 파괴하는 것
테스트가 필요한지 확인하시겠습니까?
그 결과, 그렇게 갈라졌다.
새롭게 추가된 코드(745행, 519행 등) → 위험도는 낮지만 “테스트가 필요”
기존 파일의 수정 → “확인 필요”
이는 인간의 검토로도 놓치기 쉬운 부분이라고 생각합니다. 2,103행의 이식(移植)을 눈으로 따라가다 보면 “새로운 추가의 산”에 잠겨 기존의 수정 사항이 흐릿해집니다. 그곳이 자동으로 돋보이는 것은 도움이 됩니다.
또한 부차적인 효과로 자신의 맥락을 소비하지 않는다. 107,000자 분량의 diff를 보지 않고도 18행의 표만 받아, 1문제당 약 40토큰으로 압축되어 반환되는 느낌으로, 그만큼의 시간을 실제 수정 작업에 활용할 수 있다.
한계는 명확하다.
좋은 일들만 적는 건 의미가 없으니까요.
입력은 약 32,768 토큰으로 잘리며, 일본어로는 약 4만 자입니다. 400이 반환되고, 실제로는 18 파일의 검토가 3회로 분할됩니다.
“참조되고 있는지”와 같은 사실은 답하기 어렵습니다. 이는 코드에서 확인해야만 합니다. 실제로 살아있는 설정 파일의 참조를 놓친 것을 grep이 잡아주었습니다. 모델의 판단만 의존해서는 안 되는 상황이 있습니다.
대규모 언어 모델(LLM)과 직접 비교한 A/B 테스트는 아직 진행되지 않았으며, 동일한 입력에 대해 얼마나 차이가 발생하는지 검증하는 것은 다음 단계이다.
이것은 무엇이든 할 수 있는 새로운 LLM이 아니다. 긴 문장을 쓰거나, 추론하거나, 계획을 세우는 등의 업무는 기존 LLM의 담당 업무대로 유지된다. 판단에 근거한 설계의 반전이라는 점은 좁은 범위에 불과하다.
5달러로 얼마나 쓸 수 있을까요?
가장 염려되는 부분.
방금 쓴 내용대로, 1일 동안 터치한 요청 건수는 33건, 토큰 수는 401,707개, 금액은 0.02달러입니다. 이는 5달러의 0.4%에 해당합니다.
40문제를 모아 놓은 1회는 약 1만 토큰이므로, 1달러로 약 2,300건의 요청, 판단의 수로 치면 약 9만 회에 해당한다. 0.87초로 돌아가므로, 1달러분을 계속 투자하면 30분 이상 쉴 새 없이 판단하도록 할 수 있는 계산이 된다.
숫자만 놓고 보면 ‘저렴한 AI’라는 것보다 판단을 내리는 데 드는 비용을 거의 무시할 수 있게 했다는 인상이 강하다.
현재까지의 결론
제브를 “새로운 LLM”이라고 보는 것보다, AI의 판단 능력을 소프트웨어에서 호출될 수 있는 구성 요소로 접근한 관점이 더 적절했으며, 실제로 측정해 보아도 큰 차이는 없었다.
하지만 가치는 단순히 저렴한 것 자체의 것이 아니라고 생각합니다.
저렴한 가격으로 같은 일을 저렴하게 하려고 하는 대신, 과거에 판단에 비용이 많이 들었다는 점을 간과했던 부분에 판단을 추가할 수 있게 된다. “루프 안에 판사를 여러 번 넣는” 것이 현실적인 선택지가 될 수 있다.
실제로, 이 글을 작성하는 과정에서도,
코드가 사실을 수집한다 (파일 목록, Git 히스토리, 참조 존재 여부)
제브가 의미를 판단한다 (무엇인지, 위험한지, 다음으로 해야 할 일인지).
코드가 결과를 종합하여 실행한다 (임계값, 정렬, 이동)
이러한 분배가 가장 깔끔하게 작동했다. Jev는 단독으로 완결되지 않고, 코드와 함께 사용될 때 그 효과가 빛을 발한다.
다음으로, 이를 실제 에이전트 루프 안에 넣어 판단 횟수를 늘릴 때 어떤 일이 발생하는지 확인해 보고 싶다.
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 121청크
원문 보기 | 출처: note.com