소프트웨어가 LLM에 던지는 질문의 상당수는 사실 '판단'이다. "이 티켓은 어느 팀이 처리해야 하나", "이 계약 조항은 책임 항목에 속하는가" 같은 물음이 대표적이다. 이런 경우 개발자는 보통 모델이 정해진 형식(JSON 등)을 지키고, 미리 정한 선택지(예: yes/no) 안에서만 답하도록 요구한다. 적절히 지시하면 최신 LLM은 이 요구를 꽤 안정적으로 충족한다. 문제는 속도와 비용이다. 결정 하나마다 모델이 JSON 객체 전체를 써 내려가야 하고, 추론형 모델이라면 그 앞에서 수백 개의 토큰을 '생각'하며 소모한다. 게다가 명시적으로 묻지 않으면 모델이 그 답에 얼마나 확신하는지도 알 수 없다. 대량·고빈도 처리 환경에서 LLM 기반 의사결정이 쉽게 채택되지 못한 배경이다.
Jev(TypeSafe)나 Laya(Convai) 같은 이른바 '시스템 원(System One)' 결정 모델은 바로 이 지점을 겨냥해 만들어졌다. 상태값과 이름이 붙은 선택지 집합을 넣으면, 선택된 옵션과 함께 각 옵션의 확신도(확률)를 돌려준다. Privatemode 블로그는 여기서 한 걸음 더 나아가, 별도로 학습된 전용 모델이 아니라 시중에 출시된 LLM 그대로를 이런 결정 모델로 바꿀 수 있는지 물었고, 결론적으로 "가능하다"고 답한다.
단일 추론으로 판단만 뽑아내는 원리
핵심 통찰은 LLM이 작동하는 방식에서 나온다. LLM은 텍스트를 직접 쓰는 것이 아니라, 매 순간 어휘 전체에 대한 확률 분포를 출력하고 그중 하나의 토큰을 골라 이어 붙이는 과정을 반복한다. JSON의 몇 개 필드만 채우려는데 이 과정을 통째로 거치는 것은 낭비다. 출력의 형태를 이미 알고 있다면, 굳이 JSON 전체를 생성시킬 이유가 없다는 것이다.
구체적 절차는 세 단계다. 먼저 선택지에 번호를 매겨 상태·질문·옵션을 인덱스가 붙은 JSON으로 프롬프트에 넣고, 모델이 choice_index: 뒤에 인덱스로 답하도록 지시한다. 다음으로 프롬프트를 choice_index:로 끝맺어(프리필), 모델이 처음 내놓을 토큰이 곧 옵션 인덱스가 되도록 강제한다. 마지막으로 실제로 방출된 토큰을 읽는 대신, 그 한 위치에서 모델이 각 옵션 인덱스에 부여한 확률을 읽어 옵션들에 대해 정규화한다. 그러면 옵션별 확률이 나오고, 가장 높은 것을 고르면 된다. 예컨대 "주문이 두 번 청구됐다"는 상태에 "어느 팀?"을 물으면 payments를 확신도 0.39로 답하는 식이다. Fine-tuning은 없으며, 모델은 출시된 상태 그대로 쓰인다. 구현은 vLLM 위의 GLM-5.3-Flash에서 이뤄졌고, /chat/completions 엔드포인트에 continue_final_message와 add_generation_prompt: false를 주어 프리필된 응답을 이어가게 했다. 이 설정 덕분에 텍스트와 함께 이미지를 넣는 것도 가능해진다.
벤치마크: 정확도는 대등, 지역이 속도를 가른다
검증은 공개 라벨 데이터셋 29개로 진행됐다. 의도 라우팅, 감성·주제 분류, 조정(moderation), 함의, 질의응답, 법률 텍스트, 스캔 문서 등을 포괄하고 영어와 독일어를 함께 담았으며, 선택지 수는 2개에서 151개까지 다양했다. 세 시스템 모두 동일한 상태·옵션 순서·지시를 받았다. 텍스트 데이터셋 28개에서 GLM-5.3-Flash와 Jev는 대등했다. 각각 10개 데이터셋에서 더 정확했고, 나머지 8개에서는 1%포인트 이내 차이였다. 중앙값 격차는 Jev 쪽으로 0.7%포인트였으나 통계적으로 유의하지 않았다(p=0.64). 반면 로컬에서 돌린 4억 2,100만 파라미터의 Laya는 대체로 낮았고, 중앙값 격차 13~15%포인트로 유의미했다(p