배포, 운영, 관측성, 비용 최적화

PoC가 끝난 뒤 진짜 일이 시작된다

Claude 기반 기능은 처음에는 놀라울 정도로 빨리 만들어진다. 문서 요약 봇은 하루 만에 움직이고, 고객지원 초안 생성기는 이틀이면 데모가 가능하며, 개발팀 내부 코드 리뷰 도우미는 주말 사이에도 그럴듯한 결과를 낸다. 그래서 많은 팀이 착각한다. "이 정도면 다음 주에 프로덕션으로 올려도 되겠는데?"

하지만 PoC와 실제 서비스 사이에는 생각보다 넓은 강이 있다. PoC에서는 한 명의 개발자가 직접 프롬프트를 고치고, 실패한 응답을 눈으로 확인하고, 비용을 대략 감으로 판단한다. 실제 서비스에서는 다르다. 수천 명의 사용자가 동시에 요청하고, 한 사용자의 긴 대화가 수십 번의 모델 호출로 불어나며, 도구 실행 실패가 재시도를 만들고, 재시도가 다시 rate limit을 두드린다. 어느 날 아침 재무팀이 "어제 하루 API 비용이 평소의 세 배인데요?"라고 묻기 전까지는 아무도 정확한 원인을 모를 수 있다.

이 장은 바로 그 강을 건너는 방법을 다룬다. Claude를 "잘 호출하는 법"이 아니라 "계속 안정적으로 운영하는 법"이다. 앞 장들에서 우리는 프롬프트, 도구 사용, RAG, 평가, 안전성, 보안과 컴플라이언스를 다루었다. 이제 그 모든 요소를 서비스 운영의 언어로 묶어야 한다. 운영의 언어란 버전, 환경, 로그, 지표, 한도, 예산, 장애 대응, 롤백이다.

Claude 운영에서 가장 먼저 버려야 할 생각은 "모델이 똑똑하니 알아서 잘하겠지"라는 기대다. 모델은 똑똑하지만, 서비스는 모델 하나로 이루어지지 않는다. 사용자의 입력, 시스템 프롬프트, 검색 결과, 도구 스키마, 외부 API, 캐시, 큐, 재시도 정책, 권한, 로그 저장소, 비용 대시보드가 함께 움직인다. 이 중 하나만 느슨해도 품질, 지연 시간, 비용, 보안 중 어딘가가 무너진다.

운영의 목표는 완벽한 응답을 매번 보장하는 것이 아니다. 실제 목표는 더 현실적이다. 실패를 빨리 발견하고, 실패 범위를 작게 유지하고, 비용이 급증하기 전에 알아차리고, 성능이 흔들릴 때 사용자 경험을 가능한 한 부드럽게 낮추는 것이다. 좋은 Claude 운영은 화려한 마법보다 잘 정리된 계기판에 가깝다.

환경을 나누지 않으면 프롬프트도 배포 사고가 된다

전통적인 소프트웨어에서는 개발, 스테이징, 프로덕션 환경을 나누는 일이 기본이다. 그런데 AI 기능에서는 이 기본이 자주 무너진다. 프롬프트가 코드 바깥의 문서나 운영 콘솔에 흩어져 있고, 모델명이 환경 변수에 임시로 들어가 있으며, 검색 인덱스나 도구 스키마가 누가 언제 바꾸었는지 남지 않는다. 그러다 어느 날 "어제부터 답변 톤이 달라졌다"는 신고가 들어오면, 팀은 코드 diff가 아니라 슬랙 대화와 개인 노트를 뒤지게 된다.

Claude 기반 시스템에서도 환경 분리는 선택이 아니라 필수다. 최소한 개발, 스테이징, 프로덕션 세 환경은 분리해야 한다. 개발 환경에서는 프롬프트와 도구를 자유롭게 실험한다. 스테이징 환경에서는 프로덕션과 같은 데이터 구조, 같은 모델 계열, 같은 rate limit 가정으로 회귀 테스트를 수행한다. 프로덕션 환경에서는 승인된 버전만 배포하고, 실험은 feature flag나 제한된 트래픽으로 격리한다.

여기서 중요한 점은 "코드만" 환경별로 나누면 부족하다는 것이다. Claude 시스템에서 배포 단위는 코드보다 넓다. 시스템 프롬프트, few-shot 예시, 도구 정의, RAG 검색 설정, chunking 규칙, 재정렬 모델, safety policy, 출력 JSON 스키마, 모델명, temperature, max_tokens, extended thinking 설정, prompt caching 경계까지 모두 배포 단위에 포함된다.

실무에서는 하나의 Claude 기능을 다음과 같은 설정 묶음으로 관리하는 편이 좋다.

이 표에서 알 수 있듯이 프롬프트 변경은 단순한 문구 수정이 아니다. 출력 형식을 바꾸면 파서가 깨질 수 있고, 도구 설명을 바꾸면 모델이 도구를 호출하는 빈도가 달라질 수 있다. 검색 top_k를 늘리면 답변 근거가 풍부해지지만 입력 토큰과 지연 시간이 늘어난다. max_tokens를 높이면 답변이 친절해질 수 있지만 비용과 output token per minute 압박이 커진다.

가장 안전한 방식은 "프롬프트 레지스트리"를 두는 것이다. 거창한 시스템이 아니어도 된다. Git 저장소 안에 prompts/ 디렉터리를 만들고, 각 기능별로 프롬프트와 메타데이터를 함께 둔다. 중요한 것은 사람이 읽을 수 있고, diff를 볼 수 있고, 배포된 버전을 재현할 수 있어야 한다는 점이다.

id: support_reply_draft
version: 2026-05-13.3
owner: cx-platform
model: claude-sonnet-4-6
max_tokens: 1200
temperature: 0.2
prompt_file: prompts/support_reply_draft/system.md
tools:
  - customer_profile_lookup:v2
  - policy_search:v4
retrieval:
  index: support_kb_2026_05
  top_k: 6
  reranker: rerank_v2
output_schema: schemas/support_reply_v3.json
release_stage: staging
approved_by:
  - product_owner
  - security_reviewer
  - legal_reviewer

이런 메타데이터는 귀찮아 보이지만 장애가 났을 때 보험이 된다. "지난주에는 잘 됐는데 오늘 왜 이상하지?"라는 질문에 답하려면, 지난주와 오늘의 모델, 프롬프트, 검색 인덱스, 도구 스키마, 파라미터가 모두 남아 있어야 한다. 9장에서 평가 결과를 재현하려면 모델, 프롬프트, 검색 인덱스, 도구 스키마, 파라미터, 실행 날짜를 함께 남겨야 한다고 했다. 프로덕션 운영에서도 같은 원칙이 적용된다.

배포 파이프라인: AI 기능도 CI/CD를 탄다

Claude 기능의 배포 파이프라인은 일반 애플리케이션 배포와 닮았지만, 한 가지가 더 있다. 코드 테스트뿐 아니라 "응답 품질 테스트"가 들어가야 한다. 단위 테스트가 함수의 반환값을 확인한다면, AI 회귀 테스트는 동일한 입력 집합에 대해 응답이 허용 범위 안에 있는지 확인한다.

배포 파이프라인은 다음 흐름으로 설계할 수 있다.

자동 정적 점검에서는 명백한 사고를 먼저 걸러낸다. 예를 들어 프로덕션 프롬프트에 내부 테스트용 문구가 남아 있는지, 금지된 개인정보 필드가 프롬프트에 직접 들어갔는지, deprecated 모델명이 하드코딩되어 있는지, JSON schema가 깨졌는지 확인한다. 이 단계는 모델 호출 없이도 빠르게 수행할 수 있다.

그다음 오프라인 평가셋을 실행한다. 9장에서 만든 gold set, adversarial set, regression set을 사용한다. 예를 들어 고객지원 답변 생성 기능이라면 "환불 불가 상품에 대해 환불을 약속하지 않는가", "정책 문서를 근거로 답하는가", "개인정보를 불필요하게 노출하지 않는가", "JSON 파싱이 성공하는가"를 본다. 모든 항목을 사람이 읽을 필요는 없다. 일부는 규칙 기반으로 검사하고, 일부는 LLM-as-judge나 사람 검토로 확인한다.

비용·지연 시간 시뮬레이션도 배포 게이트에 포함해야 한다. 프롬프트에 2,000토큰을 추가하는 변경은 품질을 높일 수 있지만, 월 100만 호출 서비스에서는 상당한 비용 증가가 된다. 도구를 하나 더 추가하면 tool schema 토큰이 늘고, 도구 루프가 길어질 수 있다. 따라서 배포 전에는 "품질이 좋아졌는가"와 함께 "얼마나 더 비싸졌는가", "얼마나 느려졌는가"를 함께 보아야 한다.

프로덕션 배포는 가능하면 점진적으로 한다. 처음부터 100% 트래픽을 새 프롬프트로 보내지 말고 1%, 5%, 25%, 50%, 100%처럼 늘린다. 이때 feature flag를 사용하면 특정 고객군, 특정 팀, 특정 지역, 특정 기능에만 새 설정을 적용할 수 있다. AI 기능은 비결정성이 있으므로, 작은 변경도 예상 밖의 사용자 입력에서 크게 드러날 수 있다. 점진 배포는 그 예외를 작게 만나는 방법이다.

롤백도 미리 정해야 한다. "문제가 생기면 이전 버전으로 돌린다"는 말만으로는 부족하다. 어떤 지표가 어느 기준을 넘으면 자동 롤백할 것인지 정해야 한다. 예를 들어 파싱 실패율이 5분 동안 3%를 넘거나, p95 time-to-first-token이 SLA의 두 배를 넘거나, 비용 burn rate가 평소 대비 200%를 넘으면 새 버전을 중단하는 식이다.

관측성의 네 층: 살아 있는 시스템을 보는 법

AI 시스템의 관측성은 단순한 서버 모니터링보다 넓다. 기존 서비스에서는 CPU, 메모리, HTTP 상태 코드, DB 쿼리 시간을 보면 많은 문제가 보였다. Claude 기반 서비스에서는 거기에 토큰, 캐시, 모델 라우팅, 도구 호출, 출력 품질, 사용자 피드백이 더해진다. "서버는 정상인데 답변이 나쁘다"거나 "에러는 없는데 비용이 폭증한다"는 일이 흔하기 때문이다.

좋은 관측성은 네 층으로 나누어 설계한다.

첫째는 API 건강 상태다. 요청 수, 성공률, 오류율, timeout, 429 rate, 5xx rate, time-to-first-token, total latency를 본다. 스트리밍 응답을 쓰는 경우 사용자는 전체 응답 시간보다 첫 토큰이 언제 나오느냐에 더 민감하다. 따라서 TTFT, 즉 요청 후 첫 토큰까지 걸린 시간을 별도로 추적해야 한다.

둘째는 토큰과 비용 회계다. Claude API 응답에는 사용량 정보가 포함되므로, 입력 토큰, 출력 토큰, cache creation input tokens, cache read input tokens를 요청 단위로 저장해야 한다. 이 정보가 없으면 기능별 비용, 사용자별 비용, 테넌트별 비용, 모델별 비용을 나중에 복원할 수 없다. prompt caching이 잘 작동하는지도 이 필드로 확인한다.

셋째는 애플리케이션 품질이다. 모델이 200 OK로 응답했다고 해서 서비스가 성공한 것은 아니다. 구조화 출력이 schema를 만족했는지, tool call이 성공했는지, 검색 근거가 실제 답변에 반영되었는지, 사용자가 thumbs down을 눌렀는지, 상담원이 답변을 얼마나 수정했는지, 사람이 개입한 비율이 얼마인지 봐야 한다.

넷째는 의존성 건강 상태다. Claude 호출 앞뒤에는 보통 벡터 DB, 검색 서버, 파일 저장소, 권한 서버, MCP 서버, 외부 업무 시스템, 큐, 캐시가 있다. 사용자는 "AI가 느리다"고 말하지만 실제 원인은 벡터 검색 2초, 외부 CRM API 4초, 모델 호출 1초일 수 있다. 따라서 trace는 Claude 호출만이 아니라 전체 요청 경로를 이어야 한다.

AWS의 Claude Code 관측성 사례도 비슷한 문제의식에서 출발한다. Claude Code 같은 에이전트형 도구는 한 번의 사용자 요청이 여러 모델 호출, 파일 읽기와 쓰기, 셸 명령, 도구 승인으로 이어질 수 있기 때문에 단순한 API 호출 횟수만으로는 운영 상태를 알 수 없다. 해당 사례는 OpenTelemetry 기반으로 세션, 비용, 도구 실행 결과, 코드 변경량 같은 에이전트 수준의 텔레메트리를 수집하고, 실시간 메트릭과 심층 이벤트 분석을 분리하는 이중 파이프라인을 제안한다.¹

이 관점은 일반 Claude 애플리케이션에도 그대로 적용된다. 실시간 대시보드는 "지금 괜찮은가"에 답하고, 이벤트 로그와 분석 저장소는 "왜 그런 일이 일어났는가"에 답한다. 둘을 하나로 뭉치면 어느 쪽도 만족하기 어렵다.

어떤 로그를 남길 것인가

AI 운영에서 로그는 양날의 칼이다. 너무 적게 남기면 장애를 분석할 수 없고, 너무 많이 남기면 개인정보와 영업비밀 리스크가 커진다. 11장에서 다룬 보안·프라이버시 원칙을 운영 로그에도 적용해야 한다. 원문을 무작정 저장하는 방식은 피하고, 목적에 맞게 최소화·마스킹·분리 저장한다.

요청 단위로 남길 핵심 필드는 다음과 같다.

프롬프트 원문과 응답 원문은 더 조심스럽게 다루어야 한다. 운영 환경에서는 기본적으로 원문 로그를 끄고, 디버깅이나 품질 개선에 필요한 경우에만 샘플링하거나 익명화하여 별도 저장소에 보관하는 편이 안전하다. 특히 고객 입력, 첨부 문서, 도구 결과에는 개인정보와 기밀정보가 섞일 수 있다. 로그 저장 기간, 접근 권한, 삭제 절차는 11장에서 만든 데이터 흐름 지도와 맞아야 한다.

품질 분석을 위해 원문이 꼭 필요한 경우에는 세 가지 장치를 둔다. 첫째, 민감정보 마스킹을 선행한다. 둘째, 원문 로그 접근 권한을 운영자 전체가 아니라 제한된 리뷰 그룹으로 좁힌다. 셋째, 원문과 비용·성능 메트릭을 분리 저장해 대시보드 사용자가 불필요하게 내용을 보지 않도록 한다.

로그 설계에서 흔한 실수는 "나중에 필요할 수도 있으니 다 저장하자"이다. AI 시스템에서는 이 접근이 특히 위험하다. Claude는 사용자가 넣은 긴 문서와 외부 도구 결과를 함께 처리할 수 있으므로, 로그 하나가 계약서, 의료 정보, 고객 상담 기록, 내부 코드 조각을 포함할 수 있다. 운영 가능성과 개인정보 보호는 반대편에 있지 않다. 목적을 정하고 필요한 필드만 남기는 편이 오히려 더 좋은 운영을 만든다.

대시보드는 숫자 모음이 아니라 질문 목록이다

좋은 대시보드는 예쁜 그래프가 아니라 좋은 질문에서 시작한다. Claude 운영 대시보드는 적어도 다섯 질문에 즉시 답해야 한다.

지금 서비스는 정상인가. 현재 요청량, 오류율, 429 비율, p95/p99 지연 시간, 큐 대기 시간이 안정 범위 안에 있는지 보여야 한다.

지금 비용은 정상인가. 시간당 비용 burn rate, 일간 누적 비용, 월 예산 대비 소진율, 모델별 비용 비중이 보여야 한다.

어떤 기능이 비용을 쓰고 있는가. feature, endpoint, tenant, user segment별 토큰과 비용이 나뉘어야 한다.

품질은 유지되고 있는가. JSON 파싱 실패율, tool call 실패율, citation 누락률, 사용자 부정 피드백, human escalation 비율이 보여야 한다.

최근 배포가 영향을 주었는가. prompt_version, model_version, retrieval_index_version 변경 시점과 주요 지표 변화를 함께 볼 수 있어야 한다.

이를 바탕으로 운영 대시보드를 세 장으로 나누면 실용적이다. 첫 번째는 실시간 건강 상태판이다. SRE와 온콜 담당자가 보는 화면으로, 지연 시간, 오류율, queue depth, rate limit headroom, fallback 사용률을 다룬다. 두 번째는 비용과 사용량판이다. 제품 책임자와 FinOps 담당자가 보는 화면으로, 모델별·기능별·팀별 비용, 토큰 추이, 캐시 히트율, batch 전환 가능 물량을 다룬다. 세 번째는 품질판이다. PM, 도메인 전문가, 평가 담당자가 보는 화면으로, 성공 기준별 품질 지표와 사용자 피드백을 다룬다.

다음은 최소 운영 대시보드의 예시다.

여기서 특히 중요한 것은 release marker다. 대시보드에 배포 시점을 표시하지 않으면, 지표 변화가 자연 변동인지 배포 영향인지 알기 어렵다. 프롬프트 v3.2가 배포된 직후 cache hit rate가 떨어졌다면, 시스템 프롬프트 안에 동적 값이 들어갔거나 공백·줄바꿈이 바뀌어 캐시 prefix가 깨졌을 수 있다. 도구 스키마 v5 배포 후 latency가 늘었다면 도구 호출 빈도가 증가했을 수 있다.

대시보드는 경영 보고용과 운영 대응용을 구분해야 한다. 경영진에게는 "이번 달 AI 기능이 고객당 얼마의 비용으로 어떤 성과를 냈는가"가 중요하다. 온콜 담당자에게는 "지금 429가 늘어난 원인이 RPM인지 input TPM인지 output TPM인지"가 중요하다. 같은 데이터를 쓰더라도 화면은 달라야 한다.

Rate limit은 장애가 아니라 설계 조건이다

Anthropic 문서는 한도를 크게 두 종류로 설명한다. 하나는 조직이 API 사용에 지출할 수 있는 월 비용의 상한인 spend limit이고, 다른 하나는 정해진 기간 동안 조직이 만들 수 있는 API 요청량의 상한인 rate limit이다.² 이 둘은 전혀 다르다. spend limit은 비용 안전장치이고, rate limit은 처리량 안전장치다. spend limit에 걸리면 예산 문제이고, rate limit에 걸리면 트래픽·토큰·동시성 설계 문제다.

Claude 운영에서 rate limit을 "가끔 발생하는 예외"로 보면 안 된다. 트래픽이 늘면 언젠가 반드시 만난다. 특히 AI 기능은 요청 수보다 토큰 수가 병목이 되는 경우가 많다. 짧은 분류 작업은 requests per minute이 먼저 찰 수 있고, 긴 문서 요약은 input tokens per minute이 먼저 찰 수 있으며, 장문 생성 기능은 output tokens per minute이 먼저 찰 수 있다. 따라서 "분당 몇 요청을 보낼 수 있는가"만 보면 부족하다.

실무에서 rate limit 대응은 세 단계로 나눈다.

첫째, 사전에 압력을 줄인다. 불필요한 컨텍스트를 줄이고, prompt caching을 적용하고, 단순 작업은 더 가벼운 모델로 라우팅하고, 비실시간 작업은 batch로 보낸다.

둘째, 클라이언트에서 속도를 조절한다. token bucket, concurrency cap, priority queue를 사용해 API로 나가는 요청을 제어한다. 사용자의 클릭이 곧바로 Claude 호출로 이어지는 구조는 트래픽 폭주에 취약하다.

셋째, 429가 발생했을 때 품격 있게 물러난다. retry-after 헤더를 존중하고, exponential backoff와 jitter를 적용하고, 재시도 횟수를 제한하며, 필요하면 fallback 또는 graceful degradation을 수행한다. 무한 재시도는 장애 대응이 아니라 장애 증폭기다.

간단한 Python 재시도 구조는 다음과 같다.

import random
import time
import anthropic

client = anthropic.Anthropic()

RETRYABLE_STATUS = {429, 500, 529}


def call_claude_with_backoff(**kwargs):
    max_retries = 5
    base_delay = 1.0
    max_delay = 60.0

    for attempt in range(max_retries + 1):
        try:
            return client.messages.create(**kwargs)

        except anthropic.RateLimitError as e:
            if attempt == max_retries:
                raise

            retry_after = None
            if getattr(e, "response", None) is not None:
                retry_after = e.response.headers.get("retry-after")

            if retry_after:
                delay = float(retry_after)
            else:
                delay = min(base_delay * (2 ** attempt), max_delay)
                delay = delay + random.uniform(0, delay * 0.2)

            time.sleep(delay)

        except anthropic.APIStatusError as e:
            if e.status_code not in RETRYABLE_STATUS or attempt == max_retries:
                raise

            delay = min(base_delay * (2 ** attempt), max_delay)
            delay = delay + random.uniform(0, delay * 0.2)
            time.sleep(delay)

재시도에서 중요한 것은 "어떤 오류를 재시도하지 않을 것인가"다. 잘못된 요청 형식, 인증 오류, 권한 오류, 명백한 정책 위반은 같은 요청을 반복해도 성공하지 않는다. 반면 429, 일시적 5xx, overload 계열은 제한된 횟수 안에서 backoff 후 재시도할 수 있다. 오류를 구분하지 않는 재시도 코드는 비용과 장애를 동시에 키운다.

큐와 백프레셔: 사용자를 기다리게 할 것인가, 시스템을 무너뜨릴 것인가

실시간 사용자 요청을 모두 즉시 Claude API로 보내면 구조가 단순해 보인다. 하지만 트래픽이 튀는 순간 이 구조는 위험해진다. 사용자가 새로고침을 누르고, 프론트엔드가 중복 요청을 보내고, 백엔드가 각각 재시도하면 작은 지연이 금방 요청 폭풍이 된다.

큐는 이 폭풍을 완충하는 장치다. 모든 AI 요청을 큐에 넣으라는 뜻은 아니다. 사용자가 채팅창에서 기다리는 실시간 응답은 너무 긴 큐를 타면 경험이 나빠진다. 그러나 오래 걸리는 문서 처리, 대량 요약, 코드 리뷰, 리포트 생성, 재평가 작업은 큐에 넣는 편이 안정적이다. 실시간 요청도 내부적으로 짧은 우선순위 큐와 concurrency cap을 둘 수 있다.

큐를 설계할 때는 세 가지 결정을 내려야 한다. 첫째, 우선순위다. 유료 고객의 실시간 질문, 내부 배치 작업, 품질 평가 재실행은 같은 우선순위를 가져서는 안 된다. 둘째, 거절 기준이다. queue depth가 일정 기준을 넘으면 낮은 우선순위 작업은 새로 받지 않거나 나중에 처리하도록 안내해야 한다. 셋째, 만료 시간이다. 30초 안에 필요했던 응답을 10분 뒤에 생성하는 것은 의미가 없을 수 있다.

백프레셔는 시스템이 과부하를 사용자와 상위 시스템에 정직하게 알리는 방식이다. 예를 들어 "현재 문서 분석 요청이 많아 완료까지 약 8분이 걸립니다"라고 안내하거나, 낮은 우선순위의 자동 요약을 잠시 중단하고 핵심 응답만 제공할 수 있다. 백프레셔가 없으면 시스템은 끝까지 정상인 척하다가 한꺼번에 무너진다.

Claude 기능에서 graceful degradation은 여러 형태가 있다. 실시간 챗봇은 긴 답변 대신 짧은 답변을 먼저 제공할 수 있다. 문서 분석기는 전체 문서 분석 대신 핵심 섹션 분석부터 시작할 수 있다. 코드 리뷰 봇은 전체 저장소 맥락 대신 변경 diff와 관련 파일만 볼 수 있다. 고객지원 도우미는 자동 답변 발송 대신 상담원에게 참고 초안만 제공할 수 있다.

좋은 degradation은 사용자에게 거짓말하지 않는다. "AI가 일시적으로 지연되고 있어 핵심 요약만 먼저 제공합니다"라고 말하는 편이, 40초 동안 아무 반응이 없다가 실패하는 것보다 낫다.

Prompt caching: 반복되는 입력을 다시 계산하지 않기

Claude 비용 최적화에서 가장 강력한 도구 중 하나는 prompt caching이다. Anthropic 문서는 prompt caching을 반복적인 작업이나 일관된 요소를 가진 프롬프트에서 특정 prefix를 재사용해 처리 시간과 비용을 줄이는 기능으로 설명하며, Zero Data Retention에도 적격이라고 안내한다.³

개념은 단순하다. 매 요청마다 같은 시스템 프롬프트, 같은 도구 설명, 같은 정책 문서, 같은 긴 참고 문서를 보낸다면, 매번 같은 입력 토큰 비용을 내고 있는 셈이다. prompt caching은 변하지 않는 prefix를 캐시하고, 이후 같은 prefix가 들어오면 훨씬 저렴하게 읽도록 만든다.

운영 관점에서 핵심은 "정확히 같은 prefix"다. 캐시는 대충 비슷한 문장을 알아서 찾아주는 기능이 아니다. 캐시 대상 블록에 현재 시각, 요청 ID, 사용자 이름, A/B 테스트 변형, 임의 공백이 섞이면 cache miss가 발생할 수 있다. 따라서 캐시할 내용은 결정적으로 생성되어야 한다. 정적 내용은 앞에 두고, 동적 내용은 뒤에 둔다.

좋은 구조는 다음과 같다.

[캐시 대상] 전역 시스템 지침
[캐시 대상] 출력 형식과 정책
[캐시 대상] 도구 정의 또는 반복 참고 문서
[비캐시] 사용자별 정보
[비캐시] 현재 질문
[비캐시] 현재 시각, 요청 ID, 검색 결과 중 매번 바뀌는 부분

Python에서는 다음처럼 cache_control을 붙인다.

import anthropic

client = anthropic.Anthropic()

SYSTEM_PROMPT = """
당신은 고객지원 답변 초안을 작성하는 어시스턴트입니다.
반드시 회사 환불 정책, 개인정보 처리 원칙, 상담 톤 가이드를 따릅니다.
출력은 JSON 형식으로 작성합니다.

[여기에 2,000토큰 이상의 안정적인 정책과 예시가 들어간다고 가정]
"""


def draft_reply(ticket_text: str):
    return client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1200,
        system=[
            {
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"},
            }
        ],
        messages=[
            {
                "role": "user",
                "content": f"다음 고객 문의에 대한 답변 초안을 작성하세요.nn{ticket_text}",
            }
        ],
    )

캐싱이 실제로 작동하는지는 응답의 usage 필드를 봐야 한다. cache_creation_input_tokens가 계속 높고 cache_read_input_tokens가 거의 없다면 캐시가 계속 새로 만들어지고 있다는 뜻이다. 반대로 안정된 트래픽에서 cache_read_input_tokens가 커지고 cache_creation_input_tokens가 낮아지면 캐시가 잘 맞고 있는 것이다.

캐싱은 모든 곳에 붙인다고 좋은 것이 아니다. 짧은 프롬프트, 1회성 요청, 매번 완전히 다른 문서를 처리하는 작업에서는 효과가 작다. 캐시 write 비용과 복잡도만 늘 수 있다. 반대로 긴 시스템 프롬프트, 대형 정책 문서, 반복되는 RAG 청크, 도구 정의, 다중 턴 대화의 오래된 prefix에는 효과가 크다.

Prompt caching은 비용뿐 아니라 지연 시간에도 도움이 될 수 있다. 긴 prefix를 매번 새로 처리하지 않으면 첫 토큰까지 걸리는 시간이 줄어들 가능성이 있다. 다만 운영 판단은 추측이 아니라 계측으로 해야 한다. 캐시 적용 전후의 TTFT, total latency, cache hit rate, 비용을 같은 대시보드에서 비교하자.

Batch processing: 지금 당장 필요하지 않은 일은 싸게 처리한다

모든 AI 응답이 실시간일 필요는 없다. 사용자가 채팅창에서 기다리는 답변은 즉시 필요하지만, 야간에 돌아가는 문서 분류, 월간 리포트 초안, 대량 리뷰, 평가셋 회귀 테스트, 데이터 라벨링, 오래된 티켓 요약은 몇 분 또는 몇 시간 뒤에 완료되어도 된다. 이런 작업을 실시간 API와 같은 방식으로 처리하면 비용과 rate limit을 동시에 낭비한다.

Batch processing의 사고방식은 간단하다. "즉시성"을 포기하는 대신 비용과 운영 안정성을 얻는다. 비동기 작업으로 묶어 보내고, 완료되면 결과를 가져와 후처리한다. 대량 작업은 큐와 배치에 태우면 프로덕션 실시간 트래픽과도 분리된다. 실시간 고객 요청이 몰리는 시간에 내부 분석 배치가 같은 rate limit을 소모하는 일도 줄일 수 있다.

배치에 적합한 작업은 대체로 다음 성격을 가진다.

• 사용자가 화면 앞에서 기다리지 않는다.

• 입력 데이터가 여러 건으로 독립적이거나 약하게 연결되어 있다.

• 실패한 일부 항목을 나중에 재처리할 수 있다.

• 결과 검수나 후처리가 파이프라인으로 이어진다.

• 비용 절감이 지연 시간보다 중요하다.

예를 들어 법무팀이 2,000개의 계약 조항을 위험 유형별로 분류하는 작업은 배치에 적합하다. 고객이 문의창에서 "비밀번호를 잊었어요"라고 묻는 상황은 배치에 적합하지 않다. 코드 리뷰도 경우에 따라 나뉜다. PR 생성 직후 10분 안에 리뷰 초안이 나오면 충분한 조직이라면 배치나 준실시간 큐가 가능하다. IDE 안에서 사용자가 다음 줄을 기다리는 기능이라면 실시간이어야 한다.

배치 운영에서 중요한 것은 idempotency, 즉 같은 작업이 두 번 실행되어도 결과가 망가지지 않도록 하는 것이다. 각 요청에 custom_id를 부여하고, 결과 저장 시 이미 처리된 ID인지 확인한다. 일부 항목만 실패했을 때 전체 배치를 다시 돌리지 말고 실패 항목만 재시도한다. 배치 결과도 모델, 프롬프트 버전, 입력 해시, 실행 시간을 함께 저장해야 한다.

배치 작업은 비용 대시보드에서도 따로 분리한다. 실시간 기능의 비용과 배치 기능의 비용을 합쳐서 보면 의사결정이 흐려진다. 실시간 기능은 사용자 경험과 직접 연결되고, 배치 기능은 처리량과 단위 작업 비용이 중요하다. 같은 Claude 비용이라도 KPI가 다르다.

Token counting: 토큰은 AI 운영의 전기 계량기다

토큰을 세지 않는 Claude 운영은 전기 계량기 없이 공장을 돌리는 것과 비슷하다. 월말 청구서를 보고 놀랄 수는 있지만, 어느 설비가 전기를 많이 먹었는지 알 수 없다. Claude 비용과 rate limit은 결국 토큰에서 출발한다. 입력 토큰, 출력 토큰, 캐시 write 토큰, 캐시 read 토큰, 도구 결과 토큰, 대화 기록 토큰을 봐야 한다.

비용 공식은 개념적으로 다음과 같다.

요청 비용 =
  uncached_input_tokens × 입력 단가
+ cache_write_tokens × 캐시 쓰기 단가
+ cache_read_tokens × 캐시 읽기 단가
+ output_tokens × 출력 단가
+ tool 관련 별도 비용 또는 도구 결과 토큰 비용

실제 단가는 모델과 기능, 계약, 플랫폼, 시점에 따라 바뀔 수 있으므로 프로덕션 계산기는 공식 pricing 페이지와 조직의 계약 조건을 기준으로 관리해야 한다.⁴ 중요한 것은 공식 단가를 코드에 흩뿌리지 않는 것이다. 비용 계산 로직은 중앙화하고, 모델별 단가는 설정 테이블로 관리한다. 모델명이 바뀌거나 가격이 조정될 때 한 곳만 수정하면 되게 해야 한다.

간단한 비용 계측 wrapper는 다음과 같은 형태가 될 수 있다.

from dataclasses import dataclass
from typing import Optional
import time
import uuid
import anthropic


@dataclass
class ClaudeCallMetric:
    request_id: str
    feature: str
    model: str
    ttft_ms: float = 0.0
    total_ms: float = 0.0
    input_tokens: int = 0
    output_tokens: int = 0
    cache_write_tokens: int = 0
    cache_read_tokens: int = 0
    error_type: Optional[str] = None


class ClaudeClientWrapper:
    def __init__(self, client: anthropic.Anthropic, metrics_sink):
        self.client = client
        self.metrics_sink = metrics_sink

    def create_message(self, feature: str, **kwargs):
        metric = ClaudeCallMetric(
            request_id=str(uuid.uuid4()),
            feature=feature,
            model=kwargs.get("model", "unknown"),
        )
        start = time.perf_counter()

        try:
            response = self.client.messages.create(**kwargs)
            metric.total_ms = (time.perf_counter() - start) * 1000
            metric.ttft_ms = metric.total_ms  # 비스트리밍 호출에서는 근사값

            usage = response.usage
            metric.input_tokens = getattr(usage, "input_tokens", 0) or 0
            metric.output_tokens = getattr(usage, "output_tokens", 0) or 0
            metric.cache_write_tokens = getattr(
                usage, "cache_creation_input_tokens", 0
            ) or 0
            metric.cache_read_tokens = getattr(
                usage, "cache_read_input_tokens", 0
            ) or 0

            return response

        except anthropic.RateLimitError:
            metric.error_type = "rate_limit"
            raise
        except anthropic.APIStatusError as e:
            metric.error_type = f"api_status_{e.status_code}"
            raise
        except Exception as e:
            metric.error_type = e.__class__.__name__
            raise
        finally:
            self.metrics_sink.record(metric)

이 wrapper의 목적은 예쁜 추상화가 아니다. 모든 Claude 호출에서 같은 방식으로 사용량과 오류를 기록하게 만드는 것이다. 팀마다 호출 코드를 제각각 쓰면 비용 누수가 생긴다. 어떤 기능은 usage를 저장하고, 어떤 기능은 저장하지 않으면 월말에 "기타 비용"이라는 검은 구멍이 생긴다.

토큰 계측에서 특히 조심해야 할 부분은 대화 기록과 도구 루프다. 10턴 대화의 열 번째 요청은 열 번째 메시지만 보내는 것이 아니라 앞선 대화 요약이나 기록을 함께 보낼 수 있다. 도구 사용 에이전트는 첫 호출, tool_use, tool_result, 후속 호출을 반복한다. 겉으로는 사용자 요청 하나지만 내부적으로는 여러 Claude 호출이 발생한다. 비용은 사용자 요청 수가 아니라 내부 호출과 토큰에 비례한다.

모델 라우팅: 모든 일에 가장 큰 모델을 쓰지 않는다

모델 선택은 비용 최적화이면서 품질 설계다. 단순 분류, 태깅, 짧은 재작성, 형식 변환에는 가장 강한 모델이 필요하지 않을 수 있다. 반대로 복잡한 법률 검토, 다단계 코드 디버깅, 고위험 의사결정 보조에는 더 강한 모델이 필요할 수 있다. 운영 관점에서 좋은 시스템은 요청마다 적절한 모델을 선택한다.

모델 라우팅은 세 단계로 시작할 수 있다. 첫째, 기능별 기본 모델을 정한다. 고객지원 FAQ는 Haiku 또는 Sonnet, 복잡한 분석은 Sonnet 또는 Opus처럼 기본값을 둔다. 둘째, 요청 복잡도에 따라 승격한다. 입력이 길거나, 사용자가 고위험 작업을 요청하거나, 첫 응답의 confidence가 낮거나, 검증 규칙을 통과하지 못하면 더 강한 모델로 재시도한다. 셋째, 비용과 품질을 비교해 라우팅 규칙을 주기적으로 조정한다.

간단한 라우팅 표는 다음과 같다.

주의할 점은 모델 라우팅이 "무조건 싼 모델을 먼저 쓰는 전략"이 아니라는 것이다. 싼 모델이 자주 실패해 재시도와 사람 수정이 늘어나면 총비용은 오히려 증가할 수 있다. 이때 총비용은 API 비용만이 아니라 지연 시간, 사용자 이탈, 상담원 수정 시간, 품질 리스크를 포함한다. 따라서 비교 기준은 token당 비용이 아니라 성공한 작업당 비용이어야 한다.

예를 들어 고객지원 답변 초안에서 Haiku가 호출당 비용은 낮지만 상담원이 평균 3분 더 수정해야 한다면, Sonnet이 더 저렴한 선택일 수 있다. 반대로 대량 태깅 작업에서 Haiku의 오류율이 허용 범위 안이고 downstream 검증이 있다면, Sonnet을 쓰는 것은 낭비일 수 있다.

출력 길이와 thinking effort를 예산 안에 넣기

비용 최적화에서 입력 토큰만 보는 팀이 많다. 하지만 많은 모델에서 출력 토큰은 입력 토큰보다 비싸다. 장문 보고서, 코드 생성, 상세 추론, 긴 JSON 배열 생성은 출력 비용이 빠르게 커진다. 따라서 max_tokens는 품질 설정이면서 예산 설정이다.

가장 흔한 실수는 모든 호출에 넉넉한 max_tokens를 주는 것이다. 분류 작업에 2,000토큰을 줄 필요가 없다. "high/medium/low 중 하나"를 반환하는 작업이라면 20~50토큰이면 충분하다. JSON 한 줄이면 되는 작업에 긴 설명을 허용하면 모델은 친절하게 설명을 덧붙이고, 파서는 깨지고, 비용은 늘어난다.

출력 길이 관리는 프롬프트만으로 하지 말고 API 파라미터와 후처리 검증으로 함께 해야 한다. 프롬프트에는 "간결하게 답하라"고 쓰고, max_tokens로 물리적 상한을 두며, 출력 schema로 불필요한 필드를 막는다. 사용자가 장문 설명을 요청할 수 있는 제품이라면 "짧게 보기 / 자세히 보기"를 나누어 기본 응답을 짧게 만들고, 사용자가 원할 때 추가 호출을 하는 방식도 가능하다.

Extended thinking 또는 더 깊은 추론이 필요한 설정을 사용할 때도 마찬가지다. 깊은 사고는 복잡한 문제에 도움이 되지만 모든 요청에 켜 둘 필요는 없다. 고난도 수학 문제, 복잡한 코드 수정, 다단계 계획에는 가치가 있을 수 있다. 단순 문장 교정, 태그 분류, FAQ 응답에는 과하다. thinking 관련 토큰이 과금과 지연 시간에 영향을 줄 수 있으므로, 이를 별도 지표로 보고 기능별 정책을 정해야 한다.

운영 정책은 다음처럼 단순하게 시작할 수 있다.

기본 모드: thinking 비활성 또는 낮은 effort
복잡도 감지: 긴 입력, 다단계 지시, 실패한 1차 검증
승격 모드: 더 강한 모델 또는 higher effort
상한: 사용자 요청 1건당 최대 내부 호출 수와 최대 출력 토큰

이 정책의 핵심은 무제한 루프를 막는 것이다. 모델이 도구를 계속 호출하거나, 검증 실패로 계속 재시도하거나, 긴 reasoning을 반복하면 사용자 요청 하나가 비용 폭탄이 될 수 있다. 내부 호출 수, tool loop 횟수, 총 토큰 예산을 요청 단위로 제한해야 한다.

비용 최적화는 아끼는 일이 아니라 단위 경제성을 맞추는 일이다

조직에서 Claude 비용을 이야기할 때 "비싸다/싸다"라는 말은 별로 도움이 되지 않는다. 중요한 것은 단위 경제성이다. 고객지원 답변 초안 하나가 30원이고 상담원 시간을 2분 줄인다면 훌륭한 투자일 수 있다. 반대로 무료 사용자의 장난성 요청 하나에 500원이 든다면 아무리 좋은 답변이어도 지속 가능하지 않다.

따라서 비용 대시보드는 총액보다 단위 지표를 중심에 두어야 한다.

FinOps 관점에서는 showback과 chargeback을 구분할 수 있다. showback은 팀별·기능별 사용량과 비용을 보여 주기만 하는 방식이다. chargeback은 실제 비용을 해당 팀 예산에 배부하는 방식이다. 초기에는 showback만으로도 효과가 크다. 팀이 자신들의 프롬프트 변경이 비용에 어떤 영향을 주는지 보기 시작하면, 자연스럽게 토큰을 줄이고 캐싱을 적용하고 배치를 고려하게 된다.

예산 한도는 두 단계로 둔다. 첫째, 조직 또는 프로젝트 단위의 hard limit이다. 이 한도에 가까워지면 신규 호출을 제한하거나 승인 절차를 요구한다. 둘째, 기능 또는 팀 단위의 soft budget이다. soft budget은 넘는다고 즉시 서비스를 멈추지는 않지만 알림과 리뷰를 발생시킨다.

알림 기준은 단순한 월 누적액보다 burn rate가 더 유용하다. 월 예산이 3,000달러인데 월초 이틀 만에 1,000달러를 썼다면 아직 한도를 넘지 않았어도 위험하다. 24시간 rolling spend가 월 예산의 일정 비율을 넘거나, 특정 기능의 시간당 비용이 평소 대비 두 배가 되면 알림을 보내야 한다.

비용 급증의 흔한 원인들

Claude 비용이 갑자기 늘어났을 때는 대부분 몇 가지 패턴 중 하나다. 첫째, 프롬프트나 도구 정의가 길어졌다. 새 정책 문서와 예시를 붙였는데 캐싱을 하지 않았거나, 도구 스키마가 너무 상세해졌다. 둘째, 대화 기록이 계속 누적된다. 오래된 세션을 compact하지 않고 매 턴 전체 맥락을 보낸다. 셋째, RAG가 과하게 많은 문서를 넣는다. top_k가 늘었거나 chunk 크기가 커졌거나 중복 청크 제거가 깨졌다. 넷째, 재시도 폭풍이 발생했다. 429나 5xx에 대해 여러 계층에서 동시에 재시도한다. 다섯째, 모델 라우팅이 깨져 단순 요청이 고성능 모델로 간다.

이런 원인을 찾으려면 비용을 다음 차원으로 쪼개야 한다.

총비용
 ├─ 모델별 비용
 ├─ 기능별 비용
 ├─ 사용자/테넌트별 비용
 ├─ prompt_version별 비용
 ├─ input/output/cache별 비용
 ├─ retry에서 발생한 비용
 └─ tool loop에서 발생한 비용

비용 급증 대응은 소방 훈련처럼 미리 절차를 정해 두어야 한다. 예를 들어 시간당 비용이 임계값을 넘으면 먼저 최근 배포를 확인한다. 배포가 있었다면 prompt_version을 이전으로 롤백하거나 트래픽을 줄인다. 배포가 없었다면 특정 테넌트나 endpoint의 사용량 폭증을 확인한다. 재시도율이 높으면 circuit breaker를 열고, 비필수 배치 작업을 중단한다. cache hit rate가 떨어졌다면 캐시 prefix 변경 여부를 확인한다.

비용 사고에서 가장 위험한 말은 "일단 지켜보자"다. AI 비용은 트래픽과 토큰에 따라 빠르게 누적된다. 특히 agentic workflow는 한 사용자 요청이 여러 내부 호출로 증폭될 수 있다. 자동 알림, 임시 차단, fallback, batch 중지, 모델 downgrade 같은 즉시 조치 버튼을 운영 도구에 준비해 두자.

운영 런북: 문제가 생겼을 때 누구나 같은 순서로 움직이게 한다

운영은 사람의 기억에 맡기면 안 된다. 특히 AI 시스템 장애는 원인이 다양하다. rate limit인지, 비용 한도인지, 검색 장애인지, 도구 권한 오류인지, 프롬프트 배포 문제인지, 모델 API 지연인지 빠르게 구분해야 한다. 런북은 이 구분을 위한 지도다.

예를 들어 429 오류가 증가하는 상황의 런북은 다음과 같이 쓸 수 있다.

증상: 429 rate가 5분 이상 2% 초과

1. 영향 범위 확인
   - 전체 모델인가, 특정 모델인가?
   - 전체 기능인가, 특정 endpoint인가?
   - 실시간 요청인가, 배치 작업인가?

2. 한도 차원 확인
   - RPM 압박인가?
   - input TPM 압박인가?
   - output TPM 압박인가?
   - spend limit 접근인가?

3. 즉시 완화
   - 비필수 배치 작업 일시 중단
   - 낮은 우선순위 요청 큐잉 또는 거절
   - top_k와 max_tokens 임시 하향
   - 단순 작업을 더 가벼운 모델로 라우팅
   - retry 동시성 제한

4. 원인 분석
   - 최근 배포 여부 확인
   - prompt_version별 토큰 변화 확인
   - 특정 tenant 또는 user 폭증 확인
   - cache hit rate 하락 여부 확인

5. 사후 조치
   - rate limit 상향 필요성 검토
   - 토큰 예산 조정
   - 부하 테스트 시나리오 갱신

비용 급증, latency 증가, JSON 파싱 실패율 증가, tool failure 증가, safety refusal 급증에 대해서도 각각 런북을 둔다. 런북은 길 필요가 없다. 중요한 것은 온콜 담당자가 새벽 3시에 봐도 바로 따라 할 수 있어야 한다는 점이다.

프로덕션 준비 체크리스트

Claude 기능을 프로덕션에 올리기 전에는 다음 항목을 통과해야 한다. 이 체크리스트는 기술팀만을 위한 것이 아니다. 제품, 보안, 법무, 운영, 재무가 함께 보는 배포 승인 문서의 뼈대가 될 수 있다.

이 체크리스트는 한 번 작성하고 끝나는 문서가 아니다. 사고를 겪을 때마다 갱신해야 한다. 운영 성숙도는 장애가 없었던 기간이 아니라, 장애에서 배운 내용을 시스템에 반영하는 속도로 결정된다.

작은 팀을 위한 현실적인 시작 순서

모든 것을 한 번에 완벽하게 만들 필요는 없다. 작은 팀이라면 다음 순서로 시작하는 것이 현실적이다.

첫째, 모든 Claude 호출을 하나의 wrapper로 통일한다. 이 wrapper에서 request_id, feature, model, prompt_version, latency, usage, error를 기록한다. 이것만 해도 비용과 장애 분석의 절반은 해결된다.

둘째, prompt와 model 설정을 Git으로 버전 관리한다. 운영 콘솔에 직접 붙여 넣는 프롬프트를 없애고, 배포된 prompt_version을 요청 로그에 남긴다.

셋째, 기본 대시보드를 만든다. 요청 수, 오류율, 429 rate, p95 latency, input/output tokens, 비용, cache hit rate만 있어도 초기 운영에는 충분하다.

넷째, rate limit 대응을 넣는다. backoff, jitter, retry cap, queue, concurrency cap을 적용한다. 특히 재시도는 한 계층에서만 책임지도록 정한다.

다섯째, 비용이 큰 endpoint부터 최적화한다. 모든 기능을 미세하게 손보지 말고 상위 20% 비용을 쓰는 기능을 찾는다. 그곳에 prompt caching, max_tokens 조정, model routing, batch 전환을 적용한다.

여섯째, 월간 FinOps 리뷰를 연다. 팀별 비용, 기능별 단위 비용, 품질 지표, 예산 대비 사용량을 함께 본다. 비용만 줄이는 회의가 아니라 "어떤 AI 기능이 돈값을 하는가"를 판단하는 회의가 되어야 한다.

운영의 마지막 원칙: 비용, 품질, 지연 시간은 함께 움직인다

Claude 운영에서 비용을 줄이는 가장 쉬운 방법은 아무것도 하지 않는 것이다. 모델을 낮추고, 컨텍스트를 줄이고, 출력 길이를 자르면 비용은 내려간다. 하지만 품질도 같이 내려갈 수 있다. 반대로 품질을 높이겠다고 항상 가장 강한 모델, 가장 긴 컨텍스트, 가장 자세한 답변을 쓰면 비용과 지연 시간이 오른다.

따라서 운영자는 세 값을 함께 봐야 한다. 품질, 지연 시간, 비용이다. 좋은 운영은 이 셋 중 하나를 무작정 최적화하지 않는다. 기능의 목적에 맞는 균형점을 찾는다. 고객이 즉시 답을 기다리는 챗봇은 지연 시간이 중요하다. 법률 검토 보조는 품질과 근거가 중요하다. 야간 대량 분류는 비용과 처리량이 중요하다.

이 장의 핵심을 한 문장으로 줄이면 이렇다. Claude 시스템은 모델을 배포하는 것이 아니라 운영 가능한 의사결정 흐름을 배포하는 것이다. 그 흐름에는 환경 분리, 버전 관리, 관측성, rate limit 대응, caching, batch, token counting, model routing, 예산 관리가 포함된다.

PoC는 가능성을 증명한다. 운영은 그 가능성을 매일 반복 가능한 가치로 바꾼다. 다음 장에서는 이 운영 원칙들이 산업별 사례에서 어떻게 다르게 적용되는지 살펴본다. 고객지원, 법률 요약, 콘텐츠 검토, 개발자 도구, 연구 분석은 모두 Claude를 쓰지만, 성공 지표와 위험, 비용 구조는 서로 다르다. 같은 기술이 다른 현장에서 어떻게 다른 시스템이 되는지 보게 될 것이다.

참고

¹Claude Code 비용/사용량을 한눈에: AWS에 Observability 플랫폼 구축하기

²Rate limits - Claude API Docs

³Prompt caching - Claude API Docs

⁴Pricing - Claude API Docs