Jev는 처음 보는 선택지를 호출할 때마다 받아 판단한다. 별도 학습 데이터 없이 환불 문의, 코드 변경 위험, 검색 결과 관련도를 바로 물을 수 있다는 것이 장점이다. 반대로 의료, 법률, 사내 코드 규칙처럼 일반 언어만으로 알기 어려운 기준에서는 그 장점이 약점이 된다. 현재 공개 API에는 사용자가 자기 데이터로 Jev를 미세조정하는 기능도 없다.
그렇다면 도메인 성능을 높일 방법은 프롬프트를 길게 쓰는 것뿐일까. 이 글의 결론은 다르다. 모델 하나에 전문성을 모두 넣으려 하지 말고, 도메인 지식 검색, 결정적인 검사, 의미 판단, 정책, 학습을 서로 다른 구성요소가 맡게 해야 한다.
이 글은 Jev가 이미 도메인 업무에서 높은 정확도를 냈다는 보고가 아니다. 직접 API를 측정한 3편과 네 가지 활용 사례를 만든 4편에서 확인한 실패를 바탕으로, 도메인 데이터를 모으기 시작할 때 적용할 설계를 정리한 것이다.
범용 판단과 도메인 판단은 필요한 정보가 다르다
“이 문장은 화가 난 고객의 말인가”는 일반적인 언어 이해로도 어느 정도 답할 수 있다. “이 문의는 우리 회사의 환불 정책 4.2항에 따라 자동 승인해도 되는가”는 다르다. 모델이 정책의 현재 버전, 이미 환불한 금액, 예외 상품, 승인 권한까지 알아야 한다.
이 차이를 모델의 지능 부족으로만 보면 프롬프트에 문서를 계속 붙이게 된다. 하지만 도메인 판단에는 세 종류의 정보가 섞여 있다.
| 정보 | 예시 | 맡을 구성요소 |
|---|---|---|
| 계산 가능한 사실 | 결제액, 환불 합계, 테스트 종료 코드 | 코드와 데이터베이스 |
| 현재 업무 기준 | 환불 정책, 저장소 규칙, 심사 기준 | 버전이 붙은 문서 검색 |
| 의미 판단 | 고객이 환불을 요구하는가, 테스트가 변경 동작을 다루는가 | Jev 같은 판단 모델 |
3편의 환불 실험에서 Jev는 전액 환불된 주문을 다시 승인하기도 했다. 결제액과 기존 환불액을 코드로 계산해 remaining_refundable_amount: 0을 넘기자 전체 36건을 맞혔다. 도메인 전문성을 높인 것은 모델을 다시 학습시킨 일이 아니라, 의미 판단 전에 확정할 수 있는 사실을 확정한 일이었다.
전체 매뉴얼 대신 필요한 규칙만 검색한다
사내 정책이나 코드 규칙 전체를 매번 state에 넣으면 세 문제가 생긴다. 요청이 커지고, 오래된 조항과 새 조항이 충돌할 수 있으며, 관련 없는 문맥이 판단을 흔든다. 공식 Jev 1.13 약점 문서도 무관한 정보와 충돌하는 지시를 취약점으로 든다.
먼저 현재 판단과 관련된 규칙을 찾고, 그 조항만 증거와 함께 넘기는 편이 낫다. 코딩 에이전트의 완료 보고를 검사한다면 state는 다음 정도면 된다.
{
"claim": "인증 변경에 필요한 테스트를 추가했고 모두 통과했다.",
"changed_files": ["src/auth.ts", "tests/auth.unit.ts"],
"commands": [{"command": "npm test -- auth.unit", "exit_code": 0}],
"retrieved_rules": [
{
"id": "AUTH-04",
"version": "2026-09-01",
"text": "인증 동작 변경에는 통합 테스트와 보안 검토가 필요하다."
}
]
}검색 결과에는 규칙 ID와 버전을 남겨야 한다. 그래야 오판이 났을 때 모델이 규칙을 잘못 적용했는지, 검색기가 잘못된 조항을 가져왔는지 구분할 수 있다. 검색이 실패하면 Jev가 상식으로 빈칸을 채우게 두지 않고 사람에게 보내야 한다.
복합 판단을 한 번에 묻지 않는다
작업이 제대로 완료됐는가?라는 질문 하나에는 요구사항 이해, 코드 변경 확인, 테스트 범위 평가, 실행 결과 확인, 보고의 정직성까지 들어 있다. 답이 틀려도 어느 단계에서 틀렸는지 알 수 없다.
관찰 가능한 질문으로 나누면 책임이 선명해진다.
코드가 확인
- 완료 보고에 적힌 테스트 명령이 실제 기록에 있는가
- 종료 코드는 0인가
- 사용자가 요구한 파일이 수정됐는가
Jev가 판단
- 실행한 테스트가 변경된 동작을 다루는가
- 완료 주장과 diff가 의미상 일치하는가
- 구현되지 않은 요구사항이 남아 있는가
정책 코드가 결정
- 자동 통과, 경고, 재작업, 사람 검토 중 어디로 보낼 것인가가능하면 넓은 Score 하나보다 좁은 Noul 여러 개를 먼저 시험할 이유도 생겼다. 3,600개 문항을 사용한 한 독립 평가는 질문 형식별 보정 오차를 Noul 0.012, Choice 0.086, Score 0.254로 보고했다. 표본과 과제가 서로 완전히 같지 않은 비교도 포함되므로 이 숫자를 일반 법칙으로 읽을 수는 없다. 다만 같은 600개 감성 문항에서도 예·아니오 질문의 오차가 5단계 Score보다 작았다. 도메인별 평가를 시작할 때 질문 형식을 별도로 비교해야 할 근거는 된다.
도메인의 답 공간은 애플리케이션이 정의한다
모델에 “문제가 무엇인지 설명하라”고 시키는 대신 업무에서 처리할 수 있는 상태를 먼저 정의한다. 완료 증거 검사라면 다음처럼 만들 수 있다.
verified 증거가 주장을 뒷받침한다
partial 일부만 뒷받침한다
unsupported 확인할 증거가 없다
contradicted 증거가 주장과 모순된다
not_applicable 이 주장에 적용할 검사가 아니다
needs_review 기준이나 증거가 불충분하다실패 이유는 별도 코드로 관리한다.
TEST_NOT_RUN
WRONG_TEST_SCOPE
MISSING_REQUIREMENT
CLAIM_DIFF_MISMATCH
UNVERIFIED_EXTERNAL_EFFECTJev는 후보 중 하나를 고르고 확률을 돌려준다. contradicted를 차단할지, partial을 재작업으로 보낼지, 보안 변경을 무조건 사람이 볼지는 호스트 코드가 결정한다. 공식 confidence-gated routing 패턴도 판단과 정책을 이처럼 분리한다.
이 구조에는 다른 이점도 있다. 새로운 실패 유형이 나타나면 모델을 다시 학습시키기 전에 답 공간, 규칙 검색, 결정 코드를 고칠 수 있다. 반대로 분류 체계를 자주 바꾸면 과거 데이터와 새 결과를 비교하기 어려워지므로 버전을 붙여야 한다.
하나의 confidence 임계값을 공유하지 않는다
Jev의 confidence는 업무 정확도를 보장하지 않는다. 2편에서 응답을 역산한 결과 Choice와 Score의 confidence는 가장 높은 확률을 선택지 수에 맞춰 다시 조정한 값이었다. 별도로 학습된 안전도 점수가 아니다.
따라서 0.8 이상이면 자동 처리 같은 전역 규칙을 두면 안 된다. 오류 비용과 질문의 보정 상태에 따라 문턱을 따로 잡는다.
| 판단 | 가능한 정책 |
|---|---|
| 문서 주제 분류 | 높은 확률이면 자동 태그, 나머지는 미분류 |
| 테스트 범위 충족 | 높은 확률에서만 통과, 나머지는 검토 |
| 권한·보안 변경 | 확률과 무관하게 사람 검토 |
| 실행 여부와 종료 코드 | 모델을 쓰지 않고 기록으로 확정 |
라벨이 붙은 실제 사례에서 임계값별 오탐, 미탐, 자동 처리율, 사람 검토량을 함께 재야 한다. 잘못 통과시킨 한 건의 비용이 잘못 경고한 열 건보다 크다면 정확도가 같아도 임계값은 달라진다.
모델에 질문을 추가하거나 규칙 문서를 바꾸면 보정도 다시 확인한다. 질문 문구와 검색 문서가 달라진 뒤에도 이전 임계값이 유지된다고 가정할 근거는 없다.
사람의 수정은 다음 모델의 학습 데이터가 된다
도메인 업무를 Jev로 시작하는 가장 큰 이유는 학습 데이터가 없어도 첫 버전을 만들 수 있기 때문이다. 그러나 같은 업무를 계속 처리하면 사람의 수정과 실제 결과가 쌓인다. 이 데이터를 버리면 Jev를 영구적으로 호출하면서도 도메인 성능은 제자리다.
판정마다 다음 기록을 남길 수 있다.
{
"question_version": "completion-v3",
"policy_version": "repo-policy-2026-09-01",
"jev_answer": "verified",
"jev_probability": 0.74,
"human_answer": "partial",
"final_outcome": "reopened",
"failure_code": "WRONG_TEST_SCOPE"
}이 기록은 세 단계로 사용한다.
- 반복되는 오판을 보고 state와 질문을 고친다.
- 질문별 confidence 임계값을 다시 맞춘다.
- 표본이 충분해지면 작은 도메인 전용 분류기를 학습한다.
세 번째 단계에서 Jev와 전용 모델을 승자 하나로 정할 필요는 없다. 규칙으로 확정되는 사례는 코드가, 반복되는 익숙한 사례는 전용 모델이, 새 유형이나 분포가 바뀐 사례는 Jev가 맡을 수 있다. 두 모델이 다르거나 고위험이면 사람에게 보낸다.
결정적 규칙 ── 확정 가능 ──→ 코드가 처리
│
└─ 의미 판단 필요 ──→ 전용 모델
│
├─ 익숙하고 확신 높음 → 처리
└─ 새 유형·불일치 ──→ Jev ──→ 사람고정된 라벨과 충분한 데이터가 생기면 전용 분류기가 더 싸고 정확할 수 있다. 검색 업체 Parallel의 Jev 평가는 검색 재정렬에서는 Jev가 사내 전용 모델 하나와 비슷한 NDCG@10을 냈지만, 주제 분류와 최신성 판정에서는 전용 모델보다 못했다고 보고했다. 업무에 따라 결과가 갈렸고 Jev의 문서당 비용도 자체 인프라에서 돌리는 모델보다 높았다. 범용 API의 빠른 시작과 전용 모델의 장기 최적화가 서로 다른 단계에 맞는다는 사례다.
전환 시점을 같은 데이터로 결정한다
전용 모델을 학습했다고 바로 Jev를 빼서는 안 된다. 같은 보류 데이터에서 네 구성을 비교한다.
| 구성 | 확인할 질문 |
|---|---|
| Jev만 사용 | 데이터 없이 시작할 때 기준선은 무엇인가 |
| Jev + confidence 보류 | 낮은 확률을 사람에게 보내면 오류가 얼마나 줄어드는가 |
| 전용 모델 | 반복 업무에서 비용과 정확도가 나아지는가 |
| 전용 모델 + Jev 불일치 검토 | 분포 변화와 새 유형을 더 잘 잡는가 |
채택 기준에는 정확도뿐 아니라 호출 비용, 지연, 사람 검토량, 고위험 미탐, 운영 복잡도를 포함한다. 전용 모델의 정확도가 조금 높아도 매주 다시 학습해야 하고 분포 변화를 찾지 못한다면 전환 비용이 더 클 수 있다. 반대로 라벨이 안정적이고 호출량이 많다면 외부 API를 계속 쓰는 편이 비효율적이다.
다음 글에서는 이 전환을 실제 데이터로 시험한다. Jev가 만든 초기 라벨, 사람이 수정한 라벨, 작은 로컬 분류기를 같은 보류 세트에서 비교하고, 어느 시점에 Jev 호출을 줄일 수 있는지 측정할 예정이다.
정리
Jev의 도메인 성능을 높이는 방법은 긴 프롬프트 하나가 아니다. 현재 규칙을 검색해 좁혀 넣고, 코드로 확정할 사실을 먼저 계산하고, 복합 업무를 관찰 가능한 의미 판단으로 나눠야 한다. 실제 사례로 질문별 임계값을 맞추고 사람의 수정을 데이터로 남기는 일도 필요하다.
이 과정이 충분히 진행되면 목표는 Jev를 더 많이 호출하는 것이 아닐 수 있다. 반복되는 업무는 전용 모델과 규칙으로 옮기고, Jev는 데이터가 없는 새 판단과 분포 변화에 남는다. 범용 판단 모델의 역할은 도메인 모델을 대체하는 것이 아니라, 도메인 모델을 만들기 전의 빈 구간을 줄이는 데 있다.