월말 법인카드 명세서를 열어본 재무 담당자는 낯선 영문 결제 내역부터 세기 시작한다. 마케팅팀이 쓰는 AI 구독 하나, 개발팀이 개인 카드로 긁고 정산 올린 API 요금 하나, 어느 팀 것인지 아무도 모르는 결제 하나. 팀마다 제각각 계정을 만들어 쓰다 보니 회사 전체가 AI에 얼마를 쓰는지 아는 사람이 없고, 보안 담당자는 더 답답하다. 누가 어떤 모델에 무엇을 보내고 있는지 확인할 방법이 없기 때문이다.
구독을 팀 수만큼 늘려서 생긴 문제라면, 방향을 반대로 잡으면 된다. 계정은 하나로 모으고, 팀에는 계정 대신 키를 나눠주는 것이다.
구독을 늘리는 대신, 키를 나눠준다
카페24 LLM Router는 하나의 계정에서 API 키를 목적별로 여러 개 발급할 수 있고, 키마다 사용 이력과 사용량이 따로 잡힌다. 이 구조를 그대로 팀 단위에 얹으면 사내 AI 관리의 골격이 나온다. 회사가 LLM Router 계정 하나를 운영하고, 마케팅팀·개발팀·CS팀에 각자의 키를 하나씩 쥐여주는 식이다.
키를 받은 팀 입장에서는 달라질 게 없다. OpenAI SDK 호환이라 base URL과 키만 바꾸면 쓰던 코드가 그대로 돌고, 하나의 키로 Claude·Gemini·Qwen·DeepSeek 등 100개가 넘는 모델을 호출할 수 있다. 팀마다 다른 프로바이더와 계약하고 다른 SDK를 붙일 이유가 사라진다.
관리하는 쪽 입장에서는 모든 게 달라진다. 지출은 크레딧 하나로 모이고, 증빙은 세금계산서로 나오고, 팀별 사용량은 키 단위로 갈라져 잡힌다.
키 하나에 한도와 만료일까지 담는다
콘솔의 API 키 관리에서 새 키를 만들 때 키 이름과 함께 세 가지를 정할 수 있다. 이 세 가지가 사실상 팀별 AI 예산 정책이 된다.
| 설정 | 동작 | 팀 운영에서의 의미 |
|---|---|---|
| 크레딧 한도 | 이 키가 쓸 수 있는 최대 금액. 초과 시 요청 차단 | 팀별 월 예산 상한 |
| 한도 리셋 주기 | 매일 자정 / 매주 월요일 자정 / 매월 1일 자정 / 누적 | 매월 1일 자정으로 두면 매달 예산이 자동 갱신 |
| 만료 기한 | 지정일에 키 자동 비활성화 | 프로젝트 단위 TF에는 종료일을 박아둔다 |
예를 들어 CS팀 키에 한도 50만 크레딧, 리셋 주기 매월 1일 자정을 걸어두면, CS팀은 매달 50만 원어치 안에서만 AI를 쓸 수 있고 초과분은 시스템이 알아서 막는다. 예산 협의는 사람이 하되, 집행 통제는 시스템이 하는 구조다.
퇴사나 조직 개편 같은 오프보딩도 키 단위로 끝난다. 키를 비활성화하면 그 키로 들어오는 모든 API 요청이 즉시 거부된다. 팀원 개개인의 외부 서비스 계정을 찾아다니며 해지할 일이 없다.
누가 얼마나 썼는지는 대시보드가 알려준다
키를 나눠준 다음부터는 콘솔의 사용 현황이 관제탑이 된다. 기간과 키, 모델로 필터를 걸면 총 요청 수, 총 비용, 총 토큰이 집계되고, 요청이 많은 모델·API 키·프로바이더 TOP 5가 나란히 뜬다. 이번 달 개발팀이 어떤 모델에 얼마를 썼는지가 클릭 몇 번이면 나오고, 전체 내역은 CSV로 내려받아 재무 보고에 그대로 붙일 수 있다.
팀보다 잘게 쪼개고 싶다면 metadata를 쓴다. 요청 본문에 꼬리표를 달아 보내는 방식이다.
curl https://llm-router.cafe24.com/api/v1/chat/completions \
-H "Authorization: Bearer sk-cafe24-**********" \
-d '{
"model": "Qwen/Qwen3-8B",
"messages": [{"role":"user","content":"신제품 카피 초안 3개"}],
"metadata": {"team": "marketing", "project": "ad-copy", "env": "prod"}
}'
이 값은 프로바이더에는 전달되지 않고 LLM Router 로그에만 남는다. 사용 현황에서 metadata 조건으로 조회하면 같은 마케팅팀 키 안에서도 프로젝트별, 운영/개발 환경별 사용량이 갈라져 집계된다. 집계를 자동화하고 싶으면 Activity API를 호출하면 되는데, group_by 파라미터 하나로 팀별 일자별 사용량이 내려오고, 응답의 usage_krw_micro 필드가 호출 시점에 확정된 원화 청구액이라 월말 정산 스크립트에 바로 물릴 수 있다.
요청 단위 추적이 필요할 때는 로그 조회로 내려간다. 어떤 키가 언제 어떤 모델을 호출했고 토큰을 얼마나 쓰고 크레딧이 얼마나 차감됐는지, 응답 속도는 어땠는지가 건별로 남는다.
회사가 정한 모델만 쓰게 하는 울타리
가시화 다음은 통제다. 라우팅 설정의 Access Control에서 "모두 차단하되 다음 허용" 모드를 켜고 보안 검토를 마친 모델만 허용 목록에 올리면, 그 계정의 모든 호출이 이 울타리 안에서만 움직인다. 개별 요청이 다른 모델을 지정해도, 프리셋을 쓰든 자동 라우팅(cafe24/auto)을 쓰든, 심지어 팀이 따로 등록한 BYOK 키로 호출해도 이 정책은 우회되지 않는다. 차단된 대상을 부르면 403으로 끊긴다.
반대로 팀별 호출 방식을 표준화하고 싶을 때는 프리셋이 유용하다. 모델과 폴백 체인, 시스템 프롬프트, 파라미터를 묶어 @preset/cs-bot처럼 저장해두면 팀은 프리셋 이름 하나로 호출하고, 모델 교체나 프롬프트 수정은 관리자가 콘솔에서 처리한다. 각 팀 코드를 재배포할 필요가 없고, 수정 이력은 버전으로 남아 언제든 이전 버전으로 되돌릴 수 있다.
프롬프트가 밖으로 새지 않게
임직원이 프롬프트에 무엇을 넣을지는 통제하기 어렵다. 그래서 마지막 겹은 데이터 쪽에 친다. LLM Router는 요청·응답 본문을 기본적으로 저장하지 않는다. 디버깅을 위해 저장을 켜더라도 보관 기간(7·14·30일)이 지나면 자동 삭제되고, 로그 마스킹을 켜면 이메일·전화번호·주민등록번호·신용카드번호·IP 주소가 가려진 채 저장된다.
모델로 나가는 데이터 자체를 걸러야 한다면 민감 정보 마스킹을 쓴다. 정규표현식 패턴에 걸리는 값을 지정한 라벨로 치환한 뒤에 프로바이더로 전달하는 기능으로, 주민등록번호나 카드 번호 같은 패턴은 프리셋으로 준비되어 있어 클릭 몇 번으로 적용된다. 임직원이 실수로 고객 정보를 프롬프트에 붙여 넣어도, 모델에 닿기 전에 라벨로 바뀐다.
비용 사고에 대한 안전장치도 같이 걸어둘 수 있다. 잔액이 설정한 임계값 아래로 내려가면 알림이 오고, 자동 충전을 켜두면 잔액이 바닥나 전사 서비스가 멈추는 일을 막는다. 호출이 실패한 요청은 애초에 과금되지 않는다.
계정 하나, 키 몇 개로 시작하는 거버넌스
사내 AI 관리는 결국 흩어진 지출과 데이터를 한 지점으로 모으는 문제였다. LLM Router 계정 하나를 만들고, 팀 수만큼 키를 발급해 한도와 리셋 주기를 걸고, Access Control로 모델 울타리를 치면 골격은 끝난다. 나머지는 대시보드가 센다.
팀 단위 키 발급은 https://llm-router.cafe24.com 콘솔에서 바로 시작할 수 있다. 그리고 이 구조를 더 크게 쓰려는 기업 고객을 위해, 엔터프라이즈 플랜도 준비하고 있다.