한눈에

Claire Vo가 egghead.io의 John Lindquist를 불러, TypeSafe의 결정 모델 Jev로 만든 실전 데모 8개를 돌린 에피소드입니다. 챗봇이 아니라 분류·라우팅·점수에 쓰는 엔진이라는 점이 처음부터 못 박혀 있습니다.

DevDay Decisions API 이야기와 맞닿지만, 키노트 재탕은 아닙니다. “언제 LLM 대신 Jev를 끼우면 체감이 바뀌는지”를 코드·데모로 보여줍니다.

배경

Jev는 텍스트를 길게 쓰지 않습니다. 정해진 선택지·라벨·점수를 거의 공짜·초저지연으로 내놓는 System One형 모델로 소개돼 왔습니다. 생성형 LLM의 앞에 두거나, 에이전트 루프 안에 라우터로 넣는 그림입니다.

Lenny 쪽에서는 이미 Jev 입문편을 올린 적이 있습니다. 이번은 “그래서 뭘 만들었냐”에 가깝습니다.

무슨 일 / 핵심 내용

데모 목록이 에피소드의 뼈대입니다. 실시간 음성 할 일 앱 — 말이 끝나자마자 분류·실행. 영어 한 줄을 장바구니 함수 이름으로. 지저분한 레코드 중복 병합과 신뢰도 점수. 한 입력으로 앱 깊숙한 화면까지 보내는 다단 라우터.

체스 대결은 속도·비용 비교용입니다. 낮은 추론 LLM과 붙여 보면, 수가 제한된 결정 문제에선 Jev 쪽이 체급이 다르게 느껴진다는 톤입니다. 위키피디아 “철학으로 가는 길” 매퍼, 멀티에이전트 충돌 회피, 실시간 발표 코치까지 이어집니다.

설계 힌트도 분명합니다. DOM 조작을 무한 캔버스가 아니라 유한한 결정 집합으로 보라는 것. 한 번의 Jev로 부족하면 다단 분류를 잇고, 열린 문장 생성이 필요하면 그때 일반 모델을 부르라는 역할 분담입니다.

숫자·스펙

왜 중요한가

“전부 프론티어 LLM”으로 돌리던 루프에서, 싸고 빠른 결정 레이어를 빼는 법을 손으로 보여줍니다. Decisions API가 Luna 위에 얇게 얹힌 것과 같은 문제의식을, 빌더 시선으로 구체화한 편입니다.

에이전트가 늘수록 매 스텝 생성 비용을 깎는 패턴이 필요합니다. 그 자리를 Jev 같은 모델이 노린다는 메시지가 선명합니다.

Lindquist의 맥락도 중요합니다. egghead로 개발자 교육을 오래 해온 사람이, 지금은 mega.dev처럼 에이전트로 “진짜 일”을 시키는 프로그램을 만들고 있습니다. 그래서 데모가 토이 프롬프트가 아니라, 음성→실행, 장바구니 함수, 레코드 병합처럼 제품에 바로 붙을 법한 조각입니다.

신뢰도 점수와 멀티모델 검증 구간도 반복해서 나옵니다. Jev가 싼 만큼, 애매하면 한 번 더 돌리거나 다른 모델로 교차 확인하는 패턴이 현실적이라는 이야기입니다. “한 방에 완벽한 답”보다 “싸게 여러 번”이 이 체급의 미학입니다.

OpenAI Decisions API가 Luna 위에 얇게 올라온 것과 비교하면, Jev는 생성 능력을 거의 버리고 결정만 남긴 극단입니다. 둘 다 System One 자리를 노리지만, 캘리브레이션·RLCD·출력 스키마 강제 같은 디테일은 제품마다 다릅니다. 이 에피소드는 그 차이를 이론이 아니라 데모로 보여 주려는 쪽에 가깝습니다.

그래서 뭐

프로덕션에 넣을 후보는 라우팅·가드레일 분류·중복 판정처럼 출력이 구조화된 곳입니다. 긴 문서 작성·모호한 기획은 여전히 생성 모델 자리입니다.

데모를 그대로 복제하기보다, 자기 제품의 “결정 집합”을 먼저 적어 보는 쪽이 다음 스텝입니다.