생성형 AI를 덜 쓰는 게 더 빠르다: Kev로 로컬 판단 워크플로 만들기
고객 문의 하나에 LLM이 긴 답변부터 쓰고 있다면, 순서가 뒤집힌 거야
“이 티켓은 어느 팀으로 보내지?”, “사람이 바로 봐야 하나?”, “긴급도는 몇 점이지?” 같은 질문은 대부분 답의 모양이 정해져 있어. 그런데 우리는 이 세 가지를 묻기 위해 생성형 모델에게 긴 문장을 쓰게 하고, JSON을 다시 파싱하고, 선택지가 맞는지 검증한다. 답변을 잘 쓰는 능력과 선택을 정확히 하는 능력을 한 모델·한 호출에 몰아넣는 셈이야.
이번 주 GitHub 트렌드 수집에서 jaredpalmer/kev가 빠르게 커지는 저장소로 포착됐어. 이 글은 그 신호를 그대로 옮기는 뉴스가 아니야. 내가 저장소의 README와 평가 문서를 읽고, 당신의 업무에서 생성이 필요 없는 판단을 어디까지 떼어낼 수 있는지 다시 설계해본 기록이야.
문제는 모델이 작아서가 아니라, 생성이 필요 없는 단계까지 생성하고 있다는 데 있어. 라우팅과 우선순위 판단은 문장 창작이 아니라 허용된 후보 중 하나를 고르는 일이다. 이 앞단을 분리하면 비용과 지연시간뿐 아니라, 틀렸을 때 어디서 멈출지도 설계할 수 있어.
Kev는 “더 잘 쓰는 LLM”이 아니라, 같은 입력에 여러 개의 타입이 있는 결정을 반복해서 계산하는 작은 로컬 엔진이야.
이 글에서 바로 가져갈 워크플로
| 단계 | 생성형 LLM만 쓸 때 | Kev를 앞단에 둘 때 |
|---|---|---|
| 입력 이해 | 답변 문장을 생성 | 하나의 state를 여러 결정이 공유 |
| 분류 | 문장에서 라벨을 다시 추출 | choice의 후보·확률을 받음 |
| 우선순위 | 숫자를 문장에 요구 | score의 등급·분포를 받음 |
| 안전 분기 | 출력 형식 검증에 의존 | noul 확률과 임계값으로 사람에게 넘김 |
| 최종 행동 | 모델이 바로 실행할 위험 | 결정 로그와 승인 단계를 거쳐 다음 도구 호출 |
핵심은 “Kev가 모든 답을 대신한다”가 아니야. Kev가 잘하는 좁은 결정을 앞에 배치하고, 검색·정책 확인·답변 작성·외부 상태 변경은 뒤 단계로 남기는 거야. 독자가 얻는 이득은 AI를 하나 더 추가하는 데서 나오지 않고, 업무 흐름을 판단 → 검증 → 실행으로 나누는 데서 나와.
외부 정보: Kev는 문장을 생성하는 대신 typed decision을 한 번에 계산한다
jaredpalmer/kev의 README에 따르면 Kev는 Qwen3.5 위에 만든 작은 Jev-like decision model 계열이야. 0.8B, 4B, 9B 모델과 학습 코드·평가 데이터를 공개하고, TypeSafe의 System One API와 호환되는 로컬 서버를 제공해. 따라서 기존 SDK를 버리는 대신 base_url을 로컬 Kev 서버로 가리키는 방식으로 실험할 수 있어.
한 요청 안에서 같은 state를 읽고 서로 다른 타입의 질문을 함께 던질 수 있어. noul은 예·아니오의 확률, choice는 후보별 확률과 가장 가능성 높은 선택, score는 순서가 있는 등급의 기대 점수와 분포를 반환해. 질문끼리는 서로의 답을 읽지 않도록 설계돼 있어 한 질문의 선택이 다른 질문의 근거를 오염시키는 일을 줄인다.
curl -s localhost:8009/v1/systemone \
-H 'content-type: application/json' \
-d '{
"state": "배송이 늦었고 다른 상품이 왔어. 카드에는 두 번 결제됐어.",
"model": "kev-latest",
"questions": {
"team": {"type": "choice", "instructions": "어느 팀이 처리해야 해?",
"criteria": {"returns": "교환·환불·오배송", "shipping": "배송 지연·분실", "billing": "결제·청구 문제"}},
"escalate": {"type": "noul", "instructions": "사람의 즉시 확인이 필요해?"},
"urgency": {"type": "score", "instructions": "긴급도는?",
"criteria": ["일반", "이번 주", "오늘"]}
}
}'이 구조에서 중요한 건 JSON 모양이 예쁘다는 사실이 아니야. 결과 후보를 호출 전에 고정할 수 있다는 점이야. team은 사전에 정한 세 팀 안에서만 움직이고, urgency는 임의의 73점이 아니라 세 등급 중 어디에 가까운지로 남아. 그래서 다음 시스템은 자연어를 다시 해석하지 않고도 분기할 수 있어.
근거는 확률과 평가 데이터에 있고, 숫자는 범위를 좁혀 읽어야 해
README가 공개한 새 출처 테스트에서 Kev-9B는 정확도 0.852, Brier score 0.237을 기록했고, Kev-4B는 각각 0.837과 0.255를 기록했어. Brier score는 낮을수록 확률 보정이 좋다는 지표야. 다만 이 값은 프로젝트가 정한 평가 세트의 결과이고, Jev와 학습 데이터가 같지 않아 통제된 우열 비교가 아니라고 README도 명시해. 숫자를 “우리 고객 문의도 85.2% 맞힌다”로 번역하면 안 돼.
로컬 실행의 현실적인 장단점도 공개돼 있어. Python 3.12+와 uv로 서버를 띄울 수 있고 CUDA, ROCm, Apple Silicon을 지원해. README의 Apple M5 측정에서는 약 230토큰 입력에 질문 5개를 묶은 Kev-4B의 모델 시간이 bf16 중앙값 779ms였어. 같은 조건의 이전 Qwen3 세대는 174ms였고, Qwen3.5는 현재 Mac에서 더 느릴 수 있다는 뜻이야. “로컬이니까 무조건 빠르다”가 아니라, 데이터가 밖으로 나가지 않는 경계와 운영 지연시간을 함께 선택해야 해.
반대로 반복 입력이 많고 결과 후보가 좁다면 한 번 읽은 state를 여러 질문에 재사용하는 구조가 이득이 돼. Kev는 LoRA adapter와 작은 pointer head를 Qwen base 위에 얹고, 선택지의 종료 위치를 점수화해 확률로 바꿔. 긴 답변을 생성하는 대신, 시스템이 검증할 수 있는 결과를 계산하는 접근이야.
상호작용 기반 판단: 도입은 ‘답변 생성’이 아니라 ‘다음 행동 선택’부터
이번 글을 쓰면서 Kev를 내 Mac에 설치해 개인 티켓으로 측정하지는 않았어. 그래서 아래는 사용 후기나 자체 벤치마크가 아니야. 저장소의 API·평가·서빙 문서를 검토한 뒤, 내가 실제 자동화에 적용한다면 지킬 경계를 작업 관점에서 정리한 제안이야.
- 첫 주에는 읽기 전용 분류만 한다. 티켓 state를 넣고 팀, 긴급도, 사람 검토 여부만 계산해. 환불·삭제·권한 변경·외부 발송은 호출하지 않는다.
- 확률보다 중단 규칙을 먼저 정한다. 최고 후보와 두 번째 후보의 차이가 작거나
escalate확률이 높으면 자동 라우팅하지 않고 사람 큐로 보낸다. - 결정과 실제 정답을 같이 기록한다. 모델의 choice, 확률, 질문 버전, 사람이 고친 라벨을 저장해야 다음 평가 세트를 만들 수 있다.
- 그 다음에만 도구를 연결한다. 안정된
billing분류가 확인된 뒤 정책 문서 검색이나 답변 초안 생성을 연결한다. 실행 권한은 별도 승인으로 남긴다.
이 순서가 중요한 이유는 모델을 믿기 위해서가 아니야. 틀린 판단이 생겨도 손실이 작은 위치에서 관찰하고, 네 업무의 질문 정의가 맞는지 먼저 검증하기 위해서야. “긴급도”라는 이름을 붙였지만 실제로는 답변 대기시간을 뜻하는지, 매출 손실을 뜻하는지 모호하다면 모델이 아니라 질문 설계가 먼저 실패한 거니까.
Kev를 선택하지 않아도 남는 설계 원칙
모든 팀이 지금 당장 4B·9B 모델을 운영할 필요는 없어. Apple Silicon에서 낮은 지연시간이 최우선이면 README가 안내하는 Qwen3 이전 세대를 비교 대상으로 삼을 수 있고, 정확도와 보정이 메모리보다 중요하면 9B를 검토할 수 있어. 반대로 네 문제에 라벨이 충분하지 않거나 선택지 자체가 자주 바뀐다면, 작은 decision model보다 사람이 먼저 분류 기준을 정리하는 편이 낫다.
그래도 한 가지는 남아. 생성형 AI를 도입할 때 먼저 “무엇을 써야 하지?”가 아니라 “무엇을 고르면 되지?”를 물어야 해. 답이 정해진 라우팅·등급·조건 확인은 typed decision으로 좁히고, 설명·검색·최종 문장처럼 맥락이 필요한 곳에만 생성형 모델을 쓰면 워크플로가 덜 흔들려. 비용 절감보다 더 큰 이득은 실패 지점을 눈으로 볼 수 있다는 거야.
CTA: 오늘 반복되는 문의 20개를 골라서 질문을 세 개로 다시 써봐. “담당 팀은?”, “사람 확인이 필요한가?”, “긴급도는?”처럼 choice·noul·score로 나눌 수 있다면, Kev Quick Start대로 로컬 서버를 띄우고 읽기 전용 라우팅부터 측정해봐. 정확도 하나만 보지 말고, 사람이 개입해야 했던 케이스와 확률이 애매했던 케이스까지 기록하면 네 업무에 도입할 이유가 숫자로 남아.
SEO 키워드: Kev, typed decision, Qwen3.5, 로컬 AI, 고객 문의 라우팅, 확률 기반 분류
#해시태그: #Kev #Qwen35 #TypedDecision #로컬AI #AI도구 #고객문의자동화 #워크플로자동화 #확률기반분류 #개인정보보호
근거 출처
외부 정보 (하베스터 수집)
- jaredpalmer, Kev GitHub 저장소 README. Qwen3.5 기반 모델 계열, 0.8B·4B·9B 구성, typed decision 타입, API 예시, 로컬 서빙, 평가 수치, Apple Silicon 성능, 아키텍처 설명의 근거.
- jaredpalmer, Kev 연구 로그 PLAN.md. Qwen3.5 포트와 평가·실험 맥락을 확인하기 위한 보조 출처.
- jaredpalmer, Kev LICENSE. Apache-2.0 라이선스 확인.
- 트렌드 하베스터 스냅샷(2026-09-22)의
github:jaredpalmer/kev항목. fast_growing 섹션, 별 2,746개, topics(decision-model·jev·qwen3)라는 raw signal은 글감 선정을 위한 편집 신호로만 사용했다. 이 신호는 제품 성능의 근거나 게시 승인으로 해석하지 않았다.
상호작용 (에이전트-드루 대화·작업)
이번 작업에서는 Kev 저장소와 README를 읽고, 생성이 필요 없는 라우팅·긴급도·조건 확인을 앞단의 typed decision으로 분리하자는 편집적 판단을 정리했다. Kev를 개인 데이터에 설치하거나 자체 정확도·지연시간을 측정한 경험은 없으므로, 본문에 사용 후기나 자체 통계로 쓰지 않았다. 실제 도입 전에는 네 데이터로 별도 홀드아웃 평가와 사람 검토 규칙을 만들어야 한다.
외부 트렌드 raw signal은 editorial review용 수집 신호일 뿐이야. 외부 사실은 위 출처에서 확인한 내용으로, 상호작용 기반 제안은 별도 경험 섹션으로 구분했어.