Jev와 System One 모델: 애플리케이션 설계 활용 사례

지난 3년 동안 거의 모든 “여기에 지능을 좀 넣어 달라"는 문제에 대한 답은 한결같았습니다. 대규모 언어 모델을 호출하는 것이었습니다. 작동은 합니다. 하지만 종종 잘못된 도구입니다. 놀라울 만큼 많은 프로덕션 AI 지출이, 출력 전체가 곧바로 불리언, 열거형, 큐 이름, 또는 1~5점 점수로 축소되어 버리는 LLM 호출로 흘러갑니다. 개방형 생성에 비용을 지불하고, 토큰을 몇 초씩 기다리고, JSON을 파싱한 다음, 그 대부분을 버립니다. 게다가 애초에 언어 생성과는 전혀 무관했던 작업을 위해 LLM의 최악의 특성들, 즉 지연, 비용, 그리고 확신에 차 지어낸 답변의 가능성까지 함께 떠안게 됩니다.

새로운 부류의 모델이 바로 그 불일치를 정면으로 겨냥합니다. 2026년 9월 15일, TypeSafe AI는 스스로 System One 모델이라 부르는 것의 첫 번째인 Jev를 출시했습니다. 이것이 주목할 만한 이유는 더 나은 챗봇이어서가 아닙니다. 애초에 대화 자체를 할 수 없습니다. 오히려 애플리케이션 아키텍처에 진정으로 새로운 구성 요소를 도입하기 때문입니다. 이 글은 Jev가 무엇이고, 어디에 들어맞으며, 이를 책임감 있게 설계에 반영하는 방법에 대한 실무 가이드입니다. (한 가지 먼저 짚고 넘어가자면, TypeSafe의 Jev는 Meta의 JEPA 계열 모델과 아무 관련이 없습니다.)

System One 모델이 실제로 무엇인가

이 이름은 Daniel Kahneman에 대한 오마주입니다. System 2 사고는 느리고 신중하며 노력이 드는 사고로, 대규모 언어 모델이 계획하고 작성하고 설명할 때 수행하는 종류의 추론입니다. System 1 사고는 빠르고 직관적이며 자동적인 사고로, 이유를 설명하기도 전에 내리는 순간적인 판단입니다. System One 모델은 바로 그 두 번째 모드를 위해 만들어졌습니다. 즉 소프트웨어가 직접 소비하는, 한정되고 초고속인 의미 판단입니다.

구체적으로, Jev에게 어떤 상태(텍스트, 또는 텍스트 필드로 이루어진 JSON 객체)와 하나 이상의 질문을 건네되, 각 질문에는 미리 정의된 유효한 답변 집합을 붙입니다. 그러면 확률이 붙은 타입 지정 답변을 반환합니다. 그리고 결정적으로, 산문, 코드, 설명, 임의의 JSON을 생성하지 않습니다. 당신이 정의한 공간 안에서 선택하고 점수를 매길 뿐입니다. 같은 상태를 공유하는 질문들은 독립적으로 병렬 평가되므로, 단일 호출로 하나의 문서에서 여러 결정을 한꺼번에 추출할 수 있습니다.

Jev는 세 가지 결정 프리미티브를 제공하며, 거의 모든 활용 사례가 이들의 조합입니다.

여기서 중요한 멘탈 모델은 이렇습니다. 당신이 결정과 그 답변 공간을 정의하면, Jev는 그 안에서 보정된 의견을 반환한다. 이는 “LLM에 프롬프트를 넣고 JSON이 파싱되기를 바란다"는 것과는 근본적으로 다른 계약입니다.

System One 대 System Two: 빠른 지도

Jev는 LLM과 경쟁한다기보다 결정론적 코드와 생성형 추론 사이의 틈을 차지합니다. 이 비교는 Jev가 어디에 속하는지에 대한 직관을 가장 빠르게 세우는 방법입니다.

실무적인 시사점은, Jev의 가장 강력한 경쟁자가 종종 또 다른 LLM이 아니라는 것입니다. 안정적이고 레이블이 잘 붙은 분류 문제라면, 전통적으로 학습된 분류기가 더 저렴하고 완전히 자체 호스팅 가능할 수 있습니다. Jev의 우위는 카테고리가 런타임에 정의될 때, 새로운 질문마다 맞춤형 분류기를 만드는 것이 비경제적일 때, 그리고 생성된 텍스트에서 억지로 끌어낸 숫자가 아니라 보정된 확률을 일급 출력으로 원할 때 드러납니다.

애플리케이션 설계에서 Jev가 들어맞는 지점

어떤 문제가 좋은 Jev 후보가 되려면 다섯 가지 속성을 갖춰야 합니다. 입력이 단순한 규칙으로는 해소할 수 없는 의미적 모호성을 담고 있을 것, 가능한 답변 집합이 추론 이전에 알려져 있을 것, 앱이 산문이 아니라 기계가 소비 가능한 결과를 필요로 할 것, 긴 추론 사슬 없이 사용 가능한 상태로부터 판단을 내릴 수 있을 것, 그리고 LLM의 지연과 비용이 문제가 될 만큼 충분히 자주 일어날 것. 이것들이 맞아떨어질 때, 동일한 몇 가지 패턴이 반복해서 나타납니다.

의도 라우팅 및 분류. 대표적인 사례입니다. 지원 메시지가 도착하면, Choice가 담당 큐를 고르고, Noul이 환불이 요청되었는지 플래그를 세우며, Score가 긴급도를 평가합니다. 이 모두가 하나의 상태에서, 한 번의 호출로 이루어집니다. 예전에는 수 초짜리 LLM 프롬프트였던 라우터가 1초 미만의 결정이 되고, 큐 이름은 반드시 당신이 실제로 가진 것 중 하나가 됩니다.

연관성 점수화 및 검색 게이팅. 이것이 바로 의미 기반 코드 검색을 가능하게 하는 요소입니다. 오픈소스 jevgrep 도구는 Jev를 사용해 저장소의 폴더, 파일, 선언 전반에 걸친 연관성을 판단하므로, 코딩 에이전트가 문자열을 grep하는 대신 동작을 서술함으로써 올바른 코드를 찾을 수 있습니다. 그리고 그 제작자들은 벤치마크 하위 집합에서 에이전트 비용을 약 40% 절감했다고 보고합니다. 같은 패턴이 RAG에도 적용됩니다. 즉 폭넓게 검색한 다음, 무언가가 생성기에 도달하기 전에 Jev가 각 구절의 연관성, 증거적 뒷받침, 모순 여부를 점수화하도록 하는 것입니다. 검색과 증거 수용이 별개의 관찰 가능한 단계가 됩니다.

실시간 결정 루프. LLM이 단순히 너무 느린 경우, System One 모델은 루프 안에서 실행될 수 있습니다. jev-trader 프로젝트는 교훈적인 극단 사례입니다. 이는 단일한 약 300ms 블록 안에서 오더북을 읽고 방향을 결정한 뒤 주문을 넣어야 하는 마켓 메이킹 봇입니다. 그것은 에세이가 아니라 결정입니다. 그리고 그것은 게임, 로보틱스, 제어 시스템, 실시간 개인화에서 나타나는 수많은 덜 이색적인 루프의 형태이기도 합니다.

에이전트 및 도구 게이트. 에이전트형 시스템은 전체 작업이 개방형일 때조차 한정된 선택으로 가득합니다. 어떤 도구를 쓸까? 계속할까 멈출까? 이 제안된 행동은 위험한가? Jev는 그런 게이트에 자연스럽게 들어맞습니다. Vercel과 LangChain은 이미 도구 라우팅과 사전 행동 리스크 점검용으로 이를 노출하고 있습니다. 다만 아래의 경계를 유의하십시오. Jev는 정책에 정보를 제공해야지, 정책 그 자체가 되어서는 안 됩니다.

프로덕션 평가. 값비싼 LLM 판정관을 위해 트레이스의 일부만 샘플링하는 대신, 모든 트레이스에 대해 저렴한 타입 지정 평가기를 실행할 수 있습니다. 즉 정확성, 안전성, 사용자 불만, 정책 준수를 평가하고 확률을 메트릭으로 저장하는 것입니다. Langfuse는 2026년 9월에 바로 이것을 실험적 Jev 평가기로 출시했습니다. 필요한 판정이 좁고 타입화되어 있을 때, 이것은 극적으로 저렴한 커버리지입니다. 서술형 근거가 필요할 때는 여전히 LLM 판정관이 이깁니다.

이 모두를 엮는 패턴: 확률 인식 선택적 자동화

여기 가장 중요한 아키텍처적 아이디어가 있으며, 팀들이 가장 자주 잘못 이해하는 부분이기도 합니다. Jev의 답변은 행동하라는 지시가 아닙니다. 그것은 확률입니다. 그 확률로 무엇을 할지는 당신이 소유하는 별개의 결정론적 정책 결정이며, 그것은 단순히 신뢰도 숫자가 아니라 틀렸을 때의 결과에 따라 달라져야 합니다.

“신뢰도 ≥ 0.8이면 행동하라"는 보편적 규칙은 나쁜 설계입니다. 마케팅 태그를 자동으로 적용하는 일은, 자금을 지급하거나, 청구를 거부하거나, 프로덕션 인프라를 변경하는 일보다 훨씬 더 큰 불확실성을 감내할 수 있습니다. 올바른 형태는 신뢰도로 게이팅되는 캐스케이드입니다.

input → deterministic validation → retrieve & minimize context
      → Jev decision layer → typed answer + probabilities
      → risk-aware policy engine:
            high confidence + low consequence → automate
            middle band / needs reasoning     → escalate to LLM
            uncertain / high consequence       → human review
            policy violation                   → block / safe fallback
      → outcome captured → calibration monitoring → back to policy

이를 설득력 있게 만드는 것은 경제성입니다. C_J, C_F, C_H가 각각 Jev 호출, 폴백 LLM 호출, 사람 검토의 비용이고, r_F와 r_H가 사례가 에스컬레이션되는 비율이라면, 결정당 기대 비용은 대략 C_J + r_F·C_F + r_H·C_H입니다. Jev는 다운스트림 오류율을 밀어 올리지 않으면서 그 에스컬레이션 비율을 안전하게 낮출 때 정확히 값을 합니다. TypeSafe 자체의 추출 쿡북도 이 형태를 사용합니다. 즉 저렴한 모델이 추출하고, Jev가 검증하며, 검증이 불확실할 때에만 값비싼 추론 모델이 실행됩니다.

이것은 새로운 발명이 아닙니다. 이는 잘 확립된 선택적 분류 트레이드오프, 즉 더 낮은 오류를 위해 더 낮은 커버리지를 받아들이는 것에, 보정, 즉 당신이 “90% 가능성"이라 부른 것들이 실제로 약 90%의 확률로 일어난다는 속성을 결합한 것입니다. 둘 다 깊은 연구 문헌을 가지고 있으며, 둘 다 Jev로 설계할 때의 올바른 렌즈입니다.

반드시 설계에 반영해야 할 한계

TypeSafe는 Jev 1.13에 대해 “모델이 취약한 지점"을 솔직하게 공개한 페이지를 게시한 점에서 인정받을 만합니다. 이것들을 각주가 아니라 아키텍처적 제약으로 다루십시오.

거버넌스를 좌우하기 때문에 강조할 가치가 있는 두 가지 주의 사항이 있습니다.

첫째, “환각을 일으킬 수 없다"는 것은 정밀하고 좁은 주장입니다. 출력 공간이 고정되어 있으므로, Jev는 존재하지 않는 선택지를 내놓을 수 없습니다. Choice["approve","deny"]는 결코 “아마도 손실 처리하자"를 반환하지 않습니다. 그것은 형식 환각을 제거합니다. 하지만 그것이 의미적 오류를 제거하지는 않습니다. deny가 옳았을 때 approve를 반환할 수 있으며, 그 틀렸지만 유효한 답변은 형식이 잘못된 LLM 출력보다 오히려 더 위험합니다. 검증을 깨끗이 통과해 버리기 때문입니다. Vercel 자체 문서도 이를 분명히 말합니다. 스키마는 답변을 제약할 뿐 그 정확성을 제약하지 않는다고 말입니다.

둘째, 성숙도가 진짜 리스크입니다. 이 글을 쓰는 시점에 Jev는 대략 2주 정도밖에 되지 않았습니다. 동료 심사를 거친 아키텍처 논문도 없고, 공개된 가중치나 파라미터 수도 없으며, 재현 가능한 학습 명세도 없습니다. TypeSafe는 그 방법을 “보정된 결정을 위한 강화 학습"이라 설명하지만 세부 사항은 공개되지 않았습니다. 따라서 검증된 것이 아니라 벤더가 설명한 패러다임으로 다루십시오. 눈길을 끄는 수치들(벤더는 비교 대상 LLM 워크플로 대비 최대 약 400배 낮은 비용과 약 200배 낮은 지연을 인용합니다)은 TypeSafe 자체 팀이 자체 워크플로에서 생성한 1차 벤치마크입니다. 그것들은 당신의 워크로드에서 재현해 볼 유망한 가설이지, SLA가 아닙니다.

엔터프라이즈 아키텍트에게 이것이 의미하는 바

실제 시스템을 위해 Jev를 평가하고 있다면, 몇 가지 원칙이 당신을 트레이드오프의 올바른 편에 서게 해 줍니다.

공급자 중립적 결정 서비스 뒤에 두십시오. 모든 애플리케이션이 벤더 API를 직접 호출하게 두지 마십시오. 내부 “결정” 계약, 즉 상태, 질문, 허용된 답변, 리스크 등급을 노출하여 정규화된 결과를 반환하게 하십시오. 이는 자격 증명을 격리하고, 임계값 거버넌스를 중앙집중화하며, 대안을 섀도 테스트할 수 있게 하고, 탈출 경로를 제공합니다. 여기서는 이것이 평소보다 더 중요합니다. Jev는 오늘날 자체 호스팅 옵션이 없는 호스팅 전용이기 때문입니다. 데이터 레지던시가 타협 불가라면, 바로 그 동일한 인터페이스가 대신 SemIf 같은 오픈 대안을 앞단에 둘 수 있습니다.

모델 버전을 고정하십시오. jev-latest 같은 별칭은 새 버전이 출시되면 이동합니다. 특정 버전에 대해 신뢰도 임계값을 보정해 두었는데 예고 없는 업그레이드가 일어나면, 그것을 조용히 무효화합니다. jev-1.13.0(또는 당신이 검증한 버전)을 고정하고, 버전 상승을 모델 마이그레이션처럼 다루십시오. 즉 리플레이, 섀도, 카나리를 거친 뒤 롤아웃하는 것입니다.

프롬프트가 아니라 기준을 설계하십시오. 값을 하는 규율은 긴 사고 사슬 프롬프트가 아니라, 모호한 판단(“이 청구를 승인해야 하는가?")을 원자적 질문(“정책 문구가 이 사건을 뒷받침하는가?”, “증거는 얼마나 강한가?")으로 분해하고, 이를 결정론적 정책 코드와 결합하는 것입니다. 산술, 날짜, 불변식, 부작용은 소프트웨어에 유지하고, Jev에게는 좁은 의미적 질문만 하십시오.

거버넌스는 모델이 아니라 시스템에 붙는다는 점을 기억하십시오. 채용, 대출, 안전 워크플로 안에 있는 비생성형 결정 구성 요소라 해서 EU AI Act나 NIST AI RMF 같은 프레임워크상의 의무에서 벗어나지 않습니다. 확정된 모델 버전, 결정 정의, 정책 버전, 그리고 결과를 로깅하고, 영향이 큰 결정에 대해서는 사람의 이의 제기 경로를 유지하십시오.

솔직한 요약은, Jev가 플랫폼을 통째로 걸 토대가 아니라 흥미롭고 특화된 가속기라는 것입니다. 2026년의 올바른 자세는 중립적 인터페이스 뒤에서, 결정론적 안전 봉투와 항상 사용 가능한 에스컬레이션 경로를 갖춘, 섀도 → 보정 → 신뢰도 게이팅 → 카나리 → 확장입니다. 그렇게 하면, 2주 된 확률적 모델을 단일 장애점으로 만들지 않으면서도 잠재적으로 큰 지연 및 비용상의 이점을 확보할 수 있습니다.

Big Hat Group과 함께 결정 계층을 설계하십시오

System One 모델은 진정으로 새로운 구성 요소이며, 그 가치는 거의 전적으로 그것을 둘러싼 아키텍처에 있습니다. 즉 라우팅, 신뢰도 게이트, 보정 모니터링, 그리고 확률을 언제 신뢰할지 결정하는 결정론적 가드레일입니다. 그것이 바로 우리가 하는 AI 시스템 설계입니다.

Big Hat Group은 엔터프라이즈 팀이 자신의 스택에서 결정 모델이 어디에 속하는지 파악하고, 하이브리드 System One / System Two / 사람 아키텍처를 설계하며, 이를 안전하게 운영할 수 있게 하는 거버넌스와 관찰 가능성을 갖춰 구축하도록 돕습니다.

AI 결정 아키텍처 설계를 위해 문의하기 →

관련 글: AI 거버넌스 2026: 엔터프라이즈 컴플라이언스 가이드 · AI 성숙도 모델: 엔터프라이즈 단계

이 글은 TypeSafe의 공개 Jev 문서 및 출시 자료, Vercel, Cloudflare, LangChain, Langfuse의 통합 문서, 오픈소스 jevgrep 및 jev-trader 프로젝트, 그리고 보정 및 선택적 분류 연구 문헌을 바탕으로 합니다. TypeSafe에 귀속되는 성능 및 비용 수치는 벤더 벤치마크이며, 작성 시점에 독립적으로 재현되지 않았습니다.