Jev AI — 판단만 빠르게 하는 AI가 나온 이유 (1/3)

모든 요청에 큰 모델이 필요한 건 아니다

최근 개발자들 사이에서 Jev라는 이름이 자주 보인다. TypeSafe AI가 2026년 9월에 공개한 모델인데, 처음 설명을 봤을 때는 좀 낯설었다. "AI 모델인데 글을 안 쓴다"는 게 무슨 말인가 싶었다.

노가리를 만들면서 겪은 문제를 떠올리면 이해가 빠르다. 노가리에는 댓글이 하나 달릴 때마다 거쳐야 하는 판단이 몇 가지 있다.

개인정보가 포함돼 있는가
욕설이나 혐오 표현인가
스팸인가
사람이 직접 검토해야 하는가

지금은 정규식 필터로 1차로 거르고, LLM 스크리닝으로 2차로 거른다. 그런데 이 2단계가 댓글이 올라올 때마다 Claude API를 호출하는 구조다. 사실 "이 댓글이 위험한가?"라는, 몇 글자 안 되는 판단을 위해 큰 모델 하나를 통째로 깨우는 셈이다. TypeSafe도 비슷한 고민을 한 것 같다.

텍스트를 만드는 모델과 판단만 하는 모델

일반 LLM은 결과가 JSON이든 뭐든 결국 토큰을 순서대로 생성해서 만든다. {"category": "spam", "confidence": 0.9}라는 짧은 결과를 내놓을 때도, 모델 내부에서는 토큰이 하나씩 차례로 뽑힌다. 출력 형식을 스키마로 제한할 수는 있어도, 본질은 여전히 생성형이다.

Jev는 반대 방향에서 접근한다. 처음부터 "정해진 선택지 중 하나를 빠르게 고르고, 그 판단에 대한 확률까지 반환"하는 것 자체를 목적으로 설계된 모델이다. 글자를 순서대로 뽑는 대신, 여러 판단을 한 번에 계산해서 내놓는 구조라고 TypeSafe는 설명한다.

	일반 LLM	Jev
출력 방식	토큰을 순차 생성	여러 판단을 동시 계산
목적	글 생성, 추론	분류 · 라우팅 · 채점
결과물	텍스트 (구조 제한 가능)	타입이 정해진 확률적 결정
적합한 작업	코드 작성, 문서화, 리서치	분류, 모더레이션, 검증

표로 정리하고 나니 노가리의 댓글 필터 2단계가 사실 Jev가 노리는 자리와 거의 같다는 걸 알았다. "이 댓글을 신고 큐로 보낼까 말까"는 복잡한 추론이 필요한 문제가 아니라, 몇 개 조건의 조합일 뿐이다.

Choice, Noul, Score — 세 가지 판단 단위

Jev가 쓰는 판단 방식은 크게 세 가지로 나뉜다.

Choice — 여러 선택지 중 반드시 하나를 고른다. 노가리로 치면 "이 방을 어느 카테고리(인물·물건·브랜드·사건·기타)로 분류할까" 같은 문제다.
Noul — 독립적인 Yes/No 판단. 하나의 입력에 여러 조건이 동시에 성립할 수 있을 때 쓴다. "개인정보 포함?", "욕설?", "스팸?"을 각각 따로 물어보는 식이다. 노가리 댓글 중에는 "욕설이면서 동시에 개인정보도 포함"하는 경우가 실제로 있는데, 지금 구조에서는 이걸 하나의 분류 라벨로 뭉뚱그리기 어렵다. Noul은 이런 다중 조건을 애초에 분리해서 판단하자는 접근이다.
Score — 정도를 평가한다. 위험도, 품질, 우선순위처럼 Yes/No로 끊기 애매한 값이다.

셋의 공통점은 설명문이 아니라 소프트웨어가 바로 쓸 수 있는 결정을 반환한다는 것이다. "이 댓글은 욕설로 보입니다"가 아니라 {profanity: 0.91}을 돌려주는 식이다.

지금 노가리 필터는 이렇게 생겼다

지금 노가리의 댓글 필터를 단순화하면 대략 이런 흐름이다.

comment
  ↓
regex_pii_filter(comment)        # 1단계: 정규식으로 명백한 전화번호·이메일 패턴만 거름
  ↓ (걸리지 않은 것만 통과)
llm_screen(comment)              # 2단계: Claude에게 "이 댓글 올려도 되나?" 통째로 질문
  ↓
approve / reject / flag_for_review

문제는 2단계다. 욕설 하나를 거르든, 개인정보를 거르든, 스팸을 거르든 전부 같은 LLM 호출 하나에 몰아넣고 있다. 댓글이 짧든 길든, 판단이 쉬운 케이스든 애매한 케이스든 상관없이 매번 같은 비용과 레이턴시가 붙는다. 트래픽이 지금보다 늘어난다면 이 2단계가 먼저 병목이 될 거라는 건 이미 알고 있었다. 다만 "그럼 뭘로 대체하지?"에 대한 답이 마땅치 않았는데, Jev 같은 판단 전용 모델이 그 틈을 메울 수 있겠다는 생각이 들었다.

에이전트 시대에 작아지는 판단 하나하나의 무게

사실 이 문제는 노가리에만 해당하는 게 아니다. 에이전트형 AI가 코드를 짜고, 검색하고, Tool을 호출하는 과정을 들여다보면, 그 사이사이에 "이 요청은 A인가 B인가", "이 결과를 바로 써도 되나" 같은 자잘한 판단이 수십 번씩 끼어 있다. 큰 작업 하나를 완수하기 위해 거치는 작은 판단의 개수가 많아질수록, 그 판단 하나하나를 얼마나 싸고 빠르게 처리하느냐가 전체 시스템의 체감 속도를 결정한다. 지금까지는 이런 작은 판단도 결국 Claude나 GPT 같은 모델에게 "그냥 다 물어보는" 방식으로 때워왔는데, 에이전트가 처리하는 작업 단위가 잘게 쪼개질수록 이 방식의 비효율이 누적되어 드러나는 것 같다.

왜 지금 이런 모델이 나왔을까

에이전트형 AI가 늘면서 "코드를 짜거나 글을 쓰는" 큰 작업 사이사이에 "이거 맞아 틀려?" 수준의 작은 판단이 엄청나게 많아졌다. 이 작은 판단까지 전부 Claude나 GPT 같은 모델에게 맡기면 매번 레이턴시와 비용이 붙는다. 그렇다고 if문으로 다 처리하기엔 사용자 입력이 너무 다양하다. Jev는 정확히 그 사이 — if문으로는 애매하고, Frontier 모델을 쓰기엔 아까운 — 영역을 노린다.

다음 편에서는 이 판단 모델이 실제 에이전트 아키텍처 안에서 어떤 자리에 들어가는지, 그리고 노가리나 매치다 같은 내 프로젝트에 적용한다면 어디부터 손댈 수 있을지를 정리해본다.