Jev와 d1을 활용한 설비 점검 기록 48건 실측 비교 — 가동 재개 전 '중단 여부' 판단에 활용 가능한가

결론: '즉시 판단에 사용 가능성'을 가른 것은 정확도가 아닌 '경로와 틀(프레임워크)'이었다

먼저 세 가지 결론을 말씀드립니다.

• 즉시 필요 여부의 정확도는 서로 비슷했습니다. 설비 점검 기록 48건으로 '오늘 가동 재개 전에 에스컬레이션해야 하는지'를 판정하게 했을 때, Jev와 d1 모두 놓친 건이 없었습니다. 오늘 에스컬레이션이 필요한 9건은 모두 확률 0.8 이상으로 잡아냈습니다. 다만 '어떤 시스템을 호출할 것인가'의 일치도는 Jev가 37/48, d1이 32/48로 차이가 있습니다.
• 속도는 중앙값 기준으로 둘 다 서브초(sub-second)였습니다. (Jev 0.76초, d1 0.48초). 다만 d1의 '무료 사용량'만은 건당 11~45초(중앙값 15.4초)가 걸렸고, 타임아웃도 발생했습니다. 같은 모델이라도 프레임을 선택하는 방식에 따라 즉시 판단에 활용 가능 여부가 달라집니다.
• 비용은 신경 쓰지 않을 수준입니다. d1은 48건에 0.0016달러(건당 약 0.005원)였습니다. Jev는 OpenCode Zen의 무료 사용량으로 구동되었습니다.

즉, '어떤 모델이 더 똑똑한가'보다 '어떤 경로로, 어떤 프레임워크를 사용하여, 임계값을 어떻게 설정하는가'가 결과를 좌우했습니다. 판정 모델은 측정기(측정 장비)와 동일하며, 스펙표가 아니라 자신의 조건에 맞춰 보정하여 사용하는 것입니다. 이번 실측을 통해 그 당연한 점이 입증되었습니다.

왜 지금 이 비교인가 — 판정 모델이 2주 만에 급격히 경쟁 구도가 되었다

9월 15일에 Jev가 등장한 이후, 판정 모델이라는 카테고리의 움직임이 갑자기 빨라졌습니다. 지난번 기사를 작성했던 9월 하순부터의 변화를 정리하겠습니다.

• 9월 하순: Liquid AI 'd1' — Decision Index(판정 모델의 벤치마크)에서 선두권을 주장하는 판정 모델입니다. Jev와 호환되는 API 형태이며, 무료 사용량이 제공됩니다 (docs.liquid.ai).
• 9월 29일: OpenAI DevDay에서 'Decisions API' 프리뷰 — Luna 구동으로 실시간 분류 및 분배 결과를 반환합니다. ITmedia는 이를 'Jev를 따라가는 움직임'이라고 보도했습니다 (ITmedia).
• 10월 1일: Cloudflare 'Clef' — Apache 2.0의 오픈 웨이트로, Workers AI에서 구동됩니다. 발표 기사 제목은

모델에 던지는 질문은 3가지입니다. 하나의 요청으로 모아서 보냅니다 (TypeSafe의 Cookbook에서는, 13개의 질문을 약 5.4만 자 분량의 문서(GDPR의 Wikipedia 기사)로 모아서 보내자, 개별 질문보다 12.2배 저렴하고 10.0배 빠르며, 답변도 동일했다는 검증 사례가 공개되어 있습니다). 다만 이것은 긴 문서를 대상으로 한 수치이며, 이번과 같은 짧은 점검 기록에서 같은 배율이 나올지는 미검증입니다.

{
"questions": {
"need_immediate": {
...

noul는 '예/아니오'의 확률이고, score는 단계 평가(criteria 순서를 0~3 눈금으로 한 기대값. 0이 '정상', 3이 '심각')이며, choice는 선택지 중 하나를 반환하는 질문 타입입니다 (지난 기사에서 작성했듯이, Jev는 문장을 생성하지 않고 구조화된 데이터만 반환합니다).

입력할 점검 기록의 예시도 첨부하겠습니다. 실제로 사용한 48건 중 1건입니다.

【일상점검】컴프레서 #1(보전과) 2026-10-01 08:30 담당: 요코야마
- 토출압: 0.61MPa (기준 0.65~0.75MPa)
- 토출온도: 93℃ (기준 80℃ 이하, 경보 100℃)
...

항목별로 보면 '기준 외가 하나 있다' 정도일지라도, 여러 징후가 동시에 움직이고 있습니다. 임계값의 if문만으로는 포착하기 어렵고, 그렇다고 사람이 매일 아침 전부 읽는 것은 현실적이지 않습니다. 이런 기록이야말로 판정 모델이 필요한 부분이라고 생각하여 만들었습니다 (이 건의 정답은 '대응 필요・오늘 에스컬레이션'입니다).

실행은 표준 라이브러리만으로 작성한 Python 러너로 진행했습니다. 1건당 1회, 게다가 EQ-001003는 2회씩 돌려 재현성도 확인했습니다. 재현성의 범위 내에서는 Jev가 6번 모두 성공하여 확률이 거의 동일했고 (0.31과 0.29 등), d1(무료 계정)은 성공한 횟수에서 완벽하게 일치했지만 (0.019와 0.019), 6번 중 2번은 타임아웃되었습니다. 확률이 임계값 바로 근처(0.450.55 등)에 오는 건의 경우, 이 정도의 변동으로 판정이 바뀔 수 있으므로, 임계값은 여유를 두고 정하는 것이 안전합니다.

손에서 시도해 볼 최소 스크립트

같은 것을 1건만 시도한다면 이것으로 충분합니다. Python 3.8 이상부터 추가 설치는 필요 없습니다. 위의 점검 기록과 need_immediate 질문을 하나 보내고, 반환된 JSON을 그대로 표시하는 최소 버전입니다.

import json
import os
import urllib.request
...

실행하면 이렇게 반환됩니다 (실제 출력입니다. 약 0.8초 만에 돌아왔습니다).

{
"model": "d1",
"answers": {
...

noul이 0.9997이므로, 이 기록은 '오늘 재개 전에 에스컬레이션해야 한다'고 거의 확신을 가지고 판정되었습니다 (정답 레이블도 '대응 필요・오늘 에스컬레이션'이었습니다).

여기서 User-Agent를 붙인 것은 다음 절에서 작성할 Zen 경유 호출에서 고유 헤더가 필수였기 때문입니다. 직 API(직접 API)에서 필요한지는 확인하지 않았지만, 붙여 놓아도 곤란한 일은 없습니다.

실행 환경 — Jev는 OpenCode Zen의 무료 계정, d1은 직 API

Jev 1.13 (무료 계정): OpenCode Zen(OpenCode가 제공하는 모델 이용 서비스) 경유. 엔드포인트는 https://opencode.ai/zen/v1/systemone이고, 모델명은 jev-1.13-free입니다. 기존의 OpenCode 키로 그대로 작동했습니다. 걸림돌이 한 가지 있는데, 고유한 User-Agent와 입니다 (없으면 1010 에러로 차단됩니다). Zen에는 유료 버전인 x-opencode-session 헤더가 필수인 jev-1.13도 있지만, 이번에는 무료 계정으로 측정했습니다 -
d1: Liquid AI 직(접속) (https://api.liquid.ai/decisions/v1/systemone, 모델명 d1과 d1:free)입니다. Jev와 완전히 같은 요청 형태이므로, 러너는 모델명과 URL만 교체하면 양쪽에 모두 적용할 수 있습니다.

Zen 경유 호출은 다음과 같습니다 (키는 가렸습니다).

측정은 WSL2(일본)에서 직접 실행하여 클라이언트 측의 왕복 시간을 기록했습니다. 사전에 네트워크 단독 테스트를 분리해 두었기 때문에 (api.liquid.ai에 대한 단순 GET이 0.34초), 이후 수치는 '처리 시간 포함 왕복'입니다.

솔직히 말해서, 처음에 d1 무료 사용량이 11초가 걸렸을 때는 제 측정 코드를 의심했습니다. 네트워크를 측정하여 '이건 내 쪽 문제가 아니다'라고 알았을 때는 또 다른 종류의 난감함이 느껴졌습니다.

실측 결과 — 속도・정확도・비용

속도 — 0.48초와 0.76초. 그리고 무료 사용량의 장벽

또 한 가지 주의할 점이 있습니다. Jev는 Zen을 경유하고, d1은 직(direct) API를 사용하므로 경로가 다릅니다. 0.48초와 0.76초의 차이는 모델의 속도라기보다는 '경로까지 포함된 차이'로 이해해 주십시오.

반면, d1 무료 사용량은 별개의 문제였습니다. 17번 요청하여 응답받은 것은 11번이었습니다. 빠를 때는 11.4초, 중앙값으로는 15.4초, 느릴 때는 45.2초였고, 나머지 6번은 타임아웃 또는 504 (The upstream provider timed out)였습니다. 즉각적인 판단에 사용하기에는 어려운 상태입니다.

하지만 이것은 측정 시점의 스냅샷일 뿐입니다. 무료 사용량은 실험 단계에서 제공되는 것이므로, 향후 개선될 가능성은 충분합니다. 그럼에도 불구하고 저의 결론은 '업무에 사용할 거라면 처음부터 유료 사용량'입니다. 이유는 다음 절의 비용을 보면 알 수 있습니다.

정확도 — 놓친 것 0, 과잉 7, 이진 판단은 48건에서 완벽 일치

오답 7건은 전부 과잉(false positive) 측이었습니다. 대응 필요(2472시간 이내 계획 시정)로 라벨링된 건을 두 모델 모두 '금일 재개 전 상담' 쪽으로 분류했습니다. 즉, 안전한 쪽으로 잘못 판단하는 형태입니다. 놓침과 과잉은 현장에서의 비용이 비대칭적이기 때문에, 이러한 오판 방식은 현장에 적합하다고 느꼈습니다 (Jev 확률 범위 0.640.86, d1은 0.59~0.99).

흥미로운 점은 모델 간 이진 판단(binary judgment)이 48건에서 완벽하게 일치했다는 것입니다. 대응 수준도 47/48로 일치했습니다. '어떤 모델인가'보다 '임계값과 라벨 설계'가 결과를 지배하고 있다는 것이 이 수치의 해석입니다.

두 가지 주목할 만한 사례를 소개합니다.

• 프레스#5의 안전 광선: 한쪽 차광으로 정지하지 않고, 슬라이드 위치 틀어짐 1.8mm, 금형 볼트 느슨함. 두 모델 모두 즉시(immediate) 0.98/1.00 및 중대 판정. 당연히 멈춰야 할 건입니다.
• 교정기#2의 틀어짐: 기준 압력 표시가 8.4% 틀어져 있어, 어제 합격 판정에까지 영향을 줄 수 있는 기록. 두 모델 모두 즉시 판정으로, 시스템도 '계장'을 선택했습니다. 측정 장치 자체의 이상이라는, 놓치기 쉬운 유형을 포착하고 있습니다.

한편 판단이 갈린 사례도 있었습니다. 열처리로(hardening furnace)의 원인 불명 경보 (어젯밤 1회・복구됨・가동 값 안정). 즉시 필요 여부(오늘 에스컬레이션할지)는 양쪽 모두 '보류'로 일치했지만, 대응 수준 점수에서는 Jev가 0.80, d1이 0.14로 갈렸습니다 (0은 '정상', 3이 '중대' 눈금이므로, Jev는 '경미'에 가깝고 d1은 '정상'에 가깝습니다). '애매한 이력을 어떻게 가중치 부여할지'에서 차이가 발생했으며, 이번 가장 흥미로운 케이스입니다. 어느 쪽이 맞다기보다, 이런 경계는 사람이 확인하는 영역으로 두는 것이 안전하다는 것을 알게 되었습니다.

확률의 분포에도 차이가 있습니다. Jev는 0.03, 0.95, 0.31처럼 중용적이고 균형 잡힌 형태인 반면, d1은 0.00001이나 0.9999처럼 양극단입니다. 확률의 절대값을 모델 간에 비교하는 것은 의미가 없으며, 비교한다면 '동일 모델 내에서의 순위'와 '자체적으로 정한 임계치(しきい値)'로 보는 것이 제 결론입니다.

비용 — 48건으로 0.0016달러

• d1 (유료): 48건에 0.0016달러. 건당 0.000033달러, 일본 엔화로 약 0.005엔입니다 (API 응답의 usage.cost를 합산한 값이며, 청구 확정값은 아닙니다. 참고로 위의 최소 스크립트는 질문이 하나이므로 건당 약 0.00001달러였으며, 질문 3개를 측정했을 때는 평균 약 0.000033달러였습니다). 하루에 100건을 판정해도 월 15엔 정도 - Jev: Zen의 무료 계정으로 0달러 (무료 계정 조건은 변경될 수 있으므로, 업무 이용 시에는 공식 최신 조건을 확인해 주세요)

지난 기사에서 소개한 TIMEWELL 실측(1,852건에 0.12달러)과 같은 방향으로 볼 때, 판정 모델의 비용은 더 이상 선정 요인이 아닙니다. 차이가 나는 것은 경로와 범위, 그리고 레이턴시입니다.

결과 해석 — '확률이 허가'는 아니다를 현장의 언어로

'확률이 높다 = 그대로 실행해도 좋다'는 의미가 아닙니다. 이것이 지난 기사의 원칙입니다. 숫자가 나왔으므로, 이를 현장의 언어로 번역합니다.

임계치는 자신의 놓치는 비용으로 결정한다. 이번에는 0.5로 설정하여 놓친 건(見逃し)이 없었습니다. 그렇다면 0.9로 올리면 어떻게 될까요? Jev의 즉시 판정 9건은 0.800.98 범위이므로, 0.9 미만인 건은 자동 태그 영역에서 떨어집니다. 게다가 과잉(過剰) 측 7건 (0.640.86)과 확률 범위가 겹쳐 있어 임계치만으로는 구분할 수 없습니다. 임계치를 올리면 과잉은 줄어들지만, 놓치는 건이 발생합니다. 어디서 자를지는 놓치는 비용과 과잉의 비용 비율로 스스로 결정해야 합니다. 검사 공정의 합격/불합격 기준과 마찬가지로, 모델의 기본값은 출발점에 불과합니다.

질문 문장의 함정 (솔직하게 말씀드립니다). 계통(discipline)에 대한 질문은 '대응이 필요한 경우'라고 작성했습니다. 결과를 보니, 경미한(경과 관찰) 건에서 두 모델 모두 '없음' 쪽에 가까운 답을 내는 경향이 있었습니다. 모델은 '대응'을 '실제 수리/작업'으로 해석한 것입니다. 저의 의도는 '주의를 기울여야 할 계통'이었습니다. 정답은 어느 쪽도 아니었고, 해석이 나뉘지 않는 질문 문장을 작성하지 못한 제 측의 문제였습니다. 질문은 5초 만에 답할 수 있는 수준의 세밀함(粒度)이라는 지난 원칙의 중요성을 스스로 깨달았습니다.

가장 중요한 배움: 테스트는 자신의 기준도 교정한다. 프레스#5 계통에서 두 모델 모두 '전기/제어'라고 답했습니다. 안전 광선(인터록)의 결함 때문입니다. 저는 라벨을 '기계'로 설정했었습니다. 어느 쪽이 맞는지보다, 기준으로 삼는 것(정답 라벨) 측도 의심해 봐야 합니다. 이번에 라벨 재검토 후보가 2건 나왔습니다 (이 계통 분류와 컴프레서 건의 레벨 경계). 모델을 평가하려다가, 오히려 제 판정 기준을 교정하는 작업이 되고 있었습니다. 검사 공정의 측정기 교정과 같은 구조라 신기하게 납득했습니다.

이 결과를 어디까지 믿을 것인가. 놓친 건 0은 즉시 판정 9건에 대한 이야기입니다. 9건에서 0이라도, 실제 놓치는 비율이 3할 정도 있을 가능성까지는 부정할 수 없습니다. 게다가 데이터는 AI 에이전트로 합성한 것이며, 모델 입장에서 '읽기 쉬운 문면'이 되었을 가능성이 있습니다. 그러므로 '실용 단계에 진입했다'가 아니라, '자사 실데이터로 교정할 가치가 있는 수준'으로 해석하는 것이 정확하다고 생각합니다.

**사람에게 되돌리기(人への切戻し)**는 지난 기사와 같은 형태로 생각합니다. 이번 데이터를 사용한다면 다음과 같습니다.

판정 모델을 현장에서 선택할 때의 체크리스트

이번 실측에서, 선정 시 봐야 할 순서를 정리했습니다.

경로와 범위를 먼저 확인한다 — 같은 모델이라도 무료 사용량(free tier)과 유료 사용량(paid tier)에 따라 속도가 30배 이상 차이가 났습니다 (무료 사용량 중앙값 15.4초 vs 유료 사용량 0.48초). 즉시 판단 시스템에는 무료 사용량을 배치하지 마십시오.
실측 왕복 지연 시간(round-trip latency)을 측정한다 — 처리 시간 + 경로. 이번에 측정한 0.480.76초는 일본(WSL2)에서 요청하여 돌아온 왕복 시간을 포함한 값입니다.
자사 데이터 2050건으로 보정한다 — 정답을 먼저 붙이고, 애매한 경우(gray area)를 섞는다. 이것이 완료될 때까지 본 서비스에 연결하지 마십시오.
'놓침(miss)'과 '과잉(over-detection)'의 비용을 결정한 후 임계값(threshold)을 설정한다 — 기존의 0.5로 괜찮은지는 현장 상황에 따라 다릅니다.
질문 문구는 해석이 나뉘지 않는 단어로 작성한다 — '대응'이라는 의미 하나만으로 결과가 바뀌었습니다.
기록한다 — 모델명과 버전, 질문 문구, 임계값, 오판 사례. 이는 감사와 개선의 기반이 됩니다.
안전 시스템에는 사용하지 않는다 — 지난번부터 일관됩니다. 판단 모델은 1차 선별까지만 담당하고, 안전 관련 처리는 결정론적인 별도의 시스템에 두어야 합니다.

요약 — 자사에서 시도해 볼 경우 이 순서로

• 대상을 하나 선택한다 (점검 기록의 필수 확인 추출 등, 빈도가 높고 기준을 언어로 정의할 수 있는 것).
• 20~50건의 정답 라벨을 만든다 (애매한 경우 포함/사전 지정).
• 질문을 한 논점씩 설계하여 하나의 요청에 모아 보낸다.
• 본 서비스는 지금까지처럼 사람이 판단하고, 모델의 확률은 병행하여 기록한다.
• 임계값과 사람에게 되돌리는 구간(fallback zone)을 결정하여 고정적으로 기록한다.

제 결론은 이렇습니다. 설비 점검 기록의 '필수 확인' 1차 선별은 시도해 볼 가치가 충분한 수준에 있습니다. Jev는 OpenCode Zen의 무료 사용량으로 오늘부터 시도할 수 있습니다. d1은 유료 사용량이라면 속도와 비용 모두 문제가 없습니다 (무료 사용량은 측정 시점에서는 이르다고 생각합니다). 다만, 업무에 적용할 전제라면 Jev 역시 유료 버전(jev-1.13)에서 재측정하는 것이 맞다고 생각합니다. 이번 Jev의 수치는 무료 사용량을 기준으로 한 것이기 때문에 조건이 바뀌면 결과도 달라질 수 있기 때문입니다.

다음으로는 이것을 C#(.NET) 점검 기록 앱에 통합하여, 기록 입력 시 '필수 확인' 태그가 자동으로 붙는 형태로 시험해 볼 예정입니다. 판단 API의 C# 구현은 아직 글이 적은 영역이라 결과는 여기에 다시 작성하겠습니다.

자주 묻는 질문

Q. Jev와 d1, 어느 것을 사용해야 하나요?

A. 즉시 필요 여부 판별은 이번 48건에서는 서로 비슷했습니다. 호출할 시스템의 일치도는 Jev가 약간 더 높았습니다 (37/48 대 32/48). 선택의 결정 요인은 경로입니다. 간편하게 시도해 보고 싶다면 Jev(OpenCode Zen 무료 사용량), 오픈 웨이트로 자사 운영을 고려한다면 Clef, 기존 OpenAI 기반이 있다면 Decisions API(현재 프리뷰 중)가 좋습니다. Clef와 Decisions API는 이번에는 미검증입니다. 먼저 동일한 테스트를 여러 모델에 돌려보고, 자사 데이터로 비교하는 것을 추천합니다.

Q. 무료로 시도할 수 있나요?

A. Jev는 OpenCode Zen의 무료 사용량(jev-1.13-free)으로, Zen 계정 키로 작동합니다 (커스텀 헤더 2개 지정 필요). d1에도 무료 사용량이 있지만, 측정 시점에서는 건당 11~45초가 걸리고 타임아웃도 발생하여 실용성이 떨어지는 상태였습니다. 조건은 바뀔 수 있으니 공식적으로 확인해 주십시오.

Q. 한국어에서도 정확도가 나오나요?

A. 이번의 48건은 모두 한국어로 만들었고, 즉시 건에 대한 놓침은 0이었습니다. 다만 즉시 건은 9건, 데이터는 합성, 환경은 단일/단일 시점 측정입니다. 자사 데이터로 확인하는 것이 필요합니다.

Q. 사진 점검 기록에도 사용할 수 있나요?

A. 이미지는 직접 전달할 수 없습니다. 사진은 기존의 이미지 처리나 VLM(이미지를 읽는 AI)을 통해 문자/숫자로 변환한 후, 판단 모델이 '문자로 된 이후'의 선별을 담당합니다.

Q. 설비 안전장치 판단에 사용할 수 있나요?

A. 사용하지 않는 전제로 설계하십시오 (지난번 글부터 일관). 안전 관련 처리는 결정론적인 별도의 시스템에 두고, 판단 모델은 '사람이 봐야 할 것의 선별'까지만 담당합니다.

출처

• Liquid AI 문서 (Decision Models / d1)
• OpenCode Zen 문서 (Jev 1.13 Free)
• TypeSafe AI 문서
• TypeSafe Cookbook 'Parallel questions' (13문항 일괄 투척 검증)
• Cloudflare Blog 'Introducing Clef: our open-source decision models' / Workers AI 변경 로그
• The Register 'Cloudflare tries to outplay Jev with open-weight Clef models'
• ITmedia 'OpenAI가 「Jev」를 추격하여 「Decisions API」 출시'
• PR TIMES 'Archaic, TypeSafe AI의 「Jev」를 활용한 기업용 AI 데이터 분석 기반 개발'
• Qiita '【검증】 Jev의 확률은 어떻게 읽어야 할까? - 50건 × 3회 실행으로 확률과 정답 대응 확인'
• Zenn 'Jev를 만져보고 싶었을 뿐인데, 어느새 평가 CLI를 v0.4.0으로 만들고 있었다 (typesafe-eval)'

측정일: 2026년 10월 3일 (48건 × 1회 + 재현성 확인)

【연재】

• GitHub Copilot으로 루프 엔지니어링을 구성할 수 있는지 조사해 봄
• 루프 엔지니어링 다음은 정말 '그래프'인지 생각해 봄
• AI 에이전트의 '판단' 문제, 검사 공정은 이미 해결했었다
• 판단에만 특화된 AI 모델 'Jev'를, 루프 → 그래프 → 판단의 계보로 읽어내기
• Jev 활용 사례를 제조 업계 시각으로 조사 — 검사의 1차 선별부터 로봇의 판단층까지

스킬(AI의 행동을 고정하는 구조)을 만드는 방법은, 모아놓은 책에 적었습니다.

Discussion