Claude Opus 5 리뷰: 5단계 effort로 비용·성능 최적화하기

Claude Opus 5는 복잡한 코딩, 에이전트, 엔터프라이즈 업무를 겨냥한 Anthropic의 프리미엄 모델입니다. 2026년 7월 24일 출시됐으며, 기존 Opus 가격으로 Fable 5의 성능 상당 부분을 제공한다는 명확한 약속을 내걸었습니다.

가격만 보면 Opus 4.8에서 부담 없이 업그레이드할 수 있습니다. 그러나 프로덕션 도입까지 자동으로 쉬워지는 것은 아닙니다. 이제 thinking이 기본으로 작동하고, effort는 텍스트와 툴 전반에서 모델이 투입하는 작업량을 바꾸며, 예전 출력 한도를 그대로 쓰면 추론이 끝나기 전에 작업이 잘릴 수 있습니다.

Claude Opus 5는 일상 업무용 프리미엄 모델이지 절대적 최고점은 아닙니다

매일 반복되는 고난도 업무에는 Opus 5를 사용합니다. 처리량과 지연 시간이 더 중요하면 Sonnet 5를 선택합니다. Opus 평가에서 이미 실패했고 그 실패 비용이 토큰 가격 2배의 프리미엄보다 큰 작업에만 Fable 5를 배정합니다.

Anthropic도 현재 모델 라인업을 이와 같은 위계로 설명합니다. 최신 모델 가이드는 선택을 고민하는 개발자에게 복잡한 에이전트 코딩과 엔터프라이즈 업무는 Opus 5로 시작하고, 현존 최고 수준의 성능이 필요할 때 Fable 5로 옮기라고 안내합니다.

Opus 5의 컨텍스트 윈도는 100만 토큰이고, 동기식 최대 출력은 128,000토큰입니다. 컨텍스트 윈도는 한 번의 요청에서 모델이 참고할 수 있는 자료의 범위이지, 모든 토큰에 똑같이 주의를 기울인다는 보장은 아닙니다. 출력 한도에는 숨겨진 thinking과 사용자에게 보이는 답변이 모두 포함되므로 마이그레이션할 때 특히 중요합니다.

모델 ID는 claude-opus-5입니다. Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry에서 사용할 수 있습니다. Claude 앱에서는 Anthropic이 Max의 기본 모델로 지정했으며, Pro에서 이용할 수 있는 가장 강력한 모델입니다.

이 순위는 영구적이지 않습니다. 모델 등급에 대한 선호가 아니라 실제 워크로드의 증거를 기준으로 경로를 바꾸므로, 다음 모델이 출시돼도 활용할 수 있는 라우팅 정책입니다.

Claude Opus 5 성능은 성공한 작업당 비용으로 판단해야 합니다

Opus 5의 벤치마크에서 중요한 점은 모든 항목에서 1위를 차지한다는 것이 아닙니다. 더 저렴한 실행으로도 승인 가능한 동일한 결과에 자주 도달한다는 점입니다.

Anthropic이 공개한 결과 가운데 의사결정에 영향을 주는 다섯 가지는 다음과 같습니다.

• Frontier-Bench v0.1에서 Opus 5는 작업당 비용을 낮추면서 Opus 4.8보다 2배 넘는 성능을 기록했습니다.
• CursorBench 3.2에서 max effort의 Opus 5는 작업당 비용을 절반만 쓰고도 Fable 5 최고 결과와 0.5% 이내까지 접근했습니다.
• ARC-AGI 3에서는 Anthropic 비교 기준으로 차순위 모델보다 3배 높은 점수를 받았습니다.
• Zapier AutomationBench에서는 같은 작업당 비용 기준 합격률이 차순위 모델의 약 1.5배입니다. 가장 낮은 effort에서도 해당 비교군의 다른 어떤 모델보다 많은 작업을 통과했습니다.
• OSWorld 2.0에서는 Fable 5의 최고 컴퓨터 사용 결과를 넘어섰고, 비용은 3분의 1을 조금 넘는 수준이었습니다.

이는 모든 저장소, 정책 문서, 브라우저 워크플로에 통용되는 보편적 순위표가 아니라 벤더가 출시 시점에 공개한 결과입니다. effort를 높여 추가 토큰을 쓰면 승인 가능한 작업으로 이어질 수 있다는 방향성은 보여줍니다. 하지만 자체 에이전트가 몇 번 재시도해야 하는지, 사람이 답변을 얼마나 자주 거부하는지, 서비스 수준 목표에는 조금 약하더라도 더 빠른 결과가 나은지까지 알려주지는 않습니다.

성공한 작업당 비용은 이런 누락 요소를 포함합니다. 모든 시도의 토큰 비용과 툴 호출 요금, 제품에 영향을 주는 지연 시간, 사람의 검토 비용을 더합니다. 그런 다음 승인 기준을 통과한 결과 수로 총비용을 나눕니다.

코딩 에이전트라면 테스트 통과, 범위 안에 머문 diff, 수정 라운드 없이 리뷰어가 승인한 결과를 성공으로 정의할 수 있습니다. 운영 에이전트라면 레코드의 정확한 업데이트, 적절한 승인 요청, 근거 없는 행동의 부재가 기준이 될 수 있습니다. effort를 비교하기 전에 결과를 설명하는 평가 기준부터 세워야 합니다.

모델이 겉보기에 얼마나 똑똑한지는 핵심 지표가 아닙니다. 비용을 알고 있는 상태에서 승인된 결과를 얻었는지가 중요합니다.

동일 워크로드의 비용은 $9, $22.50, $45입니다

토큰 구성이 같다면 Opus 5의 비용은 Sonnet 5의 한시적 가격과 Fable 5 사이 정확히 중간에 놓입니다.

100개 작업을 예로 들어보겠습니다. 작업 하나가 입력 토큰 20,000개를 보내고 출력 토큰 5,000개를 받는다면, 전체 배치는 입력 토큰 200만 개와 출력 토큰 500,000개를 사용합니다.

• Sonnet 5는 출시 기간 입력 $2, 출력 $10 요금으로 $9입니다.
• Opus 5는 입력 $5, 출력 $25 요금으로 $22.50입니다.
• Fable 5는 입력 $10, 출력 $50 요금으로 $45입니다.

계산에는 Anthropic의 현재 API 요금을 적용했습니다. Sonnet 5의 $2/$10 요금은 2026년 8월 31일까지이며, 이후 표준 가격은 $3/$15가 됩니다. 프롬프트 캐싱, 배치 할인, 웹 검색, 코드 실행, 재시도, 모델 또는 effort 설정에 따른 토큰 사용량 변화는 계산에서 제외했습니다.

이 정도 규모에서는 Opus가 Sonnet보다 $13.50 더 비싸고, Fable은 Opus보다 $22.50 더 비쌉니다. 배치 전체에서 $13.50가 넘는 수정 작업 하나만 막아도 Opus의 Sonnet 대비 프리미엄은 정당화됩니다. Fable로 한 단계 올리려면 $22.50가 넘는 실패 또는 검토 비용을 줄여야 합니다.

같은 구성으로 10,000개 작업을 처리하면 총액은 각각 $900, $2,250, $4,500입니다. Opus는 Sonnet보다 $1,350 높고, Fable은 거기에 $2,250를 더합니다. 프로토타입에서는 사소해 보이던 라우팅 선택도 프로덕션 규모에서는 별도 예산 항목이 됩니다.

Fast mode를 보면 차이가 더 분명해집니다. Opus 5를 약 2.5배 빠르게 실행하는 대신 $10/$50로 정상 가격의 2배를 냅니다. 100개 작업 예시의 비용은 $45가 되어 Fable 5의 기본 토큰 총액과 같아집니다. 기본 속도 스위치로 켜지 말고, 응답 시간이 그 프리미엄을 정당화할 만큼 제품 가치가 있을 때 구매해야 합니다.

Claude Opus 5 effort 설정은 토큰 예산이 아니라 정책입니다

high에서 시작합니다. Claude API와 Claude Code의 기본값이며, Anthropic에 따르면 high를 명시하는 것은 effort 매개변수를 생략하는 것과 동일하게 작동합니다.

effort는 Claude가 전체 응답에 투입하는 작업량을 조절합니다. 여기에는 사용자에게 보이는 텍스트, thinking, 툴 호출, 함수 인수가 모두 포함됩니다. 낮추면 토큰 사용량과 툴 활동이 줄어들 수 있고, 높이면 더 깊이 탐색하는 데 도움이 될 수 있습니다. 다만 하드 한도가 아니라 행동 신호이므로, 어려운 요청이라면 low에서도 thinking이 작동할 수 있습니다.

다섯 단계는 각각 용도가 뚜렷합니다.

low는 저렴하고 범위가 한정된 작업에 적합합니다. 분류, 추출, 단순 변환, 결과를 쉽게 확인할 수 있는 좁은 범위의 서브에이전트 작업에 사용합니다. 티켓을 직접 해결하는 에이전트보다 어느 대기열로 보낼지 판단하는 분류 에이전트가 더 잘 맞습니다.

medium은 균형 잡힌 프로덕션 설정입니다. 경로는 정해져 있지만 입력이 달라지는 일상적인 툴 기반 업무에 사용합니다. 고객 레코드 요약, 표준 답변 초안 작성, 명확히 정의된 운영 절차 수행 등이 해당합니다. 토큰 비용이나 지연 시간이 중요할 때 기본값에서 처음으로 낮춰볼 단계입니다.

high는 어려운 일상 업무의 기본값입니다. 코드 변경, 섬세한 분석, 실수 비용 때문에 신중한 추론이 필요한 다단계 에이전트에 사용합니다. 높거나 낮은 모든 설정을 이 지점과 비교할 수 있으므로 첫 측정값으로 적절합니다.

xhigh는 장기 실행 작업용입니다. Anthropic은 30분 넘게 실행되고 토큰 예산이 수백만 단위에 이를 수 있는 에이전트 또는 코딩 작업을 위한 단계로 설명합니다. 반복 탐색, 수많은 툴 호출, 장시간 실행 동안 계획 유지가 필요할 때 사용합니다.

max는 예외 경로입니다. 최고 성능을 위해 토큰 사용 제약을 없앱니다. xhigh가 실패했거나 결과의 가치가 매우 커서 토큰 효율이 부차적인 경우에만 이 단계가 적합합니다.

흔히 저지르는 실수는 두 가지입니다.

첫째, 글의 길이를 조절하려고 effort를 사용하면 안 됩니다. Anthropic 문서에 따르면 effort를 바꿔도 Opus 5가 사용자에게 보여주는 응답 길이가 안정적으로 짧아지지는 않습니다. 원하는 길이는 프롬프트에서 직접 요청해야 합니다.

둘째, 어려워 보이는 모든 작업을 max에서 시작하면 안 됩니다. 그러면 high로도 통과했을지 확인할 수 없고, 이후의 모든 비용 논의가 가정에 머물게 됩니다. 구매 가능한 최고 점수가 아니라 결과 기준을 안정적으로 충족하는 가장 낮은 설정을 찾아야 합니다.

Opus 5, Sonnet 5, Fable 5는 누가 사용해야 할까요?

대부분의 구매자는 모든 요청에 모델 하나만 선택해서는 안 됩니다. 기본 모델과 좁고 명확한 상향 경로를 정해야 합니다.

에이전트 제품을 만드는 투자를 유치한 창업자

검증하기 쉬운 대규모 상호작용에는 Sonnet 5를 사용하고, 계획을 세우거나 서로 충돌하는 맥락을 조정하거나 툴 실패 뒤 복구하는 단계에는 Opus 5를 사용합니다.

가장 안전해 보인다는 이유로 모든 턴에 Opus를 배치하는 것이 창업자의 위험 요소입니다. 요청 대부분이 예측 가능한 경로를 따른다면 애초에 필요하지 않았던 작업에 프리미엄을 쓰게 됩니다. 저렴한 경로는 넓게 열어두고, 중요한 단계만 Opus로 좁혀야 합니다.

복잡한 오케스트레이션은 Opus high에서 시작합니다. 추가 토큰 사용을 상쇄할 만큼 승인율이 개선될 때만 이미 어렵다고 확인된 작업 유형을 xhigh로 올립니다. 대표 작업에서 Opus가 실패했고 비즈니스 영향이 단가 2배를 감수할 만큼 클 때만 Fable로 보냅니다.

모델 계층을 표준화하는 중견기업 CTO

Opus 5를 프리미엄 기본값으로 삼되, 모델 라우팅 근거가 정책에 드러나게 해야 합니다. 각 워크로드 담당자가 Sonnet, Opus, Fable을 선택한 이유와 어떤 평가 결과가 나오면 경로를 바꿀지 설명할 수 있어야 합니다.

모든 Opus 4.8 요청에서 모델 문자열 하나만 바꾸고 마이그레이션이 끝났다고 판단하면 안 됩니다. 기본 thinking은 출력 동작과 토큰 소비를 바꿉니다. 기존 max_tokens 설정, 캐시된 대화 설계, 검증 프롬프트도 모두 다시 살펴야 합니다.

Claude Sonnet 5 분석은 유용한 하한선입니다. 현재 가격에서 승인되는 출력 품질을 유지한다면 Sonnet이 이깁니다. Fable은 상한선입니다. 이름이 붙은 워크로드에서 두 경계 모델 중 하나가 더 낫다는 증거가 나오기 전까지 중간 영역은 Opus가 맡습니다.

비즈니스 업무를 자동화하는 시니어 운영 담당자

업무가 여러 시스템이나 정책 경계를 넘나들면 Opus를 사용합니다. 요청을 읽고, 계정을 확인하고, 규칙을 적용하고, 사람의 승인이 필요한지 결정하는 일은 요약문 작성보다 어렵습니다. 각 단계가 다음 단계의 결과를 바꾸기 때문입니다.

툴 범위가 제한된 안정적인 절차에는 medium을 사용합니다. 예외 상황, 모호한 레코드, 서로 충돌하는 정책 문구가 흔하다면 high로 올립니다. 벤치마크가 좋아도 되돌릴 수 없는 행동에는 사람의 승인을 유지해야 합니다. 더 나은 모델은 일상적인 검토를 줄여줄 뿐, 책임을 없애지는 않습니다.

Fable은 작업이 유난히 어렵고 가치도 유난히 높을 때만 합리적입니다. 어차피 사람이 모든 결과를 검토한다면, 추가 모델 비용보다 검토 인터페이스 개선의 효과가 클 수 있습니다.

혼자 제품을 만드는 기술 창업자

제품 형태가 계속 바뀌는 동안에는 Sonnet 5로 시작합니다. 어려운 디버깅, 아키텍처 검토, 여러 파일에 걸친 구현은 Opus 5로 옮깁니다. 작은 수정 작업보다, 한 번 실패했을 때 맥락을 다시 구성하는 비용이 큰 작업에서 차이가 두드러집니다.

벤더를 가로지르는 더 큰 선택은 별도 문제입니다. GPT-5.6과 Claude Sonnet 5는 모델 품질뿐 아니라 실행 시스템도 다릅니다. Opus 5는 Anthropic의 프리미엄 경로를 강화하지만, 오케스트레이션이나 툴 권한, 관측 가능성까지 서로 바꿔 쓸 수 있게 만들지는 않습니다.

네 독자 유형 모두 같은 지점에서 선택이 바뀝니다. 측정된 실패·검토 비용이 모델 프리미엄을 넘을 때 업그레이드합니다. 그 비용을 아무도 측정하지 않았다면 상향하기 전에 평가하는 것이 안전한 비즈니스 결정입니다.

Opus 4.8에서 마이그레이션할 때 달라지는 동작은 두 가지입니다

claude-opus-4-8을 claude-opus-5로 바꾸면 단가는 동일한 $5/$25로 유지되지만, 런타임 동작까지 같지는 않습니다.

첫 번째 변화는 thinking의 기본 활성화입니다. Opus 4.8은 요청에서 켜지 않으면 thinking 없이 실행할 수 있었습니다. Opus 5는 기본적으로 언제 얼마나 생각할지 스스로 결정합니다. max_tokens가 thinking과 사용자에게 보이는 답변을 함께 제한하므로, Opus 4.8 응답에 충분했던 한도라도 Opus 5 에이전트가 완료되기 전에 잘릴 수 있습니다.

두 번째 변화는 thinking과 effort의 관계입니다. thinking을 비활성화하면서 xhigh 또는 max를 지정하면 API가 HTTP 400을 반환합니다. thinking을 꺼야 한다면 effort를 high 이하로 유지하고, 더 높은 effort가 필요하면 thinking 비활성화 필드를 제거합니다.

Anthropic은 thinking을 비활성화할 경우 Opus 5가 간혹 정상적인 tool_use 블록을 내보내는 대신 일반 텍스트에 툴 호출을 쓰거나 내부 XML 태그를 노출할 수 있다고도 경고합니다. 가능하면 thinking을 켜두고 effort로 지출을 조절해야 합니다.

다음은 장시간 코딩 또는 에이전트 작업에 유효한 Python 요청입니다.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this repository migration plan. Identify unsafe "
                "assumptions, propose the smallest sound change, and verify "
                "the final plan against the stated acceptance criteria."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

64,000토큰 한도는 xhigh 또는 max에 대해 Anthropic이 권장하는 시작점이지, 모든 요청에 필요한 조건은 아닙니다. 실제 사용량과 완료 동작을 관찰한 뒤 낮춥니다.

정성적인 차이도 예상해야 합니다. Anthropic에 따르면 Opus 5는 더 긴 결과물을 작성하고, 에이전트 세션 중 진행 상황을 더 자주 설명하며, 서브에이전트에 더 적극적으로 위임하고, 별도 지시 없이도 결과를 검증하는 경향이 있습니다. 이런 동작은 유용할 수 있지만, 더 조용했던 Opus 4.8에 맞춰 만든 에이전트 UI, 로그 파이프라인, 오케스트레이션 계층은 조정이 필요할 수 있습니다.

프로덕션 비용을 좌우하는 세 가지 세부 요소

effort, caching, 속도는 서로 영향을 줍니다. 하나만 따로 최적화하면 나머지 두 요소가 오히려 나빠질 수 있습니다.

캐시된 대화에서는 effort를 일정하게 유지합니다

요청 사이에 output_config.effort를 바꾸면 Anthropic이 렌더링한 프롬프트도 달라지므로, 이후 요청에서 캐시된 프리픽스가 유지되지 않습니다. 하나의 긴 대화에서 effort를 계속 올렸다 내리는 시스템은 기대했던 캐시 절감 효과를 잃을 수 있습니다.

캐시에 의존하는 세션은 시작할 때 effort를 정하고 그대로 유지합니다. 뒤이은 작업에 다른 effort가 필요하면 새 대화로 라우팅하거나, 상향 비용에 캐시 미스를 포함해 받아들입니다.

Opus 5는 캐시 가능한 최소 프롬프트를 Opus 4.8의 1,024토큰에서 512토큰으로 낮췄습니다. 반복 지시가 더 짧아도 캐싱을 활용할 수 있지만, 프롬프트 프리픽스와 effort가 안정적으로 유지되어야 합니다.

Fast mode는 성능이 아니라 지연 시간을 위해 구매합니다

Fast mode는 정상 속도의 약 2.5배이며, 토큰 100만 개당 $10/$50입니다. Opus를 Fable로 바꿔주는 기능은 아닙니다. 고정된 100개 작업 예시에서는 caching이나 재시도를 반영하기도 전에 Opus 비용이 $22.50에서 $45로 올라갑니다.

Fast mode는 Claude API의 리서치 프리뷰입니다. 현재 Amazon Bedrock, Google Cloud, Microsoft Foundry에서는 사용할 수 없습니다. 멀티클라우드 아키텍처라면 모든 환경에서 속도 설정이 모델을 따라갈 것이라고 가정해서는 안 됩니다.

새로운 beta 제어 기능은 beta로 다룹니다

대화 중간 툴 변경 기능을 사용하면 prompt cache를 유지하면서 턴 사이에 툴을 추가하거나 제거할 수 있습니다. 이 기능은 mid-conversation-tool-changes-2026-07-01 beta 헤더를 사용합니다.

자동 폴백은 분류기에 표시된 Opus 5 또는 Fable 5 요청을 차단하지 않고 Anthropic이 권장하는 폴백으로 보낼 수 있습니다. 기본 및 명시적 폴백 목록에는 server-side-fallback-2026-07-01 beta 헤더를 사용합니다.

두 기능 모두 운영 문제를 해결하지만, 하나의 논리적 세션이 할 수 있는 일과 실제로 답변하는 모델을 바꾸기도 합니다. 되돌릴 수 없는 워크플로에서 활성화하기 전에 권한 변경, 실패 처리, 출력 품질을 테스트해야 합니다.

배포 전에 5단계 effort 평가를 실행합니다

effort 선택을 의견이 아닌 라우팅 데이터로 바꾸는 데는 375회 평가면 충분합니다. 대표 작업 25개에 effort 5단계를 적용하고 각 조합을 3번씩 반복합니다.

에이전트는 우연히 한 번 통과했다가 다음 툴 경로에서는 실패할 수 있으므로 반복 실행이 중요합니다. 작업 세트의 구성은 크기보다 더 중요합니다. 일상적인 작업, 알려진 엣지 케이스, 과거에 사람이 수정해야 했던 실패 사례를 포함해야 합니다.

프로덕션에서 프롬프트 캐싱에 의존한다면 이 테스트 중 세션 안에서 effort를 바꾸지 않습니다. 각 단계를 안정적인 대화 설계에서 테스트해야 하며, 그렇지 않으면 캐시 미스가 통제되지 않은 변수가 됩니다.

평가 결과는 일상적인 계정 업무에는 medium이면 충분하고, 예외 처리에는 high가 필요하며, 일부 디버깅 유형에서만 xhigh가 개선을 보이는 식일 수 있습니다. 이 결과는 모든 곳에 xhigh를 쓰라는 뜻이 아닙니다. 경제성이 다른 세 가지 경로를 운영할 근거입니다.

같은 절차로 Fable 5가 가격만큼의 가치가 있는지도 결정할 수 있습니다. 기준에 못 미친 Opus 작업에만 Fable을 추가합니다. 100개 작업 예시에서 Fable이 승인율을 충분히 높여 $22.50의 프리미엄을 상쇄하지 못한다면 Opus를 유지합니다.

안전성 경계는 Fable 5와 다릅니다

Opus 5는 합법적인 보안 업무에서 Fable 5보다 제한이 적지만, 제약 없는 사이버 보안 모델은 아닙니다.

Anthropic에 따르면 Opus 5의 사이버 분류기는 Fable 5보다 약 85% 적게 개입합니다. 소스 코드에서 취약점을 찾을 수 있지만, 안전장치는 바이너리 기반 취약점 스캔, 침투 테스트, 익스플로잇 생성을 차단합니다. 공격적 사이버 보안과 생물학 연구에서는 여전히 Mythos 5보다 뒤에 있습니다.

이 경계는 디버깅 및 보안 에이전트에 중요합니다. 소스 검토는 가능하더라도 이후 익스플로잇 검증 단계는 거부되거나 다른 경로로 라우팅될 수 있습니다. 거부를 예상치 못한 파서 오류가 아니라 처리 가능한 상태로 설계해야 합니다.

Cyber Verification Program은 자격을 갖춘 기업과 연구자에게 보안 제한이 더 적은 버전을 제공합니다. 일반 사용자는 접근 권한을 확인하기 전까지 이 경로를 전제로 프로덕션 워크플로를 설계해서는 안 됩니다.

Anthropic의 내부 행동 감사에서 Opus 5의 전체 misaligned behavior 점수는 2.3으로, 최근 모델 가운데 가장 낮습니다. 이는 Anthropic 자체 테스트 스위트에 대한 증거일 뿐, 승인 절차나 샌드박싱, 최소 권한 툴 접근을 없애도 된다는 허가는 아닙니다.

결론

Claude Opus 5는 단계적 마이그레이션을 거친 뒤 새로운 프리미엄 워크로드와 기존 워크로드 대부분에서 Opus 4.8을 대체해야 합니다. 가격은 같고, effort에 따른 확장성이 더 안정적이며, 여러 중요한 평가에서 Fable 5에 근접합니다.

다만 처리량이 많은 모든 경로에서 Sonnet 5를 대체해서는 안 되며, max를 기본값으로 삼아서도 안 됩니다. 경제적 이점은 라우팅에서 나옵니다. 저렴하면서 승인 가능한 작업에는 Sonnet 또는 낮은 effort, 어려운 일상 업무에는 Opus high, 측정으로 입증된 장기 실행 사례에는 xhigh, Opus의 실패 비용이 크다고 확인된 경우에만 Fable을 사용합니다.

effort 조절 기능의 가치는 이 정책을 명시적으로 만든다는 데 있습니다. 평가 변수로 활용하고, caching이 중요할 때는 일정하게 유지하며, 모든 상향 결정을 이름이 붙은 실패 사례와 연결해야 합니다.

다음 모델 변화도 프로덕션 의사결정으로 정리해 보고 싶으신가요? 뉴스레터를 구독하세요.