Jev로 지식관리의
판단을 설계하다
구요한 / CMDSPACE
기록을 분류하고, 질문에 맞는 자료를 찾고, 사람이 확정하기까지.
Jev를 붙여 본 실험과 도구, 아직 맡기지 않을 판단을 함께 살펴봅니다.
2026-09-28 / 연구와 구현 사례Source
도구보다 먼저
맡길 판단을 정한다
반복되는 선택을 작은 질문으로 바꾸고, 후보를 구분할 기준과 사람이 결정할 경계를 설계합니다.
01질문 하나무엇을 반복해서 고르는가
02기준 하나어떤 관찰로 후보를 구분하는가
03경계 하나어디서 멈추고 사람이 확정하는가
01
글을 쓰는 AI와
고르는 AI
Jev는 문장을 이어 쓰기보다 주어진 정보와 선택지에서 판단값을 돌려줍니다.
무엇을 보게 하고 무엇을 물을지는 외부 코드와 사람이 정합니다.
같은 글에도
다른 질문을 던진다
예/아니오, 후보 선택, 기준 단계는 서로 다른 질문입니다.
반환된 확률과 점수가 정답이나 실행 허가를 보장하지는 않습니다.
01Noul그런가? / 이 후보가 찾는 노트인가
02Choice어느 것인가? / 어느 프로젝트인가
03Score어느 단계인가? / 어떤 기준 단계인가
값과 분포는 판단 제안이지 정답 인증이 아니다TypeSafe API
질문이 판단을 바꾼다
예시: 검색 개선을 계획했지만 아직 실험하지 않은 글.
실험 여부, 문서 역할, 발전 단계를 각각 물으면 서로 다른 판단이 됩니다.
물어볼 질문
- 실험 결과를 보고하는가?
- 계획 / 보고 / 용어 중 무엇인가?
- 메모 / 주장 / 근거 중 어디인가?
질문별로 다른 것
- 사실 신호: Noul
- 역할 선택: Choice
- 정해 둔 단계: Score
실제 API 출력이 아닌 질문 설계 예시TypeSafe API
좋은 선택은
좋은 질문에서 시작한다
‘연구, 교육, 개발’처럼 이름만 주지 말고 각 후보의 포함 조건을 적습니다.
근거가 부족하거나 후보가 겹칠 때는 보류하도록 설계합니다.
01상태판단할 정보만 제공한다
02후보정답이 들어갈 공간을 만든다
03기준이름이 아니라 포함 조건을 쓴다
04보류없거나 애매하면 되돌린다
판단과 실행을 가른다
검색은 후보를 모으고, Jev는 고를 대상을 제안합니다.
원문 설명과 실제 저장, 이동, 발행은 별도의 생성 모델과 실행 주체가 맡습니다.
Jev 자체가 검색하거나 파일을 이동하는 것은 아니다Jev × CMDS
지식의 네 단계에
작은 판단을 놓는다
CMDS는 연결→통합→적용→공유의 지식 생애주기입니다.
Jev를 새 단계로 추가하지 않고 각 단계에서 반복되는 선택을 보조하게 합니다.
01Connect입력의 분류 후보
02Merge지금 읽을 지식 후보
03Develop프로젝트와 담당 후보
04Share주장과 근거의 관계
단계별 제안 가능성을 보여주는 설계 지도Source
같은 노트, 다른 질문
분류는 지식의 성격, 폴더는 보관 위치, 프로젝트는 쓰임새, 담당은 실행 책임입니다.
따라서 한 종류의 분류 성능을 다른 종류의 정확도로 옮길 수 없습니다.
지식의 의미
- CMDS: 어떤 성격인가
- type: 어떤 문서인가
- 단계: 어디까지 발전했나
운영의 맥락
- 폴더: 어디에 보관하나
- 프로젝트: 어디에 쓰나
- 담당: 누가 처리하나
87분류 성능을 폴더나 9부문 성능으로 옮기지 않는다Jev × CMDS
02
좋은 숫자를
더 어려운 시험에 넣었다
처음의 좋은 결과가 실제 업무에서도 유지되는지 확인했습니다.
질문 생성 방식, 새 폴더, 저비용 대안을 바꾸어 비교하자 적용 범위가 좁아졌습니다.
무엇과 비교했는가
같은 찾기형 질문 54개에서 표적 노트를 고른 횟수입니다.
보류, 오류, 표적이 후보 밖인 경우도 실패로 셌고, 사람 정답 검증은 아직입니다.
| 방법 | 적중 | 해석 |
|---|---|---|
| 같은 풀 첫 결과 | 28 / 54 | 비교 기준 |
| Jev 제안 | 37 / 54 | 68.5% |
| qmd query 첫 결과 | 34 / 54 | 우위 미입증 |
| Flash 선택 | 43 / 54 | Jev보다 높음 |
r4 / 사람 골드 전 / 같은 풀 대비 조건부 GOJev × CMDS
89.8%에서 멈추지 않았다
r3는 세 번째, r4는 네 번째 실험입니다. 44/49는 ‘49개 질문 중 44개 적중’입니다.
r4는 질문과 정답 설명문이 닮아 생기는 편향을 줄이도록, 다른 본문 구간에서 질문을 만들었습니다.
r3: 44 / 49
- 설명문에서 질문을 생성
- Jev도 그 설명문을 읽음
- 순환 편향을 의심해야 함
r4: 37 / 54
- 다른 본문 구간에서 질문 생성
- 운영 경로와 대조군 추가
- 표본, 조건도 달라짐
하락 전체를 편향 하나의 인과효과로 보지 않는다Jev × CMDS
정의를 채우되 다시 잰다
기존 노트의 CMDS 라벨을 같은 답으로 재현한 수입니다.
같은 r2 표본에서는 개선됐지만, r3의 새 폴더에서는 결과가 그대로 유지되지 않았습니다.
| 조건 | 재현 | 평가 범위 |
|---|---|---|
| 이름만 | 24 / 120 | r2 |
| 정의+형식 우선 | 91 / 120 | r2 같은 표본 |
| Jev 단독 | 28 / 65 | r3 새 폴더 |
| 규칙표 | 1 / 27 | 새 폴더 부분집합 |
개선 조건은 정의와 지시를 함께 바꿨다Jev × CMDS
서랍 이름보다 목적을 쓴다
새 글을 어느 프로젝트에 연결할지 같은 80건으로 비교했습니다.
이름에 짧은 목적 설명을 더하자 기존 연결과 다른 결과가 11건에서 2건으로 줄었습니다.
프로젝트 이름만
- 69 / 80 재현
- 오류 11건
- 이름으로 용도를 추정
README 설명 추가
- 78 / 80 재현
- 오류 2건
- 짧은 목적 설명을 후보에 제공
r2 프로젝트 선택 / 담당 9부문 정확도가 아니다Jev × CMDS
잘 고르는 것과
잘 모르는 것은 다르다
답이 후보에 없음을 알아차리는 일과 여러 근거를 함께 남기는 일은 별도 능력입니다.
STOP은 아래 시험 조건의 적용 중단이지 Jev의 모든 용도를 중단한다는 뜻이 아닙니다.
01부재: STOP해당 없음 10/30, 확신 오답 14/30
02합성: STOP근거 재현율 0.583, 12건, 컷 0.3
039부문: 미측정프로젝트 선택 성능을 전이하지 않는다
r4 조건별 판정 / 자동 실행 승인 아님Jev × CMDS
싸졌다는 것만으로 충분한가
A=Jev 선택, B=qmd 상위 8개, D=검색 순서를 A와 같은 분량으로 자른 맥락입니다.
찾기 54+합성 12건을 두 모델이 채점했으며, A 대 B는 채점 1건이 빠졌습니다.
같은 분량 A 대 D
- 23승 / 40무 / 3패
- 선택 맥락의 가치, 조건부
- D의 문서 절단 방식은 한계
상위 8개 A 대 B
- 14승 / 30무 / 21패
- 품질 유지 입증 못함
- 실험 비용 약 41% 감소
합성 STOP 적용 후 운영 정책의 품질, 비용은 미측정Jev × CMDS
확률의 정밀함을
신뢰의 크기로 읽지 않는다
confidence는 모델의 확신 신호입니다. 실제 정답률과 어떤 관계인지 과제별로 확인해야 합니다.
순서를 바꿔도 같은 답이 나온다는 사실만으로 정답임이 증명되지는 않습니다.
- 과제마다confidence와 실제 정답률을 따로 보정한다.
- 보류도 비용사람 검토 시간과 처리량을 함께 센다.
- 순서 일치안정성 신호이지 정답의 증명은 아니다.
03
판단을 제품의
접점에 연결했다
실험을 CLI 명령, 웹 분류기, 판단 기록, 작업 화면으로 연결했습니다.
기능이 구현됐다는 사실과 그 판단이 업무에서 유효하다는 증거는 구분합니다.
도구들은 서로 다른 일을 한다
명령은 제안을 만들고, 화면은 검토를 돕고, 기록은 사람의 수정을 남깁니다.
여섯 칸은 연결 지점의 역할 구분이며 모두 같은 성능을 갖는 제품 목록이 아닙니다.
01CLI검색, 분류, 프로젝트 제안
02분류기글에서 필드 후보 보기
03영수증 뷰어판단과 비용 돌아보기
04컨트롤 룸작업, 담당, 검색에 제안
05명령 통합query와 connect의 보조 단계
06label / review사람 결정과 수정 이유
구현 존재와 판단 효과 검증을 구분한다Source
검색한 다음 다시 고른다
어휘, 벡터 검색으로 만든 후보를 Choice로 다시 고르고, Noul로 남길 목록을 제안합니다.
답이 처음부터 후보에 없으면 재선택만으로는 복구할 수 없습니다.
01후보 수집어휘 검색과 벡터 검색
02제안Choice 정순, 역순 비교
03남기기Noul로 후보 유지 제안
04원문 확인읽고 답한 뒤 사람이 확정
보류, 오류 시 원래 검색 결과 유지Source
화면의 제안은 실행이 아니다
글에서 분류와 문서 속성(frontmatter) 후보를 보여주고 YAML로 복사할 수 있습니다.
외부 API 전송은 일어날 수 있지만 실제 볼트 적용과 발행 승인은 사용자의 별도 결정입니다.
화면에 있는 것
- 메인 / 위키 두 모드
- 분류와 필드 후보
- 복사 가능한 YAML
자동으로 하지 않는 것
- 볼트 파일 저장
- 이동, 병합, 삭제
- 발행 또는 전송 권한 승인
글은 외부 API로 전송될 수 있다Source
영수증은 정답 증명서가 아니다
입력과 기준, 모델 버전, 결과와 비용을 돌아볼 수 있는 판단 로그입니다.
해시는 같은 기록인지 대조하는 지문일 뿐 내용이 참이라는 인증은 아닙니다.
01입력과 기준무엇을 보고 판단했나
02제안과 보류무엇을 골랐고 왜 멈췄나
03비용과 버전어떤 호출을 재현할 수 있나
해시 일치는 판단의 참, 거짓을 인증하지 않는다Source
사람이 바꾼 이유를 남긴다
Jev의 안, 실행 에이전트의 안, 사람의 최종 선택을 분리해 기록합니다.
명시적인 선택, 수정과 아무 말 없이 지나간 결과를 같은 정답 데이터로 세지 않습니다.
01Jev최초 제안
02에이전트실행 모델의 안
03사람최종 선택과 수정 이유
기록만으로 Jev가 자동 재학습하는 것은 아니다Jev × CMDS
새 앱보다 기존 흐름 안으로
작업을 만드는 순간에는 담당 후보를, 검색하는 순간에는 재선택 배지를 보여줍니다.
제안은 거절하거나 바꿀 수 있고, 담당 부문은 자동 배정하지 않습니다.
작업을 만들 때
- 담당 부문 후보 제안
- 제목과 요청문으로 필드 제안
- 자동 배정하지 않음
지식을 찾을 때
- 검색 재선택 배지
- 원래 결과로 돌아갈 수 있음
- 선택과 영수증을 남김
9부문 route는 measured:false / 내부 통합 사례Source
한 번의 입력,
여러 개의 질문
‘검색 개선 계획이며 아직 실험 결과는 없다’는 공개 합성문을 사용합니다.
문서 역할과 분류 제안을 비교한 뒤, 결과 복사와 실제 저장이 다르다는 점을 확인합니다.
- 합성 입력“검색 개선 계획이며 아직 실험 결과는 없다.”
- 관찰문서 역할과 분류 제안은 어떻게 다른가?
- 확정결과를 복사하는 것과 실제 저장은 다르다.
실제 응답을 미리 꾸며 둔 시연이 아니다Source
제안은 정답도
실행 허가도 아니다
판단기가 실패해도 원래 검색은 계속할 수 있어야 합니다.
반대로 전송 권한이나 개인정보 검사에서 실패했다면 그 데이터는 보내지 않아야 합니다.
- 업무 실패원래 검색과 수동 작업으로 복귀한다.
- 전송 권한 실패민감 자료를 보내지 않는다.
- 공개 전노트, 로그, 화면의 노출 범위를 다시 본다.
04
앱 이름보다
판단의 위치를 본다
공식 예제, 공개 코드, 제작팀의 실험 보고는 서로 다른 증거입니다.
입력, 판단, 행동이 어디서 나뉘는지 배우되 성능 향상을 독립 검증한 사례로 소개하지 않습니다.
존재와 의미를 나눈다
코드는 인용문이 원문에 있는지 찾고, Choice는 그 근거가 주장을 지지, 반박, 무관한지 제안합니다.
문장이 존재하는 것과 내 주장을 뒷받침하는 것은 다른 질문입니다.
01코드인용문이 원문에 있는가
02Choice지지 / 반박 / 무관인가
03사람내 주장에 사용할 수 있는가
공식 예제 / 범용 사실 검증기는 아니다Source
검색 엔진 앞뒤의 판단
Jev가 웹 전체를 직접 검색하는 것이 아닙니다. 실제 결과는 Search1API가 가져옵니다.
Jev는 검색 전의 조건 선택과 검색 후 제목, 요약의 관련성 판단을 맡습니다.
01검색 전Choice로 시간, 검색어 후보
02검색Search1API가 결과 수집
03검색 후Noul로 제목, 요약 관련성
공개 코드 확인 / 품질 향상 독립 실측 아님Source
비슷한 이름이 같은 대상인가
서로 다른 카탈로그에서 같은 대상을 가리키는 레코드인지 비교하는 공식 예제입니다.
비교할 쌍을 찾는 일, 동일성을 판단하는 일, 실제 데이터를 합치는 일은 구분합니다.
01후보 쌍외부 코드가 비교 대상을 준비
02Score + Noul동일성, 부분 일치 판단
03실행 경계사람 검토 후 별도 병합
공식 예제는 실제 그래프 병합을 수행하지 않는다Source
작은 판단을 넣는 세 위치
SQL은 데이터 질의, moderation은 입력 정책, UX는 사용자 경험의 판단 접점입니다.
각 사례의 오류 시 동작, 전송 권한, 호출 빈도까지 함께 보아야 합니다.
| 사례 | 판단 위치 | 증거 수준 |
|---|---|---|
| pg-jev | SQL의 의미 조건 | 공개 구현 |
| Mastra moderation | 사용자 입력 정책 | 공개 코드 |
| elvex UX | 입력 중 작은 제안 | alpha 보고 |
elvex는 제작팀 글에서 비프로덕션임을 명시pg-jev · Mastra Jev · elvex
05
더 많은 호출보다
맡길 수 있는 판단
다음 목표는 호출이나 기능 수를 늘리는 것이 아니라 실제로 맡길 조건을 확인하는 것입니다.
사람이 납득할 정답과 비교 기준, 운영 비용을 먼저 정합니다.
다음 실험은 세 가지를 닫는다
사람에게도 답이 되는지, 더 싼 대안보다 나은지, 전체 일이 줄어드는지를 확인합니다.
API 금액이 작아도 검토 시간과 운영 복잡성이 커지면 도입 가치는 달라집니다.
01사람 정답실제로 답이 되는 노트인가
02가장 싼 대안같은 후보와 보류 규칙으로 비교
03전체 비용품질, 지연, 검토 시간까지 측정
사람 골드 전 / PROPOSE 유지Jev × CMDS
개발된 기능과 계획을 가른다
글쓰기, 작업 환경, 근거 심사로 넓힐 수 있지만 아직 확장 구상입니다.
일부 보조 코드가 있다는 이유로 전체 경험의 구현이나 효과 검증이 끝났다고 말하지 않습니다.
01라이브 글쓰기관련 지식을 옆에 제안
02워크스페이스허용 메타로 작업 후보
03근거 심사제공한 증거의 관계 판단
04노트 위생중복, 상충 후보 제안
05창작 보조이벤트 상태로 피드백
06운영 보강공유 예산, 사람 라벨
확장 구상 / 전송 승인과 과제별 검증 필요Jev × CMDS
다음 미팅에서 정할 네 가지
기술을 고르기 전에 성공의 의미와 책임을 합의합니다.
외부 API에 보내도 되는 자료와 웹, 강의에서 공개해도 되는 자료의 범위도 따로 정합니다.
01성공 기준어떤 행동이 나아져야 하나
02사람 검토누가 언제 판정할 것인가
03영구 금지무엇은 자동화하지 않나
04공개 범위전송과 발행을 어떻게 가르나
내 업무의 판단 카드 한 장
반복해서 고르는 일 하나를 적고 후보, 포함 조건, 멈출 조건, 확정 주체를 채웁니다.
Jev 없이 하던 기존 방법도 비교 기준으로 남겨야 도입 효과를 판단할 수 있습니다.
01입력과 후보반복해서 고르는 것 하나
02기준과 보류포함 조건과 멈출 조건
03실행과 기록확정 주체와 수정 이유
2분 활동 / private 자료를 업로드하지 않는다Jev × CMDS
지식, 기준, 결정이
연결되어 있는가
특정 찾기 과제에서 후보 재선택의 가치는 보았지만 사람 검증과 일반화는 남았습니다.
내 지식과 기준을 연결하되, 실행 권한과 틀렸을 때 돌아갈 길을 함께 설계합니다.
- 확인한 것일부 찾기 과제에서 후보 재선택의 가치.
- 남은 것사람 검증, 일반화, 전체 운영 비용.
- 다음 행동판단 하나와 남길 권한 하나를 정한다.
조건부 결과와 아직 맡기지 않을 일을 함께 기억한다Jev × CMDS
판단 하나를 설계하고
직접 비교해 보세요
강의자료에서 세 언어 본문과 출처를 다시 살펴보고, 자신의 판단 카드 한 장으로 시작하세요.
HTML은 내려받아 오프라인에서 볼 수 있으며 외부 링크를 열 때는 인터넷이 필요합니다.
jev.cmdspace.work/lecture강의자료 / 한국어, English, 日本語
https://jev.cmdspace.work/lecture/
https://jev.cmdspace.work/lecture/
cmdspace.workCMDSPACE의 작업과 도구
https://cmdspace.work
https://cmdspace.work
bio.cmdspace.work구요한 / Yohan Koo
https://bio.cmdspace.work
https://bio.cmdspace.work
지식의 구조가 다음 행동을 만든다.
