가격 페이지에서는 저렴해 보이는 API 요청이 실제 제품 내부에서는 훨씬 더 비싸질 수 있습니다.

가격 페이지는 보통 다음과 같은 단위 요율 (unit rate)을 제공합니다:

• 입력 토큰 100만 개당 가격
• 출력 토큰 100만 개당 가격
• 생성된 이미지당 가격
• 비디오 초당 가격
• 크레딧당 가격

이는 유용하지만, 아직 실제 운영 예산 (production budget)은 아닙니다.

실제 운영 워크플로우 (production workflow)에는 반복되는 컨텍스트 (context), 도구 결과 (tool results), 캐시 쓰기 (cache writes), 재시도 (retries), 중복 제출, 실패한 미디어 작업, 그리고 사용자가 거부하고 다시 생성하는 출력물 등이 포함될 수 있습니다.

저는 이러한 요소들이 추정치를 얼마나 변화시키는지 확인하고 싶었기에, 세 가지 서로 다른 워크로드 (workload)에 대해 동일한 예산 모델을 구축했습니다:

1. 일반적인 LLM 애플리케이션
2. 코딩 에이전트 (coding-agent) 워크플로우
3. 이미지 생성 기능

이 글에서는 그 방법을 설명합니다. 또한 글 마지막에 수정 가능한 계산기와 다운로드 가능한 CSV 데이터셋을 게시했습니다.

시나리오 1: 일반적인 LLM 애플리케이션

다음과 같은 사용량을 가진 소규모 애플리케이션을 가정해 보겠습니다:

월간 활성 사용자 (monthly active users) 100명
월간 활성 일수 20일
활성 일수당 사용자당 요청 3회
...

이것들은 수정 가능한 계획 가정 (planning assumptions)이며, 보편적인 사용 평균이나 공식 제공업체의 견적은 아닙니다.

첫 번째 단계는 요청 볼륨 (request volume)을 추정하는 것입니다:

월간 요청 수 =
100 명의 사용자
× 20 활성 일수
...

입력 토큰 비용은 다음과 같습니다:

6,000 회의 요청
× 2,000 입력 토큰
÷ 1,000,000
...

출력 토큰 비용은 다음과 같습니다:

6,000 회의 요청
× 500 출력 토큰
÷ 1,000,000
...

이를 통해 나열된 기본 비용은 다음과 같습니다:

$36 + $45 = $81

수정 가능한 3%의 재시도 (retry) 가정을 추가하면:

$81 × 1.03 = $83.43

여기에 추가로 15%의 계획 버퍼 (planning buffer)를 더하면:

$83.43 × 1.15 = $95.94

이 예시에서는 차이가 상대적으로 작지만, 동일한 승수 (multipliers)가 더 높은 볼륨에서는 더 중요해집니다.

중요한 점은 $95.94가 공식 가격 견적이 아니라는 것입니다. 이것은 다음을 기반으로 도출된 계획 결과입니다:

• 사용자가 입력한 단가 (User-entered unit prices)
• 특정 워크로드 (A specific workload)
• 추정된 재시도율 (An estimated retry rate)
• 추정된 예산 버퍼 (An estimated budget buffer)

해당 카테고리들은 별도로 유지되어야 합니다.

시나리오 2: Claude Code 및 기타 코딩 에이전트 (coding agents)

코딩 에이전트 (coding-agent) 작업은 채팅 메시지 한 개와 동일하지 않습니다.

하나의 완료된 작업에는 다음이 포함될 수 있습니다:

• 프로젝트 지침 읽기 (Reading project instructions)
• 소스 파일 로드 (Loading source files)
• 의존성 검사 (Inspecting dependencies)
• 도구 정의 수신 (Receiving tool definitions)
• 셸 명령 실행 (Running shell commands)
• 명령 출력 처리 (Processing command output)
• 파일 편집 (Editing files)
• 테스트 실행 (Running tests)
• 실패한 작업 재시도 (Retrying failed operations)
• 대화 기록 보존 (Preserving conversation history)

사용자는 다음과 같은 짧은 최종 응답만을 볼 수도 있습니다:

검증 버그를 수정하고 회귀 테스트 (regression test)를 추가했습니다.

하지만, 에이전트는 해당 응답을 생성하기 전에 훨씬 더 많은 양의 컨텍스트 (context)를 처리했을 수 있습니다.

코딩 에이전트 워크플로 (workflows)의 경우, 저는 다음과 같은 비용 단위가 더 유용하다고 생각합니다:

완료된 작업당 비용 (cost per completed task)

다음보다는 말입니다:

사용자 메시지당 비용 (cost per user message)

단순화된 작업 공식은 다음과 같습니다:

작업 비용 (task cost) =
작업당 모델 호출 횟수 (model calls per task)
× 모델 호출당 추정 비용 (estimated cost per model call)
...

각 모델 호출에는 다음이 포함될 수 있습니다:

입력 토큰 (input tokens) =
지침 (instructions)
+ 대화 기록 (conversation history)
...

이것이 최종 답변이 비슷하게 짧은 두 작업이라도 비용이 매우 다를 수 있는 이유입니다.

단일 파일 구성 수정과 저장소 전체 마이그레이션 (repository-wide migration)은 동일한 예상 토큰 예산을 공유해서는 안 됩니다.

도구 사용 (Tool use)은 컨텍스트를 추가합니다

도구 사용이 총 비용을 높이기 위해 별도의 고정 수수료를 필요로 하지는 않습니다.

모델은 다음을 수행해야 할 수도 있습니다:

1. 도구 정의 수신 (Receive the tool definition)
2. 호출할 도구 결정 (Decide which tool to call)
3. 도구 결과 수신 (Receive the tool result)
4. 해당 결과 읽기 및 추론 (Read and reason about that result)
5. 다음 동작 생성 (Generate the next action)

대규모 명령 출력과 대규모 파일 읽기는 이후 입력 컨텍스트 (input context)의 일부가 될 수 있습니다.

더 자세한 분석은 Claude Code Token Cost Guide를 참조하세요.

시나리오 3: 이미지 생성 (Image generation)

이미지 생성은 다른 비용 모델이 필요합니다.

제공업체와 모델에 따라 과금 단위는 다음과 같을 수 있습니다:

• 생성된 이미지당 (Per generated image)
• 해상도 또는 품질 티어당 (Per resolution or quality tier)
• 메가픽셀당 (Per megapixel)
• 입력 및 출력 이미지 토큰 (Input and output image tokens)
• 크레딧 (Credits)
• 여러 단위의 조합 (A combination of several units)

승인된 이미지 한 장의 비용은 제출된 API 작업(API job) 한 건의 비용과 다릅니다.

어떤 제품이 한 달에 1,000장의 승인된 이미지를 필요로 한다고 가정해 봅시다.

사용자가 매번 첫 번째 결과물을 승인한다면, 애플리케이션은 약 1,000건의 생성 작업(generation jobs)을 제출합니다.

하지만 승인된 이미지 한 장을 얻기 위해 평균 2.4회의 시도가 필요하다면 다음과 같습니다:

승인된 이미지 1,000장
× 2.4회 시도

...

제출된 생성 건당 $0.04라는 예시 가격을 적용하면:

2,400 × $0.04 = $96

승인된 이미지당 실제 비용은 다음과 같습니다:

$96 ÷ 1,000 = $0.096

이는 명시된 1회 생성 가격의 두 배가 넘는 금액입니다.

이것이 모든 제공업체가 모든 실패한 요청에 대해 비용을 청구한다는 의미는 아닙니다. 실패한 작업(failed-job)에 대한 과금은 제공업체, 실패 유형 및 처리 단계에 따라 다릅니다.

유용한 구분 기준은 다음과 같습니다:

• 제출된 작업 (Submitted jobs)
• 기술적으로 성공한 작업 (Technically successful jobs)
• 승인된 사용자 출력물 (Accepted user outputs)
• 과금된 작업 (Billed jobs)

이 수치들은 요청 ID(request IDs) 및 제공업체의 과금 대시보드(billing dashboard)와 대조하여 확인해야 합니다.

Image Generation API Cost Guide에서 다양한 과금 단위에 대해 더 자세히 설명하고 있습니다.

OpenRouter 크레딧 및 API 키 제어

마켓플레이스나 게이트웨이는 비용 관리의 또 다른 계층을 도입합니다.

OpenRouter를 사용할 때는 다음 사항들을 구분하는 것이 유용합니다:

• 계정 크레딧 (Account credits)
• API 키 제한 (API-key limits)
• 모델 및 제공업체 가격 (Model and provider pricing)
• 무료 모델 속도 제한 (Free-model rate limits)
• BYOK 사용량 (BYOK usage)
• 권한 오류 (Permission errors)
• 크레딧 부족 오류 (Insufficient-credit errors)

이 개념들은 서로 연관되어 있지만, 서로 대체 가능한 것은 아닙니다.

예를 들어, 계정에 여전히 크레딧이 남아 있더라도 특정 키에 지출 한도(spending limit)가 설정되어 있을 수 있습니다. 또한 잔액 부족이 아니라 권한 또는 정책 제한으로 인해 요청이 실패할 수도 있습니다.

OpenRouter는 현재 구매 후 1년이 경과한 미사용 크레딧을 만료시킬 권리를 보유하고 있습니다. HTTP 402 오류는 일반적으로 크레딧 부족을 나타내며, 403 오류는 일반적으로 권한, 가드레일 (guardrail) 또는 모더레이션 (moderation) 제한을 의미합니다.

저는 운영 점검 사항을 OpenRouter Credits에 별도로 기록해 두었습니다.

내가 기록할 수치들

텍스트 API 요청의 경우, 최소한 다음 항목들을 기록하겠습니다:

request_id
provider
model
...

더 유용한 프로덕션 (production) 기록을 위해 다음 항목들을 추가하겠습니다:

cached_input_tokens
retry_count
latency
...

미디어 작업의 경우, 다음 항목들도 함께 기록하겠습니다:

job_id
duration_or_resolution
submitted_at
...

요청 레벨 (request-level)의 기록이 없다면, 다음과 같은 기본적인 과금 관련 질문에 답하기 어렵습니다:

• 총 요청량이 증가했는가?
• 프로덕션 모델이 변경되었는가?
• 평균 출력 (output) 길이가 길어졌는가?
• 재시도 (retry) 양이 증가했는가?
• 사용자들이 이미지를 더 많이 재생성했는가?
• 타임아웃 (timeout)으로 인해 중복 작업이 생성되었는가?
• 제공업체(provider)가 보고한 비용이 로컬 추정치와 다른가?

더 나은 예산 모델

저는 이제 비용 계획을 네 가지 계층으로 분리합니다.

1. 나열된 단위 비용 (Listed unit cost)

이는 제공업체의 가격 문서에서 가져옵니다.

예시:

1M 입력 토큰당 가격
1M 출력 토큰당 가격
생성된 이미지당 가격
...

2. 워크로드 가정 (Workload assumptions)

이는 제품에 따라 구체적으로 달라집니다:

활성 사용자 수 (active users)
사용자당 요청 수
평균 입력 토큰 수
...

3. 운영 승수 (Operational multipliers)

다음 항목들이 포함될 수 있습니다:

재시도 (retries)
중복 제출 (duplicate submissions)
캐시 쓰기 (cache writes)
...

이 항목들은 보편적인 사실이라기보다 수정 가능한 가정(assumptions)이어야 합니다.

4. 계획 버퍼 (Planning buffer)

사용량이 불확실할 때 예산 버퍼가 도움이 될 수 있지만, 근본적인 추정치를 가려서는 안 됩니다.

계산기는 다음 두 가지를 모두 보여주어야 합니다:

기본 API 비용
계획된 운영 예산

계산기가 알려줄 수 없는 것

비용 계산기에는 중요한 한계가 있습니다.

계산기는 다음을 결정할 수 없습니다:

• 귀하의 제품에 어떤 모델이 최상의 출력 품질 (output quality)을 제공하는지
• 모든 실패한 작업 (failed job)에 대해 비용이 청구될지 여부
• 향후 모델 가격
• 지역별 세금
• 환전 비용
• 제공업체별 협상된 할인 (negotiated discounts)
• 실제 데이터가 존재하기 전의 실제 재시도 동작 (retry behavior)

가격 또한 출력 품질 (output quality)의 척도는 아닙니다.

계산기는 계획 도구일 뿐, 제공업체의 사용 기록 (usage records)이나 결제 대시보드 (billing dashboards)를 대체할 수 없습니다.

벤치마크 및 계산기

저는 전체 모델을 2026 AI API Cost Benchmark에 반영했습니다.

다음 항목들이 포함되어 있습니다:

• 대화형 LLM 애플리케이션 계산기
• 코딩 에이전트 (coding-agent) 작업 계산기
• 이미지 생성 (image-generation) 워크로드 추정치
• 초당 및 작업당 비디오 추정치
• 프로토타입, 프로덕션, 에이전트 중심 프리셋 (presets)
• 재시도 (retry) 및 계획 버퍼 (planning-buffer) 제어
• 공식 출처 링크
• 가격 스냅샷 날짜
• 다운로드 가능한 CSV 데이터셋
• 방법론 및 한계점

현재 가격 스냅샷은 2026년 6월 17일에 검토되었습니다.

계산기는 무료로 사용할 수 있으며 API 키가 필요하지 않습니다. 가격은 빈번하게 변동되므로, 프로덕션 워크로드 (production workload)를 시작하기 전에 현재 제공업체의 문서를 확인하고 추정치를 실제 소규모 테스트와 비교해 보시기 바랍니다.

귀하의 원래 추정치와 실제 AI 청구서 사이에서 가장 큰 차이를 만든 원인은 무엇이었습니까: 출력 토큰 (output tokens), 반복되는 에이전트 컨텍스트 (agent context), 재시도 (retries), 아니면 미디어 재생성 (media regeneration)이었습니까?