Decision model 라우팅 설계: LLM 비용과 지연을 줄이는 실전 패턴

LLM 서비스 비용이 생각보다 빨리 늘어나는 이유는 답변 생성 때문만이 아닙니다. 실제 에이전트 시스템은 사용자에게 보이는 최종 답변 하나를 만들기 전에 여러 번 판단합니다. 검색을 해야 하는지, 어떤 도구를 쓸지, 어떤 팀으로 넘길지, 위험한 요청인지, 사람 승인이 필요한지 계속 분기합니다. 이 작은 판단들을 모두 큰 LLM에 맡기면 비용과 지연이 누적됩니다.

Cloudflare Clef, OpenAI Decisions API 같은 decision model 흐름이 주목받는 이유가 여기에 있습니다. decision model은 자유로운 문장을 쓰기보다, 미리 정해진 선택지 중 무엇이 맞는지 확률로 반환합니다. 실무에서는 “생성은 LLM, 분기는 decision model”로 나누는 것이 비용과 안정성 면에서 유리합니다.

언제 decision model을 써야 하나

가장 쉬운 기준은 출력 형태입니다. 결과가 문단, 코드, 요약처럼 자유 형식이면 LLM이 맞습니다. 반대로 결과가 yes/no, low/medium/high, billing/support/sales, allow/deny/escalate처럼 닫힌 선택지라면 decision model 후보입니다.

예를 들어 고객지원 챗봇을 생각해보겠습니다. 사용자의 문의를 이해하고 자연스러운 답변을 작성하는 작업은 LLM이 잘합니다. 하지만 긴급도 분류, 담당 팀 라우팅, 환불 정책 검토 필요 여부, 사람 상담 전환 여부는 닫힌 판단입니다. 이 부분은 큰 모델이 장문으로 설명할 필요가 없습니다. 선택지와 확률만 있으면 됩니다.

개발자 도구에서도 동일합니다. PR diff 요약은 LLM이 적합합니다. 하지만 “DB 마이그레이션 포함 여부”, “보안 리뷰 필요 여부”, “테스트 자동 실행 필요 여부”, “자동 수정 허용 여부”는 decision model로 처리할 수 있습니다. 이렇게 나누면 리뷰 파이프라인을 더 예측 가능하게 만들 수 있습니다.

기본 라우팅 구조

실전 구조는 5단계로 잡으면 됩니다. 첫째, 입력 정규화입니다. 사용자 메시지, 메타데이터, 권한, 최근 상태를 하나의 input state로 만듭니다. 둘째, decision model이 첫 라우팅을 합니다. 예를 들어 intent, risk_level, needs_retrieval, requires_human을 판단합니다. 셋째, 필요한 도구만 호출합니다. 넷째, LLM이 최종 답변이나 작업 계획을 만듭니다. 다섯째, decision model이 후처리 판단을 합니다. 답변을 바로 내보낼지, 사람 검토로 넘길지, 추가 확인 질문을 할지 결정합니다.

이 구조의 장점은 큰 모델 호출을 줄이는 것만이 아닙니다. 각 판단이 로그로 남습니다. 어떤 요청이 왜 사람에게 넘어갔는지, 어떤 의도로 검색이 실행됐는지, 어떤 위험도 때문에 자동 실행이 막혔는지 설명할 수 있습니다. 운영팀에게는 이 설명 가능성이 비용 절감만큼 중요합니다.

선택지 설계가 성능을 좌우한다

decision model에서 가장 중요한 것은 모델보다 선택지 설계입니다. 선택지가 모호하면 결과도 흔들립니다. “중요함/중요하지 않음”보다 “4시간 내 대응 필요/24시간 내 대응 가능/자동 응답 가능”처럼 액션 기준이 있는 라벨이 낫습니다. 라벨은 사람이 봐도 같은 결정을 내릴 수 있어야 합니다.

나쁜 선택지 예시는 good, bad, maybe입니다. 이 라벨은 업무 액션과 연결되지 않습니다. 좋은 선택지 예시는 auto_reply, ask_clarifying_question, route_to_support, route_to_billing, escalate_to_human입니다. 결과가 바로 다음 행동으로 연결됩니다.

또한 선택지 수는 너무 많지 않아야 합니다. 처음부터 20개 팀으로 라우팅하려고 하면 평가가 어렵습니다. 먼저 4~6개 큰 범주로 나누고, 필요하면 2차 decision model로 세분화하는 편이 안정적입니다.

임계값 정책 만들기

확률이 나온다고 해서 가장 높은 값을 무조건 선택하면 안 됩니다. 운영에서는 임계값 정책이 필요합니다. 예를 들어 route_to_billing 확률이 0.85 이상이면 자동 라우팅합니다. 0.55~0.85이면 사용자에게 확인 질문을 합니다. 0.55 미만이면 사람 검토로 넘깁니다.

위험도가 있는 판단은 더 보수적으로 잡아야 합니다. 계정 정지, 환불, 삭제, 외부 발송처럼 실패 비용이 큰 액션은 0.95 이상이어도 바로 실행하지 않는 것이 좋습니다. decision model의 역할은 자동 실행이 아니라 승인 큐를 정리하는 것일 수 있습니다. “실행해도 됨”과 “사람이 봐야 함”을 나누는 것만으로도 충분히 가치가 있습니다.

평가 데이터 없이 운영하지 않기

decision model 라우팅은 반드시 평가 데이터가 필요합니다. 최소한 실제 요청 200개를 뽑아 사람이 라벨링해야 합니다. 이상적으로는 정상 케이스, 애매한 케이스, 위험 케이스를 섞어야 합니다. 모델 후보를 바꿔도 같은 데이터로 비교해야 합니다.

평가 지표는 정확도 하나로 부족합니다. 자동 처리율, 사람 검토 전환율, 잘못 자동 처리한 비율, 평균 지연 시간, 호출 비용을 함께 봐야 합니다. 예를 들어 정확도는 높지만 애매한 요청까지 자동 처리하면 운영 사고가 날 수 있습니다. 반대로 너무 보수적이면 비용 절감 효과가 없습니다.

캐싱과 배치 처리

분류 판단은 캐싱하기 좋습니다. 같은 문서, 같은 diff, 같은 정책 입력에 대해 매번 판단할 필요가 없습니다. 입력 해시를 만들고, 모델 버전과 선택지 버전을 함께 저장하면 재사용할 수 있습니다. 단, 사용자 권한이나 최신 상태가 영향을 주는 판단은 무조건 캐싱하면 안 됩니다.

배치 처리도 효과적입니다. PR 20개를 야간에 미리 분류하거나, 고객문의 큐를 5분 단위로 묶어 처리하면 비용을 줄일 수 있습니다. 실시간성이 꼭 필요하지 않은 판단은 동기 호출에서 빼는 것이 좋습니다.

실행 체크리스트

• 서비스 안의 모델 호출을 생성형 작업과 선택형 작업으로 분류합니다.
• 선택형 작업은 닫힌 라벨과 다음 액션을 1:1로 연결합니다.
• 첫 버전은 4~6개 선택지로 시작하고, 필요하면 2차 라우팅으로 나눕니다.
• probability 임계값을 자동 처리, 확인 질문, 사람 검토로 나눕니다.
• 실제 데이터 200개 이상을 라벨링해 오프라인 평가 세트를 만듭니다.
• 정확도뿐 아니라 비용, 지연, 자동 처리율, 위험 오분류율을 함께 측정합니다.
• 입력 해시, 모델 버전, 선택지 버전을 로그에 남겨 캐싱과 회귀 테스트를 가능하게 합니다.

LLM 비용 최적화는 “더 싼 모델로 바꾸기”만으로 해결되지 않습니다. 중요한 것은 어떤 작업에 어떤 모델을 쓰는지 나누는 것입니다. decision model 라우팅은 에이전트가 커질수록 필요한 기본 설계가 됩니다. 답변은 LLM이 쓰게 하고, 반복되는 분기는 더 작고 빠른 판단 모델에 맡기는 것이 실무적으로 가장 깔끔합니다.