실측 결과, 2026-09-26 KST, 세 라운드 3,560회 호출

Jev × CMDS 실측 결과: 세 라운드 사전 등록 실험

저는 2026-09-26 하루 동안 TypeSafe의 판단 모델 Jev(System One)를 제 옵시디언 볼트(10,000+ 노트, CMDS 체계)의 지식관리 판단 네 가지에 붙여 세 라운드로 쟀습니다. 검색 후보 재선택, 후보별 유지 집합, CMDS 87 서브카테고리 분류, 프로젝트와 볼트 라우팅입니다.

구요한 (Yohan Koo), CMDSPACE게시 2026-09-26

3,560

호출, 전부 HTTP 200, 재시도 0

8,264,570

입력 tokens, 전역 상한 15,000,000의 55.1%

$0.3471

입력 × $0.042/1M 기준

100%

모델 핀 일치 3,560/3,560, jev-1.13.0

세 라운드 합계, 2026-09-26 KST. 라운드별 내역은 합계에 있습니다.

이 페이지는 무엇을 어떻게 쟀는지, 사례별로 무엇이 나왔는지, 이 숫자로 말할 수 있는 것과 말할 수 없는 것을 적습니다. 지금 운영 판정은 제안(PROPOSE) 단계입니다. Jev는 볼트에 아무것도 쓰지 않는 섀도 모드로만 붙어 있고, 결정과 저장은 사람과 코드가 합니다.

이 숫자를 읽는 법. 모든 정답은 사람이 새로 붙인 라벨이 아니라 볼트에 이미 있던 메타데이터와 위치입니다. 그래서 숫자는 "Jev가 기존 판단을 얼마나 재현하는가"이고, 불일치의 일부는 볼트의 오래된 관례나 다른 타당한 라벨일 수 있습니다. 비율 뒤 대괄호는 Wilson 95% 구간입니다. 합격선은 어느 라운드에도 두지 않았고, p값은 방향 단서로만 씁니다. 따로 적지 않은 측정일은 모두 2026-09-26입니다.

At a glance한눈에

같은 항목에서 Jev와 비교 조건을 나란히 놓았습니다. 검색의 끝단은 질의 전체 기준 정답률로, 후보 재현율과 조건부 선택의 곱입니다.

검색

검색 후보 재선택한국어 질문, r3 처음 쓰는 위키 표적 49단위

Jev 끝단[78.2, 95.6]44/49 89.8%

후보 목록 1위 (코드)[21.2, 46.6]16/49 32.7%

표적이 목록 안인 단위에서 목록 1위만 맞힌 수 1, Jev만 맞힌 수 29입니다.

유지 집합 필터Noul 절단 0.3, r3, 후보 평균 17.55개 중 2.39개 남김

Jev 유지 집합, 표적 유지[88.4, 99.6]44/45 97.8%

같은 크기의 목록 상위 3개[41.2, 69.1]25/45 55.6%

후보를 평균 17.55개에서 2.39개로 86.4% 줄이면서 표적 45개 중 44개를 남겼습니다.

찾는 노트가 목록에 없을 때표적이 후보 목록 밖인 단위에서 '해당 없음'을 고른 비율

r1 design + threshold[18.8, 81.2]3/6 50.0%

r2 봉인 final[0.0, 43.4]0/5 0.0%

r3 처음 쓰는 위키 표적[0.0, 49.0]0/4 0.0%

표적 부재 단위가 적고, r2 final과 r3에서 기권은 0이었습니다. 그래서 서비스는 fail-open입니다. Jev가 보류하거나 호출이 실패하거나 유지 집합이 비면, 코드가 만든 후보 목록을 그대로 돌려줍니다.

입력 라우팅

CMDS 87 분류, 이름 + 정의r2 봉인 final 120건, 영구 노트와 문헌 노트 폴더

Jev 이름 + 정의 87[67.5, 82.6]91/120 75.8%

Jev 이름만 87[13.8, 28.0]24/120 20.0%

노트 유형 규칙표[76.6, 89.6]101/120 84.2%

이 표본에서는 공짜 규칙표가 모든 Jev 조건 이상이었습니다. 120건 중 93건이 두 형식 클래스입니다.

CMDS 87 분류, 처음 쓰는 폴더r3 65건, 문서와 자산과 산출물 폴더, 규칙표는 r2에서 고정

Jev 이름 + 정의 87[31.8, 55.2]28/65 43.1%

캐스케이드 (규칙, 없으면 두 순서 합의)[20.9, 42.8]20/65 30.8%

규칙표가 닿은 27건[0.7, 18.3]1/27 3.7%

규칙표 행은 분모가 달라(65건 대 27건) 같은 문항 위의 맞대결로 읽지 않습니다. 같은 65건에서는 캐스케이드가 Jev 단독보다 낮았습니다.

프로젝트 라우팅r2 봉인 final 80건, 활성 프로젝트 6개 + 보류

Jev 이름 + README 한 줄[91.3, 99.3]78/80 97.5%

Jev 이름만[77.0, 92.2]69/80 86.3%

README 한 줄(호출당 +334 tokens)이 오류 11건을 2건으로 줄였습니다. 과제는 포화 상태이고, 여섯 프로젝트는 서로 뚜렷이 다릅니다.

메인 대 위키 라우팅r2 봉인 final 80건

Jev[52.8, 73.4]51/80 63.8%

다수 클래스40/80 50.0%

세 분할과 두 순서에서 60~80%(n = 40~80)에 머물러, 서비스 명령으로 만들지 않았습니다.

Method방법

네 갈래 실험을 세 라운드로 돌렸고, 라운드마다 첫 호출 전에 프로토콜을 등록했습니다.

무엇을 정답으로 삼았나

정답

CMDS 분류(E-A)는 노트의 기존 CMDS: 값, 볼트 라우팅(E-B)은 실제 볼트와 위키 폴더, 검색(E-C)은 질의를 만든 표적 노트 하나, 프로젝트 라우팅(E-D)은 실제 프로젝트 폴더가 정답입니다. 사람이 새로 판정한 골드는 이 실험군에 아직 0건입니다.

보낸 것

분류와 라우팅에는 노트의 제목, description, 태그 최대 8개, 본문 앞 1,200자를 보냈습니다. 경로, 노트 유형(type), 기존 CMDS: 값은 정답을 누설하므로 보내지 않았고, 본문 속 CMDS 링크도 가렸습니다.

검색 질의desc, qko

영어 질의(desc)는 표적의 description 전문이라 본문과 문자열이 겹치는 known-item 상한입니다. 한국어 질의(qko)는 GPT-6 Luna가 표적 description만 보고 만든 질문입니다(라운드마다 일괄 호출 1회, 제목 단어 재사용 금지 지시). desc는 목록 1위가 이미 천장이라(r2 final 55/55) 결과는 qko에서 나왔고, r3는 qko만 돌렸습니다.

수행

설계, 사전 등록, 호출, 분석은 Claude Opus 5.5 에이전트가 Python 하네스로 수행했습니다.

사전 등록과 분할

사전 등록동결 해시

라운드마다 첫 Jev 호출 전에 프로토콜을 고정했습니다(등록 시각 r1 03:22, r2 04:51, r3 06:34 KST). 프로토콜, 하네스, 자료 파일의 SHA-256을 등록 파일에 적었고, 하네스는 동결 파일(r2 18개, r3 15개)의 해시가 등록값과 다르거나 등록하지 않은 조건 이름이 들어오면 실행과 분석을 거부합니다. 등록 뒤 생긴 일은 이탈 목록에만 추가했고 등록 문서는 고치지 않았습니다. 예측은 방향만 적었고(r3 13개), 합격선은 없습니다.

분할design, threshold, final

r1은 design과 threshold만 돌렸고 final은 r2까지 봉인했습니다. 하네스는 명시 플래그 없이 final 실행을 거부합니다. r2는 threshold에서 게이트와 유지 집합 절단점을 한 번 적합해 파일로 고정했고(05:04:17, 파일이 있으면 적합 명령이 거부), final은 조건마다 정확히 한 번 보냈습니다. 재전송은 0입니다.

사후 가설새 자료로 재검증

r2 final을 본 뒤 두 가설이 나왔습니다. 노트 유형 규칙표가 닿으면 규칙으로 끝내고 아니면 Jev에 묻는 캐스케이드, 그리고 Jev 후보 선택과 Noul 유지 집합 절단 0.3입니다. final을 보고 계산한 값은 결과가 아니라 가설로 다뤘습니다. r3는 r1과 r2가 어떤 역할로든 쓴 노트 1,130개를 뺐고(검색 표적은 예전에 후보로만 나온 노트까지), 겹치지 않음을 코드로 확인했습니다. r3에는 적합 단계가 없고, r2에서 고정한 규칙표와 두 절단점만 적용했습니다.

실험	design	threshold	final (봉인)
E-A CMDS 분류	91	100	120
E-B 볼트 라우팅	40	40	80
E-C 검색 (표적, 질의 단위)	24, 48	28, 56	55, 110
E-D 프로젝트 라우팅	30	30	80

분할별 항목 수. 검색은 표적 수와 질의 단위 수(영어와 한국어)를 함께 적었습니다.

기준선과 결정 규칙

기준선

Jev 조건마다 API를 쓰지 않는 기준선을 같은 항목에 붙였습니다. 공짜 코드가 이기는 자리에는 Jev를 쓰지 않기 위해서입니다. 분류는 다수 클래스(104 Terminologies), 노트 유형 규칙표, 이름과 정의 87개 문서에 대한 BM25 1위입니다. 검색은 후보 목록 1위(로컬 검색 엔진 qmd 2.8.3의 BM25 상위 10개와 벡터 상위 10개를 RRF k=60으로 합친 순서의 1위), 로컬 qmd query 1위(질의 확장, HyDE, LLM 재랭킹을 모두 쓰는 기본 모드), 유지 집합과 크기를 맞춘 목록 상위 k개입니다. 볼트 라우팅과 프로젝트 라우팅은 정답이 곧 위치라 다수 클래스 참고치만 적었습니다.

규칙표 5행

design과 threshold 정답에서 만들었습니다. note → 220 Personal Insights(지지 79건 중 39.2%), terminology → 104 Terminologies(64건 90.6%), manuscript → 802 Articles(25건 100%), essay → 601 Knowledge Management(8건 87.5%), literature-note → 210 Literature Reviews(8건 100%).

결정 규칙코드가 결정

Jev Choice는 선택지별 확률을 돌려줍니다. 결정은 확률 argmax이고, 1위와 2위가 같으면 보류, 1위가 '보류'나 '해당 없음'이면 기권으로 셉니다. 응답의 자체 choice 필드는 결정에 쓰지 않았습니다. Noul 유지는 엄격 부등호(값 > 절단점)라 절단점과 같은 값은 남기지 않습니다.

역순 재질문

선택 조건마다 선택지 순서를 뒤집은 조건을 짝으로 돌렸습니다('보류'와 '해당 없음'은 두 순서 모두 마지막). 순서 뒤집힘은 두 순서의 결정이 다른 비율이고, 합의 규칙은 두 순서가 같은 답을 낼 때만 답합니다.

통계

모든 비율에 분모와 Wilson 95% 구간(z = 1.96)을 붙였습니다. 같은 항목에서 두 조건을 비교할 때는 앞 조건만 맞힌 수 b, 뒤 조건만 맞힌 수 c와 정확 이항 부호검정(양측)을 적었습니다. p값은 합격선으로 쓰지 않았고 분할은 합치지 않았습니다. 지연은 성공 호출의 p50과 p95(nearest-rank)입니다.

예산, 영수증, 전송 경계

예산 상한원장

전역 상한은 입력 15,000,000 tokens(Jev 공개 단가 입력 $0.042/1M 기준 약 $0.63)이고, r3에는 라운드 상한 2,500,000을 따로 걸었습니다. 보내기 전에 추정 토큰을 예약하고 실측으로 정산했으며, 200이 아닌 시도의 추정 토큰도 누계에 넣었습니다. r2부터 파일 잠금 단일 기록자 원장을 썼고, r2와 r3 원장값은 각 호출 기록의 합과 같습니다. 실측은 사전 추정 대비 80.6%(r1, 4,055,259 중 3,269,848), 95.3%(r2, 4,170,389 중 3,974,285), 99.4%(r3, 1,026,297 중 1,020,437)로, 앞 라운드 실측 비율로 보정하면서 좁혀졌습니다.

영수증

호출마다 한 줄을 남겼습니다: 시각, 실험, 분할, 조건, 항목, 선택지 순서, 요청 모델과 응답 모델, HTTP 상태, 입력 토큰, 지연, 전체 확률 분포, 결정, 재시도 수. r2와 r3 통합 분석은 저장된 확률에서 결정을 다시 계산해 하네스 수치와 대조했고, r3는 결정 불일치 0, 지표 불일치 0입니다. 분석은 API 키 없이 동결 파일만으로 다시 계산됩니다.

전송 경계

허용 폴더 목록과 거부 규칙(인물, 회의 기록, 신앙, 고객 작업, 재무, 전사본, 수강 코호트 등)으로 개인과 제3자 정보가 담길 수 있는 노트를 표본에서 뺐습니다. 호출 직전에 조립된 payload 전체를 다시 검사해 민감 패턴, 이메일, 전화번호, 홈 경로가 남아 있으면 보내지 않았습니다. r3는 음성 테스트 35개가 모두 차단됐고, 전송 시 차단은 0건입니다.

Results활용 사례별 결과

사례마다 라운드별 표를 두고, 표 아래에 읽는 법을 적었습니다. 좁은 화면에서는 표를 옆으로 밀어 볼 수 있습니다.

검색 후보 재선택

질의마다 코드가 후보 목록을 만들고(r2부터 평균 약 17~18개, r1은 약 10개), Jev Choice가 그중 하나 또는 '해당 없음'을 고릅니다. 정답은 표적 노트 하나입니다. 한국어 질문(qko) 결과입니다.

지표 (qko)	r1 design	r1 threshold	r2 final	r3 처음 쓰는 위키 표적
질의 단위 n	24	28	55	49
후보 재현율	21/24 87.5%[69.0, 95.7]	25/28 89.3%[72.8, 96.3]	50/55 90.9%[80.4, 96.1]	45/49 91.8%[80.8, 96.8]
후보 목록 1위 (코드)	8/24 33.3%[18.0, 53.3]	11/28 39.3%[23.6, 57.6]	30/55 54.5%[41.5, 67.0]	16/49 32.7%[21.2, 46.6]
로컬 `qmd query` 1위	미실행	미실행	26/55 47.3%[34.7, 60.2]	미실행
Jev 선택 (표적이 목록 안)	20/21 95.2%[77.3, 99.2]	23/25 92.0%[75.0, 97.8]	45/50 90.0%[78.6, 95.7]	44/45 97.8%[88.4, 99.6]
Jev 끝단	20/24 83.3%[64.1, 93.3]	23/28 82.1%[64.4, 92.1]	45/55 81.8%[69.7, 89.8]	44/49 89.8%[78.2, 95.6]
목록 1위 대 Jev, 표적이 목록 안 (b/c, p)	b0/c12p 0.0005	b2/c14p 0.004	b2/c17p 0.0007	b1/c29p < 0.0001
역순 뒤집힘	0/24	1/28	3/55 5.5%[1.9, 14.9]	3/49 6.1%[2.1, 16.5]

읽기네 칸 모두 끝단 = 후보 재현율 × 조건부 선택이 개수 기준으로 정확히 성립하고(r3는 45/49 × 44/45 = 44/49), 조건부 선택이 90% 이상이라 남은 손실은 후보층에 있습니다. 조건부 오류도 대부분 가까운 형제 페이지였습니다(r1 3건 전부, r2 5건 중 2건, r3는 정순 1건과 역순 1건 모두). 사후 가설을 처음 쓰는 위키 표적 49단위에서 다시 잰 r3에서도 Jev는 목록 1위를 앞섰고, 두 순서가 합의할 때만 답하면 끝단 43/49 87.8% [75.8, 94.3], coverage 46/49, 답한 것 중 43/46 93.5% [82.5, 97.8]입니다.

r2 final 기준선을 질의 종류별로 나누면 아래와 같습니다.

r2 final (55표적)	영어 질의 (desc)	한국어 질문 (qko)
후보 목록 1위	55/55 100%[93.5, 100]	30/55 54.5%[41.5, 67.0]
로컬 `qmd query` 1위	51/55 92.7%[82.7, 97.1]	26/55 47.3%[34.7, 60.2]
`qmd query` 상위 40개에 표적 포함	55/55	55/55
Jev 끝단	55/55	45/55 81.8%[69.7, 89.8]
지연	`qmd query` 질의당 중앙 19.1초	`qmd query` 질의당 중앙 33.3초, Jev 호출 p50 521ms

읽기한국어 질문에서 Jev 재선택은 로컬 qmd query 1위도 앞섰습니다(b1/c20, p < 0.0001). qmd query는 상위 40개에 모든 표적을 담아 후보 생성기로는 넓지만 1위 선택기로는 약했고, 영어 질의에서도 놓친 4단위 중 3단위는 형제 페이지가 1위였습니다.r1의 한국어 후보 목록은 qmd의 FTS5 색인이 한글을 음절 단위로 저장해 다음절 BM25 질의가 0건을 내는 바람에 벡터 상위 10개와 같았습니다(52단위 중 1단위만 BM25 결과). r2에서 인접 음절 구문 질의로 바꾸자 후보 재현율 46/55 → 50/55, 목록 1위 21/55 → 30/55가 됐고, 새로 회수된 4단위는 Jev가 모두 맞혔습니다.

유지 집합(keep-set) 필터

Jev Noul에 후보마다 "이 질의가 찾는 노트인가"를 한 요청으로 묻고, 값이 절단점보다 큰 후보만 남깁니다. 목표는 표적을 지키면서 LLM 컨텍스트에 넣을 후보를 줄이는 것입니다. 한국어 질문 결과입니다.

절단점	라운드와 역할	표적 유지 (표적이 목록 안)	평균 유지 수 (평균 후보)	축소율
0.5	r1 design, 등록 규칙	20/21 95.2%[77.3, 99.2]	1.58 (10.3)	84.3%
0.5	r1 threshold, 등록 규칙	24/25 96.0%[80.5, 99.3]	1.18 (10.0)	88.2%
0.5	r2 threshold, 적합에 사용	24/25 96.0%[80.5, 99.3]	보고 안 함	보고 안 함
0.5	r2 final	43/50 86.0%[73.8, 93.1]	1.95 (17.55)	88.9%
0.3	r2 final, final을 본 뒤 계산	49/50 98.0%[89.5, 99.6]	3.82 (17.55)	보고 안 함
0.3	r3, 등록 전 고정 (주 조건)	44/45 97.8%[88.4, 99.6]	2.39 (17.55)	86.4%
0.5	r3, 보조	39/45 86.7%[73.8, 93.7]	1.10 (17.55)	93.7%
목록 상위 2개 (크기 맞춤)	r2 final	39/50 78.0%[64.8, 87.2]	2	없음
목록 상위 3개 (크기 맞춤)	r3	25/45 55.6%[41.2, 69.1]	3	없음

읽기threshold 25단위에서 고른 0.5는 final 50단위로 옮겨지지 않았고(24/25 → 43/50), final을 본 뒤 보인 0.3은 등록 전에 고정한 새 표본에서 다시 나왔습니다(44/45). 후보별 Noul은 크기가 같은 순위 절단보다 표적을 훨씬 많이 지켰습니다(r3 44/45 대 25/45).유지율 0.95는 점 추정으로만 충족하며(Wilson 하한 88.4%), 떨어진 표적 1건은 noul이 정확히 0.30이라 엄격 규칙으로 빠졌습니다(r3에서 0.30과 같은 답은 7개).

찾는 노트가 목록에 없을 때와 대체 경로

표적이 후보 목록 밖이면 '해당 없음'이 정답입니다.

라운드	표적이 목록 밖인 단위에서 '해당 없음'	표적이 목록 안인데 '해당 없음'	빈 유지 집합
r1 (design + threshold)	3/6 50.0%[18.8, 81.2]	0/98	보고 안 함
r2 final	0/5 0.0%[0.0, 43.4]	qko 1/50desc 0/55	절단 0.5에서qko 4/55
r3 처음 쓰는 위키 표적	0/4 0.0%[0.0, 49.0]	0/45	절단 0.3에서 2/490.5에서 9/49

읽기표적이 없을 때 Jev는 기권하지 않고 관련된 다른 페이지를 골랐습니다. r3의 한 단위에서는 Jev 응답의 자체 choice 필드가 '해당 없음'이었지만 확률 1위는 다른 후보였고(0.31 대 0.30), 등록 규칙(argmax)대로 틀린 선택으로 셌습니다. choice 필드를 썼다면 r3 부재 기권은 1/4였습니다.이 파이프라인은 아직 "찾는 노트가 없다"를 말하지 못하므로, 서비스에서는 fail-open으로 설계했습니다: Jev가 보류하거나 호출이 실패하거나 유지 집합이 비면, 코드가 만든 후보 목록을 그대로 돌려줍니다.

CMDS 87 서브카테고리 라우팅

노트 하나를 87개 서브카테고리 + '보류' 중 하나로 보냅니다. 정답은 기존 CMDS: 값입니다.

조건	r1 design (91)	r1 threshold (100)	r2 final (120)	r3 처음 쓰는 폴더 (65)
Jev 이름만 87	41/91 45.1%[35.2, 55.3]	23/100 23.0%[15.8, 32.1]	24/120 20.0%[13.8, 28.0]	미실행
Jev 이름 + 정의 87	45/91 49.5%[39.4, 59.5]	17/100 17.0%[10.9, 25.6]	91/120 75.8%[67.5, 82.6]	28/65 43.1%[31.8, 55.2]
Jev 코드 압축 목록 + 정의	상위 12개 36/91 39.6%[30.1, 49.8]	상위 12개 14/100 14.0%[8.5, 22.1]	상위 20개 42/120 35.0%[27.1, 43.9]	미실행
다수 클래스 (104)	5/91 5.5%	55/100 55.0%	66/120 55.0%[46.1, 63.6]	0/65 0.0%[0.0, 5.6]
노트 유형 규칙표	40/91 44.0%규칙을 만든 표본	89/100 89.0%규칙을 만든 표본	101/120 84.2%[76.6, 89.6]	1/65 1.5%[0.3, 8.2]
BM25 1위	18/91 19.8%	10/100 10.0%[5.5, 17.4]	10/120 8.3%[4.6, 14.7]	13/65 20.0%[12.1, 31.3]
Jev top-3 제안 적중 (보류 제외)	측정 방식 다름	측정 방식 다름	112/120 93.3%[87.4, 96.6]	42/65 64.6%[52.5, 75.1]

정의 조건의 내용은 라운드마다 다릅니다. r1은 87개 중 14개 클래스에 설명이 없어 머리글 대체문이 정의로 들어갔고, r2와 r3는 그 14개를 한 줄 정의 초안으로 채우고 "형식이 분명하면 주제보다 형식 카테고리를 먼저 보라"는 문장을 더했습니다. r2와 r3의 정의 조건은 payload 구성이 같습니다.
분할마다 정답 구성이 다릅니다. r1 design은 220 Personal Insights 중심, r1 threshold와 r2 final은 104 Terminologies와 802 Articles가 대부분(r2 final 120건 중 93건), r3는 문서, 자산, 산출물 폴더의 18개 클래스이고 104는 0건입니다.
2026-09-24 사전 실험(이름만 87, payload와 결정 규칙이 다름)은 56/109 51.4% [42.1, 60.6], 같은 91건으로 좁히면 43/91 47.3% [37.3, 57.4]였습니다.

읽기r1 threshold에서 정의를 준 조건이 오히려 낮았던 것은 정답 100건 중 84건이 대체문 정의 클래스였기 때문입니다(경쟁 클래스는 풍부한 정의, 정답 클래스는 빈 정의). r2에서 빈 정의를 채우고 형식 우선 문장을 더하자 이름만 대비 b6/c73으로 올랐고(802 Articles 0/27 → 26/27, 104 Terminologies 9/66 → 54/66), 두 변경이 함께 바뀌어 기여는 가를 수 없습니다.같은 payload가 처음 쓰는 폴더에서는 28/65였고, r2에서도 설명이 있는 클래스 19건은 7/19 36.8% [19.1, 59.0]였습니다. 주제와 도구 클래스에서 Jev는 두 라운드 모두 40% 안팎이고, r2의 75.8%(91/120)는 형식 클래스가 끌어올린 값입니다.

코드 압축 목록은 목록 안에서는 선택을 해치지 않았습니다(r1 상위 12개 안에서 정의 87개 조건과 같은 36/62, 14/29, r2 상위 20개 안에서 42/55 76.4% [63.7, 85.6]). 손실은 목록 재현율에서 났고(r2 상위 20개 재현율 55/120 45.8% [37.2, 54.7]), 802 Articles 27건은 한 번도 목록에 들지 못했습니다.

r3에서 검증한 규칙표 캐스케이드는 아래와 같습니다(65건).

조건	정확도	보류	답한 것 중 정확도
규칙표만 (적용 27건)	1/27 3.7%[0.7, 18.3]	규칙 없는 38건	1/27
캐스케이드 (규칙, 없으면 두 순서 합의)	20/65 30.8%[20.9, 42.8]	6/65	20/59 33.9%[23.1, 46.6]
Jev 정순 단독	28/65 43.1%[31.8, 55.2]	1/65	28/64 43.8%[32.3, 55.9]
Jev 역순 단독	30/65 46.2%[34.6, 58.2]	1/65	30/64 46.9%[35.2, 58.9]
Jev 두 순서 합의	27/65 41.5%[30.4, 53.7]	10/65 15.4%[8.6, 26.1]	27/55 49.1%[36.4, 61.9]

읽기r2의 규칙표는 처음 쓰는 폴더로 옮겨지지 않았습니다. 27건에 적용돼 1건만 맞혔고(note → 220 행이 note 26건에서 모두 틀림, 같은 26건에서 Jev는 7건), 캐스케이드는 Jev 단독보다 낮았습니다(b0/c8, p 0.0078).두 순서 합의는 답한 노트의 정확도를 43.8%(28/64)에서 49.1%(27/55)로 올렸지만 구간이 크게 겹치고, 자동 오답 36 → 28, 사람 대기 1 → 10, 정답 28 → 27로 사람 시간과 맞바꾼 결과입니다.

87분류에서 confidence 0.7 이상 구간의 정확도는 r2 58/69 84.1% [73.7, 90.9], r3 16/33 48.5% [32.5, 64.8]입니다. 자동 승인 게이트로 쓰지 않습니다.
순서 뒤집힘은 09-24 이름만 87개 29/109 26.6% [19.2, 35.6], r2 압축 20개 15/120 12.5% [7.7, 19.6], r3 정의가 붙은 87개 10/65 15.4% [8.6, 26.1]입니다.
620 Generative AI는 정의 초안을 받고도 두 라운드 모두 한 건도 맞히지 못했습니다(r2 0/3, r3 0/8). r3에서 Jev는 620 정답 6건을 842 Course Development and Resources로, 주제와 도구 클래스 8건을 907 Product & Engineering Division으로 보냈습니다. 어느 라벨이 맞는지는 판정하지 않았습니다.

프로젝트 라우팅 (README 한 줄)

노트를 활성 프로젝트 6개 + '보류' 중 하나로 보냅니다. 이름만(D1)과 이름 + README description 200자(D2)를 비교했습니다.

조건	r1 design (30)	r1 threshold (30)	r2 final (80)	호출당 입력 (r2)
이름만	27/30 90.0%[74.4, 96.5]	29/30 96.7%[83.3, 99.4]	69/80 86.3%[77.0, 92.2]	1,239 tokens
이름 + README 요약	30/30 100%[88.6, 100]	30/30 100%[88.6, 100]	78/80 97.5%[91.3, 99.3]	1,573 tokens
이름 + README, 역순	30/30	30/30	79/80 98.8%[93.3, 99.8]	1,573 tokens
순서 뒤집힘 (README 포함)	0/30	0/30	1/80 1.3%[0.2, 6.8]	없음

읽기README 한 줄이 이름만일 때의 오류 11건을 2건으로 줄였습니다(r2 b1/c10, p 0.012). 이름만일 때의 오류 대부분은 이름만으로는 구분되지 않는 다른 프로젝트로 노트가 끌려간 경우였고, 비용 차는 호출당 +334 tokens(1,000건당 약 $0.066)라 모호할 때만 올리는 단계 없이 처음부터 README를 씁니다.과제는 포화 상태입니다. 여섯 프로젝트는 서로 뚜렷이 다르고 저위험 기준으로 골랐으며(다수 클래스 참고치 30/80 37.5%), 인접 프로젝트 사이 혼동과 어디에도 속하지 않는 노트의 보류는 재지 않았습니다.

메인 대 위키 라우팅

노트가 메인 볼트(본인 해석과 1인칭 맥락)에 속하는지 위키 볼트(LLM이 컴파일한 레퍼런스)에 속하는지, 그리고 위키 안에서 폴더 4종(Concept, Entity, Guide, Question) 중 어디인지를 골랐습니다.

조건	r1 design	r1 threshold	r2 final
메인 대 위키	32/40 80.0%[65.2, 89.5]	30/40 75.0%[59.8, 85.8]	51/80 63.8%[52.8, 73.4]
메인 대 위키, 역순	28/40 70.0%[54.6, 81.9]	29/40 72.5%[57.2, 83.9]	48/80 60.0%[49.1, 70.0]
순서 뒤집힘	4/40 10.0%[4.0, 23.1]	5/40 12.5%[5.5, 26.1]	7/80 8.8%[4.3, 17.0]
위키 폴더 4종	20/20 100%[83.9, 100]	20/20 100%[83.9, 100]	39/40 97.5%[87.1, 99.6]
위키 폴더, 역순	20/20	20/20	38/40 95.0%[83.5, 98.6]

읽기메인 대 위키는 세 분할과 두 순서에 걸쳐 60~80%에 머뭅니다(정순 32/40, 30/40, 51/80, 역순 28/40, 29/40, 48/80). r2 final 오류는 두 방향이 같은 크기였고(위키 → 메인 11, 메인 → 위키 11, 보류 7), 도구 사용법 같은 레퍼런스형 메인 노트가 높은 확신으로 위키로 가고 위키의 연구 질문 페이지가 메인으로 가는 모양이었습니다.두 순서의 결정이 갈린 7건을 첫 사람 판정 대기열로 두었고 아직 판정 전이라, 이 불일치가 모델 오류인지 옮길 만한 노트인지는 모릅니다.

confidence 0.7 이상 구간은 r1 두 분할 합산 40/42 95.2% [84.2, 98.7]에서 r2 final 37/43 86.0% [72.7, 93.4]로 약해졌습니다. 확신 구간 자동 승인 후보라는 r1의 서술은 철회했고, 메인 대 위키는 서비스 명령으로 만들지 않았습니다.
위키 폴더 분류는 포화에 가깝습니다. r2 final에서 처음으로 Concept 정답의 오류가 나왔습니다(정순 1건, 역순 2건).

Totals합계: 호출, 토큰, 비용, 오류, 모델 핀

비용은 프로토콜의 과금식대로 입력 토큰 × $0.042/1M으로 계산했습니다. 출력 토큰은 이 과금식 밖이라 참고로만 적습니다.

라운드 (2026-09-26 KST)	호출 (HTTP 200)	입력 tokens	$ (입력 × $0.042/1M)	사전 추정 대비 실측	출력 tokens (참고)	지연 p50/p95
r1 (등록 03:22, 스모크 1 포함)	1,557	3,269,848	0.1373	80.6%추정 4,055,259	590,863	510/840 ms
r2 (등록 04:51)	1,726	3,974,285	0.1669	95.3%추정 4,170,389	653,249	542/863 ms
r3 (등록 06:34)	277	1,020,437	0.0429	99.4%추정 1,026,297	188,393	668/1,041 ms
합계	3,560	8,264,570	0.3471	89.3%추정 9,251,945	1,432,505	없음

오류

3,560회 모두 HTTP 200, 재시도 0, 제외 0, 전송 직전 검사에서 차단 0입니다. 확률 동률로 보류한 답은 r1 3건, r2 6건, r3 1건입니다.

모델 핀

요청과 응답 모두 jev-1.13.0이고 일치율 100%(3,560/3,560)입니다. 응답 모델이 다르면 그 행을 제외하는 규칙이었고, 제외는 0건입니다.

상한

전역 상한 15,000,000 tokens의 55.1%를 썼고 잔여는 6,735,430입니다. r3는 라운드 상한 2,500,000의 40.8%를 썼습니다.

Jev 밖

한국어 질문 생성용 GPT-6 Luna 일괄 호출 2회(r1 입력 9,203, 출력 4,871 tokens, r3 입력 3,705, 출력 2,676 tokens)는 별도 경로로 과금돼 Jev 원장 밖입니다. 로컬 qmd는 토큰을 쓰지 않습니다.

사흘 전체2026-09-24~26

2026-09-24 섀도 사전 실험 341호출(736,861 tokens)과 스모크 1호출(603 tokens), 2026-09-26 서비스 CLI 통합 스모크와 실행 17호출(54,734 tokens)을 더하면 Jev 호출은 3,919회, 9,056,768 tokens, $0.3804입니다.

단위 비용

용도 (r3 호출당 입력 기준)	호출당 입력	1,000건당
87분류	5,761 tokens	약 $0.242
검색 재선택	1,716 tokens	약 $0.072
유지 집합	2,108 tokens	약 $0.089
프로젝트 라우팅 (r2 README 조건)	1,573 tokens	약 $0.066

노트 10,000건을 87분류로 한 번 돌리면 약 $2.4, 역순 재질문까지 하면 약 $4.8입니다. 이 규모에서 토큰 비용은 병목이 아닙니다. 사람의 검토 시간은 아직 재지 않았습니다.

Claims주장할 수 있는 것과 없는 것

모든 항목은 조건마다 한 번 실행, 모델 jev-1.13.0 하나, 기존 메타데이터 재현 기준이라는 한정을 공유합니다.

Can claim주장할 수 있는 것

한국어 질문 검색에서 Jev 후보 재선택은 세 라운드 네 표본 모두 후보 목록 1위를 앞섰습니다. r3 처음 쓰는 위키 표적에서 44/49 89.8% [78.2, 95.6] 대 16/49 32.7%이고, 표적이 목록 안인 단위에서 b1/c29입니다.
같은 과제에서 로컬 qmd query 1위보다도 높았습니다(r2 final 45/55 대 26/55, b1/c20, p < 0.0001). qmd query는 질의당 중앙 33.3초, Jev 호출은 p50 521ms였습니다.
검색 끝단은 후보 재현율 × 조건부 선택으로 정확히 나뉘고, 조건부 선택이 네 표본 모두 90% 이상이라 남은 손실은 후보층에 있습니다.
음절 구문 BM25가 한국어 후보 재현율을 46/55에서 50/55로, 목록 1위를 21/55에서 30/55로 올렸습니다(r2 final).
후보별 Noul 절단 0.3은 등록 전에 고정한 값으로 새 표본의 표적 44/45 97.8% [88.4, 99.6]를 평균 2.39개 안에 남기며 후보를 평균 17.55개에서 86.4% 줄였습니다. 크기를 맞춘 목록 상위 3개는 25/45였습니다.
영구 노트와 문헌 노트 폴더에서 노트 유형 규칙표는 모든 Jev 조건 이상으로 CMDS:를 재현했고(101/120), 그 규칙표는 문서, 자산, 산출물 폴더로 옮겨지지 않았습니다(적용 27건 중 1건).
빈 정의를 채우고 형식 우선 문장을 더하면 87분류 재현이 크게 오릅니다(r2 final 이름만 24/120 → 91/120, b6/c73). 주제와 도구 클래스에서 Jev는 두 라운드 모두 40% 안팎입니다(r2 7/19, r3 28/65).
87분류는 top-3 제안으로 쓸 때 더 많이 담깁니다(r2 112/120, r3 42/65). confidence 0.7 이상 구간도 r3에서 16/33이라 자동 승인하지 않습니다.
README 요약 한 줄이 프로젝트 라우팅을 78/80으로 올렸고(이름만 69/80), 위키 폴더 분류는 r2 final 39/40, 역순 38/40으로 95% 이상입니다. 메인 대 위키는 세 분할과 두 순서에서 60~80%(r2 final 51/80)에 머뭅니다.
세 라운드 3,560호출이 입력 8,264,570 tokens, $0.3471로 끝났고, 이탈은 모두 등록 파일에 기록했습니다.

Cannot claim주장할 수 없는 것

사람 판단 대비 정확도, 검토 시간 절감. 사람 골드가 0건입니다. 620 → 842 같은 불일치, 검색의 형제 페이지, 메인 대 위키 대기열 7건은 볼트 드리프트나 다른 타당한 라벨일 수 있습니다. 검토에 드는 시간은 잰 적이 없습니다.
결정성과 안정성. 한 모델 버전, 하루, 조건당 한 번 실행이고 같은 payload를 반복한 적이 없습니다. 응답 모델이 바뀌면 모든 컷과 규칙을 새로 등록해야 합니다.
캐스케이드라는 생각 자체의 실패. r3에서 시험된 규칙은 note → 220과 manuscript → 802 1건뿐입니다. r2 이득을 만든 고비율 규칙(terminology 58/64 90.6%, literature-note 8/8 100%)은 적용될 새 노트가 없어 시험되지 않았습니다.
정의와 형식 우선 문장의 개별 기여. r2에서 둘이 함께 바뀌었고 둘 다 r1 결과를 본 뒤 만들었습니다.
정의 초안 14개가 CMDS 정책이라는 것. 실험 당시 정책으로 확정하기 전 초안이었습니다.
절단 0.3의 0.95 유지율. 점 추정으로만 충족합니다(Wilson 하한 88.4%). 표적 1건이 경계값에 정확히 걸렸습니다.
운영 임계값. r2 게이트와 절단점은 시연용 제안값입니다. r2 게이트는 약한 BM25 1위 기준선에 맞춰 적합해 격자 380점이 전부 통과했습니다.
"찾는 노트가 없다"를 말하는 능력. 표적 부재 단위가 r2 5개, r3 4개뿐이고 기권은 0/5, 0/4였습니다.
메인 볼트 검색 성능. r3 표적은 모두 위키 페이지였습니다. 메인 볼트에는 한 번도 쓰지 않은 적격 표적이 남지 않아, 메인 검색은 등록 뒤 새로 생기는 노트로만 다시 잴 수 있습니다.
실제 사용자 질의에서의 성능. 한국어 질문은 한 모델이 description을 보고 만든 것입니다.
라운드 간 인과. 항목과 클래스 구성이 달라 라운드 간 짝 검정이 없습니다. 같은 항목 비교는 한 라운드 안에서만 했습니다.
09-24 수치와 09-26 수치의 직접 비교. payload, 결정 규칙, 표본이 다릅니다. 같은 91건에서도 두 날짜의 이름만 조건 결정이 13/91 달랐습니다.
이 볼트와 이 표본 밖으로의 일반화. r2 final 분류의 78%(93/120)가 두 형식 클래스였고, 프로젝트 라우팅은 뚜렷이 다른 6개 프로젝트였습니다.

Lessons사고에서 얻은 일반 교훈

세 라운드를 돌리며 실제로 겪은 사고에서 나온 규칙입니다.

개인정보

개인정보 필터는 조립이 끝난 payload에, 샘플링 전에 겁니다.

질문 생성 같은 보조 생성 호출도 포함합니다. 노트 필드 몇 개만 보는 필터는 본문 머리나 후보 요약에 섞인 정보를 놓칩니다.

사전 검증

사전 검증이 남긴 미결 항목은 경고가 아니라 실행 차단이어야 합니다.

경고만 남기면 다음 명령이 그대로 시작됩니다.

예산 원장

동시에 도는 프로세스가 각자 원장을 파일에 덮어쓰면 마지막 기록자만 남습니다.

r1 원장에는 1,906,450 tokens, 775호출만 남았고 호출 기록은 3,269,848 tokens, 1,557호출이었습니다(상한 초과는 없었음). r2부터 파일 잠금 원장을 쓰고 호출 기록과 대조했습니다. 과소 집계된 원장은 지우지 않고 보존했습니다.

한국어 검색

한국어 전문 검색은 조용히 0건을 낼 수 있습니다.

색인이 한글을 음절 단위로 저장하면 다음절 질의가 결과 없이 끝납니다. 호출 전에 BM25 목록이 비지 않았는지 확인하고, 색인을 고치지 않는 우회라면 우회라는 점을 결과에 표시합니다.

컷

작은 분할에서 고른 컷은 옮겨지지 않을 수 있습니다.

0.5는 threshold 24/25에서 final 43/50으로 떨어졌습니다. 컷은 그 과제의 분할에서만 고르고, 다른 과제로 옮기지 않습니다.

규칙표

규칙표는 그 폴더와 노트 유형 분포의 산출물입니다.

같은 규칙표가 101/120에서 1/27이 됐습니다. 폴더별로 정밀도를 확인한 행만 씁니다.

결정 규칙

결정 규칙과 경계 규칙은 등록 전에 코드로 정합니다.

모델의 자체 choice 필드와 확률 argmax가 갈린 단위가 있었고, 절단점과 정확히 같은 값(0.30)이 r3에서 7번 나왔습니다. 엄격 부등호(>)인지 이상(≥)인지를 미리 정하지 않으면 사후에 결과를 고르게 됩니다.

기권

기권을 믿지 말고 fail-open으로 설계합니다.

표적 부재 시 기권이 0/5, 0/4였습니다. 보류나 실패일 때 원래 목록을 그대로 보여 주는 것이 안전한 기본값입니다.

재계산

분석은 저장된 원자료에서 다시 계산해 대조합니다.

r3 통합본은 확률에서 결정을 다시 계산해 하네스와 결정 불일치 0, 지표 불일치 0을 확인했습니다. 분석 코드는 추가만 하고 기존 줄은 고치지 않았습니다.

Reproduce개념적으로 재현하는 법

아래 순서는 어떤 볼트에서도 같습니다. 코드 저장소는 비공개이고, 여기서는 절차와 설계만 적습니다.

정답이 이미 있는 과제를 고릅니다.

기존 분류 값, 폴더 위치, 프로젝트 소속처럼 볼트에 이미 기록된 판단을 정답으로 삼으면 사람 라벨 없이 "기존 판단의 재현"을 잴 수 있습니다. 결과도 그 이름으로만 읽습니다.

표본을 고정하고 세 분할로 나눕니다.

design으로 조건을 다듬고, threshold에서 컷을 한 번 고르고, final은 봉인했다가 한 번만 엽니다. 개인과 제3자 정보가 담길 수 있는 폴더와 유형은 이 단계에서 뺍니다.

호출 전에 프로토콜을 등록합니다.

조건, 지표, 결정 규칙, 분석 계산, 예측 방향을 적고, 프로토콜과 코드와 자료의 해시를 기록합니다. 해시가 다르면 실행과 분석이 멈추게 합니다.

코드 기준선부터 돌립니다.

다수 클래스, 메타데이터 규칙표, BM25 1위, 후보 목록 1위, 로컬 검색 엔진 1위를 같은 항목에 붙입니다.

payload를 만들고 조립된 상태에서 검사합니다.

정답을 누설하는 필드(경로, 유형, 기존 값)는 빼고, 선택지에는 정의를 붙이고, '보류'나 '해당 없음'은 마지막에 둡니다. 조립이 끝난 payload 전체에 개인정보 규칙을 겁니다.

Jev를 두 순서로 부릅니다.

선택은 Choice로 정순과 역순을 한 번씩, 유지 집합은 후보마다 Noul을 한 요청으로 묻습니다.

결정은 코드가 합니다.

확률 argmax, 동률은 보류, 절단은 엄격 부등호입니다. 모델의 자체 선택 필드는 쓰지 않습니다.

사후 가설은 새 표본에서 검증합니다.

final을 본 뒤 떠오른 규칙이나 컷은 앞 라운드가 쓴 노트를 모두 뺀 표본에서, 적합 없이 한 번 적용합니다.

분석은 분모와 구간과 짝 비교로 합니다.

모든 비율에 Wilson 95% 구간, 같은 항목 비교에는 b와 c와 부호검정을 씁니다. 검색은 끝단을 후보 재현율과 조건부 선택으로 나누고, 분류는 클래스별 재현율을 함께 봅니다.

예산과 영수증을 남깁니다.

보내기 전에 예약하고 실측으로 정산하는 잠금 원장, 호출당 한 줄의 영수증, 저장된 확률에서 다시 계산하는 대조 분석을 둡니다.

측정 결과를 옮긴 서비스 설계

측정 결과는 jev-cmds CLI의 세 명령으로 옮겼습니다. 명령의 입출력 규약과 운영 장치는 시스템 페이지에 따로 적었습니다.

retrieve

음절 구문 BM25 상위 10개와 벡터 상위 10개를 RRF로 합친 후보에서 Jev가 고르고 역순으로 한 번 더 묻습니다. 두 순서가 갈리거나 동률이면 보류입니다. 이어서 Noul 유지 집합을 절단 0.3(엄격)으로 남기고, 비면 후보 목록이 답입니다.

classify

87 서브카테고리 top-3 제안을 보여 줍니다. 정의와 형식 우선 문장을 쓰고, 자동 적용은 하지 않습니다. 노트 유형 규칙층은 두지 않았습니다.

project

허용 목록의 활성 프로젝트와 README description으로 라우팅을 제안합니다.

공통

모델 jev-1.13.0 고정(응답 모델이 다르면 버림), 조립 payload 개인정보 검사, 월 입력 20,000,000 tokens 상한, 키가 없거나 API 오류, 예산 초과면 제안 없이 정상 종료하는 fail-open, 볼트 쓰기 0, 실행마다 한 줄씩 남기는 섀도 로그(사람 판정 칸은 비워 두고 나중에 채움)입니다.

검증

네트워크 없이 가짜 전송 계층과 가짜 검색 엔진으로 도는 단위 테스트 90개가 통과합니다. 2026-09-26 통합 스모크에서 실호출 14회가 모두 HTTP 200이었고, 두 볼트에서 바뀐 파일은 0건이었습니다.