AI가 선택하도록 만드는 법: Jev에서 얻은 Agent Skill 아이디어 5가지

여러분은 열 개의 제목 초안을 가지고 있습니다. 그중 어떤 것을 선택해야 할까요? 수십 개의 Skill을 설치했는데, 다음 요청에는 어떤 Skill이 적합할까요? 게임 속 경비가 의심스러운 사람을 발견했습니다. 계속 순찰을 해야 할까요, 질문을 던져야 할까요, 아니면 경보를 울려야 할까요?

각 작업의 결과는 선택지 하나일 수 있지만, 그 선택을 내리기 위해서는 상황을 정확히 이해해야 합니다.

2026년 9월 15일 TypeSafe에서 얼리 액세스로 출시된 Jev는 이러한 결정을 위해 설계되었습니다. Jev는 텍스트 또는 구조화된 상태를 입력으로 받아, 미리 정의된 질문 유형에 따라 선택지나 점수와 함께 확률 정보를 반환합니다. 개발자는 이 결과를 바탕으로 소프트웨어가 다음에 수행할 작업을 결정할 수 있습니다. TypeSafe 소개

Jev는 현재 텍스트 입력만 지원합니다. 이미지, 오디오, 비디오는 평가를 위해 먼저 텍스트 설명이나 구조화된 필드로 변환해야 합니다. 입력 요구사항

Agent와 Skill을 활용하는 OOMOL 독자들에게는 다음과 같은 유용한 접근법이 제안됩니다: 워크플로우에서 반복되는 판단을 식별하고, 그 기준을 정의한 뒤, 해당 결정과 후속 단계를 재사용 가능한 Skill로 패키징하세요.

OOMOL은 이제 Jev를 지원하는 Cloudflare Workers AI Provider를 제공합니다. 연결만 하면 Agent 워크플로우에서 Jev를 호출하여 아래의 아이디어들을 실제 작업에 적용하기 시작할 수 있습니다.

Jev 작동 방식: 의미론적 판단을 소프트웨어가 활용할 수 있는 결과로 변환

Jev는 구조화된 의사결정을 위해 설계되었습니다. TypeSafe는 이러한 모델 계열을 System One 모델이라고 부릅니다. 요청에는 평가할 자료와 맥락을 담은 state와 질문, 답변 유형, 평가 기준을 정의한 questions가 포함됩니다. 모델은 코드가 분기, 순위 매기기, 라우팅 등에 사용할 수 있는 타입이 지정된 결과를 반환합니다. 기술 개요

기본적인 질문 유형은 세 가지입니다:

유형	목적	출력
Choice	메시지 카테고리와 같이 미리 정의된 옵션 중 하나를 선택	선택된 옵션, 확률 분포, 신뢰도
Score	미리 정의된 순서 있는 등급에 따라 정도를 평가	점수, 등급에 대한 분포, 신뢰도; 점수는 등급 사이의 값이 될 수 있음
Noul	특정 진술이 참인지 여부를 판단	“예”의 확률(0~1), 별도의 신뢰도 필드 없음

한 요청 내의 질문들은 동일한 상태를 기반으로 서로 독립적으로, 동시에 평가됩니다. 각 질문은 다른 질문의 답변을 알지 못합니다. 이후 판단에서 이전 결과가 필요하면 코드가 추가 요청을 해야 합니다. 질문 유형 및 구성

생성형 언어 모델은 일반적으로 한 번에 하나의 토큰씩 답변을 생성합니다. TypeSafe는 Jev가 제한된 출력을 위해 병렬 샘플링을 사용하며, 자유 형식의 텍스트 답변을 생성하지 않고 결정과 확률을 반환한다고 설명합니다. Jev의 학습 방식은 RLCD: 보정된 결정을 위한 강화학습으로, 예측된 확률을 관측 빈도와 일치시키는 것을 목표로 합니다. 모델 설계 · RLCD 설명

잘 보정된 모델의 경우, 80% 확률로 예측된 사건은 여러 비교 가능한 예측에서 약 80%의 빈도로 발생해야 합니다. 이는 통계적 목표이며, 개별 답변에 대한 보장은 아닙니다. Choice와 Score 답변의 confidence 필드는 확률 분포가 얼마나 집중되어 있는지를 요약한 것이며, 단순히 선택된 답변이 맞을 확률을 나타내는 것은 아닙니다. 코드는 여전히 실제 사례를 기반으로 검증된 규칙을 사용해 언제 조치를 취할지, 추가 정보를 요청할지, 혹은 인간의 검토를 요청할지 결정합니다. 확률과 신뢰도

간단한 예제: 고객 메시지 라우팅

온라인 스토어에 다음과 같은 메시지가 들어왔다고 가정해 보겠습니다:

오늘 램프가 도착했는데, 갓에 금이 가 있네요. 교체품을 보내주세요.

개발자가 해당 메시지를 state로 제공하고 세 가지 질문을 정의했습니다. 아래 결과는 실제 모델 호출 결과가 아닌, 예시를 위해 작성된 것입니다:

미리 정의된 질문	예시 결과	코드가 이를 어떻게 활용하는가
Choice: 이 메시지는 교체 요청인가, 배송 문의인가, 판매 전 문의인가, 아니면 기타인가?	교체 92%, 배송 3%, 판매 전 1%, 기타 4%; “교체” 선택	애플리케이션 규칙에 따라 교체 지원 대기열로 라우팅
Noul: 고객이 명시적으로 교체를 요청하고 있는가?	0.98, 즉 “예”일 확률이 약 98%	티켓에 명시적 교체 요청 태그 추가
Score: 어조는 차분한가, 다소 불만족스러운가, 아니면 매우 불만족스러운가?	“다소 불만족스러움”에 가까운 점수	지원 담당자에게 추가 검토 신호 제공

이를 마치 분류표처럼 생각해 보세요: 사람이 질문과 옵션을 정의하고, Jev가 메시지를 평가하며, 코드가 어디로 보낼지 결정합니다. 만약 메시지가 모호하고 확률이 여러 옵션에 걸쳐 분산되어 있다면, 애플리케이션은 이를 검토하도록 보낼 수도 있습니다.

여기서 98%는 고객이 명확히 교체를 요청했다는 판단이 맞을 확률을 뜻합니다. 고객이 “98% 불만족한다”는 의미가 아닙니다. 모델이 교환을 완료한 것도 아닙니다. 주문과 정책 확인, 답변 작성, 실제 교환 처리는 다른 도구나 생성 모델, 고객 지원 담당자가 이어서 수행해야 합니다.

생성, 평가, 실행의 역할 나누기

기사 제목을 고르는 워크플로우를 예로 들어 보겠습니다.

• 생성 모델이 원본 자료를 바탕으로 제목 후보 열 개를 작성합니다.
• Jev가 명확성, 구체성, 주장의 근거 여부 등 정해진 기준으로 평가합니다.
• 코드가 결과를 집계하고 제목 후보와 점수를 작성자에게 보여줍니다.

생성 모델은 후보를 제안하고, Jev는 의미를 판단하며, 코드는 계산과 실행을 맡습니다. Skill은 필요한 입력, 도구 호출 방법, 불확실한 결과의 처리 방식, 최종 산출물까지 전체 절차를 설명합니다.

이렇게 역할을 나누면 문제를 찾기도 쉬워집니다. 제목이 좋지 않으면 생성 지시를 살펴보고, 순위가 부적절하면 평가 기준을 점검합니다. 합계가 틀렸다면 집계 코드를 확인하면 됩니다.

커뮤니티에서는 이미 여러 흥미로운 실험이 나왔습니다. 아래 다섯 가지 사례에는 SKILL.md 파일이 있는 도구뿐 아니라 애플리케이션과 라이브러리도 포함됩니다. 애플리케이션 사례를 Agent가 Skill로 사용하려면 별도의 연동 작업이 필요합니다.

1. 음악 제작: 모델이 매개변수를 고르고 프로그램이 음표를 생성하기

Jev Playground는 음악 제작을 분위기, 구조, 조성, 박자, 빠르기, 악기 구성, 악구 등 미리 정의한 선택지로 나눕니다. Jev가 매개변수를 선택하면 프로그램이 이를 음표, 악보, 재생 결과로 변환합니다. MIDI 내보내기도 지원합니다.

Skill 개발자는 이 구조를 참고할 수 있습니다. 사용자가 “밤에 책을 읽을 때 들을 배경 음악”처럼 용도를 설명하면, 워크플로우가 이를 매개변수 선택으로 바꾸고 기존 음악 프로그램을 호출해 악보와 MIDI 파일을 제공하도록 구성하는 것입니다.

이는 “음악 기획 Skill”로 확장할 수 있는 아이디어입니다. 선택지가 명확하므로 분위기 설정으로 음악의 느낌을 바꾸거나 빠르기와 박자로 리듬을 조절할 수 있습니다.

프로젝트에는 휴리스틱을 사용하며 API 키가 필요 없는 오프라인 모드도 있습니다. 체험할 때는 오프라인 결과와 실제 Jev 호출을 구분해야 합니다. 음악이 재생된다는 사실만으로 모델이 참여했다고 볼 수는 없습니다.

2. 게임 NPC: 경비원의 판단 과정을 관찰하기

HEIST//ONE은 박물관을 배경으로 한 잠입 게임입니다. 변장, 신분증, 조명, 소음이 경비원의 판단에 영향을 줍니다. Jev는 위협, 의심 정도, 전술적 의도, 주시 대상을 평가하고, 코드는 물리 연산, 경로 탐색, 게임 규칙상 허용되는 행동, 승리 조건을 처리합니다.

화면에서는 경비원에게 제공된 근거, 모델의 확률, 최종적으로 실행된 행동을 확인할 수 있습니다.

경비원이 갑자기 추격을 시작하면 개발자는 경비원이 무엇을 보았는지, 어떤 판단이 달라졌는지, 프로그램이 그 판단을 행동으로 어떻게 바꿨는지 살펴볼 수 있습니다.

이를 재사용 가능한 NPC 의사결정 흐름으로 만들 수도 있습니다. 캐릭터가 감지할 수 있는 주변 상태를 입력받아 미리 정한 행동 중 하나를 선택하고, 게임 엔진이 검증 후 실행하는 방식입니다. 가능한 행동과 실행 규칙은 개발자가 정의합니다.

기본값은 API 키가 필요 없는 스크립트 모드이며, 실제 모델을 호출하려면 Jev를 활성화해야 합니다. 작성자는 모델을 이용한 실행 기록을 공개했지만, 한 번의 실행으로 다양한 상황에서의 안정성을 입증할 수는 없습니다.

3. 아이디어 평가: 모든 제안에 같은 질문 적용하기

Kill My Idea는 창업 아이디어 평가를 작은 애플리케이션으로 구현했습니다. Jev에 여덟 가지 평가 항목, 아이디어의 분류, 표현의 명확성에 관한 총 열 가지 질문을 보냅니다. 이후 코드가 점수에 가중치를 적용해 KILL(포기), FIX(수정), SHIP(출시)을 제안합니다.

수익 창출, 오픈소스 개발, 재미 중 어떤 목표를 추구하느냐에 따라 평가의 비중을 조정할 수 있습니다.

여기서 “아이디어 비교 Skill”을 생각해 볼 수 있습니다. 여러 제안을 동일한 항목으로 평가하고 차이를 나란히 보여주는 것입니다. 무엇이 명확하게 설명되어 있는지, 어떤 제안이 검증되지 않은 가정에 의존하는지, 무엇부터 작은 실험으로 확인할지 파악하는 데 도움이 될 수 있습니다.

일관된 기준은 비교를 쉽게 해줍니다. 다만 실제 사용자에게 필요하고 사용하거나 비용을 지불할 의향이 있는지는 별도로 확인해야 합니다. 프로젝트 문서에 따르면 완료된 평가는 기본적으로 서버에 보관되며, 입력 양식에서 보관 제외를 선택할 수 있습니다.

4. Skill 선택: “Skill이 필요 없음”도 결과로 남기기

Skill이 늘어날수록 적절한 Skill을 선택하는 일이 중요해집니다.

Jev Agent Skill Router는 사용자 요청과 Skill 목록을 받아 특정 Skill 선택, Skill 불필요, 추가 검토 중 하나를 반환합니다. 이 프로젝트는 선택을 담당하며, 선택한 Skill을 불러오고 실행하는 일은 다른 프로그램이 맡아야 합니다.

많은 Skill을 관리할 때 이 구분은 유용합니다. 선택기는 관련성뿐 아니라 각 작업의 범위도 고려해야 합니다. 개념을 묻는 질문에는 전용 Skill이 필요 없을 수 있고, 여러 Skill이 적합해 보이면 추가 확인이 필요할 수 있습니다. Skill을 사용하지 않는다는 판단이 이후의 도구 사용까지 배제하는 것은 아닙니다.

요청, 후보, 선택 결과, 불확실성을 보여주는 화면이 있다면 설명이 겹치거나 역할이 불명확하거나 실행 조건이 너무 넓은 Skill을 찾는 데 도움이 될 것입니다.

OOMOL처럼 Apps와 Skills를 함께 사용하는 환경에서 탐색해 볼 만한 방향입니다. 커뮤니티 프로젝트는 아이디어를 제공하며, 완전한 선택 기능을 연동하려면 개발과 검증이 필요합니다.

5. 로그 선별: 심층 분석이 필요한 항목 고르기

Jev Logs는 로그에 진단 가치, 우선순위, 전달 경로에 관한 판단을 추가합니다. 원본 로그를 보관하면서 더 큰 모델로 분석할 로그를 고르는 데 도움을 줍니다. npm 패키지와 SKILL.md 파일을 제공하며, 선별과 라우팅을 담당합니다. 근본 원인 분석은 후속 워크플로우에서 수행합니다.

반복적인 초기 선별 작업에 적합한 방식입니다. 먼저 주의가 필요한 내용을 식별한 뒤 심층 분석을 수행할 모델을 호출합니다.

검토할 근거를 남기는 것이 중요합니다. 건너뛴 로그도 보관해야 유용한 정보를 놓쳤는지 확인할 수 있습니다. 비용 절감 효과는 실제 로그 분포, 선별 오류, 후속 모델 호출 방식에 따라 달라집니다.

제목 평가 Skill부터 시작하기

그림 1: 생성, 평가, 검토는 서로 다른 역할을 맡습니다. 개념을 설명하는 그림이며, 제품 화면이나 실측 결과가 아닙니다.

이 아이디어를 실제로 적용하려면 제목 평가처럼 범위가 명확하고 결과를 확인하기 쉬운 작업부터 시작하는 것이 좋습니다.

다음과 같이 작업을 정의할 수 있습니다.

원본 자료를 바탕으로 제목 후보 열 개의 명확성과 구체성을 평가하고, 자료로 뒷받침되지 않는 약속이 포함되어 있는지 판단해 주세요. 개별 판단을 유지하고 사람이 검토할 후보를 표시해 주세요. 최종 선택은 작성자가 합니다.

워크플로우의 조건도 명확히 정해 둡니다.

항목	제목 평가 예시
입력	원본 자료, 대상 독자, 제목 후보
평가 기준	주제가 명확한가? 표현이 구체적인가? 약속에 자료상의 근거가 있는가?
결과 활용	각 항목의 판단을 유지하면서 비교와 검토 지원
예외 처리	근거가 부족하거나 판단이 불확실하면 작성자에게 검토 요청
검증	좋은 제목, 나쁜 제목, 모호한 제목을 포함한 실제 사례로 확인

작은 흐름부터 완성한 뒤 처리량과 도구를 늘리세요. TypeSafe는 Jev가 현재 영어에서 가장 좋은 성능을 보인다고 설명합니다. 중국어를 비롯한 다른 언어에서는 자신이 사용할 실제 예시로 검증해야 합니다. 모델 및 언어 지원

OOMOL에서 Provider를 연결해 Jev 사용하기

OOMOL은 Jev를 지원하는 Cloudflare Workers AI Provider를 제공합니다. 연결 후 모델을 사용할 수 있습니다. TypeSafe가 Jev를 개발하고, Cloudflare가 모델 접근 경로를 제공하며, OOMOL은 이를 Agent의 도구 사용 흐름에 연결합니다. Cloudflare의 모델 목록에도 Jev가 등록되어 있습니다.

앞서 설명한 제목 평가부터 시작해 보세요.

1. OOMOL 콘솔에서 Cloudflare Workers AI Provider 연결을 설정합니다.
2. 원본 자료와 제목 후보를 준비하고, Agent에 비교할 항목과 Jev 호출 요구를 명확히 전달합니다.
3. 반환된 판단을 확인하고 수정이나 추가 검토가 필요한 후보를 골라 다음 단계를 결정합니다.

연결이 완료되면 다음과 같이 요청할 수 있습니다.

연결된 Cloudflare Workers AI Provider로 Jev를 호출해 아래 제목 열 개를 평가해 주세요. 원본 자료를 바탕으로 명확성, 구체성, 근거 없는 약속의 포함 여부를 판단해 주세요. 각 판단을 유지하면서 비교표로 정리하고, 제가 따로 검토할 제목을 목록으로 보여주세요.

Agent는 작업을 Jev가 지원하는 질문으로 바꾸고, 반환된 결과를 표와 설명으로 정리합니다. Jev는 이 과정에서 판단을 맡습니다.

흐름이 작동하면 입력 요건, 평가 기준, 도구 호출, 검토 규칙을 제목 평가 Skill로 저장하세요. 다음 자료에도 같은 절차를 재사용할 수 있습니다. 제안 비교, 콘텐츠 분류, 로그 선별도 시작하기 좋은 작업입니다.

Provider는 모델 호출 경로를 제공하고, Skill은 작업을 완료하는 방법을 저장합니다. 이 글의 음악, 게임, 라우팅 프로젝트는 설계 참고 사례입니다. 전체 동작을 구현하려면 해당 애플리케이션 코드와 실행 로직을 연동해야 합니다.

판단 질문을 설계하는 방법은 TypeSafe 공식 Skill을 참고하세요. 다른 MCP 연동 방식을 검토한다면 커뮤니티의 jev-mcp 프로젝트도 살펴볼 수 있습니다.

좋은 판단에는 명확한 질문과 확인 가능한 결과가 필요합니다

Jev는 분류, 평가, 선택을 프로그램에 포함하기 쉽게 만듭니다. 후보와 평가 기준, 잘못 선택했을 때의 처리 방식은 여전히 개발자가 정의해야 합니다.

TypeSafe는 개수 세기, 수학, 날짜 비교, 복잡한 간접 추론 등의 한계를 공개하고 있습니다. 명확한 계산은 코드가 맡고, 출력 형식이 올바르더라도 판단 내용은 확인해야 합니다. 알려진 모델의 한계

이 프로젝트들에서 얻을 수 있는 개발 방향은 구체적입니다. 반복되는 판단을 찾고, 충분한 맥락을 제공하고, 검증 가능한 기준을 정의한 뒤 결과를 다음 행동에 연결하세요.

제목 하나를 고르거나, Skill을 선택하거나, 로그의 심층 분석 여부를 결정하는 작은 작업부터 시작할 수 있습니다. 입력, 판단, 실행, 검토를 연결하면 반복해서 사용할 수 있는 기능이 됩니다.

Leina Agent와 채팅하며 시작하기

Agent가 할 수 있는 일을 경험하려면 **Leina Agent**부터 시작해 보세요. Agent를 만들고 실행해 대화하거나 GPT 같은 대화형 모델을 사용해 본 뒤, 작업에 필요한 도구를 추가할 수 있습니다. 선택 가능한 모델은 Leina의 현재 설정 옵션에 따라 달라집니다.

Leina는 Discord, Slack, Microsoft Teams, WeChat, Feishu, DingTalk 등 익숙한 메신저를 지원합니다. 원하는 채널을 연결한 뒤 휴대폰이나 컴퓨터에서 평소 쓰던 메신저로 작업을 요청할 수 있습니다. 직접 게이트웨이를 배포하거나 API 호출 코드를 작성할 필요는 없습니다.

다음 세 단계로 시작하세요.

1. Agent 만들기: leina.ai의 시작 안내를 따라 자신의 Leina Agent를 만들고 실행합니다.
2. 메신저 연결하기: 선택한 플랫폼의 설정 안내에 따라 연결한 뒤 휴대폰이나 컴퓨터에서 첫 메시지를 보냅니다.
3. 작은 작업 시도하기: 개념 설명, 전달한 글 정리, 제목 초안 작성부터 요청합니다. 다른 앱에 접근해야 한다면 필요한 Connector를 추가하고 권한을 부여합니다.

예를 들어 다음 요청을 보낼 수 있습니다.

일상적인 예로 Jev를 설명한 다음, 아래 자료를 바탕으로 제목 다섯 개를 작성해 주세요.

작업에 맞춰 Agent에 필요한 Connector를 설정하세요. 앱 연결을 통해 Agent는 허용된 권한 범위 안에서 다른 서비스에 접근하고, 채팅으로 받은 요청을 실제 작업으로 이어갈 수 있습니다. 필요에 따라 Connector를 선택하고 검증된 절차를 Skill로 저장해 재사용할 수도 있습니다.

이 글의 Jev 평가 흐름을 체험하려면 Agent에 Jev를 지원하는 Cloudflare Workers AI Provider 연결을 설정한 뒤 앞서 제시한 제목 평가 요청을 보내세요. 일반 대화와 제목 생성은 대화 모델이 담당하며, Jev를 실제로 호출하면 분류, 점수 평가, 선택 기능을 경험할 수 있습니다.

**Leina에서 Agent 만들기**로 이동해 메시지 하나부터 시작하세요. 이미 Agent를 사용 중이라면 OOMOL 콘솔에서 Provider를 연결해 기존 환경을 유지할 수도 있습니다.

---

자료 및 범위: 이 글은 2026년 9월 18일 조사 자료를 바탕으로 하며 TypeSafe의 소개, 모델 문서, 한계를 별도로 확인했습니다. 커뮤니티 프로젝트 설명은 조사 당시 확인한 작성자 문서에 근거합니다. 이 글을 위해 데모나 성능을 독립적으로 시험하지는 않았습니다. Provider 제공 여부와 Leina 시작 방법 및 채널 지원은 제품팀의 설명과 Leina 웹사이트를 참고했습니다. 이 글은 해당 Provider의 실제 호출 시험 결과를 제시하지 않습니다. 커뮤니티 애플리케이션과 제안된 Skill 확장은 OOMOL이 출시한 완성형 애플리케이션과 구분됩니다.