소프트웨어의 실질적인 작업을 줄이는 Jev 활용 사례 7가지

누군가 우리 웹사이트에 연동이 몇 개인지 물었어요. 사이트는 가입 양식에 필드를 몇 개 넣어야 하는지 조언했어요.

답은 빨리 왔습니다. 하지만 쓸모가 없었어요.

두 질문 모두 ‘몇 개’라는 표현이 들어 있었어요. 검색 코드는 허용된 FAQ 일치에 최소 점수 0.86을 부여해 약한 일치를 그럴듯하게 보이게 했습니다. 속도가 잘못된 판단을 가렸어요.

Ship with Jev를 볼 때 생각할 만한 실패입니다. 2026년 9월 26일 기준으로 이 목록에는 커뮤니티 제작물 551개가 실려 있었어요. 게임 옆에 검색 구성 요소, 브라우저 에이전트, 조사 도구, 라우팅 실험이 있습니다. 목록의 성능 수치는 각 제작자가 제공한 것으로, 독립적인 벤치마크가 아니라 작품을 찾는 도구예요.

관심을 가져야 할 질문은 어떤 패턴이 실제 제품의 작업을 줄이는가입니다.

연동과 비즈니스 소프트웨어를 만드는 팀이라면 저는 다음 7가지를 먼저 평가하겠어요. 순서는 유용성과 검증 가능성에 대한 편집상의 판단입니다. 아래 워크플로 사례는 연결된 구현을 명시한 경우를 제외하면 제안하는 설계예요.

Jev가 애플리케이션에 더하는 것

TypeSafe는 Jev를 타입이 정해진 판단을 내리는 모델로 설명해요. 관련 상태와 질문을 주면 코드가 사용할 수 있는 선택, 확률, 점수를 돌려줍니다. 활용 사례 지도에는 라우팅, 검색, 검증, 추출이 포함됩니다.

이 구분의 선행 아이디어는 우리가 수집한 YouTube 자료에서도 찾을 수 있어요. AI Engineer에서 Diogo Almeida가 한 발표에서 TypeSafe 공동 창업자는 소프트웨어의 기본 구성 요소가 더 많은 지능을 표현할 수 있어야 한다고 주장합니다. 기존 소프트웨어에 보조 도구를 붙이는 방식과 비교했어요. 이것은 AI의 방향에 관한 그의 주장이지, Jev의 현재 성능을 측정한 벤치마크가 아닙니다.

철도 분기점을 생각해 보세요. 필요한 결과는 열차가 갈 수 있는 선로 중 어느 쪽으로 가야 하는지입니다. 선로를 설명하는 문단은 전환기에 아무 도움이 되지 않아요.

‘일반 LLM도 JSON을 반환할 수 있다’는 반론은 타당해요. 맞습니다. 다른 구성 요소를 쓸 이유는 그 판단에서 측정한 품질, 비용, 지연 시간에 달려 있어요. 타입이 정해진 응답만으로는 어느 것도 증명하지 못합니다.

CLM의 도전을 먼저 살펴봐야 합니다

9월 23일 Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré, Azalia Mirhoseini가 Contrastive Language Models를 발표했어요. 이 연구는 빠른 의미 판단을 실용적으로 구현할 유일한 길이 Jev라는 가정에 도전합니다.

저자들은 컴퓨터 사용, 게임, 도구 호출 작업에서 예시 없이 평가한 결과가 Jev와 비슷하면서 지연 시간은 최대 9배 낮다고 보고했어요. 별도로 보류해 둔 DeepSWE 작업 38개에서 81.6%, Terminal-Bench 2.1 작업 30개에서 87.6%를 보고했습니다. 이 코딩 결과는 다른 모델이 생성한 해법 중에서 고르도록 미세 조정한 CLM 검증기를 사용한 것이에요. 같은 검증기 설정에서 Jev가 무작위 선택 기준보다 낮았다고도 보고했습니다. 지연 시간은 H100에서 측정했어요. 모두 저자들의 결과이며 우리는 독립적으로 재현하지 않았습니다. 원래 평가와 방법론을 참고하세요.

이 비교는 무엇을 시험해야 하는지 바꿔요. 지원 대기열 선택, 검색 문단 선택, 긴 코딩 과정 평가는 서로 다른 작업입니다. 하나에서 좋은 결과가 나왔다고 나머지의 결론을 낼 수 없어요.

CLM은 상태와 후보 동작을 따로 인코딩하므로 재사용 가능한 동작 임베딩을 캐시할 수 있어요. 저장소에는 TypeSafe 호환 인터페이스와 기본 2,048토큰 상태 제한이 문서화되어 있습니다. 설정을 바꾸지 않으면 더 긴 상태는 잘립니다. API 경계에서 호환된다는 사실이 같은 판단을 내린다는 증거는 아니에요.

공개된 모델 카드는 Qwen3-8B 임베딩을 명시하고 강한 검증 성능에는 미세 조정한 헤드가 필요하다고 경고해요. CLM이 주어진 후보를 평가할 뿐 해법을 새로 생성하지 않는다고도 밝힙니다. 공개 가중치는 평가 선택지를 제공하지만, 하드웨어와 서비스 운영, 유지 관리에는 여전히 비용이 듭니다.

Tajo에 적용할 교훈은 구체적이에요. 같은 사례에서 판단 모델을 비교하고, 첫 실행과 반복 실행의 지연 시간을 따로 기록하고, 그럴듯하지만 틀린 후보를 시험합니다. 모델과 인코더 또는 프로젝션 헤드의 버전을 고정하세요. 지원하지 않는 제공자 설정을 조용히 다른 제공자로 대체하지 말고 거부하세요. 모델이나 후보 집합이 바뀌면 신뢰도 보정을 다시 확인합니다.

아래 7개 워크플로는 여전히 평가할 만해요. Jev가 모든 비교에서 이겨야만 가치가 있는 것은 아닙니다.

1. 결과가 질문에 답하는지 확인하는 검색

실패가 눈에 보이고 결과에 정답 표시를 하기 쉬워서 저는 이를 첫 번째로 고르겠어요. 반환된 문단이 방문자의 질문에 답했나요?

키워드 검색, 임베딩 또는 둘 모두로 작은 후보 집합을 찾으세요. 그다음 각 문단이 요청한 사실을 제공하는지 Jev에 물어요. TypeSafe의 재정렬 가이드는 이 두 단계 구조를 보여줍니다. 한계도 드러나요. 처음 검색에서 빠진 문서는 재정렬기가 선택할 수 없습니다.

1. 검색

   키워드, 임베딩

   작은 후보 집합

   놓친 문서는 추가할 수 없음
2. Jev

   타입이 정해진 판단

   이 문단이

   사실을 제공하는가?
3. 답

   또는 답 없음

   정확한 답 또는 미응답

   전체 지연 시간 측정

연동 개수 사례에서는 최단 경로가 더 간단해요. 공식 카탈로그의 항목을 세고 그 수의 의미를 밝힙니다. 문서화된 커넥터와 고객이 설정한 연결은 서로 달라요.

의미 해석이 필요한 질문에 의미 판단을 남겨 두세요. 예를 들어 ‘어제부터 변경된 고객만 옮길 수 있나요?’ 같은 질문입니다. 관련 동기화 문서를 찾은 뒤 증분 업데이트에 답하는지 확인해요.

Kyle McLaren의 jevsearch 구현은 순서를 구체적으로 보여줘요. 키워드 결과가 먼저 나오고 Jev의 순위가 뒤따릅니다. 공개 벤치마크는 자체 문서 모음과 정답이 표시된 질문을 사용해요. 이는 그 테스트에 관한 유용한 근거이지 다른 웹사이트나 언어에서의 성능 약속은 아닙니다.

정답, 근거 없는 답, 답하지 못한 질문, 전체 지연 시간을 측정하세요. 오타와 번역된 질문도 포함하세요. 무관한 결과는 빨라도 여전히 무관합니다.

2. 요청을 알맞은 페이지, 대기열, 에이전트로 보내기

사용자가 ‘계정을 바꾼 뒤 연락처가 들어오지 않아요’라고 썼다고 해요. 애플리케이션은 연결 문제 해결, 청구, 필드 매핑, 새 동기화 생성 요청을 구분해야 합니다.

현재 화면, 최근 대화, 그 사용자에게 허용된 목적지를 제공하세요. 명시적인 ‘일치 없음’ 선택지와 함께 최적 목적지를 물어요. 목적지 식별자는 애플리케이션에서 관리합니다.

의도, 목적지, 긴급도, 메시지에 실행 가능한 요청이 있는지 등 여러 판단이 함께 유용할 수 있어요. TypeSafe의 fan-out 패턴은 독립적인 질문들이 하나의 요청을 공유하게 해 줍니다. 이후 코드는 관련 답을 사용합니다.

무해한 화면 이동 제안과 실제 작업의 실행 허가는 별개의 판단이에요. 올바른 청구 페이지를 찾았다고 환불이 허가되는 것은 아니에요. 적절한 에이전트를 찾았다고 자격 증명이 부여되는 것도 아닙니다.

실용적 이점은 담당자 간 전달과 재질문이 줄어드는 것이에요. 사용자가 첫 시도에 정확한 목적지에 도달한 비율을 측정하세요. ‘예’, ‘새 작업’, ‘그건 끝났나요?’ 같은 후속 발화를 재평가 사례에 넣으세요. 이런 말은 문맥이 있어야 의미가 통합니다.

3. 지저분한 데이터를 신뢰할 수 있는 연동으로 바꾸기

다음은 제안하는 연동 워크플로예요. 원본 내보내기에는 customer_email, billing_email, account_owner_email이 있습니다. 대상 시스템은 연락처의 이메일 주소를 기대해요.

문자열 유사도만으로는 실질적인 모호성이 남아요. 필드 설명, 예시 값, 비즈니스 목적이 이를 해결하는 데 도움이 됩니다. Jev는 실제 원본 필드 중 하나를 고르고 코드는 유형, 필수 값, 대상의 제약을 확인할 수 있어요.

관련된 사전 파싱 값 추출 가이드는 특히 유용한 설계를 씁니다. 코드가 후보 값을 찾고 모델이 하나를 선택하면 코드가 원래 값을 복사해요. 새 주소나 금액을 만들어 내지 않는 방식입니다.

1. 코드

   후보 찾기

   customer_email

   billing_email

   account_owner_email
2. Jev

   하나 선택

   필드 설명

   예시 값, 목적
3. 코드

   원래 값 복사

   유형, 필수 값

   대상의 제약

CRM과 이메일 연동에서는 원본 필드와 매핑 결정을 함께 보존하세요. 영향을 받는 레코드를 미리 보여주고, 불확실한 매핑은 검토 전까지 결정하지 마세요.

경제적 이점도 있어요. 승인한 스키마 매핑은 재사용할 수 있습니다. 필드의 의미가 같다면 모든 행마다 모델을 호출할 필요는 없어요.

검토한 표본과 비교해 거부된 레코드와 잘못된 매핑을 측정하세요. API 요청 성공은 데이터가 수락되었다는 뜻일 뿐, 올바른 이메일이 올바른 연락처에 들어갔다는 증거는 아닙니다.

4. 작업을 마치는 가장 작은 모델 고르기

애플리케이션이 모든 작업을 가장 비싼 모델로 보낸다면 모델 라우팅이 매력적이에요. 레이블 변경, 검색 판단, 어려운 아키텍처 조사는 요구 사항이 서로 다릅니다.

먼저 설정되어 있고 작업 데이터를 받아도 되는 모델을 정하세요. 지원 도구와 관찰한 성능을 기록합니다. 그러면 범위를 좁힌 판단이 그 집합에서 적합한 모델을 추천할 수 있어요. TypeSafe의 모델 라우팅 사례에 이 패턴이 있습니다.

OpenRouter의 Jev Router는 채팅 API에서 모델 ID typesafe/jev-router로 이 패턴을 제공해요. 목록에는 대화가 바뀌면서 모델과 추론 수준을 모두 선택한다고 적혀 있습니다. 채택하기 전에 허용되는 후속 모델, 실제 요금, 데이터 처리, 도구 호출 중 동작을 평가하세요. 목록은 확인했지만 이 라우터를 벤치마크하지는 않았습니다.

우리가 제안하는 정책은 정확한 규칙과 사실에 일반 코드를 먼저 사용해요. 범위가 정해진 의미 질문에는 판단 모델, 글쓰기나 구현에는 적합한 생성 모델, 근거가 있을 때는 상위 모델로의 전환을 사용합니다.

작업에 무엇이 필요한가?

1. 정확한 규칙과 사실

   일반 코드

2. 범위가 정해진 의미 질문

   판단 모델

3. 글쓰기 또는 구현

   적합한 생성 모델

4. 근거가 더 요구할 때

   상위로 전환

라우터 자체에도 시간과 비용이 들어요. 명백하고 반복 가능한 작업에는 고정 규칙이 더 나을 수 있습니다. 애매한 작업에서는 완료된 결과를 놓고 고정 모델을 쓴 기준과 라우팅을 비교하세요.

수용된 결과당 비용, 재시도, 상위 모델 전환율, 나중에 발견된 실패를 추적하세요. 누군가 출력을 고쳐야 한다면 저렴한 첫 호출이 비싼 워크플로가 됩니다.

5. 고객 대상 답변이 되기 전에 주장 확인하기

인용이 있어도 바로 옆 문장을 뒷받침하지 않을 수 있어요. 자료가 계획된 기능을 설명하는데 답변은 이미 이용 가능하다고 말할 수도 있습니다.

TypeSafe의 인용 확인 가이드는 두 검사를 나눠요. 일반 문자열 비교로 빠진 인용문을 찾습니다. 의미 판단은 주변 원문이 주장을 뒷받침하는지 평가해요.

같은 설계를 지원 답변, 생성된 연동 안내문, 에이전트가 제안한 완료 보고서에 적용하세요. 주장, 원문 문단, 판정을 검토할 수 있게 보관합니다.

완료에는 여전히 직접적인 증거가 필요해요. 테스트는 시험한 동작을 입증합니다. 배포 기록은 배포 사실을 입증해요. 의미 판단은 보고서와 증거의 불일치를 표시할 수 있지만 없는 증거를 만들어 내지는 못합니다.

이 활용 사례는 기존 게시 단계 앞에 둘 수 있어 매력적이에요. 놓친 근거 없는 주장, 불필요하게 막힌 근거 있는 주장, 새로 생긴 검토 작업을 측정하세요. 시스템이 이미 저지르는 명백한 오류부터 시작합니다.

6. 녹취록과 고객 피드백을 유용한 후보 목록으로 만들기

녹취록 보관소는 필요한 대목을 찾을 수 있어야 유용해져요. ‘연동이라는 단어를 포함함’은 ‘고객이 설정을 포기한 이유를 설명함’에 비해 약한 필터입니다.

먼저 관련 있어 보이는 문단을 찾고 몇 가지 구체적인 속성을 판단하는 방법이 있어요. 설정 장애를 설명하는지, 구체적 사례가 있는지, 빠진 맥락 없이 혼자 읽혀도 이해되는지 살펴봅니다.

선택한 모든 문단에 원본 URL과 타임스탬프를 붙여 두세요. 타임스탬프는 녹취록에서 가져오고 모델은 관련성을 판단합니다.

동영상 편집자는 검토할 장면의 후보 목록을 만들 수 있어요. 제품팀은 반복되는 반대 의견을 정리할 수 있습니다. 마케팅 담당자는 고객 증거와 근거 없는 캠페인 주장을 구분할 수 있어요.

TypeSafe의 복합 점수 패턴은 평가 차원을 나눠 두므로 코드에서 가중치를 바꿀 수 있어요. 튜토리얼에 적합한 장면과 짧은 제품 시연에 적합한 장면은 다를 수 있습니다. 근거와 기준이 같다면 기존 판단을 재사용하세요.

관련 커뮤니티 구현인 JevQL은 PostgreSQL 행에 의미 조건을 적용하고 데이터베이스 밖에서 평가해요. 문서는 일반 필터가 비용에 중요하다는 점을 보여줍니다. 의미 판단을 요청하기 전에 대상 행을 줄이세요.

검토자의 채택률과 쓸 만한 자료를 찾는 데 절약한 시간을 측정하세요. 도입부의 매력 점수는 조회수 예측이 아닙니다.

7. 다음으로 유용한 동작을 선택하는 인터페이스

설정 화면에 ‘이 동기화를 내일까지 멈춰 줘’라는 요청이 들어올 수 있어요. 브라우저 에이전트는 현재 페이지에 보이는 컨트롤 중에서 골라야 할 수 있습니다.

제안하는 인터페이스 설계에서 애플리케이션은 허용된 동작과 현재 상태를 제공해요. Jev가 그중에서 선택하면 인터페이스가 적절한 컨트롤이나 검토 가능한 제안을 보여줍니다.

Ship with Jev에는 Gregor Zunic의 브라우저 항공편 검색 데모가 있어요. 보고된 실행 시간과 비용은 그 시연에만 해당합니다. 다른 작업에 적용할 수 있는 아이디어는 매 단계 가능한 동작 중에서 고른다는 것이에요. 다른 브라우저 흐름은 별도로 검증해야 합니다.

상태의 최신 여부도 중요해요. 판단 중 선택한 계정이나 페이지가 바뀌면 오래된 결과를 버리세요. 동작을 검토한 계정 및 상태와 연결합니다.

타입이 정해진 UI 목록도 유용해질 수 있어요. 모델이 알려진 화면과 범위가 정해진 데이터를 고르고, 일반 렌더링 코드가 인터페이스를 만듭니다. 작업 완료율과 잘못된 동작을 측정하면서 컨트롤을 계속 이해하기 쉬운지 특히 살펴보세요.

어디서 시작할까요

이미 눈에 띄는 낭비를 만드는 반복 판단을 고르세요. 실제 실패 사례로 평가 집합을 만듭니다.

기존 문제	첫 실험	모을 가치가 있는 근거
검색이 엉뚱한 질문에 답함	찾은 짧은 후보 목록을 판단	정답, 판단 보류, 지연 시간
요청이 팀 사이를 오감	허용된 대기열에서 선택	첫 라우팅 정확도, 전달 횟수
가져오기에서 수동 매핑 필요	실제 원본 필드를 선택	매핑 오류, 검토 시간
모든 작업이 최대 모델을 사용	적합한 작업을 라우팅	수용된 결과당 비용
생성한 답이 지나치게 주장함	자료에 비춰 주장 확인	놓친 근거 없는 주장
아무도 녹취록 보관소를 쓰지 않음	타임스탬프가 있는 문단 반환	검토자 채택률, 근거를 찾는 시간
사용자가 컨트롤을 못 찾음	가능한 동작 제안	완료율, 잘못된 선택

데모의 신뢰도 임계값을 그대로 복사하지 마세요. TypeSafe의 신뢰도 문서는 Choice와 Score 신뢰도가 분포를 요약한다고 설명해요. 입력이 완전하거나 선택한 동작이 허가되었다는 증거는 아닙니다.

어느 후보도 맞지 않는 사례를 포함하세요. 이용할 수 없는 서비스도 포함하세요. 지원하려는 모든 언어를 포함하세요. 이후 변경을 공정하게 비교할 수 있도록 결과에 모델 버전과 질문 정의를 함께 보관하세요.

연동 제품이라면 저는 검색 관련성과 필드 매핑부터 시작하겠어요. 둘 다 실제로 작동하는 동기화까지의 길을 줄여요. 둘 다 실수가 고객 문제로 커지기 전에 확인할 수 있습니다.

지금 소프트웨어가 내놓는 오답 하나를 고르세요. 다음 단계에서 올바른 결정을 안정적으로 하게 만드세요.