AI로 글을 쓰지 않는 ‘제브’의 정체――TypeSafe AI는 무엇을 만들고 싶어 하는가

게시판: 뉴스 | 작성자: admin | 작성일: 2026-09-18T08:01:05.767Z

2026년 9월, TypeSafe AI가 공개한 Jev는 일반적인 LLM을 축소한 모델이 아니다. 인간을 위한 문장 생성 대신, 소프트웨어가 그대로 사용 가능한 형태의 판단과 확률을 반환하는 데 특화된 AI이다. TypeSafe는 이를 System One Model이라고 부르며, 분류, 라우팅, 점수, 승인, 검증과 같은 대량의 의사 결정을 일반적인 LLM보다 훨씬 낮은 레이턴시와 비용으로 소프트웨어에 통합하는 것을 목표로 한다. 이 발표가 주목을 받은 것은 단순히 “193.6배 빠르다”는 수치 때문만이 아니었다. 공동 창업자 겸 CEO 디오고 알메이다는 OpenAI의 InstructGPT 논문 공저자이며, GPT-4의 공식 기여자 목록에도 Foundational RLHF 및 InstructGPT 작업 기여자로서 기재되어 있다. ChatGPT로 이어지는 “인간의 지시를 따르는 AI”의 실현에 관여했던 연구자가 이번에는 “기가 사용하는 AI”를 다른 형태로 재구성하려는 점이 이 회사의 의미를 가진다.

본 글에서는 TypeSafe의 공식 발표와 문서, 자사 평가, 계약 문서, 외부 실측, 독립 분석을 다루고 있다. Jev가 무엇을 달성했는지, 무엇이 아직 벤더 주장의 단계인지, 어디에 기술적인 반론이 있는지, 그리고 에이전트나 기업 시스템에 도입할 경우 무엇을 측정해야 하는지까지 정리한다. 최종 버전에서는 중복되는 부제를 본문으로 통합하고 2026년 9월 18일 기준으로 확인 가능한 정보로 업데이트했다.

결론부터 말씀드리자면

제브의 가치는 “가장 현명한 AI”인 것이 아니다. TypeSafe의 공식 워크플로우 평가에서는 제브가 최상위 추론 모델보다 정확도가 낮지만, 동일한 System One형 태스크에서는 비용과 레이턴시를 크게 낮추고 있다. 중요한 것은 어려운 추론을 담당하는 거대 모델과, 방대한 양의 작은 판단을 담당하는 decision model, 정확한 계산과 부작용을 담당하는 일반 코드를 분업하는 설계 철학이다. 다만, 공식적으로 193.6배 빠르고 444.6배 저렴하다는 수치는 동일 모델과의 일대일 비교가 아니다. TypeSafe가 직접 설계한 워크플로우 평가에서 제브와 동수준의 정확도를 보인 모델과의 속도 차이, 다른 모델과의 비용 차이에서 비롯된 것이다. TypeSafe는 또한 실세계에서 기대할 수 있는 개선 폭이 높은 측이라고 언급하고 있다. 또한 “hallucination-free”는 자유 형식의 정의되지 않은 출력이나 타입 오류를 구조적으로 배제한다는 의미가 중심이며, 의미적인 판단 미스만 해결되는 것은 아니다.

외부 검증은 발표 직후부터 증가하고 있다. Every는 대량의 텍스트 검토로 속도와 비용을 확인하면서 프론티어 모델보다 결함을 한 건 더 많이 놓친 것으로 나타났다. Near Here는 좁은 이벤트 판정으로 비교한 소형 모델보다 높은 정확도와 낮은 비용을 보고했다. Aera는 400건의 실타스크 재생으로 동일한 커버리지를 유지하면서 precision과 latency를 개선하고, Jev의 확률과 유용성 대응도 측정했다. DevelopersIO와 YTAL의 검증은 Jev 단체가 빠르고 저렴하더라도 네트워크, 후보 생성, 임계값, 집계, fallback을 포함하는 시스템 설계에서 최종 KPI가 크게 달라지는 것을 보여준다.

제1장: 발표 시점 및 TypeSafe AI라는 회사
제2장 디오고 알메이다와 창업팀
제3장: TypeSafe가 해결하려는 문제
제4장 시스템 원 모델과 제브의 기본 설계
제5장 API, 기본 연산, 병렬 처리
제6장 왜 제프는 빠르고 저렴한가
제7장: RLCD, 확률 보정, 신뢰도
제8장 TypeSafe 공식 워크플로우 평가를 어떻게 해석해야 하는가
제9장: 유형 안전성과 “할시네이션 제로”의 진정한 의미
제10장 사이드바이사이드는 DOOM, 위키레이스 데모
제11장 기술에 대한 반론과 제브의 기술적 장벽
제12장 외부 검증 결과
제13장 워크플로우 분해 및 책임 명확화
제14장: 에이전트와 차세대 AI 아키텍처
제15장 ERP, MES, 금융, 사이버보안, 로봇 응용
제16장 계약, 데이터, 개인정보
제17장: Vercel, Netlify 및 생태계
제18장 타입세프 연구 사상
제19장 현재 시점에서 미공개된 것들과 앞으로 측정해야 할 것들
결론: 지능을 역할에 따라 분해한다
그래요, 아무리 그래도 그렇게 힘들었는데, 그래도, 그래도, 그래도, 그래도, 그래도, 그래도, 그래도.
해시태그

제1장: 발표 시점 및 TypeSafe AI라는 회사

TypeSafe의 공식 블로그 “Introducing System One Models and Jev”은 현재 확인 가능한 페이지 표시 및 검색 인덱스에서는 2026년 9월 14일로 되어 있다. 블로그 본문은 “오늘”이라는 표현을 사용하여 Jev의 Early Access 시작을 알리는 내용이다. 반면, DCVC 주도 4,000만 달러 규모의 시드 라운드와 스텔스 해제 관련 보도자료, Almeida氏의 대규모 X(트위터) 발표, Forbes 등 주요 언론의 보도는 9월 15일에 발표되었다. 따라서 Jev의 기술 블로그 공개를 9월 14일, 회사로서의 광범위한 론칭과 자금 조달 발표를 9월 15일로 나누는 것이 가장 혼란이 적다. 이후 9월 16일에는 Vercel이 Jev를 AI Gateway에 추가하고, 9월 17일에는 Netlify도 AI Gateway를 통해 제공을 시작했다. 같은 시기에 Every, Near Here, DevelopersIO, YTAL, Aera 등 외부 검증도 연이어 공개되었다. Jev는 발표 직후부터 단순 연구 데모가 아닌, 실제 소프트웨어 스택 안에서 시험되는 단계로 접어들었다.

타입세이프 AI는 2024년 설립되었으며 본사는 샌프란시스코에 위치한다. 자칭 “프론티어 AI 랩”이라고 한다. 애플리케이션 기업이 아닌 모델 자체를 만드는 연구소를 명칭하고 있다. 팀은 OpenAI, Google Brain, Meta/FAIR, Stripe, Airbnb, Plaid, Docker 등 출신 인물로 구성된다. 사무실은 Embarcadero 역 근처에 위치하며 주 5일, 모든 직원이 출근해야 한다고 명시하고 있다. 2026년 AI 스타트업으로는 드물게 원격 근무를 전제로 하지 않는다. 회사의 슬로건은 일관되게 “Build Prod, Not God.”, 즉 “신처럼 완벽한 AI를 만드는 것이 아니라 실제 환경(production)에서 사용 가능한 지능 부품을 만드는 것”이라는 의미를 담고 있다. 회사 내 상품에는 “Death before strings”, “No strings attached”, “UnSLOPable” 등의 문구가 들어있다. 문자열(string)을 버린 것을 회사의 정체성에 두고 있다.

2년의 은폐 기간을 거쳐 2026년 9월 15일에 Jev의 제품 발표와 자금 조달 및 은폐 해제를 동시에 진행했다.

DCVC 주도 시드 라운드에서 약 4,000만 달러(약 64억 원)를 조달했다. DCVC의 제네럴 파트너인 James Hardiman 氏가 “TypeSafe는 AI가 해결해야 할 가장 큰 과제 중 하나인, 성능이 지속적으로 향상되는 모델을 개발자가 제품에 확실하게 통합하고 확장할 수 있도록 하는 기술로 변화시키고 있다”고 밝혔다.

【보도 베이스】Forbes는 관계자들의 말을 인용해 평가액을 2억 달러(약 320억 원)로 보도했다. 기사 제목은 “This $200 Million Startup Wants To Fix AI's Overconfidence Problem”이다. TypeSafe 스스로가 발표한 숫자와는 다르다. DCVC의 포트폴리오 페이지는 TypeSafe에 대한 초기 투자를 2025년으로 명시하고 있다. 9월 15일 발표는 “라운드 종료일”이 아닌 “공개일”일 가능성이 높다. 라운드가 언제 닫았는지는 회사와 DCVC 모두 밝히지 않았다. 4,000만 달러 규모의 시드 라운드는 초기 라운드としては 규모가 크다. 이 계약의 특징은 DCVC가 애플리케이션 계층이 아닌 “모델 자체의 형태를 변화시키는” 데 집중 투자했다는 점이다.

제2장 디오고 알메이다와 창업팀

공동 창업자는 3명입니다.

【디오구 알메이다 — 공동 창업자 겸 CEO】 전 OpenAI의 임원. 이전에는 Google Brain에서 일했다. InstructGPT 논문의 공저자이며, GPT-4의 공식 기여자 목록에는 “Foundational RLHF 및 InstructGPT 작업”에 대한 기여자로 명시되어 있다. 공식 팀 페이지 소개글은 “RLHF와 InstructGPT를 공동 발명했다”고 한다. 덧붙여서, League of Legends에서 북미 30위 안에 진입하고, Hearthstone에서 2위를 기록한 경력이 소개에 포함되어 있다.

에릭 가프니 — 공동 창업자 겸 CTO] 그는 연속 창업가이다. DNA 시퀀싱용 멀티모달 AI 스타트업 “라벨(Ravel)”의 창업자이기도 하며, Invitae와 Freenome이라는 두 개의 유니콘 기업의 초기 직원으로서도 활동했다. 여러 논문과 특허를 보유하고 있으며, 본번 운영 AI 시스템 구축을 전문으로 한다.

【사샤 셰ᠩ — 공동 창업자 겸 COO】메타/FAIR의 전 리서치 엔지니어다. 뉴스 피드, AI 경험, AI 연구에 관여했으며, NeurIPS와 ECCV에 논문을 발표했다. 2023년 해커톤에서 7회 우승한 경력을 본인 소개에 첨부했다. TypeSafe AI는 기초 연구와 프로덕션 구현 모두를 경험한 팀이다. 연구소를 표방하면서도 제품 출시라는 데 강한 의지를 가지고 있다. Business Wire 보도자료, TypeSafe 공식 팀 페이지, 관련 언론 보도에서 Almeida를 “RLHF/ChatGPT의 공동 발명가(co-inventor)”라고 언급하지만, 인간 피드백을 이용한 강화 학습의 중요한 선행 연구는 2017년에 Paul Christiano, Jan Leike, Dario Amodei 등이 발표했다. Almeida는 해당 논문의 저자가 아니다.

따라서 “RLHF라는 기술 자체를 발명한 사람”이라는 이해는 정확하지 않다. 그러나 이것을 “미디어의 과장”으로 치부하는 것도 정확하지 않다. TypeSafe 자체의 공식 페이지가 그렇게 쓰고 있다. 회사의 자가 설명이므로, 공식 문서인 “AI primer”에서는 이 주장의 링크로 Almeida 교수의 Google Scholar 페이지를 지칭하고 있다. The Register 역시 Google Scholar의 특정 인용 문헌에 링크를 제공하고 있다. 본 글에서는 다음 표현으로 통일하여 다루겠다: “ChatGPT로 이어지는 InstructGPT와 RLHF의 실용화에 깊이 관여한 전 OpenAI 연구원” 및 “그들은 이 사람을 ‘RLHF의 공동 발명가’로 표기하고 있다”고 발표 기반임을 명시한다. 이는 사소한 이야기가 아니다. 이 회사의 이야기 전체가 “RLHF를 만든 당사자가 RLHF의 한계를 폭로하는” 구조로 짜여져 있기 때문이다. 전제로서의 강도는 결론의 강도에 직접적으로 연결된다.

제3장: TypeSafe가 해결하려는 문제

TypeSafe의 매니페스트는 이 회사를 이해하는 데 가장 중요한 문서이다. 제시하는 미션은 다음과 같다. “지능을 합성 가능하게(composable) 만들고, 지적 소프트웨어의 캄브리아 폭발을 촉진하며, AI를 통한 경제 혁명으로 가는 최단 경로를 개척한다.” 또한, 이 문서를 통해 그 ‘경제 혁명’을 수치로 정의하고 있다. 세계의 전 요소 생산성(TFP) 성장률이 5년 이내에 3%에 도달하고, 그 수준을 10년 동안 유지하는 것이다. 이 회사는 이를 “경제 역사상 전례 없는 수준이지만, AI의 이익이 실체 경제로 확산되면 달성 가능하다”고 쓰고 있다. AI 기업의 매니페스트에서 목표를 TFP 성장률이라는 구체적인 거시 지표로 제시한 경우는 드물어 주목할 만하다. 세 단계의 계획 또한 명시되어 있다.

머신 네이티브한 합성 가능한 AI의 “형태”를, 최대한 높은 지능 대비 비용 효율성으로 출시한다.
본래의 자동화가 경제를 변화시키는 데 충분한 신뢰성을 확보하는 것
합성 및 계층을 통해 안정적이고 고차원적인 지능 추상을 세계에 제공한다.

마무리로 “우리는 신이 아니며, 실제 환경을 구축하고 있다”고 말한다. 마니페스트의 핵심은 AGI에 대한 태도이다. “우리는 ‘AGI’라는 지속적으로 나아가는 목표를 쫓아가는 것이 아니라, 오늘날의 모델이 막대한 경제적 가치를 창출하는 데 필요한 지능의 임계점을 훨씬 초과하고 있다는 것을 말한다.” 그러면서 “수년 동안 수조 달러를 투자했음에도 불구하고 대부분의 소프트웨어는 의미 있는 지적 능력을 갖추지 못했고, 평균적인 인간의 삶은 거의 변하지 않았다. 이는 무엇을 보여주는가. 병목은 순수한 지능이 아니라, 오늘날의 지능이 그 위에 무언가를 구축하기가 어렵다는 점이다”라고 덧붙인다. 비유가 두 가지 사용되었다. 첫 번째는 “말이 없는 마차”이다. 초기 자동차는 마차에서 말을 모터로 바꾼 것과 같이, 높은 좌석, 바ギー용 스프링, 경우에 따라서는 채찍을 삽입하는 소켓까지 그대로 남겨둔 상태였다. 새로운 기술은 자신만의 형태를 찾기 전에 대체 대상의 형태에 억지로 맞춰지는 경향이 있다. 현재의 AI는 “친절하고 명확하며 매너 좋은 비서”가 되도록 훈련되고 있으며, 인간이 상대일 경우 합리적인 목표이다. 그러나 그 당연한 결과로, 배경에서 작동하는 대신 인간을 루프에 필요로 하는 AI가 만들어진다.

두 번째는 “SQL 이전의 데이터베이스”입니다. “오늘날의 지능은 SQL 이전의 데이터베이스와 유사한 것이다. 강력하지만, 사용될 때마다 희소성이 있다.” 데이터베이스를 만든 사람들은 구글을 상상하지 못했다. 인터넷 프로토콜을 만든 사람들은 스트립을 구상하지 않았다. 그들은 저수준의 기능을 백그라운드에서 실행될 뿐만 아니라, 그 위에 층을 쌓을 수 있을 정도로 신뢰성 있게 만들었다. TypeSafe가 노리는 곳은 바로 이것이다. 공식 문서의 “AI primer”에는 더 심층적인 정의가 있다. “우리는 이것을 Machine Native Intelligence라고 부른다. 구조, 신뢰성, 가시성, 테스트 가능성, 속도, 일관성, 저비용과 같은 소프트웨어적인 특성을 갖춘 인공지능이다.” 그리고, 이 회사의 미래 예측이 숫자로 제시되어 있다. “대규모 AI 자동화는 99%가 기계 간의 상호작용, 1%가 인간과의 상호작용에 가까워지기를 예상한다.” 이 문장이 TypeSafe의 제품 설계를 모두 설명한다.

99% 측면을 최적화한다면, 읽기 좋은 응답이 아닌 소프트웨어 내에서 예측 가능하게 작동하는 출력을 설계 목표로 해야 한다는 의미다. 이 예측이 맞는지 여부는 아직 누구도 알 수 없지만, 이는 검증 가능한 예측이며, 그 점은 평가할 수 있다. “Jev”의 유래는 19세기 영국 경제학자 윌리엄 스탠리 제보너즈(William Stanley Jevons)이다. 공식 블로그 설명은 다음과 같다. “우리는 기계 지능이 석탄과 같은 길을 걷게 될 것이라고 예상하고 있다. 증기기관의 효율성이 수요 증가를 초래했듯이, 지능의 비용이 한 자릿수 아래로 내려가면 기하급수적으로 많은 유스케이스가 해소될 것이다.” 제보너즈의 역설, 즉 효율이 상승하면 소비량이 줄지 않고 오히려 증가하는 현상이다. TypeSafe의 주장을 요약하면 “AI 판단의 가격이 극단적으로 저렴해지면, AI 이용량은 줄지 않고 수백 배, 수천 배로 증가할 것이다”다. 다만 The Register는 여기에 냉정한 보류를 덧붙이고 있다.

이 도박은 “토큰 시장이 에너지 시장과 유사한 정도로 넓다”는 전제를 바탕으로 하고 있다. 그리고 그 전제는 아직 쟁점이다. AI 툴을 사용할 수 있는 위치에 있으면서 활용 방법이 없는 사람도, 윤리적인 이유로 피하는 사람도 실제로 많다. 석탄은 누구나 사용하는 반면, AI 판단이 누구나 사용하는 것으로 이어질지 여부는 앞으로 결정될 것이다.

제4장 시스템 원 모델과 제브의 기본 설계

TypeSafe는 Jev를 “시스템 원 모델”이라고 부른다. 이 회사가 자체적으로 명명한 새로운 모델 분류이다. 공식 문서의 정의는 다음과 같다. “시스템 원 모델은 소프트웨어가 직접 사용할 수 있는 고속かつ 구조화된 판단을 수행하기 위해 만들어진 AI 모델의 클래스이다.” LLM과 마찬가지로 자연어 입력을 이해하지만, 출력은 생성 텍스트가 아닌, 형태화된 판단과 확률이다. Almeida 氏의 비유가 이해하기 쉬운 부분이다. “Jev는 프론티어 지능의 함수 호출이라고 생각해주시면 좋겠다. 비구조화된 상태가 들어가면서 형태화된 확률 판단이 나온다.” 원문은 “unstructured state in, typed probabilistic decisions out”이다. 중요한 점은 이것이 모델의 소형화가 아니라는 것이다. TypeSafe는 일관되게 “새로운 클래스의 프론티어 모델”이라고 표현하고 있다. 새로운 아키텍처, 새로운 샘플러, 새로운 학습 알고리즘의 3가지 세트를 자문에서 구축한 것이라는 것이 이 회사의 주장이다.

제브는 답변할 수 있는 질문이 3가지뿐이다. 이것이 TypeSafe가 말하는 “AI 프리미티브”다.

【선택】 주어진 선택지 중에서 하나를 선택한다. 순서가 없는 집합에 적용되며, 반환 값은 선택된 선택지(choice), 모든 선택지의 확률 분포(probabilities), 그리고 확신도(confidence)이다. 용도 예시는 문의 부서 배정, 문서 종류 분류, 프로그래밍 언어 판별 등이다. 선택지가 전체 입력을 포괄하지 않을 경우 “other”, “none of the above”를 추가하는 것이 권장된다.

【점수】정의된 순서 레벨에 따라 평가한다. 반환 값은 점수(score), 레벨 번호 및 설명 대응표(legend), 각 레벨의 확률 분포(probabilities), 확신도(confidence)이다. 이는 원고에서 흔히 오해되는 부분인데, 점수는 “Low/Medium/High”와 같은 이산적인 레이블이 아니다. 확률로 가중된 연속적인 값이며, 레벨과 레벨 사이에 속한다. 공식 예시에서는 레벨이 “Calm/Frustrated/Very angry”의 3단계로, 반환 값이 점수 1.6, 확률 분포가 {0: 0.05, 1: 0.3, 2: 0.65}, 확신도 0.78로 나타난다. 용도 예시: 버그 심각도, 고객 불만도, 스킬 레벨이다. 레벨 수는 최대 10단계이며, Choice의 선택 옵션은 255개까지 가능하다. 이 두 가지 상한은 Jev로 표현 가능한 판단의 범위를 규정한다.

【Noul】 Yes/No 질문에 대해 Yes일 확률을 0부터 1까지 반환한다. 이것은 TypeSafe만의 고유한 명칭으로 가장 특징적인 프리미티브이다. 중요한 사양은 Noul에 confidence가 붙지 않는다는 점이다. 반환되는 값은 noul 값 하나뿐이다. 용도 예시는 반환을 원하는 경우, 버그 보고인지 확인하는 경우, 직무 경력서에 분산 시스템에 대한 내용이 있는지 확인하는 데 사용될 수 있다. 공식 문서에서는 Noul과 Score의 혼동에 대해 명확한 경고를 하고 있다. Noul 값 0.5는 “Yes와 No가 동등 확률”을 의미하며, “중간 정도의 숙련도”를 의미하지 않는다. 정도를 측정하고 싶다면 Score를 사용해야 한다는 지시이다. 간과하기 쉽지만 중요한 제약이 존재한다. 공식 문서의 주석은 “Jev는 현재 텍스트 입력만 받는다. 문자열, JSON 객체, 텍스트 배열을 평가한다. 이미지, 음성, 비디오에는 (아직) 대응하지 않는다”고 명시하고 있다. 이 제약은 적용 범위를 고려할 때 결정적인 요소이다. DOOM 데모가 게임 화면을 보고 있지 않은 이유도 여기에 있다. Jev는 게임 상태를 묘사한 구조화된 텍스트를 읽고 있기 때문이다.

따라서 Jev는 Vision-Language-Action 모델과 같은 존재가 아니다. 로보틱스에 사용하는 경우, 지각은 별도의 모델이 담당하고, 그 출력을 Jev에게 전달하여 텍스트화하는 방식으로 구성된다. “(아직)”라는 괄호 표기가 공식적으로 포함된 점을 고려할 때, 멀티모달 대응은 향후 계획에 포함될 예정임을 짐작할 수 있다. 다만 현재 시점에서는 계획의 표명이라 보기는 어렵다. Jev의 설계 철학에서 가장 구현에 영향을 미치는 부분은 바로 이다. 하나의 요청에 포함되는 모든 질문은 동일한 state를 보고 각각 독립적으로 평가된다. 공식 문서의 표현인 “하나의 질문의 답은 다른 질문에 대한 숨겨진 맥락이 되지 않는다. 다른 답을 변경하지 않고 질문을 추가하거나 삭제할 수 있다”는 것은 장점일 뿐만 아니라 제약이 되기도 한다. 장점은 효율이다. 질문을 늘려도 응답 시간은 거의 변하지 않는다. 추가 비용은 질문 문장의 토큰 수만큼만 발생하며, 이는 극히 저렴하다. 공식적으로는 “사용하지 않을 수도 있는 질문을 던지는 것은 거의 무료에 가깝다”라고 언급하며, 이를 “Speculative fan-out” 패턴이라고 명명하고 있다.

공개된 요리책에서는 GDPR 위키피디아 기사에 대한 13가지 질문을 1회 요청에 모으면, 13회로 나누는 것보다 12.2배 저렴하고 10.0배 빠르며 답변 또한 동일하다는 결과가 나타나고 있다. 제약은 연쇄적인 것이다. 어떤 판단이 다른 판단의 답변에 의존하는 경우, 코드에서 2차 요청을 발행해야만 한다. 공식적으로 “2차 요청은 예외이며 원칙이 아니다”라고 명확히 밝히고 있다. 만약 2차 질문이 원래 상태에도 들을 수 있었다면, 최초의 요청에 모아 불필요한 답변을 코드에서 무시하라는 지시이다. 요청의 토큰 예산은 상태와 질문의 총합으로 약 32,000 토큰에 해당하며, 이는 영어로 약 15만 문자 상당한다. Choice의 카디날리티 상한은 255이다. 이를 초과하는 선택지를 다루는 경우, TypeSafe는 “먼저 독립적으로 점수를 매기고, 다음으로 명시적인 선택을 수행”하는 2단계 방식을 채택하고 있다. WikiRace 데모에서 가끔 속도가 저하되는 이유는 이것이 원인이라는 공식 설명이다.

제5장 API, 기본 연산, 병렬 처리

엔드포인트는 하나뿐이다. POST 요청은 https://api.typesafe.ai/v1/systemone 에 전달되며, 인증 방식은 Bearer 토큰이다. SDK의 기본 alias는 “jev-latest”이다. 9월 16일 Near Here에서 측정한 결과, jev-latest에 대한 요청에는 jev-1.13.0이 반환되었다. 응답의 버전 ID는 반드시 운영 환경 로그에 기록해야 한다. Vercel AI Gateway를 통해 호출하는 경우에는 모델 ID는 typesafe-ai/jev가 된다. 인증은 Gateway 측에서 처리한다. 요청 구조는 단순하다. state (평가 대상 내용, 문자열 또는 JSON 객체 또는 배열 중 선택 가능), model (“jev-latest”), questions (사용자가 지정한 키와 타입화된 질문 객체의 매핑 표)가 있으며, 응답은 동일한 키 아래에 답변이 반환된다. 또한 usage (input_tokens와 output_tokens)가 추가된다.

여기 흥미로운 사실이 하나 있습니다. 출력 토큰은 과금되지 않지만, 사용량에는 output 토큰이 기상됩니다. 공식 샘플 응답에서는 입력 312 토큰에 대해 출력 48 토큰으로 기록되어 있습니다. 즉, “문장을 생성하지 않는다”는 것은 “내부적으로 전혀 토큰을 생성하지 않는다”는 의미가 아닙니다. 과금하지 않는다는 의미입니다. 에러 코드는 401 (인증 실패), 422 (유효성 검사 실패), 429 (요청률 제한), 529 (과부하)입니다. 429와 529에는 지수 백오프를 통한 재시도가 지시되어 있으며, 공식 SDK는 이를 기본적으로 처리합니다. 여기서 한 가지 주의할 점은 이 요청 형식은 OpenAI의 chat completions와 호환되지 않습니다. 기존의 OpenAI 호환 클라이언트를 단순히 URL만 변경하는 것으로는 작동하지 않으며, 별도의 클라이언트가 필요합니다. SDK는 Python 버전과 JavaScript 버전이 제공됩니다. 이 둘 모두 MIT 라이선스입니다. Python 버전에서는 client.system_one(...)에 Choice, Noul, Score 객체를 전달하는 형태로 사용됩니다.

또한 Claude Code나 Codex와 같은 에이전트 환경용으로 “에이전트 스킬”이 배포되고 있다. GitHub에는 typesafe-sdk-python, typesafe-sdk-js, system-one-adapter-python, skills 리포지토리가 공개되어 있다. 적용에 대한 논의를 하기 전에 TypeSafe가 실제로 무엇을 공개하고 있는지 살펴보는 것이 가치 있다. 추측이 아닌 공식 요리책과 같다.

GDPR 위키피디아 기사 관련 13가지 규정 브리핑을 실행했습니다. 모든 질문을 1회 TypeSafe 호출에 모으면 12.2배 저렴하고, 10.0배 빠르며, 답변은 동일합니다.

【재순위화】CLERC 법률 쿼리 40건에 대해 BM25 알고리즘으로 30개의 패스지 후보 목록을 생성한다. 쿼리와 후보의 쌍마다 TypeSafe 질문을 사용하여 Top-1 정확도를 5%에서 18%로, Top-10 정확도를 38%에서 62%로 향상시켰다. 검색 재순위화는 Jev의 가장 실용적인 활용 사례 중 하나일 수 있다.

GitHub 이용 약관에 대한 의미 검색을 수행합니다. 1 요청으로 218행의 ID를 쉬운 단어로 표현된 쿼리에 대해 평가하고, Noul 질문을 통해 문서에 답변이 포함되어 있는지 확인합니다.

문서 구조 복구: 평문 텍스트에서 Markdown으로 복원합니다. 1단계에서는 각 줄이 문을 나누었는지 여부를 확인하고, 줄을 블록으로 통합합니다. 2단계에서는 블록을 제목, 목록, 코드, 콜아웃으로 분류합니다.

자연어 기반 거래 요청을 일반적인 형식화된 함수 호출로 변환하고, 함수 이름과 닫힌 집합의 인수를 신뢰도를 고려한 질문으로 매핑한다.

【지식 그래프 개체 정렬】두 맥주 카탈로그에서 450개의 후보 페어에 대해 동일 상품 여부를 판단하며, ScoreQuestion 1개가 판단 전체를 담당한다. 3단계로, 해당 페어에 대해 통합, 미링크 유지, 큐레이터에게 전달 등의 조치를 취할 수 있다.

SEC 연간 보고서를 75개 산업 그룹으로 분류하고, 정답의 신뢰도를 판단하여 해당 그룹을 보고할지 또는 더 넓은 상위 분류를 보고할지 결정한다.

【SDE 카ска드】2단계 구조화된 데이터 추출 카ска드를 통해 대규모 추론 모델의 품질의 대부분을 일부 비용으로 확보한다.

특허, 소매 상품, 생물 의학, 소스 코드의 심층적인 분류 체계로 문서를 분류한다. TypeSafe의 Choice 확률에 대한 병렬 빔 탐색을 사용하며, 이는 가설이 아니다. TypeSafe가 절차와 코드를 공개하는 실제 구현 예시이다. 응용을 논의한다면, 우선 여기서부터 시작하는 것이 타당하다.

제6장: 왜 츠베는 빠르고 저렴할까요

일반적인 LLM은 자기 회귀적이다. 토큰을 1개 생성하고, 그것을 조건으로 다음 토큰을 생성하는 순차적인 과정을 반복한다. 구조화된 출력을 요구하는 경우에도 마찬가지이다. “{”, “ “, “answer”, ":"와 같은 토큰들을 각각 다른 포워드 패스에서 생성한다. Jev는 문자열을 생성하지 않는다. 모든 출력을 단일한 병렬 패스에서 반환한다. TypeSafe는 이를 “병렬 샘플러”라고 부르며 “매우 효율적이고 하드웨어를 고려한 설계”라고 설명한다. 공식적으로 언급하는 응답 시간은 70밀리초에서 500밀리초이다. 비교 대상으로 언급되는 최첨단 모델의 엔드 투 엔드 응답 시간은 3초에서 329초이다. 이는 추론 모드를 켰을 때의 숫자이다. 속도의 배율에 대해서는 여러 숫자가 유통되고 있다. 공식 블로그의 비교표는 “40배에서 200배”라고 제시하며, Almeida氏 본인의 X 포스트와, 그것을 인용한 많은 보도는 “20배에서 200배 빠르고, 40배에서 400배 저렴하다”고 한다. 모두 공식 발의 숫자이다. 원고로 다루는 경우에는 양쪽 모두를 함께 기재하는 것이 정확하다.

공식적으로 속도 측정 조건은 자발적으로 공개하고 있습니다. “공개된 평가는 기본적으로 서해안에서 저희가 운영하는 랩탑을 통해 실행되며 (현재 서비스가 제공되는 위치이므로) 즉, 네트워크 지연이 가장 적은 조건에서 측정됩니다. 일본에서 호출한 경우에는 왕복 레이턴시가 추가됩니다. 공식 가격표는 단순합니다.

[Jev] 입력: 100만 토큰당 0.042달러(약 6.7엔). 10억 토큰으로 42달러(약 6,720엔). 출력: 무료. 공식 표현은 “too cheap to meter”입니다.

[공식에서 제시하는 LLM 가격대 비교] 입력: 100만 토큰당 0.20달러부터 10달러. 출력: 입력의 약 5배. The Register가 제시한 구체적인 예시에서는 GPT-5.6 Terra가 입력 2.00달러/MTok, 출력 12.00달러/MTok. Jev는 최상위급 Fable 5.1과 비교했을 때 238배 저렴하다고 제시한다. TypeSafe는 이 가격에 대해 스스로 보류를 걸어두고 있다. “가격은 투명하게 공개하고 있으며, 보조금이 들어오지 않았음을 증명할 수 없습니다. 이 가격 설정이 지속 가능한지 장기적으로 증명해야 합니다(우리는 하락을 예상하고 있습니다).” 보조금 가능성을 스스로 언급하는 기업은 흔하지 않다. 이곳은 진솔하다. 동시에 이것이 가장 검증하기 쉬운 주장이다. 실제 사용이 시작되면 가격이 유지될 수 있을지 곧바로 드러날 것이다. 홈페이지의 주요 숫자 출처는 공식이 명시한 바 있다. “이것이 우리가 홈페이지에 게시한 193.6배 빠른 속도, 444.6배 낮은 비용이라는 주장 출처이며, 이는 실제 세계에서 개선 폭이 높은 측에 있다고 예상하고 있다.”

제21장의 표와 비교를 통해 계산 근거를 확인할 수 있다. 193.6배 속도: Sonnet 5의 워크플로우 구성이 78.1초, Jev가 0.4초이다. 약 195배이다. Sonnet 5는 Jev와 동일한 정확도(67.8%)를 가지므로 “동일 정확도로 비교했을 때의 최대 속도 차이”로 선정되었다. 444.6배 저 비용: Opus 5의 워크플로우 구성이 1건 0.1761달러, Jev가 0.0004달러이다. 약 440배이다. 즉, 이 두 숫자는 별도의 모델과의 비교를 나타내는 것이다. 동일 모델에 대해 193배 빠르고 444배 저렴한 것은 아니다. 일본어 기사 제목에서 “LLM의 193배 빠르다”라고 쓰이는 경우, “Claude Sonnet 5의 워크플로우 구성과 비교한”다는 조건을 제외하면 부정확해진다. 참고로 단발 데모의 숫자는 훨씬 작다. 사이드바이사이드 데모에서는 Jev가 0.114초, GPT-5.6 Terra가 8.566초이다. 이는 75.1배이다. 공식적으로는 “20~200배” 범위에 속하지만, 193.6배에는 훨씬 미치지 못한다.

193.6배라는 숫자는 다중 분기를 수반하는 특정 워크로드에서 나온 최대값입니다. 일반적인 단일 호출 값은 아닙니다.

제7장: RLCD, 확률 보정, 신뢰도

제브는 RLHF나 RLVR이 아닌 RLCD로 훈련되고 있다. 강화된 판단을 위한 강학습이다. 공식 문서에서는 후속 학습의 3가지 체계를 다음과 같이 정리하고 있다.

【RLHF】인간 피드백을 통한 강화 학습. 사전 학습된 모델을 챗봇으로 변환한 기법으로, 인간이 선호하는 응답을 생성하도록 훈련한다.

검증 가능한 보상 기반 강화 학습으로 수학과 같은 작업에 강한 추론 모델을 개발했지만, 속도가 느리고 비용이 많이 든다.

【RLCD】교정된 판단을 위한 강화 학습이다. 생성 텍스트가 아닌 판단과 교정된 확률을 반환하도록 훈련한다. RLCD가 최적화하는 “출력 계약”은 세 가지이다. 모델은 텍스트를 생성하지 않고 판단과 확률을 반환한다. 확률이 높을수록 해당 답이 옳을 가능성이 높아져야 한다. 교정(calibration)의 정의 또한 명확하게 제시되어 있다. 확률 0.2를 할당하면 약 20%의 빈도로, 확률 0.8을 할당하면 약 80%의 빈도로 발생해야 한다. 확률 1.0을 할당하면 100% 발생해야 한다. 또한 매우 중요한 부연 설명이 이어지는데, “이러한 비율은 예측의 집합에 대한 내용이며, 개별적인 답변에 대한 보증은 아니다.”라는 문구가 후반부에 반복적으로 나타난다. 참고로 학계에는 2023년 발표된 “RLCD: Reinforcement Learning from Contrastive Distillation”이라는 유사한 방법이 존재한다. 약어가 동일하지만 의미가 다르므로 검색 시 주의해야 한다.

TypeSafe의 RLHF 비판은 상당히 구체적이다. 공식 문서의 설명에 따르면 “RLHF는 모델에게 사람들이 선호하는 것을 말하도록 가르치고, 챗봇에게는 잘 작동하는 목적 함수를 사용한다. 그러나 맹종과 자신감 넘치는 환각을 보상으로 제공할 수도 있다.” 또한 “모드 드롭핑”이라는 개념이 언급된다. 선호 최적화로 인해 모델은 특정 스타일(예: 지시 추종)을 선호하게 되어 다른 가능한 출력의 확률을 낮추는 현상이 발생한다. 공식적으로는 이를 GAN의 “모드 붕괴”의 완화된 버전으로 설명하고 있으며, 다음과 같은 경고 문구를 덧붙인다. “어떤 출력이 인간에게 설득력이 있는 것과 무인 자동화에 충분한 신뢰성을 갖는 것은 별개의 문제이다. 인간의 선호와 기계의 신뢰성은 서로 다른 최적화 목표이다.” 헌장(마니페스트)의 노트 또한 같은 논점을 제기한다. “RLHF, 즉 현재 AI의 거의 모든 것이 훈련되고 있는 알고리즘은 인간의 선호를 직접 최적화하며, 현대의 ‘추론’ 모델은 RLVR로도 훈련된다. 이는 프로그램적으로 평가 가능한 태스크(즉, 벤치마크)를 최적화한다.”

RLHF를 실용화한 당사자가 RLHF의 구조적 결함을 지적하고 있습니다. 이 구도가 바로 이 회사의 이야기 전체를 구성합니다. 여기는 원고에서 가장 흔하게 오류가 발생하는 부분입니다. Choice와 Score의 답변에는 확률 분포와 確信도가 모두 부여됩니다. 이 두 가지는 완전히 다른 개념입니다. 공식적인 설명입니다. 확률 분포의 “형태” 자체가 모델이 얼마나 確신하고 있는지를 나타냅니다. 하나의 결과에 집중되어 있다면 자신감 있는 답변이고, 널리 퍼져 있다면 불확실한 답변입니다. 確信도는 그 형태를 0부터 1까지의 단일 숫자로 압축한 것입니다. TypeSafe가 스스로 계산하지 않아도 임계값 판별을 해 줍니다. 공식은 또한 確信도를 절대화하지 않도록 주의하고 있습니다. “우리는 確信도를 대부분의 유스케이스에 맞는 편리한 척도로 제공하지만, 우리의 정의에 얽매이는 것은 결코 없습니다. 평가 대상에 따라서는 다른 척도의 것이 더 적합한 경우도 있으며, 그래서 반응에서 완전한 확률 분포를 반환합니다.”

낮은 신뢰도의 의미 또한 설명되어 있다. Choice에서 낮은 경우, 어떤 선택지도 명확한 승자가 아니라는 의미일 경우가 많다. Score에서 낮은 경우, 수준이 모호하거나 다차원적이거나, 상태에 판단 기준이 충분하지 않다는 의미일 경우가 많다. 그리고 철학적인 문장 “지적 시스템이 인간이든 기계든 진실된 불확실성을 표명할 수 없다면 그 시스템은 신뢰할 수 없다.”

공식에서 권장하는 운영 방식은 3단계로 구성된다. 높은 신뢰도에서는 자동 실행하고, 중간 신뢰도에서는 주의 깊게 진행하며 사용자에게 확인을 요청하거나, 리뷰에 플래그를 立て거나, 추가 정보를 수집하는 등의 조치를 취한다. 낮은 신뢰도에서는 실행하지 않고, 인간에게 전달하거나, 명확화를 요청하거나, 다른 시스템으로 복귀하는 등의 조치를 취한다. 더욱 중요한 것은 임계값을 하나로 고정하지 않는 설계 철학이다. 공식 문서의 코드 예시에서는 신뢰도가 0.5 미만은 일괄적으로 인간에게 전달하고, 그 이상은 행위의 위험도를 기준으로 분리한다. 잔액 조회와 같이 읽기 전용의 작업은 당장 실행하고, 송금 승인과 같이 파괴적인 작업은 신뢰도가 0.9 초과하더라도 확인을 덧붙인다. “임계값은 하나의 숫자가 아니다. 동일한 시스템 내에서도 실수를 했을 경우의 결과에 따라 행위마다 다른 수준으로 게이트를 설정해야 한다.” 99%라면 완전 자동, 95~99%라면 별도의 AI로 확인, 70~95%라면 인간 리뷰와 같이 고정된 단계를 쓰는 것은 공식의 설계 철학과 일치하지 않으며, 행위의 위험도가 핵심이고, 신뢰도만 핵심이 아니기 때문이다.

제8장 TypeSafe 공식 워크플로우 평가를 어떻게 해석해야 하는가

TypeSafe는 자체적인 평가 방법을 구축하고 모든 데이터를 공개하고 있습니다(evals.typesafe.ai). 설계 철학이 독특하기 때문에 꼼꼼히 읽어봐야 합니다.

[전제] 실제 작업은 구조화된 워크플로우로 실행할 수도 있으며, 단일 프롬프트로 실행할 수도 있습니다. TypeSafe는 “구조화된 방식이 항상 우수하다”고 주장합니다.

【절차】과제를 프로그램적 규칙과 지적 판단에 따라 분해한다. 모델에 문제 전체를 한 번에 해결하는 대신, 독립적이고 좁은 질문을 제시하고 가능한 한 코드로 위임한다. 질문은 Noul, Choice, Score 세 가지 유형만 사용하며, 결과는 프로그램적으로 처리하여 출력 액션을 생성한다.

【정답 레이블 생성 방법】 여기가 가장 중요한 설계 결정이다. TypeSafe는 하르ネス(코드)와 레이블의 정확성을 논의하는 대신 “코드는 정확하다”는 전제를 바탕으로 했다. 그 위에, 현재 시점에서 가장 현명한 대형 모델의 답변을 기준으로 했다. 구체적으로는 GPT-6 Astra와 Claude Fable 5.1을 고성찰 설정으로 실행하여 하르ネス 내의 모든 질문에 답하게 하고, 그 평균을 참조 레이블로 사용했다. 다른 모델은 모두 각 제공업체의 기본 추론 설정으로 평가되었다.

【4가지 업무】 보안 사고: 노트북이나 서버에서 경고가 발생한다. 경고와 해당 장비의 모든 기록을 통해 종결할지, 분석가에게 전달할지, 즉시 격리할지 결정한다. 에이전트 추적 모니터링: 지원 에이전트가 고객 응대를 마쳤다. 툴 호출을 포함한 전체 실행에서 사람이 확인해야 하는지, 얼마나 급한지를 결정한다. 청구서 처리: 거래처의 청구서가 도착한다. 청구서, 발주, 실제 납품에서 지급할지, 보류할지, 반송할지 결정한다. 고객 서비스: 고객으로부터 연락이 온다. 기존 스레드와 계정 상태에서 보조인이 다음에 무엇을 말하고 무엇을 할지를 결정한다. 즉, 평가 대상은 “지식 퀴즈”가 아닌 “업무 의사 결정”이다. 이 설계 자체는 설득력이 있다. 원고에 가장 결여되었던 것이 바로 이 숫자이다. 4가지 업무의 평균(등가중) 결과는 다음과 같다.

읽을 수 있는 내용은 명확하다. Jev는 가장 현명한 모델이 아니다. 중위권에 속하며, Sonnet 5와 동률이고 Terra와 거의 같다. Sol과 Opus 5는 5~6% 정도 뒤쳐져 있다. 하지만 비용은 1건당 0.0004달러(약 0.06원)이고, 시간은 0.4초이다. 이 두 지표에서 압도적으로 차이가 난다.

TypeSafe는 “파레토 프론티어를 2桁 가까이 독점하고 있다”고 말하는 것은 다음과 같은 의미이다. 아무도 Jev보다 저렴하고 정확하지 않으며, 아무도 Jev보다 빠르고 정확하지 않다.

업무별로 살펴보면, 득이 될 만도 하고 손해가 될 만도 하다. 고객 서비스: Jev 76.0%, DeepSeek V4 Flash (76.8%)에 이어 두 번째로 높은 수준이며, Opus 5 (72.4%)나 Sonnet 5 (69.3%)를 상회한다. Jev가 가장 강점을 보이는 영역이다. 에이전트 추적 모니터링: Jev 71.6%, Sol 76.6%, Luna 76.1%, Opus 5 75.2%보다 낮다. 보안 사고: Jev 61.7%, Opus 5 (66.2%)와 Sol (62.5%)보다 낮지만, Terra (51.2%)나 Sonnet 5 (60.8%)보다 높다. 청구서 처리: Jev 61.8%, 여기서 가장 약한 부분이다. Sol 79.1%, Opus 5 78.4%, Terra 74.7%와 비교하면 큰 차이를 보인다. 이러한 분포는 시사하는 바가 크다. 짧은 텍스트에서 의도와 감정을 파악하는 업무 (고객 서비스)에서는 Jev가 상위 모델과 경쟁할 수 있다. 여러 문서를 엮어 일관성을 검증하는 업무 (청구서 처리)에서는 명확히 뒤쳐진다.

이 차이는 다음 장에서 다룰 “추론 시 계산 능력이 없는” 구조적 제약과 부합한다. 이 평가에는 Jev와 무관하지만, 극도로 중요한 발견이 담겨 있다. 평가 사이트의 설명에 따르면 “4개의 예제 작업의 평균으로, 모든 모델이 동일한 정책을 프롬프트로 제시했을 경우보다 워크플로우로 제시했을 경우 더 정확하고, 저렴하며, 더 빠르다”는 수치를 보면 차이가 뚜렷하다. Claude Haiku 4.5: 프롬프트 18.1% → 워크플로우 53.6% GPT-5.6 Luna: 프롬프트 51.9% → 워크플로우 66.8% GPT-5.6 Sol: 프롬프트 63.4% → 워크플로우 74.1% Claude Opus 5: 프롬프트 64.8% → 워크플로우 73.1% 청구서 처리라는 복잡한 업무에서는 Haiku 4.5가 프롬프트 6.0%에서 워크플로우 42.9%로 급격히 상승한다. 이는 “작업을 작은 독립적인 질문으로 분해하고, 결합은 코드로 수행한다”는 설계 자체가 모델을 막론하고 큰 효과를 나타낸다는 의미이다.

즉, Jev를 사용하지 않더라도 이 분해만으로도 정확도는 올라갑니다. TypeSafe의 진정한 주장은 2단계로 구성되어 있습니다. 첫째, 워크플로우화되어야 하며 (이는 모델 비의존적인 설계론), 둘째, 워크플로우화된 후에는 그 안의 판단은 Jev로 충분하고, 현저히 저렴합니다 (이것이 제품의 판매 포인트). 첫 번째 주장은 Jev를 사용하는지 여부와 관계없이 현장에서 바로 시도해 볼 수 있다는 점이며, 이것이 실무적으로 가장 가져가야 할 가치 있는 부분입니다. 공식 블로그는 “Nuance(기미)”라는 제목으로 자사 평가의 약점을 나열하고 있습니다. 이는 드물게 평가할 만합니다.

이러한 워크플로우의 내용은 우리 모델을 더 잘 보이게 하기 위해 의도적으로 선택하거나 구성한 것이 아니며, 우리 훈련 분포에도 포함되지 않았다. 그러나 우리 모델 능력팀의 개인들이 만든 것이므로, 어떠한 편향이 존재할 수 있다. GPT-6 Astra와 Fable 5.1의 평균을 참조 답변으로 사용하고 있으며, 이는 OpenAI와 Anthropic의 모델에 답변을 편향시키는 것이다. 우리 자신의 모델과 DeepSeek 모델의 상대적인 성능을 과소평가하고 있을 가능성이 높다. 이 두 번째 문장이 중요하다. 참조 레이블이 OpenAI와 Anthropic의 합의로 만들어진 이상, 이 평가는 “OpenAI와 Anthropic의 상위 모델에 얼마나 유사한 답변을 내놓는가”를 측정하는 것이다. 절대적인 정답을 측정하는 것이 아니다.

【LLM 측의 조건에 대하여】“LLM은 저희의 System One LLM 라ッパー를 사용하고 있습니다. 이는 LLM을 저희 API와 호환 가능한 구조화된 판단을 출력하도록 제약하는 것입니다. 저희는 이것이 LLM로부터 판단을 얻는 가장 정확한 방법이라고 생각하지만, 확률 없이 판단을 내리게 하면 더 느리고 비용이 많이 들 수 있다는 경향이 있습니다.” 이 라ッパー는 GitHub에서 공개되어 있습니다(system-one-adapter-python). 스스로 검증할 수 있도록 하는 점은 칭찬할 만합니다. 다만, 뒤에서 논의될 Sean Goedecke 氏はまさに 이 점을 비판하고 있습니다. LLM에 불필요하게 JSON 덩어리를 토큰 단위로 생성하게 하는 비교가 이에 해당한다는 것입니다.

【사이드바이사이드 데모에 대하여】“쿼리는 매우 단순화되어 있으며, 상태 또한 짧고 밀집되어 있어 상세한 단락이며, 샘플링 방법론의 차이를 강조하기 위한 것이다. 상대적으로 짧은 입력은 우리 모델을 유리하게 보이게 한다. 기록된 실행에서 GPT-5.6 Terra와의 유일한 불일치는 ‘Churn likelihood level’이었다. 실제 답변은 우리에게도 매우 모호하게 보인다. 자체 데모에서 유일한 불일치를 “상대가 틀렸다고 단정할 수 없다”고 표현하는 것은 진솔한 태도이다.

【CounterProof에 의한 공개 아티팩트 감사】2023년 9월 16일, CounterProof Research의 루크 요셉 수네즈(Luuk Joseph Soons) 氏가 TypeSafe의 공개 벤치마크 아티팩트를 감사한 Field Note를 공개했다. 이는 Jev를 재실행한 독립적인 벤치마크가 아니며, TypeSafe가 공개한 케이스 파일들을 아카이브하고 그 참조 구조를 재계산한 감사이다. 이 점은 중요하다. TypeSafe의 711 케이스 중 상세한 케이스 파일로 공개되었던 20건을 조사한 결과, 두 참조가 일치하는 19건 중

최종 액션의 언어러드 셋 비교 결과 8건 완료
첫 번째 행동만 고려할 경우 6/19건입니다.

GPT-6 Astra 측과 제2 참조 측의 최종 액션이 일치하지 않았습니다. 더불어 356개의 쿼리 쌍 중 31건에서 두 참조가 답변하고 있었음에도 불구하고 값(value)이 달랐습니다. 또한 Vendor가 “all three miss the reference”라고 라벨링한 공개 4가지 사례 모두에서 두 개의 참조 모델 자신들도 서로 불일치했습니다. 이는 “TypeSafe의 벤치마크가 무효”라는 결론을 의미하지 않습니다. 실제 업무에는 객관적인 정답이 존재하지 않는 경우가 많아, 강력한 모델 두 개의 합의를 프록시 레이블(proxy label)로 사용하는 실무적인 이유가 있습니다.

제브는 총 711건 중 객관적으로 정답을 67.8% 맞혔다. TypeSafe가 정의한 워크플로우와 Astra/Fable 계열 레퍼런스로 만든 레이블링 정규화에 대해 67.8%의 일치도를 보였다.

별의 정원사는 정말 제가 오랫동안 찾던 것이었습니다. 생떼뷔리 선생님의 말씀은 어린 시절 읽었던 동화책처럼 제 마음속 깊이 스며들었습니다. 이 이야기를 읽고 나니 세상이 조금 더 따뜻해진 것 같았습니다. 그리고 이 이야기를 누군가에게 선물한다면 그 사람도 분명 행복한 기분이 들었을 것입니다. 별의 정원사는 저에게는 소중한 보물입니다.

CounterProof 감사에도 한계가 존재한다.

상세하게 공개된 20개는 벤더가 선별한 슬라이스이며, 전체 711건의 불일치율을 추정할 수 없습니다.
콜을 재실행하지 않고 있습니다.
질문별 답변에서 공개 정확도로 변환하는 점수 함수는 공개 파일 내에 존재하지 않습니다.
CounterProof 자체도 결과 기반 평가의 보급에 상업적 이익을 추구하며, 이는 이해 상충을 인정하는 것이다.
드래프팅 모델로, 벤치마크의 레퍼런스 모델 중 하나인 클로드 페이블 5.1을 사용하고 있습니다.

그러므로 이 감사는 “67.8%의 의미를 좁게 해석해야만 한다”는 강력한 근거가 된다 하더라도, Jev의 진정한 정확성을 대신 제공하는 것은 아니다.

본고에서는 이래서 가능한 한 “정답률” 대신 TypeSafe 워크플로우 평가상 accuracy/reference agreement로 표기한다. 그리고 실제적인 채용 판단에서는 Aera, Near Here, YTAL과 같이, 자체 데이터와 자체의 실패 비용으로 평가하는 것이 중요하다.

제9장 유형 안전성과 “해시네이션 제로”의 진정한 의미

TypeSafe는 유형 안전성에 대해서도 비교 데이터를 제시한다. 구조화 출력 오류율(OpenRouter 데이터를 기반으로 함)은 다음과 같다. GPT-5.6 Luna와 Terra: 0.58%, Claude Opus 5: 5.73%, Claude Haiku 4.5: 45.5%. 툴 호출 오류율에서는 GPT-5.6 Sol이 가장 심각한 수준으로 17.0%이며, Jev는 0%이다. 여기서 TypeSafe는 자신의 데이터의 성격을 솔직하게 드러낸다. “우리 데이터는 실제 측정값이 아니며, 스키마 적합성은 보장되므로, 플롯에 0%를 자신 있게 넣을 수 있습니다.” 또한 LLM(Large Language Model) 측의 숫자 대해서도 보류를 둔다. “LLM의 숫자 데이터는 OpenRouter에서 유래한 것이므로, 즉 거의 확실하게 편향이 있을 수 있습니다. 더 복잡한 쿼리는 더 나은 모델로 라우팅될 가능성이 있습니다.” 유형 안전성이 왜 중요한지에 대한 설명은 설득력이 있다. “에이전트 내에서 환각적인 툴 호출이 발생하는 것은 불편하지만, 레이턴시 보장 시스템의 일부이거나 의존 체인의 수층 아래에 묻혀 있을 경우에는 절대적인 치명적인 손상을 입힐 수 있습니다. 기존 모델은 아무리 똑똑해도 여전히 환각을 일으키고 유형 오류를 발생시킵니다.”

이는 정확한 지적이다. 인간이 보고 있는 화면상의 오류와 5단계 하위 서브시스템에서 발생하는 오류는 심각성이 다르다. 이 논점은 여러 독립적인 논자들이 동일한 결론에 도달하고 있다.

TypeSafe는 Jev가 구조상 환각을 일으킬 수 없다고 주장한다. 이는 스키마 적합성이 보장되기 때문이다. approve/reject/human_review와 같이 선택지를 정의할 경우, Jev는 maybe_approve_later와 같은 정의되지 않은 문자열을 반환하지 않는다. 이는 수학적으로 불가능하다.

[The Register의 지적] “TypeSafe는 Jev가 ‘환각(hallucination) 프리’라고 주장하지만, 출력 결과가 자연어와 다를 경우 이는 공정한 비교라고 할 수 없다. Jev는 대신 확률 기반의 구조화된 응답을 제공하지만, 부정확성을 배제하지 않는다. TypeSafe의 모델은 허위로 만들어진 법적 인용과 같은 오정보의 발생 원천이 되지 않지만, 동시에 응답이 소프트웨어에 소비될 수 있도록 설계되어 있으므로, 같은 방식으로 사용되지 않을 수도 있다.”

고에데케 씨의 지적) “Jev의 개발자들이 환각(hallucination)에 대한 면역력을 주장하고 있습니다. 저는 이것을 의미론적 회피로 해석합니다. Jev는 틀린 선택지를 고를 수 있으며(예컨대 하늘을 ‘빨간색’이라고 부르는 것) 이는 기술적으로 단순한 오류일 수 있습니다. 모델이 새로운 것을 처음부터 발명하는 대신 사용자가 제공한 선택지를 선택하는 한, 이러한 점은 구조화된 출력을 사용한 일반적인 LLM에도 해당되므로 실질적으로 Jev가 다른 것보다 더 신뢰할 수 있는 것은 아닙니다.”

“해러스네이션 제로”는 다음 두 가지를 의미한다. 스키마 해러스네이션과 타입 오류가 발생하지 않는다. 이는 판단이 정확하다는 것을 의미하지 않으며, “해러스네이션 제로 ＝ 정확도 100%”가 아니다. TypeSafe 워크플로우 평가판의 정확도는 67.8%이며, TypeSafe 자체도 이 0%가 실측값이 아닌 구조적 보증에서 비롯된 것임을 명시하고 있다. 오히려 보도와 독자 측의 오해를 낳는 구조에 놓여 있다.

제10장 사이드바이사이드는 DOOM, 위키레이스 데모

공식 웹사이트에 게시된 비교 영상의 숫자입니다. Jev: 0.114초, GPT-5.6, Terra(기정 추론 설정): 8.566초, 배율로 75.1배. 비용 또한 같은 화면에 표시됩니다. Jev는 0.000081달러, LLM 측은 0.013880달러입니다. 배율로 약 171배입니다. 즉, 이 데모의 실측치는 75배 및 171배이며, 메인 페이지의 제목인 193.6배 및 444.6배와는 다릅니다. 제목의 숫자는 별도의 워크플로우 eval에서 나온 것입니다. 같은 페이지에 놓여진 두 종류의 숫자가 다른 것임을 읽는 사람이 인지해 두어야 합니다. TypeSafe가 Terra를 선택한 이유도 설명되어 있습니다. “이 예에서는 GPT-5.6 Terra를 기정 추론 설정으로 사용했습니다. 평균적으로 지능 면에서 Jev에 가장 근접하다고 저희가 생각하기 때문입니다.” 즉, TypeSafe 스스로가 Jev의 지능 수준을 GPT-5.6 Terra와 맞먹는다고 평가하고 있습니다. 이 자체 평가는 제21장의 평가 결과(Terra 67.9%, Jev 67.8%)와 일치합니다.

데모의 의미는 속도 차이의 시각화에 있다. Jev는 모든 확률을 병렬로 출력하고, LLM은 토큰마다 자기 회귀 생성한다. 화면상에서 그 차이가 보인다. 참고로 공식에서는 “이와 유사한 데모こそ가 우리가 System One Model의 방향으로 완전히 몰리게 된 이유였다”라는 뒷이야기를 덧붙이고 있다. 가장 화제가 된 데모이다. Jev는 1초에 약 10번의 판단을 반환하며, 게임 『DOOM』을 실시간으로 플레이한다. 판단 내용은 “트리거를 계속 누르기에는 좋은가?”, “현재 목표는 무엇이어야 하는가?”, “그 목표를 전제로 어떤 키 입력을 눌러야 하는가”라는 질문이다. 운영 비용은 1시간에 약 7달러(약 1,120엔)이며, 1초 10회는 1시간으로 36,000회로 계산된다. 1 판단당 약 0.000194달러(약 0.031엔)가 된다. 공식의 묘사에 유머가 있다. “이것을 만든 엔지니어는 매초 10쿼리를 던지는 것을 걱정했지만, 나머지 우리는 ‘생각보다 싸네’로 일치했다.” TypeSafe는 이 데모의 한계도 스스로 쓰고 있다.

이 데모는 텍스트를 포함하는 데이터 구조로서의 구조화된 상태에 대한 것이며, 이미지에 대한 것이 아니었다(아직). AI를 사용하지 않은 DOOM 보트가 더 잘 플레이할 수 있을 것이다. 하지만 우리는 게임 상태의 다른 표현에 반응하는 보트를 원했고, 무엇보다 명령을 따르는 것이 엄청나게 멋있었다. 스스로 쓴 데모는 드물며, 이 데모의 주장은 “DOOM이 강하다”는 것이 아니다. “지금까지 AI를 넣을 수 없었던 루프에 100밀리초의 지능을 넣는” 것이다. Sean Goedecke 씨의 평가가 정확하다. “물론, DOOM을 플레이하는 뉴럴 네트워크는 이미 훈련할 수 있다. 하지만 Jev는 범용적인 지능이다. LLM이 소득 정산, 수학 연구, 파이썬 환경 복구, 시 쓰기 등 다양한 작업을 할 수 있도록 Jev도 하나의 비디오 게임 외에 다른 많은 작업이 가능하다.” 그리고 그는 Nelson Elhage 씨의 말을 인용한다. 빠른 소프트웨어는 같은 일을 더 빠르게 하는 것뿐만 아니라 완전히 새로운 종류의 일을 가능하게 한다.

위키피디아 링크만을 따라 목표 기사로 도달하는 게임이다. TypeSafe가 이 데모를 선택한 이유는 명확하다. “각 단계에서 수백에서 수천 개의 링크 중에서 선택하게 되므로, 단순한 지능의 초당 처리 속도뿐만 아니라 고카디나리티의 선택에서 환각을 피하는 복리적인 이점을 보여주는 완벽한 테스트 환경이다”라는 공식에서 제시한 제한 사항은 3가지다. “우리의 속도 향상 폭은 기존 데모보다 훨씬 작아지는 경향이 있다. 이는 모델의 비추론 모드와 대결하고 있기 때문이다 (Astra는 최소 추론 설정을 사용함). Jev가 더 적은 단계로 완료하는 경향이 있었던 것도 이 때문이며 (더 높은 지능의 증거임). 이는 데모를 보는 데 충분히 가치 있는 것으로 만드는 것이었다. 추론을 활성화하면 LLM은 이 작업에서 훨씬 더 잘 보일 것이다.” Jev는 카디나리티 255까지 지원하며, 더 높은 카디나리티의 선택에서는 독립적으로 점수를 매긴 다음 명시적인 선택을 수행하는 2단계 시스템을 채택한다. 간헐적인 속도 저하는 그 때문이며 “2회차와 3회차 도전 모두 ‘Rubber Duck’에서 시작한 것은 우리가 알고 있는 한 완전히 우연이었다.”

【본문 작성에 관하여】초안에 포함된 “Jev는 0.419초에 완주했으며, 대전한 GPT-5.6 Terra가 존재하지 않는 링크를 답변으로 다시 작성되었다”는 구체적인 내용은 공식 블로그나 주요 보도에서는 확인되지 않았다. 공식적으로 언급된 내용은 고카디내리티로 인해 환각이 발생하지 않는 것의 장점, 비추론 모드와의 비교, Jev가 적은 단계로 종료하는 경향이 있다는 세 가지 사항이다. 데모 영상 내의 표시값일 가능성은 있으나, 1차 자료로 뒷받침되지 않으므로 단정적으로 기록해서는 안 된다.

제11장 기술에 대한 반론과 제브의 기술적 장벽

발표 다음 날인 9월 16일, 엔지니어 Sean Goedecke 씨가 기술적인 검토 기사를 공개했다. 현재 시점에서 가장 내용이 풍부한 독립 분석이며, 원고에 결여되었던 가장 큰 요소였다. 그의 평가는 긍정적인 부분과 부정적인 부분이 모두 포함되었다.

【긍정 측】 “빠른 구조화 출력이 지능을 위한 진정으로 새로운 계산 프리미티브가 될 수 있다. 지금까지 우리는 자기 회귀적인 토큰 생성 위에 많은 프로그램을 만들어왔지만, 그것들은 모두 화려한 챗봇처럼 보였다. 구조화 출력에 전적으로 의존한다면, AI의 비 챗봇 용도를 한 번에 해방시킬 수 있을지도 모른다.” 그는 “다양한 판단점에 100밀리초 분량의 저렴한 지능을 주입함으로써 어떤 새로운 종류의 프로그램이 작성될 수 있을지”를 “Jev에서 가장 흥미로운 점”이라고 부르고 있다.

제(Jev)에 대한 최대 문제는, 빠른 구조화 출력이 이미 가능하다고 생각하는 점이다. 그의 주장은 다음과 같다. 제한된 선택지에서 빠른, 병렬 구조화 출력을 원한다면 자기 회귀 생성은 엄밀히 필요하지 않다. 응답을 “choice”: “로 프리필하고, 사용자가 제시한 선택지에 제한된 1토큰만 생성하면 된다. LLM은 입력 토큰을 병렬로 처리하기 때문에 전체 구조화 출력을 생성하는 것보다 훨씬 빠르다. 여러 선택지는 일반적인 추론 배치 처리로 동일한 포워드 패스에 모아진다. 긴 문장의 구조화 출력을 할 수 없지만, 그 대신 제(Jev)의 ‘비밀 소스’의 대부분이 손에 들어온다. 속도, 일관성, System One 모델의 병렬성이 그것이다. 그는 직접 시도하고 있다. Qwen2.5-1.5B-Instruct로 직접 테스트한 결과, 프리픽스 없는 구조화 출력에 비해 2~3배의 속도 향상을 얻었다고 발표 당일에 다른 개발자들도 이 방법을 시도하고 있으며, 잘 진행되고 있는 것처럼 보인다.

결론적으로, 즉 저는 Jev에게 실질적인 기술적 장벽이 없으며, 그들이 주장하는 “교정된 판단을 위한 강화 학습”이 완전히 새로운 스케일링 축이 아니라고 의심합니다. 다른 연구실에서도 재현하는 것은, 혹은 개별 프로그래머가 기존 오픈 소스 LLM을 빠른 Jev 모델로 변형하는 것이 아마도 상당히 간단할 것입니다.

하지만 전적으로 부정하는 것은 아니며, 저는 Jev가 ‘Qwen-32B-System-One’과 같은 모델들보다 우월할 것이라고 의심하고 있습니다. 구조화된 출력을만으로 모델을 미세 조정하고 최적화할 수 있다는 점은 분명히 의미 있는 우위라고 생각합니다. 그는 RLCD 교정 문제에 대해서도 예외적인 입장을 보입니다. Jev가 생성하는 확률이 ‘교정되었다’고 주장하지만, 그것이 일반적인 로짓 확률과 다르다는 증거를 보지 못했으며, 불확실한 상황에서 정확한 로그 확률을 내도록 하는 어떤 지혜로운 훈련이 있을지도 모른다고 추측합니다. 만약 그렇다면, 발표에서 그에 대해 더 자세히 설명했으면 좋았을 것입니다.

“Jev의 가치가 모델 자체에 얼마나 존재하는지, 그리고 질문마다 1 토큰만 생성한다는 추론 전략에 얼마나 의존하는지는 아직 명확하지 않다. 발표된 데이터와 데모를 통해 볼 때, Terra 크기의 어떤 모델이라도 단일 토큰 추론 스택에 삽입하면 동일하게 생성되는 것처럼 보인다.” 그는 긍정적으로 마무리하며 “전반적으로 Jev가 존재하게 되어 기쁘며 성공을 기원한다. 고속 구조화 출력 분야에서 진정한 경쟁이 일어나, 대규모 연구소들이 자신들의 모델을 이 용도에 맞게 미세 조정된 공식 버전을 출시하도록 동기 부여받을 수 있기를 바란다. GPT-5.6-Terra-System-One은 AI 제품을 만드는 기반으로서 매우 흥미로운 모델이 될 것이다”라고 말했다. 이는 Jev의 가장 근본적인 제약 사항이라는 Goedecke의 지적이다. “Jev가 프론티어 LLM처럼 똑똑해질지는 의심스럽다. 테스트 시 계산을 전혀 사용할 수 없는 것은 큰 불리함이며, 이 유형의 모델을 비추론 LLM의 강점 수준으로 멈추게 할 가능성이 높다.”

실제로 저지연 애플리케이션에서는 이것이 큰 문제가 되지 않을 것입니다만, 이것을 새로운 스케일링 축이나 더 지능적인 모델을 만드는 방법으로 보아서는 안 됩니다. 그는 부록에서 도피 가능성을 언급하고 있습니다. 고정 횟수 루프를 하는 루프형 트랜스포머와 같은 것은 가능할 것입니다. 하지만 추론과 유사한 것을 한다면, 지연은 느리고 예측 불가능해지고 궁극적인 목적 자체가 무너집니다. 즉, Jev는 설계상 속도와 지능의 균형을 속도에 치우치게 하고 있습니다. 그리고 그 균형은 나중에 취소할 수 없습니다. 제21장의 업무별 데이터가 이러한 제약을 뒷받침합니다. 짧은 문장에서 의도와 감정을 읽는 일(고객 서비스 76.0%)은 잘 합니다. 여러 문서를 엮어 일관성을 검증하는 일(청구서 처리 61.8%)은 못 합니다. 공식 문서 또한 동일한 제약을 이용자에게 맞는 지침으로 작성하고 있습니다. “System One 모델은 빠르고 집중된 판단을 위해 만들어졌으며, 적절한 맥락이 주어진 통찰력 있는 사람이 1초 안에 내릴 수 있는 판단을 요구합니다. ‘이 메시지는 긴급성을 전달하고 있습니까?’는 좋은 질문입니다. ‘이 메시지를 분석하여 최선의 행동 방침을 결정하시오’는 좋지 않습니다. 그것은 느린 추론을 필요로 하고, 작업을 작은 질문으로 나누어 코드와 결합해야 한다는 신호입니다.”

이는 제약에 대한 고백인 동시에 올바른 사용법에 대한 설명이기도 하다. “System One”이라는 이름은 다니엘 카네만의 『빠르고 느린 생각』에서 유래했다. 공식 설명에 따르면 “모델 클래스의 이름은 빠르고 직관적인 System 1 사고와 느리고 신중한 System 2 추론의 구분을 나타낸다.” 동시에 공식은 스스로 이 비유의 약점을 인정하고 있다. “System 1 사고”는 오류를 일으킬 가능성이 있다는 함의를 내포했기 때문이다. 이 점을 자세히 설명할 이유가 있으므로, 우리는 System One 모델을 대체 수단보다 더 신뢰할 수 있는 것으로 간주하고 있다. 여기에 더 깊은 보류를 덧붙여야 한다. 고에데크 氏は 주해에서 카네만의 이중 과정 이론이 “부분적으로 부정되었으며” 재현성 문제를 다룬 기사로 연결되어 있다고 언급하고 있다. 『빠르고 느린 생각』에서 소개된 연구 중 일부, 특히 프라이밍 효과에 관한 장은 이후 재현성 위기 속에서 크게 흔들렸다. 카네만 자신도 이후에 해당 부분에 대해 공개적으로 보류를 표명했다.

그러므로 “System 1/System 2”는 뇌과학적으로 확립된 사실이라기보다는 편리한 비유로 취급하는 것이 더 정확하다. 제브의 기술적 주장은 이 이론이 옳지 않든 그렇지 않든 독립적으로 성립한다. 이름의 유래와 기술의 타당성은 분리하여 평가해야 한다. 또한 AI의 추론을 고속층과 숙고층으로 나누는 발상은 TypeSafe만의 독점적인 것이 아니다. 고에데크 박사 스스로도 Thinking Machines사의 “interaction models”에 대해 이전에 논문을 발표했으며, 이를 “충분히 빠르면서 의미적으로 다른 패러다임”으로 간주하고 있다. TypeSafe의 FAQ는 제브에 대해 소형 LLM이 아니라고 설명하고 있다. 회사 측은 명확하게 제브를 또 다른 모델 클래스로 취급하고 있다. 그러나 공개된 자료만으로는 그 경계를 기술적으로 확정할 수 없다. 공식 문서의 AI 프라이머는 사전 학습된 언어 모델이 RLHF와 RLVR로 적응되어 온 흐름을 보여주고 있으며, 그 위에 “TypeSafe는 제3의 길을 더한다”고 하여 RLCD를 배치하고 있다.

이는 최소한 RLCD가 사전 학습된 언어 모델 연구의 연장선상에 있음을 시사한다. 반면, 론치 FAQ에서는 Jev가 LLM이 아니라고 한다. 가능한 구성은 여러 가지가 있다. 방대한 언어 이해 트랭크를 가지지만, 자기 회귀 텍스트 디코더는 없애고 판단 헤드에 대체한 모델이다. 언어 모델의 사전 학습을 활용하면서, 사후 학습 후 서빙 구성이 일반적인 LLM과 크게 다른 모델이다. 혹은, TypeSafe가 말하는 “새로운 아키텍처”가 더 근본적인 변경을 포함할 가능성도 있다. 모두 추측이다. Hacker News의 기술자들도 인코더만 사용하는 Transformer에 분류 헤드를 붙인 것, 간소화된 텍스트 확산 모델 등 여러 가설을 제시했지만 결론을 내려놓지 못했다. Almeida氏は“현재로서는 손 안에 있는 것을 밝히지 않겠다”고 답했다. 파라미터 수, 기반 체크포인트, 어텐션 구조, 디코더, 판단 헤드, 샘플링 구현이 공개될 때까지 단정할 수 없다.

이 불투명성이 남아있는 숙제다. Sean Goedecke 씨의 “기존 LLM + 프리필 + 1 토큰 제약 디코딩으로 대부분을 재현할 수 있다”는 반론은 이 불투명성 때문에 결론을 내리지 못하고 있다. 만약 Jev의 우위성의 대부분이 서빙과 샘플링의 공학이라면, 대규모 연구소도 쉽게 따라올 수 있다. 만약 RLCD와 전용 아키텍처가 큰 능력 차이와 교정 차이를 만들어낸다면, TypeSafe에는 더욱 강력한 기술적 장벽이 있을 것이다. 현재 시점에서 그 차이를 구분하기 위한 정보가 부족하다. 또한 Almeida 氏가 스스로 “제로샷 분류기다”라는 지적에 “정말로 그렇다”라고 답한 것으로 인해 이 질문은 오히려 더 복잡해졌다.

개발러스IO는 9월 17일, Jev의 Choice에 “ひらがな＋句読点＋END”의 88가지 선택지를 제공하고, 이전 출력을 state에 더하여 1자씩 선택하는 실험을 공개했다. 이는 Jev가 일반적인 언어 모델처럼 자유 텍스트를 autoregressive generation하는 API가 아니더라도, 반복적인 Choice decision을 묶으면 문자열과 유사한 것을 구성할 수 있음을 시사한다. 하지만 이는 Jev의 주요 용도가 아니다. 오히려 중요한 점은 TypeSafe가 생성 능력을 제품 인터페이스에서 의도적으로 배제하고 decision primitive에 최적화했다는 것이다. “문자열을 절대 생성할 수 없는 물리적 구조인가?”와 “API로서 자유 형식 생성 제공하지 않는다”는 질문은 다른 문제이며, 아키텍처가 비공개이므로 전제 단정하기 어렵다.

제12장 외부 검증 결과

발표 직후 공개된 최초의 체계적인 제3자 실측 중 하나이다. 미디어 Every의 평가 책임자 마이크 테일러 氏가 Jev에 초기에 접근하여 실측을 수행했다. 이 氏 또한 오라이언의 『Prompt Engineering for Generative AI』 공저자이기도 하다.

【테스트 1――37문서×21문제】대상은 Every가 공개한 기사 27본과, 의도적으로 AI다운 문체로 작성한 10본, 총 37문서. 각각에 21개의 질문을 던져 모두를 묶어 1개의 요청으로 만들었다. 결과, 777건의 판단이 0.7초 미만으로 반환되었으며, 추정 비용은 약 0.25센트(약 0.4원). 1초당 약 1,110건의 판단, 1건의 판단당 약 0.0000032달러(약 0.0005원)였다. Taylor 氏は11가지 시나리오를 시험하여 총 1,709건의 판단을 1센트 미만으로 획득했다.

제프는 AI에 의존한 자신의 기사를 정확하게 감지했다. 하지만 실제 투입 전에 더욱 철저한 정확성 검증을 실시하고 싶어 한다. 그럴 때나마 좋은 결론이 나올 것이다. 조기 경고 시스템으로서 유용하며, 대안은 “검사를 전혀 하지 않는” 것보다 훨씬 낫다.

【테스트 2――장치 오류를 찾아낼 수 있는가】Every의 CEO가 진행한 두 번째 테스트는 정확도를 직접적으로 측정하고 있다. 12개의 합성 문장을 준비했다. 그 중 6개는 정상적인 문장이고, 6개에는 의도적으로 장치 오류를 심었다. 그 문장들을 4가지 유형의 문장 검사 시스템에 투입했다. Jev는 문장당 평균 0.35초, Claude Fable 5.1 (고성능 설정)은 8.83초가 소요되었다. 약 25배 빠른 속도이며, 비용은 약 580분의 1이다. 그리고 정확도다. Jev는 심어진 7개의 오류 중 6개를 감지했고, Fable 5.1은 모든 7개를 감지했다. Every의 평가는 “좋지만 완벽하지는 않다”였다.

이 검증은 다음과 같이 3가지로 정리할 수 있다. 속도 및 비용에 대한 주장은 제3자에게도 유효하다. 정확도는 프론티어 모델보다 1단위 낮다. 표본 크기가 너무 작아 실제 운영 가능성을 판단할 만한 근거가 되지 않는다. 이는 21장 워크플로우 eval(Jev 67.8%, Opus 5 73.1%)과 동일한 방향을 제시한다. 공급업체 평가와 독립 검증 모두 정확성 측면에서 일치한다. 이러한 점은 TypeSafe의 숫자 처리 방식을 판단하는 데 도움이 된다. 속도와 비용은 과장된 측정이 아니다. 현명함에 대한 주장은 처음부터 제시되지 않았다.

【여기 근처】영국 지역 이벤트 서비스 Near Here는 이벤트 게재 제외 판정이라는 좁은 실타스크에서 Jev, Mistral Small 4, Gemini 3.5 Flash-Lite를 비교했다. 50건의 메인 테스트 세트：

제브: 48/50, 96%
Gemini 3.5 Flash-Lite：43/50、86%
미스트랄 Small 4: 42/50, 84%

다른 21건:

제브: 19/21
제미니: 20/21
미스트랄: 19/21

21개 모델의 중앙값 레이턴시는 Jev는 0.58초, Mistral은 2.73초, Gemini는 3.44초였습니다. 추정 비용은 Jev는 1,000건의 판단당 0.043달러, Mistral은 0.370달러, Gemini는 2.496달러였습니다. 오차 방향에 대한 보고도 있었습니다. Jev는 유효한 이벤트를 1건도 잘못 거부하지 않았습니다. 반면 Mistral은 5건, Gemini는 1건을 잘못 거부했습니다. 掲載 서비스 입장에서는 이 비대칭성이 종합 정답률보다 더 중요하게 작용할 수 있습니다. Near Here 스스로가 X에서 요약한 내용은 “최대 5.7배 빠르고, 98% 저렴하며, 정답률 12점 높음”입니다. 다만, 해당 회사는 “개별적으로 튜닝한 프롬프트로”라는 조건을 덧붙이고 있습니다. 이는 중요한 반례입니다. Jev는 TypeSafe의 4가지 업무 평균에서 최상위 모델보다 정확도가 낮지만, 작업이 좁고 질문 형식에 Jev가 맞다면 비교 대상이 정확도 면에서 우세할 수 있습니다. 다만 Near Here 스스로가 주의하고 있습니다. 50건은 프롬프트 선택에도 활용되었으며, 21건은 편향된 소규모 샘플일 뿐입니다. 이는 production accuracy의 추정치로 볼 수 없으며, “특정 용도에 대한 적합성 테스트”라고 읽어야 합니다.

또 다른 중요한 점은 jev-latest로 요청한 응답이 jev-1.13.0을 반환했다는 보고이다. Alias는 업데이트될 수 있다. 임계값을 조정하여 프로덕션 환경에 적용한다면, 실제 응답한 버전 ID를 반드시 로그에 기록하고, 가능하다면 평가 시와 프로덕션 환경에서 버전을 고정해야 한다.

클래스메ethod 말레이시아의 모렌가 다이지 氏は、LLM 라우팅의 분류기를 제프의 큐오트へ 대체하여 검증했다. 분류는 simple/medium/complex/reasoning의 4가지 종류이며, 각 종류별로 10회씩, 총 40회 진행했다. 결과는 40회 모두 API 성공이었고, 4가지 패턴 모두 10/10회로 예상되는 티어에 분류되었다. 중앙값 레이턴시는 다음과 같다.

단순: 0.661초
중간: 0.651초
복잡도: 0.674초
이유: 0.643초 1차 번역문: 그렇습니다. 2023년 5월 25일, 저는 ‘마법의 숲’이라는 제목의 책을 읽었습니다. 이 책은 1998년에 출간되었으며, 작가 사토 히로시가 쓰고 그린 그림을 담고 있습니다. 저는 이 책을 읽으면서 숲 속에서 길을 잃은 어린 소녀 미나의 이야기를 따라가며 그녀가 숲의 정령들과 만나면서 겪는 모험과 성장을 지켜보는 것이 즐거웠습니다. 특히 미나가 숲의 정령 코코로와 친구가 되어 함께 숲을 지키는 모습은 감동적이었고, 코코로의 지혜와 용기를 통해 미나가 어려움을 극복해 나가는 모습은 저에게 큰 영감을 주었습니다. 이 책은 단순한 모험 이야기뿐만 아니라 자연과 인간의 조화, 그리고 서로를 존중하는 마음의 중요성을 일깨워주는 교훈적인 내용도 담고 있습니다. 저는 이 책을 통해 자연에 대한 사랑과 존중의 마음을 배우고, 어려움에 굴하지 않고 자신의 꿈을 향해 나아가는 용기를 얻었습니다. 저는 ‘마법의 숲’을 읽고 난 후 숲 속을 산책하며 코코로와 함께 숲을 지키는 소녀 미나를 상상하며 즐거운 시간을 보냈습니다. 그리고 이 책을 통해 얻은 교훈들을 실생활에 적용하여 자연과 더불어 살아가는 삶을 더욱 의미 있게 만들어갈 것입니다. 이 책은 저에게 잊을 수 없는 추억을 선물해 주었고, 앞으로도 오랫동안 제 마음속에 남아있을 것입니다.

1콜의 추정 비용은 약 0.000025~0.000027달러이다. 해당 기사가 비교한 기존 분류기에서는 Gemini 3.5 Flash가 중앙값이 2.1초, DeepSeek V4 Flash가 7.2초였기 때문에, 이번 조건에서는 Jev가 약 3배, 약 10~11배 고속이었다. 비용 비교는 단위가 다르므로 단순화할 수 없다. 원본 기사의 NeMo Switchyard 측에서는 세션 단위로, Gemini 3.5 Flash가 0.70달러/세션, DeepSeek V4 Flash가 0.0004달러/세션이었다. 이번 Jev는 콜 단위이다. 그럼에도 불구하고 1판정당 비용이 桁으로 다른 것은 확인해 볼 수 있다. confidence의 행동 또한 시사적이다. simple, complex, reasoning은 모두 confidence 1.0으로 망설임 없이 분류되었지만, medium만 0.57~0.67로 낮았다. 경계선상의 케이스에서 판정이 흔들리는 것이, 확률 분포에 솔직하게 반영되어 있다. LLM의 텍스트 분류에서는 얻기 힘든 성질이다.

가장 실질적인 발견은 연결 실패일지도 모른다. NeMo Switchyard의 분류기는 OpenAI Chat Completions과 같은 정해진 형식을 대상으로 하는 설계로 구성되어 있어, TypeSafe의 /v1/systemone을 그대로 base_url에 지정하여 연결하는 것이 불가능했다. 어댑터를 사용하거나 Switchyard를 라이브러리로 통합해야 한다. 해당 기사는 TypeSafe 자체의 워크플로우 평가(Jev 67.8% 대비 최적 74.1%)를 “별도의 독립적인 제3자 검증(Every社)”이라고 표현하고 있지만, 이는 TypeSafe의 벤더 평가이다. Every의 검증은 완전히 다른 것이므로, 인용 시 혼동하지 않도록 주의해야 한다. 여기서 중요한 것은 공식적으로 제시된 70~500ms를 절대적인 값으로 취급하지 않고, 실제 애플리케이션에서 발생하는 end-to-end 지연 시간은 지리, 네트워크, 입력 길이, 혼잡, SDK 처리 등 다양한 요소를 포함한다는 점이다.

【YTAL】株式会社YTAL은 업무 자료에서 구축한 그래프의 일치 처리를 실제 운영 중인 저장된 로그와 동일한 입력으로 로컬 재생했다. 대상은 67건의 자료, 525개의 노드였다. 후보가 있던 423개의 노드에 대해 423회의 HTTP 요청을 수행했으며, 입력 데이터는 765,035 토큰이었다. 공개 단가 환산 시 Jev의 추계 비용은 약 0.0321달러, HTTP 시간 총합은 101.398초, 1회 요청의 중앙값은 약 220ms였다. 기존의 실제 운영 처리 1회분과 단순한 비교에서는 Jev 단체의 요금이 약 4%, 즉 약 96% 저렴했다. 그러나 여기서 결론을 서두르지 말아야 한다. 실제 운영의 44건의 병합 중 Jev가 동일한 병합을 수행한 경우는 20건이었고, 반면 Jev가 다른 클러스터였던 것을 병합한 경우는 19건이었다. ground truth가 없으므로 20/44를 recall(재인식률)이라고 부르거나 19건을 오통합이라고 부르는 것은 적절하지 않다. 더 나아가 YTAL은 잠시 동안 “Jev는 보류가 많아 명요제에 까다롭다”는 결론을 내리려고 했으나, TypeSafe의 Cookbook와 비교하여 철회하고 수정했다.

요리책 수준의 0.5/1.5 임계값에서는 페어 단위 보류 건수가 5,285건 중 686건, 13.0%였다. 그러나 자체 집계 규칙으로 노드 단위로 집계하면 525건 중 208건, 39.6%까지 증가했다. 즉, 모델의 1가지 판단 정확성만으로는 시스템 품질이 결정되지 않는다. 질문 단위, 후보 생성, 임계값, 집계, 폴백 설계에서 최종 KPI가 크게 변동한다. 이는 TypeSafe가 주장하는 “컴포저블 AI”를 평가하는 데 있어 공식 벤치마크 이상으로 실무적인 교훈일지도 모른다.

【DSPy의 소규모 PoC】TypeSafe 관계자가 주도한 DSPy 통합 PoC에서는 워크플로우의 판단 단계 일부를 Jev로 대체한 3가지 경우에서, end-to-end 기준으로 15.9%의 속도 향상, 30.1%의 비용 절감이라는 수치가 보고되었다. 부품이 100배 더 빠르더라도 전체 시스템이 100배 더 빨라지는 것은 아니다. Jev 도입 효과를 확인하는 데에는 반드시 워크플로우 전체의 wall clock 시간과 총 비용으로 측정해야 한다. 9월 17일, 브라우저 에이전트 개발사인 Aera가 “Agent memory doesn't need a generator: TypeSafe's Jev vs. LLM on 400 real tasks”를 공개했다. 이는 Jev의 외부 검증으로서 중요한 것이다. 단순한 합성 분류가 아닌, 실제 작동 프로필로부터 수주에 걸쳐 발생하는 real work를 재연성하고, 에이전트가 과거의 memory 후보를 선택하는 과정을 LLM에서 Jev로 대체하는 것이다.

연구는 오프라인 벤치마크이며, Aera는 “2026년 9월 16일 현재 production release가 TypeSafe로 데이터를 보내고 있지 않다”라고 명시하고 있다.

400건의 구성

아직 124에서 시작된 대화는 마치 엉뚱한 방향으로 흘러가는 것처럼 느껴졌다. “그래서, 그 책에 대해 어떻게 생각해?” 마츠모토가 물었다. 그는 며칠 전 ‘고독한 숲’이라는 제목의 소설을 읽고 난 후, 꽤 격렬하게 자신의 생각을 이야기하고 있었다. “솔직히 말해서, 나는 그 책이 너무 뻔했어.” 그의 목소리는 약간 짜증 섞인 듯했다. “이야기의 전개가 예측 가능했고, 등장인물들의 감정 변화도 지나치게 과장된 느낌이었어. 마치 작가가 너무 쉽게 이야기를 풀어나가려고 했던 것처럼 느껴졌지.” 옆에 앉은 사토는 고개를 끄덕였다. “나도 그랬어. 특히 주인공 ‘카즈키’의 고독함이 너무 억지스럽게 묘사된 것 같았어. 마치 작가가 ‘고독’이라는 단어를 너무 많이 사용한 것처럼 느껴졌지.” 마츠모토는 잠시 생각하더니 다시 말을 이어갔다. “하지만 ‘카즈키’의 과거 이야기가 흥미로웠어. 특히 그의 아버지 ‘켄지’가 ‘붉은 달’이라는 책을 읽고 겪었던 일들이 ‘카즈키’의 행동에 영향을 미치는 중요한 요소로 작용했어.” “‘붉은 달’은 꽤 유명한 책이라고 들었어. ‘아카가키 히로시’가 쓴 책이지?” 사토가 물었다. 마츠모토는 고개를 끄덕였다. “맞아. ‘아카가키 히로시’는 일본 문학계에서 굉장히 유명한 작가야. 그의 작품은 주로 인간의 내면 심리에 대한 깊이 있는 탐구를 보여주지.”
런 리뷰: 70
예정된 실행: 82
대리인 하도급업체: 124
총액은 400입니다. 그렇다고 해서 모든 것을 한 번에 해결할 수 있다는 의미는 아니라는 점을 분명히 하고 싶습니다. 특히 ‘가쿠노’의 경우, 그가 겪은 고통은 상상하기 어려울 정도로 끔찍했습니다. 그는 끊임없이 자신을 비난하고, 자신의 행동에 대한 책임을 지려고 노력했지만 결국에는 그 고통을 극복할 수 없었습니다. 그의 이야기는 우리에게 중요한 질문을 던져줍니다. 우리는 타인의 고통을 어떻게 이해하고 공감할 수 있을까요? 우리는 타인의 고통을 묵과할 권리가 있을까요? 우리는 우리 자신의 행동이 타인에게 어떤 영향을 미칠 수 있는지 항상 경계해야 할까요? ‘가쿠노’의 이야기는 우리에게 단순한 연민을 넘어선 깊은 성찰을 요구합니다. 우리는 ‘가쿠노’의 고통을 통해 우리 자신의 삶을 돌아보고, 우리 자신의 행동에 대한 책임을 지는 법을 배워야 합니다. 또한, ‘가쿠노’의 이야기는 우리에게 희망을 주는 메시지를 전달합니다. 그는 자신의 고통을 극복하고 새로운 삶을 시작하는 데 성공했습니다. 그의 이야기는 우리에게도 용기를 주고, 우리 자신의 삶을 긍정적으로 살아갈 수 있도록 격려합니다. ‘가쿠노’의 이야기는 우리에게 단순한 이야기가 아닙니다. 그것은 우리에게 삶의 의미를 되새기고, 우리 자신의 삶을 더욱 가치 있게 만드는 기회를 제공합니다. 우리는 ‘가쿠노’의 이야기를 통해 우리 자신의 삶을 돌아보고, 우리 자신의 삶을 더욱 의미 있게 만들어갈 수 있습니다. 이 모든 것을 고려할 때, ‘가쿠노’의 이야기는 우리에게 단순한 슬픔을 넘어선 깊은 감동과 깨달음을 선사합니다.

역사적 관점에서 GPT-5.6 Luna를 판단하면서 “시작 전에 무엇을 알아야 했는지”를 추출하고, 또 다른 매칭 모델이 selector가 전달한 아이템이 유용한지, 노이즈인지, 필요한 정보를 충분히 담고 있는지 평가했다. 판단자와 매칭 모델이 공통으로 인정한 199개의 아이템에 대해 일치율이 79%라는 결과가 나왔다. 평가 자체의 불확실성을 고려할 수 없다.

미관리 업무 276건에 대해 LLM 선택자와 Jev에게 동일한 후보 풀을 제시했다.

보도율: 46%
정밀도：79%
미디어/P95: 463/707ms
비용: 0.00028／케이스

저는 아직 해당 note.com 게시글의 본문 청크 180/354를 제공받지 못했습니다. 게시글의 내용을 제공해주시면, 일본어 출판·문화 콘텐츠 전문 한국어 번역가로서 자연스럽고 정확한 한국어 번역문을 100% 출력해 드리겠습니다.

보도율: 46%
그러므로 본 문건의 182/354번 청크는 다음과 같습니다. “이 기획의 목적은 독자가 자신의 관심사에 맞는 작품을 더 깊이, 더 깊이 이해할 수 있도록 돕는 것입니다. 구체적으로, 독자가 작품을 읽어가는 과정에서 작품의 배경에 있는 역사적, 문화적, 사회적 요소를 이해하기 위한 정보를 제공하며, 작품을 읽은 후에도 더 깊이 탐구할 수 있는 자료를 제시합니다. 이 기획은 독자의 독서 경험을 풍부하게 하고, 독서를 통해 지식과 교양을 쌓는 것을 목표로 합니다. 독서는 단순히 글을 읽는 것을 넘어 상상력을 자극하고 사고력을 향상시켜 삶을 풍요롭게 하는 소중한 경험입니다. 이 기획을 통해 독자는 자신의 관심사에 맞는 작품을 찾고, 그것을 깊이 이해함으로써 더욱 풍요로운 삶을 살아갈 수 있다고 믿습니다.”
메디언/P95: 147/271ms
비용: 0.00017／케이스

같은 커버리지에서 제프는 노이즈를 줄여 중앙값으로 약 3분의 1 시간으로 단축했다.

124 체스트 시작에서는 Jev의 저비용/저지연을 활용하여 후보 풀을 28에서 150으로 확장하는 방안을 시도했다. Jev 와이드 풀 + 두 번의 패스를 사용했을 때, 커버리지 46%, 정밀도 72%, 중앙값/p95 441/709ms, 비용 $0.00123/체스트의 결과를 얻었다. Aera 스스로가 작성한 것처럼, Jev는 “1 체스트당 LLM보다 더 많은 정확한 메모리를 찾는 마법의 파인더”가 아니다. 제약 기한이 없는 LLM과 비교했을 때, Jev가 더 나은 30 체스트, 더 나쁜 29 체스트, 같았던 65 체스트였다. 주요 차이는 정밀도, 속도, 예측 가능성에 있었다.

Aera는 13,947명의 후보자와 124개의 채팅 시작을 포함하는 광범위한 풀을 매치어에게 점검하게 하고, Jev의 Noul 확률과 “유용했는가”를 비교했다.

제브 0.4 ~ 0.5: 47%가 유용함
제브 0.7 ~ 0.8: 88%가 유용함
유용한 후보자를 노이즈보다 높은 순위에 배치한 AUC: 0.82

또한 “특별한 보정 없이도 신뢰도 곡선이 대각선에 가까웠다”고 언급하고 있다. 이는 RLCD를 완전히 입증하는 것이 아니다. 레이블은 매칭 모델에서 비롯되었으며, 하나의 프로필, 하나의 용도, 1일 Jev 빌드 결과이다. 그럼에도 불구하고 “0.8이라는 숫자가 단순한 랭킹 점수가 아닌 운영 임계값으로 해석될 수 있는가”라는 질문에 대한 현재 시점에서 가장 구체적인 외부 데이터 중 하나이다.

[실패 사례와 스테이트 엔지니어링] 에라는 필요한 정보가 브라우저 화면 상에만 존재하고, Jev에게 전달된 스테이트에 존재하지 않는 경우 등 실패 사례를 기록하고 있다. 이는 시스템 원 설계의 기본을 보여준다. 모델은 스테이트에 없는 사실을 정확하게 판단할 수 없다. Jev를 사용하는 경우, 프롬프트 엔지니어링보다 먼저 스테이트 엔지니어링이 중요하다.

제13장 워크플로우 분해 및 책임 명확화

리뷰어들이 지속적으로 지적하는 실무상의 쟁점이다. Jev는 확률을 반환하지만, 자연어의 이유를 반환하지 않는다. 디버깅과 규제업종의 감사를 포함하여, 이는 현실적인 제약이 된다. 컴플라이언스 부서가 “왜 이 담보 신청이 이렇게 점수되었는가”를 알 필요가 있을 때, confidence의 숫자만으로는 설명이 될 수 없다. 실무적인 회피책은 명확하다. 방대한 라우팅 계층에 Jev를 사용한다. 플래그가 立った 사건과 저 confidence의 사건은 문장으로 설명 가능한 모델로 에스컬레이션한다. 이렇게 하면 스루프트를 유지하면서 법적으로 필요한 장소에는 감사 증적이 남는다. 이는 TypeSafe 자체의 권장과도 일관성이 있다. 공식적인 “Intent routing” 패턴은 수신 요청을 분류하고 각각을 최적의 핸들러(확정적인 로직, 전문 LLM, 혹은 인간)로 분배하는 설계이다. 즉, Jev는 설명 책임이 필요한 최종 판단을 내리는 장소는 아닌데, 그곳에 이르기 전에 분류하는 전 단계에 위치해야 한다.

일본의 금융기관이나 상장기업에서 사용될 경우, 이 선입견은 먼저 결정해야 한다. TypeSafe는 이 용도를 스스로 “스마트 if 문”이라고 부른다. 매니페스트의 한 문장이 사상의 핵심이다. “컴퓨터는 비트에서 분기하든 얼마나 많은 일을 할 수 있을까 상상해 보게. 만약 일반적인 지식, 이해, 의도에서도 분기할 수 있다면.” 그리고 주석에서 그 연관성을 명시하고 있다. “이는 뉴로심볼릭 AI의 꿈이다. 인지 위한 신경망과 추론을 위한 기호 논리를 결합한다. 때때로 ‘스마트한 if 문’이라고 장난스럽게 요약된다.” 이는 원고에 부족했던 논점이다. “AI 버전 if 문”은 우연한 슬로건이 아닌, AI 연구에서 수십 년 동안 논의되어 온 뉴로심볼릭 AI의 연관성에 자신을 위치시키는 선언이다. 구체적으로는 다음과 같이 된다. 기존 코드에서는 금액과 같은 수치적 조건으로 분기한다. Jev를 사용하면, 부정확률과 같은 의미적 판단으로 분기할 수 있다.

다만, TypeSafe는 일반적인 if 문까지 AI로 대체하는 것을 권장하지 않는다. 매니페스트의 표현은 다음과 같다. “AI는 모든 프로그래머가 의미적 판단과 결정하기 위해 호출할 수 있는 프리미티브로서, 기존 소프트웨어와 함께 작동시키고 싶다. 반면 코드는, 그것이 가장 잘 할 수 있는 것, 즉 정확한 계산에 사용을 계속해야 한다. 분담의 원칙에 따라 정확하게 계산할 수 있는 것은 일반적으로 코드로 판단해야 하며, 다음과 같은 판단은 Jev에 적합하다. 이 고객이 화가 났는가? 이 문의는 긴급한가? 이 주문은 부정한가? 이 이메일은 법무 부에 보내야 하는가?”

제14장 에이전트와 차세대 AI 아키텍처

제브가 실제로 보여주는 것은 AI 아키텍처의 분해이다. 이전에는 한 층이었고, 모든 것을 LLM에 투입하는 방식이었다. 이제는 세 층으로 구성될 수 있다.

시스템 2: 심층 추론층] 심층적인 추론, 계획 수립, 코드 생성, 연구 활동을 수행한다. 담당 모델은 GPT-6 Astra, Claude Fable, Gemini 등 최첨단 모델이다.

【시스템 1：고속 판단 계층】 분류, 라우팅, 점수 산정, 도구 선택, 위험 평가, 승인, 검증. 담당자는 Jev형 시스템 원 모델입니다.

【정형화된 소프트웨어 계층】 규칙, 데이터베이스, API, 워크플로우, 계산을 담당하는 핵심 인력은 기존 코드 기반입니다. TypeSafe의 매니페스트는 이 계층 구조를 가능하게 하는 조건을 “안전성”이라고 정의하며, “안전성은 계층 구조의 전제 조건이다. 신뢰할 수 있는 부품이기 때문에 무인 운영이 가능하며, 그 위에 다른 요소를 구축할 수 있다. 의존 관계를 시스템의 5계층 아래에 구현하기 위해서는 신뢰가 필수적이다. 이는 검토 가능하고, 테스트 가능하며, 제약 조건을 적용할 수 있는 경우에만 가능하다는 논리와 일치한다.” Jev에 대한 가장 엄격한 요구 사항 역시 동시에 존재합니다. 67.8%의 정확도를 가진 모델이 갖춰야 할 신뢰성은, 5계층 아래에 구현될 수 있을 만큼 충분해야 한다. 따라서 제18장 ‘신뢰도 설계’와 제32장 ‘상위 이행 설계’가 중요하다. 현재 에이전트는 종종 하나의 대규모 LLM에 문맥 이해, 계획 수립, 추론, 도구 선택, 분류, 라우팅, 검증, 응답 생성 등 모든 기능을 맡기고 있습니다.

이는 비용이 많이 들고 처리 속도도 느립니다. 향후에는 업무 분담이 이루어질 가능성이 있습니다. 100번의 판단 중 70회는 Jev 모델이 처리하고, 20회는 소형 LLM이 처리하며, 8회는 중규모 추론 모델이 처리하고, 2회는 최첨단 모델이 처리합니다. 이렇게 되면 에이전트 전체의 비용과 지연 시간이 크게 감소합니다. 이 세계에서는 단순한 모델 성능뿐만 아니라 다음 설계가 결정적으로 중요해집니다. 하이픈(ハーネス), 오케스트레이터, 모델 라우팅, 신뢰도 임계값, 에스컬레이션 정책 등이 있습니다. TypeSafe 공식 문서에는 이 업무 분담을 직접 지지하는 레시피(クックブック)가 있습니다. “Skill suggestion”은 Nous Research의 Hermes 카탈로그에 있는 182개의 스킬 중에서 해당 턴에 사용할 스킬을 최대 1개 선택합니다. 1차 요청에서 모든 스킬을 순위 지정하고, 스킬이 필요한지 여부도 동시에 확인합니다. 2차 요청에서 상위 3개의 본문을 제대로 읽어주고, 전부 거부할 수도 있습니다. “Guardrails for LLMs”은 LLM 앱의 모든 입력 및 출력을 1차 요청으로 검사합니다. “이는 제보깨기 시도인지”와 같은 위험을 기술하고, “따랐을 경우 얼마나 해로운지”로 심각도를 점수화합니다.

RAG 패스지 분류는 검색을 통해 얻은 각 패스지를 평가하여 답변 모델에 전달할 내용을 코드로 결정한다. 질문과 모순되는 내용을 유지하고, 숨겨진 지시나 프롬프트 주입을 포함하는 경우 제거한다. 인용 확인은 Choice 질문 1개로 인용이 원천에서 뒷받침되는지 판단하고, 신뢰도에 따라 인간 검토에 플래그를 지정한다. 즉, TypeSafe는 Jev를 “에이전트의 대체물”이 아닌 “에이전트의 수호자이자 교통 관리자”로 판매하고 있다. OpenClaw와 같은 에이전트 런타임에서도 Jev 유형 모델이 중요해질 수 있다. 예상되는 구성은 다음과 같다. 사용자 요청이 들어오면, 프론티어 모델이 전체 계획을 수립하고, Jev가 도구를 선택하며, Jev가 위험을 평가하고, 도구를 실행하며, Jev가 결과를 검증한다. 필요한 경우에만 프론티어 모델로 다시 되돌린다. 이 구성은 프론티어 모델 호출 횟수를 크게 줄일 수 있다.

TypeSafe가 공개하고 있는 4가지 패턴이 거의 이에 해당한다.

【추론 기반 분산】다수의 질문을 1회 호출에 전송하며, 사용 여부가 불확실한 투기적 질문까지 포함한다. 질문의 선택은 코드가 결정한다.

신뢰도 기반 라우팅은 신뢰도를 제2의 축으로 활용한다. 정답이 “무엇인가”를 가르치고, 신뢰도가 “실행해도 괜찮다”는 신호를 보낸다.

복합적인 판단을 원자적인 점수로 분해하고, 코드 측에서 제어하는 가중치를 활용하여 결합한다. 우선순위가 변경되면 프롬프트를 재작성하는 대신 가중치 값을 조정한다.

【의도 라우팅】수신 요청을 분류하고 각각을 최적의 핸들러로 라우팅한다. 이는 확정론적 로직, 전문 LLM, 혹은 인간을 활용하는 방식이다. 4번째 패턴은 에이전트 런타임 설계 그 자체를 의미한다. 공식 문서에는 코딩 에이전트에 대한 주의사항이 언급되어 있다. “코딩 에이전트는 인간보다 ‘1 호출당 1 질문’이라는 습관에 빠지기 쉽다. TypeSafe 에이전트 스킬은 일부 입력에서는 의미를 가지지 않는 질문을 포함하여 각 호출에 많은 질문을 입력하도록 에이전트에게 지시한다.”

제15장 ERP, MES, 금융, 사이버보안, 로봇 응용

제브형 모델은 기업 시스템과 잘 어울린다. ERP 쪽 후보는 품의서 배분, 지급 승인, 부정 탐지, 청구서 분류, 고객 분류, 신용 위험 평가이다. MES 쪽 후보는 이상 징후 판단, 유지 보수 우선 순위 결정, 작업 지시 라우팅, 품질 이상 판단, 인간 검토 필요 여부 판단이다. 기존의 규칙 기반 시스템에서는 다루기 어려웠던 “의미 판단”을 저비용 AI로 통합할 수 있다. 다만, 제21장의 데이터에는 얼음 물을 쏟아붓는 듯한 사실이 있다. TypeSafe 자체의 평가에서 제브가 가장 어려워했던 것이 청구서 처리(61.8%)였다. 청구서, 발주, 인도 기록의 3가지 일치 작업은 ERP의 핵심 업무이다. Opus 5(78.4%)나 Sol(79.1%)과의 16~17 포인트 차이는 무시할 수 없다. 따라서 ERP 적용에는 다음 설계가 필수적이다. 일치 작업 자체는 코드로 수행하고, 제브에게는 “이 설명이 청구서 내용과 일치하는가”와 같은 단일 의미적 판단만 전달하며, 결합과 최종 판단은 코드가 수행한다.

TypeSafe 자체의 경비 정산 예시는 바로 이와 같습니다. 영수증이 읽을 수 있는지, 경비의 종류는 무엇인지, 설명과 영수증이 얼마나 일치하는지를 모델에 묻고, “식사로 75달러 초과이고 설명이 일치하지 않는 경우 상급자 검토”라는 판단을 코드가 내립니다. 금융은 Jev와 잘 어울리는 분야로 보입니다. AML(자금세탁방지), KYC(본인확인), 인수 심사, 신용 판단, 거래 라우팅, 규정 준수, 인간 검토의 필요 여부 판단 등이 있습니다. 하지만 금융에서는 판단 미스의 비용이 높습니다. 다음 3가지가 필수적으로 요구됩니다. Confidence 임계값의 행위별 설계, 인간 검토의 흐름, 다수 모델에 의한 검증. 또한 제32장의 논점이 적용됩니다. 금융감독원의 감독을 받는 업무에서 “왜 이 신용 판단이 이루어졌는가”를 설명할 수 없는 모델을 최종 판단에 두는 것은 불가능합니다. 현실적인 구성은 다음과 같습니다. Jev는 대량의 1차 선별을 담당하고, 임계값을 초과한 사건과 저 Confidence 사건만을 설명이 가능한 모델 또는 인간에게 전달합니다.

제브가 반환한 확률과 신뢰도는 판단 기록으로 저장된다. 마지막 점이 중요하다. 제브는 자연어 설명을 반환하지 않지만, 모든 선택지 확률 분포를 반환한다. 이는 자연어 설명보다 감사에 용이한 면이 있다. 수치이기 때문이다. “모델이 0.85로 technical, 0.08로 billing, 0.07로 sales로 판단했다”는 기록은 재현성이 있다. “고객이 기술적인 문제를 제기했기 때문에”라는 문장보다 기계적으로 검증하기 쉽다. 보안은 제브가 처음부터 노리고 있는 영역이다. TypeSafe 워크플로우 eval 4건 중 2건이 여기에 속한다. 예상 용도는 다음과 같다. 알림 트리아지, 인시던트 심각도 판정, 멀웨어 분류, 의심스러운 활동 판정, SOC로의 라우팅, 에스컬레이션. 매 초 수많은 보안 이벤트가 발생하는 이상, 대규모 LLM을 사용하는 것은 비현실적이며, 1건당 0.0004달러라는 가격은 이 영역의 경제성을 변화시킨다.

그러나 평가 결과는 낙관을 허용하지 않는다. 보안 사고 워크플로우에서 Jev는 61.7%, Opus 5의 66.2%에는 도달하지 못했다. 반면에 비용은 0.0001달러 대 0.0574달러, 시간은 0.3초 대 15.1초이다. 트리아지라는 맥락에서 이 차이는 의미가 크다. 인간의 분석가가 봐야 할 건수를 줄이는 것이 목적이라면, 정확도에서 수 포인트 뒤쳐져도 슬루프트가 수백 배가 되는 경우도 있을 수 있다. 더 나아가 LLM 가이드레일이라는 용도가 있다. 공식 요리책 “Guardrails for LLMs”은 제일브레이크 탐지 및 유해 심각도 점수를 1 요청으로 수행한다. RAG 패스지의 프롬프트 인젝션 탐지 또한 마찬가지이다. AI 시스템의 입구와 출구에 저렴한 검사를 대량으로 배치하는 것이다. 이 용도는 Jev의 제약(추론하지 않으며, 설명하지 않음)과 가장 잘 어울린다. 우선 제약을 확인한다. Jev는 텍스트 입력만 가능하다. 이미지, 음성, 영상도 받지 않는다. 따라서 Jev가 카메라나 LiDAR의 출력을 직접 보는 경우는 없다.

또한, Jev가 직접 모터 제어를 수행하는 것은 아니다. 100Hz부터 1kHz의 제어는 MCU, RTOS, PID, MPC, 안전 제어기가 담당한다. Jev의 70~500밀리초라는 응답 시간은 이 대역에는 지나치게 느리다. 그럼에도 불구하고, 그 상위의 의미적 판단층에는 적용될 가능성이 있다. 이 상자를 가져야 할까? 이 사람에게 다가가는 것이 괜찮을까? 작업을 중단해야 할까? 이상이 감지되어 운영자를 호출해야 할까. 예상되는 구성은 다음과 같다. 카메라, LiDAR, 힘 센서로부터 입력이 들어온다. 지각 AI가 처리하여 세계 상태를 구조화 텍스트로 출력한다. Jev(System One)가 빠른 의미적 판단을 반환한다. 필요에 따라 프론티어 AI(System Two)가 계획을 수립한다. 모션 플래너가 궤적을 만든다. 컨트롤러가 제어한다. 액추에이터가 움직인다. DOOM 데모는 이 구성의 실증이다. 게임 상태를 구조화 텍스트로 전달하고, 10Hz로 판단을 반환한다. 로봇의 의미적 판단층은 바로 이 형태를 하고 있다.

현재 상황에서는 인지형 AI에서 구조화 텍스트로의 변환이 별도로 필요하며, 이 변환 자체에도 지연 시간과 비용이 발생합니다. Jev가 멀티모달 대응할 때까지 이 구성에는 추가적인 레이어가 끼워집니다. The Register는 다음 문장으로 이 글을 마무리하고 있습니다. “그리고 만약 Jev가 광고대로 유창하고 효율적으로 DOOM을 플레이할 수 있다면, 사용자가 Jev에게 드론의 표적 판단을 지시하도록 요구할 때까지 그렇게 오래 가지 않을 수도 있습니다.” 이는 농담으로 쓰여진 것이지만, 논점 자체는 진지하게 고려할 가치가 있습니다. DOOM 데모는 다음 세 가지를 증명했습니다. 구조화된 상황 묘사에서 100밀리초 안에 판단을 내릴 수 있으며, 1시간 7달러로 매초 10번의 판단 루프를 실행할 수 있습니다. 판단은 유형화되어 있으며 확률과 신뢰도를 가집니다. 이 세 가지 요소는 자율형 무기 시스템의 요구 사항과 직접적으로 일치합니다. 현재 군사 AI에서 의미적 판단을 대규모 LLM에 투입하는 구성은 지연 시간과 비용 측면에서 실현 불가능합니다. Jev형 모델은 이러한 제약을 해소하며, TypeSafe는 이 용도에 대해 아무런 언급을 하지 않고 있습니다. 이용 약관의 상세 내용도 본 논고에서는 다루지 않습니다.

하지만 “지능을 1 판단당 0.03엔으로, 70밀리초 안에 무제한적으로 채워 넣을 수 있는” 기술이 민생용에만 한정된다고 생각하는 이유가 없는 것은 아니다. 이 주장은 원고에 한 장을 할애하는 가치가 있으며, 기술 기사로서의 진실성을 유지하기 위해 필요한 부분이다.

제16장 계약, 데이터, 개인정보

이 장은 이전 버전에서 가장 크게 수정되었으며, “API 이용 계약 및 DPA를 공개 링크에서 확인할 수 없다”는 내용은 잘못된 정보였다. 최종 조사 결과, Typesafe는 다음 문서를 공개하고 있음을 확인했다.

마스터 고객 계약 (MCA): 2026년 8월 27일 최종 수정
데이터 처리 부록(DPA): 2026년 4월 24일 최종 수정
개인정보처리방침：2025년 11월 19일 최종 업데이트
사이트 이용 약관：2026년 9월 14일 최종 업데이트

【고객 데이터 및 학습 이용】MCA 4.1은 TypeSafe가 고객 데이터를 서비스 제공 및 텔레메트리 생성의 목적으로 처리할 수 있도록 규정하고 있으며, 고객의 사전 동의 없이 고객 데이터를 AI/ML 모델의 가중치를 변경하는 학습 데이터 세트에 포함하지 않도록 명시하고 있다. 개인정보 처리방침은 더욱 직접적으로, 프롬프트나 기타 입력에 대해 인공지능 또는 기계 학습 모델을 훈련하거나 미세 조정하지 않겠다고 명확히 한다. 따라서 “입력 데이터를 학습에 사용하는지 여부는 불명”이라는 이전 표현은 삭제한다.

MCA 4.2에서는 TypeSafe가 Input의 소유권을 주장하지 않으며, 법적으로 가능한 범위 내에서 Output에 대한 소유권을 포기하고, TypeSafe가 가질 수 있는 Output의 권리를 고객에게 이전한다는 내용이다. 이는 기업 이용에 대한 명확한 조항이다.

【텔레메트리】MCA 4.3의 텔레메트리에는

기술 로그
해시값들
요약 통계 및 분류
측정 지표
고객 사용 관련 학습 내용

등등이 포함되며, TypeSafe는 Telemetry를 서비스 또는 다른 제품의 개선을 포함하여 제한 없이 처리할 수 있다고 한다. 따라서 “Input을 웨이트 트레이닝에 사용하지 않는다”는 것과 “사용과 관련된 파생 Telemetry를 전혀 사용하지 않는다”는 것은 동일하지 않다. 기밀성이 높은 도입의 경우, 어떤 것이 Customer Data로 남아있고, 어떤 것이 Telemetry로 파생되는지 계약 및 보안 검토를 통해 확인해야 한다.

【벤치마크 공개 조항】MCA 2.3은 중요하다. 표준 계약에서는 고객에게…

모델 압축은 딥러닝 모델의 크기를 줄이고 추론 속도를 높이는 기술입니다. 복잡한 모델을 더 작고 효율적인 모델로 변환하는 과정을 의미하며, 이를 통해 모바일 기기나 임베디드 시스템과 같은 제한된 환경에서도 딥러닝 모델을 활용할 수 있게 됩니다. 모델 압축 방법은 다양합니다. 대표적으로는 가지치기, 양자화, 지식 증류 등이 있습니다. 가지치기는 모델의 중요하지 않은 연결을 제거하여 모델 크기를 줄이는 방법이고, 양자화는 모델의 가중치를 낮은 정밀도로 표현하여 모델 크기를 줄이는 방법입니다. 지식 증류는 크고 복잡한 모델(Teacher Model)의 지식을 작고 가벼운 모델(Student Model)로 전달하는 방법입니다. 특히 지식 증류는 Teacher Model의 예측 확률 분포를 Student Model이 학습하도록 유도하여, Student Model이 Teacher Model과 유사한 성능을 낼 수 있도록 합니다. 이를 통해 Student Model은 Teacher Model보다 훨씬 작은 크기에도 불구하고 높은 정확도를 유지할 수 있습니다. 최근에는 이러한 모델 압축 기술을 통해 딥러닝 모델의 활용 범위가 크게 확대되고 있으며, 다양한 분야에서 딥러닝 모델의 성능을 향상시키는 데 기여하고 있습니다.
서비스 아웃풋을 활용한 모방 모델 훈련에 대해 알아보겠습니다.
역공학은 제품이나 시스템의 작동 방식을 분석하여 설계, 기능, 작동 원리를 파악하는 기술입니다. 일반적으로 제품의 물리적 구조를 분석하거나, 소프트웨어의 실행 파일을 분석하여 내부 구조와 동작을 이해하는 것을 포함합니다. 역공학은 다양한 분야에서 활용됩니다. 예를 들어, 소프트웨어 보안 연구에서 악성 코드의 작동 방식을 분석하고 방어 기술을 개발하는 데 사용될 수 있으며, 제품의 디자인 개선이나 새로운 기능 추가에도 활용됩니다. 역공학은 때로는 법적인 문제와 관련될 수 있습니다. 특히, 특허 침해나 지적 재산권 침해 문제가 발생할 수 있으므로, 역공학을 수행할 때는 관련 법규를 준수하고 저작권자의 허락을 받는 것이 중요합니다.
기저 알고리즘/구조의 도출
서비스에 대한 벤치마크 또는 성능 정보를 게시하는 것을 의미함

이는 특정 기술의 사용을 금지하고 있습니다. 이는 TypeSafe 스스로 “각 사는 자체적인 평가 기능을 만들라”고 권장하는 연구 아이디어와 양립하는 동시에, 공개되는 제3자 벤치마크의 증가 속도에 영향을 미칠 수 있습니다. 이미 Every, Near Here, Aera, DevelopersIO, YTAL 등의 공개 테스트가 존재합니다. 그러나 각각이 개별 허가를 받고, 서로 다른 조건이나 Early Access 계약 등의 형태로 존재할 가능성도 있습니다. 따라서 표준 MCA 위반으로 간주해서는 안 되며, 도입 기업이 자사 벤치마크를 블로그나 논문에서 공개하고 싶다면 사전에 TypeSafe로부터 명시적인 허가를 받아야 합니다.

MCA 9.3에서는 서비스가 부정확하거나 잘못된 Output을 생성할 수 있다고 명시하고 있으며, 고객이 Output을 독립적으로 평가할 책임을 져야 한다고 규정하고 있습니다. 이는 “환각 없는”이라는 마케팅 표현을 고려할 때 중요합니다. TypeSafe가 보장하는 것은 주로 유형/스키마이며, 의미론적 정확성은 아닙니다.

【DPA】DPA는 TypeSafe를 고객 개인정보 처리자/서비스 제공자로서 취급한다. 또한,

새로운 하청업체 사전 고지
개인정보 또는 보안상의 사유로 15일 이내에 이의를 제기할 수 있습니다.
보안 사고를 인지한 후, 즉시 72시간 이내에 통보한다.
매년 1회 고객 감사 점검을 실시합니다.
유럽 SCCs
영국 부록
트러스트 센터의 보안 조치

등기가 규정되어 있으며, 하위 처리자 목록은 https://trust.typesafe.ai/subprocessors 에서 관리한다고 한다.

[데이터 보존] DPA 일정은 고객 개인 데이터를 처리 목적과 적용 법에 따라 필요한 기간 동안 보관하며, 고정된 “30일” 등의 기간을 명시하지 않는다. 반면 MCA는 계약 종료 후 TypeSafe에 고객 데이터 보관 의무는 없으며, 자유롭게 삭제할 수 있고, 표준 백업에 남아있는 기밀 정보는 기밀 유지 제한을 따른다. 따라서 “API 입력은 반드시 X일 후에 삭제된다”라고 표현할 수 없다.

【기업 도입 시 최종 점검】 1차 번역문: 기업 도입 시 최종 점검 프로젝트의 최종 단계, 마지막 체크포인트입니다. 지금까지의 준비가 모두 무駄가 되지 않도록 다음 항목을 다시 확인하고, 문제점이 있으면 신속하게 대응책을 마련해 주십시오. **1. 도입 환경 확인** * 서버, 네트워크, 스토리지 등 인프라가 도입 요건을 충족하는지 확인합니다. 특히 AWS의 EC2 인스턴스 상태, Azure의 가상 머신 가용성, Google Cloud Platform의 스토리지 용량 등이 중요합니다. * 도입 전에 설정한 네트워크 구성이 실제 환경에서 제대로 작동하는지, 패킷 캡처 툴 등으로 확인합니다. * 도입 환경의 보안 대책이 최신 위협에 대응 가능한지, 취약성 스캔 툴 등으로 체크합니다. * Docker 컨테이너 이미지가 정확하게 빌드되었는지, Kubernetes 클러스터에 배포되었는지, 컨테이너 상태를 확인합니다. * Ansible이나 Chef와 같은 구성 관리 툴로 설정이 정확하게 적용되었는지, 역할 플레이링으로 확인합니다. **2. 소프트웨어 확인** * 도입하는 소프트웨어의 버전이 최신 버전인지 확인합니다. * 소프트웨어의 라이선스가 제대로 관리되는지 확인합니다. * 소프트웨어의 설치가 정상적으로 완료되었는지 확인합니다. * 소프트웨어의 동작 확인을 수행하여 기대에 부응하는 기능이 작동하는지 확인합니다. * Salesforce의 데이터 이관이 제대로 완료되었는지, 데이터 양과 이관 시간을 확인합니다. * SAP의 시스템 이관이 계획대로 진행되는지, 이관 로그를 확인합니다. * Microsoft Office의 애플리케이션이 정확하게 설치되었고, 작동하는지 확인합니다. **3. 데이터 확인** * 도입하는 데이터의 종류, 양, 형식을 확인합니다. * 데이터의 백업이 정상적으로 완료되었는지 확인합니다. * 데이터의 이관이 제대로 완료되었는지 확인합니다. * 데이터의 일관성이 유지되는지, 데이터 검증 툴 등으로 확인합니다. * MySQL 데이터베이스의 백업과 복구가 정상적으로 작동하는지 확인합니다. * PostgreSQL 데이터베이스의 백업과 복구가 계획대로 진행되는지, 로그를 확인합니다. **4. 사용자 확인** * 도입 후 사용자에게 제공되는 교육이 계획대로 진행되는지 확인합니다. * 사용자의 접근 권한이 정확하게 설정되었는지 확인합니다. * 사용자의 운영 매뉴얼이 정비되었는지 확인합니다. * 사용자로부터 피드백을 수집하여 개선 사항이 있으면 대응책을 마련합니다. **5. 기타** * 도입 프로젝트 전체의 진행 상황을 확인합니다. * 위험 관리 계획에 따라 위험 대응책을 마련합니다. * 문제 발생 시 신속하게 대응책을 마련합니다. * 도입 완료 후 운영 체계를 구축합니다. * Slack이나 Microsoft Teams와 같은 커뮤니케이션 툴이 도입 사용자 간에 공유되는지 확인합니다. * Jira나 Asana와 같은 프로젝트 관리 툴로 작업이 정확하게 할당되었고, 진행 상황이 관리되는지 확인합니다. * 도입 프로젝트의 결과물을 정리하여 관계자에게 공유합니다. * 도입 프로젝트의 교훈을 정리하여 향후 프로젝트에 활용합니다.

입출력 유지 구현 및 로그 설정
텔레메트리 구체적인 내용
하위 위탁업체 및 데이터 위치
VPC/프라이빗 엔드포인트/온프레미스 존재 여부
모델 알리어스 업데이트 시 알림 발송
SLA(서비스 수준 협약)는 기업이 고객에게 제공하는 서비스의 품질을 보장하기 위해 설정하는 약속입니다. SLA는 일반적으로 서비스 제공자와 고객 간에 체결되며, 서비스 수준 목표, 측정 방법, 책임 및 제재 등을 명시합니다. SLA는 서비스 제공자가 고객의 요구 사항을 충족하는지 확인하는 데 도움이 되는 중요한 도구입니다. SLA는 서비스 제공자와 고객 간의 의사 소통을 개선하고, 서비스 품질을 향상시키며, 분쟁을 해결하는 데 기여할 수 있습니다. SLA는 다양한 유형의 서비스에 적용될 수 있습니다. 예를 들어, IT 서비스 SLA는 IT 서비스 제공자가 고객에게 제공하는 서비스의 품질을 보장하기 위해 설정될 수 있으며, 고객 서비스 SLA는 고객 서비스 제공자가 고객에게 제공하는 서비스의 품질을 보장하기 위해 설정될 수 있습니다. SLA를 효과적으로 관리하기 위해서는 다음 사항을 고려해야 합니다. * 명확한 목표 설정: SLA는 측정 가능하고 달성 가능한 목표를 포함해야 합니다. * 정기적인 측정 및 보고: 서비스 수준 목표를 정기적으로 측정하고 보고해야 합니다. * 피드백 루프 구축: 고객과 서비스 제공자 간의 피드백 루프를 구축하여 SLA를 개선해야 합니다. * 책임 및 제재: SLA는 서비스 제공자와 고객의 책임을 명확하게 정의하고, 서비스 수준 목표를 충족하지 못할 경우 제재를 명시해야 합니다. SLA는 서비스 제공자와 고객 간의 신뢰를 구축하고, 서비스 품질을 향상시키며, 장기적인 관계를 유지하는 데 도움이 될 수 있습니다.
감사 기록
사고 발생 보고서입니다. 자세한 내용은 첨부 파일을 참조해주십시오.
벤치마크 출판 허가
개별 조건에 따른 규제 데이터 및 민감 데이터

제브는 “소프트웨어가 의존하는 AI”를 목표로 삼는다. 따라서 모델 정확도만큼 계약, 버전 관리, 데이터 거버넌스가 중요하다.

제17장 Vercel, Netlify 및 생태계

9월 16일, Vercel은 Jev를 AI 게이트웨이에 추가했다. Vercel의 변경 로그 설명은 간결하다. 상태가 반영되고, 타입이 지정된 Choice, Score, Boolean의 답변이 나온다. 일반적인 언어 모델이 텍스트를 1 토큰씩 생성하고, 애플리케이션 측에서 이를 파싱하여 검증하는 방식과 달리, Jev는 선언된 모든 질문을 병렬로 평가하고, 타입이 지정된 답변과 확률을 직접 반환한다. 또한, 에이전트 루프에서 다음 도구나 서브 에이전트를 선택하고, 계속 진행할지, 재시도할지, 사용자에게 질문할지, 중단할지 결정하며, 작업 전에 긴급성이나 위험을 평가하고, 모델 출력을 검증하여 가드레일을 적용한다.

【Vercel에서의 호출 방식】AI SDK 7의 실험적인 experimental_evaluate API를 활용한다. 프로바이더는 @ai-sdk/typesafe-ai이다. 환경 변수는 TYPESAFE_AI_API_KEY이다. baseURL의 기본값은 https://api.typesafe.ai/v1이다. 게이트웨이를 통한 모델 ID는 typesafe-ai/jev이다. 응답은 질문 ID와 Choice의 키를 그대로 유지한다. Choice와 Score의 신뢰도는 result.providerMetadata.typesafe.confidence에 저장된다. 평가 콜드는 Vercel 측의 로그와 커스텀 보고서에 나타나며, 예산에 포함된다.

【기본 이름의 차이점】 이는 구현 시 반드시 걸림돌이 되는 부분이다. TypeSafe 공식 API의 3가지 기본 유형은 Choice, Score, Noul이다. 반면, Vercel AI SDK의 프로바이더에서는 choice, score, boolean으로 불리고, Noul에 해당하는 답변은 probability라는 필드에서 반환된다. 동일한 기능에 2가지 이름이 존재하는 것이다. 어떤 경로로 호출하고 있는지 먼저 확인하지 않으면, 문서를 오독할 수 있다.

[제로 데이터 유지 및 무 훈련] 이것이 기업 도입에서 가장 중요한 부분일 수 있다. Vercel의 챌린지록은 Jev가 제로 데이터 유지 및 무 훈련에 대응하고, 요청 단위로 활성화할 수 있다고 명시하고 있다. 계약 문서상의 조항과는 별개로, API 호출마다 플래그로 지정할 수 있다는 운영상의 보장이 있다. 제16장의 계약 확인과 함께 이 두 가지 측면을 고려하는 것이 실무적이다.

Near Here의 실측에서는 jev-latest에 대한 요청에 대해 jev-1.13.0이라는 응답이 반환되었으며, jev-latest는 별칭이며 고정 버전이 아니다. 임계값을 0.72로 조정해도 jev-latest의 내용이 업데이트되면 확률 분포가 달라질 수 있다. 따라서 운영 환경에서는 최소한 다음 MLOps가 필요하다.

응답 버전 ID를 로그에 기록합니다.
버전 업데이트 전후에 프라이빗 평가를 재실행합니다.
확률 임계값을 재조정한다
크리티컬 워크플로우에서는 캐나리 배포를 진행합니다.

형태가 손상되지 않는 것과 의사 결정 분포가 변하지 않는 것은 별개의 문제이다. 제브의 유형 안전성 보증은 전자에만 해당하며, 후자를 지키는 것은 사용자 측의 책임이다.

【생태계 내 위치】Jev의 가치가 확장된다면, 경쟁은 단일 모델 리더보드만으로는 결정되지 않는다. AI Gateway, Agent runtime, MCP, 워크플로우 엔진, observability, ERP/MES, 보안 파이프라인 내에 “decision model”이라는 슬롯이 표준화되는 것이 중요해진다. 실제로, 지난 수일 동안 Jev는 여러 곳으로 침투하기 시작했다. Vercel AI Gateway와 AI SDK 7의 제공업체. 오픈 소스 브라우저 에이전트. Almeida氏가 소개한 데모에서는 Browser Use와 함께 사용하여 항공 검색을 7초, 0.0039달러(약 0.6엔)로 완료하고 있었다. 매 단계마다 행동 공간을 재구성하고, DOM 상태 공간을 처리하며, 입력이 필요한 경우에만 소형 LLM으로 폴백하는 구성이었다. MIT 라이선스의 SDK와 어댑터. 커뮤니티에 의한 자료집과 TypeScript 클라이언트.

한편, 제대로 녹아들지 못하는 위치도 구체적으로 드러나기 시작했다. DevelopersIO의 검증 결과, NVIDIA의 NeMo Switchyard의 classifier가 OpenAI Chat Completions과 같은 정해진 형식을 따르는 target으로 구성되는 설계이기 때문에, TypeSafe의 /v1/systemone을 그대로 base_url에 지정하여 연결하지는 못했다. 중간에 어댑터를 삽입하거나, Switchyard를 라이브러리로서 組み込んで直接呼び出す 필요가 있었다. 자체적인 요청 형식은 속도의 원천이 되는 동시에, 기존 생태계에 대한 진입 장벽이 되기도 한다. Vercel과 같은 Gateway가 흡수할 수 있을지가 보급의 분수령이 될 것이다.

2026년 9월 17일에는 Netlify도 Jev를 AI Gateway에 추가했다. Netlify Functions에서 TypeSafe SDK를 활용할 수 있게 되어, 개별 TypeSafe API 키나 base URL 설정을 생략하고 Gateway 측에서 인증과 청구를 처리할 수 있게 되었다. Netlify의 changelog은 SDK의 jev-latest alias가 당시 jev-1.13.0을 가리키고 있으며, state와 questions에서 약 32,000 토큰의 예산을 공유한다는 내용과 TypeSafe가 70~500ms의 응답 시간을 공적으로 명시하고 있음을 기록하고 있다. Vercel과 Netlify 양쪽에 통합됨으로써, Jev는 전용 API만을 위한 실험적 모델에서 기존의 AI 인프라를 통해 통합 가능한 decision model로 한 단계 발전했다.

18장: TypeSafe 연구의 사상 TypeSafe 연구의 핵심은 폰트 자체의 기술적인 측면뿐만 아니라, 폰트가 담고 있는 의미와 맥락, 그리고 그것이 사용되는 환경과의 상호작용을 깊이 있게 이해하는 데 있었다. 특히 폰트 디자인의 궁극적인 목표는 ‘가독성’을 넘어 텍스트의 ‘의미 전달’을 극대화하는 데 있다는 점을 강조했다. 이러한 관점에서 TypeSafe는 폰트의 선택과 사용에 있어 시각적인 아름다움만을 추구하는 것이 아니라, 텍스트의 내용과 목적에 가장 적합한 폰트를 선택하고, 그 폰트가 가진 특성을 최대한 활용하여 메시지를 효과적으로 전달하는 것을 목표로 했다. TypeSafe 연구는 폰트 디자인의 기술적인 측면뿐만 아니라 폰트가 담고 있는 문화적, 역사적 맥락을 고려하는 ‘인문주의적’ 접근 방식을 통해 폰트 디자인의 새로운 가능성을 제시했다. 폰트는 단순한 글자 형태가 아닌 문화와 역사를 담고 있는 ‘문화재’로서 폰트를 바라보는 시각을 확립시킨 것이다. 이러한 TypeSafe 연구의 사상은 이후 폰트 디자인 분야에 큰 영향을 미쳤으며, 폰트 디자인의 가치를 단순히 시각적인 요소뿐만 아니라 의미 전달과 문화적 맥락을 포함하는 ‘지적’이고 ‘문화적’한 영역으로 확장시키는 데 기여했다.

제브 발표 직전, TypeSafe는 “The Bitterest Lesson”(2026년 9월 10일), “Lies, Damned Lies, and Benchmarks”(2026년 9월 11일), “AI: too good to be true, too bad to be useful”의 3개 논고를 공개하고 있었다. 이 논고들을 통해 제브가 단순한 아이디어에서 비롯된 제품이 아니라, 상당히 명확한 연구 철학에 기반한 것이라는 점을 알 수 있다.

【가장 쓰라린 교훈】본문 시작 부분에 TL;DR 한 문장이 제시된다. “계산 자원은 AI의 발전을 이끌지만, 제대로 된 작업을 수행하지 못하면 그 발전이 어떤 의미가 있는가?” 리차드 사튼의 “가장 쓰라린 교훈”은 계산 자원이 알고리즘을 능가한다는 내용이었다. 알메이다는 이것을 빙산의 일각이라고 말한다. “ML에서 가장 쓰라린 교훈은 제대로 된 작업을 수행하는 것 > 데이터 > 계산 자원 > 알고리즘이다.” 사튼의 교훈이 게임에서 잘 드러나는 이유는 두 가지다. 첫째, 제대로 된 작업이 자명하다는 점(규칙에 따라 이기는 것, 점수를 최대화하는 것)이고, 둘째, 자기 대전에서 데이터를 무한히 생성할 수 있다는 점이다. 현실 세계에서는 그 어느 것도 자명하지 않다. “결국, 머신러닝은 보상을 늘리거나 손실을 줄이는 것 외에는 아무것도 하지 않는다. 하지만 무엇을 최적화할지는 누군가가 결정해야 한다.” “제대로 된 작업이 없다면 모든 것이 완벽하게 움직이고, 가장 아름다운 손실 곡선과 스케일링 곡선이 나타나더라도 모델은 무용지물일 수 있다.”

그러면서 냉소적인 상황이 지속된다. “불운하게도, 머신러닝 연구는 이러한 문제들을 역방향으로 접근하는 경향이 있다. 연구자들은 알고리즘을 만드는 것을 매우 좋아하고, 최근에는 스케일링 곡선을 사랑하게 되었다. 반면에 데이터는 불결하며, 적절한 작업을 선택하기 위해서는 머신러닝 문제 자체에서 벗어나 사용자, 제품, 조직, 혹은 혜택을 누릴 대상이 되는 세계 일부를 연구해야 하는 경우가 많다.”

이 논고에서 가장 강력한 부분은 자신의 과거 업무를 활용한 예시이다. GPT-3는 인터넷 텍스트에서 다음 토큰 예측을 학습한 놀라운 모델이었다. 그러나 사람들이 원했던 것은 초고성능 자동 완성 기능이 아닌, 지시를 따르는 것이었다. GPT-2 크기의 모델, 즉 GPT-3의 100분의 1 이하의 규모를 적절한 작업으로 훈련시키면, 가장 어리석은 알고리즘으로도 거의 계산 자원 없이 GPT-3를 압도할 수 있었다. 알메이다는 더 나아가, 사전 학습 스케일링만으로도 이 베이스라인에 도달하려면 대략 GPT-7 급이 필요하며, GPT-3 위에 구축된 InstructGPT를 능가하려면 GPT-9 급이 필요하다고 밝혔다. 결론적으로 “당신은 최적화한 것을 얻는다. 그리고 머신러닝에서 가장 중요한 교훈은 그 가장 중요한 부분이 머신러닝이 아닌 것”이라는 것이다. 제브는 이 사상의 두 번째 사례이다. 챗 AI가 취약했던 부분을 개선하기 위해 다시 만들지 않은 것이다. 챗(chat)이라는 목적 함수 자체가 소프트웨어 자동화라는 업무에 적합하지 않다는 주장이다.

다음 논고에서 TypeSafe는 공개 벤치마크에 대한 ‘산등성’을 “benchmaxxing”이라고 비판한다. 그 주장은 다음과 같다. 공개 평가에 맞춰 학습 선택과 실험을 계속하면, 그 벤치마크에서 직접 훈련하지 않더라도, 선택을 통해 모델은 벤치마크에 적응해 나갈 것이다. 그리고 일반적인 신뢰성과 거리가 멀어진다. 이에 해당 회사는 다음과 같은 정책을 명시하고 있다. “모델 출시 시 표준 벤치마크 표는 포함하지 않는다.” 새로운 평가 방식은 “날짜가 기재된 스냅샷 형태로 공개하고, 공개 시점에 즉시 퇴출시킨다. 산등성 대상에는 포함하지 않는다.”

【런치 FAQ】FAQ에도 동일한 정책이 기재되어 있다. 공개 벤치마크에 대한 성능을 “의도적으로 공개하지 않기로 결정했다.” 성능 평가는 “제품 업데이트 시 일회성”으로만 진행하며, 사용자에게 자신의 유스케이스에 맞는 평가를 스스로 만들어 보도록 요청한다. FAQ에 등장하는 질문의 톤 역시 이 회사의 성격을 잘 드러낸다. “Jev는 단순한 소형 LLM인가?”, “JSON 모드나 구조화 출력과 무엇이 다른가?”, “왜 이렇게 빠르고 저렴하게 가능한가?”, “더욱 빠르게 할 수 있는가?”, “이 가격은 일시적인 것인가, 아니면 보조금 지원을 받는 것인가?” 등 예상되는 비판을 스스로 먼저 제시하고 있다.

이 정책을 어떻게 평가해야 하는가? 벤치마크 오염 문제는 실제로 존재한다. 그 의미에서 이 입장은 타당하다. 하지만 동시에 외부 검증의 필요성이 사라지는 것은 아니다. 오히려 “각社가 스스로 평가하라”는 자기 내부 결론에 그치는 것이다. Jev를 채택하는 측이 보기에 MMLU 순위는 중요하지 않다. 자사의 청구서, 부정 검지, 라우팅, 에이전트 추적, MES 이상 판단에 있어서의 정밀도, 교정, 지연 시간, 실패 패턴이 중요하다.

TypeSafe의 연구 사상을 한마디로 요약하면 “더 큰 모델을 만들기 전에 모델에게 무엇을 시킬 것인지부터 재검토해야 한다”이다.

제19장 현재 시점에서 미공개된 것들과 앞으로 측정해야 할 것들

최종 조사 결과, TypeSafe 제품 사양, 계약, 외부 검증에 대해 상당한 정보가 축적되었지만, Jev의 핵심 부분에는 여전히 미공개 사항이 남아 있었다.

여전히 공개되지 않은 기술 정보

파라미터 수. 모델의 복잡성을 나타내는 지표로서, 모델이 학습할 수 있는 파라미터의 수에 해당합니다. 파라미터 수가 많을수록 모델이 더 복잡한 패턴을 학습할 가능성이 높아지지만, 과적합의 위험도 커집니다. 파라미터 수를 조정하는 것은 모델의 성능을 최적화하는 데 중요한 요소입니다. 파라미터 수를 줄이면 과적합을 방지하고 일반화 성능을 높일 수 있습니다. 반면 파라미터 수를 지나치게 줄이면 모델의 표현력이 저하되어 복잡한 패턴을 학습하기 어려울 수 있습니다. 파라미터 수는 모델의 크기뿐만 아니라 학습 데이터량과 학습 시간에 영향을 미칩니다. 학습 데이터량이 적은 경우에는 파라미터 수를 많이 하더라도 과적합의 위험이 높아집니다. 또한 학습 시간이 길어질수록 파라미터 수를 조정하는 빈도가 늘어납니다. 파라미터 수를 결정할 때는 이러한 요소들을 종합적으로 고려해야 하며, 모델의 성능을 평가하기 위해 다양한 평가 지표를 활용하는 것도 중요합니다.
기반 모델／체크포인트
트랜스포머 기반인지, 아니면 그 외인지 포함한 상세 아키텍처.
입력 측 인코더/트렁크와, Choice/Score/Noul을 반환하는 헤드·샘플러의 구체적인 구성
RLCD의 완전한 알고리즘, 보상 함수, 보상 소스
교사 모델의 유무와 자기 생성 데이터에 다른 모델의 답변이 포함되는지 여부.
학습용 데이터셋의 구체적인 규모와 분포
모델 가중치
온프레미스/고객 VPC를 위한 상세 로드맵
장기적인 가격 안정성

TypeSafe의 FAQ는 Jev에 대해 “작은 규모의 LLM이나 LLM이 아닌” 모델이라고 설명한다. 반면, 공식 AI 프라이머는 RLCD를 “사전 훈련된 언어 모델을 적용하는 제3의 방법론”이라는 맥락에서 설명한다. 외부 감사의 CounterProof 또한 이러한 긴장 관계를 지적하고 있다. 기반 트렁크의 공개가 이루어지지 않았기 때문에, 제3자가 “LLM이 아닌” 기술적 경계를 확정할 수 없는 상황이다.

【수정이 필요한 부분】 초고에서는 “제3자 검증이 거의 없다”라고 썼다. 그러나 9월 17일까지 상황은 바뀌었다. Every의 소규모 테스트에 더하여, Near Here의 50건 이상에 추가로 21건, DevelopersIO의 40콜, YTAL의 본番 로그 재생, Aera의 400건 실타스크 재생, CounterProof에 의한 공개 평가 감사 등이 진행되고 있었다. 따라서 현재 시점의 정확한 표현은 “외부 실측은 여러 형태로 시작되었지만, TypeSafe의 711건 케이스 평가를 동일 조건에서 독립적으로 재실행한 포괄적인 재현 시험은 아직 확인되지 않았다”이다. 또한, TypeSafe의 Master Customer Agreement와 DPA는 공개되어 있다. 초고의 “API 계약을 공개 확인이 불가능하다”는 묘사는 오류였기 때문에, 제16장에서 전면 수정했다. 최종본에서는 “무엇이 밝혀졌는가”뿐만 아니라 “시공사가 다음에 무엇을 측정해야 하는가”를 명확히 하는 데 주력했다.

【즉시 시도해 볼 수 있는 것】자사 시스템에서 LLM의 출력을 파싱하는 부분을 발굴하고, 분류, 라우팅, 위험 점수, 승인, 가이드레일, 재랭킹, 후보 필터링 등을 Jev 모델의 후보로 고려한다. 워크플로우 분해 자체를 시도해 본다. TypeSafe 공개 평가에서 가장 재사용성이 높은 발견은 Jev 고유의 성능이 아닌 “큰 작업을 작은 독립적인 판단으로 분해하고, 결합, 계산, 부작용을 코드에 되돌리는” 방식이며, 비교 대상 LLM까지 개선하는 데 기여했다는 점이다. Choice와 Noul을 활용하여 사용한다. “하나만” 선택해야 한다면 Choice를, “각 후보가 조건을 만족하는지”를 독립적으로 판단해야 한다면 Noul이 적합하다. 신뢰도/확률 임계값은 행위의 위험도에 따라 설계하고, 일률적으로 “0.9 이상이면 실행”과 같은 규칙에 의존하지 않는다. Jev 앞뒤에 fallback을 배치한다. Hosted API이므로, 타임아웃, 429, 529, 품질 변화, 모델 별칭 업데이트, 벤더 장애를 전제하고 설계한다.

【최종 조사 결과, 새롭게 확인된 사항】Aera는 400건의 실타스크래징에서 동일한 후보 풀에 대해 무인 작업을 수행했을 때 LLM 셀렉터와 동일한 46%의 커버리지를 유지하면서 정밀도를 79%에서 85%로 향상시켰고, 중앙값 레이텐시를 463ms에서 147ms로 단축했다. 이는 속도뿐만 아니라 실타스크래징에서의 선별 품질에 대해서도 외부적으로 긍정적인 평가를 이끌어낸 것이다. 더불어 Aera는 13,947건의 후보에 대해 Jev의 확률과 매처 판정을 비교하여 0.4~0.5 구간에서는 47%, 0.7~0.8 구간에서는 88%가 유용하다고 판정했다는 보고를 담고 있으며, AUC는 0.82이다. RLCD의 “칼리브레이티드 확률” 주장에 대한 현재 시점에서 가장 구체적인 외부 자료 중 하나이다. 다만, 이 라벨은 사람의 골드 레이블이 아닌, 저격/매처 모델을 활용한 평가이며, 400건은 하나의 워킹 프로필에서 파생된 것이다.

Near Here에서는 좁은 이벤트 게시물 평가에서 Jev가 48/50, Mistral Small 4가 42/50, Gemini 3.5 Flash-Lite가 43/50로 나타났습니다. 추가 21건에서는 Jev와 Mistral이 19/21, Gemini가 20/21로 평가되었습니다. 소규모이며 프롬프트 선택에 사용한 데이터를 포함하고 있어 일반 성능 순위에는 사용하기 어렵지만, “Jev가 정확도 면에서 항상 한 단계 낮다”고 단순화하는 것은 틀렸습니다. DevelopersIO에서는 4가지 모델 라우팅 분류를 10회씩, 총 40회 진행하여 40/40이 기대한 티어에 일치했습니다. 중앙값은 0.643~0.674초, 1 호출당 약 0.000025~0.000027달러였습니다. 공식적으로 제시된 70~500ms보다 느린 실측이 존재하는 것은 지역 및 네트워크를 포함한 엔드 투 엔드 지연 시간을 자체적으로 측정해야 함을 시사합니다. YTAL은 실제 저장된 로그를 재생하고 67개 문서 및 525개의 노드를 정제하여 검증했습니다. Jev 단체의 추정 비용은 기존 처리의 약 4%였던 반면, 보류를 기존 처리로 되돌리는 방식에 따라 시스템 전체 비용은 오히려 증가할 수 있음을 보여주었습니다. 더불어 보류율의 높이는 모델뿐만 아니라 “질문의 단위”와 “페어 판정을 노드 판정으로 집계하는 규칙”에 크게 영향을 받았습니다. 이는 도입 설계상 매우 중요한 실측입니다.

다음과 같이 관찰해야 할 사항이 있습니다.

RLCD 논문 또는 기술 보고서가 발행 예정인가요?
대규모 연구소들이 원-토큰 제한 디코딩, 전용 분류 헤드, 교정된 의사 결정 API를 따를지 주목한다.
다중 모달 입력이 추가될지 궁금합니다.
JEV-최신 버전 업데이트 시 확률 분포 및 임계값 변동 정도를 확인해야 합니다.
다수 기업 및 다수 언어, 다수 지역에서 장기간에 걸쳐 캘리브레이션 유지가 가능한가.
고위험 영역에서 설명 가능성, 감사 추적, 인적 개입을 어떻게 결합할 것인가.
요금이 장기적으로 유지될 수 있을까요?

또한 기업 이용의 경우 계약 역시 중요합니다. 공개 Master 고객 계약에는 Output을 이용한 모델 증류, 역공학적 분석뿐만 아니라 서비스의 성능 벤치마크 정보 공개를 금지하는 조항이 포함되어 있습니다. 공개된 외부 테스트가 어떤 계약 또는 허가 하에 진행되었는지 각각 확인해야 하며, “외부 테스트가 존재한다는 것”은 표준 계약 조건에 따라 자유롭게 공개할 수 있다는 의미로 해석되어서는 안 됩니다. Jev를 테스트할 때는 성능 평가뿐만 아니라 벤치마크 공개 가능 여부, 입력 데이터, 텔레메트리, 보관, 서브프로세서, 모델 버전 고정까지 포함하여 설계해야 합니다.

결론: 지능을 역할에 따라 분해한다

TypeSafe AI는 ChatGPT를 더욱 똑똑하게 만드는 회사라기보다는, “소프트웨어 내부로 인공지능의 지능을 대량, 고속, 저렴, 안전하게 ‘내재화’하는 방법에 대한 문제”를 해결하는 데 초점을 맞추고 있습니다. Diogo Almeida 氏はOpenAI에서 InstructGPT와 RLHF(강화학습 기반 인간 피드백)를 실현하는 데 관여한 후, “인간과 대화하는 AI”와 “기계가 사용하는 AI”를 같은 출력 형식으로 억지로 묶을 필요는 없다고 생각했습니다. 그 첫 번째 답이 Jev입니다. Jev가 목표하는 것은 AI가 소프트웨어의 if/switch/score 판단을 할 때마다, 매번 “짧은 문구”를 생성할 필요를 없애는 것입니다. 최종 조사 결과, 론칭 시점보다 평가 자료가 늘어났습니다. Every는 고속, 저 비용을 확인하면서 frontier 모델보다 결함을 1건 더 놓쳤습니다. Near Here에서는 좁은 이벤트 판정에서 Jev가 비교 모델 2개를 정확도, 속도, 비용으로 상회시켰습니다. DevelopersIO에서는 40회의 라우팅이 40/40으로 기대 Tier에 진입했으며, 중앙값은 약 0.65초였습니다. YTAL은 본번 로그 재생에서, Jev 단체가 저렴하더라도 보류, 집계, 폴백 설계에 따라 시스템 전체의 경제성이 역전될 수 있음을 보여주었습니다.

Aera는 400건의 실타스크 재생을 통해 동일한 커버리지를 유지하면서 정밀도와 지연 시간을 개선했으며, 13,947명의 지원자에서 확률 교정(probability calibration)에 대해 일정한 외부 증거를 제시했다. CounterProof는 TypeSafe의 벤치마크 아티팩트를 감사하여 “67.8%”는 객관적인 ground truth accuracy가 아닌, 모델 컨센서스가 오라클과 일치하는 합의임을 구체적으로 보여주었다. 그리고 Vercel은 Jev를 AI Gateway에 추가했다. 지금까지의 내용을 “Jev는 ‘193배 빠른 AI’라는 제목으로만 이해하는 것은 충분하지 않다.”는 점을 강조하며, AI 아키텍처는 System 2 reasoning 모델 + System 1 decision 모델 + 결정론적 코드 + 데이터베이스/상태 + 도구/물리적 행동으로 구성되어 있다는 점을 핵심으로 설명했다.

분해되어 가는 가능성을 보이고 있다. 다만, Jev가 이 카테고리를 독점할 수 있을지는 불확실하다. 아키텍처와 RLCD의 상세 정보도 공개되지 않았으며, 대규모 실험실이나 오픈소스 모델이 유사한 의사결정 API를 구축할 가능성이 높다. 기존 LLM을 constrained decoding으로 고속화하는 기술적 반론도 나오고 있다. 더불어 Jev에는 명확한 제약이 존재한다. 자유 형식의 설명을 반환하지 않고, 현재 텍스트 기반이다. 상태에 없는 정보는 판단할 수 없으며, 의미론적 오류가 발생할 수 있다. 고위험 업무에서는 인간 검토나 추가적인 검증 레이어가 필요하다. 또한 표준 MCA에서는 벤치마크/성능 정보 공개에 제한이 있다. 그럼에도 불구하고 TypeSafe가 제기한 질문은 여전히 남아 있다. 고도의 지능을 갖는 것과 소프트웨어의 모든 판단에 저렴하고 빠르고 예측 가능하게 지능을 내재시키는 것은 동일한 문제가 아니다.

다음 AI 인프라 경쟁에서는 “누가 가장 똑똑한 모델을 가지고 있는지”뿐만 아니라, 1 결정당 얼마인지, 몇 밀리초인지, 어느 정도 캘리브레이션되었는지, 그리고 인간에게 어떻게 이행할 수 있는지를 묻게 될 것이다. 제브의 장기적인 승패는 아직 결정되지 않았다. 하지만 “모든 것을 거대 LLM에 투입하여 해결한다”는 설계에서 “판단, 추론, 최종 결정 처리를 분업시킨다”는 설계로 전환되는 방향성은 에이전트, ERP, MES, 금융, 사이버 보안, EC, 검색, 그리고 물리 AI까지 광범위하게 영향을 미칠 수 있다. 그리고 이 방향성을 시험하는 데 제브만 필요한 것은 아니다. 먼저 작업을 분해하고, 의미적 판단을 좁게 정의하며, 계산과 부작용을 코드에 되돌려놓는 것이다. TypeSafe가 던진 가장 큰 질문은 모델 이름 자체보다는 이 소프트웨어 설계의 재고에 있다.

2026년 9월 18일 현재 최종 확인

공식 블로그는 9월 14일자 게시글을 통해 4,000만 달러 규모의 시드 투자와 스텔스 해제에 대한 발표가 9월 15일에 이루어졌다. Vercel AI Gateway 추가는 9월 16일, Netlify AI Gateway 추가는 9월 17일이다. TypeSafe의 workflow eval은 67.8%, 193.6배, 444.6배의 비율로 벤더 평가이며, 이는 수동으로 확정된 객관적인 ground truth에 대한 일반적인 성능을 나타내지 않는다. CounterProof의 감사는 공개 아티팩트의 labeling 구조를 조사한 것으로, Jev 본체를 재실행한 독립적인 벤치마크가 아니다. Every, Near Here, DevelopersIO, YTAL, Aera의 외부 검증은 원본 소스를 확인할 수 있다. Aera는 400건의 offline replay를 사용했으며, Near Here는 소규모 용도별 비교, DevelopersIO는 40회분의 API 실측, YTAL은 저장된 production log의 replay를 활용했다. 이러한 자료들은 속도, 비용, 확률 교정, state 설계, fallback 설계 등을 고려하는 데 도움이 된다.

마스터 고객 계약(Master Customer Agreement)과 데이터 처리 추가 약관은 TypeSafe 공식 웹사이트에서 공개되어 있다. MCA는 고객 데이터를 사전 동의 없이 모델 가중치를 변경하는 훈련 데이터셋에 포함하지 못하도록 규정하는 한편, 텔레메트리 처리는 별도로 규정한다. 또한 표준 MCA에는 서비스의 벤치마크 또는 성능 정보를 공개하는 것을 금지하는 조항이 있어 기업이 자사 평가를 외부 공개하는 경우 계약 조건과 개별 허가를 확인해야 한다. 현재 공개되지 않은 내용은 파라미터 수, 기본 체크포인트, 모델 아키텍처 상세, 병렬 샘플러 구현, RLCD의 재현 가능한 알고리즘 및 보상 설계, 튜터 모델 유무, 가중치 등이다. TypeSafe는 Jev를 소형 LLM이 아닌 별도의 클래스 모델로 간주하지만, 공개 정보만으로는 아키텍처상의 경계를 제3자가 검증할 수 없다. 환율은 원칙적으로 1달러 160엔으로 추정했다.

이제부터 이 프로젝트의 핵심 부분인 ‘별의 요정’의 번역에 대해 심층적으로 논의하겠습니다. 첫째, 이 작품은 앙리 드 센-테크쥐페리가 여러 언어로 번역할 때 수차례 수정했다는 점을 고려해야 합니다. 이는 그의 작품에 대한 깊은 애정과 독자들에 대한 배려를 엿볼 수 있는 부분입니다. 동시에 번역가에게 원점에 돌아가 작가의 의도를 최대한 이해하려는 노력이 필수적임을 시사합니다. 특히 이 작품은 간결함 속에 깊은 철학적 메시지를 담고 있어, 번역가는 단순히 단어를 대체하는 것뿐만 아니라, 그 단어가 지닌 의미와 이야기 전체를 통해 흐르는 감정을 어떻게 표현할 것인가라는 매우 어려운 과제에 직면합니다. 예를 들어, 왕자가 사막에서 만나는 다양한 인물들과의 대화는 각각 상징하는 의미를 가지고 있기 때문에, 번역가는 각 인물의 성격과 왕자와의 대화를 통해 작가가 전달하고자 하는 메시지를 어떻게 효과적으로 전달할 것인가라는 점에 주의해야 합니다. 또한 이 작품은 어린이들의 이야기이면서 동시에 어른들에게도 생각할 거리를 제공하는 작품이기 때문에, 번역가는 어린이들도 이해할 수 있도록 쉬운 단어로 표현하는 것뿐만 아니라, 어른들에게도 감동을 줄 수 있는 세련된 표현을 갖추도록 노력해야 합니다. 이 프로젝트에서는 이러한 과제를 극복하기 위해 번역팀 전체가 긴밀하게 협력하여 다양한 의견을 참고하며 번역을 진행했습니다. 최종적으로 완성된 번역은 앙리 드 센-테크쥐페리 스스로가 인정하는 최고의 번역 중 하나로 평가받고 있습니다. 이 번역을 통해 ‘별의 요정’의 아름다운 이야기가 더 많은 독자들에게 전달되기를 바랍니다.

TypeSafe AI는 개발자가 안전하고 신뢰할 수 있는 방식으로 AI 모델을 배포하고 관리할 수 있도록 돕는 플랫폼입니다. TypeSafe AI는 AI 모델의 성능을 모니터링하고, 잠재적인 문제를 감지하며, 모델을 지속적으로 개선하는 데 필요한 도구를 제공합니다. 또한, TypeSafe AI는 AI 모델의 보안을 강화하고, 악의적인 공격으로부터 보호하는 데에도 도움이 됩니다. TypeSafe AI는 특히 대규모 언어 모델(LLM)과 같은 복잡한 AI 모델을 배포하고 관리하는 데 유용합니다. TypeSafe AI를 사용하면 개발자는 AI 모델의 성능을 실시간으로 모니터링하고, 모델의 동작을 분석하며, 모델의 문제점을 해결할 수 있습니다. 또한, TypeSafe AI는 AI 모델의 배포 프로세스를 자동화하고, 모델의 업데이트를 관리하며, 모델의 사용량을 추적하는 데에도 도움이 됩니다. TypeSafe AI는 다음과 같은 주요 기능을 제공합니다. * **실시간 성능 모니터링:** AI 모델의 성능을 실시간으로 모니터링하고, 성능 저하를 감지하며, 성능 개선을 위한 조치를 취할 수 있습니다. * **이상 감지:** AI 모델의 동작에서 이상 징후를 감지하고, 잠재적인 문제를 사전에 예방할 수 있습니다. * **모델 개선:** AI 모델의 성능을 지속적으로 개선하기 위한 도구를 제공합니다. * **보안 강화:** AI 모델의 보안을 강화하고, 악의적인 공격으로부터 보호합니다. * **자동화된 배포:** AI 모델의 배포 프로세스를 자동화하고, 배포 시간을 단축할 수 있습니다. * **업데이트 관리:** AI 모델의 업데이트를 관리하고, 업데이트 프로세스를 자동화할 수 있습니다. * **사용량 추적:** AI 모델의 사용량을 추적하고, 사용 패턴을 분석할 수 있습니다.

시스템 원 모델과 Jev를 소개합니다. 최근 Typesafe AI에서 개발한 시스템 원 모델과 Jev에 대한 정보를 소개합니다. 시스템 원 모델은 인간의 인지 과정을 모방하여 복잡한 문제를 해결하는 데 특화된 새로운 AI 모델입니다. 특히, 시스템 원 모델은 ‘시스템 1’과 ‘시스템 2’라는 두 가지 인지 시스템을 결합하여 작동합니다. 시스템 1은 직관적이고 자동적인 방식으로 작동하며, 빠르게 판단하고 결정을 내립니다. 반면, 시스템 2는 의식적이고 분석적인 방식으로 작동하며, 복잡한 문제를 해결하고 논리적인 결론을 도출합니다. 시스템 원 모델은 이 두 시스템을 유기적으로 연결하여, 시스템 1의 빠른 판단력과 시스템 2의 분석 능력을 모두 활용할 수 있습니다. Jev는 시스템 원 모델을 기반으로 구축된 새로운 도구입니다. Jev는 사용자가 시스템 원 모델을 활용하여 다양한 문제를 해결하도록 돕습니다. Jev는 특히, 복잡한 데이터 분석, 의사 결정 지원, 그리고 창의적인 문제 해결에 유용합니다. Typesafe AI는 시스템 원 모델과 Jev를 통해 인공지능 분야에 새로운 가능성을 열고자 합니다. 앞으로 시스템 원 모델과 Jev는 다양한 산업 분야에서 활용될 것으로 기대됩니다.

인공지능은 단순한 도구가 아닌, 새로운 형태의 지능으로서 우리의 창의성과 생산성을 증폭시키는 데 활용될 수 있습니다. TypeSafe AI는 인공지능이 모든 사람에게 도움이 되도록 하는 데 헌신하고 있습니다. 우리는 인공지능이 인간의 삶을 개선하는 데 기여할 수 있다고 믿습니다. 의료, 교육, 환경 보호 등 다양한 분야에서 인공지능을 활용할 수 있으며, 우리의 일상생활을 더욱 편리하고 효율적으로 만들 수 있습니다. TypeSafe AI는 인공지능 개발에 대한 책임감 있는 접근 방식을 지지하며, 인공지능이 안전하고 신뢰할 수 있으며 윤리적으로 개발되어야 한다고 믿습니다. 인공지능이 인간의 가치를 존중하고 인간의 권리를 보호하도록 하는 데 전념하고 있습니다. TypeSafe AI는 인공지능 개발에 참여하는 모든 이해관계자와 협력하고 있으며, 인공지능이 인류의 미래를 형성하는 데 중요한 역할을 할 것이라고 기대합니다.

그렇기 때문에, 우리는 이 경험을 통해, 특히 챗봇과 같은 AI 모델이 인간의 창의성을 완전히 대체할 수 없다는 것을 깨달았습니다. 챗봇은 방대한 데이터를 기반으로 패턴을 학습하고, 이를 바탕으로 새로운 텍스트를 생성할 수 있습니다. 하지만 챗봇은 진정으로 ‘창의적’이라고 할 수 있는, 즉 완전히 새로운 아이디어를 떠올리거나, 기존의 아이디어를 완전히 새로운 방식으로 조합하는 능력은 아직 가지고 있지 않습니다. 예를 들어, 챗봇이 ‘고양이’라는 단어를 입력하면, 챗봇은 ‘고양이’에 대한 정보를 바탕으로 다양한 텍스트를 생성할 수 있습니다. 하지만 챗봇은 ‘고양이’를 소재로 하여 인간이 상상할 수 있는 것과 같은 독창적인 이야기를 만들거나, 새로운 시를 쓰거나, 새로운 예술 작품을 창작할 수는 없습니다. 이러한 점을 고려할 때, 챗봇은 인간의 창의성을 보조하는 도구로 활용될 수 있지만, 인간의 창의성을 완전히 대체할 수는 없습니다. 챗봇은 인간의 아이디어를 더욱 발전시키고, 새로운 가능성을 탐색하는 데 도움을 줄 수 있지만, 궁극적으로는 인간의 창의성이 만들어내는 독창적인 결과물은 챗봇이 따라올 수 없는 영역에 속합니다. 이러한 경험을 통해, 우리는 AI 기술의 한계를 명확하게 인식하고, AI 기술을 인간의 창의성을 보완하고 강화하는 방향으로 활용하는 것이 중요하다는 것을 깨달았습니다. 앞으로도 AI 기술은 계속 발전할 것이지만, 인간의 창의성은 여전히 중요한 가치를 지니고 있으며, AI 기술과 인간의 창의성이 서로 협력하여 더욱 놀라운 결과물을 만들어낼 수 있을 것이라고 믿습니다. 특히 ‘인간의 창의성’이라는 개념은 매우 복잡하고 다층적인 의미를 지니고 있습니다. 인간의 창의성은 단순히 새로운 아이디어를 떠올리는 능력뿐만 아니라, 아이디어를 평가하고 선택하는 능력, 아이디어를 현실로 구현하는 능력 등 다양한 요소를 포함합니다. 챗봇은 이러한 모든 요소를 완벽하게 수행할 수는 없으며, 인간의 창의성은 이러한 요소를 통합하여 작동하는 복잡한 시스템입니다. 결론적으로, 챗봇은 인간의 창의성을 완전히 대체할 수 없으며, 인간의 창의성을 보조하는 도구로 활용될 수 있습니다. 앞으로도 AI 기술은 계속 발전할 것이지만, 인간의 창의성은 여전히 중요한 가치를 지니고 있으며, AI 기술과 인간의 창의성이 서로 협력하여 더욱 놀라운 결과물을 만들어낼 수 있을 것이라고 믿습니다.

TypeSafe AI 팀 TypeSafe는 사이버 보안 위협을 실시간으로 탐지하고 대응하는 데 전념하는 기업입니다. 저희는 전 세계의 가장 중요한 조직을 보호하기 위해 최첨단 AI 기반 위협 인텔리전스 플랫폼을 구축하고 있습니다. TypeSafe 팀은 전 세계의 뛰어난 보안 전문가들로 구성되어 있습니다. 저희는 위협 인텔리전스, 사이버 보안, 인공지능 분야에서 풍부한 경험을 가진 전문가들입니다. TypeSafe 팀은 다음과 같은 핵심 분야에서 전문성을 가지고 있습니다. * **위협 인텔리전스:** TypeSafe는 전 세계의 다양한 소스에서 수집된 위협 인텔리전스를 제공합니다. 저희는 최신 위협 트렌드를 파악하고, 새로운 위협을 식별하며, 공격자의 활동을 추적합니다. * **사이버 보안:** TypeSafe는 다양한 사이버 보안 솔루션을 제공합니다. 저희는 위협 인텔리전스를 활용하여 네트워크를 보호하고, 악성 소프트웨어를 탐지하며, 사이버 공격을 방어합니다. * **인공지능:** TypeSafe는 인공지능을 활용하여 위협 인텔리전스를 분석하고, 위협을 탐지하며, 사이버 보안 솔루션을 개선합니다. 저희는 머신 러닝, 자연어 처리, 컴퓨터 비전 등 다양한 인공지능 기술을 활용합니다.

TypeSafe AI 문서는 https://docs.typesafe.ai/ 에서 확인할 수 있습니다. TypeSafe AI는 엔터프라이즈 환경에서 AI 모델을 안전하게 관리하고 배포하기 위한 플랫폼입니다. TypeSafe AI는 다음과 같은 주요 기능을 제공합니다. * **모델 카탈로그:** AI 모델의 메타데이터, 버전, 라이선스, 성능 지표 등을 중앙 집중식으로 관리합니다. 이를 통해 조직은 AI 모델을 쉽게 검색하고 찾을 수 있습니다. * **모델 평가:** 다양한 지표를 사용하여 AI 모델의 성능을 평가하고 비교합니다. 이를 통해 조직은 가장 적합한 모델을 선택할 수 있습니다. * **모델 배포:** AI 모델을 다양한 환경(예: 클라우드, 온프레미스)에 쉽게 배포합니다. * **모델 모니터링:** AI 모델의 성능을 실시간으로 모니터링하고 문제를 해결합니다. * **모델 거버넌스:** AI 모델의 사용을 규제하고 관리합니다. TypeSafe AI는 다음과 같은 조직에 적합합니다. * AI 모델을 사용하는 모든 조직 * AI 모델의 안전하고 효율적인 관리를 원하는 조직 * AI 모델의 거버넌스 요구 사항을 충족해야 하는 조직 TypeSafe AI는 다음과 같은 기술 스택을 기반으로 구축되었습니다. * Java * Scala * Kubernetes * Docker TypeSafe AI에 대한 자세한 내용은 [TypeSafe AI 웹사이트](https://www.typesafe.ai/)를 참조하십시오.

Primitives는 Typesafe가 개발한 오픈 소스 데이터 모델링 라이브러리입니다. 복잡한 데이터 구조를 쉽게 정의하고 관리할 수 있도록 설계되었으며, 특히 데이터 파이프라인, 데이터 변환, 데이터 유효성 검사 등 다양한 데이터 관련 작업에 유용합니다. Primitives는 JSON과 유사한 형태의 데이터 모델을 정의할 수 있도록 지원하며, 이 모델은 다양한 프로그래밍 언어에서 사용할 수 있습니다. 또한 데이터 변환 및 유효성 검사 기능을 제공하여 데이터 품질을 향상시키는 데 도움을 줍니다. Primitives의 주요 특징은 다음과 같습니다. * 간결한 모델 정의 * 다양한 언어 지원 * 데이터 유효성 검사 * 데이터 변환 * 오픈 소스 Primitives는 데이터 중심의 애플리케이션 개발을 위한 강력한 도구이며, 데이터 파이프라인 구축, 데이터 변환 작업, 데이터 유효성 검사 등 다양한 데이터 관련 작업에 활용될 수 있습니다. Typesafe는 Primitives의 지속적인 개발과 개선을 통해 데이터 관리의 효율성을 높이는 데 기여할 것입니다.

시스템 원 개념 인간의 두 가지 사고 시스템, 시스템 1과 시스템 2는 우리의 생각과 행동을 이해하는 데 중요한 역할을 합니다. 시스템 1은 자동적이고 직관적이며 빠르게 작동하는 반면, 시스템 2는 의식적이고 계산적이며 더 많은 노력을 필요로 합니다. **시스템 1** 시스템 1은 우리의 무의식적인 사고 방식을 나타냅니다. 이는 우리의 직관, 감정, 자동적인 반응과 관련이 있습니다. 시스템 1은 빠르고 효율적이지만, 오류가 발생하기 쉽고, 논리적인 추론이나 복잡한 문제 해결에는 적합하지 않습니다. * **자동적이고 직관적:** 시스템 1은 외부 자극에 즉각적으로 반응하며, 명확한 의식적 노력 없이 작동합니다. 예를 들어, 우리는 운전 중 다른 차량의 움직임을 자동으로 감지하고 반응합니다. * **감정적:** 시스템 1은 감정에 의해 영향을 받기 쉽습니다. 예를 들어, 우리는 아름다운 풍경을 보거나 좋아하는 음악을 들을 때 행복감을 느낍니다. * **제한된 주의:** 시스템 1은 한 번에 하나의 작업에만 집중할 수 있습니다. 예를 들어, 우리는 동시에 여러 대의 자동차를 운전하거나, 대화를 나누면서 동시에 책을 읽을 수 없습니다. **시스템 2** 시스템 2는 우리의 의식적인 사고 방식을 나타냅니다. 이는 우리의 논리적 추론, 문제 해결, 계획 수립과 관련이 있습니다. 시스템 2는 더 느리고 어렵지만, 더 정확하고 신뢰할 수 있는 결과를 제공합니다. * **의식적이고 계산적:** 시스템 2는 명확한 의식적 노력과 계산을 필요로 합니다. 예를 들어, 우리는 수학 문제를 풀거나, 복잡한 계획을 수립할 때 시스템 2를 사용합니다. * **집중적:** 시스템 2는 한 번에 하나의 작업에만 집중할 수 있습니다. 예를 들어, 우리는 어려운 문제를 풀면서 다른 생각을 하지 못합니다. * **에너지가 많이 소모됨:** 시스템 2는 시스템 1보다 더 많은 에너지를 소모합니다. 따라서 우리는 시스템 1의 자동적인 반응에 의존하는 경우가 많습니다. **두 시스템의 상호 작용** 시스템 1과 시스템 2는 서로 협력하여 우리의 생각과 행동을 결정합니다. 시스템 1은 빠르게 정보를 처리하고, 시스템 2는 필요에 따라 더 자세한 분석을 수행합니다. 예를 들어, 우리는 운전 중 다른 차량의 움직임을 감지하고, 시스템 1은 즉각적으로 반응하도록 유도합니다. 동시에 시스템 2는 주변 환경과 교통 상황을 고려하여 안전하게 운전하도록 돕습니다. 이러한 두 시스템의 상호 작용은 우리가 의사 결정을 내리는 방식에 큰 영향을 미칩니다. 시스템 1은 우리의 직관과 감정에 따라 빠르게 결정을 내리지만, 시스템 2는 이러한 결정을 비판적으로 평가하고 수정할 수 있습니다.

머신 러닝은 컴퓨터가 명시적인 프로그래밍 없이도 학습할 수 있도록 하는 기술입니다. 즉, 컴퓨터가 데이터를 통해 스스로 패턴을 파악하고 예측 또는 의사 결정을 내릴 수 있도록 하는 것입니다. 머신 러닝은 크게 지도 학습, 비지도 학습, 강화 학습으로 분류할 수 있습니다. * **지도 학습 (Supervised Learning):** 정답이 알려진 데이터를 사용하여 모델을 학습시키는 방법입니다. 예를 들어, 고양이와 강아지의 이미지를 각각 ‘고양이’ 또는 ‘강아지’라고 레이블링하여 모델에 학습시키면, 새로운 이미지가 들어오면 고양이인지 강아지인지 예측할 수 있습니다. * **비지도 학습 (Unsupervised Learning):** 정답이 없는 데이터를 사용하여 모델을 학습시키는 방법입니다. 예를 들어, 고객 데이터를 클러스터링하여 유사한 특성을 가진 고객 그룹을 찾거나, 데이터에서 숨겨진 패턴을 발견할 수 있습니다. * **강화 학습 (Reinforcement Learning):** 에이전트가 환경과 상호 작용하면서 보상을 최대화하는 방향으로 학습하는 방법입니다. 예를 들어, 게임 AI가 게임을 플레이하면서 승리하는 방법을 학습하는 데 사용될 수 있습니다. 머신 러닝은 다양한 분야에서 활용되고 있습니다. 예를 들어, 의료 분야에서는 질병 진단, 금융 분야에서는 사기 탐지, 마케팅 분야에서는 고객 맞춤형 추천 등에 활용됩니다. 이 자료는 머신 러닝의 기본적인 개념을 소개하는 것을 목적으로 합니다. 더 자세한 내용은 관련 서적이나 온라인 자료를 참고하십시오.

자신감은 OpenAI의 GPT-3 모델을 기반으로 구축된 챗봇입니다. 자신감은 질문에 답변하고, 텍스트를 생성하며, 다양한 작업을 수행할 수 있습니다. 자신감은 특히 다음과 같은 분야에서 뛰어난 성능을 보입니다. * **지식 기반 질문 응답:** 자신감은 방대한 양의 텍스트 데이터를 학습하여 질문에 정확하고 상세하게 답변할 수 있습니다. * **텍스트 생성:** 자신감은 다양한 스타일과 형식으로 텍스트를 생성할 수 있습니다. 예를 들어, 이메일, 기사, 시, 코드 등을 생성할 수 있습니다. * **요약:** 자신감은 긴 텍스트를 짧고 간결하게 요약할 수 있습니다. * **번역:** 자신감은 다양한 언어 간 번역을 수행할 수 있습니다. * **코드 생성:** 자신감은 다양한 프로그래밍 언어로 코드를 생성할 수 있습니다. 자신감은 지속적으로 학습하고 개선되고 있으며, 앞으로 더욱 다양한 기능을 제공할 것으로 기대됩니다. 자신감을 사용하면 생산성을 높이고 창의적인 작업을 수행하는 데 도움이 될 수 있습니다. 자신감은 OpenAI의 강력한 AI 기술을 활용하여 여러분의 문제를 해결하고 목표를 달성하는 데 기여할 것입니다. 자신감은 여러분의 디지털 라이프를 더욱 풍요롭게 만들어 줄 것입니다.

LangChain은 다양한 프레임워크와 모델을 연결하는 데 중점을 둡니다. 특히 OpenAI, Cohere, Hugging Face, Google PaLM 2와 같은 모델을 지원합니다. LangChain은 이러한 모델들을 활용하여 복잡한 작업을 수행할 수 있도록 다양한 도구와 기능을 제공합니다. 예를 들어, LangChain은 프롬프트 템플릿, 체인, 에이전트 등 다양한 구성 요소를 통해 사용자가 원하는 방식으로 모델을 활용할 수 있도록 돕습니다. 또한, LangChain은 데이터 연결, 메모리, 지식 베이스 등 다양한 기능을 통해 모델의 성능을 향상시키는 데 기여합니다. LangChain은 지속적으로 업데이트되고 있으며, 새로운 모델과 기능을 지원하기 위해 노력하고 있습니다.

워크플로우 평가 기능은 Typesafe AI의 evals 서비스를 통해 제공됩니다. 이 기능은 특정 워크플로우의 실행 결과를 평가하고, 그 결과를 바탕으로 워크플로우를 개선하거나 최적화하는 데 도움을 줍니다. evals 서비스는 다양한 데이터 소스를 활용하여 워크플로우의 성능을 측정하고 분석하며, 이를 통해 사용자에게 맞춤형 개선 제안을 제공합니다.

마스터 고객 계약

데이터 처리 부록 본 계약의 데이터 처리 관련 조항은 Typesafe AI의 데이터 처리 정책을 준수합니다. Typesafe AI는 고객의 데이터를 안전하게 처리하고 보호하기 위해 최선을 다하며, 관련 법규 및 규정을 준수합니다. Typesafe AI는 고객의 데이터를 다음 목적으로 처리합니다. * Typesafe AI 제품 및 서비스 제공 * 제품 및 서비스 개선 * 고객 지원 * 마케팅 및 홍보 (고객의 동의를 얻은 경우) * 데이터 분석 및 보고 (익명화된 데이터 또는 집계된 데이터의 경우) Typesafe AI는 고객의 데이터를 다음 방식으로 처리합니다. * Typesafe AI의 데이터 센터에서 처리 * Typesafe AI의 보안 시스템을 통해 보호 * Typesafe AI의 데이터 처리 정책에 따라 처리 Typesafe AI는 고객의 개인 정보 보호를 위해 다음 조치를 취합니다. * 개인 정보 보호 정책을 수립하고 시행 * 개인 정보 보호 교육을 실시 * 개인 정보 보호 관련 법규 및 규정을 준수 Typesafe AI는 고객의 데이터 처리 관련 문의 사항에 대해 신속하고 정확하게 답변합니다.

개인정보처리방침은 Typesafe AI의 웹사이트 및 서비스(이하 “서비스”)를 이용하시는 분들의 개인정보를 처리하는 방법에 대한 내용을 담고 있습니다. 본 개인정보처리방침은 서비스 이용과 관련하여 Typesafe AI가 수집, 사용, 공개, 공유, 판매하는 개인정보의 종류와 방법에 대한 정보를 제공합니다. 본 개인정보처리방침은 서비스 이용에 앞서 Typesafe AI가 여러분의 개인정보를 어떻게 다루는지 이해하도록 돕기 위해 작성되었으며, Typesafe AI의 정책 변경에 따라 수정될 수 있습니다. 변경 시에는 본 개인정보처리방침을 웹사이트에 게시하여 공지합니다. 본 개인정보처리방침에 명시되지 않은 개인정보 처리 방법에 대한 문의는 Typesafe AI에 문의해주시기 바랍니다. Typesafe AI는 다음과 같은 개인정보를 수집합니다. * **수집하는 정보:** Typesafe AI는 서비스 이용과 관련된 정보를 수집합니다. 여기에는 다음이 포함될 수 있습니다. * 이름 * 이메일 주소 * IP 주소 * 사용자 계정 정보 * 서비스 이용 기록 * 기술 데이터(브라우저 유형, 운영체제, IP 주소, 방문 URL 등) * 개인정보보호법에 따라 본인 확인을 위해 수집하는 정보 * **정보 사용 목적:** Typesafe AI는 수집한 정보를 다음과 같은 목적으로 사용합니다. * 서비스 제공 및 개선 * 사용자 지원 * 서비스 관련 통지 * 신규 서비스 개발 * 서비스 이용 분석 * 개인정보보호법 등 관련 법규 준수 * **정보 제공:** Typesafe AI는 다음과 같은 경우에 개인정보를 제3자에게 제공할 수 있습니다. * 서비스 제공을 위해 필요한 경우(예: 클라우드 서비스 제공업체) * 법률에 의해 요구되는 경우 * 서비스 이용자의 동의를 얻은 경우 * **정보 공유:** Typesafe AI는 서비스 개선 및 사용자 지원을 위해 개인정보를 다른 Typesafe AI 서비스와 공유할 수 있습니다. * **정보 보관:** Typesafe AI는 개인정보를 법적으로 보관 의무가 있는 기간 동안 보관합니다. * **개인정보 열람, 정정, 삭제:** Typesafe AI는 개인정보보호법에 따라 서비스 이용자가 자신의 개인정보에 대한 열람, 정정, 삭제를 요청할 수 있습니다.

이용 약관 Typesafe

System One LLM 어댑터

InstructGPT 논문 https://arxiv.org/abs/2203.02155

OpenAI GPT-4 기여자 OpenAI는 GPT-4 기여자 프로그램을 통해 GPT-4 모델을 개선하는 데 도움을 주시는 분들께 보답하고자 합니다. 이 프로그램은 GPT-4를 활용하여 생성된 데이터를 평가하고 피드백을 제공함으로써 모델의 성능을 향상시키는 데 기여하는 데 중점을 둡니다. 저희는 GPT-4를 사용한 다양한 작업에 대한 여러분의 의견을 환영합니다. 여기에는 다음이 포함됩니다. * **텍스트 생성:** GPT-4가 생성한 텍스트의 품질, 관련성 및 창의성을 평가합니다. * **코드 생성:** GPT-4가 생성한 코드의 정확성, 효율성 및 가독성을 평가합니다. * **번역:** GPT-4가 수행한 번역의 정확성, 자연스러움 및 문맥 적합성을 평가합니다. * **질의 응답:** GPT-4가 제공한 답변의 정확성, 완전성 및 유용성을 평가합니다. * **기타 작업:** GPT-4가 수행한 기타 작업에 대한 여러분의 의견을 제공합니다. 저희는 여러분의 의견을 통해 GPT-4가 더욱 강력하고 유용하게 발전할 수 있도록 돕고자 합니다. 여러분의 참여에 진심으로 감사드립니다.

Vercel AI 게이트웨이 Jev 발표, Typesafe AI의 Jev가 AI 게이트웨이에서 사용 가능하다고 발표했습니다. Jev는 대규모 언어 모델(LLM)에 최적화되어 빠른 응답 속도와 낮은 지연 시간을 제공하며, 다양한 AI 모델을 지원하여 개발자가 쉽게 구성할 수 있습니다.

Vercel Jev 모델 페이지는 Vercel에서 제공하는 AI 게이트웨이 내에 위치하며, 이 모델은 특히 일본어 텍스트 생성에 특화되어 있습니다. Vercel의 안정적인 인프라를 통해 높은 성능을 제공하는 Jev 모델은 다양한 텍스트 생성 작업에 활용될 수 있습니다. 자세한 내용은 Vercel AI 게이트웨이 모델 페이지를 참조하십시오.

Netlify AI 게이트웨이 Jev 발표 Netlify는 AI 게이트웨이용 새로운 유형인 Jev를 발표했습니다. Jev는 특히 AI 모델을 활용하는 애플리케이션을 위한 최적화된 솔루션입니다. Jev는 Netlify의 기존 AI 게이트웨이와 마찬가지로 모델 배포 및 관리에 필요한 모든 기능을 제공하지만, 추론 속도 향상, 비용 절감, 개발자 워크플로우 간소화에 초점을 맞추도록 설계되었습니다. Jev는 다음과 같은 주요 기능을 제공합니다. * 최적화된 추론: Jev는 모델의 추론 속도를 향상시키기 위해 특별히 설계되었습니다. 이를 통해 개발자는 더 빠른 응답 시간을 얻고 사용자 경험을 개선할 수 있습니다. * 비용 절감: Jev는 모델 추론 비용을 절감하는 데 도움이 됩니다. * 간소화된 워크플로우: Jev는 개발자의 워크플로우를 간소화하도록 설계되었습니다.

모든 평가[https://every.to/also-true-for-humans/mini-vibe-check-typesafe-s-jev-judged-everything-i-ve-written-in-0-7-seconds](https://every.to/also-true-for-humans/mini-vibe-check-typesafe-s-jev-judged-everything-i-ve-written-in-0-7-seconds) 역시 인간에게도 유효합니다. Typesafe S-JEV는 제가 0.7초 안에 작성한 모든 것을 평가했습니다.

Aera 평가: 에이전트 메모리가 생성자를 필요로 하지 않습니다 – Typesafe JEV vs LLM을 400개의 실제 작업에서 평가

개발자 IO 모델 라우팅 테스트는 LLM 모델 라우팅을 위한 DevClass 모델을 활용하여 LLM 모델을 효율적으로 라우팅하는 방법을 보여줍니다. 이 테스트는 DevClass 모델 설정, LLM 모델 등록, 요청 라우팅, 결과 확인 등의 단계를 포함합니다. 이를 통해 LLM 모델을 DevClass 모델을 사용하여 라우팅하는 방법을 이해할 수 있습니다.

최근 개발자 IO에서 진행한 언어 모델 실험 결과, 특정 언어 모델이 특정 언어에 강점을 보이는 현상을 확인했습니다. 이 실험은 개발자 IO의 자체 개발한 언어 모델을 대상으로 진행되었으며, 이 모델은 일본어 데이터셋을 기반으로 학습되었습니다. 실험 결과, 이 모델은 일본어 텍스트 생성 능력에서 뛰어난 성능을 보였으며, 특히 일본어 문법 및 어휘 사용에 있어서 자연스럽고 유창한 텍스트를 생성하는 데 성공했습니다. 이는 언어 모델이 학습 데이터의 특징을 반영하여 특정 언어에 대한 전문성을 갖게 되는 현상을 보여줍니다. 이 실험은 언어 모델의 성능을 평가하고 개선하는 데 중요한 자료로 활용될 수 있을 뿐만 아니라, 언어 모델 개발 시 데이터셋의 중요성을 다시 한번 강조하는 계기가 되었습니다. 앞으로도 개발자 IO는 다양한 언어 모델 실험을 통해 언어 모델 기술을 발전시켜 나갈 계획입니다.

YTAL 프로덕션 로그 재생 재현 URL: https://ytal.io/blog/typesafe-jev-entity-resolution-production-replay/

CounterProof 벤치마크 감사 보고서: Typesafe JEV 벤치마크, 합의를 오라클로 활용하기

세안 고에데크의 기술 분석 JEV(JSON 유사 이벤트 뷰어)를 통한 구조화된 출력의 중요성 재조명 본 글에서는 JEV(JSON 유사 이벤트 뷰어)를 통해 얻을 수 있는 구조화된 출력의 가치를 다시 한번 강조합니다. JEV는 Windows 운영체제에서 발생하는 다양한 이벤트를 JSON 형식으로 출력하여 분석가들이 데이터를 보다 효율적으로 활용할 수 있도록 지원하는 도구입니다. 특히, JEV를 활용하여 특정 이벤트의 발생 빈도, 시간 패턴, 관련 시스템 정보 등을 파악함으로써 시스템의 문제점을 진단하고 해결하는 데 큰 도움이 됩니다. 또한, JEV의 출력 결과를 다양한 분석 도구와 연동하여 더욱 심층적인 분석을 수행할 수 있습니다. 최근에는 클라우드 환경에서 발생하는 이벤트 데이터를 분석하는 데 JEV가 널리 활용되고 있으며, DevOps 문화 확산과 함께 개발 및 운영 팀 간의 협업을 강화하는 데 기여하고 있습니다. JEV를 통해 얻을 수 있는 구조화된 출력은 단순한 로그 분석을 넘어 시스템의 성능을 최적화하고 안정성을 확보하는 데 필수적인 요소입니다. 앞으로도 JEV는 시스템 분석 및 문제 해결 분야에서 더욱 중요한 역할을 수행할 것으로 기대됩니다.

TypeSafe AI의 모델은 둠(Doom)을 플레이하며, 이를 통해 AI의 능력을 평가했다. 이 모델은 텍스트 기반 지침과 함께 게임 내에서 특정 목표를 달성하기 위해 행동을 생성하도록 설계되었다. 예를 들어, “방을 탐색하고, 적을 찾아 파괴하고, 새로운 무기를 수집하고, 맵을 탐색하여 엔딩을 달성하라”와 같은 지시를 받았다. TypeSafe AI는 이 모델을 통해 AI가 복잡한 작업을 얼마나 효과적으로 수행하고, 주어진 지시를 이해하며, 실시간으로 적응하는지 평가했다. 둠과 같은 고도로 시각적이고 역동적인 환경에서 AI가 얼마나 잘 작동하는지를 측정하는 것은 AI 개발 분야에서 중요한 지표가 된다. TypeSafe AI는 이러한 평가를 통해 AI 모델의 성능을 개선하고, 더욱 강력하고 신뢰할 수 있는 AI 시스템을 개발하는 데 기여할 것으로 기대된다. 특히, 이 모델은 AI가 게임과 같은 실제 환경에서 복잡한 문제를 해결하는 능력을 보여주면서 AI 연구 및 개발 분야에 새로운 가능성을 제시했다.

Windows 11 업데이트로 마이크로소프트가 “성능 개선”을 강조했지만, 실제로는 CPU 부하를 늘리는 작업이 크게 증가했다는 지적이 나타나고 있습니다. 구체적으로 Windows 시작 시 실행되는 “Windows Search” 작업이 크게 증가했으며, “Windows Update” 작업도 늘어난 것을 확인했습니다. 이러한 작업들이 CPU 부하를 증가시키는 원인이 될 수 있으며, 특히 CPU 코어 수가 적은 PC나 사양이 낮은 PC에서는 성능 저하가 심각할 수 있습니다. 마이크로소프트는 이러한 작업을 최적화하여 성능을 개선해야 하지만, 현재는 오히려 성능 저하를 초래한다는 의견이 많습니다. 또한 Windows 11 업데이트 후 PC 동작이 불안정해진다는 보고도 이어지고 있으며, 이는 업데이트로 인한 시스템 파일 손상이나 드라이버 호환성 문제로 인해 발생할 수 있습니다. 이러한 문제들이 해결될 때까지 Windows 11 업데이트는 미루는 것이 좋습니다.

파이널 판타지 7 리메이크 출시 1주년을 맞아, 베타 테스트 참여자 및 플레이어 피드백을 반영한 대대적인 개선이 진행 중입니다. 특히 전투 시스템은 더욱 전략적인 배틀을 즐길 수 있도록 적 AI가 강화되었으며, 새로운 명령어나 액션이 추가되었습니다. 그래픽과 UI 또한 개선되어 더욱 아름답고 직관적인 조작이 가능해졌습니다. 개발팀은 플레이어 요청에 따라 게임 내 아이템 및 장비 밸런스 조정 작업을 진행했으며, 이를 통해 플레이어는 더욱 전략적인 파티 구성과 다양한 적 공략이 가능해졌습니다. 게임 난이도 또한 조절되어 초보자부터 고급자까지 폭넓은 계층의 플레이어가 즐길 수 있도록 설계되었습니다. 베타 테스트 결과를 바탕으로 향후 업데이트를 통해 게임의 매력을 높일 방안을 검토하고 있으며, 새로운 지역 및 캐릭터 추가, 게임 모드 추가 등이 고려될 수 있습니다. 개발팀은 플레이어 피드백을 적극적으로 수집하고 게임 발전에 힘쓸 것입니다.

저기, 그 그림 정말 멋지지 않아요? 저, 그 그림을 그렸던 사람이 사실… 그렇죠, 그 그림을 그렸던 건 사실 저와 같은 대학교의 미술 전공 학생이었어요. 다나카 켄타라는 이름의 학생이었죠. 그는 이 그림을 그렸던 게 대학 수업 과제였거나 그런 이야기가 아니라고 했어요. 개인적으로 이 그림을 그리고 싶었던 거랍니다. “왜 그 그림을 그렸는지” 물어봤을 때, 그는 이렇게 말했어요. “이 그림에는 제 인생의 여러 감정이 담겨 있어요. 특히, 그때 잃어버린 것들에 대한 깊은 슬픔과 그걸 극복하려는 희망의 마음…” 그는 이 그림을 완성하기 위해 6개월 동안 매일 꾸준히 그렸다고 해요. “이 그림은 저에게 소중한 보물이에요.” 그는 이렇게 마무리했어요. “이 그림을 당신에게 보여주고 당신에게 이 그림에 담긴 마음을 전하고 싶었어요.”

#제브 #타입세이프AI #디오고알메이다 #시스템원모델 #알알씨D #알알에이치에프 #인스트럭트GPT #오픈AI #인공지능 #생성AI #LLM #AI 에이전트 #에이전틱AI #구조화출력 #AI 인프라 #소프트웨어 자동화 #시스템1 #시스템2 #Physical AI #인간형 로봇 #ERP #MES

출처: note 원문

번역: Gemma 3(.44) 초벌 + 교정 264청크

원문 보기 | 출처: note.com