Jev AI — Confidence Gate 설계와 도입 전에 따져볼 것들 (3/3)

틀리는 것보다 무서운 건 "얼마나 확신하는지 모르는 것"

자동화에서 진짜 어려운 부분은 AI가 가끔 틀린다는 사실 자체가 아니다. 더 큰 문제는, 틀렸을 때도 모델이 "저는 확실합니다"라는 얼굴을 하고 있다는 거다. 정확도가 95%인 모델이라도 모든 응답에 confidence 0.99를 찍어버리면, 그 수치는 아무 의미가 없다. 자동화 여부를 confidence 기준으로 나누는 구조 자체가 무너진다.

Jev가 강조하는 지점이 여기다. 단순히 라벨 하나(spam)를 뱉는 게 아니라, 그 판단이 실제 정확도와 맞아떨어지는 확률(spam: 0.91)까지 같이 내놓는 것, 즉 Calibration을 모델의 핵심 가치로 내세운다.

Confidence Gate를 코드로 그려보면

이 아이디어를 내 방식대로 의사코드로 옮겨보면 이렇다.

decision = jev.classify(comment)

if decision.confidence > 0.95:
    auto_apply(decision.label)          # 바로 처리
elif decision.confidence > 0.70:
    escalate_to_llm(comment)            # 큰 모델로 재검토
else:
    queue_for_human_review(comment)     # 사람에게 넘김

중요한 건 0.95, 0.70이라는 숫자 자체가 아니다. 이 기준은 Jev가 정해주는 공식 값이 아니라, 서비스 성격과 오판 비용에 따라 직접 정해야 하는 운영 정책이다. 노가리처럼 잘못 걸러도 댓글 하나가 신고 큐에 더 들어가는 정도의 서비스와, 결제 승인처럼 오판 비용이 큰 서비스가 같은 문턱값을 쓸 이유는 없다.

그리고 Noul처럼 여러 개의 독립 판단을 쓰는 구조라면, 하나의 최종 confidence만 보는 대신 판단마다 서로 다른 문턱값을 둘 수 있다. "개인정보 포함 0.97"은 바로 가리고, "스팸 의심 0.4"는 그냥 흘려보내는 식이다.

"Zero Hallucination"이라는 말은 나눠서 봐야 한다

TypeSafe는 Jev를 소개하면서 "Zero Hallucinations"라는 강한 표현을 쓴다. 이 말을 그대로 받아들이기보다는 두 가지로 나눠 보는 게 맞다고 생각한다.

없는 걸 지어내는 할루시네이션 — 존재하지 않는 API, 없는 필드 이름을 만들어내는 것. Jev는 애초에 자유 문자열을 생성하지 않고 정해진 타입 중에서 고르기 때문에, 이 종류는 구조적으로 거의 발생하지 않는다.
판단 자체가 틀리는 것 — 실제로는 스팸이 아닌데 스팸으로 분류하는 것. 이건 출력 형식과 무관하게 여전히 일어날 수 있다.

즉 "형식이 틀릴 가능성"은 구조로 막았지만 "판단이 틀릴 가능성"은 여전히 남아있다. 그래서 Confidence Calibration이 양보할 수 없는 핵심이 된다 — 형식은 안전해도 판단이 틀릴 수 있다면, 최소한 "이 판단이 얼마나 못 미더운지"는 정확히 알아야 자동화 여부를 정할 수 있으니까.

속도·비용 수치는 일단 의심하고 보는 게 맞다

TypeSafe가 공개한 수치는 꽤 공격적이다.

항목	공개 수치
End-to-end 응답 시간	약 70 ~ 500ms
가격	입력 토큰 100만 개당 $0.042 (출력 토큰 별도 과금 없음)
자체 워크플로우 평가 기준 속도	최대 193.6배
자체 워크플로우 평가 기준 비용	최대 444.6배 절감

숫자만 보면 혹할 만하다. 다만 이 수치는 TypeSafe 자체 벤치마크이고, 그들이 Jev에 가장 유리하게 설계한 워크플로우 위에서 나온 결과라는 점은 감안해야 한다. "Jev가 GPT보다 193배 빠르다"로 일반화하기보다는, "판단 중심 워크플로우에서는 큰 생성 모델 대비 상당한 이점이 날 가능성이 있다" 정도로 받아들이는 게 맞다고 본다.

지금 당장 바꾸기 전에 확인할 것

Jev는 아직 Early Access 단계다. 내 프로젝트에 도입을 검토한다면 적어도 이 정도는 직접 확인하고 싶다.

실제 트래픽에서의 레이턴시 — 공식 수치와 내 워크로드는 다를 수 있다
도메인별 정확도 — 노가리 댓글, 매치다 공고처럼 내 데이터로 직접 재봐야 한다
Confidence가 실제 정확도와 맞는지 — calibration 주장을 내 데이터로 검증
API 안정성과 장기 신뢰성 — Early Access 단계라 변경 가능성이 있다
가격 정책의 지속 가능성 — 초기 가격이 그대로 유지될지는 별개 문제

체크리스트를 하나씩 뜯어보면

위 다섯 항목 중에서 가장 먼저 걸리는 건 2번, 도메인별 정확도다. TypeSafe가 공개한 벤치마크는 그들이 고른 평가 데이터셋 기준이지, 노가리에 실제로 달리는 한국어 댓글이나 매치다에 들어오는 실제 채용공고 문장과는 분포가 다를 수밖에 없다. 분류 모델은 학습 데이터와 실제 서비스 데이터의 분포가 어긋나는 순간 정확도가 생각보다 크게 떨어지는 경우가 많다. 그래서 공식 수치를 그대로 믿기보다, 내가 가진 실제 댓글 샘플 몇백 개 정도를 따로 떼어 직접 돌려보고 confidence와 실제 정답이 얼마나 잘 맞는지 확인하는 과정이 꼭 필요하다고 본다.

4번(API 안정성)도 가볍게 넘길 부분은 아니다. Early Access 단계의 API는 스키마나 가격 정책이 바뀔 가능성이 일반 GA 제품보다 높다. 노가리나 매치다처럼 이미 돌아가고 있는 서비스의 핵심 경로에 바로 박아 넣기보다는, 실패해도 기존 LLM 경로로 자연스럽게 되돌아갈 수 있는 보조 경로로 먼저 붙여보는 쪽이 안전할 것 같다.

정리

Jev가 흥미로운 이유는 "GPT보다 똑똑해서"가 아니라, 애초에 목표가 다르기 때문이다. 큰 모델은 "생각하고 말하고 생성"하는 데 최적화돼 있고, Jev는 "판단"하는 데만 최적화돼 있다. 모든 요청에 가장 큰 모델을 쓰는 대신, 명확한 규칙은 코드로, 애매하지만 빠른 판단은 Jev 같은 모델로, 깊은 추론은 LLM으로, 장기 작업은 Agent로 나누는 설계가 점점 자연스러워지는 것 같다.

내 프로젝트로 좁혀보면, 노가리의 댓글 필터와 매치다의 매칭 점수가 가장 먼저 눈에 띄는 후보다. 다만 Early Access 단계인 걸 감안하면, 지금 당장 교체하기보다는 다음 기능 추가 시점에 한 번 직접 붙여보고 레이턴시와 정확도를 내 손으로 재보는 게 먼저일 것 같다.