언제 LLM, 언제 결정모델? — 선택 기준과 의사결정 트리
LLM과 결정모델은 경쟁이 아니라 분업입니다. 출력의 모양, 처리량과 지연, 신뢰도 요구를 기준으로 어느 쪽을 써야 하는지 4가지 신호로 정리하고, 요약·추출처럼 경계가 애매한 작업을 실전 예시와 의사결정 트리로 판단합니다. 이 장을 마치면 파이프라인의 어느 단계에 결정모델을 끼울지 스스로 결정할 수 있습니다.
두 모델은 경쟁이 아니라 분업입니다
1장에서 Jev가 텍스트를 만들지 않고 스키마에 맞춘 결정만 돌려주는 모델이라는 걸 봤습니다. 그러면 자연스럽게 드는 질문이 있습니다. 어떤 작업을 LLM에 맡기고, 어떤 작업을 결정모델로 넘겨야 할까요.
이 질문에 "둘 중 뭐가 더 좋냐"로 접근하면 답이 안 나옵니다. LangChain 공식 블로그의 정리가 기준을 잘 잡아 줍니다. "개방형 추론과 생성에는 LLM을, 그 사이의 빠르고 구조화된 결정에는 Jev를 쓰라." 하나의 요청 흐름 안에서 둘은 번갈아 등장합니다.
출력의 '모양'을 먼저 보세요
가장 빠른 판별 기준은 결과물의 형태입니다. 최종 산출물이 사람이 읽는 문장·문서·코드라면 LLM의 일입니다. 반대로 산출물이 코드가 곧바로 소비할 라벨·점수·참거짓이라면 결정모델 자리입니다.
"이 문의를 요약해 고객에게 답장을 써 줘"는 생성입니다. "이 문의가 환불·버그·기능요청 중 무엇인가"는 결정입니다. 둘은 종종 한 요청 안에 같이 있습니다. 앞의 분류로 경로를 정하고, 뒤의 생성으로 답장을 만듭니다.
판단과 생성을 한 파이프라인에서 나눕니다
실전 설계는 대개 이렇게 흘러갑니다. 들어온 입력을 결정모델이 먼저 분류·라우팅하고, 꼭 필요한 요청만 LLM으로 넘겨 문장을 생성합니다. 값싸고 빠른 판단이 앞단을 지키고, 비싼 생성은 뒤에서 최소한으로 돕니다.
결정모델이 맞는 신호 네 가지
아래 조건에 여러 개 해당할수록 그 단계는 결정모델로 옮길 후보입니다.
1. 출력이 정해진 집합이다
답이 미리 아는 라벨 목록, 순서형 점수, 예/아니오 중 하나로 떨어진다면 결정모델의 정확한 사용처입니다. Jev의 세 질문 형태(Choice·Score·Noul)가 이 세 가지 모양을 그대로 담습니다.
2. 대량이고, 지연과 비용이 중요하다
같은 판단을 초당 수백·수천 건 처리해야 한다면 지연과 단가가 곧 서비스 품질입니다. Jev의 응답 지연은 70~500ms, 입력 단가는 100만 토큰당 $0.042에 출력은 무료입니다. 같은 판단을 LLM으로 하면 3~329초에 100만 토큰당 $0.20~$10 수준으로, 트래픽이 커질수록 격차가 벌어집니다.
결정모델 후보의 신호: 같은 판단 × 대량 × 저지연·저비용 요구
3. '얼마나 확신하는가'가 필요하다
분류 결과만이 아니라 그 결과를 얼마나 믿을 수 있는지가 중요할 때가 있습니다. 확신이 높으면 자동 처리하고, 낮으면 사람이나 LLM으로 넘기는 식입니다. Jev는 각 답에 보정된 신뢰도를 함께 주기 때문에, 이 신뢰도를 임계값으로 삼아 자동/보류를 가를 수 있습니다.
4. 같은 판단을 계속 반복한다
한 번 스키마를 잘 정의해 두면 같은 형태의 판단을 값싸게 무한히 반복할 수 있습니다. 반대로 매번 기준이 달라지는 일회성 판단이라면 스키마 설계 비용이 아깝습니다.
LLM이 여전히 맞는 자리
경계를 분명히 하려면 결정모델이 못 하는 일도 알아야 합니다. TypeSafe 문서 스스로 생성형 작업, 특수 도메인 지식, 깊은 다단계 추론(카너먼식 System 2)에는 Jev가 적합하지 않다고 안내합니다.
열린 추론·설명·창작
"왜 이런 결론이 나오는지 설명해 줘", "이 주제로 블로그 글을 써 줘", "이 코드를 리팩터링해 줘" 같은 요청은 정해진 선택지로 환원되지 않습니다. 자유로운 문장·코드가 산출물인 작업은 LLM의 몫입니다.
도메인 지식과 다단계 사고
여러 단계를 거쳐 근거를 쌓아 가는 판단, 풍부한 배경지식을 끌어와야 하는 추론은 결정모델의 단일 패스로 담기 어렵습니다. 이런 작업은 LLM에 맡기고, 그 과정 중간의 작은 판단만 결정모델이 거들게 하는 편이 낫습니다.
경계가 애매한 작업 — 실전 판단
현실에서는 딱 잘리지 않는 작업이 더 많습니다. 몇 가지 자주 헷갈리는 경우를 정리했습니다.
| 작업 | 추천 | 이유 |
|---|---|---|
| 문의를 카테고리로 분류 | 결정모델 | 라벨 집합이 고정, 대량·반복 |
| 문의 요약해서 답장 작성 | LLM | 산출물이 자유 문장 |
| 요청 복잡도로 모델 라우팅 | 결정모델 | Score로 채점 후 분기 |
| 리뷰에서 감정 라벨만 추출 | 결정모델 | 정해진 라벨 + 신뢰도 |
| 리뷰에서 개선 포인트 서술 | LLM | 서술형 생성 |
| 입력이 탈옥 시도인지 판단 | 결정모델 | Noul 이진 + 임계값 |
"요약"은 어느 쪽인가
요약이라는 단어에 속으면 안 됩니다. 결과가 사람이 읽는 문장이면 생성이고, "핵심 카테고리 3개만 고르기"처럼 정해진 태그를 뽑는 일이면 분류입니다. 같은 '요약'도 산출물의 모양에 따라 갈립니다.
"추출"은 어느 쪽인가
추출도 마찬가지입니다. 자유 텍스트에서 임의의 문장을 뽑아 재구성하면 LLM에 가깝고, 미리 정한 필드·라벨로 값을 판정해 채우는 일이면 결정모델이 빠르고 안전합니다.
의사결정 트리로 정리합니다
머뭇거릴 때 이 순서로 물어보면 대부분 정리됩니다.
- 산출물이 사람이 읽는 문장·코드인가 → 그렇다면 LLM
- 답이 정해진 라벨·점수·참거짓 집합인가 → 아니라면 LLM, 맞다면 다음 질문
- 대량이고 지연·비용이 중요한가, 또는 신뢰도 기반 자동화가 필요한가 → 맞다면 결정모델
- 애매하면: 앞단 판단은 결정모델, 뒤단 생성은 LLM으로 쪼개 배치
라우팅처럼 판단 자체가 목적인 작업은 OpenRouter 같은 도구로 여러 LLM 사이를 오갈 때도, 그 '어디로 보낼지'를 Jev (TypeSafe AI) 같은 결정모델이 맡는 구조가 자연스럽습니다.
정리
LLM과 결정모델의 선택은 취향이 아니라 작업의 모양이 정합니다. 출력이 자유 텍스트면 LLM, 정해진 집합이면 결정모델, 그리고 대부분의 실전 파이프라인은 둘을 단계별로 나눠 씁니다.
다음 장에서는 가장 흔한 결정모델 작업인 '분류 자동화'를 다룹니다. 문의·티켓·콘텐츠를 스키마로 나누는 법과, 결과 품질을 좌우하는 질문 스키마 설계를 실전 예시로 살펴보겠습니다.