잘 만든 스킬로 프로덕션 환경을 찍어낼 수 있을까?
AI 스킬 기반 구축에서 나타나는 결과물의 편차와 검증의 한계: LLM Gateway Governance Skill 사례
1. 스킬이 늘어날수록 커지는 질문
AI 코딩 에이전트가 빠르게 발전하면서, 특정 영역의 지식과 구축 절차를 묶어 둔 스킬도 많아지고 있습니다. Claude Code, Codex, Kiro 같은 도구에 스킬을 넣어 두면, 에이전트는 그 안의 설명과 참조 코드, 주의 사항을 바탕으로 인프라와 애플리케이션을 만들어 냅니다.
잘 만들어진 스킬은 분명 출발점을 크게 앞당겨 줍니다. 처음부터 설계하고 시행착오를 겪어야 했던 부분을, 이미 정리된 패턴과 검증된 코드로 빠르게 구성할 수 있습니다.
다만 스킬이 잘 만들어졌다는 것과, 그 스킬로 만든 결과물을 신뢰할 수 있다는 것은 조금 다른 이야기입니다. 스킬은 에이전트가 따를 방향을 제공할 뿐, 매번 같은 결과물을 보장하지는 않습니다. 그리고 해당 영역을 제대로 이해하지 못한 상태라면, 결과물이 어떻게 동작하는지 판단하기도 어렵습니다.
더 까다로운 경우도 있습니다. 스킬의 요구조건을 모두 만족하고, 스킬이 안내하는 방식대로 구축했는데도 예상하지 못한 문제가 생길 수 있습니다.
이 글에서는 그 예로 AWS에서 배포한 LLM Gateway 거버넌스를 위한 스킬인 LLM Gateway Governance Skill을 살펴봅니다. 그리고 그 안에서 두 가지 사례를 다룹니다.
예시 1 신규 프로젝트의 첫 요청에서 만들어지는 Team
예시 2 고객의 정책이 요구사항으로 더해질 때두 사례 모두 스킬의 범위를 벗어나지 않습니다. 그럼에도 결과물은 고객이 기대한 것과 다르게 동작할 수 있습니다.
2. 예시로 살펴볼 스킬: LLM Gateway Governance Skill
Amazon Bedrock을 통해 다양한 LLM을 사용하는 기업이 늘면서, 단순히 모델을 호출하는 것만으로는 충분하지 않은 상황이 많아지고 있습니다. 관리자는 다음을 알고 싶어 합니다.
- 누가 어떤 모델을 사용하고 있는가?
- 고비용 모델은 어느 조직에 허용할 것인가?
- 프로젝트별 AI 사용 예산은 얼마인가?
- 예산을 초과한 호출은 어떻게 막을 것인가?
이런 요구 때문에 LiteLLM과 같은 LLM Gateway를 사용합니다.
개발자 또는 애플리케이션 → LLM Gateway → Amazon Bedrock 모델Gateway는 단순한 중계 서버가 아니라, 사용자별 Key, Team별 모델 정책, 예산, 사용량 정보를 한 곳에서 관리하기 위한 도구입니다.
LLM Gateway Governance Skill은 이러한 Gateway를 구성하기 위해 IAM Identity Center SSO, Cognito, LiteLLM Virtual Key, Team별 정책, 모니터링을 연결하는 구조를 제공합니다. 이 글에서는 그중 org-sso 방식, 즉 IAM Identity Center SSO를 사용하는 흐름을 기준으로 살펴봅니다.
3. org-sso 에서 Permission Set은 Team을 연결하는 이름이 된다
org-sso는 IAM Identity Center 조직 인스턴스의 Permission Set 역할을 사용합니다. 사용자가 Gateway를 호출하면 Token Service는 로그인 세션에 사용된 Permission Set 이름을 확인하고, 같은 이름의 LiteLLM Team을 연결해 Virtual Key를 발급합니다.
로그인에 사용한 Permission Set 이름
=
LiteLLM Team의 team_alias예를 들어 TeamResearch Permission Set 역할로 로그인한 사용자는 TeamResearch LiteLLM Team에 연결됩니다.
이름 기반 연결은 코드에서 사용자나 프로젝트별 분기를 두지 않고 Team을 연결할 수 있게 합니다. 동시에 Permission Set 이름과 Team 이름이 정책이 연결되는 지점이 됩니다.
4. 예시 1: 신규 프로젝트의 첫 요청에서 만들어지는 Team
Team은 첫 요청에서 만들어질 수 있다
새 프로젝트나 조직이 생길 때마다 Lambda 코드를 수정하고 재배포하지 않도록, Token Service는 같은 이름의 LiteLLM Team을 먼저 조회하고 없으면 생성합니다.
Team이 없을 때에는 TIER_CONFIG에 준비된 초기값을 사용할 수 있습니다. 해당 이름의 초기값이 있으면 Team 생성 시 모델 Allowlist와 max_budget이 함께 설정됩니다. 초기값이 없으면 Team은 이름과 기본 접근 그룹만 가진 상태로 생성될 수 있고, 모델과 예산은 생성된 뒤 LiteLLM Admin UI에서 설정합니다.
TIER_CONFIG에 ProjectAlpha 초기값이 있는 경우
→ Team 생성 시 models와 max_budget 함께 설정
TIER_CONFIG에 ProjectAlpha 초기값이 없는 경우
→ Team 이름으로 생성
→ Team별 models와 max_budget 없이 시작할 수 있음TIER_CONFIG는 최초 생성 시점에만 쓰이는 값입니다. Team이 이미 존재하면 시드를 나중에 수정해도 기존 Team에 다시 적용되지 않습니다.
ProjectAlpha의 첫 로그인
새 프로젝트 ProjectAlpha가 시작됐다고 가정해 보겠습니다. 프로젝트 구성원에게 ProjectAlpha Permission Set이 할당되고, 사용자가 해당 역할로 로그인해 Gateway를 호출합니다.
ProjectAlpha Permission Set 생성
→ 사용자 또는 Group에 할당
→ 사용자가 ProjectAlpha 역할로 SSO 로그인
→ Token Service 호출
→ ProjectAlpha Team 조회 또는 생성
→ Virtual Key 발급
→ 모델 호출ProjectAlpha Team이 이미 있고 Allowlist와 예산이 설정돼 있었다면, 발급된 Key는 그 Team 정책과 연결됩니다.
최초 생성용 초기값이 준비돼 있었다면, Team이 없더라도 Team 생성과 함께 초기 정책이 적용되어 같은 결과가 나옵니다.
하지만 Team이 없고 그 이름에 대한 초기값도 없었다면, 로그인과 Key 발급, 모델 호출은 정상적으로 이루어지면서 Team별 모델 Allowlist와 예산이 없는 상태가 남을 수 있습니다.
Gateway에 등록되지 않은 모델까지 쓸 수 있다는 뜻은 아니지만, Gateway에 등록된 모델 범위 안에서는 해당 Team에 별도 제한이 없을 수 있습니다. 이 흐름에는 오류나 경고가 없습니다. 개발자에게도, 처음 동작을 확인하는 운영자에게도 정상적인 온보딩으로 보입니다.
5. 예시 2: 고객의 정책이 요구사항으로 더해질 때
고객의 요구사항에는 기능뿐 아니라 고객이 이미 생각하고 있는 운영 정책이 함께 담기는 경우가 많습니다. 예를 들어 다음과 같은 요청입니다.
“개발자 한 명당 하루 $10까지만 사용하게 해 주세요.”고객에게는 분명한 정책입니다. 기준은 사람이고, 주기는 하루입니다.
스킬 안에서 자연스럽게 나오는 구현
이 스킬에서 Team의 max_budget은 Team 구성원 전체가 함께 쓰는 공용 예산입니다. 열 명이 한 Team에 있으면, 먼저 많이 쓴 몇 명이 나머지 사람의 몫까지 소진할 수 있습니다.
그래서 스킬의 운영 문서는 “1인당 한도”가 필요하면 Team이 아니라 Key에 예산을 걸라고 안내합니다. Token Service가 Key를 발급할 때 /key/generate 요청에 max_budget과 budget_duration을 넣는 방식입니다. 이 Gateway에서는 사용자마다 Virtual Key가 발급되므로, 개인별 한도를 구현하는 자연스러운 선택으로 보입니다.
고객 정책: 개발자 한 명당 하루 $10
구현: Key 발급 시 max_budget=10, budget_duration=1d이렇게 구성한 뒤 테스트해 보면, 한 사용자가 $10을 넘기는 순간 다음 호출이 거부됩니다. 개인별 한도가 동작하는 것처럼 보입니다.
Key는 하루에도 여러 번 바뀐다
이 스킬에는 다른 이유로 들어간 설계가 하나 더 있습니다. Virtual Key에는 만료 시간(KEY_DURATION_SECONDS)이 있고, 참조 구현의 기본값은 1시간입니다.
이 만료 시간은 권한 회수와 관련된 장치입니다. IAM Identity Center에서 사용자를 제거해도 이미 발급된 Key는 계속 동작하기 때문에, Key 수명을 짧게 두어 남아 있는 접근 시간을 줄입니다. Key가 만료되면 클라이언트의 Token helper가 사용자 모르게 새 Key를 받아 오므로, 사용자는 차이를 느끼지 못합니다.
문제는 이 두 설계가 만나는 지점입니다. 예산이 Key에 걸려 있으면, 새로 발급된 Key는 자기 사용액을 따로 가지고 시작합니다.
이렇게 되면 고객이 생각한 “한 사람당 하루 $10”은 실제로는 “Key 하나당 $10”으로 동작합니다. Key가 1시간마다 바뀐다면, 한 사람이 하루에 사용할 수 있는 금액은 이론상 그 몇 배가 될 수 있습니다.
고객이 생각한 정책: 사람 1명 × 하루 = $10
실제로 동작하는 단위: Key 1개 = $10
Key 수명 1시간: 하루 최대 약 24개의 Key각각은 타당한 설계다
여기서 어느 한쪽이 잘못된 것은 아닙니다. Key 예산은 스킬 문서가 안내하는 개인별 한도 방식이고, 짧은 Key 수명은 권한 회수 이후의 잔여 접근을 줄이기 위한 장치입니다. 둘 다 스킬의 범위 안에 있습니다.
차이는 고객의 정책 문장에 담긴 사람과 하루라는 기준이, 구현에서는 Key와 Key 수명이라는 다른 단위로 해석되면서 생깁니다. 그리고 이 차이는 한 Key로 한도를 넘겨 보는 테스트에서는 드러나지 않습니다. Key가 바뀌는 시점을 지나야 보입니다.
Key 수명을 24시간처럼 길게 두면 차이는 줄어듭니다. 다만 그 경우에도 한도가 다시 시작되는 기준은 달력상의 하루가 아니라 Key가 발급된 시각이 됩니다.
비슷한 모습은 스킬의 예시 안에서도 볼 수 있습니다. 저비용 Tier 예시는 “1인당 $50 한도”로 설명되지만, 실제 설정은 Team의 max_budget이어서 Team 전체가 함께 쓰는 공용 예산으로 동작합니다. 운영 문서도 이 차이를 언급하고 있습니다. 정책을 표현한 말과 그 정책이 적용되는 단위는 쉽게 어긋날 수 있습니다.
정책 요구사항은 대개 한 문장으로 전달되지만, 구현 안에서는 로그인 역할, Key 발급 단위, Key 수명, Team 예산, 사용량 집계가 함께 맞물립니다. 예산이 작업 중간에 소진될 때, 프로젝트가 종료될 때, 사용자가 다른 조직으로 옮길 때처럼 정책 문장에 드러나지 않는 상황도 있습니다. 이런 지점은 요구사항을 기능 목록으로 볼 때보다, 실제 사용자가 겪을 상황을 시나리오로 따라가 볼 때 드러나는 경우가 많습니다.
6. 같은 스킬, 다른 결과물
스킬을 이용한 구축은 하나의 고정된 결과만 만드는 과정이 아닙니다. 고객이 어떤 요구를 전달하는지, 구축 당시 어떤 프롬프트와 조건을 제공하는지, 그리고 AI가 그 요청을 그때그때 어떻게 해석해 구성하는지에 따라 결과물은 달라질 수 있습니다.
예를 들어 다음 요청들은 비슷해 보이지만 구현의 출발점과 결과에 차이를 만들 수 있습니다.
“새 프로젝트를 코드 수정 없이 바로 추가하고 싶다.”
“프로젝트별로 고비용 모델을 제한하고 싶다.”
“프로젝트별 예산을 분리하고 싶다.”
“개발자 한 명당 사용량을 제한하고 싶다.”첫 번째 요청은 자동 Team 생성 흐름과 잘 맞을 수 있습니다. 두 번째와 세 번째 요청은 Team이 생성되는 시점의 모델·예산 상태와 연결됩니다. 네 번째 요청은 예산이 Team과 Key 중 어디에 걸리는지, 그리고 Key가 얼마나 자주 바뀌는지와 연결됩니다.
같은 스킬을 사용하더라도 어떤 요청이 함께 들어왔는지, 그 요청이 어떤 단어로 표현됐는지에 따라 Team 구조, 초기 정책, 예산 단위가 서로 다른 결과물이 만들어질 수 있습니다. 그리고 그 결과물들은 모두 “스킬을 사용해 구축한 Gateway”입니다.
여기에 Google Workspace 로그인이나 외부 IdP 연동처럼 고객별 요구가 더해지면, 사용자 인증과 Team·Key 정책 사이에 연결 단계가 늘어나고, 앞의 두 사례와 같은 지점도 그만큼 많아질 수 있습니다.
7. 마치며
잘 만들어진 스킬은 분명 구축의 시작을 훨씬 쉽게 만듭니다. 복잡한 구조와 반복해서 겪게 되는 시행착오를 미리 정리해 두고, 필요한 코드와 운영 절차의 초안을 빠르게 만드는 데 큰 도움이 됩니다. LLM Gateway Governance Skill도 인증, Virtual Key, Team 정책, 사용량 관측을 하나의 구조로 살펴보고 구현할 수 있게 해 준다는 점에서 충분한 가치가 있습니다.
다만 한 번의 구축을 넘어 같은 환경을 여러 고객이나 조직에 반복해서 배포하려면, 매번 스킬에 의존해 결과물을 새로 생성하는 방식만으로는 부족합니다. 고객의 요청, 프롬프트의 표현, 구축 당시의 조건, AI의 해석에 따라 세부 구현이 달라질 수 있기 때문입니다. 앞의 사례처럼 일반적인 기능 테스트를 통과하더라도, 최초 Team 생성이나 Key 교체처럼 특정 조건과 시간이 겹칠 때만 드러나는 차이도 있습니다.
한 가지 방향은 스킬을 최종 배포 수단이 아니라 통제 가능한 자산을 만드는 출발점으로 사용하는 것입니다. 스킬로 초안을 빠르게 만든 뒤, 필요한 정책과 동작을 명확히 정의하고, 구현을 충분히 검토하고 검증해 버전이 고정된 IaC, 설정, 테스트, 배포 절차 같은 우리 소유의 자산으로 만드는 방식입니다. 이후에는 그 자산을 정해진 파이프라인을 통해 반복 배포함으로써, 어디에 배포하더라도 같은 기준과 동작을 유지할 수 있습니다.
물론 이것만이 정답은 아닙니다. 중요한 것은 스킬을 사용할지 말지가 아니라, 스킬의 역할이 어디까지이고 그 이후를 우리가 어떤 방식으로 통제할 것인지 구분하는 일입니다. 프로덕션 환경에 안전하게 적용하고 여러 곳에 확장하려면, 스킬의 장점을 활용하되 결과물의 소유권과 검증 기준, 변경 및 배포 방식은 우리가 통제할 수 있는 형태로 설계해야 합니다. 결국 필요한 것은 스킬에 대한 의존이 아니라, 스킬을 기반으로 우리만의 반복 가능하고 신뢰할 수 있는 구축 방식을 만드는 일입니다.