TL;DR

  • Vercel 유료 AI Gateway 팀의 거의 13%가 출시 첫 24시간 안에 Jev를 사용했으며, 첫날 사용 비중이 이전 어떤 모델보다 두 배 이상 높아 출시 당일부터 개발자들이 코드를 작성하는 제품임.
  • TypeSafe는 나란히 비교하는 시연으로 Jev의 속도 차이와 용도를 보여주고, 사용자가 결과와 한계를 직접 판단할 수 있게 함.
  • Jev는 텍스트 생성이 아니라 코드가 활용할 선택, 점수, 확률을 반환하며, 기존 워크플로의 의사결정 단계를 겨냥함.
  • 출시 첫 주 사용자들이 에이전트 도구부터 컨텍스트 관리 실험까지 프로젝트를 만들어 공유했으며, 각 프로젝트가 Jev의 활용 사례를 보여주는 시연물이 됨.
  • 이해하기 쉽고, 시도하기 쉽고, 입증하기 쉽고, 통합하기 쉽고, 공유하기 쉬운 제품 경험에 계획된 배포를 결합한 출시 방식임.

Jev 출시의 흐름

  • Vercel 유료 AI Gateway 팀 중 거의 13%가 Jev 출시 첫 24시간에 사용했으며, 이는 그전까지 출시된 어떤 모델의 첫날 사용 비중보다 두 배 이상 높은 수치임. 출시 첫날부터 개발자들이 코드를 작성하는 상황임.
  • 제품 출시를 계획한다면 사람들이 가치를 이해하고, 빠르게 경험하며, 다른 사람에게 보여줄 이유를 제품에 어떻게 담을 수 있는지가 질문임.
  • Jev 출시에서 읽히는 순서는 강력한 제품 가설 → 입증 가능한 가치 → 사용자 제작 증거 → 계획된 확산임.

시연이 먼저였음

  • TypeSafe는 나란히 비교하는 시연이 Jev를 만들기로 결정하는 데 도움이 됐다고 밝힘. 팀은 출시를 계획하기 전부터 차이를 확인함.

개발자들이 이미 가진 문제

  • 개발자에게는 의사결정을 내리는 소프트웨어가 필요하지만, 개발자들이 사용하는 시스템은 텍스트 생성용으로 만들어져 있음. Jev는 컨텍스트와 범위가 정해진 질문을 받아 코드가 활용할 수 있는 선택, 점수 또는 확률을 반환함.
  • 제품에 관심을 가질 이유는 이미 존재함. 앱 어딘가에는 무언가를 라우팅하거나 점수를 매기거나 확인하는 단계가 있으며, 이 작업이 더 빠르고 저렴하며 제어하기 쉬워질 수 있는지가 질문임.
  • 분류는 새로운 개념이 아니지만, 모든 요청에서 실행하기엔 너무 느렸던 확인 작업이 갑자기 충분히 빨라질 수 있음. 이는 “새 모델이 나왔으니 용도를 알아서 찾아보라”는 접근보다 나은 진입점임.
  • 지연 시간은 설명하기 어렵지만 보여주기는 쉬움. 두 출력을 나란히 놓고 한쪽이 끝나는 동안 다른 쪽은 계속 처리 중인 모습을 보여줄 수 있음.
  • 시연에서는 TypeSafe와 GPT-5.6 Terra를 비교함. 아래 벤치마크에서는 GPT-6 Luna를 사용함.
  • 작은 벤치마크에서 Jev의 중앙 응답 시간은 약 0.27초, GPT-6 Luna는 약 0.9초였으며, 해당 실행에서 정확도는 비슷한 수준임. Jev의 비용도 더 낮았지만, 가장 인상적이었던 점은 속도임.
  • 각 의사결정에서 약 600밀리초를 절약하며, 파이프라인에서는 많은 의사결정이 이뤄짐.
  • 시연에는 짧은 입력이 사용됐으며 Jev에 적합한 조건임. TypeSafe는 이 점을 밝혔고, 문서에는 Jev가 어려움을 겪는 작업도 명시돼 있어 결과를 보고 한계를 판단할 수 있음.
  • 시연을 보는 것에서 실제로 사용해보는 것까지의 거리가 짧다는 점이 중요함. 몇 분 안에 시연을 보고, 플레이그라운드에서 Jev를 사용하고, 결과를 다른 사람에게 보낼 수 있음. 출시 당시 사람들이 여전히 관심을 두는 동안 확인하고 공유할 수 있는 주장이 제시됨.

사용자가 다음 시연을 만듦

  • 첫 주 안에 에이전트 도구부터 컨텍스트 관리 실험까지 여러 프로젝트가 만들어져 공유됐으며, Ben Tossell은 그중 100개를 모음.
  • Steel의 도움을 받아 Jev가 어떤 웹사이트든 혹평하는 시연을 만듦. 누구도 제작을 요청하지 않았으며, 제품 자체가 시도하는 일을 재미있게 만듦.
  • 초기 제작자에게는 참여할 이유가 두 가지 있었음. Jev로 문제를 해결할 수 있고, 자신의 작업으로 사람들을 끌어들이는 무언가를 만들 수도 있었음. 좋은 시연은 다른 사람들이 Jev를 발견하도록 돕는 동시에 제작자의 독자층을 키우는 데도 도움이 될 수 있음.
  • 사람들이 작은 앱을 만들고 보여줬으며, 각 앱은 다른 사람에게 Jev의 기능을 이해할 방법을 제공함.
  • 제품에서 공유 가능한 산출물을 만들 수 없다면(엔터프라이즈 제품 등), 재현 가능한 벤치마크, 참조 구현, 승인된 사례 연구처럼 이에 해당하는 방식을 찾을 수 있음. 공개 공유가 맞지 않는 상황에서 이를 강요하지 않는 것이 원칙임.

기존 워크플로에 들어맞음

  • Jev는 이미 존재하는 작업 단계에 들어맞으므로 일하는 방식을 바꾸지 않고 도입할 수 있음.
  • 문서에는 Jev가 코딩 에이전트의 모델을 대체하지 않는다고 명시돼 있음. 평소 사용하던 코딩 에이전트로 Jev를 호출해 범위가 정해진 의사결정을 내리는 소프트웨어를 만들 수 있음. 이 한 문장이 “챗봇처럼 써봤는데 쓸모없다”는 평가를 상당수 막음.
  • 플랫폼에 들어가기 전에 Jev는 “Jev가 메시지를 작성할 수 있나요?”라고 묻고, 예 또는 아니요로 답하게 함.
  • 이 질문은 온보딩 단계로 유용함. 제품에 도달하기 전에 질문 하나로 사용자를 파악하고 기대를 맞출 수 있음. 사용자는 무엇을 시험할지, 유용한 결과가 어떤 모습일지 더 명확히 알고 시작함.
  • 제품이 익숙하지 않은 방식으로 작동한다면 클릭 한 번을 없애는 것보다 좋은 설명 하나가 더 가치 있음.

첫 번째 유용한 결과

  • 첫 번째 유용한 결과는 실제로 활용할 수 있는 의사결정임.
  • Jev의 빠른 시작 예시는 지원 메시지가 얼마나 긴급한지 묻고, 답변은 어떤 메시지에 먼저 주의를 기울일지 결정하는 데 명확히 활용됨. 개발자는 그 결정이 타당한지 판단하고 코드에서 어떻게 사용할지 확인할 수 있어 첫 실행에 목적이 생김.
  • 목표는 온보딩 노력의 최소화가 아니라, 처음으로 정확하고 의미 있게 사용하는 데 필요한 노력의 최소화임.

배포도 실제 작업이었음

  • Doomers가 출시 전략과 확산을 맡고, 스튜디오가 영상을 제작했으며, 발표 내용은 엔지니어·창업자·크리에이터 80~100명에게 사전 공유됨.
  • 창업자는 ChatGPT의 기반 시스템을 만드는 데 참여한 경험이 있으며, 이는 이름이 알려지지 않은 회사의 이례적인 주장을 사람들이 진지하게 받아들일 이유가 됨.
  • Diogo Almeida(@CompleteSkeptic)의 Jev 출시 게시물 원본 날짜는 2026년 9월 15일임.
  • 각 참여자는 서로 다른 내용을 보여줬으며, 이는 제품이 각자에게 서로 다른 시연거리를 제공했기 때문임.
  • 제품 작업과 출시 작업이 만나는 지점은 제품이 사람들이 시연할 무언가를 제공하고, 계획된 배포가 그 시연을 사람들에게 보여준다는 점임.
  • 인원 규모를 그대로 따라 할 필요는 없음. 같은 칭찬을 반복 게시하는 많은 계정보다 실제 접근 권한을 가진 신뢰도 높은 소규모 그룹이 더 효과적임.

공식

  • 이해하기 쉬움 → 시도하기 쉬움 → 입증하기 쉬움 → 통합하기 쉬움 → 공유하기 쉬움임.