관리자 설정
관리자 설정
LLM Gateway를 활성화하고 사용자 접근을 부여하기 위한 일회성 조직 설정 방법을 알려드릴게요.
참고: LLM Gateway는 베타 상태입니다.
공식 조직에서 LLM Gateway를 활성화하기 위한 일회성 설정입니다. 개별 사용자가 게이트웨이를 통해 호출을 라우팅하기 전에 조직 관리자가 완료해야 합니다.
출처: 문서
본문
사전 요구사항
LangSmith에서 organization:manage 권한이 필요합니다. 2단계 옵션 A는 RBAC(커스텀 역할)를 포함하는 요금제도 필요합니다.
1. 프로바이더 시크릿 추가하기
LangChain 호스팅 모델은 이 단계를 건너뜁니다: LangSmith API 키를 사용하며 프로바이더 시크릿이 아닙니다. 유료 채팅 모델은 Gateway Credits를, SemIf는 의사결정 모델을 참고하세요. 게이트웨이 접근을 부여하려면 2단계로 계속하세요.
게이트웨이는 워크스페이스의 Provider Secrets에서 프로바이더 API 키를 해석합니다 — 이것이 개별 사용자가 프로바이더 키의 로컬 사본을 보유하지 않고도 업스트림 프로바이더로 호출을 프록시하는 방식입니다.
Settings > Integrations > Provider Secrets로 이동해 게이트웨이를 통해 프록시하려는 프로바이더의 키를 추가합니다:
| Secret name | Provider |
|---|---|
ANTHROPIC_API_KEY |
Anthropic |
AWS_BEARER_TOKEN_BEDROCK |
AWS Bedrock |
AZURE_FOUNDRY_API_KEY |
Azure Foundry |
AZURE_FOUNDRY_RESOURCE_NAME |
Azure Foundry |
BASETEN_API_KEY |
Baseten |
FIREWORKS_API_KEY |
Fireworks |
GOOGLE_API_KEY |
Google Gemini |
OPENAI_API_KEY |
OpenAI |
VERTEX_SERVICE_ACCOUNT_JSON |
Gemini Enterprise Agent Platform |
조직이 사용하는 프로바이더만 추가하세요. 사용자가 키가 추가되지 않은 프로바이더를 호출하려 하면 게이트웨이는 오류를 반환합니다.
2. 사용자용 게이트웨이 접근 구성하기
빌트인 역할 WORKSPACE_USER와 WORKSPACE_VIEWER는 gateway:invoke 권한을 포함하지 않으며 편집할 수 없습니다. 게이트웨이 접근을 부여하는 두 가지 옵션이 있습니다:
옵션 A: 커스텀 워크스페이스 역할 만들기 (권장)
RBAC 활성 요금제 필요.
- Settings > Members/Roles로 이동합니다.
- 새 워크스페이스 역할을 만듭니다.
- 최소
gateway:invoke와workspaces:read를 부여합니다. - 게이트웨이 접근이 필요한 사용자를 이 역할에 배정합니다.
전체 워크스페이스 관리자 권한을 주지 않고 특정 사용자에게 게이트웨이 접근을 부여하고 싶을 때 사용합니다. 게이트웨이를 사용할 수 있는 사람을 가장 잘 제어할 수 있습니다.
옵션 B: 워크스페이스 관리자 역할 사용
요금제 요구사항 없음.
WORKSPACE_ADMIN 역할은 기본적으로 gateway:invoke와 workspaces:read를 모두 이미 포함합니다. 게이트웨이 접근이 필요한 사용자를 이 역할에 배정합니다.
세밀한 접근 제어가 필요 없거나 RBAC가 활성화되어 있지 않을 때 사용합니다.
3. 정책 구성하기 (선택)
게이트웨이 정책 관리는 organization:manage 권한이 필요합니다.
LLM Gateway로 이동해 거버넌스 정책을 만듭니다. 구성할 수 있는 것:
- Spend 한도: 조직, 워크스페이스, API 키, 사용자 수준의 하드 캡. Spend 정책 참고.
- 데이터 정책: 모델에 도달하기 전에 PII와 시크릿 감지·삭제, 요청·응답 본문이 트레이싱되는지 제어. 데이터 정책 참고.
정책은 초기 설정 중에는 선택 사항입니다. 정책을 구성하기 전까지 게이트웨이는 호출을 자유롭게 허용합니다.
4. 사용자에게 API 키 배포하기
게이트웨이 접근이 필요한 사용자를 위해 워크스페이스 범위 Service Keys를 만듭니다. 각 키는 gateway:invoke와 workspaces:read를 포함하는 역할에 연결되어야 합니다.
조직 범위 키가 아닌 워크스페이스 범위 키를 사용하세요. 자세한 내용은 API 키 범위 지정을 참고하세요.
키와 게이트웨이 엔드포인트를 각 사용자와 공유하거나, 회사 전체 코딩 에이전트 롤아웃을 위해 MDM(모바일 기기 관리)으로 배포하세요. 에이전트별 구성 지침은 코딩 에이전트 설정을 참고하세요.
검증
SemIf의 경우 사용자에게 SemIf 요청 예제를 실행하도록 요청하세요. 200 응답이 모델 접근, API 키, 역할 권한을 확인합니다.
자체 키(bring-your-own-key) 프로바이더의 경우 사용자에게 퀵스타트의 검증 cURL을 실행하도록 요청하세요. 200 응답이 게이트웨이, API 키, 프로바이더 시크릿, 역할 권한이 모두 올바르게 구성되었음을 확인합니다. 호출은 워크스페이스의 gateway 트레이싱 프로젝트에 트레이스로 나타납니다.
다음 단계
- 퀵스타트: 시작 가이드로 사용자와 공유.
- 코딩 에이전트 설정: 조직 전체에서 Claude Code, Codex, 기타 에이전트 구성.
- 트레이스, Engine, 접근 제어: 역할, 범위 키, 트레이스 라우팅, 누가 무엇을 볼 수 있는지 심층 분석.
더 알아보기
- 퀵스타트 — 첫 게이트웨이 호출.
- 코딩 에이전트 설정 — 에이전트 구성.