화제인 TypeSafe Jev, 실제로 어디에 쓰고 있을까?

 

AI · AI Agent · Decision Model

요즘 화제인 TypeSafe Jev, 실제로 어디에 쓰고 있을까?

ChatGPT나 Claude처럼 글을 생성하는 AI가 아니라, 소프트웨어가 바로 사용할 수 있는 판단 결과를 만들어내는 Jev가 등장했습니다. 실제 공개 사례와 측정 결과를 통해 Jev가 어디에 쓰이고 있는지 살펴봅니다.

작성 기준일 : 2026년 9월 23일
검증 기준 : TypeSafe 공식 홈페이지·공식 블로그·공식 GitHub 및 공개 Jev 데모

1. Jev가 대체 무엇인가?

최근 AI 개발자 사이에서 TypeSafe의 Jev가 빠르게 주목받고 있습니다.

Jev를 처음 보면 "또 하나의 LLM인가?"라는 생각이 들 수 있습니다. 하지만 TypeSafe가 설명하는 방향은 조금 다릅니다.

일반적인 LLM

입력 → 자연어 생성

Jev

애플리케이션 상태 → Typed Judgment + Probability

TypeSafe는 Jev를 자사의 첫 번째 System One Model이라고 설명합니다. 일반적인 LLM이 사람이 읽을 텍스트를 생성하는 데 최적화되어 있다면, System One Model은 소프트웨어가 직접 사용할 수 있는 구조화된 판단을 반환하는 방향으로 설계됐습니다. [oai_citation:8‡TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com)

즉 Jev의 핵심은 "무슨 말을 생성할 것인가?"가 아니라 "주어진 상황에서 어떤 판단을 내려야 하는가?"에 있습니다.

2. Jev는 어떤 결과를 반환할까?

Jev의 중요한 특징은 출력 형식이 처음부터 정의되어 있다는 것입니다. TypeSafe 공식 Skill에서는 대표적인 판단 primitive를 Choice, Score, Noul로 설명합니다. [oai_citation:9‡GitHub](https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md?utm_source=chatgpt.com)

Primitive	의미	예시
Choice	정해진 선택지 중 하나를 선택	문의 유형 → 결제 / 기술지원 / 배송
Score	정렬 가능한 수준으로 평가	긴급도 → 낮음 / 보통 / 높음 / 매우 높음
Noul	조건이 참일 확률을 판단	이 메일은 답장이 필요한가?

Noul을 단순한 "확률값"으로 이해하면 안 됩니다.
Noul은 특정 조건에 대해 "Yes일 확률"을 제공하는 판단 primitive입니다. 별도의 "confidence"와 동일한 개념도 아닙니다. 여러 항목이 동시에 참일 수 있는 경우에는 각각 별도의 Noul을 사용하는 방식이 공식 가이드에 제시되어 있습니다. [oai_citation:10‡GitHub](https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md?utm_source=chatgpt.com)

3. 이메일 하나를 예로 들어보면

예를 들어 다음과 같은 이메일이 들어왔다고 가정해 보겠습니다.

메일
"지난주 결제한 서비스에 문제가 있습니다. 오늘 안에 확인 부탁드립니다."

기존 방식에서는 LLM에게 메일 전체를 전달하고 "분류하고 우선순위를 정한 다음 어떻게 처리할지 알려줘"라고 요청할 수 있습니다.

Jev 방식에서는 판단을 작게 나눌 수 있습니다.

Choice → 어떤 유형의 문의인가?

Score → 얼마나 긴급한가?

Noul → 답장이 필요한가?

그리고 중요한 것은 최종 실행은 코드가 담당한다는 것입니다.

이메일 수신
↓
Jev 판단
↓
구조화된 결과
↓
애플리케이션 코드
↓
담당자 라우팅 / 자동 답변 / Human Review

TypeSafe 공식 Skill 역시 알려진 규칙과 계산, 정확한 조회, 실제 실행은 코드가 담당하고 의미를 이해해야 하는 판단을 Jev에 맡기는 방식을 권장합니다. [oai_citation:11‡GitHub](https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md?utm_source=chatgpt.com)

4. 그런데 Jev가 왜 이렇게 빠른가?

TypeSafe가 설명하는 핵심 차이 중 하나는 출력 생성 방식입니다.

일반적인 LLM은 토큰을 순차적으로 생성합니다. 반면 Jev는 구조화된 판단 결과를 병렬적으로 생성하도록 설계됐다고 TypeSafe는 설명합니다. [oai_citation:12‡TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com)

LLM

토큰을 순차적으로 생성하면서 자연어 답변을 만듭니다.

Jev

미리 정의된 구조화된 판단을 병렬적으로 반환하는 방향으로 설계됐습니다.

TypeSafe 공식 발표에서 제시한 Jev의 end-to-end 응답시간은 70ms~500ms입니다. 다만 TypeSafe는 자사의 서비스 환경에서 측정한 값이며, 공개된 평가가 주로 미국 서부 지역의 노트북 환경에서 실행됐다는 점도 함께 밝히고 있습니다. 따라서 실제 서비스의 전체 지연시간은 네트워크와 애플리케이션 처리 등을 포함해 달라질 수 있습니다. [oai_citation:13‡TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com)

5. 비용은 실제로 얼마나 저렴할까?

TypeSafe 공식 공개 가격

$0.042

입력 100만 토큰(MTok) 기준

출력 토큰 비용 : 무료

TypeSafe 공식 발표는 Jev의 입력 비용을 1M tokens당 $0.042로 공개하고 있으며, 출력은 측정할 필요가 없을 정도로 저렴해 무료로 제공한다고 설명합니다. [oai_citation:14‡TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com)

이를 단순 계산하면 10만 입력 토큰은 약 $0.0042에 해당합니다. 단, 이것은 공식 가격을 단순 비례 계산한 값이며 특정 애플리케이션의 실제 청구액을 의미하는 실측값은 아닙니다.

주의
API 비용만 계산한 값과 실제 서비스 전체 비용은 다릅니다. 데이터 수집, 다른 LLM 호출, 저장소, 네트워크, 애플리케이션 실행 비용 등이 별도로 발생할 수 있습니다.

6. 실제 공개 사례 ① — 이메일 500개 분류

Jev의 특징을 가장 직관적으로 보여주는 사례 중 하나가 이메일 분류입니다.

공개 제작자 측정

500개 이메일

처리 비용 약 $0.035

수 초 수준의 처리 시간으로 공개

공개 사례에는 500개의 이메일을 분류한 결과가 $0.035의 비용으로 소개되어 있습니다. 또 다른 사용자는 자신의 이메일 1,500개에 적용한 사례를 공개했습니다. 이는 TypeSafe가 모든 환경에서 보장하는 성능이 아니라 사용자가 자신의 데이터로 실행해 공개한 사례입니다. [oai_citation:15‡Echai](https://echai.ventures/jev?category=Triage+and+classification&utm_source=chatgpt.com)

이 구조를 실제 업무에 적용한다면 다음과 같이 만들 수 있습니다.

메일 수신 → Jev 분류 → 중요도 판단 → 담당 부서 선택 → 자동 처리 또는 사람 검토

7. 실제 공개 사례 ② — 광고 724개 분석

마케팅 영역에서는 더욱 흥미로운 사례가 공개됐습니다.

제작자 공개 측정

724개 광고

37개 브랜드

약 40초

약 $0.09

공개 사례에서는 37개 브랜드의 라이브 광고 724개를 약 40초 동안 분석하고 약 9센트가 사용됐다고 제작자가 공개했습니다.

분석 항목에는 광고의 Hook, Format, Offer, CTA, Awareness Stage, 랜딩 페이지와의 불일치 등이 포함됐습니다. [oai_citation:16‡shipwithjev](https://www.shipwithjev.com/builds/competitor-ad-teardown?utm_source=chatgpt.com)

여기서 중요한 것은 Jev가 광고 문구를 새로 작성한 것이 아니라 수많은 광고를 같은 기준으로 판단하고 구조화하는 역할을 했다는 것입니다.

8. 실제 공개 사례 ③ — AI 논문 1,018개 분류

실제 제작자 공개 측정

1,018개 논문

24개 주제로 분류

Jev 비용 $0.08

논문당 중앙값 256ms

이 사례는 특히 중요합니다. 제작자는 1,018개의 AI 연구 논문을 먼저 DeepSeek V4 Flash로 요약한 뒤, 제목과 요약 그리고 24개의 주제 후보를 Jev에 전달하여 분류했습니다.

공개된 결과는 Jev 분류 비용 $0.08, 논문당 end-to-end latency 중앙값 256ms였습니다. 단, 논문 요약에는 별도의 약 $3.99가 사용됐습니다. 즉 $0.08은 전체 파이프라인 비용이 아니라 Jev 분류 비용입니다. [oai_citation:17‡Made With JEV](https://madewithjev.com/sites?utm_source=chatgpt.com)

여기서 중요한 포인트
"Jev만 사용해서 1,018개 논문을 모두 이해했다"는 사례가 아닙니다.

DeepSeek → 요약
Jev → 24개 주제 분류
Code → 결과 저장 및 시각화

즉 여러 모델을 각각 잘하는 일에 배치한 파이프라인입니다.

9. 실제 공개 사례 ④ — Browser Use + 항공권 검색

Jev가 단순한 데이터 분류를 넘어 Computer Use / Browser Agent의 다음 행동 결정에도 활용될 수 있다는 사례가 공개됐습니다.

공개 데모

취리히 → 런던 항공편 검색

약 7초

Jev 비용 약 $0.0039

공개된 Browser Use 사례에서는 Jev가 브라우저의 상태를 받아 다음 행동과 대상 DOM 요소를 선택하고, 텍스트 입력처럼 필요한 경우에만 작은 LLM이 개입하는 구조가 소개됐습니다. 공개된 저장소 기록에서는 약 7.1초의 실행 시간이 확인됩니다. [oai_citation:18‡Jev News](https://jevainews.com/news/browser-use-jev-flights/?utm_source=chatgpt.com)

브라우저 상태
↓
Jev → 클릭 / 입력 / 선택 / 스크롤 / 대기 / 완료
↓
Browser Agent 실행
↓
새로운 화면 상태
↓
다시 판단

이 방식은 AI Agent에서 상당히 중요한 아이디어입니다. Agent 전체를 하나의 거대한 LLM으로 만드는 대신, 작은 판단을 빠르게 반복하는 구조로 분리할 수 있기 때문입니다.

10. 실제 공개 사례 ⑤ — AI 콘텐츠 필터

공개된 Jev 사례에는 AI-generated 콘텐츠 또는 이른바 AI Slop을 판단하는 콘텐츠 필터 사례도 있습니다.

현재 공개된 Made with Jev 페이지에는 AI Slop Detector가 243ms의 check time, 35개의 판단 항목, $0.00015의 비용으로 표시되어 있습니다. [oai_citation:19‡Made With JEV](https://madewithjev.com/sites?utm_source=chatgpt.com)

다만 이것 역시 특정 공개 데모의 측정값입니다. "Jev가 AI 콘텐츠를 243ms 안에 항상 정확하게 판별한다"는 의미는 아닙니다.

11. 광고·논문·이메일에서 공통으로 보이는 패턴

지금까지의 사례를 보면 분야는 서로 다르지만 공통점이 하나 있습니다.

많은 데이터

↓

반복적인 의미 판단

↓

구조화된 결과

↓

일반 코드가 실행

바로 이 지점이 Jev가 기존 LLM과 다른 방향으로 보이는 이유입니다.

LLM에게 모든 작업을 맡기는 대신, 언어를 이해해야 하지만 결과는 정해진 형태로 받을 수 있는 작업을 별도의 판단 모델로 분리할 수 있습니다.

12. Jev가 모든 문제를 해결하는 것은 아니다

이 부분은 실제 개발에서 매우 중요합니다. Jev가 빠르고 저렴하다는 이유만으로 모든 작업을 Jev에게 맡기는 것은 좋은 설계가 아닙니다.

문제	권장 담당	이유
정확한 계산	Code	AI가 계산할 이유가 없음
DB 조회	Code / SQL	정확한 데이터 조회가 목적
파일 이동	Code	실제 실행은 프로그램이 담당
문의 유형 판단	Jev	의미를 이해해야 하는 분류
긴급도 판단	Jev	언어적 의미와 맥락 판단
복잡한 설명 작성	LLM	자연어 생성이 필요함

TypeSafe 공식 Skill도 명확하게 계산·정확한 조회·규칙·실행은 코드가 담당하고, 의미적 판단이 필요한 부분을 Jev에 맡기는 방식을 설명합니다. [oai_citation:20‡GitHub](https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md?utm_source=chatgpt.com)

13. Confidence를 어떻게 사용해야 할까?

Jev를 기존 분류 모델과 다르게 만드는 또 하나의 요소는 판단 결과와 함께 확률과 confidence를 제공한다는 점입니다. [oai_citation:21‡TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com)

예를 들어 고객 문의를 분류했는데 결과가 다음과 같다고 가정해 보겠습니다.

기술지원 : 0.96

결제문의 : 0.03

기타 : 0.01

애플리케이션은 이 결과를 그대로 사용하지 않고 자신의 데이터와 실제 업무 결과를 이용해 임계값을 정할 수 있습니다.

높은 확률 → 자동 처리

애매한 확률 → 추가 검증

낮은 확률 → Human Review

중요
Confidence가 높다고 해서 애플리케이션 전체의 결정이 항상 옳다는 뜻은 아닙니다. 공식 Skill도 confidence와 probability는 실제 데이터와 업무 결과를 이용해 검증하고 threshold를 정해야 한다고 설명합니다. [oai_citation:22‡GitHub](https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md?utm_source=chatgpt.com)

14. AI Agent에서는 더 재미있어진다

Jev가 특히 흥미로운 영역은 AI Agent Orchestration입니다.

기존 Agent 구조는 모든 판단을 하나의 강력한 LLM에게 맡기는 경우가 많았습니다.

User
↓
Frontier LLM
↓
Tool
↓
Frontier LLM
↓
Tool
↓
Frontier LLM

Jev를 넣으면 일부 판단을 별도의 저지연 모델로 분리할 수 있습니다.

User
↓
Frontier LLM
복잡한 계획·생성
↓
Jev
분류·라우팅·검증·우선순위
↓
Code / Tool
실제 실행

이런 구조에서는 비싼 Frontier Model이 잘해야 하는 문제와 빠르게 반복 처리해야 하는 문제를 분리할 수 있습니다.

실제 공개 사례에서도 "서로 다른 모델을 서로 다른 작업에 배치한다"는 패턴이 반복해서 등장합니다. 1,018개 논문 사례에서도 요약은 DeepSeek가 담당하고 분류는 Jev가 담당했습니다. [oai_citation:23‡Made With JEV](https://madewithjev.com/sites?utm_source=chatgpt.com)

15. Claude Code에서 Jev를 사용할 수 있을까?

여기서는 공식 TypeSafe Skill과 커뮤니티에서 만든 Jev 실행 도구를 구분해야 합니다.

TypeSafe 공식 Agent Skill

TypeSafe가 공식 GitHub 저장소를 통해 Agent Skill을 공개하고 있습니다. 이 Skill의 목적은 TypeSafe의 System One API를 이용해 애플리케이션을 설계하고 구현하는 것을 Coding Agent가 지원하도록 하는 것입니다. [oai_citation:24‡GitHub](https://github.com/typesafe-ai/skills?utm_source=chatgpt.com)

Claude Code에서는 공식 README에 다음 설치 명령이 안내되어 있습니다.

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

skills.sh를 지원하는 다른 Agent에서는 다음 방식도 공식 README에 안내되어 있습니다.

npx skills add typesafe-ai/skills --skill typesafe-ai

설치 후 Claude Code에서는 다음과 같이 Skill을 명시적으로 호출할 수도 있습니다.

/typesafe:typesafe-ai

이 부분은 TypeSafe 공식 GitHub 저장소에서 직접 확인된 내용입니다. [oai_citation:25‡GitHub](https://github.com/typesafe-ai/skills?utm_source=chatgpt.com)

16. 그렇다면 Codex에서는?

여기서는 원문의 내용을 그대로 쓰지 않는 것이 중요합니다.

TypeSafe 공식 Skill 저장소는 skills.sh를 통한 다른 Agent 설치를 지원하지만, "Codex에서 TypeSafe 공식 Skill을 다음 명령으로 설치한다"는 식의 별도 공식 Codex 설치 명령은 현재 확인한 공식 README에서 직접 확인되지 않았습니다. [oai_citation:26‡GitHub](https://github.com/typesafe-ai/skills?utm_source=chatgpt.com)

대신 커뮤니티 프로젝트인 jev-code는 Claude Code, Codex, Pi, OpenCode에 Jev를 MCP 도구로 연결하는 방법을 실제로 제공하고 있습니다. [oai_citation:27‡GitHub](https://github.com/FrancoisChastel/jev-code?utm_source=chatgpt.com)

따라서 다음 두 가지를 구분해서 이해하는 것이 정확합니다.

TypeSafe 공식 Skill

Jev를 애플리케이션에 통합하는 방법을 Coding Agent가 설계하도록 지원

jev-code 커뮤니티 프로젝트

Coding Agent 내부에서 Jev 판단 도구를 직접 호출하도록 MCP/Skill을 제공

`jev-code`는 Codex에 대해 MCP 서버를 등록하고 `$jev` Skill을 사용할 수 있는 방법을 프로젝트 README에서 설명하고 있습니다. 다만 이 프로젝트는 TypeSafe 공식 제품이 아니라 독립적인 커뮤니티 프로젝트라는 점을 반드시 구분해야 합니다. [oai_citation:28‡GitHub](https://github.com/FrancoisChastel/jev-code?utm_source=chatgpt.com)

17. Jev를 실제 프로젝트에 넣는다면?

예를 들어 사내 Groupware 시스템에 AI 자동화를 추가한다고 생각해 보겠습니다.

게시글 / 이메일 / 업무 요청
↓
Jev
유형 / 긴급도 / 담당 부서 / 답변 필요 여부
↓
Application Code
권한 확인 / DB 조회 / Workflow 실행
↓
Frontier LLM
복잡한 답변 생성
↓
Human Review
필요한 경우 최종 확인

이 구조의 장점은 AI가 시스템 전체를 직접 통제하는 것이 아니라 각 AI의 역할을 작게 제한할 수 있다는 것입니다.

특히 기존의 .NET, Java, Node.js 같은 백엔드 시스템에 AI 기능을 추가할 때 "모든 것을 Agent로 다시 만드는 것"보다 이런 방식의 점진적인 도입이 더 자연스러운 경우가 있습니다.

18. 가장 중요한 설계 원칙

AI에게 모든 것을 맡기지 않는다.

LLM → 생성하고 복잡하게 추론한다.

Jev → 좁고 명확한 판단을 한다.

Code → 규칙·계산·DB·API·실제 실행을 담당한다.

Human → 중요한 판단과 예외를 검토한다.

이 구조는 단순히 비용을 줄이는 방법만을 의미하지 않습니다. AI가 어디까지 판단하고 어디부터 프로그램이 통제하는지를 명확하게 만드는 AI 시스템 아키텍처의 변화로 볼 수 있습니다.

19. Jev의 한계도 반드시 알아야 한다

Jev가 새로운 방식의 모델이라는 점과 실제 업무에 바로 사용할 수 있다는 것은 별개의 문제입니다.

TypeSafe 공식 자료 역시 Jev가 모든 문제에 적합하다고 주장하지 않습니다. 오히려 어떤 판단을 분리하고 어떤 방식으로 질문을 구성할 것인지가 중요하다고 설명합니다. [oai_citation:29‡GitHub](https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md?utm_source=chatgpt.com)

• 정확한 숫자 계산은 코드로 처리하는 것이 적합합니다.
• 날짜 계산과 비교도 가능한 경우 코드로 처리하는 것이 좋습니다.
• 생성 작업 자체는 Jev의 목적이 아닙니다.
• 판단 질문은 좁고 명확하게 설계하는 것이 중요합니다.
• 확률 threshold는 자신의 실제 데이터로 검증해야 합니다.
• 공개 Cookbook이나 Demo의 threshold를 그대로 운영 정책으로 사용해서는 안 됩니다.
• 실제 운영에서는 대표적인 정상·예외·경계 사례를 별도로 평가해야 합니다.

특히 중요한 부분
"Typed output"은 출력 형식이 안전하다는 의미이지, 판단 내용 자체가 항상 진실이라는 의미는 아닙니다. TypeSafe 공식 Skill도 실제 대상 도메인에서 성능을 검증할 것을 명시합니다. [oai_citation:30‡GitHub](https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md?utm_source=chatgpt.com)

20. 결국 Jev가 보여주는 것은 무엇일까?

지금까지의 공개 사례를 보면 Jev는 단순히 "빠른 AI 모델 하나가 등장했다" 정도로만 보기에는 흥미로운 부분이 있습니다.

이메일 500개를 분류하고, 광고 724개를 분석하고, 논문 1,018개를 분류하고, 브라우저에서 다음 행동을 결정하는 것처럼 AI가 해야 하는 일을 잘게 분해해서 서로 다른 모델에게 맡기는 구조가 나타나고 있기 때문입니다. [oai_citation:31‡shipwithjev](https://www.shipwithjev.com/builds/competitor-ad-teardown?utm_source=chatgpt.com)

기존의 질문

"어떤 LLM이 가장 똑똑한가?"

새로운 질문

"어떤 AI에게 어떤 판단을 맡길 것인가?"

앞으로 AI Agent를 설계할 때는 모델 하나의 성능만 보는 것이 아니라 LLM + Decision Model + Code + Human Review를 어떻게 조합할 것인지가 중요한 설계 요소가 될 가능성이 있습니다.

21. 한눈에 정리

항목	확인된 내용
제품	TypeSafe의 첫 번째 System One Model, Jev
주요 역할	구조화된 판단, 분류, 라우팅, 점수화, 검증
대표 primitive	Choice / Score / Noul
공식 입력 가격	$0.042 / 1M input tokens
출력 비용	무료
공식 응답시간	70~500ms
공개 논문 사례	1,018개 / $0.08 / 256ms median per paper
공개 이메일 사례	500개 / $0.035
공개 광고 사례	724개 / 약 40초 / 약 $0.09
Browser Use 사례	항공편 검색 약 7초 / Jev 비용 약 $0.0039

※ 가격 및 70~500ms는 TypeSafe 공식 발표 기준입니다. 나머지 공개 사례 수치는 각 제작자가 자신의 실행에서 공개한 측정값입니다. 서로 다른 환경의 수치를 동일한 벤치마크로 해석해서는 안 됩니다. [oai_citation:32‡TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=chatgpt.com)

마무리

Jev를 단순히 "저렴하고 빠른 LLM"이라고 이해하면 핵심을 놓치게 됩니다.

오히려 중요한 것은 AI의 판단을 하나의 독립적인 프로그래밍 primitive처럼 사용할 수 있도록 만들었다는 점입니다.

LLM은 글을 쓰고, Jev는 판단하고, Code는 실행하고, Human은 중요한 결정을 검토합니다.

LLM → Generate

Jev → Decide

Code → Execute

Human → Review

결국 앞으로의 AI Agent 개발에서 중요한 질문은 "가장 강력한 모델 하나를 어떻게 사용할까?"에서 "각 문제에 가장 적합한 AI를 어떻게 조합할까?"로 이동할 가능성이 있습니다.

출처

TypeSafe AI 공식 홈페이지
https://typesafe.ai/

TypeSafe 공식 발표 — Introducing System One Models & Jev
https://typesafe.ai/blog/introducing-system-one-models-and-jev

TypeSafe 공식 Agent Skills GitHub
https://github.com/typesafe-ai/skills

Made with Jev — 공개 제작 사례
https://madewithjev.com/

Jev 광고 분석 공개 사례
https://www.shipwithjev.com/builds/competitor-ad-teardown

jev-code — 커뮤니티 Coding Agent 통합
https://github.com/FrancoisChastel/jev-code

업데이트 및 면책
이 글은 2026년 9월 23일 기준으로 공개된 자료를 확인하여 작성했습니다. TypeSafe의 가격, 모델, API, 서비스 상태, Agent Skill 및 커뮤니티 프로젝트는 이후 변경될 수 있습니다. 공개 제작자의 비용·속도 수치는 각자의 실행 환경에서 얻은 결과이므로 공식 성능 보증이나 일반적인 벤치마크로 해석해서는 안 됩니다.

#Jev #TypeSafe #SystemOne #AIAgent #AIOrchestration #ClaudeCode #Codex #DecisionModel