Decision Model 운영법: LLM 호출 전에 확률 모델로 분기하는 구조 만들기

최근 모델 릴리스 흐름에서 눈에 띄는 변화는 “텍스트를 길게 생성하는 모델”만 늘어나는 것이 아니라 “결정을 빠르게 내리는 모델”이 따로 등장한다는 점이다. LLM Gateway의 10월 릴리스 목록에도 Microsoft-Decision-1, GPT-6 Luna Decisions 같은 의사결정 계열 모델이 보인다. 이름만 보고 특정 모델을 바로 도입할 필요는 없지만, 제품 구조 관점에서는 중요한 신호다. 모든 요청을 대형 LLM에 보내기 전에, 먼저 확률 기반 분기 모델로 처리할 수 있는 일이 많다.

실무에서 LLM 비용이 커지는 이유는 어려운 질문 때문만이 아니다. 쉬운 분류, 위험도 판단, 라우팅, 중복 감지, 정책 위반 예비 판단까지 모두 큰 모델에 보내기 때문이다. Decision Model은 이런 앞단 작업을 빠르고 싸게 처리하는 슬롯으로 볼 수 있다. 답변 문장을 생성하는 대신 “A일 확률 0.82, B일 확률 0.14, 사람 검토 필요 0.04”처럼 짧은 결과를 내는 구조다.

Decision Model이 맞는 작업

가장 좋은 후보는 정답 공간이 제한된 작업이다. 고객 문의 카테고리 분류, 티켓 우선순위 산정, 문서 민감도 판단, 환불 가능성 예비 판단, 프롬프트 인젝션 의심 점수, 코드 변경 위험도, 검색 쿼리 라우팅이 여기에 속한다. 이런 작업은 장문의 자연어 답변보다 확률과 라벨이 더 유용하다. 후속 시스템은 그 값을 기준으로 워크플로우를 선택한다.

반대로 창의적 글쓰기, 복잡한 법률 해석, 여러 문서를 종합한 전략 제안처럼 근거 설명이 중요한 작업은 Decision Model만으로 끝내면 안 된다. 이 경우 Decision Model은 “어떤 고급 모델로 보낼지” 또는 “사람 검토가 필요한지”를 정하는 앞단 필터로 쓰는 것이 맞다.

기본 아키텍처

구조는 단순하다. 사용자 요청이 들어오면 먼저 정규화 단계에서 입력 길이, 파일 수, 사용자 권한, 요청 유형, 과거 실패 여부를 추출한다. 그다음 Decision Model이 라벨과 확률을 반환한다. 예를 들어 route: simple_answer, confidence: 0.91, risk: low 같은 결과다. 라우터는 이 값을 보고 저비용 답변 모델, 고급 추론 모델, 검색 증강 경로, 사람 검토 큐 중 하나로 보낸다.

중요한 것은 임계값이다. confidence가 0.9 이상이면 자동 처리, 0.6~0.9는 상위 모델 검증, 0.6 미만은 사람 검토처럼 구간을 정할 수 있다. 위험도가 높은 액션은 더 보수적으로 잡는다. 예를 들어 이메일 발송이나 권한 변경은 0.95 이상이어도 사용자 확인을 요구한다. 확률은 자동화의 근거가 아니라 자동화 범위를 제한하는 안전장치로 써야 한다.

학습 데이터 없이 시작하는 방법

처음부터 별도 모델을 학습할 필요는 없다. 규칙 기반 필터와 소형 LLM 분류로 시작할 수 있다. 먼저 실제 로그 300개를 뽑아 라벨을 붙인다. 라벨은 너무 많으면 안 된다. 간단답변, 검색필요, 도구실행필요, 고위험, 사람검토처럼 5~7개가 적당하다. 그런 다음 소형 모델에 JSON 출력만 요구하고, 결과를 사람이 검수한다.

운영 로그가 쌓이면 오분류 케이스를 모아 기준을 수정한다. 특정 고객군에서 고위험이 자주 누락되거나, 특정 문구가 검색필요로 잘못 분류되는 패턴을 찾는다. 이 단계에서 규칙을 추가할지, 프롬프트를 고칠지, 별도 경량 분류 모델을 학습할지 결정한다. 처음부터 복잡한 ML 파이프라인을 만들면 피드백 속도가 느려진다.

실패 비용을 기준으로 임계값 잡기

Decision Model의 품질은 정확도 하나로 판단하면 안 된다. 라벨별 실패 비용이 다르기 때문이다. 단순 문의를 고급 모델로 보내는 실수는 비용 증가로 끝난다. 하지만 고위험 요청을 단순 답변으로 보내는 실수는 보안 사고가 될 수 있다. 따라서 라벨별로 false positive와 false negative 비용을 따로 정해야 한다.

예를 들어 프롬프트 인젝션 탐지에서는 의심 요청을 과하게 막는 false positive가 사용자 경험을 해치지만, 놓치는 false negative는 데이터 유출로 이어질 수 있다. 이 경우 임계값을 높게 잡고, 애매한 요청은 안전 경로로 보낸다. 반대로 마케팅 문구 톤 분류처럼 실패 비용이 낮은 작업은 자동화 비율을 높여도 된다.

관측 지표

운영 대시보드에는 라벨 분포, 평균 confidence, 자동 처리율, 상위 모델 승격률, 사람 검토율, 오분류 신고율이 들어가야 한다. 특히 라벨 분포가 갑자기 바뀌면 입력 트래픽이 변했거나 모델이 이상해졌을 수 있다. 고위험 비율이 평소 3%였는데 0.2%로 떨어졌다면 좋아진 것이 아니라 탐지가 깨졌을 가능성을 봐야 한다.

또한 다운스트림 결과와 연결해야 한다. Decision Model이 simple_answer로 보낸 요청에서 사용자 재질문률이 높다면 라우팅이 너무 공격적일 수 있다. human_review로 보낸 요청 중 사람이 대부분 자동 처리 가능하다고 판단한다면 임계값이 너무 보수적이다. 라우터는 한 번 만들고 끝나는 코드가 아니라 계속 조정하는 운영 장치다.

보안 로그도 별도로 남겨야 한다. 분기 모델은 최종 답변을 만들지 않더라도 접근 경로를 결정한다. 그래서 어떤 입력이 어떤 라벨로 분류됐고, 그 결과 어떤 모델과 도구 권한이 열렸는지 추적 가능해야 한다. 나중에 문제가 생겼을 때 “왜 이 요청이 자동 처리됐는가”를 설명할 수 없으면, 비용 절감 장치가 감사 리스크가 된다.

실행 체크리스트

• 정답 공간이 제한된 분류·라우팅·위험도 판단 작업부터 Decision Model 후보로 잡는다.
• 실제 로그 300개 이상에 5~7개 라벨을 붙여 초기 평가셋을 만든다.
• 모델 출력은 자연어가 아니라 라벨, confidence, 근거 필드가 있는 JSON으로 제한한다.
• 라벨별 실패 비용을 정하고 고위험 라벨은 보수적인 임계값을 쓴다.
• 자동 처리, 상위 모델 승격, 사람 검토 구간을 confidence 기준으로 나눈다.
• 라벨 분포, 승격률, 재질문률, 오분류 신고율을 대시보드로 본다.
• 월 1회 이상 오분류 샘플을 리뷰해 라벨 정의와 임계값을 조정한다.