Classifier와 LLM 사이의 빈자리: Jev를 통해 다시 생각한 AI의 판단

이 글은 WikiDocs의 Decision AI와 Jev를 읽고, 인상 깊었던 내용을 바탕으로 작성한 글입니다.

 

최근 Jev라는 조금 특이한 AI 모델을 알게 됐다.

처음에는 TypeSafe AI가 만든, 일반적인 LLM처럼 문장을 생성하지 않고 주어진 상황에 대한 판단과 그 확률을 반환하는 모델 정도로 이해했다.

 

첫인상은 솔직히 단순했다.

결국 엄청 빠른 classifier 같은 것 아닌가?

 

그런데 WikiDocs의 관련 글을 읽다 보니 Jev 자체의 성능이나 API보다 더 흥미로운 부분이 눈에 들어왔다.

우리는 왜 분류처럼 단순해 보이는 작업까지 LLM에게 맡기게 됐을까?

그리고 조금 더 생각해보니 이 질문은 단순히 Jev에 대한 이야기가 아니었다.

생성, 분류, 판단, 정책, 실행을 하나로 뭉뚱그려 생각하던 내가 AI 시스템을 조금 다른 관점에서 바라보게 된 계기가 됐다.

---

우리는 너무 많은 것을 LLM에게 물어보고 있다

요즘 AI 서비스를 개발한다고 하면 자연스럽게 LLM부터 떠올리게 된다.

예를 들어 고객 문의가 하나 들어왔다고 해보자.

결제가 두 번 됐습니다.
빨리 환불해주세요.

 

이 문의를 처리하기 위해 필요한 정보는 꽤 명확하다.

어느 부서의 문의인지, 환불을 요구하는지, 얼마나 긴급한지 등을 알아내면 된다.

LLM에게는 이런 식으로 요청할 수 있다.

다음 고객 문의를 분석해서 JSON으로 반환해줘.

- department: billing | technical | sales | other
- refund: true | false
- urgency: 0 ~ 3

그리고 최근의 LLM은 이런 작업을 꽤 잘한다.

Structured Output을 지원하는 모델이라면 JSON 형식 자체도 상당히 안정적으로 받을 수 있다.

그러니 처음에는 이런 생각이 든다.

 

잘 되는데 굳이 다른 모델이 필요한가?

그런데 여기에서 질문을 조금 바꿔볼 필요가 있다.

LLM이 이 일을 할 수 있느냐가 아니라,

이 일을 하는 데 LLM이 가장 적절한 도구인가?

---

생성과 판단은 꽤 다른 문제다

LLM의 가장 큰 장점은 출력 공간이 열려 있다는 것이다.

요약을 부탁할 수도 있고, 코드를 작성시킬 수도 있고, 이메일을 쓰게 할 수도 있다.

정답을 미리 정의하지 않아도 된다.

반면 우리가 고객 문의에서 원하는 것은 전혀 다르다.

billing인가?
→ Yes / No

어느 부서인가?
→ billing / technical / sales / other

얼마나 긴급한가?
→ 0 / 1 / 2 / 3

 

가능한 답의 공간이 이미 정해져 있다.

무언가를 생성하고 싶은 게 아니라 하나를 판단하고 싶은 것이다.

그런데 지금 우리는 이런 작은 판단에도 매우 범용적인 생성 모델을 사용하고 있다.

그 사실을 인식하고 나니 다음 질문이 자연스럽게 따라왔다.

그럼 그냥 classifier를 쓰면 되는 것 아닌가?

---

그런데 분류와 의사결정도 조금 다르다

이 지점은 WikiDocs의 글을 읽으면서 특히 와닿았던 부분이다.

전통적인 supervised classifier는 이런 작업에 정말 잘 맞는다.

입력을 받고 정해진 class 가운데 하나를 고른다.

billing      0.97
technical    0.01
sales        0.01
other        0.01

 

빠르고, 저렴하고, 확률까지 얻을 수 있다.

언뜻 보면 판단 문제에는 LLM보다 classifier가 훨씬 적합해 보인다.

그런데 classifier에는 다른 비용이 있다.

변화시키기 어렵다.

예를 들어 처음에는 문의 유형이 다음과 같았다고 해보자.

billing
technical
sales
other

 

서비스를 운영하다가 security라는 새로운 유형이 필요해졌다.

전통적인 supervised classifier라면 새로운 label에 대한 데이터를 준비하고, labeling하고, 다시 학습하고, 평가하고, 모델을 배포해야 할 가능성이 높다.

반면 LLM이라면 선택지를 하나 추가하고 instruction을 조금 수정하는 것만으로도 일단 새로운 요구사항을 시험해볼 수 있다.

billing
technical
sales
security
other

 

물론 제대로 운영하려면 LLM도 evaluation은 필요하다.

하지만 문제를 정의하는 방식 자체를 바꾸는 비용은 classifier와 상당히 다르다.

원문에서는 이 차이를 통해 규칙 엔진 → 분류기 → LLM 사이에 존재하는 빈자리를 설명한다.

나는 이 내용을 읽으면서 둘의 차이를 이렇게 이해하게 됐다.

Classifier는 inference에는 싸지만 변화에는 비쌀 수 있다.
LLM은 inference에는 비싸지만 변화에는 싸다.

 

그동안 AI 모델을 비교할 때 주로 latency, token cost, accuracy 같은 실행 비용만 생각했다.

그런데 실제 제품 개발에서는 그에 못지않게 중요한 비용이 하나 더 있었다.

Change Cost

요구사항이 바뀌었을 때 얼마나 쉽게 시스템의 행동을 바꿀 수 있는가.

이 관점으로 보니 최근 많은 팀이 간단한 분류까지 LLM으로 구현하는 이유도 어느 정도 이해가 됐다.

항상 가장 효율적인 추론 방식이어서가 아니라,

제품이 계속 변하는 상황에서 가장 다루기 쉬운 방식이기 때문일 수 있다.

---

그리고 그 사이에 빈자리가 보였다

이 부분 역시 원문의 문제의식에서 큰 영향을 받았다.

개념적으로 정리해보면 이런 모습이다.

방식 변경 유연성 추론 속도 명시적인 판단 확률 시작 비용

Rule	낮음	매우 빠름	없음	낮음
Supervised Classifier	낮음	매우 빠름	있음	높음
LLM	매우 높음	상대적으로 느림	일반적으로 바로 쓰기 어려움	낮음
Decision Model	높음을 지향	빠름을 지향	있음	낮음을 지향

 

여기에서 마지막 줄이 Jev 같은 판단 전용 모델이 노리는 자리라고 이해했다.

내가 흥미롭게 느낀 부분은 단순히

“classifier보다 좋은 모델이 등장했다.”

가 아니었다.

오히려,

 

classifier가 갖고 있던 판단 인터페이스와
LLM이 가져온 runtime flexibility를
한 시스템 안에서 같이 가져갈 수 있을까?

 

라는 시도처럼 보였다는 점이었다.

Jev가 실제로 그 자리를 얼마나 잘 채울 수 있는지는 별개의 문제다.

하지만 그런 자리가 비어 있었다는 사실을 인식하게 된 것 자체가 내게는 꽤 흥미로웠다.

---

답보다 더 중요했던 것은 “얼마나 확신하는가”였다

Jev에서 또 하나 흥미롭게 느낀 것은 probability였다.

예를 들어 두 시스템이 똑같이 다음 결과를 내놓는다고 해보자.

 

department = billing

 

코드 입장에서는 둘이 완전히 같은 결과다.

하지만 실제 모델 내부에서는 전혀 다른 상황일 수 있다.

Case A

billing     0.99
sales       0.01

 

와

Case B

billing     0.51
sales       0.49

 

는 같은 billing이지만 의미가 다르다.

첫 번째 판단은 자동으로 처리해볼 만할 수 있지만, 두 번째 판단은 다른 모델이나 사람에게 넘기는 편이 나을 수도 있다.

여기서 내게 중요하게 다가온 것은 probability가 단순히 화면에 보여주는 부가 정보가 아니라는 점이었다.

시스템의 다음 행동을 결정하는 입력이 될 수 있다.

if confidence >= 0.95:
    handle_automatically(result)
else:
    escalate(result)

 

그동안 confidence를 모델의 성능을 설명하는 숫자로만 생각했다면, 이제는 control flow를 만드는 신호로도 볼 수 있다는 생각이 들었다.

물론 0.9라는 숫자를 반환한다고 해서 자동으로 믿을 만한 확률이 되는 것은 아니다.

예측 confidence가 실제 정답률과 얼마나 일치하는지를 보는 calibration 문제가 있기 때문이다.

결국 중요한 질문은

confidence = 0.9인가?

 

에서 끝나지 않는다.

confidence가 0.9인 판단들을 모았을 때
실제로 약 90% 정도 맞는가?

 

까지 가야 한다.

그리고 그 숫자를 어느 정도 신뢰할 수 있다면 비로소 시스템은 **“모르면 기권한다”**는 선택을 할 수 있다.

나에게는 이 부분이 단순한 accuracy 경쟁보다 훨씬 실용적으로 느껴졌다.

---

정확도가 높은 모델보다 기권할 줄 아는 모델

예를 들어 두 모델이 있다고 생각해보자.

A 모델은 전체 요청의 95%를 맞힌다.

하지만 어떤 요청에서 틀릴지 알 수 없다.

B 모델은 전체 기준으로는 90%밖에 맞히지 못한다.

대신 스스로 확신한다고 말한 60%의 요청에서는 거의 틀리지 않고, 나머지 40%에서는 자신 없어 한다.

단순 accuracy만 보면 A가 좋아 보인다.

하지만 자동화 시스템을 만든다면 이야기가 달라질 수 있다.

B의 높은 confidence 영역만 자동 처리하고 나머지는 더 강한 LLM이나 사람에게 보내면 되기 때문이다.

                   높은 confidence ─→ 자동 처리
Request → Judge ──┤
                   낮은 confidence ─→ LLM / Human

 

그래서 Jev를 보면서 내게 크게 남은 생각 중 하나는 이것이었다.

 

좋은 AI는 항상 답을 내놓는 AI가 아니라,
언제 자신의 답을 사용하면 안 되는지 시스템이 판단할 수 있게 해주는 AI일 수도 있다.

---

그런데 판단과 결정도 같은 말은 아니었다

이 부분도 원문의 Judgment / Policy / Action 구분을 보면서 특히 생각이 많이 바뀐 지점이다.

다음 두 질문을 비교해보자.

사용자가 환불을 요구하고 있는가?

와

이 사용자에게 자동 환불을 해도 되는가?

 

언뜻 보면 비슷하지만 완전히 다른 문제다.

첫 번째는 입력을 보고 판단할 수 있다.

refund_requested = 0.98

 

하지만 두 번째 질문에는 더 많은 정보가 필요하다.

환불 금액은 얼마인지, 이미 환불 이력이 있는지, 회사 정책상 자동 환불 한도는 얼마인지, 특정 상품은 예외인지 등이 포함된다.

즉 첫 번째는 Judgment에 가깝고 두 번째는 Policy다.

그리고 실제 환불 API를 호출하는 것은 다시 Action이다.

Input
  ↓
Judgment
"환불을 원하는 것 같다: 98%"
  ↓
Policy
"10만 원 이하 + confidence 95% 이상이면 자동 승인"
  ↓
Action
refund()

 

원문에서도 모델의 판단, 코드의 정책, 시스템의 실행을 분리하는 구조를 중요하게 다룬다.

그리고 이 부분을 읽으면서 특히 이런 생각이 들었다.

AI 서비스를 만들다 보면 프롬프트를 점점 자세하게 만드는 방향으로 가기 쉽다.

10만 원 이상이면 승인하지 말고...
VIP 고객이면...
최근 30일 내 환불 이력이 있으면...

 

그런데 가만히 보면 이것들은 모델이 이해해야 하는 세상의 정보라기보다 우리 서비스가 정한 정책일 수 있다.

프롬프트에 정책을 계속 추가하는 순간, 원래 코드로 테스트할 수 있었던 비즈니스 로직을 확률적인 영역으로 옮기게 될 수도 있다.

그래서 이 대목을 읽고 나서는 이렇게 생각하게 됐다.

모델에게는 세상을 해석하게 하고,
그 해석으로 무엇을 할지는 가능한 한 코드가 결정하게 하자.

---

모델 선택보다 모델 배치가 더 중요할 수도 있다

이 관점으로 AI 시스템을 다시 보면 구조도 달라진다.

예전에는 AI 기능을 만들 때 이런 식으로 생각했다.

어떤 LLM을 사용할까?

 

GPT인가, Claude인가, Gemini인가.

더 큰 모델을 쓸지 작은 모델을 쓸지.

물론 중요한 질문이다.

하지만 그보다 앞에 다른 질문이 필요할 수도 있다.

이 단계에서 정말 LLM이 필요한가?

 

어떤 요청은 코드만으로 해결할 수 있다.

어떤 요청은 작은 semantic judgment 하나면 된다.

어떤 요청은 frontier LLM의 reasoning이 필요하다.

그리고 어떤 요청은 사람이 확인해야 한다.

                           ┌→ Code
                           │
Request → Judgment Layer ──┼→ Small Model
                           │
                           ├→ Frontier LLM
                           │
                           └→ Human

 

그러면 AI 시스템을 하나의 거대한 모델로 보는 대신 서로 다른 역할을 가진 컴포넌트의 조합으로 볼 수 있다.

이걸 보면서 든 생각은 단순했다.

어떤 모델을 선택하느냐만큼, 그 모델을 어디에 놓느냐가 중요하다.

---

그렇다고 Jev가 정답이라는 뜻은 아니다

여기까지 보면 Jev가 기존 문제를 모두 해결한 것처럼 느껴질 수도 있다.

하지만 아직 그렇게 보기에는 이르다고 생각한다.

그리고 Jev에서 흥미롭게 보이는 개념 중 상당수는 완전히 새로운 것도 아니다.

분류기는 오래전부터 probability를 반환해 왔고, calibration 역시 오랫동안 연구되어 왔다. confidence가 부족한 입력을 자동 처리하지 않는다는 사고방식도 머신러닝 시스템에서 낯선 개념은 아니다.

그래서 나는 Jev를

“LLM보다 뛰어난 새로운 AI”

라고 이해하기보다는,

“그동안 LLM 하나에 너무 많은 역할을 넣고 있지는 않았는지 다시 생각하게 만드는 모델”

정도로 받아들이고 있다.

그리고 이 역시 내가 참고한 WikiDocs 글에서 얻은 문제의식을 내 방식으로 다시 해석한 결과다.

---

Jev를 공부하고 나서 달라진 질문

Jev가 앞으로 얼마나 많이 사용될지는 모르겠다.

LLM이 지금보다 훨씬 빠르고 저렴해진다면 Decision Model과 LLM의 경계가 다시 희미해질 수도 있다.

또 다른 방식의 판단 모델이 등장할 수도 있다.

그래도 이번 글을 읽고 정리하면서 얻은 관점은 꽤 오래 남을 것 같다.

이제 AI 기능을 설계할 때 단순히

어떤 모델을 쓰지?

 

만 묻기보다는,

이 문제는 생성인가, 판단인가?

이미 정해진 선택지 안의 문제라면
굳이 생성 모델이 필요한가?

이 판단은 모델이 해야 하는가,
아니면 코드에 남겨야 할 정책인가?

모델이 확신하지 못할 때
우리 시스템에는 기권할 경로가 있는가?

이 모델의 inference cost뿐 아니라
요구사항이 바뀔 때의 change cost는 얼마인가?

 

를 먼저 생각해볼 것 같다.

Jev라는 특정 모델보다 오히려 이런 질문들이 더 기억에 남았다.

생성과 판단은 다르고,

분류와 유연한 의사결정도 다르고,

판단과 정책 역시 다르다.

좋은 AI 시스템을 만든다는 것은 더 많은 일을 AI에게 넘기는 것이 아닐지도 모른다.

오히려 AI가 판단해야 할 영역과 코드가 책임져야 할 영역의 경계를 더 잘 그리는 일에 가까울 수 있다.

그리고 Jev가 정말 Classifier와 LLM 사이의 빈자리를 채우게 될지는 아직 모르겠다.

하지만 적어도 내게는,

그 빈자리가 존재한다는 사실을 발견한 것 자체가 가장 큰 수확이었다.

---

다음 글에서는 — 그 판단은 실제로 어떻게 만들어질까?

여기까지 정리하고 나니 오히려 기술적인 궁금증이 더 커졌다.

LLM과 Jev가 역할이 다르다는 건 알겠는데, 모델 내부에서는 실제로 무엇이 다른 걸까? LLM은 왜 token을 하나씩 생성하고, 판단 모델은 어떻게 선택지별 probability를 바로 내놓을 수 있을까? 지난 글에서 중요하게 봤던 confidence는 실제로 어디서 나오고, LLM의 RLHF와 Decision Model이 말하는 RLCD는 무엇을 다르게 최적화하는 걸까?

Jev는 아직 내부 아키텍처와 RLCD의 구체적인 구현이 충분히 공개되어 있지 않다. 그래서 다음 글에서는 Jev의 구조를 추측하지 않고, 같은 typed-decision 문제를 푸는 오픈웨이트 모델 Laya의 공개 코드와 웨이트를 실제 구현 사례로 살펴보려고 한다.

Laya의 구조가 Jev와 같다는 의미는 아니다. 대신 Decision Model이라는 아이디어가 실제 코드에서 어떻게 구현될 수 있는지, LLM의 next-token prediction과는 기술적으로 무엇이 다른지를 한 단계 더 깊게 알아봤다.

 

다음글: 오픈웨이트 Decision Model 뜯어보기: LLM은 토큰을 생성하고, Laya는 선택지를 점수화한다

 

https://blog.wookingwoo.com/89

오픈웨이트 Decision Model 뜯어보기: LLM은 토큰을 생성하고, Laya는 선택지를 점수화한다