본문으로 건너뛰기
Kreath Archive
TechProjectsBooksAbout
TechProjectsBooksAbout

내비게이션

  • Tech
  • Projects
  • Books
  • About
  • Tags

카테고리

  • AI / ML
  • 웹 개발
  • 프로그래밍
  • 개발 도구

연결

  • GitHub
  • Email
  • RSS
© 2026 Kreath Archive. All rights reserved.Built with Next.js + MDX
홈TechProjectsBooksAbout
//
  1. 홈
  2. 테크
  3. 6장: 비용 관리와 최적화 아키텍처
2026년 3월 5일·아키텍처·

6장: 비용 관리와 최적화 아키텍처

LLM API 비용을 제어하는 아키텍처 전략 — 토큰 예산 시스템, 모델 라우팅, 캐싱 경제학, 비용 모니터링, 그리고 비용 효율적 시스템 설계를 다룹니다.

16분422자7개 섹션
architecturellminfrastructure
공유
ai-architecture6 / 10
12345678910
이전5장: AI 시스템의 캐싱 전략다음7장: 장애 대응과 회복 탄력성

LLM 비용의 구조를 이해하기

AI 시스템 운영에서 LLM API 비용은 전통적인 서버 비용과 근본적으로 다른 특성을 가집니다. 일반적인 API 호출이 고정 비용에 가깝다면, LLM API는 처리하는 토큰 수에 비례하여 비용이 증가합니다. 더 까다로운 점은 입력 토큰과 출력 토큰의 단가가 다르고, 모델마다 가격 차이가 극적이라는 것입니다.

모델 등급입력 (1M 토큰)출력 (1M 토큰)상대 비용
Haiku 급 (경량)$0.25$1.251x
Sonnet 급 (중간)$3.00$15.0012x
Opus 급 (최상위)$15.00$75.0060x

이 가격 차이가 의미하는 바는 명확합니다. 모든 요청을 최상위 모델로 처리하면 비용이 60배까지 치솟을 수 있다는 것입니다. 따라서 비용 최적화 아키텍처의 핵심은 "적절한 모델을 적절한 요청에 매칭하는 것"입니다.

Info

토큰 비용은 빠르게 변화합니다. 2024년 초 대비 2025년 말 기준으로 동일 성능 대비 비용이 약 80% 이상 하락했습니다. 그러나 사용량 증가 속도가 비용 하락 속도를 초과하는 경우가 많으므로, 비용 제어 아키텍처는 여전히 필수적입니다.

토큰 예산 시스템

첫 번째 방어선은 토큰 예산 시스템입니다. 사용자별, 요청별, 팀별로 토큰 소비 한도를 설정하여 예상치 못한 비용 폭증을 방지합니다.

예산 계층 설계

토큰 예산은 세 가지 계층으로 나누어 관리합니다.

요청 수준(Request-level)은 단일 API 호출에서 소비할 수 있는 최대 토큰 수를 제한합니다. 프롬프트가 비정상적으로 길어지거나 출력이 무한히 생성되는 상황을 방지합니다.

사용자 수준(User-level)은 개별 사용자가 일정 기간(시간/일/월) 동안 소비할 수 있는 총 토큰 수를 제한합니다. 특정 사용자의 과도한 사용이 전체 시스템 예산을 잠식하는 것을 막습니다.

시스템 수준(System-level)은 전체 서비스의 월간 또는 일간 토큰 예산을 설정합니다. 최종 안전망으로서, 이 한도에 도달하면 요청을 거부하거나 하위 모델로 강제 라우팅합니다.

src/middleware/token-budget.ts
typescript
interface TokenBudget {
  maxInputTokens: number;
  maxOutputTokens: number;
  periodMs: number;
  currentUsage: number;
}
 
interface BudgetConfig {
  request: TokenBudget;
  user: TokenBudget;
  system: TokenBudget;
}
 
class TokenBudgetManager {
  private store: Map<string, { usage: number; resetAt: number }> = new Map();
 
  async checkBudget(
    userId: string,
    estimatedTokens: number,
    config: BudgetConfig
  ): Promise<{ allowed: boolean; remainingBudget: number; suggestedModel?: string }> {
    // 요청 수준 검사
    if (estimatedTokens > config.request.maxInputTokens) {
      return {
        allowed: false,
        remainingBudget: 0,
        suggestedModel: undefined,
      };
    }
 
    // 사용자 수준 검사
    const userKey = `user:${userId}`;
    const userUsage = this.getUsage(userKey, config.user.periodMs);
 
    if (userUsage + estimatedTokens > config.user.maxInputTokens) {
      // 예산 초과 임박 시 경량 모델로 라우팅 제안
      const remaining = config.user.maxInputTokens - userUsage;
      return {
        allowed: remaining > 0,
        remainingBudget: remaining,
        suggestedModel: "haiku",
      };
    }
 
    // 시스템 수준 검사
    const systemUsage = this.getUsage("system:global", config.system.periodMs);
    if (systemUsage + estimatedTokens > config.system.maxInputTokens) {
      return {
        allowed: false,
        remainingBudget: 0,
        suggestedModel: undefined,
      };
    }
 
    return {
      allowed: true,
      remainingBudget: config.user.maxInputTokens - userUsage - estimatedTokens,
    };
  }
 
  recordUsage(userId: string, actualTokens: number): void {
    const userKey = `user:${userId}`;
    this.incrementUsage(userKey, actualTokens);
    this.incrementUsage("system:global", actualTokens);
  }
 
  private getUsage(key: string, periodMs: number): number {
    const entry = this.store.get(key);
    if (!entry || Date.now() > entry.resetAt) {
      return 0;
    }
    return entry.usage;
  }
 
  private incrementUsage(key: string, tokens: number): void {
    const entry = this.store.get(key);
    if (entry && Date.now() < entry.resetAt) {
      entry.usage += tokens;
    } else {
      this.store.set(key, {
        usage: tokens,
        resetAt: Date.now() + 86400000, // 24시간
      });
    }
  }
}

모델 라우팅 전략

모든 요청이 동일한 복잡도를 가지지 않습니다. 단순한 분류 작업에 최상위 모델을 사용하는 것은 낭비입니다. 모델 라우터(Model Router)는 요청의 특성을 분석하여 최적의 모델을 선택합니다.

라우팅 기준

모델을 선택할 때 고려해야 할 기준은 다음과 같습니다.

  • 작업 복잡도: 단순 분류, 요약, 추출은 경량 모델로 충분합니다
  • 품질 요구 수준: 사용자에게 직접 노출되는 응답은 높은 품질이 필요합니다
  • 지연 시간 제약: 실시간 응답이 필요한 경우 경량 모델이 유리합니다
  • 입력 길이: 긴 컨텍스트가 필요한 작업은 비용이 급격히 증가합니다
src/services/model-router.ts
typescript
type ModelTier = "haiku" | "sonnet" | "opus";
 
interface RoutingDecision {
  model: ModelTier;
  reason: string;
  estimatedCostMultiplier: number;
}
 
interface RequestContext {
  taskType: string;
  inputLength: number;
  userTier: "free" | "pro" | "enterprise";
  qualityRequired: "low" | "medium" | "high";
  latencyBudgetMs: number;
}
 
function routeToModel(context: RequestContext): RoutingDecision {
  // 규칙 1: 짧은 입력 + 단순 작업 -> 경량 모델
  if (context.inputLength < 500 && isSimpleTask(context.taskType)) {
    return {
      model: "haiku",
      reason: "단순 작업, 경량 모델로 충분",
      estimatedCostMultiplier: 1,
    };
  }
 
  // 규칙 2: 높은 품질 요구 + 엔터프라이즈 -> 최상위 모델
  if (context.qualityRequired === "high" && context.userTier === "enterprise") {
    return {
      model: "opus",
      reason: "높은 품질 요구, 엔터프라이즈 등급",
      estimatedCostMultiplier: 60,
    };
  }
 
  // 규칙 3: 실시간 응답 필요 -> 경량 또는 중간 모델
  if (context.latencyBudgetMs < 2000) {
    return {
      model: "haiku",
      reason: "실시간 지연 시간 제약",
      estimatedCostMultiplier: 1,
    };
  }
 
  // 기본값: 중간 모델
  return {
    model: "sonnet",
    reason: "범용 작업, 중간 등급 모델",
    estimatedCostMultiplier: 12,
  };
}
 
function isSimpleTask(taskType: string): boolean {
  const simpleTasks = [
    "classification",
    "extraction",
    "sentiment",
    "translation",
    "summarization-short",
  ];
  return simpleTasks.includes(taskType);
}
Tip

실전에서는 규칙 기반 라우팅으로 시작한 뒤, 로그 데이터를 축적하여 점진적으로 ML 기반 라우팅으로 전환하는 접근이 효과적입니다. 초기에 복잡한 라우팅 모델을 구축하는 것보다 단순한 규칙으로 빠르게 비용을 절감하는 것이 중요합니다.

프롬프트 최적화와 비용

프롬프트의 길이는 비용에 직접적인 영향을 미칩니다. 불필요하게 긴 시스템 프롬프트, 반복적인 지시사항, 과도한 예시는 매 요청마다 비용을 증가시킵니다.

프롬프트 압축 전략:

  1. 시스템 프롬프트 최소화: 핵심 지시사항만 포함하고, 상세한 가이드라인은 필요할 때만 동적으로 주입합니다
  2. 구조화된 출력 지정: JSON 스키마를 명시하면 모델이 불필요한 설명 없이 구조화된 응답만 생성하므로 출력 토큰이 줄어듭니다
  3. 대화 이력 관리: 전체 대화 이력 대신 요약본을 사용하여 컨텍스트 토큰을 절감합니다
  4. few-shot 예시 최적화: 최소한의 예시로 최대 효과를 얻도록 예시를 선별합니다

캐싱의 경제학

5장에서 다룬 시맨틱 캐싱은 비용 관점에서도 강력한 도구입니다. 캐시 적중률(hit rate)에 따른 비용 절감 효과를 분석해 보겠습니다.

캐시 적중률일간 요청 수LLM 호출 수예상 비용 절감
0% (캐싱 없음)100,000100,0000%
30%100,00070,000약 28%
50%100,00050,000약 47%
70%100,00030,000약 67%

캐시 적중률과 비용 절감이 정비례하지 않는 이유는 캐시 인프라 자체의 운영 비용(Redis, 벡터 DB)이 존재하기 때문입니다. 그러나 일반적으로 30% 이상의 적중률만 달성해도 캐싱 인프라 비용 대비 충분한 ROI를 확보할 수 있습니다.

Warning

캐시 적중률이 높다고 항상 좋은 것은 아닙니다. 지나치게 넓은 유사도 임계값은 부정확한 응답을 반환할 수 있으며, 이는 사용자 경험을 해치고 결국 비용보다 큰 손실을 초래합니다. 적중률과 응답 정확도 사이의 균형을 지속적으로 모니터링해야 합니다.

비용 모니터링 대시보드

비용을 제어하려면 먼저 비용을 가시화해야 합니다. AI 시스템에 특화된 비용 대시보드가 추적해야 할 핵심 메트릭은 다음과 같습니다.

필수 메트릭

  • 요청당 비용(Cost per Request): 평균, P50, P95, P99 분위수로 분류합니다
  • 모델별 비용 분포: 어떤 모델이 전체 비용에서 얼마나 차지하는지 시각화합니다
  • 사용자/팀별 비용: 비용 주체를 식별하여 예산 책임을 부여합니다
  • 시간대별 비용 추이: 비용 급증 패턴을 사전에 감지합니다
  • 캐시 절감 효과: 캐싱으로 절약된 비용을 실시간으로 추적합니다

알림 설정 기준

단순 임계값 기반 알림 외에, 비정상적 비용 패턴을 감지하는 이상 탐지도 중요합니다. 예를 들어, 평소 대비 200% 이상의 비용이 발생하거나, 특정 엔드포인트의 평균 토큰 수가 갑자기 급증하는 경우를 경고해야 합니다.

src/monitoring/cost-alert.ts
typescript
interface CostAlert {
  type: "threshold" | "anomaly" | "budget-warning";
  severity: "info" | "warning" | "critical";
  message: string;
  currentCost: number;
  threshold: number;
}
 
function evaluateCostAlerts(
  dailyCost: number,
  monthlyBudget: number,
  historicalAvgDaily: number
): CostAlert[] {
  const alerts: CostAlert[] = [];
  const dayOfMonth = new Date().getDate();
  const projectedMonthlyCost = dailyCost * 30;
 
  // 일간 비용이 이력 평균의 2배 초과
  if (dailyCost > historicalAvgDaily * 2) {
    alerts.push({
      type: "anomaly",
      severity: "warning",
      message: `일간 비용이 평균 대비 ${Math.round((dailyCost / historicalAvgDaily) * 100)}% 수준입니다`,
      currentCost: dailyCost,
      threshold: historicalAvgDaily * 2,
    });
  }
 
  // 월간 예산의 80% 도달 경고
  const monthlyUsed = dailyCost * dayOfMonth;
  if (monthlyUsed > monthlyBudget * 0.8) {
    alerts.push({
      type: "budget-warning",
      severity: "critical",
      message: `월간 예산의 ${Math.round((monthlyUsed / monthlyBudget) * 100)}%를 사용했습니다`,
      currentCost: monthlyUsed,
      threshold: monthlyBudget,
    });
  }
 
  // 추정 월간 비용이 예산 초과 전망
  if (projectedMonthlyCost > monthlyBudget) {
    alerts.push({
      type: "threshold",
      severity: "warning",
      message: `현재 추세로 월 예산을 ${Math.round(((projectedMonthlyCost - monthlyBudget) / monthlyBudget) * 100)}% 초과할 것으로 예상됩니다`,
      currentCost: projectedMonthlyCost,
      threshold: monthlyBudget,
    });
  }
 
  return alerts;
}

비용 효율적 시스템 설계 원칙

지금까지 다룬 내용을 종합하면, 비용 효율적인 AI 시스템 설계의 핵심 원칙은 다음과 같습니다.

  1. 계층화: 모든 요청을 동일하게 처리하지 않습니다. 요청의 복잡도와 중요도에 따라 모델, 캐싱, 예산을 계층적으로 적용합니다.
  2. 가시성: 측정하지 않으면 제어할 수 없습니다. 비용 메트릭을 실시간으로 수집하고 시각화합니다.
  3. 점진적 최적화: 모든 최적화를 한 번에 적용하지 않습니다. 가장 비용 영향이 큰 영역부터 순차적으로 개선합니다.
  4. 안전 장치: 토큰 예산과 비용 알림은 선택이 아닌 필수입니다. 한 번의 버그로 월간 예산이 소진될 수 있습니다.

이번 장에서는 LLM API 비용의 구조를 이해하고, 토큰 예산, 모델 라우팅, 프롬프트 최적화, 캐싱, 모니터링을 활용한 비용 제어 아키텍처를 설계했습니다. 다음 장에서는 AI 시스템에서 불가피하게 발생하는 장애에 대응하는 회복 탄력성 패턴을 다루겠습니다.

이 글이 도움이 되셨나요?

관련 주제 더 보기

#architecture#llm#infrastructure

관련 글

아키텍처

7장: 장애 대응과 회복 탄력성

AI 시스템의 장애 시나리오와 회복 탄력성 패턴 — 서킷 브레이커, 폴백, 재시도, 타임아웃, 모델 장애 조치, 그리고 그레이스풀 디그레이데이션을 다룹니다.

2026년 3월 7일·16분
아키텍처

5장: AI 시스템의 캐싱 전략

LLM 추론 비용과 지연을 줄이는 다층 캐싱 전략 — 의미론적 캐시, 프롬프트 캐시, KV 캐시, 임베딩 캐시, 그리고 캐시 무효화 전략을 다룹니다.

2026년 3월 3일·11분
아키텍처

8장: AI 시스템의 관측 가능성

LLM 기반 시스템의 관측 가능성 설계 — 트레이싱, 메트릭, 로깅, 프롬프트 버전 관리, 품질 모니터링, 그리고 AI 특화 대시보드 구축을 다룹니다.

2026년 3월 9일·16분
이전 글5장: AI 시스템의 캐싱 전략
다음 글7장: 장애 대응과 회복 탄력성

댓글

목차

약 16분 남음
  • LLM 비용의 구조를 이해하기
  • 토큰 예산 시스템
    • 예산 계층 설계
  • 모델 라우팅 전략
    • 라우팅 기준
  • 프롬프트 최적화와 비용
  • 캐싱의 경제학
  • 비용 모니터링 대시보드
    • 필수 메트릭
    • 알림 설정 기준
  • 비용 효율적 시스템 설계 원칙