여러 개의 AI API(Gemini, Claude, OpenAI 등)를 부서 전반에 걸쳐 이용하는 기업이 늘어나고 있습니다. 이 기사에서는 GWS(Google Workspace) 환경을 중심으로, GAS(Google Apps Script)와 스프레드시트(Spreadsheet)를 결합한 부서별 예산 프레임 관리 설계 패턴을 해설합니다.

• 사내에서 Gemini / Claude / OpenAI API를 여러 부서가 이용하고 있으며, 매월 비용 초과가 반복되고 있는 정보시스템(情シス) 담당자
• API 키의 발행 및 관리는 시작했지만, 부서별 이용 상황 파악까지는 미치지 못하고 있는 분
• GAS나 Google Sheets를 사용한 자동화 경험이 있으며, 비용 관리 체계를 자사에서 구축하고 싶은 분
• API 비용의 사전 관리 체제를 정비하고 싶은 정보시스템(情シス) 담당자

개발 부서가 OpenAI API를 사용하고, 영업 부서가 Claude API로 제안서 자동 생성을 돌리고, 마케팅 부서가 Gemini API로 이미지 생성을 시도하는——이러한 구조에서는 API 키조차 일원 관리되지 않는 경우가 실태로서 많습니다. 비용 초과가 발각되는 것은 "월말에 프로바이더(Provider)로부터 청구가 왔을 때"가 됩니다.

전형적인 사고 패턴은 다음 3가지입니다.

배치 처리(Batch Processing)의 폭주: 개발자가 GPT-4 계열 모델로 대량의 문서를 처리하는 스크립트를 실행하여, 며칠 만에 크레딧을 다 써버림. 입력 토큰(Token) 수의 예측이 안일할 경우 특히 일어나기 쉬움 -
여러 부서의 동시 급증: 신기능 평가 기간이 겹쳐, 여러 부서가 동시에 고비용 모델을 테스트함. 부서 전반의 예산 총액이 2~3배로 불어나도 아무도 알아차리지 못함 -
API 키 공유로 인한 귀속 불명: 개발 팀이 하나의 API 키를 부서 내외에서 돌려쓰며, 누구의 어떤 처리가 비용을 발생시켰는지 특정할 수 없게 됨

이러한 사후 구조를 만드는 근본 원인은 다음 2가지입니다.

측정 지점이 분산되어 있음: 각 프로바이더의 관리 콘솔(Management Console)에 로그인하지 않으면 사용량을 볼 수 없음 -
부서별 예산 배분이 없음: "사용한 만큼 지불한다"는 구조는 이해할 수 있지만, 누가 얼마나 사용해도 되는지가 정해져 있지 않음

이 2가지를 해소하는 설계 프레임워크가 본 기사의 핵심입니다.

AI API 비용 관리를 설계하기 전에, 프로바이더 측에서 할 수 있는 것과 GAS 측에서 할 일의 경계를 정리합니다.

프로바이더 측에서 할 수 있는 것

각 프로바이더는 API 키 단위 또는 프로젝트 단위의 상한 설정이나 알림(Alert) 기능을 가지고 있습니다.

Google Cloud (Vertex AI / Gemini API): Cloud Billing의 예산 알림 기능으로, 프로젝트 단위의 지출이 임계값을 초과했을 때 이메일 통지를 보낼 수 있습니다. 임계값은 금액 또는 퍼센테이지로 설정할 수 있으며, 여러 개의 통지 포인트를 설정하는 것도 가능합니다 -
OpenAI: 조직 설정에서 월간 이용 예산과 알림 임계값을 설정할 수 있습니다. 예산에 도달한 경우 이메일 통지와 대시보드 알림이 전달되지만, API 액세스 자체는 계속됩니다. OpenAI는 과거의 하드 리미트(Hard Limit, 자동 정지) 기능을 폐지하였으므로, 상한 도달 후에도 청구는 계속된다는 점에 주의가 필요합니다 -
Anthropic (Claude): 조직 계정에서 사용량 모니터링이 가능합니다. API 키 단위의 소비량도 관리 화면에서 확인할 수 있습니다. 알림 통지는 Admin API를 통한 구현도 가능합니다

모두 프로바이더의 관리 콘솔에서 설정할 수 있으며, 예산 초과 시 통지를 받을 수 있습니다. 이곳은 반드시 가장 먼저 설정해야 할 "하한 가드(Lower Guard)"입니다. 이 설정 없이 GAS 측의 관리만 만들면, GAS가 멈췄을 때 제어 장치가 없어집니다.

GAS 측에서 보완하는 부분

프로바이더 측의 제한만으로는 "부서별 예산 할당"과 "GWS 연동(Slack 통지·Sheets 집계·Google Chat 통지)"을 커버할 수 없습니다. 아래 표로 정리합니다.

프로바이더 측의 네이티브 기능으로 리스크의 하한을 억제하고, GAS 측에서 부서별 예산 관리와 통지를 덧씌우는 이층 구조가 현실적인 설계입니다. 어느 한쪽만으로는 빈틈이 생깁니다.

"어떻게 나눌 것인가" 이전에 "무엇을 기준으로 나눌 것인가"를 결정해야 합니다.

예산 배분의 3가지 패턴

실무에서 자주 채택되는 패턴은 다음 3종류입니다.

• 균등 배분 (Equal Allocation): 월간 총 예산을 부서 수로 나눕니다. 단순하고 설명하기 쉽지만, 이용량에 차이가 있을 경우 불공평함을 느낄 수 있습니다.
• 이용 실적 기반 (Usage-based): 최근 3개월간의 실적 비용을 참고하여 배분합니다. 실제 상황에 맞추기 쉽지만, 신설 부서 처리에 어려움이 있습니다.
• 프로젝트 기반 (Project-based): AI를 사용하는 업무 프로젝트별로 예산을 할당합니다. 입도가 세밀하여 관리하기 쉽지만, 유지보수 비용이 높습니다.

100명 규모의 기업에서는 초기에는 "균등 배분 + 이용 실적 3개월 후 재검토"라는 조합이 운영하기 쉽습니다. 처음부터 완벽한 배분을 목표로 하기보다, 우선 실행하며 실적을 확인한 뒤 조정하는 사이클을 만드는 것이 중요합니다.

예산 금액의 기준은 사용하는 모델과 처리량에 따라 크게 달라집니다. GPT-4o 계열이나 Claude 3.5 Sonnet 계열은 경량 모델보다 1030배 더 많은 비용이 드는 경우도 있습니다. 첫 23개월은 "기록만 하고 예산 설정은 하지 않는" 시범 운영 기간을 두는 것을 권장합니다. 예산 감각이 없는 상태에서 한도를 정하면, 너무 엄격한 제한으로 업무가 중단되거나, 너무 느슨해서 관리의 의미가 없어집니다.

API 키 발급 설계

부서별 관리를 기능하게 하려면, API 키와 부서 간의 대응 관계를 확립해야 합니다. 가장 확실한 방법은 부서별로 API 키를 나누어 발급하는 것입니다.

하나의 키를 여러 부서가 공유하면 비용의 귀속을 알 수 없게 됩니다. 관리 대장(Google Sheets로 충분함)에 키 ID, 발급 부서, 담당자, 용도, 생성일, 유효 기간을 기록하고 정보시스템(情シス) 부서가 일원 관리합니다.

API 키 관리 대장의 시트 열 예시입니다.

유효 기간은 6개월~1년으로 설정하고, 기간이 되면 정보시스템 부서와 부서 담당자가 이용 상황을 확인한 후 연장 또는 폐기를 판단합니다. 사용하지 않는 키를 그대로 두면, 퇴사한 직원의 단말기에 남은 키가 악용될 리스크가 남습니다. 키의 재고 조사(Inventory)는 API 비용 관리와 동시에 보안 관리와도 직결됩니다.

여기서는 "API 키가 부서별로 나누어져 있다"는 전제하에, GAS를 이용한 모니터링 구현 패턴을 보여줍니다.

설계의 골격은 3단계입니다.

• 각 부서의 API 사용량을 Google Sheets에 집약한다
• 집약된 데이터를 예산 마스터와 비교한다
• 임계값을 초과한 부서에 Slack 알림을 보낸다

Sheets 구성

두 개의 시트를 준비합니다.

• usage 시트: date, department, provider, api_key_id, estimated_cost_jpy 열 구성
• budget 시트: department, monthly_budget_jpy, alert_threshold_pct 열 구성

estimated_cost_jpy는 프로바이더의 API 응답에 포함된 토큰 사용량과 요율(Rate)로부터 계산한 추정 엔화 환산 비용을 기록합니다. 이는 어디까지나 "경향을 파악하기 위한 근사치"로 취급하며, 실적 확인은 프로바이더의 청구서(Invoice)를 기반으로 매월 수행합니다.

GAS 스크립트 (골격)

"usage 시트의 이번 달 데이터를 집계하여 budget 시트의 임계값과 비교하고 Slack 알림을 보내는" GAS 코드의 골격입니다. 자사의 예산 금액, Slack Webhook URL, 알림 문구만 바꾸면 바로 작동할 수 있도록 설계되어 있습니다.

// Slack Incoming Webhook URL은 스크립트 속성(Script Properties)으로 관리한다
const SLACK_WEBHOOK_URL = PropertiesService.getScriptProperties()
.getProperty('SLACK_WEBHOOK_URL');
...

코드 커스터마이징 포인트

이 코드는 골격이므로, 다음 3점을 자사 환경에 맞춰 조정합니다.

• SLACK_WEBHOOK_URL 관리: GAS의 스크립트 속성에 설정합니다. 코드 내에 직접 작성(Hard-coding)하면, 스크립트를 다른 멤버와 공유했을 때 비밀 정보(Secret)가 유출됩니다. 스크립트 속성은 GAS 에디터의 "프로젝트 설정"에서 추가할 수 있습니다.
• buildAlertMessage 문구: 운영 상황에 맞춰 변경합니다. 부서별로 다른 Slack 채널에 보내고 싶다면, budget 시트에 Slack Channel ID 열을 추가하여 sendSlackNotification

에 전달합니다 -
알림 임계값의 단계화: 80%에서 Warning, 100%에서 Critical과 같이 2단계로 설정하면, 부서에서 스스로 인지하고 사용량을 조절하기 쉬워집니다. buildAlertMessage의 반환값을 {text, severity} 객체로 만들어 색상을 구분하는 것도 효과적입니다.

트리거 설정

checkBudgetAndNotify는 시간 기반 트리거(Time-driven trigger)로 정기 실행합니다. GAS 에디터의 트리거 설정에서 시간 주도형 · 시간 기반 타이머 · 매일 · 특정 시간대(예: 오전 9시~10시)를 설정합니다. 대부분의 경우 매일 1회 실행으로 충분합니다. 비용이 급증하기 쉬운 월초나 프로젝트 평가 기간 중에는 하루 2회(오전/오후)로 변경하는 것도 검토해 보세요.

usage 시트에 데이터를 입력하는 방법은?

이 스크립트는 Sheets를 읽기만 합니다. Sheets에 쓰는 작업은 별도로 설계가 필요하며, 주요 선택지는 다음 세 가지입니다.

• 수동 입력 (초기 1~2개월): 이용 부서 담당자가 주 단위로 API 프로바이더(Provider)의 관리 화면을 확인하여 Sheets에 기입합니다. 자동화하기 전에 "어떤 수치를 확인해야 하는가"를 전원이 파악하는 효과가 있습니다.
• API 프록시 (Proxy) 경유: GAS로 자체 제작한 API 프록시를 준비하여, AI API로의 모든 요청을 이곳을 경유하게 합니다. 프록시가 요청마다 비용 추정치를 Sheets에 기록합니다. 정확도는 높지만 구현 비용이 발생합니다.
• 프로바이더 API로부터 정기 취득: 각 프로바이더가 제공하는 사용량 취득 엔드포인트(Endpoint)를 정기적으로 호출하여 Sheets에 기록합니다. OpenAI와 Anthropic 모두 이 엔드포인트를 제공하며, GAS의 URLFetchApp을 통해 호출할 수 있습니다. 참고로 Anthropic의 경우 Admin API Key(sk-ant-admin... 형식)가 필요합니다. 일반 API 키와는 별도로 관리 콘솔의 Settings > Admin Keys에서 발행하여 별도로 관리해야 합니다.

100명 규모라면 우선 수동 입력부터 시작하여, 익숙해지면 프로바이더 API로부터 정기 취득하는 방식으로 전환하는 단계적 접근이 현실적입니다. 체계가 운영으로서 정착된 후에 자동화하는 순서가, 만들어 놓고 사용되지 않는 대시보드가 될 리스크를 줄일 수 있습니다.

주의 사항: 비용 계산의 정확도

GAS 측에서 토큰(Token) 수로 비용을 추정할 경우, 환율 변동과 프로바이더의 가격 개정이 계산 오차를 발생시킵니다. 이 GAS는 어디까지나 "알림을 위한 실시간 근사치"로 위치시키는 것이 중요합니다. 실적 확인은 월 단위로 프로바이더의 청구서와 대조하고, 괴리가 클 경우 환율 계산 로직을 재검토합니다. "회계 수치의 대체재"가 아님을 관계 부서와 사전에 합의해 두지 않으면, 나중에 "GAS 수치와 청구서가 다르다"라는 클레임이 발생할 수 있습니다.

구현을 시작하기 전에 다음 사항을 확인하십시오.

정보 정리 (정보시스템 측)

• 사내에서 이용 중인 AI API 프로바이더와 사용 중인 API 키 목록을 보유하고 있는가
• 각 API 키가 누구의 권한으로 발행되었고, 누가 관리하고 있는지 파악하고 있는가
• 월간 허용 비용 총액에 대해 경영진과 합의가 되었는가
• 부서별 예산 범위에 대해 부서장의 합의를 얻는 프로세스가 설계되어 있는가
• 시범 운영 기간(기록만 수행)으로서 최소 2개월분의 실적 데이터 수집 계획이 있는가

기술 전제 (GAS 구현)

• GAS 프로젝트를 생성할 수 있는 GWS(Google Workspace) 계정이 있는가
• Slack Incoming Webhook 발행 권한이 있거나, 시스템 관리자에게 요청할 수 있는가
• GAS의 시간 기반 트리거를 설정할 수 있는가
• Google Sheets에 대한 읽기/쓰기 권한이 확보되었는가
• GAS의 스크립트 속성(Script Properties)에 Webhook URL 등의 비밀 정보(Secret)를 저장하는 방법을 이해하고 있는가

운영 규칙 설계

• usage 시트에 데이터를 입력하는 방법(수동 또는 자동)이 결정되었는가
• 알림이 발생했을 때의 대응 플로우(누가 어떻게 움직일 것인가)가 문서화되어 있는가
• 예산을 초과했을 경우의 API 키 무효화 절차가 결정되었는가
• GAS의 집계 값과 프로바이더 청구서의 월간 대조 담당자가 정해졌는가

AI API의 비용 관리는 체계를 만들지 않는 한 "월말에 숫자를 보고 놀라는" 사이클에서 벗어날 수 없습니다.

기술적으로 어려운 작업이 아닙니다. GAS (Google Apps Script)와 Google Sheets의 조합으로 부서별 예산 프레임 설정, 사용량 집계, Slack 알림 전송을 구현할 수 있습니다. 프로바이더(Provider) 측의 상한 설정과 GAS 측의 부서별 관리를 이중 구조로 결합하는 것이 비용 효율적인 설계입니다.

이번 주 안에 실행할 수 있는 첫 3단계는 다음과 같습니다.

각 프로바이더의 관리 콘솔에서 예산 알림을 설정하기: OpenAI, Anthropic, Google Cloud 모두 관리 콘솔에서 알림(Alert) 설정을 할 수 있습니다. OpenAI는 하드 리미트(Hard Limit, API 자동 중단)를 폐지했으므로, 알림을 받은 후 신속하게 대응할 수 있는 체계도 함께 설계하십시오 -
사내에서 사용 중인 API 키를 모두 리스트업하기: 파악되지 않은 키가 있는 단계에서는 부서별 관리가 시작될 수 없습니다. 정보시스템(情シス) 부서가 주도적으로 각 부서에 확인하고, 신규 발급은 정보시스템 부서를 거치도록 일원화하는 규칙을 세웁니다 -
Google Sheets에 월간 이용 실적을 수동으로 기록하기 시작하기: 자동화는 나중에 해도 좋습니다. 우선 2~3개월 치의 실적을 확보함으로써 부서별 예산 배분의 근거를 마련합니다

사내에 GAS를 작성할 수 있는 인재가 있다면, 이 체크리스트를 들고 자산 조사(Inventory)부터 착수하십시오. 그러면 3개월 후에는 '월말 서프라이즈'를 구조적으로 방지할 수 있는 체계가 갖춰질 것입니다.

이 기사에서 다룬 것과 같은 업무 개선 및 자동화의 설계부터 구현까지, DRASENAS는 코포레이트 IT (Corporate IT) 현장에 밀착하여 지원을 제공하고 있습니다.

'우선 상담만' 하는 것도 대환영입니다. DRASENAS 공식 사이트를 통해 편하게 문의해 주세요.

※ 이 기사는 DRASENAS Blog의 전재물입니다. 오리지널 버전에서는 코드와 설정 절차가 수시로 업데이트되고 있습니다.