리퀴드 d1 공개 — 글 대신 판단만 내놓는 결정 모델

「이 문의는 어느 팀으로 보낼까」 같은 판단에까지 글 쓰는 모델을 부르는 건 과합니다. 리퀴드가 답 대신 확률만 돌려주는 결정 모델 d1을 내놨습니다.

리퀴드가 첫 결정 모델 d1을 공개했습니다. 결정 모델은 글을 한 글자씩 써 내려가는 대신, 주어진 상황을 보고 정해진 선택지에 대한 확률을 한 번의 호출로 돌려주는 새로운 종류의 모델입니다. 출력 토큰을 아예 만들지 않아 값이 싸고 빠릅니다. 글 대신 판단을 다루는 이 흐름은 앞서 제브를 소개한 글에서 다룬 적이 있는데, d1은 그 결정 모델 계열의 새 제품입니다. 공식 문서를 기준으로 무엇이 다른지 정리했습니다.

짧게 정리하면

• 결정 모델은 분류·라우팅·점수 매기기를 한 번의 호출로 끝내고, 선택지마다 보정된 확률을 돌려줍니다.
• 글을 생성하지 않으니 출력 토큰이 0이고, 그만큼 값과 지연이 줄어듭니다.
• 질문은 예·아니오(노울), 여럿 중 하나(초이스), 눈금 매기기(스코어) 세 가지 유형으로 던집니다.

리퀴드 공식 문서의 결정 모델 안내와 이전 가이드를 기준으로 했습니다. 직접 호출해 성능을 재 보지는 않았고, 문서에 적힌 동작을 옮겼습니다.

질문 세 가지 유형

결정 모델에는 세 가지 모양으로 질문을 던집니다. 내 코드가 그다음에 무엇을 하느냐에 맞춰 고르면 됩니다. 분기하면 여럿 중 하나를, 기준값과 견주면 눈금을, 참·거짓으로 막으면 예·아니오를 씁니다.

리퀴드 공식 문서 기준, 질문 유형

유형	돌려주는 값
노울(예·아니오)	0과 1 사이 확률. 「이 메시지가 스팸인가」에 0.92처럼
초이스(여럿 중 하나)	선택지별 확률 분포. 「어느 팀이 맡나」에 요금 0.65·기술 0.30처럼
스코어(눈금 매기기)	정해진 단계 위의 확률 가중 위치. 「얼마나 급한가」에 1.85처럼

세 유형을 가르는 요령도 문서가 짚어 줍니다. 예·아니오에서 0.5는 「가장 애매한 상태」를 뜻할 뿐 정도를 말하지 않으니, 세기나 심각도처럼 정도를 재고 싶으면 눈금 매기기를 쓰라는 식입니다. 공통점은 모두 「확률」을 함께 준다는 것입니다. 단순히 「요금팀」이라는 딱지 하나가 아니라, 각 선택지가 얼마나 그럴듯한지와 전체적으로 얼마나 확신하는지를 같이 돌려줍니다. 그래서 확신이 낮으면 더 센 모델로 넘기는 식으로 뒤를 설계할 수 있습니다. 글 대신 선택지와 확률을 받는 구조가 기존 모델과 어떻게 다른지는 제브와 기존 모델의 차이 글에 더 풀어 뒀습니다.

기존 모델 호출과 무엇이 다른가

리퀴드 결정 모델 가이드 기준, 글 쓰는 모델과 비교

항목	글 쓰는 모델 → 결정 모델
결과물	생성한 글자를 딱지로 파싱 → 확률이 붙은 결정값
지연	글 길이·추론에 따라 늘어남 → 낮고 일정, 만들 토큰 없음
출력 토큰	한 단어 답에도 과금 → 0. 생성이 없음
불확실성	없거나 믿기 힘든 자가 보고 → 보정된 확률을 매번 제공

쓰기 시작하려면 리퀴드 콘솔에서 키를 발급해 환경 변수로 넣고, 모델 이름에 무료 등급을 가리키는 값을 넣어 호출하면 됩니다. 정확한 호출 형태와 소프트웨어 개발 키트 사용법은 공식 결정 모델 문서에 그대로 나와 있습니다. 응답에는 출력 토큰이 항상 0으로 찍히고, 들어간 입력 토큰만 집계됩니다.

어디에 쓰고 어디에 안 쓰나

문서가 꼽은 적합한 자리는 분명합니다. 문의·이메일·요청을 알맞은 곳으로 보내는 라우팅, 들어온 내용을 갈래로 나누는 분류, 급한 정도를 재는 점수 매기기, 먼저 걸러내는 선별, 올라온 글을 살피는 내용 검열, 안전 점검, 그리고 모델에게 「이게 맞는 답인지 평가해 줘」라고 맡기던 심사를 대신하는 일입니다. 공통점은 답이 미리 정해진 목록 안에 있다는 것입니다.

반대로 결정 모델이 맞지 않는 자리도 문서가 명확히 적어 두었습니다. 자유로운 글쓰기, 창작, 여러 번 주고받는 대화, 여러 단계를 밟아야 하는 복잡한 추론, 열린 질문에 대한 답, 요약, 코드 작성이 그렇습니다. 이런 일은 결국 글을 생성해야 하므로 글 쓰는 모델을 써야 합니다. 그래서 d1은 글 쓰는 모델을 대체한다기보다, 그 앞뒤에서 「판단만 떼어 맡는」 조각으로 끼워 넣는 쓰임에 가깝습니다. 라우팅처럼 자주 불리는 자리를 결정 모델로 바꾸면, 값싼 판단이 앞에서 거르고 비싼 생성은 꼭 필요할 때만 부르는 구조가 됩니다.

모든 일을 결정 모델로 바꾸려 하면 안 됩니다. 문서는 답이 미리 정해진 「경계가 있는 판단」일 때만 결정 모델이 맞는다고 못 박았습니다. 분류, 문의 라우팅, 점수 매기기, 선별, 내용 검열, 안전 점검, 심사 대체처럼 선택지가 정해진 일이 그렇습니다. 반대로 자유로운 글쓰기, 여러 번 오가는 대화, 복잡한 다단계 추론, 요약, 코드 작성은 여전히 글 쓰는 모델의 몫입니다. 둘을 갈라 쓰는 게 핵심입니다.

자주 묻는 질문

출력 토큰이 0이면 정말 공짜인가요

출력 토큰은 0으로 찍히지만, 상황과 질문을 읽어 들이는 입력 토큰은 집계됩니다. 문서에는 무료 등급을 가리키는 모델 이름이 쓰여 있으니, 실제 과금 조건은 리퀴드 콘솔에서 확인하는 편이 안전합니다. 핵심은 「한 단어 답에도 붙던 출력 토큰 값이 사라진다」는 점입니다.

언제 결정 모델을 쓰면 좋나요

답이 미리 정해진 선택지 안에 있을 때입니다. 문의 분류, 담당 라우팅, 긴급도 점수, 내용 검열, 모델에게 맡기던 심사 대체 같은 일이 대표적입니다. 반대로 열린 답이 필요하면 글 쓰는 모델을 그대로 쓰세요. 실제로 어떻게 끼워 쓰는지는 제브 활용 사례를 참고하면 됩니다.

확률이 왜 중요한가요

딱지 하나만 받으면 틀렸는지 알 길이 없지만, 확률을 함께 받으면 기준값을 정해 애매한 경우를 걸러낼 수 있습니다. 확신이 낮으면 더 센 모델로 넘기거나 사람에게 돌리는 식으로, 같은 입력에도 판정이 덜 흔들리게 만들 수 있습니다.

글 쓰는 모델 하나로 모든 걸 처리하던 습관을 되돌아보게 하는 제품입니다. 저라면 지금 글 쓰는 모델에게 「분류해 줘」, 「어디로 보낼까」, 「몇 점짜리야」처럼 시키는 호출부터 찾아, 그중 답이 정해진 것들을 결정 모델로 옮겨 보겠습니다. 값과 속도가 눈에 띄게 줄고, 확률 덕분에 애매한 경우를 다루기도 쉬워집니다. 같은 회사의 다른 모델 소식은 리퀴드 디스파크 글에 정리해 뒀습니다.

확인한 곳: 리퀴드 공식 문서 「결정 모델」과 「결정 모델 가이드」(세 가지 질문 유형, 출력 토큰 0·입력 토큰 집계, 글 쓰는 모델과의 비교표, 적합·부적합 용도, 무료 등급 모델 이름). 2026년 10월 1일 기준이며, 과금 조건은 변동될 수 있습니다.