Jev AI

JEV 프로젝트

302
건
227
코드 저장소
75
실무 기록

여기 있는 모든 Jev 프로젝트는 Jev를 실제 타입 판단 —— 라우팅, 채점, 검증, 가드레일 —— 에 쓴다. 다만 전부가 코드는 아니다. 어느 쪽인지는 「종류」 열이 알려 준다.

302 / 302

공개 후 일주일 만에 Jev 프로젝트 생태계는 0에서 수백 건까지 늘었다. 그것도 꽤 독특한 모양으로 늘었다. Jev 자체를 제품으로 만든 사람은 거의 없다. 다들 만든 것은 층이었다. API를 한 언어로 감싸는 Jev 프로젝트, Jev의 판단을 MCP 도구로 노출하는 Jev 프로젝트, 이미 있던 에이전트 루프에 Jev 호출 하나를 떨어뜨리는 Jev 프로젝트.

혼자서는 아무것도 못 하는 모델이라면 그렇게 되는 게 당연하다. Jev 프로젝트는 거의 언제나 Jev와 다른 무언가 사이의 배관이다 —— 브라우저 에이전트, 코딩 하네스, RAG 파이프라인, 매매 전략, 게임 루프. 어떤 Jev 프로젝트든 재미있는 물음은 「그게 무엇인가」가 아니라 「남의 시스템 어디에 판단을 두기로 했는가」다.

이 JEV 프로젝트 색인 읽는 법

모든 줄이 코드는 아니다

상류 목록은 저장소와 X 스레드, 블로그 글, 호스팅된 데모를 섞어 둔다. 그쪽의 의도적인 방침이고 —— 기록된 실천도 증거이긴 하다 —— 그래서 Jev 프로젝트 한 줄이 글일 수도 있다. 「종류」 열이 REPO, PACKAGE, WRITE-UP, SITE를 갈라 두니 열기 전에 알 수 있다.

등재는 추천이 아니다

상류가 적용하는 것은 수록 기준뿐이다. 공개돼 있고, 인용 가능하고, 실제로 Jev를 타입 판단에 쓸 것. 여기 있는 어떤 Jev 프로젝트도 코드 품질이나 보안, 심지어 도는지 여부를 아무도 심사하지 않았다. 같은 날 한꺼번에 올라온 무더기는 뼈대를 공유하고 커밋 이력도 얇다.

판단 유형은 추정치다

Jev 프로젝트의 한 줄 설명에서 질문 유형이 읽히면 CHOICE, SCORE, NOUL 중 하나를 붙인다. 읽히지 않으면 찍지 않고 비워 둔다. 다섯 중 둘쯤이 후자다.

분류는 상류의 것

분류 체계는 상류 목록이 가진 것이고, 모든 Jev 프로젝트는 직접적인 응용 영역에 따라 정확히 하나에 들어간다. 그중 「과학 파이프라인」은 정말로 비어 있어서, 감추지 않고 빈 채로 보여 준다.

JEV 프로젝트의 쏠림이 말해 주는 것

압도적으로 큰 덩어리는 인프라다. SDK 래퍼, 게이트웨이 어댑터, MCP 서버, 평가용 뼈대. 이건 「새 시스템을 다시 짜는 대신 지금 있는 시스템에서 써 보고 싶다」고 여겨지는 모델의 전형적인 징후다. 시작하는 참이라면 여기를 먼저 보는 게 좋다. 내 스택에 맞는 어댑터는 이미 누군가 써 뒀을 가능성이 크다.

두 번째는 에이전트 판단이고, Jev가 왜 그렇게 빨리 채택됐는지를 가장 잘 설명해 주는 덩어리다. 클릭마다 프론티어 모델을 부르는 브라우저 에이전트는 느리고 비싸다. 매 수의 판단을 Jev로 옮기고 글자를 쳐야 할 때만 큰 모델을 부르는 Jev 프로젝트는 양쪽에서 한 자릿수를 가져간다. 같은 치환이 코딩 에이전트, 데스크톱 자동화, 로보틱스에서도 나타난다.

그다음은 검증과 가드레일이고, 보정이 실제로 본전을 뽑는 자리가 여기다. 이 덩어리의 Jev 프로젝트는 대개 문지기다. 이 도구 호출은 파괴적인가, 이 완료 선언은 정직한가, 끌어온 문단이 주장을 떠받치는가, 생성된 답이 말한 그 출처를 인용했는가. 전부 임계값이 달린 Noul이고, 이미 돌고 있는 시스템에 Jev를 넣는 가장 위험이 낮은 방법이다.

그리고 롱테일 —— 금융, 게임, 모더레이션, 데이터 라벨링, 컴플라이언스 —— 은 건수는 적지만 더 재미있다. 한 건 한 건이 자기 영역이 사실은 유한한 판단으로 가득했다는 걸 알아챈 기록이기 때문이다. 건당 비용이 맞지 않아서 아무도 자동화하지 않았을 뿐이었다.

출발점으로 삼을 JEV 프로젝트 고르기

Jev를 직접 부르고 싶다면 래퍼를 건너뛰고 공식 SDK에서 시작한다. 파이썬은 typesafe-sdk, 자바스크립트는 @typesafe-ai/sdk이고 둘 다 얇다. 이 색인에 있는 래퍼 계열 Jev 프로젝트 대부분은 그것들을 개선하려는 게 아니라 특정 프레임워크로 다리를 놓으려고 존재한다.

이미 에이전트를 돌리고 있다면 MCP 서버를 찾는다. Choice·Score·Noul을 Claude Code나 Codex 같은 하네스가 바로 부를 수 있는 도구로 노출하는 Jev 프로젝트가 여럿 있다. 위험한 동작 앞에 Jev 판단을 끼우는 데 연동 코드를 한 줄도 안 써도 된다는 뜻이다.

결정하기 전에 모양만 보고 싶다면 작은 걸 하나 끝까지 읽는다. 가드레일 계열이나 컨텍스트 가지치기 계열 Jev 프로젝트는 대개 몇백 줄로 끝난다. 재미있는 부분이 배관이 아니라 질문 설계이기 때문이다. 좋은 Jev 질문이 어떻게 생겼는지 감을 잡는 데는 이게 가장 빠르다.

애초에 Jev가 맞는지 재고 있는 단계라면, 개별 Jev 프로젝트보다 판단 패턴 페이지가 출발점으로 낫다. 반복해서 나타나는 11가지 모양에 대해 state와 질문과 라우팅 정책이, 남의 코드베이스라는 잡음 없이 적혀 있다.

이 JEV 프로젝트 데이터의 출처

이 색인의 모든 Jev 프로젝트는 커뮤니티의 awesome-jev 목록에서 가져온다. MIT 라이선스이고 관리하는 사람은 우리가 아니다. 그쪽 분류 파일을 파싱하고, URL로 중복을 걷어내고, 각 건을 코드인지 실천 기록인지 나누고, 설명에서 판단 유형이 추정되면 유형을 붙이고, 그런 다음 원출처로 바로 링크한다.

우리 쪽 설명은 덧붙이지 않는다. 각 Jev 프로젝트 줄에 있는 한 문장은 상류 관리자가 쓴 것이다. 남의 요약을 우리 말로 고쳐 써서 우리 것처럼 보이게 하는 건 정직하지도 않고 결과도 나쁘다.

JEV 프로젝트 자주 묻는 질문

Jev 프로젝트는 모두 몇 건인가?
이 색인은 302건을 담는다. 코드 저장소나 패키지가 227건, 실천 기록이 75건이고, 내용이 있는 분류 14개에 걸쳐 있다.
이 Jev 프로젝트들은 프로덕션에 써도 되나?
쓸 수 있다고 말할 수 없고, 아무도 확인하지 않았다. 상류가 적용하는 건 수록 기준뿐이고 —— 공개돼 있고, 인용 가능하고, 실제로 Jev를 쓸 것 —— 같은 날 한꺼번에 올라온 무더기가 뼈대를 공유하고 커밋 이력도 얇다고 분명히 경고한다. 등재는 이정표이지 추천이 아니다.
GitHub에 없는 Jev 프로젝트가 있는 이유는?
전체의 4분의 1쯤이 코드가 아니기 때문이다. 상류 목록은 X 스레드, 블로그 글, 호스팅된 데모도 실천 증거로 수록한다. 「종류」 열에서 그것들은 WRITE-UP이나 SITE로 표시되니 걸러 낼 수 있다.
내 Jev 프로젝트를 올리려면?
상류의 awesome-jev 목록에 제출한다. 이 색인은 그 목록에서 만들어지므로 거기서 통과하면 다음 빌드에 여기에도 올라온다.
먼저 읽어야 할 Jev 프로젝트는?
작은 가드레일 계열이나 컨텍스트 가지치기 계열 중 하나. 대개 몇백 줄이고 그 대부분이 배관이 아니라 질문 설계다 —— 그리고 내가 만드는 것으로 가져올 수 있는 건 바로 그 부분이다.
Jev 프로젝트에 공식 SDK가 꼭 필요한가?
필요하지 않다. Jev는 맨 HTTP로 부를 수 있고, 이 색인에도 그렇게 한 건이 여럿 있다. SDK가 주로 덜어 주는 건 재시도와 스키마 코드를 직접 쓰는 수고다.