2026년 11월 9일 Anthropic이 Claude Fable 5.2와 Mythos 5.2를 공개했습니다. 고난도 추론과 장시간 Agent 작업을 위한 선택지가 늘었고 표준 API 토큰 단가도 낮아졌습니다. 문서 분석, 소프트웨어 유지보수, 조사 업무를 운영하는 기업이 확인할 질문은 검수를 통과하는 결과물을 실제로 더 저렴하게 얻을 수 있느냐는 것입니다.
판단할 사항은 세 가지입니다. 새 모델이 필요한 업무, 기존 Agent의 이전 비용, 그리고 데이터 처리 조건입니다. 이 글은 11월 10일 확인 가능한 자료를 바탕으로 제품 사양과 도입 제안을 구분합니다. 공급업체 시연을 독립적인 성능 실측으로 취급하지 않습니다.
1. 접근 조건: Fable과 Mythos의 이용 자격을 구분합니다
Anthropic 발표에 따르면 두 제품은 같은 기반 모델을 사용합니다. Fable에는 사이버 보안 및 생물학 분야의 악용을 막는 강화된 보호 조치가 적용되며, Mythos는 검증 프로그램을 거쳐야 이용할 수 있습니다. 기업 유료 계정만으로 두 이름을 자유롭게 바꿔 쓸 수 있다는 뜻은 아닙니다.
공개된 100만 토큰 컨텍스트와 최대 12만 8천 토큰 출력은 한 작업에 넣을 수 있는 정보량을 늘립니다. 모든 문서를 정확히 이해하거나 장시간 작업을 끝까지 올바르게 수행한다는 보장은 아닙니다. 공급업체가 설명한 개선은 자체 문서, 저장소, 검수 기준으로 확인해야 합니다.
AWS도 Amazon Bedrock과 Claude Platform on AWS에서의 제공을 발표했습니다. 실제 리전, 계정, 계약 조건은 따로 확인해야 합니다. 🔗클라우드와 온프레미스의 선택 기준에 따라 데이터 흐름을 정리하면 외부 모델에 맡길 업무 범위를 판단하기 쉽습니다.
더 강한 모델이 필요한 병목부터 찾습니다
조달 분석Agent가 계약 첨부 문서의 제한을 놓치는 상황을 가정해 보겠습니다. 자료가 모델에 전달되지 않았거나, 검색이 필요한 문단을 찾지 못했거나, 최종 답변에서 대조 절차가 빠졌을 수 있습니다. 원인마다 필요한 조치가 다릅니다. 입력 부족은 모델 업그레이드만으로 해결하기 어렵습니다. 자료와 절차가 갖춰졌는데도 문서 간 모순을 처리하지 못하는 사례가 더 유용한 비교 대상입니다.
최근 실패 사례를 모아 자료 누락, 도구 장애, 추론 오류, 불명확한 합격 기준으로 나눠 봅니다. 모든 실패를 모델 능력 탓으로 돌리기보다 도입 후 개선을 확인할 수 있는 병목을 찾기 위해서입니다. 구매 이유와 실제 결과를 대조할 근거를 남겨야 합니다.
2. 단가: 20% 인하와 전체 업무 비용을 나누어 봅니다
Claude API 릴리스 노트에 기재된 표준 가격입니다. 단위는 100만 토큰당 미 달러이며 캐시, 배치, 빠른 모드, 플랫폼 및 기타 추가 요금은 제외합니다.
| 모델 | 입력 가격 | 출력 가격 |
|---|---|---|
| Claude Fable 5.1 | US$10 | US$50 |
| Claude Fable 5.2 | US$8 | US$40 |
공개 가격으로 계산하면 입력과 출력 단가가 각각 20% 낮아졌습니다. 과금 입력 100만 토큰과 과금 출력 20만 토큰을 정확히 사용하는 예시에서는 토큰 요금이 20달러에서 16달러로 줄어듭니다. 사용량을 고정한 계산이며 실측이나 모든 기업 업무에서 4달러가 절약된다는 예측은 아닙니다.
계획, 재시도, 병렬 작업이 늘면 사용량도 달라집니다. 반대로 사람의 재작업을 줄이면 토큰 비용이 높아도 경제적일 수 있습니다. API, 도구, 실행 환경, 사람의 검토 비용을 합산한 뒤 검수를 통과한 작업 수로 나누어 ‘합격 결과물당 비용’을 계산해야 합니다.
연동 구조를 검토할 때 🔗AI-Stack 솔루션을 참고해 모델 접속, 실행 기반, 기존 시스템의 역할을 나눌 수 있습니다. 플랫폼 이름만으로 품질 향상이나 비용 절감을 보장할 수는 없습니다.
청구 금액과 합격 건수를 함께 봅니다
도구, 실행 환경, 사람의 확인까지 포함한 가상의 시험을 보겠습니다. 기존 방식이 120달러로 40건을 통과시켰다면 건당 3달러입니다. 후보 방식이 160달러로 64건을 통과시켰다면 건당 2.5달러입니다. 전체 지출은 늘어도 합격 결과물당 비용은 내려갑니다. 계산법을 설명하는 예시이며 Fable의 실측이 아닙니다. 난이도와 합격 기준이 같아야 비교가 의미 있습니다.
예산 검토에서는 직접 서비스 요금, 검토와 재작업 시간, 미완료 업무의 지연을 구분합니다. 절약한 시간이 곧바로 인건비 절감액이 되는 것은 아닙니다. 더 많은 업무를 처리할 여력이 될 수도 있습니다. 기대하는 이익을 먼저 명시해야 기술 개선을 이미 실현된 재무 절감으로 과장하지 않습니다.
3. 비교 기준: 기존 Opus 업무부터 평가합니다
새 버전 안내는 대부분의 업무를 최신 Opus로 시작하고, 더 높은 추론 설정에서도 자체 평가 기준을 충족하지 못할 때 Fable 5.2를 검토하도록 권합니다.
기업도 이미 검수를 통과하는 흐름을 기준으로 유지하고 어려운 사례를 비교하는 것이 좋습니다. 여러 문서의 모순 찾기, 코드 수정 후 테스트 완성, 출처를 추적할 수 있는 조사 자료 작성처럼 실제 인력이 많이 드는 일을 고릅니다. 편리한 질문에 매끄럽게 답하는지만 보아서는 구매 판단이 어렵습니다.
입력 자료, 도구 권한, 합격 기준을 동일하게 두고 완료율, 사람의 수정 시간, 합격 결과물당 비용을 기록합니다. 새 모델에만 추가 도구와 정보를 주면 개선 원인을 가리기 어렵습니다. 🔗MLOps의 관리 방식으로 버전과 평가 조건을 남기면 재현과 복귀가 쉬워집니다.
직접 확인할 수 있는 결과물이 나오는 업무를 고릅니다
문서 비교에는 차이마다 페이지와 인용을 요구합니다. 소프트웨어 유지보수에는 변경 사항, 테스트 결과, 알려진 제약을 요구합니다. 조사 업무에서는 확인된 사실, 추론, 미확인 사항을 구분합니다. Agent에게 끝났다고 생각하는지 묻기보다 결과물을 직접 점검하는 편이 판단하기 쉽습니다.
바꾸지 않는 대조군도 남겨야 합니다. 고정 형식 추출이 안정적으로 합격한다면 새 버전이 나왔다는 이유만으로 교체할 필요는 없습니다. 어려운 사례의 한 유형부터 후보 모델로 보내 실제 개선을 확인합니다. 단계적 도입은 효과의 범위를 드러내고, 성과가 나빠질 때 기존 절차로 돌아가기 쉽게 해 줍니다.
4. 이전 작업: 재시도와 중간 복귀를 따로 시험합니다
모델 ID 변경만으로 이전이 끝나지는 않습니다. 이전 가이드는 직접 API 요청을 만드는 코드가 과거 대화, 시스템 지시, 도구를 변경한 뒤 이전 접두부에 연결된 thinking 블록을 다시 보내면 400 오류가 발생할 수 있다고 설명합니다. 오류를 없애려고 실행 상태를 버리기 전에 실제 요청 생성 과정을 확인해야 합니다.
모델 간 전환에도 방향이 있습니다. 모든 이전 모델이 Fable 5.2의 thinking 블록을 읽을 수 있는 것은 아닙니다. 복귀 요청이 성공해도 추론 상태까지 온전히 이어졌다고 볼 수 없습니다.
정상 완료, 재시도, 다른 모델로의 복귀를 분리해 시험합니다. 각 경로에는 읽을 수 있는 작업 요약, 도구 실행 이력, 체크포인트가 필요합니다. 🔗TaaS 테스트 서비스 접근법은 반복 평가에 참고할 수 있지만 특정 플랫폼이 해당 모델을 제공하거나 호환성을 보장한다는 주장은 아닙니다.
실패할 때 넘겨야 할 것은 업무 상태입니다
다시 시작할 수 있는 업무는 확인한 자료, 끝낸 단계, 남은 질문, 이미 실행한 외부 동작을 설명할 수 있어야 합니다. 변경을 제출한 직후 연결이 끊겼다면 재시도에서 그 동작을 알아보고 이중 제출을 피해야 합니다. 모델이 이전 시도를 기억할 것이라는 기대가 아니라 업무 흐름의 기록이 필요합니다.
이전 시험에서는 대표 작업 도중 도구 장애, 시간 초과, 모델 복귀를 발생시켜 봅니다. HTTP 성공 여부뿐 아니라 재개한 결과물, 추가 비용, 동작 중복을 확인합니다. 대체 모델에 읽을 수 있는 요약을 넘긴다면 필요한 항목을 정의해야 합니다. 원래 모델의 내부 상태가 전부 전달된다고 가정하면 안 됩니다.
5. 데이터 조건: 무보관 적용 여부를 플랫폼별로 확인합니다
Fable 5.2 모델 문서는 30일 데이터 보관을 요구하며 무보관에는 Anthropic의 명시적 허가가 필요하다고 안내합니다. AWS는 별도로 Enterprise Frontier Safeguards가 제공되기 전까지 자격을 갖춘 고객에게 무보관 이용이 가능하다고 설명합니다.
플랫폼과 자격에 따라 다른 조건을 모든 기업에 적용되는 예외로 합쳐 해석하면 안 됩니다. 조달, 보안, 데이터 담당자가 실제 계정과 리전, 보관 범위, 계약상 예외를 확인해야 합니다. 조건이 정해지지 않았다면 합성 데이터나 비식별 데이터로 흐름부터 검증합니다. 시험 성공과 데이터 처리 승인은 별개입니다.
공급업체 보관 조건과 자체 기록을 나눕니다
공급업체의 보관 조건은 전체 데이터 흐름 중 일부입니다. 자체 시스템에는 검색 문서, 도구 응답, 실행 로그, 검토 메모가 남을 수 있습니다. 특정 플랫폼의 무보관 자격을 얻어도 자체 환경에 민감 자료가 남지 않는다는 증거는 아닙니다. 반대로 추적 가능성을 확보하려고 모든 원문을 무기한 보관해야 하는 것도 아닙니다.
입력, 외부 서비스, 로그, 결과물의 흐름을 그리고 저장 위치, 열람 역할, 삭제 방법을 적어 계약과 대조합니다. 그러면 모델을 시험할 수 있는지와 실제 업무 데이터를 넣어도 되는지를 나눠 판단할 수 있습니다. 기능 시험이 끝난 뒤에야 조달 또는 데이터 조건의 미해결 사항을 발견하는 일을 줄일 수 있습니다.
6. 장시간 작업 검수: 예산·권한·결과물을 함께 시험합니다
다음 세 단계는 이 글의 도입 제안이며 모델 벤치마크 결과가 아닙니다.
- 대표 업무와 합격 결과물을 고정합니다. 코드 변경에는 테스트 증거, 조사에는 원출처, 문서 분석에는 근거 위치를 요구합니다.
- 비용, 실행 시간, 도구 호출 수에 상한을 둡니다. 중요한 쓰기나 외부 작업 전에 사람의 확인을 넣고 중지와 재개도 시험합니다.
- 성공뿐 아니라 실패와 거부도 집계합니다. 어려운 사례나 검토 인건비를 빼지 않은 상태에서 합격 결과물당 비용을 계산합니다.
자체 인프라와 외부 API를 함께 쓰는 경우에는 자원과 비용을 나눠 기록해야 합니다. 🔗GPU 자원 관리의 용량 및 스케줄링 개념은 자체 환경에 도움이 되지만 GPU를 늘린다고 외부 API의 토큰 단가가 직접 낮아지지는 않습니다.
시험 전에 실패 기준을 정합니다
계약 요약은 읽기 좋다는 이유만으로 합격하지 않습니다. 반드시 포함할 조항, 인용이 가리킬 위치, 첨부 문서가 빠졌을 때의 보고 방법을 정합니다. 담당자들이 같은 기준으로 검토하고 수정 이유를 남기면 모델의 누락과 자료 부족, 불명확한 요청을 구분하기 쉽습니다.
장시간 작업에는 단계별 중지 조건도 필요합니다. 도구 장애가 반복되거나 예산이 거의 소진되거나 핵심 자료가 없다면 완료한 부분과 남은 문제를 돌려주는 편이 무한 재시도보다 나을 수 있습니다. 상한은 해당 업무가 감수할 수 있는 범위에서 정해야 합니다. 시연의 설정을 전사 공통 기준으로 복사해서는 안 됩니다.
7. 결론: 확대 도입은 세 가지 결과로 결정합니다
Fable 5.2는 기존 모델이 어려워하는 업무에서 시험할 가치가 있는 선택지입니다. 어려운 작업의 합격률이 높아지는지, 합격 결과물당 비용이 합리적인지, 데이터 및 복귀 조건을 받아들일 수 있는지를 확인한 뒤 사용을 확대해야 합니다.
단가 인하는 관심을 가질 이유입니다. 예산을 늘릴 이유는 안정적인 결과물입니다. 기존 모델이 충분한 업무는 유지하고 일부 어려운 사례만 상위 모델로 보내는 것도 합리적입니다.
기업 AI 도입과 평가에 관한 후속 분석은 AI-Stack 블로그를 구독해 확인하세요.
나중에 다시 검토할 수 있는 결정 기록을 남깁니다
평가한 업무, 모델과 설정, 자료 버전, 성공 및 실패 사례, 사람의 수정 시간, 비용 계산 방법을 보관합니다. 사용량이 늘고 약관이 바뀌고 업무가 어려워졌을 때 어떤 가정을 다시 시험할지 알 수 있습니다. 지난번에 더 좋아 보였다는 기억만으로 예산 확대를 정당화하기는 어렵습니다.
도입 범위는 제한적이어도 됩니다. 반복 업무는 기존 방식에 두고 어려운 사례의 상위 모델 전환 조건을 정해 품질과 지출을 주기적으로 확인합니다. 조달, 기술, 업무 담당자가 같은 결과물을 기준으로 이야기할 수 있어야 합니다. 추가한 절차의 이유를 설명할 수 있는 안정적인 업무 운영이 목표입니다.
