요금표는 구매의 핵심 질문에 답하지 못합니다: 필요한 권한과 허용 가능한 비용 내에서 필요한 통합이 제대로 작동할 것인가? 토큰 패키지 페이지를 열어 가격 범위를 확인하고 예산을 승인하지만, 한 달 뒤에 알고 보니 지정된 scope(범위)가 키 유형과 일치하지 않거나, 인증서가 운영 서버에 설치되지 않았거나, 실제 시나리오를 구축하지 못해 결제한 계정의 절반이 유휴 상태로 남아 있는 상황이 발생합니다.

이 글은 가격을 단순히 나열하는 것이 아니라, 구매를 정당화해야 하는 기업 기술 리더(Tech Lead)를 위한 글입니다. 논지는 단호하며 검증 가능합니다: 만약 선택한 하나의 비즈니스 시나리오가 권한, 통합 또는 예산 측면에서 통과되지 않는다면, 대규모 구매는 정당화될 수 없습니다. 이어지는 내용은 하나의 시나리오를 통해 측정 가능한 카나리(Canary) 모델을 구축하는 방법, 액세스 패스포트(Access Passport)에 무엇을 포함해야 하는지, 그리고 기술적 상태와 예산 상태를 어떻게 분리할 것인지에 대해 다룹니다.

요금제가 작동하는 결합을 증명하지 못하는 이유

제가 반박하는 논쟁적인 기본 통념은 다음과 같습니다: "기업용 요금제가 비즈니스 통합의 준비성을 증명한다." 그렇지 않습니다. 요금제는 토큰당 가격과 패키지 유효 기간을 설명할 뿐, 실제 도입 과정에서 발목을 잡는 세 가지 요소에 대해서는 침묵합니다.

모든 것은 액세스 권한(Access Rights)에서 시작됩니다. 법인 및 개인 사업자를 위한 두 가지 버전의 API 액세스(scope)가 존재합니다: 선불 패키지 작업을 위한 GIGACHAT_API_B2B와 후불 결제를 위한 GIGACHAT_API_CORP입니다. 지정된 scope가 실제 키 유형 또는 계정과 일치하지 않으면 인증 오류가 발생합니다 (Sber Developers 문서 기준, 2026년 7월 18일 확인). 요금제 페이지에는 이 내용이 적혀 있지 않습니다. 패키지를 결제하더라도 코드가 잘못된 scope로 요청을 보내면 거부될 수 있습니다.

다음은 첫 번째 요청을 보내기 전에 발생하는 기술적 장벽입니다. 법인 또는 개인 사업자는 작업을 시작하기 전에 디지털 서명 센터(NUC)의 인증서를 설치해야 합니다. 이는 키를 받기 전 단계로 진행되는 별도의 절차입니다 (Sber Developers, 2026년 7월 18일). 개발자의 노트북에서는 즉시 눈에 띄지 않을 수 있지만, 고객사의 폐쇄망(Closed Circuit) 환경에서는 인증서가 주요 장애물이 되는 경우가 많습니다.

그리고 마지막으로, 예산을 확인하는 방식 자체도 요금제(Tariff)에 따라 달라집니다. GET /balance 엔드포인트는 선불 패키지(Prepaid packages)를 사용하는 계정에 대해서만 잔여 토큰을 반환합니다. 사용한 만큼 지불하는 종량제(Pay-as-you-go) 방식의 경우, 동일한 요청에 대해 403 Permission Denied를 반환합니다 (Sber Developers, 2026년 7월 18일). 지출 제어는 선택한 결제 모델에 의해 결정되며, 이는 가격표(Price list)에 명시되어 있지 않습니다.

기업용 카나리(Canary) 여권: 세 개의 시트

카나리(Canary)란 대규모 계약을 체결하기 전에, 실제 호출과 견적 산출까지 완료해 보는 하나의 제한된 시나리오를 의미합니다. 여권(Passport)은 기술적 상태와 비용적 상태가 '작동하는 것 같다'는 식의 모호한 상태로 뒤섞이지 않도록, 카나리의 결과를 세 가지 섹션으로 기록하는 문서입니다.

여권 자체는 제가 만든 독자적인 도구이며, 그 어떤 문서 페이지에도 존재하지 않습니다. 소스(Sources)는 액세스 권한, 토큰, 오류에 대한 사실을 제공하지만, 이를 하나의 검증 가능한 산출물(Artifact)로 모아야 한다는 결론은 Sber Developers의 인용구가 아닌 저의 규범적 입장입니다. 이 방법론을 지탱하는 가설 또한 가설이라고 명시했습니다. 즉, 꼼꼼하게 읽은 가격표보다 하나의 실제 연결(Connection)이 접근 불가능한 권한이나 수용 불가능한 비용을 드러낼 가능성이 더 높다는 것입니다. 이를 증명할 수 있는 것은 저의 글이 아니라 여러분의 실행(Run)뿐입니다.

여권은 세 개의 시트로 구성됩니다. 액세스 시트(Access sheet): 어떤 스코프(Scope)가 요청되었는지(선불형 GigaChat B2B 또는 기업용 후불제), 디지털 서명 인증서(NUЦ Минцифры)가 설치되었는지, 인증 키(Authorization key)가 어떻게 구성되었는지 기록합니다. 토큰 모델 시트(Token model sheet): 어떤 라인업이 선택되었는지, 동기(Synchronous) 또는 비동기(Asynchronous) 모드인지, 전형적인 시나리오 요청 한 번에 토큰을 얼마나 소비하는지, 그리고 하루에 그러한 요청이 몇 건 발생하는지 기록합니다. 통합 로그 시트(Integration log sheet): 실제 실행 시 어떤 응답 코드(Response codes)가 반환되었는지, 그리고 그중 어떤 것이 정상적인 것이고 어떤 것이 차단(Blocking) 요소인지 기록합니다.

각 시트는 별도의 준비 상태를 제공합니다. '기술적 통과'와 '견적 통과'는 서로 다른 셀(Cell)에 존재합니다. 이는 당연한 결과입니다. 기술적으로는 작동할 수 있지만 경제적으로는 수용 불가능할 수 있으며, 그 반대의 경우도 존재할 수 있기 때문입니다.

여권(Passport)은 벤더(Vendor)에 종속되지 않습니다. OpenRouter의 현지 대안인 provod.ai와 같은 러시아 애그리게이터(Aggregator)를 포함하여, 어떤 모델에 접속하든 동일한 세 장의 시트가 작성됩니다. 셀의 값은 바뀌지만 셀 자체는 바뀌지 않으므로, 마지막에 동일한 양식으로 옵션들을 비교할 수 있습니다.

액세스 구조: 스코프(Scope), 키(Key), 그리고 인증서(Certificates)는 어떻게 구성되는가?

액세스 시트는 모델의 첫 번째 응답을 확인하기도 전에 먼저 통과해야 합니다. 여기서의 장벽은 순수하게 기술적인 것이며, 요금제 표에는 이 중 어느 것도 설명되어 있지 않습니다.

인증 키(Authorization key)는 GigaChat API 프로젝트의 클라이언트 ID(Client ID)와 클라이언트 시크릿(Client Secret)으로 구성된 Base64 문자열입니다. 프로젝트는 Studio 내에서 생성되며, 이는 많은 이들이 'GigaChat 개인 계정 API'로 검색하는 바로 그 섹션입니다. 키는 한 번만 표시되며 계정 내에 다시 저장되지 않습니다. 이 키로 발급받은 액세스 토큰(Access token)은 30분 동안 유효하며, 토큰 발급 요청은 초당 10회를 초과할 수 없습니다 (Sber Developers, 2026년 7월 18일 확인). 여권(Passport) 작성을 위한 실질적인 결론은 다음과 같습니다: 시크릿 저장소(Secret-storage)에는 토큰이 아닌 '키'를 저장하고, 타이머에 따라 토큰을 갱신하는 로직을 설계하십시오. 그렇지 않으면 30분 후 운영 환경(Production)에서 아무런 문제 없이 작동하던 시나리오가 갑자기 중단될 것입니다.

다음은 스코프(Scope)입니다. 'GigaChat 연결하기'에 대한 가이드는 수십 개가 넘지만, 거의 대부분은 단일 스레드를 사용하는 개인을 대상으로 합니다. 법인의 경우 결제 유형에 따라 경로가 나뉩니다: 선불 패키지는 GIGACHAT_API_B2B이며, 후불제는 GIGACHAT_API_CORP입니다. 여기서 발생하는 실수는 비용이 많이 듭니다. 코드는 완벽할 수 있지만, 계정과 선언된 액세스 권한이 일치하지 않으면 결국 인증 단계에서 모든 것이 무너집니다.

인증서(Certificates) 설치 후의 작업 호출(Working call)을 도식화하면 다음과 같습니다. 먼저 토큰을 받고, 그다음 모델에 요청을 보냅니다:

# 1. 인증 키를 통해 액세스 토큰(access-token) 받기 (Base64 Client ID:Client Secret)
curl -X POST https://ngw.devices.sberbank.ru:9443/api/v2/oauth \
  -H "Authorization: Basic <ВАШ_КЛЮЧ>" \
...

운영 환경(prod)에서 스크립트가 실행될 머신에 민츠프리(Mintsifry) 국가 인증 센터(NUC) 인증서가 설치되어 있다는 사실을 반드시 명심하세요. 로컬 환경에만 설치해서는 안 됩니다. Sber GigaChat API 도입이 폐쇄망(closed circuit) 환경에서 가장 자주 막히는 지점이 바로 여기입니다. 코드는 준비되었지만, TLS 핸드셰이크(TLS handshake)가 통과되지 않는 것이죠. LM Studio를 사용하든 메모장에서 작업하든, 프롬프트를 로컬에서 테스트할 때는 이 장벽을 전혀 인지할 수 없습니다.

예산 산출: 가격 범위에서 단일 시나리오 비용까지

토큰 모델 리스트는 카나리(canary) 프로젝트가 존재하는 근본적인 이유입니다. 지출의 한계는 가격표를 통해 알 수 있지만, 특정 시나리오의 실제 비용은 실제 프롬프트에 사용되는 실제 토큰 양을 통해서만 확인할 수 있습니다.

법인 및 개인 사업자를 위한 GigaChat API 가격이 게시된 공식 페이지(Sber Developers, 2026년 7월 18일 확인)에는 두 가지 결제 모델이 설명되어 있습니다. 선불 토큰 패키지는 결제일로부터 12개월 동안 유효하며, 오퍼(offer) 또는 계약을 통해 체결됩니다. 사용량에 따른 월별 결제(pay-as-you-go) 방식은 사용량이 있을 경우 월 최소 기본 요금 600루블이 부과됩니다.

패키지는 라인업별로 구분됩니다: GigaChat Lite (3억10억 토큰, 19,50065,000 ₽), GigaChat Pro (5,000만10억 토큰, 25,000500,000 ₽), 그리고 GigaChat Max (3,000만10억 토큰, 19,500650,000 ₽)이며, 임베딩(embeddings)은 별도 패키지로 판매됩니다. Pay-as-you-go 방식의 경우 1,000토큰당 가격은 모델마다 다르며, 비동기(asynchronous) 처리는 동기(synchronous) 처리보다 50% 저렴합니다. 여기서 예산 산출의 직접적인 변수가 발생합니다. 동일한 시나리오라도 GigaChat Max API를 선택하느냐 Lite를 선택하느냐, 그리고 어떤 모드로 호출을 보내느냐에 따라 GigaChat 토큰 비용은 몇 배씩 차이가 날 수 있습니다.

GigaChat API 명세서에서 비용은 다음과 같은 한 줄의 수식으로 요약됩니다: 전형적인 요청당 토큰 수 × 일일 요청 수 × 30 × 라인업 및 모드별 가격. 가격표는 이 공식의 승수(multipliers)만을 제공합니다. 또한 페이지의 수치들은 명확하게 업데이트 가능한 것으로 표시되어 있으므로, 계산 직전에 해당 링크를 통해 요금 및 조건을 최신 상태로 다시 확인해야 합니다.

팀 단위의 대안이 GigaChat과 동일한 것은 아닙니다. Sber의 모델은 Sber에만 존재하며, 하나를 다른 하나로 대체하는 것은 공정하지 않습니다. 하지만 시나리오가 반드시 해당 모델을 요구하지 않는다면, 견적서의 두 번째 열을 애그리게이터(aggregator)를 기준으로 계산하여 동일한 명세서를 작성하는 것이 의미가 있습니다. provod.ai의 액세스 리스트는 더 간결합니다. API가 OpenAI 및 Anthropic의 SDK와 호환되므로, 인증서나 결제 유형에 따른 스코프(scope) 선택 없이 API 키와 base_url만 변경하여 카나리(canary) 테스트를 이전할 수 있습니다. 토큰 모델 리스트 또한 계산 방식이 다릅니다. 제공업체의 가격에 추가 마진이 붙지 않으며, 조직은 하나의 잔액을 사용하고, 러시아 카드, SBP(Fast Payment System) 또는 증빙 서류가 포함된 계좌 이체로 결제할 수 있습니다 (제품 관련 사실은 소유자에 의해 확인됨, 2026년 7월 15일).

# 동일한 클라이언트, 다른 업스트림(upstream): 키와 base_url 변경
from openai import OpenAI
client = OpenAI(api_key="ВАШ_КЛЮЧ", base_url="https://api.provod.ai/v1")

카나리(canary) 테스트는 어떤 오류를 잡아내는가?

GigaChat 통합이 깨질 때, 거부 응답은 타입화된 코드로 전달됩니다. 이를 통해 로그 시트는 모호한 "작동하지 않음"을 명세서의 구체적인 미통과 항목으로 변환해 줍니다. 오류 코드는 문서(Sber Developers, 2026년 7월 18일)에 기술되어 있으며, 명세서에 거의 그대로 적용됩니다.

기본적으로 법인 및 개인 사업자(IP)에게는 10개의 동시 요청 스트림이 허용됩니다 (개인은 1개). 증설은 gigachat@sberbank.ru로 별도 요청을 통해서만 가능합니다 (Sber Developers, 2026년 7월 18일). 모델의 자체 콘텐츠 제한 설정 또한 동일한 이메일을 통한 별도의 관리적 단계가 필요하며, 이는 요금제 표에 명시되어 있지 않습니다. 이 두 가지 사실은 한 가지를 의미합니다. 즉, 단일 시나리오를 벗어나는 순간 가격표에는 전혀 없는 서신 교환과 승인 절차에 부딪히게 된다는 것입니다.

GET /balance에 대한 403 오류에 대해 별도로 설명하자면: 만약 후불제 시나리오라면, 해당 엔드포인트(endpoint)를 통해 표준적인 방식으로 예산 잔액을 확인할 수 없습니다. 해당 요금제 유형에 대해 이 엔드포인트가 작동하는 방식이 그러하기 때문입니다. 따라서 후불제에서는 명세서상의 지출 제어가 요청마다 토큰을 자체적으로 기록하고 계산하는 방식에 의존하게 됩니다.

이제 어떤 시나리오를 검증할지 선택해야 합니다. 카나리(canary) 테스트는 정확히 하나만 가져갑니다. 팀은 보통 다음과 같은 수많은 가설과 함께 찾아옵니다: 고객 지원용 GigaChat 텔레그램 봇, 내부 알림용 GigaChat 텔레그램 봇, 메신저 MAX용 GigaChat 내의 봇, n8n GigaChat을 통한 프로세스 자동화, GigaChat Agent Navigator를 통한 오케스트레이션(orchestration). 개발자들은 자신만의 요구사항을 추가합니다: 어떤 이들은 n8n과 GigaChat을 연결하는 준비된 노드(n8n GigaChat node)가 있는지 묻고, 다른 이들은 기존 클라이언트를 다시 작성하지 않기 위해 GigaChat OpenAI API가 필요하다고 합니다. 이러한 욕망의 전시장은 계획이 되지 않습니다. 그것은 대기열로 변할 뿐입니다. 대기열의 첫 번째 항목이 카나리 테스트로 들어가 응답 코드로 도출되며, 나머지는 기다립니다. 하지만 그 대가로, 검증 과정을 처음부터 다시 발명하는 대신 이미 검증된 명세서 템플릿을 채워 넣게 됩니다.