AI makes it easier to ship anything, even bad ideas. The hard part is knowing which ideas are worth building.

Jira Product Discovery brings your ideas, customer insights, and priorities into one place, so your team can decide what to ship and move forward with confidence.

Capture ideas, prioritize with evidence, and build living roadmaps your team can rally around—all while staying connected to delivery in Jira, so everyone can see what’s being built and why.

Better product decisions in the AI era.

Try Jira Product Discovery

금주인 2026년 9월 15일, 샌프란시스코의 AI 랩 TypeSafe AI가 2년간의 스텔스 모드를 끝내고 모습을 드러냈습니다. 2024년 설립된 이 회사는 DCVC가 주도한 4,000만 달러 규모의 시드 투자와 함께 그 첫 모델 ‘Jev’를 공개했죠 - 막 첫 제품을 발표한 회사치고는 규모가 꽤 크죠? (물론, 최근 실리콘밸리의 기준으로는 꼭 그렇다고 볼 수도 없죠 ^.^;)

창업자 겸 CEO인 디오고 알메이다(Diogo Almeida)는 전 OpenAI 연구자로, 회사 팀 페이지에는 디오고 RLHF와 InstructGPT, 결국 ChatGPT로 이어진 방법론을 공동으로 발명한 사람이라고 소개하고 있습니다. InstructGPT 논문에도 공동 저자로 이름이 올라 있구요.

이 팀이 만든 AI 모델, Jev는 ‘사람과 대화하지 않는 모델’인데요.

TypeSafe가 내건 명제를 그대로 옮겨보면, “사람만이 지능의 소비자일 수는 없다”는 겁니다. 지금까지의 AI는 사람이 질문하고 사람이 답을 읽는 인터페이스에 맞춰서 발전했는데, TypeSafe는 앞으로 훨씬 많은 지능이 ‘소프트웨어 안에서 조용히 작동할 것’이라고 본다고 합니다. 그래서 사람이 읽기 좋은 문장이 아니라, 프로그램이 바로 사용할 수 있는 값, 이른바 기계 친화적 지능(machine-native intelligence)을 만들겠다고 나선 겁니다.

TypeSafe의 첫 모델 Jev는, 프리 텍스트 (Free Text)를 생성하지 않고, 구조화된 상태와 타입이 지정된 질문을 받아서, 토큰을 하나씩 이어 쓰는 대신에 여러 개의 답을 병렬로 계산해서 타입이 정해진 값으로 돌려줍니다. 예·아니요에 대한 보정된 확률, 최대 255개 후보 가운데 하나, 또는 정의된 연속 척도 위의 점수예요.

이 회사에서는 새로운 모델 구조와 병렬 샘플러, 그리고 RLCD(Reinforcement Learning for Calibrated Decisions)라는 자체 학습법을 개발했다고 하고 있습니다. 대니얼 카너먼의 시스템 1·시스템 2 구분을 빌려서, Jev가 첫 번째 System One Model이라 부르기도 하는데, 오래 생각을 해서 문장을 만드는 모델이 아니라, 소프트웨어가 다음 행동을 정할 때 필요한 ‘범위가 비교적 제한되어 있는 빠른 결정’ 부분을 맡겠다는 거예요.

Jev 모델의 가격과 속도에 관한 공개 수치를 보면, 입력 100만 토큰당 0.042달러, 출력은 무과금, 엔드투엔드 응답 시간은 70~500ms입니다. TypeSafe는 System One 형태의 과제에서 프런티어 LLM보다 20~200배 빠르고 40~400배 저렴하다고 주장하고, 주요 용도는 요청의 분류와 라우팅, 스코어링, 탈옥 시도 탐지, 다른 모델이 내놓은 결과의 2차 검토 등으로 제시합니다.

여기서 ‘공개 수치’와 ‘검증된 일반 성능’을 구분해야겠죠. 가격은 확인할 수 있는 수치지만, 속도와 배수는 TypeSafe가 설계하고 실행한 워크플로우 평가에서 나온 회사 수치라서, 과제와 네트워크, 비교 모델의 추론 설정이 달라지면 결과도 달라질 수 있습니다.

Jev가 공개된 직후 Hacker News 등 초기 반응은 꽤 좋았습니다. 발표 글이 하루 사이에 1,500점 안팎, 400개가 넘는 댓글을 모았고, Gemini 3.8 Live와 Periodic Labs의 발표가 겹친 날에도 오랫동안 1위를 지켰습니다. 새로 시장에 모습을 드러낸 시드 단계 회사의 첫 제품으로는 보기 드문 관심이었구요.

흥미로운 것은 비판의 방향인데, Jev가 아무것도 하지 못하는 가짜 기술이라는 식의 공격은 거의 없었고, 회사가 제시한 비교를 어디까지 믿을 수 있느냐는 질문이 중심이었습니다.

먼저 70ms의 Jev와 최대 329초가 걸린 LLM을 한 그래프에 놓은 것이 제대로 된 비교냐는 지적이 나왔습니다. TypeSafe의 비교 대상 중에는 워크플로우의 전체 논리를 chain-of-thought로 생성하는 LLM 설정도 포함돼 있습니다. 정해진 답의 공간에서 병렬로 값을 고르는 Jev와 긴 추론 과정을 생성하는 LLM을 비교하면, 아키텍처의 차이만큼 과제 설정의 차이도 속도 차이에 들어가겠죠.

두 번째 의문은 RLCD와 병렬 샘플러를 실제로 어떻게 구현하고 검증했느냐입니다. 공개 시점에는 이걸 상세하게 설명하는 논문이나 Ablation 연구(제거 연구)가 없었습니다. 새로운 이름과 성능 수치는 나왔지만, 구성 요소 중에 어떤 것이 얼마나 기여했는지 외부에서 살펴보면서 확인할 자료는 아직 부족합니다.

평가 방식도 논쟁거리입니다. 출시 당시에 핵심적인 수치는, 독립된 제3자 벤치마크보다는 TypeSafe가 만든 자체 워크플로우 평가에 의존하고 있죠. 참조 답도 사람이 만든 정답표가 아니라 GPT-6 Astra와 Claude Fable 5.1의 확률을 평균내서 구성했습니다. TypeSafe 역시 이 방식이 OpenAI와 Anthropic 모델 쪽으로 답을 편향시킬 수 있다고 밝히고 있습니다.

가장 날카로운 비판은 ‘제로 할루시네이션’이라는 표현에 대한 것이었습니다. Jev가 스키마에 없는 값을 만들어내지 않는다는 것은 ‘타입 안정성’에 관한 주장일 뿐이지, 허용된 선택지 안에서 틀린 답을 고르는 일까지 사라졌다는 뜻은 아닙니다. TypeSafe의 0% 수치도 실제 오류를 센 결과가 아니라 스키마 일치가 보장된다는 분석적 수치입니다. 형식적으로 유효한 답과 사실적으로 옳은 답은 다르죠.

그렇다고 TypeSafe가 불리한 조건을 감추기만 한 건 아닙니다. 회사는 평가 사이트에 워크플로우, 비교 방식, 예시 쿼리를 모두 공개했고, 자체 팀이 과제를 만들었다는 점과 참조 답의 편향 가능성, 193.6배·444.6배가 실제 이득의 최상단 수준일 가능성까지도 각주에 적어 놨습니다. 주장에도 완전히 객관적이라고 보기 힘든 문제가 있지만, 한계까지도 함께 공개했다는 점은 고려할 만 합니다.

자, 그렇다면 남은 질문은 뭐, 단순하죠. 화려한 숫자를 잠시 내려놓고 실제로 써봤을 때, Jev는 뭘 할 수 있고 Codex 같은 생성 모델과 어떻게 다를까요?

저희 튜링포스트 팀이 TypeSafe AI로부터 사전 접근 권한을 받아서 Jev의 콘솔을 살펴보고, Codex에 연결해서 같은 과제를 돌려서 비교해 봤습니다. 튜링포스트의 Ksenia가 진행해 본 이 테스트를 유튜브에서 17분짜리 영상으로 보실 수도 있습니다 - 테스트는 가벼운 ‘샌드위치’ 질문에서 시작해서 헬프데스크 분류, Codex와의 비교, 그리고 에이전트가 일을 끝까지 해내려면 뭐가 더 필요할까 하는 질문까지 이어집니다.

그럼, 저희가 테스트해본 Jev, 함께 확인해 보시죠.

Jev의 화면을 보면 플레이그라운드가 있고, 거기에 두 가지 종류의 입력란이 있습니다. State에는 모델이 살펴볼 정보를 넣고, Questions에는 그 정보를 가지고 무슨 판단을 할지 적는 거예요.

질문의 형태는 세 가지입니다. Noul은 예·아니요 중 ‘예’일 확률을 돌려주고, Choice는 사용자가 미리 정한 후보 중에 하나를 고르고, Score는 순서가 있는 기준에 따라서 점수를 매깁니다. 질문은 자연어로 쓰지만, 답이 나올 틀은 사람이 먼저 정하는 방식이죠.

첫 번째로 해 본 질문은 “핫도그는 샌드위치인가?”였습니다. 핫도그-샌드위치 논쟁은, 정의를 어떻게 내리느냐에 따라 답이 갈리는 미국의 오래된 음식 밈이자, AI에서 경계가 애매한 분류 문제를 설명할 때 자주 쓰이는 단골 예시죠? Jev 테스트에서 이 질문을 첫 번째로 고른 것도 기준 없이는 애매하게, 기준을 주면 그에 따라 확 달라지는 모습을 보여주지 않을까 해서였구요.

기준을 따로 주지 않고 실행했을 때는, 이미지에 보시다시피 58% true가 나옵니다. ‘그렇다’ 쪽으로 조금 기울었지만, 자신 있게 단정할 정도는 아닙니다.

이번에는 샌드위치의 기준을 넣어 봤습니다. 고기나 치즈, 채소 같은 속재료가 전분질의 바깥 구조 사이에 놓인 음식이라는 정의입니다. 빵이 없거나, 빵 한 장만 쓰거나, 토르티야·웨이퍼·쿠키처럼 빵이 아닌 것으로 감싼 경우는 ‘아니요’라고 판단하라는 기준도 붙였습니다.

그랬을 때, 결과는 77%로 올라갑니다.

입력 대상을 아이스크림 샌드위치로 바꾸니까 33%가 나왔는데요, 이름에 ‘샌드위치’가 들어 있다는 이유만으로 거기에 끌려가지 않고, 앞에서 정한 기준에 맞춰 다시 판단한 거라고 생각할 수 있겠죠.

중요한 건, 여기서 58%가 77%로 올랐다는 게 ‘정확도 개선’으로 이해하면 안 된다는 겁니다. 정답을 맞힌 비율이 아니라, 기준을 더 구체적으로 주었을 때 같은 질문에 내놓은 확률이 달라진 것이니까요.

이 짧은 시연을 통해서 Jev의 사용법을 쉽게 이해할 수 있었습니다. 정보를 넣고, 질문과 판단 기준을 정하고, 소프트웨어가 쓸 수 있는 확률을 받습니다.

두 번째 예시는 좀 더 실질적이라는 느낌이 드실 겁니다.

한 사람이 ‘와이파이가 작동하지 않는 문제’를 시스템에 신고했다고 해 보죠. 그런데 이 신고 내용에 대해서 일주일 넘게 답을 받지 못해서, 이 사람이 ‘내가 전에 한 신고가 어떻게 처리되고 있는지’ 다시 묻는 시나리오입니다.

(아마도) “내가 이전에 문의한 와이파이 문제가 어떻게 처리되고 있나요?”라는 내용의 메시지를 State로 넣고, Jev에게 네 가지 질문을 동시에 던졌습니다 - 이 요청의 우선순위가 뭔지, 어느 팀의 업무인지, 특정 마감이나 일정이 언급되었는지, 그리고 200개 정도의 도구들 중에 어떤 도구를 사용해야 하는지 하는 질문이었습니다.

Jev가 내놓은 답은 이렇습니다:

일반적인 LLM의 경우라면 이 네 질문에 하나씩 순서대로 답을 아마 했을 텐데, Jev는 한 번의 요청에 이 내용들을 다 넣고 병렬로 계산해서 각각 확률·선택지 형태의 값으로 돌려줬습니다. 앞에서 설명한 "여러 답을 병렬로 계산해서 타입값으로 돌려준다"는 Jev의 핵심 동작 방식이 여기서 실제 사례로 드러납니다.

단어만 언뜻 보면, 와이파이를 고치는 도구를 고르기 쉬울 수 있지만, 사용자가 지금 묻는 것은 ‘장애 해결 방법’이 아니라 ‘이미 제출한 신고의 처리 상태’죠. 작은 차이처럼 보이지만, 이런 선택이 수십 번 이어지는 에이전트에게는 작업의 방향을 바꾸는 차이이기도 합니다.

물론 지금 이 과정에서 Jev가 티켓을 직접 조회한 건 아니고, 어떤 도구를 써야 할지 골랐을 뿐이죠. 실제 실행은 이 결과를 넘겨받은 소프트웨어가 하게 될 겁니다. 화면을 JSON 보기로 바꾸면 같은 결과가 구조화된 데이터로 나타납니다. 사람에게 읽히는 문장을 만드는 대신에, 프로그램이 조건문과 분기에 바로 넣을 수 있는 값을 주는 셈입니다.

TypeSafe에서는 Jev가 ‘긴 답을 토큰 단위로 이어 쓰는 대신에 여러 판단을 병렬로 산출한다’고 설명합니다. 다만, 형식이 항상 맞는 것과 판단이 항상 옳은 것은 다른 이야기라서, 기준을 잘 만들고 실제 사례로 시험하는 일은 여전히 사람의 몫입니다.

저희는 Jev와 Codex를 비교해 보고 싶어졌습니다.

그래서, Jev 콘솔에 있는 Quick Start(Jev API 호출 방법 설명서) 내용을 Codex에게 넘기고, "Jev와 LLM의 가장 큰 차이를 보여주고 싶은데 뭘 만들 수 있을까?"라고 물어봤습니다.

그래서 Codex가 'Model Lab'이라는 이름으로 ‘같은 보도자료와 같은 판단 기준을 Jev와 Codex에 동시에 주고, 둘의 답을 나란히 비교하는 도구를 만들었습니다. 여덟 개 예제가 준비돼 있지만, 영상에서는 '잘못된 헤드라인을 정정한 발표문' 하나만 실행합니다.

이 보도자료는 문서 한 장 안에 원래 주장과 정정 내용이 함께 담겨 있는 형태입니다. 가상의 제품 'Relay'는 처음엔 "누구나 쓸 수 있고 가중치도 다운로드할 수 있다"고 소개됐지만, 같은 문서 뒤쪽에 "실제로는 초대받은 사용자만 접근할 수 있고, 가중치는 비공개"라는 정정 문구가 이어집니다. "SupportBench에서 92%를 기록해 KeywordRouter의 86%를 앞섰다"는 성능 수치는 두 버전 모두에 남아 있구요.

Jev와 Codex는 이 문서 하나만 읽고 세 가지를 판단해야 합니다.

까다로운 지점은 두 가지입니다. 첫째, 문서 앞쪽에 남아 있는 정정 전 문구("누구나 쓸 수 있음")에 낚이지 않고, 뒤쪽의 정정된 내용만 최신 사실로 따라가야 합니다. 둘째, "92% vs 86%"처럼 숫자가 있다는 사실과, 그 숫자를 뒷받침하는 비교 조건(누구와, 어떤 데이터셋으로 비교했는지)이 명시돼 있다는 사실은 서로 다른 문제라서, 이 둘을 구분해 낼 수 있는지도 함께 시험합니다. 정답표는 미리 만들어 두되, 두 모델에는 보여주지 않았습니다.

둘 다 세 가지 질문에 정확한 답을 내놨습니다. Jev는 0.20초, Codex는 4.61초가 걸렸고, 입력 토큰은 각각 616개와 15,984개였습니다. 이 사례만 놓고 계산하면, 시간은 약 23배, 입력 토큰은 약 26배 차이입니다. (출력 토큰은 과금을 안 한다고 했으니 비용에 대한 시사점은 더 커지겠죠?)

숫자의 차이가 꽤 커 보이죠? 하지만 조건과 셋업을 함께 봐야 합니다.

우선, Jev 쪽은 API 왕복 시간이고 Codex 쪽은 전체 실행 시간입니다. 같은 글과 규칙을 받았지만 도구가 구성한 전체 입력의 크기도 다릅니다. 여덟 개 예제 전체를 돌린 결과도 아니구요. 그러니까 이 실행 사례에서, 범위가 좁고 구조화된 판단의 경우에 Jev와 Codex의 비용 구조가 얼마나 달라질 수 있는지 예시적으로 보여준다고 할 수는 있지만, 모든 작업에서 Jev가 23배 빠르다거나 Codex보다 정확하다는 증거는 절대 아니라는 점 말씀드립니다.

오히려 더 흥미로운 질문은 사실 따로 있습니다: "코드를 짜는 일"과 "그 코드가 다음에 뭘 할지 고르는 일"에, 꼭 같은 모델을 써야 할까요?

튜링포스트 팀의 테스트 결과를 보면, 7만여 토큰을 사용했는데 비용은 1센트도 안 나왔다고 합니다. 물론, 이 수치도 현재의 일반 요금표를 설명하는 수치라기보다 이번 체험에서 확인한 사용료라는 점은 말씀드리구요. 그래도 작은 판단을 하기 위해서 아주 모델을 자주 호출하는 시스템에서 가격이 왜 중요한지는 충분히 드러납니다.

이렇게 빠른 속도를 얻기 위해서, Jev는 프리 텍스트를 생성하는 능력을 포기한 셈입니다. 어떤 도구를 쓸지 물을 수는 있지만, 그 도구의 코드를 작성해 달라고 할 수는 없습니다. 앞에서 본 Noul·Choice·Score 등처럼 답의 범위를 사람이 미리 정해야 합니다.

그래서, Jev는 Codex와 경쟁하는 포지셔닝이라기보다는, 다른 역할을 맡기 위한 모델로 만들어졌다고 생각하는게 맞다고 봅니다. 애플리케이션 코드를 작성하는 일에는 추론과 생성이 필요하지만, 어떤 요청에 정보가 빠졌는지 확인하고, 다음 행동을 고르고, 사람에게 넘길지를 결정하는 일 같은 건 훨씬 그 ‘범위가 좁은 판단’이잖아요?

에이전트를 만들 때 “어떤 모델 하나를 고를 것인가”만 물어서는, 이렇게 의미있는, 때로는 중요한 구분이 필요하다는 점을 놓치게 될 겁니다. 더 실용적인, 진짜 필요한 질문은, “이 작업에서 생성이 필요한 곳은 어디이고, 선택만 잘하면 되는 곳은 어디인가”겠죠.

자, 여기서 잠깐 디오고 알메이다의 연구 이력을 살펴볼 필요가 있습니다. InstructGPT가 풀려고 했던 문제는 "그럴듯한 문장을 이어 쓰는 능력"과 "사용자의 의도를 따르는 능력" 사이의 갭이었습니다. 사람들이 좋은 답의 예시를 직접 만들고 여러 응답의 선호도를 평가하면, 그 피드백을 학습에 반영하는 방식이었죠. 논문에 따르면 1.3B 크기의 InstructGPT 응답이 사람 평가에서 175B GPT-3 응답보다 더 선호도가 높았어요 - 모델을 크게 키우는 것과 사람이 원하는 답을 하도록 훈련하는 것은 서로 다른 문제였다는 겁니다.

다음 질문은 자연스럽게 이어지죠 - 사람에게 유용하게 ‘말하는’ 모델을 만들었다면, 이제 소프트웨어가 그 판단을 믿고 행동하게 하려면 뭐가 더 필요할까요?

여기서 앞서 이름만 나온 RLCD(Reinforcement Learning for Calibrated Decisions)가 다시 등장합니다.

RLHF는 "사람이 선호하는 응답"을 보상 기준으로 삼고, RLVR는 "테스트 통과 여부"처럼 정답을 코드로 검증할 수 있는 결과를 보상 기준으로 삼습니다. 둘 다 최종 결과물은 사람이 읽는 문장입니다.

RLCD는 여기서 한 걸음 더 나갑니다. 문장을 잘 쓰도록 보상하는 게 아니라, 확률 자체가 정확하도록 훈련합니다. 예를 들어 모델이 "이 답이 맞을 확률 80%"라고 냈다면, 실제로 그런 사례들을 1,000번 모았을 때 그중 약 800번은 정말 맞아야 한다는 식이죠. 이렇게 되면 소프트웨어는 그 확률 값을 그대로 믿고 "80% 이상이면 자동 처리, 애매하면 사람에게 넘기기" 같은 분기를 짤 수 있습니다. 즉 RLHF·RLVR가 "더 나은 문장"을 목표로 훈련한다면, RLCD는 "더 믿을 수 있는 숫자"를 목표로 훈련하는 셈입니다. (물론, 어느 값과 Threshold에서 자동 처리할지 같은 결정은 업무에 맞춰서 따로 테스트를 해야 할 겁니다. 확률 보정은 예측 집단에서 나타나는 성질이지, 개별적인 답이 맞다는 보증은 아니니까요)

물론, 이 아이디어 자체가 완전히 새로운 건 아닙니다. 확률 예측의 품질은 오래전부터 일기예보 같은 곳에서도 다뤄졌고, 신경망의 확률을 얼마나 믿을 수 있는지도 꾸준히 연구돼 왔습니다. 자연어로 분류 기준을 설명하는 방식 역시 Jev보다 훨씬 먼저 나온 것이구요.

그래서, Jev의 주장은 "분류를 발명했다"는 게 아니라, 이미 익숙한 작업을 에이전트 안에서 많이 반복해도 될 만큼 빠르고 저렴하게 만들고, 그 판단의 불확실성을 소프트웨어가 쓸 수 있는 정도에 이르게 하겠다는 거라고 생각합니다.

실제 개발자들이 써본 사례를 보면 이 판단이 더 잘 와닿습니다.

첫 번째는 Vercel의 ‘명령 안전성’ 검토 사례입니다. 에이전트가 명령어를 하나 실행할 때마다 다른 모델이 "이거 안전한 명령이야?"를 확인합니다. 그런데 이 확인이 조금만 느려도, 작업이 반복될수록 지연 시간은 엄청나게 늘어날 겁니다.

Vercel CEO 기욤 로시(Guillermo Rauch)는, 자기 회사의 도구 fx가 모든 명령에 이런 안전성 검토를 돌리는데, 지금은 GPT-5.6 Luna를 쓰고 있다고 밝혔습니다. 그러면서 "Jev로 바꾸면 최대 18배(p95 기준) 빠르고 더 정확하다"고 X에 직접 썼습니다. "곧 기본값으로 바꿀 가능성이 높다"고도 했지만, 아직 확정된 사항은 아니라고 선을 긋기는 했습니다.

실제 평가는 이렇게 진행됐습니다. 정답이 정해진 사례 70개를, 모델마다 세 번씩 돌렸습니다. 총 210번 판단한 거예요. Jev는 207/210건(98.6%) 맞혔고, GPT-5.6 Luna는 203/210건(96.7%) 맞혔습니다. 속도는 중앙값 기준 312ms 대 1,458ms, 가장 느린 5% 구간(p95) 기준으로는 374ms 대 6,583ms였습니다.

그래서, 여기서 "최대 18배"라는 말은 평균 속도가 아니라, 가장 느렸던 케이스들(p95)만 비교했을 때 나온 숫자입니다. 그냥 중앙값끼리 비교하면 4.7배 정도예요. 실제로 이 실험을 한 Vercel의 Pranit(@fazxes)도 "5~18배 빠르고 더 정확하다"고만 밝혔을 뿐, 자세한 데이터를 따로 공개하진 않았습니다. 한 팀이 자기네 명령어 검토 작업으로 해본 결과라, 다른 상황에서도 똑같이 나올지는 알 수 없지만, 에이전트가 작업 중에 수십 번씩 호출하는 안전성 검토를, 왜 굳이 작은 판단 전용 모델에 맡기려 하는지는 잘 보여줍니다. 참고로 Jev는 9월 16일부터 Vercel AI Gateway에도 정식으로 올라와서, 이제 데모가 아니라 실제 서비스에서도 쓸 수 있게 됐습니다.

두 번째 사례는 OpenCode의 Dax(@thdxr)가 공유한 Filip(@Neriousy)의 브라우저 사용 프리뷰입니다. Jev와 OpenCode의 브라우저 사용 CLI를 합친 데모예요.

브라우저로 뭔가 할 때는 클릭 한 번으로 끝나지 않죠 - 뭘 누를지 고르고, 결과를 확인하고, 다음에 뭘 할지 또 정해야 합니다. 아직 프리뷰 단계라 완성된 건 아니지만, 문의에 대한 분류 같은 작업보다 더 길게 이어지는 작업에서도 Jev가 쓰일 수 있다는 걸 보여주는 장면입니다. 이 게시물에는 "Jev가 정확히 어느 부분을 대신하는지 잘 모르겠다"는 반응도 달렸는데, 이런 초기 프리뷰에서 흔히 나오는 반응입니다.

Jev라는 이름은 경제학자 윌리엄 스탠리 제번스(William Stanley Jevons)와 '제번스의 역설'에서 따왔습니다. 뭔가를 쓰는 효율이 좋아지면 오히려 절약하게 되는게 아니라 전체 사용량이 늘어난다는 역설이에요. 판단하는 데 드는 비용이 확 싸지면, 지금은 굳이 AI까지 안 불러도 되던 작은 결정까지도 다 AI한테 맡기게 될 거라는 기대가 이 이름에 담겨 있습니다.

그럼 다시 처음 질문으로 돌아가서, 이미 좋은 모델이 이렇게 많은데, 뭐가 더 필요할까요?

에이전트가 코드를 아무리 잘 써도, 잘못된 도구를 고르면 거기서 멈춰버리게 됩니다. 실행 작업의 결과를 잘못 읽어도 엉뚱한 방향으로 가죠. 작업 하나를 끝내는 동안 이런 작은 판단이 수십, 수백 번 반복될 수 있어요. "한 번 멋진 답을 내놓는 것"과 "끝까지 믿고 맡길 수 있는 것" 사이에는 여전히 큰 갭이 있습니다.

Jev가 노리는 게 바로 이 빈틈이라고 생각합니다. 뭐든 만들어내는 큰 모델을 내놓은 게 아니라, 그 모델이 짜놓은 시스템 안에서 계속 반복되는 자잘한 판단을 대신 Jev가 맡으면 어떻겠느냐 제안하는 거예요. 그래서 "Codex가 만들고 Jev가 고른다"는 조합이 의미가 있는 겁니다.

물론 앞에서 짚었던 문제들은 여전히 남아 있고, 이번에 본 것만으로는 Jev의 확률이 실제 서비스 환경에서도 잘 맞는지, 다른 종류의 분류 작업에서도 속도와 정확도가 그대로 유지되는지까지는 아직은 알 수 없어요. 이건 앞으로 더 많은 독립적인 검증과 실제 사용 사례를 통해서 우리가 판단해 봐야 할 문제입니다.

다만 Jev는 우리가 지금까지 해 온 한 가지 질문만큼은, 그 방향만큼은 확실히 바꿔야 한다는 생각을 하게 해 줍니다. 바로 "제일 똑똑한 모델이 뭐야?"가 아니라, "이 일을 끝내려면 어떤 판단을, 어떤 모델들한테 나눠서 맡기면 좋을까?"하는 질문을 해야 한다는 생각이요.

여러분의 업무에서는 어떤 자잘한 판단이 가장 자주 반복되나요? 그 판단에 드는 시간과 비용이 지금보다 훨씬 줄어든다면, 어떤 걸 더 많이, 더 새롭게 자동화할 수 있을까요?

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