AI API 비용이 새기 전에 작은 서비스의 상한을 만드는 법

AI 기능을 붙인 작은 서비스는 사용자가 없을 때보다 반응이 오기 시작했을 때 더 위험해질 수 있습니다. 한 번의 요약이나 이미지 생성은 작아 보여도 반복 요청, 긴 출력, 실패 재시도가 겹치면 운영자가 확인하기 전에 비용이 늘어납니다.

비용 관리는 수도꼭지 아래에 월말 고지서를 두는 일이 아닙니다. 수도꼭지마다 최대 흐름을 정하고, 계량기를 읽고, 일정 수준에서 알리고, 넘치기 전에 밸브를 잠그는 과정에 가깝습니다. 대시보드 예산 하나만 믿기보다 서비스 안팎에 여러 겹의 경계를 두어야 합니다.

먼저 한 번의 성공 비용을 계산한다

AI API는 다른 회사의 AI 모델을 내 프로그램에서 요청해 쓰는 연결 창구입니다. 많은 텍스트 모델은 입력과 출력의 token, 즉 글을 처리하기 위해 나눈 단위 수에 따라 비용을 계산합니다. 모델과 기능에 따라 이미지, 음성 길이, 저장 공간, 도구 호출처럼 다른 기준이 더해질 수 있습니다.

월 총액만 보면 어떤 기능이 비용을 만드는지 알기 어렵습니다. “답변 생성 한 건”, “문서 요약 한 건”, “사용자가 실제로 저장한 결과 한 건”처럼 성공 단위를 정하고 아래 항목을 기록합니다.

• 요청에 들어간 입력량과 나온 출력량을 나눕니다.
• 실패와 재시도에 든 사용량도 포함합니다.
• 검색, 파일 저장, 이미지 같은 부가 기능 비용을 구분합니다.
• 무료 사용과 유료 사용을 별도 집계합니다.
• 단가는 글에 고정하지 않고 실행 시점 공식 가격표에서 확인합니다.

같은 요청도 모델, 출력 길이, 캐시 적용, 부가 도구에 따라 비용이 달라질 수 있습니다. 근거 없이 “한 번에 얼마”라고 고정하지 말고 실제 사용량 자료로 평균과 큰 값의 범위를 봅니다.

상한은 요청 전에 정해야 한다

비용이 발생한 뒤 대시보드에서 발견하면 이미 늦습니다. 사용자 한 명이 하루에 실행할 수 있는 횟수, 한 요청의 입력 길이, 최대 출력 길이, 동시에 처리할 작업 수를 기능 설계 단계에서 정합니다. 이 제한은 돈뿐 아니라 응답 지연과 서비스 안정성도 지켜 줍니다.

예를 들어 긴 문서 요약 기능이라면 다음처럼 설명할 수 있습니다.

사용자당 하루 요청 10회
요청당 문서 최대 20쪽
출력 최대 1,000자
실패 재시도 최대 2회

위 숫자는 설명용 예시이지 모든 서비스에 맞는 기준이 아닙니다. 실제 제한은 가격, 사용자 가치, 서버 용량, 결제 약속을 보고 정해야 합니다. 화면에도 제한과 초기화 시점을 숨기지 않아야 사용자가 같은 요청을 반복하지 않습니다.

가격표와 사용량 자료의 역할을 구분한다

OpenAI의 현재 공식 가격표는 텍스트 모델의 입력, 캐시된 입력, 출력처럼 서로 다른 과금 항목을 구분하고 웹 검색이나 컨테이너 같은 도구별 비용도 따로 안내합니다. 한 가지 단가만 곱하면 실제 청구 구조를 놓칠 수 있으므로 사용하는 모델과 도구의 현재 항목을 모두 확인해야 합니다.

가격표는 단가를 알려 주지만 내 서비스가 어느 사용자에게 몇 번의 요청을 허용했는지는 알려 주지 않습니다. Usage API 같은 사용량 자료는 실제 소비를 확인하는 데 도움이 되지만, 그 자료를 읽는 일과 다음 요청을 차단하는 일은 별도 구현입니다. 현재 문서와 계정 화면을 확인한 날짜를 운영 기록에 남기고 자동으로 멈춘다고 가정하지 않습니다.

하드 상한은 서비스 내부에도 둔다

hard cap은 한도에 닿으면 실제 요청을 막는 강제 상한을 뜻합니다. 제공사 설정이 알림만 보낸다면 내 서버가 오늘과 이번 달의 사용량을 확인해 새 요청을 거부하거나 저비용 경로로 보내야 합니다. 브라우저 화면에서 버튼만 비활성화하면 직접 API 요청으로 우회될 수 있으므로 서버에서 검사합니다.

예상 비용 확인
→ 기능별 남은 한도 확인
→ 허용이면 API 요청
→ 실제 사용량 기록
→ 임계값을 넘으면 다음 요청 차단

동시에 여러 요청이 들어오면 각각이 남은 한도가 있다고 판단해 합계가 넘어갈 수 있습니다. 사용량 예약, 대기열, 원자적 갱신처럼 중복 실행을 막는 구조가 필요할 수 있습니다. 결제와 환불까지 연결된 서비스라면 단순 파일 숫자 하나보다 신뢰할 수 있는 서버 저장소와 거래 기록을 사용합니다.

알림은 한 번이 아니라 단계로 보낸다

비용이 상한에 닿은 뒤 처음 알게 되면 대응할 시간이 없습니다. 정상 범위, 주의 범위, 중단 직전, 차단 상태처럼 여러 임계값을 둡니다. 알림에는 총액만 쓰지 말고 어느 프로젝트, 기능, 모델, 사용자가 변화를 만들었는지 조사할 단서를 포함합니다.

• 예상 범위의 절반에서 추세를 확인합니다.
• 주의 단계에서 비정상 반복 요청과 긴 출력을 봅니다.
• 중단 직전에는 새 기능과 대량 작업을 보류합니다.
• 상한 도달 시 유료 API 호출을 막고 사용자에게 상태를 설명합니다.
• 담당자가 확인한 뒤에만 제한을 올리며 변경 이유를 기록합니다.

알림에 API 키, 사용자 입력 원문, 개인정보를 넣지 않습니다. 야간 알림을 아무도 보지 않는다면 상한이 대신 요청을 멈출 수 있어야 합니다. 반대로 작은 흔들림마다 알림을 보내면 중요한 신호가 묻히므로 기능별 평소 범위를 바탕으로 조정합니다.

사용량과 비용 자료를 함께 본다

OpenAI의 현재 Usage API는 조직의 여러 사용량 항목을 조회할 수 있고 Costs 항목으로 비용 자료를 볼 수 있게 합니다. 공식 설명은 사용량 집계와 비용이 작은 기록 차이로 완전히 일치하지 않을 수 있으며 재무 확인에는 비용 자료나 사용 대시보드를 보라고 안내합니다.

요청 수만 기록하면 긴 출력 한 건과 짧은 출력 한 건을 같은 값으로 보게 됩니다. 내 서비스 로그에는 요청 ID, 기능 이름, 성공 여부, 사용자 구분용 내부 식별자, 입력과 출력 사용량을 최소한으로 남기고, 제공사 비용 자료와 정기적으로 대조합니다. 사용자 입력 전문과 비밀키는 비용 분석 로그에 넣지 않습니다.

비상 경로는 단순하고 값싸게 만든다

상한에 닿았을 때 전체 서비스를 오류 화면으로 만들 필요는 없습니다. AI가 꼭 필요한 기능만 멈추고 저장된 결과 읽기, 일반 검색, 직접 입력 같은 비유료 기능은 유지할 수 있습니다. 낮은 비용의 모델이나 짧은 출력으로 전환할 때는 품질이 달라진다는 사실을 사용자에게 숨기지 않습니다.

재시도도 비용 경계에 포함합니다. 속도 제한이나 일시 오류에 지수 백오프, 즉 실패할수록 기다리는 시간을 늘리는 방식을 쓸 수 있지만 같은 작업이 이미 처리됐는지 확인해야 합니다. 결제 승인, 이메일 발송, 이미지 생성처럼 중복 결과가 생길 수 있는 기능은 요청 식별자와 상태 조회를 둡니다.

가격 변경은 코드와 화면을 함께 점검한다

모델 가격과 과금 항목은 변할 수 있으므로 글이나 코드에 오래된 단가를 사실처럼 박아 두지 않습니다. 공식 가격표를 확인한 날짜, 계산에 사용한 모델 ID, 입력과 출력 구분, 환율과 세금 포함 여부를 내부 문서에 남깁니다. 사용자에게 크레딧을 판매한다면 사용 조건과 소진 방식을 결제 전에 설명합니다.

모델을 바꿀 때는 비용만 비교하지 않습니다. 같은 평가 입력으로 품질, 지연, 실패율, 사용량을 함께 측정합니다. 저렴한 모델이 더 많은 재시도와 고객 지원을 만들면 완료 한 건의 실제 비용은 오를 수 있습니다.

오늘 바로 해볼 작은 실습

실제 결제나 계정 설정을 바꾸지 않고 10분짜리 비용 경계표를 만듭니다.

1. AI를 호출하는 기능을 한 개만 고릅니다.
2. 사용자 한 명의 하루 최대 요청 수를 가정해 적습니다.
3. 입력 길이, 출력 길이, 재시도 횟수의 상한을 적습니다.
4. 사용량을 50%, 80%, 100%로 나눠 각 단계의 행동을 씁니다.
5. 제공사 예산이 알림인지 차단인지 공식 문서에서 확인할 칸을 둡니다.
6. 상한에 닿았을 때 유지할 비유료 기능과 중지할 기능을 구분합니다.

API 키를 문서, 브라우저 코드, 채팅에 붙이지 마세요. 예산 경고가 왔다고 원인을 확인하지 않은 채 한도를 올리거나 자동 충전 금액을 키우지 않습니다. 현재 사용량과 비용 자료, 반복 요청 원인, 사용자 영향, 복구 경로를 설명할 수 없으면 새 호출을 먼저 멈추는 것이 작은 서비스의 안전한 운영 기준입니다.