TECH 으로 돌아가기
TECH HACKER NEWS 오늘 8분 읽기 23 READS

OpenAI는 왜 TypeSafe의 'Jev'를 빠르게 따라잡을 수 있나

OpenAI는 왜 TypeSafe의 'Jev'를 빠르게 따라잡을 수 있나
SOURCE IMAGE · HACKER NEWS

AI 게이트웨이 시장에 갑자기 등장한 TypeSafe의 'Jev'는 기존 언어 모델과 결이 다른 제품이다. 긴 문장을 생성하는 대신, 주어진 상황과 질문에 대해 잘 보정(calibrated)된 확률값으로 즉각적인 판단을 돌려준다. Vercel은 Jev를 두고 "AI 게이트웨이 역사상 가장 빠르게 채택된 모델"이라고 표현했다. 그런데 Arcturus Labs의 한 분석가는 이 성공이 오히려 위험 신호일 수 있다고 본다. Jev가 약속한 성능을 실제로 구현했다면, 바로 그 이유 때문에 OpenAI가 손쉽게 복제하고, 나아가 자사 모델 안으로 흡수해 버릴 수 있다는 것이다.

Jev가 실제로 하는 일

분석의 출발점은 Jev가 기존 대형 언어 모델과 상당히 가까운 구조를 쓰고 있으리라는 가정이다. Latent Space는 초기 복제품 상당수가 실제로 LLM 기반이라고 전했다. 원리는 이렇다. 모델은 상태와 질문을 받으면 다음 토큰 하나에 대한 확률 분포를 만들어 내는데, Jev는 이 분포를 필요한 형식으로 가공해 답으로 되돌린다. 참·거짓을 묻는 질문이라면 true와 false 두 토큰의 확률만 떼어 내 정규화하고, 선택형이라면 A·B·C·D처럼 제시된 후보 토큰들의 상대 확률을 비교해 가장 높은 것을 답으로 고른다. 점수형 역시 같은 패턴의 변형으로 추정된다. 저자는 이 아이디어의 골격을 이미 2025년 자신의 글 'Supercharging LLM Classifications with Logprobs'에서 다뤘다고 밝히며, 결국 관건은 아이디어가 아니라 실행이었음을 자조적으로 인정한다.

OpenAI는 이미 이 기법을 써 왔다

핵심 논지는 OpenAI가 이런 방식의 '암묵적 분류기'를 수년째 써 왔다는 데 있다. 저자가 2024년 글에서 보여 준 것처럼, ChatML 형식에서 어시스턴트 응답이 시작되는 순간 모델이 예측하는 첫 토큰은 일반 문장이거나 도구 호출(to=function.)이다. 이 한 토큰이 사실상 '도구를 부를지 말지'를 가르는 분류기 역할을 하고, 뒤이어 어떤 도구를 부를지, 인자는 무엇인지, 메시지가 끝났는지()를 판단하는 미세 분류기들이 줄줄이 이어진다. 저자는 GitHub Copilot 시절 겪은 일화도 든다. 초기 GPT-4 내부 API에서 메시지 구분자 사용을 허용하는 헤더값을 빠뜨리자, 모델이 응답을 끝내는 토큰을 예측하지 못해 "좋은 하루 보내세요"류의 인사를 토큰 한도까지 끝없이 반복했다는 것이다. 요컨대 언어 모델은 이미 모든 다음 토큰마다 확률 분포를 매기는, 대단히 일반적인 분류기다. Jev의 분류기가 범용이고 OpenAI의 것은 특정 작업 전용이라는 차이가 있을 뿐, 그 간극은 생각보다 좁을 수 있다.

진짜 해자는 아키텍처가 아니라 데이터

그래서 저자는 아키텍처에 방어막이 거의 없다고 본다. 남는 것은 학습 데이터, 정확히는 데이터를 '보정된' 판단을 낳도록 가공하는 기법이다. TypeSafe 공동창업자 Diogo Almeida도 데이터가 아키텍처보다 중요하다는 지적에 "우리를 데이터 연구소라 여긴다"며, 연구의 대부분이 진정으로 범용적인 데이터를 만드는 데 쏠렸고 데이터의 100%가 합성이라고 답했다. 다만 그는 그것이 "LLM이 그냥 뱉어 낸 쓰레기" 같은 종류는 아니라고 선을 그었다. 저자가 상상하는 학습셋은 결과가 이미 알려진 방대한 사례다. 라우팅된 지원 티켓, 채용 결과가 확정된 이력서, 실제 별점이 매겨진 리뷰, 판정이 끝난 신고 큐, 이미 정산된 예측 시장 등을 각각 정답을 아는 질문과 짝지어, 특정 도메인 지식이 아니라 폭넓은 도메인을 가로지르는 분류 일반화 능력을 키우는 방식이다. 여기에 어떤 강화학습이 결합되는지는 불분명하지만, 진짜 비법이 있다면 아마 그 지점에 있을 것이라고 본다.

다만 이 모든 것은 Jev가 실제로 정확할 때만 해자가 된다. 속도·비용·사용 편의성은 눈에 보이지만, 정확도만은 검증이 어렵다. 저자 스스로 Jev의 확률이 잘 들어맞지 않는 도메인을 이미 발견했다고 털어놓는다. TypeSafe 역시 Jev가 수학이나 다단계 추론이 아니라 빠른 '시스템 1'식 즉각 판단에 강하다는 한계를 공개하고 있다.

복제를 넘어 모델 안으로

그렇다면 OpenAI의 다음 수는 무엇일까. 가장 뻔한 선택은 Jev를 그대로 베껴 새로운 모델 유형으로 출시하는 것이다. 해자가 얕다면 OpenAI는 기술·하드웨어·자금을 모두 갖췄다. 그러나 더 흥미로운 길은 이 분류 능력을 일반 LLM 안에 접어 넣는 것이다. 도구 호출을 알리던 to=function. 구문처럼, 모델이 스스로의 문맥 안에 같은 태그를 넣어 즉석 판단을 요청하는 방식이다. 일반 도구 호출과 달리 여기엔 외부로의 인계가 없다. 모델이 'probability:'까지 쓴 지점에서 일반적인 디코딩 대신 true·false 두 토큰의 로짓만 정규화해 그 확률값을 텍스트로 되받아 쓴 뒤, 마치 자신이 생성한 숫자인 양 이어서 디코딩한다. 제약 출력 라이브러리가 쓰는 가이드 디코딩을 문법이 아니라 확률에 적용하는 셈이다.

관건은 이 한 자리에서 모델이 '다음에 올 토큰'이 아니라 '이 질문의 참된 답'을 추정하도록 만드는 것인데, 요즘 프런티어 모델이 대부분 전문가 혼합(MoE) 구조인 만큼 몇 차례 미세조정으로 이런 보정된 즉답을 전담하는 전문가를 떼어 내는 그림이 무리는 아니라는 것이 저자의 관측이다. 이렇게 하면 모델이 사고 블록 안에서 자기 자신에게 질문을 던지고 곧바로 답하며, GPU를 한 번도 벗어나지 않는다. 확신도를 평문으로 말하게 하는 방식보다 환각도 적다. 결국 저자의 우려는 명확하다. Jev가 발굴한 통찰이 진짜라면, 그 가치를 가장 크게 누릴 위치에 선 쪽은 정작 그것을 자사 모델과 에이전트에 내장할 수 있는 OpenAI이며, 스타트업 Jev는 그 확장을 따라갈 수 없다는 것이다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://arcturus-labs.com/blog/2026/09/21/will-openai-eat-je...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...