Gemini Decision vs Gemini Decision 1: 하나는 이름이고, 하나는 모델 ID입니다

검색어: Gemini Decision — 출시 관련 보도, 리더보드 항목, 가격 행, API 참조가 나오며, 모두 같은 것을 조금씩 다른 단어로 표현합니다. 검색어: Gemini Decision 1 — 실제로 작동하는 모델 ID가 나옵니다. 두 문자열은 한 글자만 다르지만 코드에서는 완전히 다르게 동작합니다. 하나는 사람들이 제품을 부르는 이름이고, 다른 하나는 POST /v1beta/decisions가 받아들이는 유일한 값입니다. 분명히 존재하는 모델이 왜 찾을 수 없는지 궁금한 채로 404에 오후를 통째로 허비한 적이 있다면, 이 글이라면 그 시간을 아껴 줬을 것입니다.

이 혼란은 특정 누군가의 실수라기보다는, G​oogle이 2026년 11월 11일 한 번의 릴리스에서 모델, 엔드포인트, 패밀리 이름을 함께 내놓았고 이 세 가지를 모두 언급할 때 자연스러운 방식이 이름을 줄여 쓰는 것이기 때문에 생긴 일이다. 그렇게 줄여 쓰는 것은 산문에서는 통하지만 요청 본문에서는 실패하며, 이 두 사실 사이의 간극이 다음 달 동안 이 범주에서 발생할 대부분의 지원 티켓이 나오는 지점이다.

두 이름이 무엇으로 해석되는지

매핑부터 시작하세요. 다른 모든 것은 그것에서 비롯되니까요.

• Gemini Decision — 제품명입니다. 이는 의사결정 모델 라인을 가리키며, Google 자체 문서에서는 산문의 제품군 레이블로, 모델 카드 제목에서, 그리고 "Gemini Decision에서만 사용 가능"과 같은 문장에 등장합니다. 모델 ID가 아니고 그 뒤에 별칭도 없으며, 이를 모델로 전달하면 제품군의 최신 구성원으로 폴백되지 않고 알 수 없는 모델 오류가 반환됩니다.

• Gemini Decision 1 — 모델 및 ID gemini-decision-1입니다. 이것이 작동하는 값입니다. Decisions API가 제공하는 유일한 모델이며, 문서에 명시되어 있습니다: 엔드포인트는 G​emini Decision 1에서만 사용할 수 있습니다.

두 이름, 하나의 모델, 그리고 그 둘 사이에는 별칭이 없습니다. 마지막 부분이 특이한 점입니다. 대부분의 Google 모델 패밀리는 이동 별칭과 고정 ID를 제공합니다. 즉 프로토타입용 -latest 형태와 프로덕션용 날짜 또는 번호 형태입니다. 이 모델은 고정 형태만 제공하므로, 패밀리에 유동적인 헤드가 있다고 가정해 구축된 코드 경로는 새 버전을 조용히 추적하는 대신 여기서 실패하게 됩니다.

두 번째 이름이 계속 나타나는 곳

이 모호성이 계속 설득력을 갖는 이유는 세 개의 별도 시스템이 이 모델을 설명하면서 그중 어느 것도 동일한 명명 규칙을 공유하지 않기 때문이다.

가격 책정 페이지에는 해당 모델 자체의 이름 아래에 요금과 함께 출력이 적용되지 않는다는 참고 사항이 나와 있습니다. API 참조 문서는 엔드포인트를 설명하고, 모델 이름을 모델 표가 아니라 사용 가능 여부를 설명하는 문장에서 언급합니다. 해당 모델을 벤치마크하는 독립 리더보드는 행과 차트에 읽기 쉬운 이름을 사용합니다. 이 중 어느 것도 잘못된 것은 아니며, 어느 것도 모델 id가 아니므로 이들 중 어느 곳에서든 요청 본문으로 복사하면 동일한 실패가 발생합니다.

시간이 지날수록 더 중요해질 네 번째 변동 요인이 있습니다: 다른 사람들이 쓴 글입니다. 출시 보도, 튜토리얼, 포럼 답변은 모두 그 이름을 줄여 쓰고, 그중 일부는 id처럼 보이는 것—소문자, 하이픈 포함, 그럴듯한—으로 줄입니다. 해결책은 그중 어느 것도 신뢰하지 않는 것입니다. 엔드포인트에 물어보세요.

주어진 키가 실제로 무엇을 호출할 수 있는지 확인하는 방법

요청을 작성하기 전에 해당 키가 사용할 수 있는 모델을 나열하세요. Generative Language API의 표준 list-models 호출은 프로젝트에서 사용 가능한 모델을 해당 ID와 함께 반환하며, 한 번 실행하면 해당 키에 대해서는 이 질문이 영구적으로 해결됩니다.

gemini-decision-1이 나타나면 액세스 권한이 있는 것이며, 요청에는 바로 그 문자열을 넣어야 합니다. 나타나지 않는다면 문제는 철자가 아니라 권한이나 지역에 있는 것이므로, 이름을 아무리 바꿔도 소용없습니다. 그 목록에서 찾을 수 없는 것은 gemini-decision이라는 항목인데, 그런 모델은 존재하지 않기 때문입니다.

두 번째 점검은 응답에 대한 것입니다. 성공적인 결정 응답은 해당 응답을 처리한 모델을 식별하므로, 자체 요청 id와 함께 model 필드를 기록하는 파이프라인은 몇 달 후에도 구성을 다시 읽지 않고 "어떤 모델이 이 답변을 생성했는가"에 답할 수 있습니다. 그것은 누군가 결정이 왜 바뀌었는지 처음 묻고, 솔직한 답이 별칭이 옮겨졌다는 것임을 알게 될 때까지는 잡무처럼 들립니다.

이 모호함이 실제로 초래하는 세 가지 실수

• 알 수 없는 모델 404. 뻔한 사례다. 요청 본문에 gemini-decision이 있으면 권한 문제처럼 읽히지만 실제로는 그렇지 않은 오류가 반환된다. 오류가 프로젝트가 아니라 모델을 언급한다면, 결제 계정을 확인하기 전에 그 문자열부터 확인하라.

• 은밀한 별칭 가정. 발견하기가 더 어렵습니다. -latest 관례를 체득한 팀은 패밀리 이름과 해석 단계로 구성을 작성하며, 해석 단계는 별칭이 없으면 조용히 리터럴 패밀리 이름을 반환합니다. 그러면 실패는 배포 시점이 아니라 첫 실제 요청에서 드러나는데, 이는 실패가 나타날 수 있는 최악의 시점입니다.

• 잘못된 엔드포인트 가정. 모델이 존재하고 이름도 올바르기 때문에 더욱 미묘합니다. gemini-decision-1을 일반적인 generate-content 엔드포인트로 보내도 여전히 실패합니다. 이 모델은 그런 방식으로 호출할 수 없습니다. 이 모델은 decisions 엔드포인트에서 확률만 출력하는 대상이며, 산문을 요청하는 요청은 이 모델이 생성하지 않는 것을 요구하는 것입니다. 채팅 완성을 기본으로 하는 모든 클라이언트 라이브러리는 명시적인 경로가 필요합니다.

이것이 단지 모델의 이름만이 아니라 모델 자체에 대해 말해주는 것

이름 지정은 실제 설계 결정의 증상일 뿐이며, 그 결정은 이것이 출력 형식만 다른 채팅 모델이 아니라는 것입니다. 채팅 모델은 텍스트를 반환하므로, 모두 동일한 스키마를 사용하는 제공자, 프록시, 게이트웨이 사이에서 그 id를 자유롭게 교체할 수 있습니다. 사용자가 정의한 타입 지정 질문에 대해 보정된 확률을 반환하는 모델에는 그런 공통 스키마가 없으며, 그 id는 하나의 요청 형태를 가진 하나의 엔드포인트에 묶여 있습니다.

그것이 이 패밀리에 아직 플로팅 별칭도, 두 번째 멤버도 없는 이유입니다: 호환될 대상이 없기 때문입니다. 이는 또한 그 모델을 단순히 범용 라우터에 추가할 수 없는 이유를 설명합니다. OrcaRouter는 gemini-decision-1을 제공하지 않습니다. 확률만 제공하는 엔드포인트는 채팅 완성 대상이 아니며, 해당 스키마를 사용하는 키 뒤에 그것을 두는 것은 라우팅 계층이 지킬 수 없는 약속이 되기 때문입니다. 우리가 결정 공간에서 제공하는 것은 TypeSafe의 typesafe/jev-1.14이며, 이는 카탈로그의 다른 모든 것과 동일한 인터페이스를 통해 호출할 수 있는 결정 모델입니다.

라우터가 실제로 담당하는 의사결정 파이프라인의 부분은 초안 작성 절반입니다 — 후보 답변이나 이후 채점자가 평가할 루브릭을 생성하는 생성 호출입니다. 해당 호출은 한 엔드포인트에서 200개 이상의 모델에 걸쳐 실행되며, 제공업체 정가가 0% 마크업으로 그대로 전달됩니다, 그리고 바로 이 호출에서 공급업체를 바꾸는 것이 재작성이 아니라 구성 변경이 됩니다. 반면 채점 호출은 설계상 하나의 엔드포인트에 묶여 있으며, 정직한 아키텍처는 이를 우회할 대상이 아니라 고정 의존성으로 취급합니다.

양식에서 두 문자열 중 하나를 선택하는 경우

이 질문에는 식별자와 전혀 관계없는 버전이 있으며, 표현 방식이 그런 해석을 유도하기 때문에 직접 답할 가치가 있습니다. 누군가 "G​emini Decision"을 "G​emini Decision 1"과 비교하면서 더 오래된 제품과 더 새로운 제품, 두 제품을 보고 있다고 믿고 어느 것을 도입할지 알고 싶어 할 수 있습니다. 하지만 제품은 하나뿐입니다. G​emini Decision 1 이전에 출시된 G​emini Decision이라는 것은 없으며, 더 짧은 이름은 현재 구성원이 하나뿐인 제품군의 제품군 라벨입니다.

실질적인 결과는, 두 제품을 각각 별도의 항목으로 나열한 비교표나 리뷰, 벤치마크는 모두 같은 모델을 두 번 설명하고 있다는 것입니다. 두 개의 행, 하나의 모델, 하나의 가격. 두 행의 수치가 서로 다르다면, 그것은 서로 다른 것을 측정한 것이 아니라 둘 중 하나가 최신 정보가 아니라는 뜻입니다.

결론은

모든 요청 본문, 엔드포인트 경로, 구성 값에는 gemini-decision-1을 사용하고, 사람이 읽는 곳에서만 "G​emini Decision"을 사용하세요. 대체할 별칭은 없고, 더 짧은 이름 뒤에 숨은 두 번째 모델도 없으며, 더 긴 이름으로 가는 chat-completions 경로도 없습니다. 이걸 틀렸을 때의 비용은 작습니다 — 404 하나, 혼란스러운 오후 하나 — 하지만 별칭이 있다고 가정하는 비용은 더 큽니다. 그 실수는 리뷰를 통과해 프로덕션에서 실패하기 때문입니다. id를 고정하고, 응답이 명시하는 모델을 로그에 남기고, 패밀리 이름은 산문으로 취급하세요.