지원 티켓을 담당 팀으로 보내고, 거래를 검토 대상으로 올리고, 콘텐츠를 정책 흐름에 맞게 나누는 일은 반복 횟수가 많을수록 매 요청 LLM 호출의 비용과 지연이 눈에 띄기 시작한다. 그렇다고 모든 분류·점수화·라우팅 업무를 작은 로컬 모델로 바꾸는 것이 답은 아니다.
STROT 같은 로컬 결정 런타임이 제안하는 방식은 LLM을 매 레코드의 판단자로 쓰지 않는 데 있다. 업무 지시, 선택지, 출력 형식, 샘플을 바탕으로 한 번 컴파일한 뒤에는 캐시된 결과물과 결정 모델로 반복 입력을 처리한다. 제품 문서상 이후 실행은 로컬에서 이뤄질 수 있고, 결과는 선택지·점수·불리언처럼 타입이 정해진 JSON 형태로 반환한다.
따라서 핵심 질문은 “로컬 모델의 정확도가 더 높은가”가 아니다. 우리 업무는 한 번 정의한 판단 규칙을 충분히 오래 반복할 수 있는가, 그리고 판단을 보류했을 때 처리할 다음 경로가 있는가가 먼저다.
이 구조가 맞는 업무는 자유 생성보다 제한된 선택이 많은 업무다
로컬 결정 런타임은 답의 범위를 미리 좁힐수록 검토하기 쉬워진다. 예를 들어 지원 요청을 청구, 기술 결함, 제품 의견, 스팸 중 하나로 배정하거나, 특정 항목을 1점부터 5점 사이로 점수화하거나, 정해진 조건에 따라 참·거짓을 판단하는 업무가 여기에 가깝다.
이런 업무에서는 모델이 매번 긴 답변을 새로 작성할 필요가 없다. 허용된 라우팅 목적지, 점수 범위, 반환 형식을 고정하고, 그 안에서 어떤 결정을 내렸는지와 신뢰도를 함께 받는 편이 운영에 더 유용할 수 있다.
STROT은 run()과 decide()라는 두 실행 방식을 제시한다. 전자는 정해진 작업 경로로 레코드를 보내는 라우팅 중심 방식이고, 후자는 선택형·점수형·불리언 질문에 구조화된 답을 반환하는 방식이다. 제품 설명에 따르면 로컬 런타임은 기본 모델을 준비한 뒤 오프라인 환경에서도 실행할 수 있다. 다만 컴파일 과정에는 LLM 사용이 포함될 수 있으므로, “로컬 실행”과 “처음부터 끝까지 외부 모델을 쓰지 않음”을 같은 의미로 취급하면 안 된다.
반대로 다음과 같은 업무는 매 요청 LLM 호출 또는 별도 전용 모델을 더 신중하게 비교할 필요가 있다.
- 분류 기준과 정책 문구가 자주 바뀌어 결과물을 반복해서 다시 만들어야 한다.
- 입력마다 여러 문서, 최신 규정, 긴 대화 이력을 함께 해석해야 한다.
- 새 국가, 새 상품, 새 고객군이 빠르게 늘어나 입력 표현의 범위가 계속 달라진다.
- 라우팅 오류를 되돌릴 사람이나 후속 자동화 경로가 없다.
- 검증용 정답 데이터를 만들기 어렵고, 오류의 영향도 크다.
이 경우 로컬 실행의 낮은 반복 호출비가 전체 비용 절감으로 이어진다고 보기 어렵다. 재컴파일, 테스트, 승인, 예외 처리에 드는 시간이 더 커질 수 있기 때문이다.
비용 비교에는 호출 단가 외에 네 가지 숫자가 필요하다
STROT은 공개 벤치마크에서 144M 규모 CPU 모델을 사용해 레코드당 약 60ms, 런타임에서 레코드당 추가 LLM 호출 0회를 제시한다. 최초 컴파일 단계의 LLM 사용은 이 수치에 포함되지 않는다. 같은 자료에는 컴파일 방식이 단순 실행보다 높은 분류 성능을 보였다는 결과도 포함돼 있다. 예를 들어 398개 레코드의 라우팅 평가에서 92.5%와 74.8%, AG News 기반 의미 분류에서 86.7%와 72.7%가 제시됐다.
다만 이 수치는 해당 프로젝트가 공개한 데이터셋, 모델, 컨테이너 환경에서 나온 결과다. 자사 입력 길이, 서버 사양, 동시 요청 수, 라벨 체계, 예외 유형이 다르면 같은 지연 시간이나 정확도를 기대할 근거는 없다.
요구사항 단계에서는 요청당 비용과 응답 시간 외에 아래 네 항목을 분리해 기록하는 편이 낫다.
-
자동 결정률
전체 입력 중 사람이나 상위 모델의 개입 없이 처리할 수 있는 비율이다. 이 비율이 낮으면 로컬 런타임의 처리 비용이 낮아도 전체 흐름의 비용은 줄지 않을 수 있다. -
보류율과 보류 후 경로
신뢰도가 낮은 입력을 보류하는 방식은 오분류를 줄이는 데 도움이 될 수 있다. 선택적 분류 연구에서도 모델이 답변을 거절하면 수용된 예측의 정확도를 높일 수 있다고 설명한다. 그러나 신뢰도 자체가 언제나 믿을 만한 것은 아니므로, 보류 기준은 자사 데이터에서 검증해야 한다. 보류 건을 사람 검토 큐로 보낼지, 기존 LLM에 재판단시킬지까지 함께 정해야 한다. -
변경 후 승인 시간
선택지 하나를 추가하거나 점수 기준을 바꿨을 때, 누가 샘플과 정답 데이터를 갱신하고 어떤 테스트를 통과해야 배포할 수 있는지 기록해야 한다. 이 시간은 추론 비용과 성격이 다른 유지보수 비용이다. -
오류 복구 비용
잘못 보낸 티켓을 재배정하고, 잘못 분류한 거래를 다시 검토하고, 잘못 적용한 흐름을 되돌리는 데 드는 일을 따로 봐야 한다. 라벨 일치율만으로는 오류의 업무상 무게를 구분하기 어렵다.
보류 기능은 안전장치가 아니라 운영 설계의 일부다
STROT은 낮은 신뢰도의 라우팅 결과를 자동으로 결정하지 않고 fallback으로 모으는 흐름을 제공한다고 설명한다. 반면 decide()는 신뢰도와 함께 결과를 반환하되 호출자가 임계값을 적용하는 구조다. 같은 제품 안에서도 보류의 책임이 실행 방식에 따라 다를 수 있다는 뜻이다.
여기서 흔한 실패는 신뢰도 점수를 정확도 보증으로 받아들이는 일이다. 보정된 확률과 신뢰도를 제공한다고 해도, 그 값이 새 입력 분포에서도 실제 오류율과 잘 맞는지는 별도 검증이 필요하다. 특히 새 유형의 문의, 누락된 필드, 정책 범위 밖의 표현이 들어올 때 신뢰도가 어떻게 움직이는지 확인해야 한다.
파일럿에서는 다음처럼 역할을 나누는 편이 현실적이다.
- 높은 신뢰도 구간은 자동 라우팅 후보로 둔다.
- 중간 구간은 기존 LLM 호출이나 검토 큐로 보낸다.
- 낮은 신뢰도 또는 미정의 유형은 새 라벨·새 정책 검토의 입력으로 모은다.
이 설계의 목적은 모든 건을 로컬에서 처리하는 데 있지 않다. 반복적이고 되돌릴 수 있는 판단을 자동화 범위에 넣고, 불확실한 건은 더 비싼 판단 경로로 넘기는 데 있다.
전환 판단은 세 가지 업무 조건에서 갈린다
| 판단 조건 | 로컬 결정 런타임 검토 우선 | 기존 LLM 호출 또는 전용 모델 검토 우선 |
|---|---|---|
| 업무 정의 | 선택지와 출력 형식이 비교적 안정적 | 지시와 정책이 자주 바뀜 |
| 입력 특성 | 반복되는 유형이 많고, 구조화 가능한 정보가 있음 | 문서·대화·최신 맥락을 매번 길게 종합해야 함 |
| 오류 대응 | 보류 건과 오분류를 되돌릴 경로가 있음 | 한 번의 오류가 즉시 큰 피해로 이어지고 복구가 어려움 |
| 검증 기반 | 알려진 정답과 승인 기준을 준비할 수 있음 | 정답 데이터가 부족하거나 라벨 합의가 어려움 |
| 운영 여력 | 결과물 버전, 재컴파일, 테스트를 관리할 담당자가 있음 | 지속적인 변경을 관리할 데이터·운영 체계가 없음 |
전용 모델은 로컬에서 실행된다는 이유만으로 대안이 되지 않는다. 해당 업무의 라벨과 입력 분포를 지속적으로 관리할 수 있을 때 검토할 수 있는 경로다. STROT의 컴파일 방식도 마찬가지다. 컴파일 결과가 알려진 정답을 통과하는 절차를 제공하더라도, 정답 데이터가 현재 운영의 예외와 변경을 담지 못하면 배포 후 신뢰성은 별개 문제가 된다.
요구사항 회의에서 먼저 합의할 질문
제품 기능 목록보다 아래 질문에 답해 보면 전환 가능성을 더 빨리 가늠할 수 있다.
- 우리 서비스에서 자동 결정해도 되는 범위와 반드시 보류해야 하는 범위는 어디까지인가?
- 분류 항목, 점수 기준, 출력 스키마가 바뀔 때 누가 정답 데이터와 승인 기준을 갱신하는가?
- 컴파일 단계에서 어떤 샘플과 업무 정보가 외부 LLM으로 전달될 수 있는가?
- 모델, 업무 지시, 예시, 스키마가 달라졌을 때 이전 결과물과 새 결과물을 어떻게 비교하고 되돌릴 것인가?
- 보류된 레코드는 어느 팀, 어느 시스템, 어느 모델이 처리하며 그 비용을 누가 측정하는가?
첫 파일럿은 가장 단순한 업무보다 정답 데이터가 있고, 오류를 되돌릴 수 있으며, 입력 유형이 비교적 안정적인 업무에서 시작하는 편이 낫다. 그 업무에서 자동 결정률, 보류율, 오류 복구 비용, 변경 후 승인 시간을 함께 비교해야 한다. 그때 비로소 반복 LLM 호출을 줄인 이점이 유지보수 부담과 정확도 위험을 상쇄하는지 판단할 수 있다.
