LLM을 데모에서 프로덕션으로 옮기는 시점에 거의 모든 조직이 같은 길을 걷는다.
- 어떤 팀이 모델이 필요하다고 한다. 플랫폼 팀이 공급자 API 키를 하나 만들어 시크릿 매니저에 넣어 준다.
- 그 키에는 만료도, 범위도, 사용자 구분도 없다. 팀원 누구나, CI도, 디버깅하던 노트북도 그 키를 쥐고 있다.
- 레이트 리밋이 키 단위라서 한도에 걸리면 팀 전체가 멈춘다. 해법은 키를 하나 더 만드는 것이다.
- 키가 로그 한 줄, 스크린샷, 잠깐 공개된 저장소로 새어 나간다. 며칠 뒤 이상한 청구서를 보고서야 안다.
- 그동안 사람들은 팀 키가 늘 막혀 있으니 개인 계정으로 일한다. 회사의 정직한 비용 숫자는 이제 존재하지 않는다.
문제는 부주의가 아니다. 정적 키는 사용자가 여럿이고 사용량으로 과금되는 자원에 맞지 않는 도구다. ID는 하나, 수명은 영원, 범위는 전부. 필요한 건 정반대다. 많은 ID, 짧은 수명, 좁은 범위, 그리고 돈이 드는 자격 증명을 혼자 쥐고 있는 브로커.
규칙 하나: 정적 LLM 키는 아무에게도 발급하지 않는다
사람에게도, 서비스에게도, 저장소에게도 안 준다. 대신 이렇게 한다.
- 공급자 자격 증명은 게이트웨이의 관리형 ID 뒤 한 곳에만 있다. 설정 파일에도, 저장소에도, 로그에도 없다. 긴급 접근(break-glass) 권한이 없는 사람은 볼 수 없다.
- 모든 호출자는 수명이 짧은 토큰(수 분~1시간)으로 게이트웨이를 부른다. 토큰에는
principal,team,role,scopes,on_behalf_of가 담긴다. 로테이션할 호출자 키가 없다. 애초에 키가 없으니까. - 공급자 입장에서 게이트웨이는 고객 한 명이다. 조직 단위로 레이트 한도를 협상하고, 청구서도 계정 단위로 깔끔하다.
서비스는 클라우드 플랫폼이 발급한 워크로드 토큰으로 인증하고, 게이트웨이는 공급자 자격 증명을 키리스로 받아 붙인다. 서비스와 게이트웨이 사이에 공유 비밀번호도, 게이트웨이와 공급자 사이에 정적 키도 없다.
사람은 OBO로, 그래야 개인 계정이 사라진다
개발자의 IDE나 포털은 SSO가 발급한 사용자 토큰을 가지고 있다. 이걸 그 사용자에게 범위가 묶인 게이트웨이 토큰으로 교환한다(OBO, on-behalf-of). 이제 게이트웨이는 IDE가 아니라 사람을 미터링하고 한도를 적용한다.
이 변화 하나가 "팀 키가 맨날 막혀서 개인 계정 쓴다" 문제를 끝낸다. 사람이 예산과 한도를 가진 1급 ID가 되기 때문이다.
서비스가 사용자를 대신해 호출할 때(예: CI 장애 분석 봇)는 토큰에 on_behalf_of: user를 담고, 비용을 서비스와 사용자 양쪽에 귀속시킨다. 단, 교환에는 반드시 사용자 본인의 토큰이 필요해야 한다. 서비스가 아무 사용자 이름으로나 토큰을 만들 수 있다면 그건 OBO가 아니라 가장(impersonation)이다.
역할은 여섯 개면 된다
LLM 플랫폼이 실제로 구분해야 하는 건 "누가 쓰고, 누가 관리하고, 누가 지켜보고, 누가 감시받는가"다.
| 역할 | 추론 | 핵심 |
|---|---|---|
| viewer | 불가 | 모델 카탈로그와 본인 사용량만 조회 |
| contributor | 가능 | 기본 사람 역할. 저렴한 모델, 본인 기준 일일 쿼터 |
| reviewer | 가능 | 비싼 추론 모델 사용, 팀 쿼터 요청 승인 |
| ops | 저용량 | 기능·예산·카나리 관리, 테스트용 호출. 역할 부여와 자격 증명은 불가 |
| admin | 가능(전부 플래그) | 지명된 2~3명. 모든 추론 호출이 감사 대상 |
| auditor | 불가 | 감사 스트림과 정산 리포트만 읽기. 요청 내용은 못 본다 |
새 사용자는 자기 팀의 contributor로 시작한다. "API 키 받기" 단계가 없다. admin이 매일 추론을 돌리고 있다면 역할 설계가 잘못된 것이다. 그 작업에는 contributor 토큰을 주면 된다.
검사 순서와 에러 메시지도 설계다
게이트웨이는 이 순서로 검사하고, 처음 실패한 곳이 곧 응답이다.
- 토큰 유효성
- 해당 모델 별칭에 대한 역할·스코프
- RPS (토큰 버킷)
- 예산 사전 검사
- 라우팅
각 실패는 서로 다른 에러 코드와 사람이 읽을 안내를 가진다. 예를 들어 스코프가 없으면 403과 함께 "여기서 권한을 요청하세요" 링크를 준다. 그 에러를 받는 사람이 바로 권한을 요청할 사람이기 때문이다.
RPS와 예산을 카운터 하나로 합치지 말자. 가장 흔한 구현 실수다. RPS는 공급자와 큐를 보호하고, 예산은 지출을 보호한다. 하나로 합치면 "레이트 때문에 막혔나, 돈 때문에 막혔나"에 답할 수 없다.
일일 쿼터는 새벽 3시를 위한 것
월 예산이 한 달을 관리한다면, 사람·서비스별 일일 토큰 쿼터는 폭주 루프를 잡는다. 새벽 3시에 시간당 수백만 토큰을 쏟아내기 시작한 서비스는 월말 정산이 아니라 90분 안에 일일 상한에 걸린다.
쿼터를 올려 줄 때는 만료일을 붙인다. 한 번 시끄러웠다고 "무제한"으로 바꾼 쿼터는, 편의를 위해 제거된 바로 그 가드레일이다.
권한 요청은 채팅 스레드보다 빨라야 한다
- 저렴한 모델의 소폭 증설(예: 기본값의 +50%)은 자동 승인하고 기록만 남긴다. 요청의 90%가 여기에 속한다.
- 비싼 추론 모델이나 그 이상은 팀 reviewer에게 48시간 SLA로 넘기고, 처리 안 되면 ops로 에스컬레이션한다.
- 쿼터 부여와 역할 부여는 다른 문이다. 쿼터는 지출 결정, 역할은 접근 결정이다. 섞으면 "그냥 저 admin 그룹에 넣어 주세요"가 일상이 된다.
워크플로가 채팅 스레드보다 느리면 사람들은 스레드로 돌아가고 예산은 조용히 죽는다. SLA가 곧 채택 장치다.
장애 때도 정적 키는 없다
ID 플랫폼이 죽어서 토큰을 못 받는 상황에서도 답은 "임시로 정적 키 발급"이 아니다. 게이트웨이가 지명된 사람에게 15분짜리 긴급 토큰을 발급하고, 긴급 접근과 똑같이 감사한다. 수명이 긴 비밀을 만들어내는 폴백은 없다는 걸 장애 문서에 명시해 두자.
그리고 이 설계에서 유일하게 오래 사는 비밀, 즉 게이트웨이가 쥔 공급자 자격 증명은 왕관의 보석이다. 2인 승인 긴급 접근, 사용 후 자동 로테이션, 정기 훈련까지가 "정적 키 없음"이라는 주장의 실제 시험대다.
정리
- 정적 LLM 키는 사람·서비스·저장소 누구에게도 발급하지 않는다
- 공급자 자격 증명은 게이트웨이의 관리형 ID 뒤 한 곳에만 둔다
- 사람은 OBO로 미터링하고, 서비스 대리 호출은 사용자 토큰을 반드시 요구한다
- 역할 6개, 검사 순서 고정, RPS와 예산은 별도 카운터
- 쿼터 증설에는 만료일, 쿼터와 역할은 다른 문
이 글은 제가 쓴 『AI 게이트웨이 플레이북』 한국어판 3장(키리스 인증과 6단계 RBAC)을 요약한 것입니다. 책에는 모델 레지스트리, 토큰 미터링과 예산, MCP 서버, RAG 어시스턴트, 운영 런북과 40개 항목 체크리스트까지 담았습니다. 책과 이 글은 저의 실무 경험을 바탕으로 AI 도구의 도움을 받아 작성했습니다.
- 한국어판 (Leanpub, 무료 샘플 있음): https://leanpub.com/aigatewayplaybook-ko
- 한국어판 (Ko-fi): https://ko-fi.com/s/47455c0a7e
- 이전 글: LLM API 비용, 팀별로 정확하게 나누는 법
