“팀원들이 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 사용을 직접 운영해야 하는 팀이기도 합니다.
활용이 늘수록 운영상의 고민도 커졌습니다.
발급: 팀원과 서비스에 Amazon Bedrock 접근 권한을 누가, 어떤 절차로 주는가?
승인: 비용이 높은 최상위 모델은 아무나 써도 되는가?
할당량과 비용: 지금 누가 얼마나 쓰고 있는지 확인하고, 한도를 조절하고, 넘으면 멈출 수 있는가?
세 번째 질문이 이 플랫폼을 만든 직접적인 동기였습니다. 결정적인 계기도 있었습니다. 최상위 모델을 이틀 시험 사용했을 때, 기존 모델 대비 몇 배의 비용이 단기간에 청구된 것입니다. 집계 오류를 의심하고 확인해 보니 정상 과금이었습니다. 상위 모델의 단가와 출력량을 생각하면 당연한 결과였지만, 모니터링과 할당량 제한 없이는 같은 일이 언제든 반복된다는 것이 분명해졌습니다. 게이트웨이 구축 작업은 바로 그 주말에 시작됐습니다. 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와 비용 할당 태그로 임계 알림은 받을 수 있지만, 사용자·키 단위 지출 한도를 걸어 실시간으로 멈추는 기능은 네이티브로 없