AI 모델 비용 줄이는 법 | 기획과 실행을 나누면 왜 비용이 내려갈까요
Anthropic이 값비싼 Claude Fable 5를 모든 작업에 쓰지 말고 플래너로만 쓰라고 권장했어요. 실행은 소형 모델 Sonnet 5에 위임하는 Advisor·Orchestrator 두 패턴과 벤치마크 수치(성능 92%를 비용 63%로 등), 그 배경까지 개발사 관점으로 정리했어요.
“성능 좋은 AI 모델을 쓰긴 써야 하는데, 비용이 부담돼서 고민이신가요?” AI를 실제 업무에 붙이려는 팀이라면 한 번쯤 마주치는 지점이에요. 가장 똑똑한 모델은 결과가 좋지만, 모든 작업에 그 모델을 돌리면 비용이 빠르게 불어나거든요.
이번에 Anthropic이 이 고민에 대한 구체적인 해법을 공식적으로 권장했어요. 핵심은 의외로 단순해요 — 값비싼 대형 모델은 ‘기획·판단’에만 쓰고, 실제 실행은 작은 모델에 넘기라는 것이에요. 어떤 구조인지, 실제로 비용이 얼마나 줄어드는지 개발사 관점에서 차근차근 정리해 볼게요.
1. 대형 AI 모델은 왜 비용이 부담될까요
Anthropic의 최신 모델 Claude Fable 5는 성능이 뛰어나지만, 그만큼 실행 비용이 비싸요. 문제는 실제 업무가 대부분 반복적이고 단순한 작업 + 가끔 나오는 어려운 판단의 조합이라는 점이에요.
단순 작업까지 전부 가장 비싼 모델로 처리하면, 정작 그 모델의 값어치가 필요 없는 부분에도 큰 비용을 쓰게 돼요. 마치 모든 서류 작업에 가장 비싼 전문가를 붙이는 것과 비슷하죠. Anthropic이 내놓은 권장안은 바로 이 낭비 지점을 겨냥해요.
2. Anthropic의 해법 — 대형 모델은 ‘플래너’로만
Anthropic 개발자 팀은 Fable 5를 모든 작업의 실행자로 쓰지 말고, 주로 플래너(기획자)로 쓰라고 권장했어요. 실제 실행은 더 작은 모델에 넘기는 거예요.
이를 위한 구성으로 두 가지 패턴을 제시했는데, 둘 다 큰 모델을 아끼면서도 성능은 크게 잃지 않는 방식이에요. 하나씩 살펴볼게요.
3. Advisor 패턴 — 실행은 소형, 조언만 대형
첫 번째는 Advisor(어드바이저) 패턴이에요. 소형 모델인 Sonnet 5가 실무를 직접 처리하고, 판단이 애매하거나 막힐 때만 Fable 5를 불러 조언을 구하는 구조예요.
개발 벤치마크인 SWE-bench Pro에서 이 조합은 Fable 5를 단독으로 썼을 때의 약 92% 성능을 63% 비용으로 달성했어요. Anthropic에 따르면 이 구성에서 대형 모델 호출은 작업당 한 번 정도예요. 즉, 값비싼 모델은 꼭 필요한 순간에만 최소한으로 부르는 셈이에요.
4. Orchestrator 패턴 — 대형은 지휘, 실행은 나눠서
두 번째는 Orchestrator(오케스트레이터) 패턴이에요. 이번엔 반대로 Fable 5가 플래너가 되어 여러 Sonnet 5 작업자 에이전트에게 일을 분배해요. 큰 모델은 전체를 설계·지휘하고, 실제 실행은 여러 소형 모델이 나눠 맡는 구조죠.
웹 탐색 벤치마크인 BrowseComp에서 이 방식은 성능 96%를 비용 46%로 달성했어요. 성능은 거의 그대로 유지하면서 비용은 절반 이하로 낮춘 셈이에요.
5. 두 패턴의 공통 열쇠 — 캐시로 중복 맥락 줄이기
두 패턴 모두 Claude Managed Agents(관리형 에이전트) 위에서 돌아가요. 여기서 비용을 한 번 더 아끼는 장치가 캐시예요.
각 서브 에이전트가 자체 캐시를 사용해서, 같은 맥락(문맥 정보)을 여러 번 중복으로 처리하는 비용을 줄여요. 여러 에이전트가 협업할 때 흔히 발생하는 ‘같은 배경 설명을 매번 다시 읽는’ 낭비를 막는 셈이에요. 구조를 나누는 것뿐 아니라, 나눈 조각들이 서로 중복 작업을 하지 않도록 설계하는 것까지가 비용 절감의 핵심이에요.
6. Anthropic이 지금 이 팁을 공개한 배경
Anthropic이 자사 비싼 모델의 비용을 아끼는 법을 직접 안내한 데에는 커지는 가격 압박이 있어요.
중국의 오픈소스 모델들이 이미 서구 모델 대비 낮은 가격으로 시장을 파고들고 있고, 새로 나온 GPT-5.6 Sol은 토큰당 단가가 훨씬 저렴하면서 토큰 효율도 더 좋다고 알려져 있어요. 이런 흐름 속에서 “우리 모델은 비싸지만, 이렇게 쓰면 합리적이에요”라는 사용법을 함께 제시한 것으로 볼 수 있어요.
7. 도입 관점에서 무엇을 기억하면 될까요
이번 소식이 던지는 실무적 메시지는 명확해요. AI 도입에서 ‘어떤 모델을 쓰느냐’만큼이나 ‘무엇을 어떤 모델에 맡기느냐’가 실제 비용을 좌우한다는 점이에요.
기획·판단처럼 어려운 부분은 성능 좋은 대형 모델에, 반복 실행처럼 단순한 부분은 소형 모델에 나눠 맡기면 같은 결과를 훨씬 적은 비용으로 낼 수 있어요. 직접 서비스를 만들고 운영해 온 개발사 입장에서 보면, 이런 역할 분리 설계는 특정 모델 하나에 의존하는 것보다 비용과 유연성 모두에서 유리해요. 모델이 바뀌거나 더 싼 대안이 나와도 실행 계층만 갈아끼우면 되니까요.
8. 자주 묻는 질문 (FAQ)
Advisor 패턴과 Orchestrator 패턴, 무엇이 다른가요?
Advisor는 소형 모델이 실무를 맡고 어려울 때만 대형 모델에게 조언을 구하는 구조예요. Orchestrator는 반대로 대형 모델이 기획·분배를 맡고 여러 소형 모델이 실행하는 구조예요. 작업이 대체로 단순하면 Advisor, 복잡한 작업을 여러 갈래로 나눠야 하면 Orchestrator가 어울려요.
성능이 92%, 96%면 나머지는 손해 아닌가요?
벤치마크마다 결과는 다르지만, 비용을 절반 안팎으로 줄이면서 성능은 소폭만 내주는 트레이드오프예요. 정확성이 최우선인 작업과 비용 효율이 중요한 작업을 구분해 설계하면, 대부분의 실무에서는 합리적인 선택이 될 수 있어요.
우리 팀에도 바로 적용할 수 있나요?
핵심은 특정 도구가 아니라 ‘역할을 나누는 설계’ 자체예요. 지금 쓰는 워크플로우에서 어떤 단계가 단순 반복이고 어떤 단계가 어려운 판단인지 구분하는 것부터 시작하면 돼요.
9. 마무리
정리하면, 비싼 AI 모델의 비용 부담은 ‘모델을 바꾸는 것’이 아니라 ‘역할을 나누는 설계’로 풀 수 있다는 게 이번 소식의 핵심이에요. 대형 모델은 기획·판단에, 소형 모델은 반복 실행에 배치하고, 캐시로 중복 맥락까지 줄이면 성능을 크게 잃지 않고도 비용을 절반 수준으로 낮출 수 있어요.
AI 도입을 고민 중이라면 ‘어떤 모델을 쓸까’와 함께 ‘무엇을 어떤 모델에 맡길까’를 같이 설계해 보세요. 도움이 됐다면 나중에 다시 볼 수 있게 저장하거나 동료와 공유해 주세요.
관련해서 함께 보면 좋은 글이에요.