Microsoft-Decision-1 도입 전 Foundry에서 확인할 것

1. 선택지가 정해진 판단을 점수로 받는 모델

에이전트를 만들다 보면 이 문의를 어느 담당으로 보낼지, AI가 쓴 답변을 그대로 내보낼지처럼 정해진 선택지 중 하나를 고르는 단계가 생깁니다. Microsoft는 Command Line 블로그에서 이런 판단만 맡는 모델 Microsoft-Decision-1을 소개했고, 공식 글은 이 모델을 Microsoft Foundry와 OpenRouter에서 쓸 수 있다고 밝혔습니다. Foundry에서 에이전트의 분류·라우팅·승인 단계를 만드는 팀이라면 이번 소식을 검토해 볼 만합니다.

Microsoft CTO실의 소프트웨어 엔지니어링 부사장 Achint Srivastava가 쓴 이 글은 화면에 2026.10.09로 날짜가 표시됩니다. 반면 페이지 메타데이터의 발행 시각은 2026년 10월 10일 01시 35분 UTC, 한국 시각으로 10월 10일 오전 10시 35분입니다. 어느 쪽이 실제 발표 시점인지는 이 글에서 정하지 않고 두 값을 함께 적습니다. 원문에는 벤치마크를 추가하려고 처음 글을 고쳤다는 편집자 주도 붙어 있습니다.

공식 글은 이 모델이 하는 일을 이렇게 설명합니다. 고정된 답 선택지를 주면 Microsoft-Decision-1이 선택지마다 보정된 확률 점수(calibrated probability score)를 준다는 내용입니다. 문장을 새로 써 주는 생성형 모델과 달리, 미리 정한 선택지 목록 안에서 각 선택지가 맞을 가능성을 숫자로 받습니다.

2. 요청 형식과 생성형 모델을 계속 써야 하는 경우

날짜가 표시되지 않은 Microsoft Learn 사용 문서에 따르면 요청은 상황을 담는 state와 물을 내용을 담는 questions로 구성합니다. 질문 유형으로는 참·거짓 확률을 묻는 noul, 선택지별 확률을 묻는 choice, 순서가 있는 척도로 점수를 매기는 score가 있습니다. 같은 문서는 콘텐츠를 만들거나 요약하거나 다시 쓰거나 설명해야 하는 애플리케이션이라면 생성형 LLM을 쓰라고 안내합니다.

작성자 해석으로는 판단 단계만 따로 떼어 낼 수 있는 흐름에서 먼저 검토할 만합니다. 답변 작성은 기존 생성형 모델에 두고, 작성된 답을 통과시킬지 정하는 단계만 점수로 받는 구성을 생각해 볼 수 있습니다. 아래 그림은 공식 문서의 요청 형식에 작성자가 만든 예시 값을 넣어 이 흐름을 그렸습니다.

3. 공식 글이 든 쓰임새와 Copilot 팀 측정 사례

공식 글은 쓰임새로 모델 라우팅과 AI 판정을 듭니다. 모델 라우팅에서는 들어온 요청을 평가해 품질·비용·지연 시간 요구에 맞는 모델을 고르고, AI 판정에서는 AI가 만든 응답을 정해 둔 품질 기준으로 평가해 수락·수정·반려를 정합니다.

Copilot과 관련된 내용은 공식 글의 한 문장에 있습니다. Copilot 팀은 채팅과 에이전트 응답의 품질을 측정하는데, 그 시험에서 Microsoft-Decision-1이 GPT5.6 Luna와 견줄 만한 결과를 냈고 100배 빨랐다고 적었습니다. 이 문장은 Copilot 팀이 품질 측정 작업에 이 모델을 시험했다는 뜻으로 읽어야 합니다. Microsoft 365 Copilot이나 Copilot Studio에 이 모델이 들어갔다는 문장은 이번에 확인한 공식 자료에 없습니다.

성능 수치는 모두 Microsoft가 직접 측정해 발표한 값입니다. 공식 글은 학습에서 가려 둔 벤치마크 36개, 약 15만 문항을 비교한 결과 가장 높은 정확도를 냈고 GPT-6 Sol보다 35배 빨랐다고 밝혔습니다. Xbox Research가 피드백 1만 건 이상을 분류한 내부 사례에서는 GPT-6 Sol보다 14배 넘게 빠르고 비용은 200배 적었다고 적었습니다. 이 수치는 Microsoft의 비교 조건에서 나온 값이므로, 자기 업무에서도 같은 비율이 나온다고 가정하지 말고 직접 시험한 결과로 판단하십시오.

4. Foundry에서 쓰려면 준비할 것

Learn 문서에 따르면 Foundry에서 이 모델을 쓰려면 유효한 결제 수단이 등록된 Azure 구독, Foundry 프로젝트, 모델을 배포할 수 있는 권한인 Cognitive Services Contributor가 필요합니다. 배포 유형은 일부 리전에서 제공되는 DataZoneStandard와 GlobalStandard가 있고, 모델 버전은 1, API 종류는 Decision으로 적혀 있습니다. 문서의 절차는 이번에 직접 실행하지 않았습니다.

공식 글은 Qwen3.5-9B를 한 번의 처리로 빠르게 점수를 매기도록 추가 학습해 이 모델을 만들었고, 곧 Microsoft AI(MAI)와 OpenAI 모델 등을 기반으로 다시 만들 계획이라고 밝혔습니다. 작성자 해석으로는 기반 모델이 바뀌면 같은 질문에 대한 점수 분포도 달라질 수 있습니다. 점수 기준값을 정해 운영하려는 팀이라면 모델 버전이 바뀔 때 기준값을 다시 확인하는 절차를 처음부터 정해 두는 편이 좋습니다.

5. 공식 가격과 적혀 있지 않은 제공 조건

공식 글에 적힌 가격은 입력 토큰 100만 개당 0.042달러이고, 출력 토큰은 무료입니다. 작성자 해석으로는 결과가 선택지별 점수로 돌아오므로, 비용은 주로 state와 questions에 넣는 입력 길이에 따라 달라진다고 볼 수 있습니다.

제공 등급은 공식 글에 적혀 있지 않습니다. 원문은 Microsoft Foundry와 OpenRouter에서 쓸 수 있다고만 했고 정식 출시(GA)인지 프리뷰인지 밝히지 않았으므로, 이 글에서도 제공 상태를 정하지 않습니다. Foundry 청구에 적용되는 공식 가격표, 리전별 제공 범위, 쿼터, 무료 체험 여부는 공식 문서에서 확인하지 못했습니다. 예산을 잡을 때는 사용하는 Azure 구독의 가격 안내에서 다시 확인하십시오.

6. 공식 문서가 밝힌 한계와 이번 주에 해 볼 점검

Learn 문서는 한계도 적었습니다. 점수를 개인에 대한 결정의 유일한 근거로 쓰지 말라고 했고, 질문과 선택지를 어떻게 표현하고 어떤 순서로 두느냐에 따라 점수가 바뀔 수 있다고 했습니다. 판단 근거를 설명해 주지도 않습니다.

작성자 해석으로는 인사 평가나 대출 심사처럼 사람에 대한 결정에는 점수를 참고 자료로만 쓰고 최종 판단은 담당자가 하도록 흐름을 짜야 합니다. 문의 분류나 응답 품질 판정처럼 사람이 대상이 아닌 판단에 쓰더라도, 문구와 선택지 순서만 바꿨을 때 결과가 뒤집히는지 미리 시험해 두면 운영 중의 혼란을 줄일 수 있습니다. 반려 이유를 사용자에게 알려야 하는 업무라면 설명을 만드는 단계를 따로 두어야 합니다.

이번 주에는 운영 중이거나 만들고 있는 에이전트 흐름에서 선택지가 정해진 판단 단계 1곳을 고르십시오. 예시로 문의를 결제·배송·기타 중 어디로 보낼지 정하는 단계가 있습니다. 정답을 이미 아는 과거 사례를 50건 정도 모으고, 질문 문구와 선택지 목록을 적은 다음 선택지 순서만 바꾼 질문도 함께 만들어 두십시오. Foundry에서 시험하기 전에는 Azure 구독의 결제 수단, Foundry 프로젝트, 배포 권한부터 확인하면 됩니다. 기존 방식과 정확도, 응답 시간, 입력 토큰 수를 나란히 기록하면 이 단계를 점수 모델로 옮길지 판단할 근거가 생깁니다.