당신이 다른 사람의 private repository에서 작동하는 키를 발견하고, 등록 과정의 번거로움을 피하려고 그것을 프로토타입에 붙여넣으려 한다고 가정해 봅시다. 잠시 멈추세요. 작동하는 키와 '이 키가 무엇을 할 수 있는지, 그리고 누가 이 권한을 책임지고 검토하는지' 설명할 수 있는 키는 완전히 다른 두 가지 객체입니다. 전자는 당신을 문제가 발생하기 직전까지 빠르게 진행시키지만, 그 문제는 예측하거나 수정할 수 없는 종류의 문제입니다.

GitHub Models에 공식적으로 접근하는 가치는 단 하나의 속성에 달려 있습니다: 팀이 토큰의 용도와 경계를 보여줄 수 있어야 합니다. 만약 '이 토큰이 무엇을 할 권한이 있고 누가 이 권한을 검토하는지'라는 질문에 답할 수 없다면, 그 실험은 정의상 통제 불가능합니다—아무리 빨리 시작되었다 하더라도 말이죠.

다음으로는 GitHub Models에 대한 자체 테스트 접근 방식을 구축하고, 그것이 첫 번째 추론(inference)과 첫 번째 보안 검사를 모두 견딜 수 있도록 하는 방법에 대해 다루겠습니다.

타인의 키는 빠른 시작을 보장하지 않는다

불쾌한 메커니즘부터 시작하겠습니다. GitHub의 개인 토큰은 특정 개인의 자격 증명입니다. GitHub의 공식 계정 관리 보안 문서는 이를 명확하게 규정합니다: '개인 토큰을 다른 사람과 공유하지 마십시오'. 이것을 비밀번호처럼 취급해야 하며, 팀이 공유가 필요하다면 GitHub App이나 패스워드 매니저 또는 key vault(S6)와 같은 안전한 비밀 저장소를 사용해야 합니다. 즉, 토큰 공유는 회색 지대가 아니라 공급업체가 별도의 페이지를 만들어 경고하는 금지 사항입니다.

다음으로 자동화 시스템이 작동합니다. GitHub의 secret-scanning 시스템은 개인 토큰을 공개 리포지토리에서 발견하면 자동으로 취소하고 소유자에게 이메일로 알림을 보냅니다(S7). 당신이 열린 repository에서 찾은 '작동하는' 키는 언제든지, 그리고 당신의 스케줄에 맞춰서라도 회수될 후보입니다. 반면, 비공개 리포지토리에는 자동 취소 기능이 없습니다: 거기서는 경고 알림 내부에서 사람이 직접 'Report leak' 버튼을 눌러야 합니다. 따라서 사적인 유출은 더 오래 지속되고 조용하게 진행되며—그 결과는 키를 발견한 사람에게가 아니라 토큰의 소유자에게 돌아갑니다.

이 두 가지 사실을 결합하면, '무료 시작(free start)'은 예측 가능한 수명도, 명확한 범위(scope)도 없는 구조로 변질됩니다. 당신은 타인의 토큰이 모델 접근 권한 외에 어떤 추가적인 스코프(scope)를 갖는지 알 수 없습니다. 그 한도(limits)를 알 수 없습니다. 그것이 언제 회수될지도 알 수 없습니다. "무료 키는 큰 결과 없이 추론(inference)을 가속화한다"라는 논란의 여지가 있는 믿음은, 이 세 가지 불확실성 중 첫 번째를 마주하는 순간 무너집니다.

사람들이 "무료 키"를 찾을 때 실제로 찾는 것은 무엇인가?

타인의 접근 권한을 쫓는 행위는 상당히 좁은 범위의 문구들로부터 시작되며, 이 문구들은 그 필요성을 솔직하게 드러냅니다. 하나씩 분석해 보겠습니다. 거의 모든 문구 뒤에는 자신의 계정으로 이용할 수 있는 합법적인 경로가 존재합니다.

마지막 줄이 시사하는 바가 큽니다. 사람들은 gpt-5.3-codex-spark를 정확한 모델 이름인 것처럼 검색하는데, 이는 어딘가에서 그 이름을 들었기 때문이며, 그 후 "반드시 해당 모델을 지원하는" 키를 찾아 나섭니다. 차라리 최신 카탈로그를 열어 당신의 토큰으로 무엇을 사용할 수 있는지 확인하는 것이 더 현명합니다. 들은 모델 이름은 카탈로그가 이를 확인해주기 전까지는 가설로 남아있을 뿐입니다.

테스트 접근 권한 여권: 5가지 필드

실험을 통제 가능하게 만들려면 하나의 컴팩트한 산출물, 즉 '테스트 접근 권한 여권(passport of test access)'이 필요합니다. "나는 키를 가지고 있다"를 "나는 이 키가 무엇을 하는지 알고 있다"로 바꿔주는 다섯 가지 필드입니다. 필드의 구성은 GitHub 문서의 인용이 아니라 이 글의 독자적인 방법론이지만, 각 필드는 플랫폼의 검증 가능한 동작에 기반합니다.

여권의 다섯 줄: 목적(토큰이 생성된 이유), 범위(어떤 스코프(scope)와 어떤 리포지토리/조직을 포함하는지), 예상 거부(범위를 벗어났을 때 어떤 일이 일어나야 하는지), 소유자(토큰에 대해 책임지는 사람), 그리고 재검토(범위를 언제 다시 확인하는지)입니다. 첫 번째 추론(inference)을 수행하기 전, 시작 단계에서 이 여권을 작성해 두면 타인의 키를 위험하게 만드는 세 가지 불확실성에 모두 답할 수 있습니다.

“GitHub에 로그인함”과 “Models에 대한 유효한 자격 증명 (credentials)을 보유함” 사이의 차이는 여권이 가장 먼저 기록하는 사항입니다. Playground는 기존의 GitHub 계정으로 인증되며 별도의 키를 요구하지 않지만, API를 통한 프로그래밍 방식의 접근 (programmatic access)은 계정 설정(S1)에서 생성된 models 스코프 (scope) (classic) 또는 models: read 권한 (fine-grained)을 가진 개인용 액세스 토큰 (Personal Access Token, PAT)을 생성해야 합니다. 즉, “로그인 정보가 있음”과 “API용 자격 증명이 있음”은 두 가지 서로 다른 단계이며, 여권은 당신이 정확히 어떤 것을 가지고 있는지 명시하도록 강제합니다.

여권은 최신 제한 사항 (limits) 확인을 대신하거나 절대적인 보안을 보장하지는 않습니다. 여권이 하는 역할은 다릅니다. 팀에게 공통된 언어를 제공하여, “이 토큰이 원래 이 작업을 수행할 수 있어야 했나?”라는 감사 (audit) 질문에 단 1분 만에 답변할 수 있게 해줍니다.

PAT는 GitHub Actions의 토큰과 어떻게 다른가?

테스트를 위해 당신에게는 두 가지 서로 다른 합법적인 접근 소스가 있으며, 여권은 어떤 것이 사용되는지 명확히 명시해야 합니다. 첫 번째는 위에서 언급한 개인용 액세스 토큰 (Personal Access Token, PAT)입니다. 두 번째는 GitHub Actions 워크플로 (workflow) 내부의 자동화된 GITHUB_TOKEN입니다. 이 토큰은 워크플로의 permissions 블록에 models: read를 명시적으로 선언한 경우에만 GitHub Models에 접근할 수 있습니다. 자격 증명 자체는 기본적으로 존재하지만, 권한 범위 (scope)는 수동으로 활성화해야 하며 암시적으로 부여되지 않습니다 (S1).

이는 여권에 있어 미묘하지만 중요한 지점입니다. “자격 증명이 존재함”과 “자격 증명이 필요한 권한 범위를 가짐”은 다시 한번 두 가지 서로 다른 상태입니다. Actions의 토큰은 권한을 직접 작성하기 전까지는 기본적으로 모델에 접근할 수 없습니다. 따라서 Actions 시나리오에서 여권의 “권한 범위” 필드는 풀 리퀘스트 (pull request) 리뷰에서 확인할 수 있는 YAML 내의 구체적인 문자열이 됩니다.

# GitHub Actions: 내장 토큰을 통한 Models 접근
permissions:
  contents: read
...

개인용 토큰 (Personal Access Token)을 통한 프로그래밍 방식의 접근 시, 권한 범위 (scope)는 코드 내에서 설정하는 것이 아니라 토큰을 생성할 때 지정됩니다. 세분화된 토큰 (fine-grained token) 방식에서는 models: read 권한이 이에 해당하며, 클래식 (classic) 방식에서는 models 스코프 (scope)를 사용합니다. 엔드포인트 (endpoint) 호출은 해당 토큰을 헤더에 포함한 일반적인 HTTP 호출과 동일한 형태를 띱니다.

# 요청 헤더에 models 스코프를 포함한 개인용 토큰 사용
curl https://models.github.ai/inference/chat/completions \
  -H "Authorization: Bearer $GITHUB_MODELS_TOKEN" \
...

별도로, 정직한 패스포트 (passport)라면 반드시 기록해야 할 문서화의 경계 지점을 언급하고자 합니다. GitHub의 세분화된 토큰 (fine-grained token) 권한에 관한 일반 가이드에는 repo, org, 또는 actions가 나열된 것과 같은 방식으로 "models"라는 별도의 카테고리가 존재하지 않습니다. models 권한은 세분화된 PAT (Personal Access Token)의 일반 권한 카탈로그가 아니라, 바로 GitHub Models 문서에 기술되어 있습니다 (S5, F8). 이 두 영역을 동일한 것으로 간주해서는 안 됩니다. 이들은 서로 다른 곳에 문서화되어 있으며, 이는 추측하기보다 명확하게 기록해 두는 것이 좋은 미묘한 차이점입니다.

무료 티어 (free tier) 제한은 모델 클래스에 따라 다름

이제 사람들이 타인의 키를 자주 찾는 이유인 제한 사항 (limits)에 대해 알아보겠습니다. GitHub Models의 무료 레벨 (free tier) 제한은 단일하지 않으며, 모델 클래스 (class)에 따라 나뉩니다. 이 글을 작성하는 시점의 GitHub 문서 (S2)에 따르면, "Low" 모델은 분당 약 15회, 일일 150회의 요청을 제공합니다. "High" 모델은 분당 약 10회, 일일 50회의 요청을 제공하며, "Embedding" 모델은 분당 15회, 일일 150회의 요청을 제공하지만 요청당 토큰 상한선이 더 높습니다 (채팅 모델의 입력 약 8,000 / 출력 약 4,000 토큰 대비 약 64,000 토큰).

중요한 주의 사항: GitHub는 이 수치들을 명백히 "예고 없이 변경될 수 있음 (subject to change without notice)"이라고 표시하고 있으며, 게다가 이 수치들은 계정의 Copilot 플랜(Free, Pro, Business 또는 Enterprise (F4))에 따라 확장됩니다. 즉, 테스트 전에 기록된 어떤 한도 수치라도 상수로 간주하지 말고 테스트 시점에 다시 확인해야 합니다. 여권(Passport)에는 "재검토 (review)\

러시아 팀에게 있어 여기서 갈림길이 어디인지 주목하십시오. 두 경로 모두 해외 제공업체의 빌링 (billing) 문제에 직면하게 되며, 이는 이미 GitHub의 범위를 벗어난 문제입니다. 질문이 "GitHub 생태계 내부에서 실험하기"에서 "모델에 대한 작동 가능한 액세스를 얻고 그에 대한 비용을 지불하기"로 옮겨갔다면, 이는 다른 영역입니다. provod.ai — OpenRouter의 러시아 대안은 서비스 추가 수수료 없이 제공업체의 공식 가격으로 루블(ruble) 결제를 지원하며, 자체 카탈로그 모델들에 대한 단일 API를 제공합니다. OpenAI 호환 프로토콜을 지원하는 클라이언트는 코드를 다시 작성할 필요 없이 키(key)와 base_url만 변경하여 연결할 수 있습니다.

# 호환되는 호출: 키와 base_url만 변경되며, 클라이언트 코드는 이전과 동일함
from openai import OpenAI

...

여기서의 경계는 이 글 전체가 다루고 있는 것과 같습니다. 즉, 고유한 키를 가진 별도의 작업 정체성(working identity)이라는 점입니다. 이것은 당신의 GitHub Models 토큰의 범위를 단 1바이트도 확장하지 않으며, 여권(Passport) 상에서도 목적이 서로 다른 두 개의 별개 액세스입니다. 이들의 영역을 혼동하는 것은 타인의 키를 사용하는 것과 정확히 같은 오류입니다.

경계 확인 및 "예상되는 거부 (expected refusal)"

여권의 네 번째 필드인 "예상되는 거부"를 확인할 때 비로소 여권은 작업용이 됩니다. 여기서 소스의 정확성이 필요합니다. 이 사실 관계 세트 내의 어떤 GitHub 문서도 요청이 일일 또는 분당 한도를 초과하거나 토큰에 부여된 범위를 벗어날 때 어떤 코드나 메시지가 반환되는지 정확하게 설명하지 않습니다. 따라서 "경계에서의 예상되는 거부"는 GitHub에 인용된 동작이 아니라, 당신의 자체적인 실험을 통해 검증해야 하는 가설입니다.