이틀 만에 복제된 것은 인터페이스였고, 품질은 아니었다

이틀 전 Jev에 대해 쓰면서 이렇게 판단했다 — 락인은 벤더의 개방성이 아니라 인터페이스의 폭으로 결정된다, 가중치가 비공개여도 출력 계약이 좁으면 교체 비용은 낮다.

이틀 만에 같은 입출력 형태의 오픈소스가 나왔다. 그래서 내 판단은 절반만 맞았다.

인터페이스는 복제됐다. 품질은 복제되지 않았다. 그리고 그 사실을 만든 사람이 직접 README에 적어뒀다.

출처: github.com/vinnylarouge/jevlike (MIT)

확인된 것

저장소를 직접 읽고 확인한 것만 적는다.

저장소 생성 2026-09-16, 같은 날 마지막 푸시. 확인 시점 별 716개, 포크 67개. MIT.
하는 일: 텍스트 하나와 선택지 N개를 받아 각각의 확률을 돌려준다. 한 번의 패스로. 자기 정의는 이렇다.

This repository is an independent starter model with the same input and output shape.
구조: 각 선택지가 쿼리 벡터가 되어 컨텍스트 토큰에 어텐션을 걸고, 공유 내적으로 점수를 만든 뒤 선택지들 사이에 softmax. 기본 인코더는 사전학습 없이 바이트 임베딩을 처음부터 학습하고, 옵션으로 Hugging Face의 동결 인코더를 쓸 수 있다.
데이터 형식은 JSONL 한 줄에 {"context":..., "options":[...], "label":0}. 행마다 선택지 개수가 달라도 된다(최소 2개).
저자가 밝힌 수치: 합성 메뉴 약 98%. Wikispeedia 다음 클릭 예측에서 동결 Qwen2.5-0.5B + 스코어러 26%, 대조군(셔플·랜덤 인코더)은 약 8%. 4만 클릭으로 처음부터 학습한 작은 모델은 29%. 선택지 8개일 때 한 번의 패스가 400토큰을 쓰는 작은 디코더보다 약 100배 빨랐다.
체스 체크포인트 성적을 스스로 적어뒀다. 랜덤 무버 상대 50판에서 4승 46무 0패, Stockfish 레벨 0 상대로는 0승 2무 48패.
한계를 여섯 줄로 나열하는데, 그중 둘이 핵심이다.

We did not show equal quality with Jev or reproduce TypeSafe's private training method.

One-pass scoring requires the complete option list before prediction.

판단

1. 좁은 인터페이스가 보장하는 것은 대체재가 아니라 대체재의 가능성이다

이틀 만에 같은 형태의 구현이 나왔다는 건 내 이틀 전 판단을 뒷받침한다. 출력 계약이 "선택지별 확률"처럼 좁으면 누군가 같은 모양을 만드는 데 오래 걸리지 않는다.

그런데 만든 사람 본인이 Jev와 품질이 같다는 걸 보이지 못했다고 쓴다. 그러니 정확히 다시 쓰면 이렇다 — 좁은 인터페이스는 대체재가 생길 확률을 높이지, 벤더를 지금 바꿀 수 있게 만들지 않는다. 내가 얻는 건 무료 대안이 아니라 협상력과 퇴로다.

실무에서 이 차이는 크다. "언제든 갈아탈 수 있으니 붙어도 된다"와 "갈아탈 자리가 생기고는 있으니 계약을 길게 묶지는 말자"는 다른 결정이다. 후자가 맞다.

2. 좋은 숫자를 어디 뒀는지 말고, 나쁜 숫자를 어디 뒀는지 보라

이틀 전 글에서 벤더 쪽 발표를 이렇게 정리했다. 홈페이지에는 193.6배와 444.6배가 있고, 본문 안쪽에 "우리 수치는 실증이 아니다"가 있었다.

이 저장소는 순서가 반대다. Wikispeedia 26%를 쓰면서 대조군 8%를 같은 문장에 넣는다. 체스 체크포인트가 랜덤 상대로는 이기지만 Stockfish 레벨 0에게 48판 진 것을 README 첫 화면에 적는다. 데모 영상 구간에 대해서는 활동량 기준으로 고른 것이고 통상 플레이나 실력 주장이 아니라고 못박는다.

숫자의 크기로는 두 발표를 비교할 수 없다. 비교 가능한 건 반증 자료를 같이 냈는가다. 이건 오픈소스라서 정직한 게 아니다. 가중치를 공개해도 대조군을 안 쓰면 검증할 수 없고, 비공개여도 대조군을 쓰면 읽을 게 남는다. 발표를 읽을 때 쓸 기준은 라이선스가 아니라 이쪽이다.

3. 26%를 보고 실망했다면 대조군을 안 본 것이다

대조군이 8%다. 위키 링크 다음 클릭 맞히기는 정답이 여럿일 수 있는 작업이라 상한 자체가 낮다. 3배 넘게 이겼으면 신호가 있다는 뜻이고, 그 이상으로 이 숫자를 해석할 필요는 없다.

정작 중요한 건 정확도가 아니라 형태다. 컨텍스트 + 가변 선택지 N개 → 확률 N개. 이틀 전에 쓴 실행 항목이 그대로 유효하다 — 내 호출을 A통(열거형·점수·불리언)과 B통(자유 텍스트)으로 나눠 비율부터 세는 것.

다만 이번에 제약 하나가 명확해졌다. 예측 전에 선택지 목록 전체가 있어야 한다. 선택지가 실행 중에 만들어지는 라우팅에는 이 형태를 못 쓴다. A통에 넣어둔 호출을 다시 볼 때 이걸 기준으로 한 번 더 걸러야 한다.

4. 이 저장소의 실제 쓸모는 Jev의 대체재가 아니다

기본 인코더가 사전학습 없이 바이트부터 배우고 합성 메뉴에서 98%를 낸다는 점이 실무적으로 제일 중요하다. "이 작업에 정말 LLM이 필요한가"를 로컬에서 싸게 판정할 수 있다는 뜻이기 때문이다.

분류·라우팅·점수화를 프런티어 모델로 돌리고 있다면, 그 작업의 데이터를 JSONL로 뽑아 여기에 넣고 대조군과 비교해보는 것이 API 요금제를 비교하는 것보다 먼저다. 결과가 대조군과 비슷하면 그 작업은 데이터가 부족한 것이고, 훨씬 나으면 그 호출에는 모델 지능이 필요 없었던 것이다. 둘 다 알아야 할 답이다.

이건 저장소가 주장하는 용도가 아니라 내가 보는 용도다. 저자는 이걸 "research starter"라고 부른다.

모르는 것

직접 학습시켜보지 않았다. README와 저장소 구조를 읽었을 뿐이다. 위 판단은 그 독해에서 나온 것이다.
저자가 밝힌 수치는 "이 스타터로 이어진 실험"의 것이고 퀵스타트를 그대로 돌린 결과가 아니라고 본인이 단서를 달았다. 재현 조건을 확인하지 못했다.
100배 비교의 상대는 작은 로컬 디코더다. 저자가 직접 적었다. 상용 대형 모델과의 비교가 아니다.
Jev의 실제 정확도를 모르니 "품질이 복제되지 않았다"는 것도 저자의 진술에 근거한 것이지 내가 두 모델을 비교해서 확인한 게 아니다. 애초에 Jev 발표에도 정확도 비교 수치가 없었다.
별 716개는 이틀치 숫자다. 채택이 아니라 관심의 지표로만 읽어야 한다.