OpenAI API 기능별 사용량 추적: 비용 귀속 가이드

OpenAI 인보이스는 지난달 $4,237를 썼다고 알려줍니다. 하지만 그중 $3,100가 폭주한 요약 엔드포인트에서 발생했고, $700는 월 $50를 내는 고객에게서, $437는 아무도 쓰지 않는 기능에서 발생했다는 사실은 알려주지 않습니다. 기본 대시보드만으로는 가격 책정, 용량 계획, 로드맵 결정을 할 수 없습니다.

지금 Apidog 사용해 보기

이 글에서는 OpenAI API 비용을 기능, 경로, 고객 단위로 귀속하는 구현 방법을 다룹니다. 핵심은 모든 요청에 메타데이터를 붙이고, 토큰 수와 비용을 구조화된 로그로 남기고, 데이터 웨어하우스에서 집계한 뒤, 키별 예산 상한과 알림을 설정하는 것입니다.

💡 Apidog는 비용 추적 래퍼를 프로덕션에 배포하기 전에 요청 수준 가시성과 시나리오 테스트를 제공합니다. 태그가 지정된 요청을 재생하고, 로그 형태를 확인하며, 모든 호출이 데이터 웨어하우스가 기대하는 메타데이터를 포함하는지 검증하는 데 사용할 수 있습니다.

요약 (TL;DR)

구현해야 할 것은 단순합니다.

1. 모든 OpenAI API 호출을 하나의 래퍼 함수로 통과시킵니다.
2. 각 호출에 feature, route, customer_id, environment를 필수로 붙입니다.
3. response.usage에서 토큰 수를 읽고, 쓰기 시점에 cost_usd를 계산합니다.
4. 요청당 JSON 로그 한 줄을 남깁니다.
5. BigQuery, ClickHouse, Snowflake, Postgres 같은 웨어하우스에서 집계합니다.
6. OpenAI 프로젝트 키별 상한과 자체 알림을 함께 둡니다.
7. Apidog 시나리오 테스트로 래퍼와 로그 스키마를 검증합니다.

왜 OpenAI 청구 대시보드만으로는 부족한가

OpenAI 청구 페이지는 일일 지출, 모델별 사용량, 조직 수준 제한을 보여줍니다. 애플리케이션 하나, 고객 하나, 기능 하나만 있다면 충분할 수 있습니다.

하지만 실제 프로덕션에서는 보통 다음 질문에 답해야 합니다.

• 어떤 기능이 비용을 만들었는가?
• 어떤 고객이 가장 많은 비용을 발생시키는가?
• 어떤 API 경로가 폭주하고 있는가?
• 스테이징 비용과 프로덕션 비용은 분리되어 있는가?
• 특정 기능의 시간당 지출이 평소보다 급증했는가?

기본 대시보드는 이 질문에 답하지 못합니다.

기본 대시보드의 한계

컨텍스트 없는 총액

대시보드는 어제 GPT-5.5에 $312를 썼다고 알려줄 수 있습니다. 하지만 이것이 고객 한 명의 지원 채팅 호출 때문인지, 잘못된 배치 작업이 전체 지식 기반을 다시 요약했기 때문인지는 알려주지 않습니다.

기능별 분석 없음

OpenAI는 모델과 키 기준 사용량은 보여주지만, 제품 기능, HTTP 경로, 고객 ID, 환경 같은 애플리케이션 수준 차원은 제공하지 않습니다.

보고 지연

사용량 데이터는 수십 분에서 몇 시간 지연될 수 있습니다. 폭주 루프를 대시보드에서 확인했을 때는 이미 비용이 발생한 뒤입니다.

세밀한 알림 부족

조직 단위 예산 상한과 이메일 알림은 가능하지만, “지원 채팅 엔드포인트가 한 시간에 $50를 넘으면 Slack으로 알림” 같은 조건은 직접 만들어야 합니다.

고객별 귀속 없음

B2B SaaS에서 AI 기능을 제공한다면 고객별 LLM 원가를 알아야 합니다. 그래야 가격 책정, 사용량 제한, 상향 판매, 총마진 계산이 가능합니다.

프로젝트 키만으로는 부족함

OpenAI 프로젝트 키는 프로젝트별 분리를 제공합니다. 하지만 기능별, 고객별, 경로별 귀속은 여전히 애플리케이션에서 직접 처리해야 합니다. OpenAI 사용량 API도 요청 단위가 아니라 집계 데이터를 반환합니다.

이 문제는 LLM 기능을 운영하는 대부분의 팀에서 반복됩니다. Dev.to의 “OpenAI는 당신이 얼마를 썼는지 알려줍니다. 어디에 썼는지는 아닙니다. 그래서 대시보드를 만들었습니다”라는 주제가 공감을 얻은 이유도 여기에 있습니다.

비용 계산에 필요한 가격 맥락은 GPT-5.5 가격 분석을 참고하십시오. 개발자 도구 측면의 관련 문제는 API 팀을 위한 GitHub Copilot 사용량 청구를 참고할 수 있습니다. OpenAI API 기본 사항은 공식 OpenAI API 참조를 확인하십시오.

비용 귀속 데이터 모델 설계

비용 귀속의 기본 단위는 “OpenAI 요청 1건”입니다.

모든 요청은 다음 정보를 가진 이벤트로 기록되어야 합니다.

중요한 원칙은 쿼리 시점이 아니라 쓰기 시점에 비용을 계산하는 것입니다. 가격은 바뀔 수 있습니다. 과거 이벤트는 해당 요청이 발생한 날의 요율로 고정되어야 합니다.

비용 계산 함수 만들기

다음은 GPT-5.5 계열 가격을 기준으로 한 예시입니다.

PRICING = {  # USD per 1M tokens, as of May 2026
    "gpt-5.5":      {"input": 5.00,  "cached": 2.50,  "output": 30.00},
    "gpt-5.5-pro":  {"input": 30.00, "cached": 15.00, "output": 180.00},
    "gpt-5.4":      {"input": 2.50,  "cached": 1.25, "output": 15.00},
    "gpt-5.4-mini": {"input": 0.25,  "cached": 0.125, "output": 2.00},
}

def compute_cost_usd(
    model,
    prompt_tokens,
    cached_tokens,
    completion_tokens,
    reasoning_tokens
):
    rates = PRICING[model]

    uncached = max(0, prompt_tokens - cached_tokens)

    input_cost = (uncached * rates["input"]) / 1_000_000
    cache_cost = (cached_tokens * rates["cached"]) / 1_000_000
    output_cost = (
        (completion_tokens + reasoning_tokens) * rates["output"]
    ) / 1_000_000

    return round(input_cost + cache_cost + output_cost, 6)

주의할 점은 reasoning_tokens입니다. OpenAI API는 이를 usage.completion_tokens_details.reasoning_tokens에 반환하지만, 요금은 출력 토큰 기준으로 계산됩니다. 이를 입력으로 처리하면 Thinking 모드 호출 비용을 잘못 계산하게 됩니다.

전체 가격 맥락은 GPT-5.5 가격 분석을 참고하십시오.

OpenAI 클라이언트 래퍼 구현

이제 모든 OpenAI 호출이 하나의 함수만 통과하도록 만듭니다.

import time
import uuid
import json
import logging
from openai import OpenAI

client = OpenAI()
logger = logging.getLogger("llm.cost")

def call_with_attribution(
    *,
    feature,
    route,
    customer_id,
    environment,
    model,
    messages,
    **openai_kwargs
):
    request_id = str(uuid.uuid4())
    started = time.time()
    error_code = None
    response = None

    try:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            **openai_kwargs
        )
        return response

    except Exception as e:
        error_code = getattr(e, "code", "unknown_error")
        raise

    finally:
        latency_ms = int((time.time() - started) * 1000)

        u = response.usage if response else None

        prompt_tokens = getattr(u, "prompt_tokens", 0)
        completion_tokens = getattr(u, "completion_tokens", 0)

        cached_tokens = (
            getattr(
                getattr(u, "prompt_tokens_details", None),
                "cached_tokens",
                0
            ) or 0
        )

        reasoning_tokens = (
            getattr(
                getattr(u, "completion_tokens_details", None),
                "reasoning_tokens",
                0
            ) or 0
        )

        cost_usd = compute_cost_usd(
            model,
            prompt_tokens,
            cached_tokens,
            completion_tokens,
            reasoning_tokens
        )

        logger.info(json.dumps({
            "event": "openai.request",
            "request_id": request_id,
            "feature": feature,
            "route": route,
            "customer_id": customer_id,
            "environment": environment,
            "model": model,
            "prompt_tokens": prompt_tokens,
            "completion_tokens": completion_tokens,
            "reasoning_tokens": reasoning_tokens,
            "cached_tokens": cached_tokens,
            "latency_ms": latency_ms,
            "cost_usd": cost_usd,
            "error_code": error_code,
        }))

이 래퍼가 비용 귀속의 단일 진입점입니다.

코드베이스에서 다음 패턴을 검색해 모두 교체합니다.

OpenAI(
client.chat.completions.create

모든 호출은 다음처럼 명시적으로 태그를 전달해야 합니다.

response = call_with_attribution(
    feature="support-chat",
    route="/api/v1/chat/answer",
    customer_id=current_user.customer_id,
    environment="prod",
    model="gpt-5.5",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_question},
    ],
)

feature, route, customer_id, environment는 기본값을 두지 않는 것이 좋습니다. 누락되면 "unknown"으로 기록하지 말고 오류를 발생시키십시오. "unknown"은 나중에 귀속 블랙홀이 됩니다.

Node.js에서도 구조는 같습니다.

• OpenAI SDK를 직접 호출하지 않습니다.
• 래퍼 함수가 메타데이터를 받습니다.
• response.usage를 읽습니다.
• 비용을 계산합니다.
• JSON 이벤트를 stdout, Kafka, NATS, Pub/Sub, OTLP 중 하나로 보냅니다.

구조화 로그를 데이터 웨어하우스로 보내기

요청당 JSON 한 줄이면 충분합니다.

예시 로그:

{
  "event": "openai.request",
  "request_id": "7a91d2d3-1d7f-4a21-91b5-f29b7f12a111",
  "feature": "support-chat",
  "route": "/api/v1/chat/answer",
  "customer_id": "cust_4291",
  "environment": "prod",
  "model": "gpt-5.5",
  "prompt_tokens": 15234,
  "completion_tokens": 812,
  "reasoning_tokens": 4500,
  "cached_tokens": 12000,
  "latency_ms": 2341,
  "cost_usd": 0.045672,
  "error_code": null
}

기존 로그 파이프라인을 재사용하십시오.

• Vector
• Fluent Bit
• Logstash
• OpenTelemetry Collector
• Cloud Logging
• Datadog
• Kafka 기반 이벤트 파이프라인

대상은 BigQuery, ClickHouse, Snowflake, Postgres 등 무엇이든 됩니다. 별도 서비스가 꼭 필요한 것은 아닙니다.

기능별 비용 집계 쿼리

이벤트가 웨어하우스에 들어오면, 대시보드는 SQL 문제로 바뀝니다.

SELECT
  feature,
  DATE_TRUNC(timestamp, DAY) AS day,
  COUNT(*) AS requests,
  SUM(cost_usd) AS spend_usd,
  SUM(prompt_tokens + completion_tokens) AS tokens,
  AVG(latency_ms) AS avg_latency_ms,
  SUM(cached_tokens) / NULLIF(SUM(prompt_tokens), 0) AS cache_hit_rate
FROM openai_events
WHERE environment = 'prod'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY feature, day
ORDER BY day DESC, spend_usd DESC;

운영 대시보드에는 최소한 다음 세 가지 뷰를 만드십시오.

1. 시간대별 기능별 지출
2. 시간대별 고객별 지출
3. 어제 지출 기준 상위 20개 경로

Grafana, Metabase, Looker, Superset 등 어떤 BI 도구든 사용할 수 있습니다.

Apidog로 배포 전 검증하기

많은 팀이 래퍼는 만들지만 검증을 건너뜁니다. 그러면 스키마가 조용히 틀어지고, 대시보드는 그럴듯한 거짓말을 보여줍니다.

Apidog로 다음 시나리오를 만드십시오.

1. 알려진 customer_id, feature를 사용해 AI 엔드포인트에 요청을 보냅니다.
2. 응답과 로그 방출을 함께 확인합니다.
3. 로그 페이로드에 다음 필드가 있는지 검증합니다.
   • feature
   • route
   • customer_id
   • environment
   • model
   • prompt_tokens
   • completion_tokens
   • cost_usd
4. cost_usd > 0인지 확인합니다.
5. prompt_tokens > 0인지 확인합니다.
6. Apidog 환경 변수를 사용해 staging/prod에서 같은 시나리오를 실행합니다.
7. 동일 요청을 재생하여 재시도 시 비용이 중복 집계되지 않는지 확인합니다.

재시도 처리에서는 request_id가 중요합니다. 애플리케이션 레벨에서 같은 작업을 재시도한다면 같은 request_id를 전달하고, 웨어하우스 적재 또는 집계 단계에서 중복 제거해야 합니다.

API 테스트 접근 방식은 QA 엔지니어를 위한 API 테스트 도구를 참고하십시오. 계약 기반 API 개발과 함께 운영하려면 계약 우선 API 개발도 참고할 수 있습니다.

프로젝트 키와 예산 상한 설정

애플리케이션 수준 귀속과 별개로 OpenAI 프로젝트 키는 방어선으로 사용하십시오.

예시:

• prod-support-chat
• prod-summarization
• prod-agent
• staging-all
• dev-all

각 키에 하드 상한을 설정하면 하나의 기능이 폭주해도 조직 전체 예산을 소진하지 않습니다.

그 위에 자체 알림을 둡니다.

예를 들어 10분마다 다음 로직을 실행합니다.

• 기능별 최근 1시간 지출 계산
• 같은 기능의 7일 이동 평균 시간당 지출 계산
• 현재 지출이 평균의 3배를 넘으면 Slack/PagerDuty/Opsgenie 알림

트리거는 OpenAI 대시보드가 아니라 데이터 웨어하우스에서 나와야 합니다. 그래야 지연을 줄이고 원하는 차원으로 감지할 수 있습니다.

고급 최적화 패턴

프롬프트 캐싱

GPT-5.5는 캐시된 토큰에 대해 입력 요금의 50%를 청구합니다.

캐시 적중률을 높이려면 다음처럼 프롬프트를 구성하십시오.

• 안정적인 시스템 프롬프트를 앞에 둡니다.
• 자주 바뀌는 사용자 입력은 뒤에 둡니다.
• 버전이 바뀌는 프롬프트에는 prompt_cache_key를 명시적으로 기록합니다.

대시보드에서는 기능별 cache_hit_rate를 추적하십시오. 프롬프트 변경 후 캐시 적중률이 떨어지면 입력 비용이 조용히 증가할 수 있습니다.

공식 규칙은 OpenAI 프롬프트 캐싱 문서를 참고하십시오.

배치 API 사용

동기 응답이 필요 없는 작업은 배치 API로 보내십시오.

대표 예시:

• 야간 요약
• 평가 실행
• 임베딩 백필
• 문서 재처리
• 대량 분류 작업

배치 작업에도 동일한 귀속 스키마를 적용하십시오. batch_job_id를 추가하면 원래 워크로드와 연결할 수 있습니다.

추론 노력 튜닝

GPT-5.5 Thinking 계열은 reasoning.effort에 따라 출력 토큰이 늘어납니다.

각 기능에 대해 다음을 점검하십시오.

• medium이 꼭 필요한가?
• low로 품질 기준을 통과하는가?
• 노력 수준별 비용 대비 품질은 어떤가?

A/B 테스트를 통해 품질과 비용을 함께 기록하고, 품질이 유지된다면 더 낮은 옵션을 배포하십시오. 관련 구현 맥락은 GPT-5.5 API 사용 방법을 참고하십시오.

컨텍스트 창 관리

긴 프롬프트는 비용을 빠르게 증가시킵니다.

RAG를 사용한다면 전체 문서를 컨텍스트 창에 넣지 말고 검색 예산을 제한하십시오.

기능별로 다음 지표를 추적합니다.

SELECT
  feature,
  AVG(prompt_tokens) AS avg_prompt_tokens,
  PERCENTILE_CONT(prompt_tokens, 0.95) AS p95_prompt_tokens
FROM openai_events
WHERE environment = 'prod'
GROUP BY feature
ORDER BY avg_prompt_tokens DESC;

기능 변경이 없는데 prompt_tokens가 매주 증가한다면 프롬프트가 비대해지고 있는 것입니다.

GPT-5.5 272K 토큰 절벽 감지

GPT-5.5는 272K 토큰을 초과하는 요청에 대해 입력 2배, 출력 1.5배 승수가 적용됩니다.

래퍼에 다음 가드를 추가하십시오.

if prompt_tokens > 250_000:
    logger.warning(json.dumps({
        "event": "openai.large_context_warning",
        "request_id": request_id,
        "feature": feature,
        "route": route,
        "customer_id": customer_id,
        "prompt_tokens": prompt_tokens,
    }))

가격 세부 정보는 GPT-5.5 가격 책정 게시물을 참고하십시오.

고객별 지출 상한

B2B SaaS에서는 고객별 AI 사용량 제한이 필요합니다.

간단한 패턴은 다음과 같습니다.

1. 고객별 월 누적 cost_usd를 계산합니다.
2. 각 OpenAI 호출 전에 고객의 사용량을 확인합니다.
3. 한도를 넘으면 OpenAI를 호출하지 않고 429를 반환합니다.
4. 응답에는 “월별 AI 할당량 초과” 메시지와 업그레이드 CTA를 포함합니다.

예시:

def ensure_customer_budget(customer_id):
    spend = get_month_to_date_llm_spend(customer_id)
    limit = get_customer_llm_limit(customer_id)

    if spend >= limit:
        raise AiQuotaExceeded(
            f"Monthly AI quota exceeded for customer {customer_id}"
        )

이렇게 해야 AI 기능이 마진 리스크가 아니라 가격 책정 가능한 제품 기능이 됩니다.

피해야 할 실수

• 추론 토큰을 입력 토큰으로 계산하는 것
• 실시간 알림을 OpenAI 대시보드에 의존하는 것
• SDK 내부에서만 태그를 붙이고 호출 지점의 기능 컨텍스트를 잃는 것
• Cron, 큐 워커, 웹훅 같은 백그라운드 작업에 태그를 붙이지 않는 것
• 요청을 샘플링하는 것
• customer_id를 null로 두는 것
• 실패한 요청과 성공 후 재시도된 요청을 구분하지 않는 것
• 가격표를 코드에 넣고 업데이트 절차를 만들지 않는 것

백그라운드 작업에는 다음처럼 합성 route를 사용하십시오.

cron:nightly-summarize
queue:image-caption
webhook:crm-sync

customer_id를 모를 경우에도 null 대신 internal, system, unknown_customer처럼 명시적인 값을 사용하십시오.

대안 및 도구 비교

직접 구축하지 않아도 됩니다. 선택지는 다음과 같습니다.

프록시 기반 도구는 빠르게 시작할 수 있지만 경로에 추가 홉이 생깁니다. 자체 호스팅 관찰성 도구는 제어권이 크지만 운영 부담이 있습니다. 맞춤형 웨어하우스 접근은 초기 구현이 필요하지만 대규모 팀이 결국 선택하는 경우가 많습니다.

프록시 기반 접근은 Helicone 팀의 LLM 비용 추적 가이드를 참고하십시오. 오픈 소스 접근은 Langfuse 비용 추적 문서를 참고할 수 있습니다.

플랫폼 규모에서 이 패턴을 운영한다면 마이크로서비스 아키텍처를 위한 API 플랫폼도 참고하십시오.

실제 사용 사례

고객별 LLM 지출이 필요한 B2B SaaS

한 영업 인텔리전스 제품은 고객의 요약 요청마다 GPT-5.5를 호출합니다.

귀속을 도입하기 전에는 월 OpenAI 비용이 $80,000라는 사실만 알 수 있었습니다. 고객별 귀속을 적용한 뒤에는 고객의 12%가 지출의 71%를 만든다는 것을 확인했습니다.

이후 팀은 다음을 도입했습니다.

• 계층별 가격
• 하위 플랜의 소프트 할당량
• 좌석당 초과 요금

그 결과 AI 기능의 총마진이 한 분기 만에 41%에서 73%로 증가했습니다.

내부 개발자 도구 비용 추적

한 엔지니어링 조직은 모든 개발자에게 개인 GPT-5.5 채팅 도우미를 제공합니다.

customer_id에 개발자 이메일을 기록하자, 세 명의 개발자가 내부 LLM 지출의 50%를 차지한다는 사실이 드러났습니다.

두 명은 끄는 것을 잊은 자동화 에이전트 루프를 실행 중이었고, 이를 중단해 월 $1,800를 절감했습니다. 나머지 한 명은 실제 업무상 높은 사용량이 필요했고, 데이터는 더 높은 할당량을 정당화하는 근거가 되었습니다.

AI 기능 출시 전 비용 예측

제품팀이 새 요약 기능을 출시하려 할 때, 과거 기능별 데이터를 사용해 다음을 예측할 수 있습니다.

• 호출당 평균 입력 토큰
• 호출당 평균 출력 토큰
• 활성 사용자당 예상 호출 수
• 예상 활성 사용자 수
• 사용자당 일/월 비용

예측 결과가 활성 사용자당 하루 $0.04, 월 $1.20이라면, 가격 책정팀은 기능을 사용자당 월 $5로 책정할 수 있습니다. 단위 경제학이 보이면 재무 승인도 쉬워집니다.

결론

OpenAI 청구 대시보드는 “얼마를 썼는가”에는 답합니다. 하지만 제품팀과 엔지니어링팀은 “어디에서, 누가, 왜 썼는가”를 알아야 합니다.

구현 체크리스트는 다음과 같습니다.

• 모든 요청에 feature, route, customer_id, environment를 필수로 붙입니다.
• OpenAI 호출을 단일 래퍼로 통과시킵니다.
• response.usage에서 토큰 수를 읽고 쓰기 시점에 비용을 계산합니다.
• 요청당 구조화된 JSON 로그를 남깁니다.
• 웨어하우스에서 기능별, 고객별, 경로별로 집계합니다.
• 프로젝트 키별 하드 상한을 설정합니다.
• 웨어하우스 기반 알림을 추가합니다.
• 배포 전에 Apidog로 로그 스키마와 시나리오를 검증합니다.
• 추론 노력, 프롬프트 크기, 캐시 적중률을 정기적으로 감사합니다.

Apidog를 다운로드하여 비용 귀속 래퍼를 엔드투엔드로 검증할 수 있습니다. 태그가 지정된 요청으로 AI 엔드포인트를 호출하고, 로그 페이로드 형태를 확인하며, 여러 환경에서 시나리오를 재생해 데이터 웨어하우스가 신뢰할 수 있는 데이터를 받고 있는지 확인하십시오.

관련 비용 관리 자료는 GPT-5.5 가격 분석과 API 팀을 위한 GitHub Copilot 사용량 청구를 참고하십시오.

자주 묻는 질문 (FAQ)

추론 토큰은 입력인가요, 출력인가요?

출력 요율로 청구됩니다. OpenAI API는 usage.completion_tokens_details.reasoning_tokens에 값을 반환합니다. 비용 계산 시 completion_tokens에 더하십시오. 자세한 내용은 GPT-5.5 가격 분석을 참고하십시오.

response.usage는 OpenAI 대시보드와 얼마나 일치하나요?

토큰 수는 대시보드와 토큰 단위로 일치합니다. 다만 오래된 가격표로 비용을 계산하면 가격 변경 때문에 차이가 생길 수 있습니다. 모델별 요율은 고정하고, OpenAI가 가격 변경을 발표하면 버전을 업데이트하십시오.

OpenAI 프로젝트 키만으로 귀속할 수 있나요?

부분적으로만 가능합니다. 프로젝트 키는 프로젝트 단위 귀속을 제공합니다. 기능별, 고객별, 경로별 귀속은 애플리케이션 메타데이터가 필요합니다.

재시도 요청은 비용이 이중 계산되나요?

모델 실행 전에 실패한 요청은 보통 usage를 반환하지 않으므로 비용이 기록되지 않습니다. 하지만 성공 후 애플리케이션 레이어에서 재시도하면 중복 기록될 수 있습니다. 같은 작업의 재시도는 동일한 request_id를 사용하고, 저장 또는 집계 단계에서 중복 제거하십시오.

OpenAI 사용량 API는 실시간인가요?

아니요. 수십 분 정도 지연될 수 있습니다. 실시간 알림, 킬 스위치, 고객별 제한에는 자체 이벤트 로그와 웨어하우스를 사용하십시오. 월별 대사에는 사용량 API가 적합합니다.

로그 볼륨을 줄이기 위해 샘플링해도 되나요?

권장하지 않습니다. 요청당 JSON 한 줄이면 데이터 볼륨은 작습니다. 샘플링하면 고객별, 경로별 귀속 정확도가 깨집니다. 모든 요청을 기록하십시오.

다른 LLM 공급자에도 같은 방식을 쓸 수 있나요?

가능합니다. 스키마에 provider 열을 추가하십시오.

예:

openai
anthropic
google
deepseek

공급자별 래퍼와 가격표만 다르고, 웨어하우스와 대시보드는 재사용할 수 있습니다. 비교 자료로 DeepSeek V4 API 가격을 참고하십시오.

임베딩과 이미지 생성에도 적용되나요?

예. 비용 계산식만 다릅니다.

• 임베딩: 입력 토큰 기준 과금
• 이미지 생성: 이미지 수, 해상도, 품질 기준 과금
• 채팅: 입력/캐시/출력/추론 토큰 기준 과금

스키마에 endpoint를 추가하면 됩니다.

chat
embeddings
image

그리고 endpoint별로 비용 계산 함수를 분기하십시오.