Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례

“팀원들이 AI 코딩 도구를 쓰고 싶어 하는데, 키는 누가 어떻게 나눠주죠?” 생성형 AI를 도입하는 조직이라면 어디서든 나오는 질문입니다. 저희는 이 질문에 조금 다른 순서로 답했습니다. 전사 플랫폼을 하향식으로 기획하는 대신, 사내에서 AI를 가장 많이 쓰는 팀이 자기 팀을 위해 먼저 만들고, 검증한 뒤 확대를 고민하기로 한 것입니다.

이 글은 F&F의 AI Engineering 팀이 Amazon Bedrock 위에 구축한 사내 LLM 플랫폼(클라우드 포털의 LLM Lite)의 구축과 운영 이야기입니다. 키 발급에서 모델 승인, 할당량 확인과 자동 차단, 사용량 감사까지 하나의 운영 수명주기로 묶은 과정을 다룹니다.

F&F 디지털본부 프로세스 담당 AI Engineering 팀

F&F는 MLB, Discovery Expedition 등의 브랜드를 전개하는 패션 기업입니다. 저희는 F&F 디지털본부 프로세스 담당 AI Engineering 팀으로, 사내 AX(AI 전환)와 AI Agent 연구·서비스화를 담당합니다. 팀원 개개인의 AI 코딩 도구 활용부터 업무를 자동화하는 사내 AI Agent까지, 사내에서 가장 넓고 깊게 생성형 AI를 활용하는 조직이고, 그만큼 그 바탕이 되는 LLM 사용을 직접 운영해야 하는 팀이기도 합니다.

활용이 늘수록 운영상의 고민도 커졌습니다.

1. 발급: 팀원과 서비스에 Amazon Bedrock 접근 권한을 누가, 어떤 절차로 주는가?
2. 승인: 비용이 높은 최상위 모델은 아무나 써도 되는가?
3. 할당량과 비용: 지금 누가 얼마나 쓰고 있는지 확인하고, 한도를 조절하고, 넘으면 멈출 수 있는가?

세 번째 질문이 이 플랫폼을 만든 직접적인 동기였습니다. 결정적인 계기도 있었습니다. 최상위 모델을 이틀 시험 사용했을 때, 기존 모델 대비 몇 배의 비용이 단기간에 청구된 것입니다. 집계 오류를 의심하고 확인해 보니 정상 과금이었습니다. 상위 모델의 단가와 출력량을 생각하면 당연한 결과였지만, 모니터링과 할당량 제한 없이는 같은 일이 언제든 반복된다는 것이 분명해졌습니다. 게이트웨이 구축 작업은 바로 그 주말에 시작됐습니다. Amazon Bedrock을 안정적으로 운영하려면 대시보드에서 사용량을 “보는” 것을 넘어, 할당량을 팀이 직접 확인하고 조절할 수 있어야 했습니다.

왜 Amazon Bedrock이었나, 그리고 왜 그것만으로 끝나지 않았나

초기 목표는 명확했습니다. 팀이 운영하는 서비스와 구성원들에게 Claude 모델을 보안적으로 안전하게, 감사(audit) 가능한 형태로 제공하는 것이었습니다.

Amazon Bedrock을 선택한 이유는 저희 서비스가 이미 AWS 위에서 움직이기 때문입니다.

외부 SaaS의 API 키를 개별 계약·발급·배포하는 방식과 비교하면 다음과 같은 장점이 있습니다.

• 서비스 워크로드는 키 자체가 필요 없습니다. Identity and Access Management(이하 IAM) 역할 Amazon EKS Pod Identity으로 인증하므로 자격증명 수명주기가 AWS 안에서 관리됩니다.
• 키를 쓰는 경우에도 IAM 조건(aws:SourceIp 등)으로 사용을 사내 IP 대역·특정 서비스로 제한할 수 있습니다. 외부 SaaS 키는 별도의 네트워크·정책 제약이 없다면 유출 시 오남용 범위가 더 넓어질 수 있습니다.
• CloudTrail과 모델 호출 로깅으로 감사가 기존 AWS 보안 체계에 일원화되고, 비용도 AWS 청구서 하나로 통합됩니다.

다만 Amazon Bedrock 기본 기능만으로는 운영 요건을 모두 충족하기 어려웠습니다. 실제로 운영을 준비하며 다음과 같은 한계를 마주했습니다.

• 알람은 되지만 차단은 안 됩니다. AWS Budgets와 비용 할당 태그로 임계 알림은 받을 수 있지만, 사용자·키 단위 지출 한도를 걸어 실시간으로 멈추는 기능은 네이티브로 없습니다. 실시간 강제(enforcement)가 필요하면 애플리케이션 레이어 게이트웨이로 푸는 것이 일반적인 방식입니다.
• 서비스 할당량(Service Quotas)은 계정·리전 단위입니다. 모델별 분당 요청/토큰 한도는 계정 전체에 걸리므로 “이 사용자에게 이만큼”처럼 배분할 수 없습니다.
• 키별 모델 허용·할당량을 IAM만으로 관리하기 어렵습니다. Amazon Bedrock API 키는 연결된 IAM principal의 권한을 그대로 상속하므로, 사용자마다 다른 모델 세트와 한도를 주려면 사용자 수만큼 IAM 정책을 만들고 유지해야 합니다.
• 셀프서비스가 없습니다. 키 발급·회수를 위해 일반 구성원에게 IAM 콘솔 권한을 줄 수는 없습니다.

그래서 방향이 정해졌습니다. Amazon Bedrock이 잘해주는 것(모델 서빙, IAM 인증, 네트워크 경계, 로깅)은 그대로 쓰고, 다루지 않는 영역(셀프서비스 발급, 모델 승인, 예산 차단)만 저희가 보완합니다.

전체 아키텍처는 두 개의 영역으로 나뉜다

클라우드 포털(컨트롤플레인), LiteLLM 게이트웨이(데이터플레인), Amazon Bedrock으로 구성된 전체 아키텍처

플랫폼은 역할이 뚜렷한 두 영역으로 나뉩니다.

앞서 정한 방향(Bedrock이 잘하는 것은 그대로, 부족한 부분만 보완)을 아키텍처로 풀면, 게이트웨이는 요청이 지나는 길목에서 정책 강제(차단·제한)를 맡고 포털은 발급·승인·조직 연동을 담당합니다. 예산 초과 차단, 키 만료, 사용량 집계는 LiteLLM의 네이티브 기능을 그대로 쓰고, 포털은 발급 백엔드로 LiteLLM의 API를 호출하는 구조입니다. 모든 구성 요소는 Terraform과 GitOps(Argo CD)로 코드로 관리합니다.

이 데이터플레인은 AWS Solutions Library 의 Guidance for Multi-Provider Generative AI Gateway on AWS가 제시하는 LiteLLM 기반 게이트웨이 배치 패턴과 맞닿아 있습니다. 다만 해당 Guidance가 게이트웨이 자체의 데이터플레인 레퍼런스에 가깝다면, 저희 사례의 초점은 그 앞단, 곧 발급·승인·조직 연동을 담당하는 컨트롤플레인의 운영 모델에 있습니다.

서비스는 그룹으로, 개인은 이메일로 귀속한다

운영 초기에 의도적으로 새로 만들지 않은 것도 있습니다. 바로 귀속의 기준입니다. 저희 팀의 서비스는 이미 Amazon EKS 위에서 운영되고 있었고 서비스별 관리자 그룹도 존재했으므로, 포털은 새 소유자 목록을 만드는 대신 서비스 식별자와 SSO 로그인 이메일 두 기준을 그대로 가져왔습니다.

개인 사용은 이메일로 묶었습니다. 포털 로그인이 Microsoft Entra ID SSO이므로 “발급 이력”, “내 사용량”, “개인 가상 키”가 모두 user.email 하나로 수렴합니다. 서비스 사용은 svc:{서비스명} 식별자로 발급해 게이트웨이가 그 값만으로 프로젝트에 귀속시키고 예산도 같은 단위로 겁니다. 덕분에 개인의 실험적 사용과 서비스의 상시 호출이 섞이지 않습니다. 실제로 사내 AIOps 에이전트를 편입할 때도 별도 매핑 없이 식별자만으로 사용량이 프로젝트 대시보드에 잡히고 일 예산 제한이 적용됐습니다.

권한과 통보도 기존 구조에 얹었습니다. Amazon EKS 서비스 운영에 쓰던 서비스별 관리자 그룹(Entra ID) 포털의 서비스 범위 권한과 예산 경고·차단 통보 수신자로 재사용했고, Amazon S3 조회는 조직 경로 기반 권한 부여(grant)를 따릅니다. 그래서 서비스 운영자는 본인 서비스의 Secret, Amazon S3, Amazon Bedrock 사용량을 한 포털에서 함께 봅니다. 결국 저희가 새로 만든 것은 발급·승인·예산의 운영 흐름이지 귀속 기준이 아니며, 이 기준은 뒤이어 설명할 승인 방식과 예산 통보로 그대로 이어집니다.

구성원 경험: 발급에서 첫 호출까지 3분

팀원은 포털에 사내 SSO(Microsoft Entra ID)로 로그인해 사용 목적과 서비스를 입력하고 키를 발급받습니다. 포털 백엔드는 LiteLLM에 가상 키 생성을 위임합니다.

curl -s http://litellm.internal.example.com/key/generate \ 
    -H "Authorization: Bearer $LITELLM_MASTER_KEY" \ 
    -d '{
        "user_id": "svc-example",
        "key_alias": "portal-svc-example-a1b2c3",
        "models": ["general-models"],
        "max_budget": 100.0,
        "budget_duration": "1d" 
     }'

발급 화면은 키만 던져주고 끝나지 않습니다. Claude Code, 사내 에이전트 프레임워크 등의 사용처별 설정 스니펫을 복사-붙여넣기 형태로 함께 제공해, 발급받은 사람이 문서를 뒤지지 않고 3분 안에 첫 호출까지 도달하도록 했습니다. 발급 시 입력한 목적·서비스 메타데이터는 포털 DB에 남아 이후 사용량 감사의 조인 키가 됩니다.

포털의 키 발급 화면 – 사용 목적·서비스를 입력하면 셀프서비스로 발급되고, 사용처별 설정 스니펫이 함께 제공된다

발급 화면이 함께 내려주는 설정 스니펫은, 발급받은 키를 사용처에 그대로 붙이기만 하면 되는 형태입니다. 예를 들어 Claude Code는 환경변수 두 줄이면 게이트웨이에 연결됩니다.

# Claude Code - 발급받은 가상 키를 게이트웨이로 연결 (예시)
export ANTHROPIC_BASE_URL="https://litellm.internal.example.com"
export ANTHROPIC_AUTH_TOKEN="sk-<발급받은 가상 키>"
# 이후 평소처럼 claude 실행 - 모든 호출이 게이트웨이를 거칩니다

프로젝트 단위로 고정하고 싶으면 같은 값을 .claude/settings.json에 넣습니다. 어느 쪽이든 사용자는 base URL과 키만 설정하면 되고, 모델 접근 범위·예산·감사는 게이트웨이가 알아서 적용합니다.

최상위 모델은 허가받고 쓴다

일반 모델은 발급 즉시 사용할 수 있지만, 비용이 높은 최상위 모델(예: Claude Fable 5)은 승인 방식으로 제한했습니다. 여기서 저희가 부딪힌 문제가 하나 있습니다. 모델 선택이 요청 본문(body) 안에 들어가는 호출 형태에서는, IAM 정책의 리소스 ARN 조건만으로 저희가 원하는 “사용자별 모델 승인” 요구를 일관되게 표현하기 어려웠습니다. IAM만으로 풀기 어려운 이 문제를 게이트웨이 도입으로 해결했습니다.

게이트웨이에서는 모델을 접근 그룹으로 묶고, 키가 속한 그룹만 호출을 허용합니다.

# LiteLLM config.yaml (발췌, 값은 예시)
model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: bedrock/global.anthropic.claude-sonnet-5
    model_info:
      access_groups: ["general-models", "service-models"]
  - model_name: claude-fable
    litellm_params:
      model: bedrock/us.anthropic.claude-fable-5
    model_info:
      access_groups: ["restricted-models"]   # 승인자만 (최상위 모델)

승인 흐름도 같은 그룹 체계 위에 올렸습니다. 포털에서 사용 요청 → 관리자 승인 → Microsoft Entra ID 승인 그룹에 추가 → 해당 사용자의 키에 승인 그룹 모델이 열립니다. 배포 후 실제로 확인해 보니, 미승인 사용자의 요청은 차단됐고 승인을 받은 뒤에는 같은 요청이 정상적으로 처리됐습니다.

할당량과 비용: 관측에서 차단, 통보까지

이 플랫폼의 존재 이유였던 부분입니다. 비용 거버넌스는 보이고(Observability), 멈추고(Enforcement), 알리는(Notification) 세 요소가 맞물려야 완성됩니다. 예산은 목적이 다른 두 계층으로 나눴습니다.

한도를 넘으면 게이트웨이가 429(ExceededBudget)로 자동 차단합니다. 차단 로직을 직접 만들지 않고 LiteLLM 기능을 그대로 쓴 것이 운영 부담을 크게 줄였습니다. 관리자는 포털 UI에서 프로젝트별 한도를 조회·조정합니다. “할당량 확인과 조절”이 콘솔 권한 없이 팀 안에서 완결됩니다.

예산이 임계치에 도달하면 사람이 챙기지 않아도 자동으로 통보되도록 만들었습니다.

예산 경고·차단 통보 흐름 – LiteLLM webhook을 포털이 중계해 Entra 그룹 수신자에게 메일과 Slack으로 통보

• 일/월 예산이 80% 도달 시 경고를, 100% 도달 시 차단 사실을 통보하는 2단계로 운영합니다.
• LiteLLM의 budget webhook을 포털이 수신해 일/월 계층을 판정합니다.
• 수신자는 수동 관리 목록이 아니라 프로젝트에 대응하는 Entra 그룹 멤버를 실시간 조회하므로, 담당자가 바뀌어도 수신자 목록을 따로 갱신할 필요가 없습니다.
• 경보 발송은 사내 메일 발송 게이트웨이와 Slack으로 보냅니다.

사용량은 적정 규모로 관측한다

사용량 데이터는 두 경로에서 옵니다. 게이트웨이의 지출(spend) API가 가상 키 단위 상세를, Amazon Bedrock의 모델 호출 로깅(invocation logging) 이 게이트웨이 도입 이전 이력까지 포함한 전체 호출을 커버합니다. 로그는 Amazon CloudWatch Logs(90일)와 Amazon S3(영구 보관, KMS 암호화)에 이중으로 전달되도록 구성했습니다.

여기서 의도적으로 도입하지 않은 것이 있습니다. 바로 Amazon Athena, Amazon Data Firehose, Amazon QuickSight 서비스입니다. 현재의 단일 계정/팀 규모 데이터양에서는 CloudWatch Logs Insights 집계만으로 충분했고, 파이프라인을 늘리지 않아 유지 비용을 낮출 수 있었습니다. 대신 포털 대시보드에서 두 데이터 소스를 병합해 사용자·모델·프로젝트별 비용, 토큰, 그리고 프롬프트 캐시 적중률까지 보여주도록 구현했습니다.

사용량 대시보드 – 총비용·토큰과 함께 누가·어떤 서비스로·어디에서 호출했는지 한 화면에서 확인 (데모 데이터)

운영에서 얻은 교훈

1. 외부 진입 제어와 클러스터 내부 경로는 별도로 설계해야 합니다. 게이트웨이를 Internal ALB로 노출하고 접근 CIDR을 사내 NAT/VPN 대역으로 제한했더니, 클러스터 내부 Pod의 호출까지 차단됐습니다. 같은 VPC 안에서 ALB로 가는 Pod 트래픽에는 SNAT가 일어나지 않아 Pod IP가 그대로 도달하기 때문입니다. 사내 사용자는 Internal ALB, 클러스터 내부 서비스는 ClusterIP + NetworkPolicy로 경로를 분리해 해결했습니다.
2. 200 응답만으로는 전환 완료를 판단할 수 없습니다. 직접 호출하던 서비스를 게이트웨이로 옮길 때, 초기에 도달성 확인(200)만으로 완료 처리할 뻔했지만 일부 보조 경로가 여전히 직접 호출로 남아 있었습니다. 이후에는 서비스 로그의 base_url이 모두 게이트웨이를 가리키고, CloudTrail에서 직접 호출이 없는 것으로 확인되었으며, 게이트웨이 로그에 해당 워크로드의 요청이 정상(200)으로 기록되는 세 가지를 모두 만족해야 전환 완료로 판정합니다.
3. 게이트웨이 밖 경로도 함께 막아야 통제가 완성됩니다. 게이트웨이를 거치지 않는 예전 발급 키는 사내 네트워크에서만 쓸 수 있도록 제한을 걸었고, 직접 호출하던 사내 AI 에이전트는 게이트웨이를 거쳐도 프롬프트 캐시가 그대로 유지되는지 먼저 확인한 뒤 옮겼습니다. 큰 시스템 프롬프트가 게이트웨이 경유 후에도 캐시에 그대로 적중하는 것을 확인하고 나서야 전환했습니다.
4. 대체 모델은 워크로드 특성으로 판단해야 합니다. 다양한 모델을 선택하고 시험하여 업무에 적합한 모델을 선정하고 적용할 필요가 있습니다. Amazon Bedrock에서 제공하는 저비용 모델(예: Grok 4.3)은 지연에 덜 민감한 용도나 메인 모델의 폴백 경로로 활용할 수 있습니다. LLM 게이트웨이가 있으니 이런 모델 교체, 폴백 구성이 설정 몇 줄로 끝난다는 점도 확인했습니다.

성과와 향후 계획

이 플랫폼을 도입한 뒤 운영이 눈에 띄게 단순해졌습니다. 키 발급은 셀프서비스로 즉시 이뤄져 3분 안에 첫 호출까지 도달하고, 승인제 모델은 게이트웨이가 403(model access denied)으로 강제해 무단 사용이 발생하지 않았습니다. 사용자·프로젝트 단위 한도와 429(ExceededBudget) 차단으로 예산 초과를 구조적으로 막고, 모든 호출은 “누가·어떤 키로·어떤 모델을·얼마나” 기준으로 조회할 수 있어 발급부터 비용까지 전 과정을 추적할 수 있는 상태로 운영하고 있습니다.

현재 이 플랫폼은 AI Engineering 팀 범위에서 운영 중입니다. 가장 많이 사용하는 팀에서 발급·승인·예산·감사로 이어지는 거버넌스 체계가 실제로 동작함을 검증했고, 이 거버넌스를 전사 차원으로 일관되게 적용하기 위해 다음 단계로 전사 확대를 준비하고 있습니다. 플랫폼은 처음부터 스케일아웃을 염두에 두고 구현했기 때문에, 사용자와 프로젝트, 승인 그룹이 늘어나더라도 동일한 구조 위에서 안정적이고 효율적으로 운영할 수 있습니다.

마치며

돌아보면 가장 큰 수확은 특정 도구가 아니라, 비용 문제가 커지기 전에 멈출 수 있는 구조를 팀 규모에서 검증하고 전사로 확장할 발판을 마련했다는 사실입니다. 저희는 거버넌스 요구를 문서 공지가 아니라 시스템 동작으로 구현하는 데 집중했습니다. “쓰지 마세요”라고 막는 대신, 쓰기 쉬운 포털을 만들고 그 뒤에 게이트웨이를 두는 아키텍처로 풀어냈습니다.

생성형 AI 활용이 특정 팀부터 빠르게 늘고 있는 조직이라면, 전사 계획을 기다리기보다 그 팀에서 먼저 시작하는 것도 좋은 답이 될 수 있습니다.

끝으로, 지금까지 소개해드린 사내 LLM 플랫폼은 파트너의 도움으로 더 탄탄하게 구축할 수 있었습니다. 초기 설계 단계에서 AWS Technical Account Manager님의 Best Practice 제안과 설계 리뷰, 메가존클라우드 Solution Architect님의 기능 검증과 실측 지원이 안정적인 플랫폼을 완성하는 데 큰 힘이 됐습니다.

참고 자료

• AWS Solutions Library – Multi-Provider Generative AI Gateway on AWS 가이던스 (LiteLLM 기반 멀티 프로바이더 게이트웨이 레퍼런스 아키텍처)
• AWS re:Post – 사용자별 Amazon Bedrock 사용량 추적·제한 방법
• AWS 공식 문서 – Amazon Bedrock API 키
• AWS 공식 문서 – Amazon Bedrock 할당량(Quotas)
• AWS Builder Center – Amazon Bedrock 사용량·비용 제한 방법

함께 읽으면 좋은 블로그

• 단일 LLM Gateway 아키텍처 : Claude Code와 Codex를 Amazon Bedrock을 통해 한 곳에서
• Amazon Bedrock 기반 Claude Code, 조직에서 안전하게 운영하기: LLM Gateway 구축 가이드
• Claude Code 비용/사용량을 한눈에: AWS에 Observability 플랫폼 구축하기