작업과 예산에 맞는 모델 선택하기

유용한 사고방식: 작업 특성이 먼저, 모델은 그다음

실무에서는 모델 이름을 살펴보기 전에 LLM 워크로드를 다섯 가지 축으로 분류합니다:

“어떤 모델이 가장 똑똑한가?” 대신 “비용을 들여 어떤 실패 유형의 위험을 줄이려는가?”라고 묻기 시작하면 모델 선택이 훨씬 쉬워집니다.

예를 들면:

• 비밀번호 재설정 요약 도구에는 일관성과 낮은 비용이 필요합니다.
• 코드 마이그레이션 어시스턴트에는 추론과 도구 사용 능력이 필요합니다.
• 계약서 변경 사항 비교 도구에는 긴 컨텍스트뿐 아니라 신중한 출처 명시도 필요합니다.
• 고객 응대 에이전트에는 최고 수준의 벤치마크 성능보다 예측 가능한 지연 시간이 더 중요합니다.
• 배치 데이터 보강 파이프라인에서는 응답의 세련됨보다 비용 대비 처리량이 더 중요할 수 있습니다.

잘못된 모델 선택은 기술적으로 틀린 경우보다 경제적으로 맞지 않는 경우가 많습니다.

실용적인 모델 단계 체계

제가 대부분의 프로덕션 시스템에서 사용하는 단계 체계는 다음과 같습니다.

Haiku급 모델: 저렴하고 빠른 언어 작업의 기본 선택

Haiku급 모델은 일차 처리에 탁월합니다. 저는 답변이 짧고, 입력이 깔끔하며, 출력 형식이 제한된 작업에 이 모델들을 사용합니다.

적합한 작업:

• 티켓 태그 지정
• 짧은 요약
• 감정 분류
• 이메일 제목 정규화
• FAQ 매칭
• 간단한 JSON 추출
• 위험도가 낮은 콘텐츠 검토 사전 필터

저비용 모델을 사용하는 초기 분류기의 프롬프트 예시:

{
  "model": "claude-haiku-4.5",
  "temperature": 0,
  "max_tokens": 120,
  "response_format": { "type": "json" },
  "messages": [
    {
      "role": "system",
      "content": "Classify the support ticket. Return only valid JSON."
    },
    {
      "role": "user",
      "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge."
    }
  ]
}

예상 출력:

{
  "category": "billing",
  "urgency": "medium",
  "needs_human": true,
  "reason": "Refund dispute involving payment status"
}

흔한 함정이 있습니다. 팀에서 저비용 모델에 추론과 완벽한 형식의 출력을 한 번에 요구하는 것입니다. 모델이 가끔 유효하지 않은 JSON을 출력한다면 곧바로 Opus로 전환하지 마세요. 먼저 작업을 더 명확하게 제한하세요:

• 설정할 항목: temperature: 0
• JSON 스키마 또는 도구 호출 사용
• 지시 사항의 범위 축소
• 분류와 설명 분리
• 출력 검증 후 한 번 재시도

많은 프로덕션 작업에서는 Haiku급 모델로 한 번 재시도하는 편이 최첨단 추론 모델을 기본으로 사용하는 것보다 여전히 저렴하고 빠릅니다.

Sonnet급 모델: 실제 제품 로직의 주력 모델

저는 대화형 제품 기능에 대체로 Sonnet급 모델을 선택합니다. 추론 능력이 충분하고, 도구 사용이 안정적이며, 사용자 대상 흐름에서도 대체로 충분히 빠릅니다.

적합한 작업:

• 고객 지원 답변 초안 작성
• 도구를 사용하는 에이전트 워크플로
• 코드 설명 및 가벼운 리팩터링
• 여러 단계의 문서 질의응답
• 영업 또는 고객 성공 코파일럿 워크플로
• 정돈되지 않은 입력에서 구조화된 정보 추출

실제로 Sonnet은 라우팅을 너무 깊이 고민하고 싶지 않을 때 가장 좋은 선택인 경우가 많습니다. 새 기능에 하나의 모델 등급만 통합할 수 있다면 여기서 시작하세요.

예시: 주문, 정책, 이전 지원 티켓을 확인할 수 있는 지원 에이전트.

SYSTEM = """
You are a support resolution assistant.
Use tools before making claims about orders, refunds, or account state.
If policy is ambiguous, say what is ambiguous and escalate.
Return:
- summary
- recommended_action
- customer_reply
- escalate: true/false
"""

request = {
    "model": "claude-sonnet-4.6",
    "temperature": 0.2,
    "max_tokens": 900,
    "tools": [
        {"name": "get_order", "description": "Fetch order state"},
        {"name": "get_refund_policy", "description": "Fetch current refund rules"},
        {"name": "search_prior_tickets", "description": "Search customer history"}
    ],
    "messages": [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": "Customer says they returned item A but were charged again."}
    ]
}

이런 워크플로를 프로덕션에서 실행하면 실제로 어떤 일이 생길까요? 대부분의 실패는 “모델이 똑똑하지 않아서” 발생하지 않습니다. 통합 과정의 실패입니다.

• 도구가 오래된 상태를 반환합니다.
• 모델에 관련 없는 컨텍스트가 너무 많이 제공됩니다.
• 정책 문서에 서로 모순되는 내용이 있습니다.
• 도구 호출이 실패한 뒤에도 에이전트가 계속 진행하도록 허용됩니다.
• 프롬프트가 내부 분석과 고객에게 바로 제공할 문장을 구분하지 않고 둘 다 요구합니다.

Sonnet급 모델은 어느 정도의 혼란을 수습할 만큼 충분한 지능을 제공하지만, 명확한 도구 계약의 필요성까지 없애 주지는 않습니다.

Opus급 모델: 비싸지만 때로는 실수보다 저렴한 선택

Opus급 모델은 잘못된 답변의 비용이 추론 비용보다 훨씬 큰 작업을 위한 모델입니다.

저는 다음과 같은 경우에 Opus를 사용합니다:

• 입력이 모호하고 결과의 파급력이 큰 경우
• 서로 영향을 주는 제약 조건이 많은 경우
• 사용자가 심층적인 추론을 기대하는 경우
• 작업에 코드, 정책 또는 아키텍처의 절충안이 관련된 경우
• 저비용 모델의 시도가 실패하면 사람의 시간이 낭비되는 경우

예시:

• 데이터베이스 마이그레이션 계획 검토
• 프로덕션 장애의 시간대별 경과 분석
• 사람이 검토할 복잡한 법률·정책 비교 자료 생성
• 여러 서비스에 걸친 에이전트 실패 디버깅
• 자동화된 작업이 안전한지 평가

저는 모든 “중요한” 작업에 Opus를 사용하지는 않습니다. 중요성과 난이도는 다릅니다. 백만 건의 비밀번호 재설정 티켓은 사용자에게 중요하지만, 각각의 처리는 어렵지 않습니다. 반면 미묘한 문제가 있는 단 한 건의 데이터 삭제 마이그레이션은 중요하면서도 어려울 수 있습니다.

유용한 패턴은 “불확실할 때 상위 모델로 전환”하는 것입니다:

def choose_model(task):
    if task["context_tokens"] > 700_000:
        return "fable-5"

    if task["risk"] == "high" and task["requires_reasoning"]:
        return "claude-opus-4.8"

    if task["requires_tools"] or task["multi_step"]:
        return "claude-sonnet-4.6"

    return "claude-haiku-4.5"

이는 의도적으로 단순하게 만든 것입니다. 라우터는 팀이 새벽 2시에도 디버깅할 수 있을 만큼 평범하고 단순해야 합니다.

Fable 5과 1M 컨텍스트: 검색이 문제일 때 사용하세요

긴 컨텍스트 모델은 검색 관련 엔지니어링 작업을 상당 부분 덜어 주기 때문에 매력적입니다. Fable 5의 1M 컨텍스트 윈도는 문서 전체 검토, 방대한 대화 기록 종합, 대규모 저장소 점검, 여러 파일에 걸친 정책 분석 등 직접 시도할 수 있는 작업의 범위를 바꿉니다.

하지만 긴 컨텍스트가 만능은 아닙니다.

1M 토큰 윈도는 “관련 사실이 어디에나 있을 수 있다”는 점이 어려움의 핵심일 때 도움이 됩니다. 그렇다고 모델이 백만 토큰 전체에 걸쳐 완벽하게 추론한다고 보장하지는 않으며, 관련 없는 컨텍스트의 비용이 사라지는 것도 아닙니다. 긴 프롬프트는 여전히 비용이 들고, 지연 시간을 늘리며, 주의를 분산시킬 수 있습니다.

저는 다음과 같은 경우에 Fable 방식의 긴 컨텍스트를 사용합니다:

• 자료 간 연결 관계가 너무 복잡해 단순한 청크 분할이 어려운 경우
• 세부 사항 하나를 놓치는 것이 추가 컨텍스트 비용보다 더 큰 손해인 경우
• 사용자가 느린 응답을 감수할 수 있는 경우
• 주변의 원문 자료를 함께 보는 것이 작업에 도움이 되는 경우

대규모 문서 검토를 위한 아키텍처 예시:

User request
  -> lightweight classifier
  -> retrieve obvious relevant sections
  -> if confidence high: Sonnet answer with citations/quotes from chunks
  -> if confidence low or query is global: Fable 5 over full document set
  -> optional Opus review for high-risk final answer

이러한 혼합 방식은 “항상 모든 내용을 컨텍스트에 넣는” 방식보다 효과적입니다. 실제로 긴 컨텍스트 모델은 검색 신뢰도가 낮을 때 대안으로 활용할 때 가장 가치가 높습니다.

가중치 공개 모델: 제어, 비용, 처리량

Llama, Qwen, DeepSeek, MiniMax, Kimi 같은 가중치 공개 모델은 단순히 “더 저렴한 대안”이 아닙니다. 운영 방식에 관한 선택입니다.

다음이 필요할 때 적합합니다:

• 로컬 또는 VPC 배포
• 예측 가능한 대량 배치 처리 비용
• 미세 조정 또는 증류
• 맞춤형 추론 최적화
• 데이터 저장 위치 제어
• 초기 설정 후 극히 낮은 한계 비용

이러한 모델은 특히 범위가 좁고 반복적인 작업에 적합합니다. 예를 들어 vLLM으로 제공되는 Qwen 또는 Llama 변형 모델은 프롬프트 길이와 출력 형식을 제어하면 분류, 추출, 내부 정보 보강을 높은 처리량으로 수행할 수 있습니다.

로컬 서빙 구성 예시:

vllm serve Qwen/Qwen3-14B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

그런 다음 OpenAI 호환 클라이언트로 호출합니다:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"
)

result = client.chat.completions.create(
    model="Qwen/Qwen3-14B",
    temperature=0,
    messages=[
        {"role": "system", "content": "Return valid JSON only."},
        {"role": "user", "content": "Classify: user cannot access invoice PDF"}
    ]
)

절충점은 엔지니어링 책임입니다. 호스팅되는 최첨단 모델에서는 다른 주체가 용량, 패치, 양자화 방식 선택, 커널 수준의 성능 작업을 처리합니다. 공개 모델에서는 이 모든 것이 여러분의 일이 됩니다.

가중치 공개 모델은 워크로드가 안정적일 때 매우 적합합니다. 제품이 매주 바뀌고 순수 서빙 비용보다 프롬프트 품질이 더 중요할 때는 적합성이 떨어집니다.

저비용 모델 우선 라우팅과 상위 모델 전환

좋은 라우터는 순위표가 아닙니다. 위험 제어 시스템입니다.

프로덕션에 적합한 패턴은 다음과 같습니다:

1. 작업을 수행할 수 있을 것으로 예상되는 가장 저렴한 모델을 먼저 시도합니다.
2. 출력을 기계적으로 검증합니다.
3. 관찰 가능한 기준에 대해서만 모델에 보정된 자기 점검을 요청합니다.
4. 검증이 실패하거나, 신뢰도가 낮거나, 위험도가 높으면 상위 모델로 전환합니다.
5. 나중에 조정할 수 있도록 라우팅 경로와 결과를 기록합니다.

라우터 예시:

def run_with_escalation(task, input_text):
    first_model = pick_first_model(task)

    response = call_model(
        model=first_model,
        input=input_text,
        schema=task["schema"],
        temperature=0
    )

    validation = validate(response, task["schema"])

    if not validation.ok:
        return call_model(
            model="claude-sonnet-4.6",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    if task["risk"] == "high" and response.get("needs_review"):
        return call_model(
            model="claude-opus-4.8",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    return response

중요한 점은 상위 모델 전환이 직감이 아니라 측정 가능한 신호에 기반해야 한다는 것입니다.

상위 모델 전환에 유용한 신호:

• 유효하지 않은 JSON
• 필수 필드 누락
• 모순되는 답변
• 도구 호출 실패
• 검색된 근거가 빈약함
• 사용자가 되돌릴 수 없는 작업을 요청함
• 입력이 일반적인 길이를 초과함
• 모델이 불확실성을 명시적으로 표시함
• 분류기가 법률, 의료, 보안 또는 금융 콘텐츠를 감지함

“모델 신뢰도”만을 수치 점수로 사용하는 것은 피하세요. LLM의 신뢰도는 보정된 확률이 아닙니다. 그래도 구체적인 점검 항목으로 제한하면 유용합니다. “입력에 답변하기에 충분한 정보가 있었나요?”가 “얼마나 확신하나요?”보다 낫습니다.

지연 시간, 가격, 사용자 경험

가장 빠른 모델이 항상 최고의 UX를 제공하는 것은 아닙니다. 최고의 UX는 사용자가 감당할 수 있는 대기 시간 안에 올바른 결과에 도달하도록 하는 것입니다.

대화형 시스템에서는 지연 시간 예산을 기준으로 생각합니다:

피드백 없이 로딩 표시 뒤에 느린 추론을 숨기지 마세요. Opus나 Fable 작업에 90초가 필요하다면, 분석 작업임을 명확히 표시하세요.

Analyzing 184 files...
✓ Indexed repository structure
✓ Found 12 migration scripts
✓ Checking rollback safety

시스템이 수행하는 작업이 눈에 보이므로 사용자의 인식이 달라집니다.

또한 가능하면 항상 스트리밍을 사용하세요. 스트리밍은 전체 완료 시간을 줄이지는 않지만, 채팅과 초안 작성 워크플로에서 체감 지연 시간을 크게 개선합니다.

실제 작업별 선택

제가 지금이라면 내릴 구체적인 선택은 다음과 같습니다.

지원 티켓 분류

Haiku를 먼저 사용하세요.

• 입력: 짧은 티켓 텍스트
• 출력: 분류, 긴급도, 배정할 큐
• 청구 분쟁, 화가 난 고객, 모호한 정책은 Sonnet으로 에스컬레이션
• 기준 금액을 초과하는 환불은 사람이 검토

이는 저비용 모델을 먼저 사용하는 전형적인 워크플로입니다.

고객 응대 지원 에이전트

Sonnet을 사용하세요.

• 도구 사용 필요
• 어조 제어 필요
• 정책 처리 필요
• 원활한 에스컬레이션 필요

Haiku는 전처리에만 사용하세요. 고위험 사례의 감독 검토에는 Opus를 사용하세요.

코드 리뷰 어시스턴트

일반적인 PR 리뷰에는 Sonnet을 사용하세요. 아키텍처에 민감한 변경, 동시성, 보안, 데이터 마이그레이션, 미묘한 정확성 문제를 다루는 작업에는 Opus를 사용하세요.

흔한 실수는 기본적으로 저장소 전체를 입력하는 것입니다. 변경 사항의 diff, 의존성 그래프, 인접 파일부터 시작하세요. 변경이 여러 영역에 걸쳐 있을 때만 Fable이나 다른 긴 컨텍스트 모델로 에스컬레이션하세요.

긴 계약서 또는 정책 비교

범위가 좁은 질문에는 검색과 Sonnet을 함께 사용하세요. “이 문서들 전체에서 모든 모순을 찾아줘”처럼 전체를 아우르는 질문에는 Fable 5을 사용하세요.

출력이 실제 법률 또는 규정 준수 결정에 영향을 미친다면, 모델은 분석을 준비하는 데 사용하고 결정을 내리는 데 사용하지 마세요.

대량 데이터 보강

처리량이 많고 작업이 안정적이라면 가중치 공개 모델을 사용하세요.

예:

• 회사명 정규화
• 업종 태그 추출
• 인바운드 잠재 고객 분류
• 짧은 내부용 요약 생성

매일 밤 배치를 실행하고, 표본을 검증하고, 예외 사례는 호스팅 모델로 에스컬레이션하세요.

대규모 아카이브를 다루는 리서치 어시스턴트

컨텍스트 길이와 추론 요구 사항에 따라 Gemini 3, GPT-5.5, Opus 또는 Fable을 사용하세요. 쿼리가 명백히 단순하지 않다면 저는 저비용 모델부터 시작하지 않겠습니다. 리서치 실패는 드러나지 않는 경우가 많습니다. 모델이 핵심 문서를 놓친 채 그럴듯한 답변을 제공하기 때문입니다.

자기기만 없는 예산 책정

과도한 지출로 이어지는 가장 쉬운 길은 재시도, 사람의 수정, 실패한 워크플로를 무시한 채 호출당 비용만 최적화하는 것입니다.

작업 유형과 모델별로 다음 지표를 추적하세요.

• 입력 토큰
• 출력 토큰
• 지연 시간 p50/p95
• 검증 실패율
• 에스컬레이션 비율
• 사람이 결과를 수정하거나 대체한 비율
• 사용자 재시도율
• 호출당 비용이 아닌 성공한 작업당 비용

마지막 지표가 중요합니다. 재시도가 세 번 필요하고 그 후에도 수동 검토를 유발하는 저렴한 모델은 Sonnet보다 비용이 더 많이 들 수 있습니다. 잘못된 마이그레이션을 막아 주는 Opus 호출은 그 주에 내린 가장 저렴한 결정일 수 있습니다.

Claude, GPT, Gemini 제품군 전반에 대한 AI Prime Tech의 API 액세스 같은 멀티 모델 게이트웨이를 사용한다면, 주요 이점은 단순히 공급업체 선택의 폭이 넓어진다는 데 있지 않습니다. 모델 등급 전반에 걸쳐 라우팅과 측정이 쉬워진다는 데 있습니다. 하지만 여전히 어려운 부분은 작업 설계입니다.

실무 핵심 요점

• 변환, 추출, 추론, 긴 컨텍스트 종합, 배치 보강 등 작업의 유형부터 파악하세요.
• 기계적으로 검증할 수 있고 제약이 명확한 저비용·고속 작업에는 Haiku급 모델을 사용하세요.
• 추론, 도구, 사용자에게 제공할 만한 품질이 필요한 제품 기능에는 Sonnet급 모델을 기본으로 사용하세요.
• 실수의 대가가 크거나, 모호성이 높거나, 깊은 추론이 중요할 때는 Opus급 모델을 사용하세요.
• 검색의 불확실성이 핵심 문제일 때 Fable 5과 같은 긴 컨텍스트를 사용하세요. 이를 프롬프트에 모든 내용을 쏟아붓는 기본 전략으로 삼지는 마세요.
• 워크로드의 안정성, 개인정보 보호, 처리량, 배포 제어를 고려했을 때 추론을 직접 운영할 타당성이 있다면 가중치 공개 모델을 사용하세요.
• 유효하지 않은 출력, 빈약한 근거, 도구 실패, 고위험 행동, 불확실성과 같은 명시적인 에스컬레이션 신호를 갖춘 저비용 우선 라우팅을 구축하세요.
• 토큰당 또는 호출당 비용이 아니라 성공한 작업당 비용을 측정하세요.
• 긴박한 상황에서도 디버깅할 수 있을 만큼 라우터를 단순하게 유지하세요.
• 모델 선택을 일회성 공급업체 결정이 아니라 엔지니어링에서 조정할 수 있는 제어 수단으로 다루세요.