2026년 5월 28일, Anthropic이 Claude Opus 4.8을 공개했습니다. 동시에 Claude Code에는 Dynamic Workflows(리서치 프리뷰)라는 새로운 메커니즘이 도입되었습니다.
이 기사는 단순히 '신기능 목록'을 나열하는 소개 기사로 만들 생각이 아닙니다. Opus 4.8에서 변한 것은 개별 스펙보다도, Anthropic이 어디에 승부수를 던지고 있는가 하는 설계의 무게중심이라고 생각하기 때문입니다. 벤치마크 수치, effort 파라미터, Messages API의 미묘한 변경, 그리고 Dynamic Workflows. 이것들을 별개의 발표로 보면 단편적이지만, 하나의 선으로 연결하면 '대화하는 모델'에서 '완전히 맡길 수 있는 에이전트(Agent)'로 향하는 동일한 방향을 바라보고 있습니다.
그 선을 따라가며, 각각의 기능이 왜 존재하는지, 어떤 트레이드오프 (Trade-off) 위에 성립되어 있는지까지 깊이 파고들어 보겠습니다.
본 기사의 벤치마크 수치는 공식 발표 페이지 및 시스템 카드(System Card), 각종 공개 정보를 바탕으로 하고 있습니다. 공식 페이지에도 비교표의 개요는 있지만, 개별 스코어의 상세 내용은 Claude Opus 4.8 System Card에 맡겨져 있습니다. 수치의 일부는 이차 정보를 포함하며, 공식 측에서 나중에 각주로 스코어를 업데이트하는 경우도 있으므로, 엄격한 검증 용도로는 일차 정보를 확인하시기 바랍니다.
세부적인 이야기에 들어가기 전에, 전체상을 한 단계 높은 관점에서 파악해 두겠습니다. Opus 4.8의 변경 사항은 대체로 다음 4가지로 정리할 수 있습니다.
| 영역 | 변한 점 | 배후에 있는 목적 |
|---|
| 모델의 성격 | 코드의 결함을 놓칠 확률이 이전 세대의 약 1/4로 | 장시간 태스크에서 신뢰할 수 있을 것 |
| ... | | |
가격은 입력 $5 / 출력 $25 (100만 토큰당, Opus 4.7에서 동결). Fast mode는 $10 / $50로, 이는 기존 Fast mode의 약 1/3 가격이 되었습니다. API 식별자는 claude-opus-4-8입니다.
이 표의 오른쪽 열인 '목적'을 모두 합치면 하나의 문장이 됩니다. "인간이 붙어 있지 않아도, 길게 달리고, 스스로 실수를 깨닫고, 비용을 조정하면서, 대규모로 병렬 작동할 수 있는가". Opus 4.8은 이 질문에 대한 답변이라고 읽힙니다.
먼저 벤치마크를 보겠습니다. 다만 숫자의 높고 낮음 그 자체보다, 어느 부분이 성장했고 어느 부분이 성장하지 않았는지라는 패턴에 주목하고자 합니다. 그곳에 개발사의 우선순위가 나타나기 때문입니다.
공개된 주요 스코어를 Opus 4.7과의 대비로 나열해 보겠습니다.
| 벤치마크 | Opus 4.8 | Opus 4.7 | 차이 |
|---|
| SWE-bench Verified | 88.6% | 87.6% | +1.0 |
| ... | | | |
PC 조작 계열인 OSWorld-Verified도 83.4%라는 높은 수준에 있습니다 (이전 세대 대비 수치는 공식 측이 각주로 스코어를 업데이트하고 있어 차이 해석이 갈리므로, 여기서는 절대값만 표시합니다).
이 테이블에는 이해하기 쉬운 이야기가 담겨 있습니다. 에이전트 계열·도구 이용 계열 (SWE-bench Pro, BrowseComp, MCP-Atlas)이 일제히 +5 전후의 큰 성장을 보인 반면, 순수하게 학술적 지식을 묻는 GPQA Diamond는 약간 하락했습니다.
이 '불균형'을 어떻게 읽어야 할까요. 저에게는 이것이 트레이드오프라기보다 우선순위의 표현으로 보입니다. 어디까지나 하나의 해석입니다만, GPQA Diamond는 이미 93~94%라는 천장에 가까운 수치에 도달해 있어, 이곳을 0.6% 끌어올리는 노력보다 '도구를 사용하여 실제 환경에서 길게 일하는 능력' 쪽에 성장 가능성과 가치가 있었다는 사정을 상상할 수 있습니다. 일문일답 식의 박식함이 포화 상태에 이르는 한편, 지금 현장에서 효과적인 것은 'PC를 조작하고, 브라우저를 넘나들며, 외부 도구를 올바르게 호출할 수 있는' 능력이라는 온도감은 숫자 배열과도 일치합니다. 다만 이것은 Anthropic이 명시적으로 배분한 것은 아니며, 어디까지나 결과로부터 역산한 추측이라는 점은 미리 말씀드립니다.
물론 이 해석이 유일한 정답이라고 할 수는 없습니다. GPQA의 미세한 감소는 오차 범위라고 할 수도 있고, 학습 데이터나 RLHF (Reinforcement Learning from Human Feedback)의 부작용일 수도 있습니다. 다만, 성장한 항목들의 면면이 이 정도로 일관적이라면, 우연이라고 치부하기보다는 '의도'를 읽어내는 편이 더 자연스럽게 느껴집니다.
공식적인 증언에 따르면, Online-Mind2Web에서 84%, Legal Agent Benchmark에서 "all-pass 기준(all-pass 기준)으로 처음 10%를 넘긴 첫 번째 모델"이라는 언급이 있었습니다. 후자는 언뜻 보기에 미미한 숫자처럼 보일 수 있지만, "전 과정을 실수 없이 통과하는" 기준으로 측정했을 때 여전히 10%대에 머물고 있다는 사실 그 자체가 롱-런 에이전트(Long-running Agent)의 난이도를 대변합니다.
Opus 4.8에서 개인적으로 가장 중요하다고 느낀 점은 벤치마크 수치가 아니라 다음의 한 문장입니다.
"Opus 4.8은 자신이 작성한 코드의 결함을 지적 없이 통과시켜 버릴 확률이 이전 세대의 약 4분의 1로 줄어들었다."
이는 "코딩 실력이 좋아졌다"는 것과는 다른 축의 이야기입니다. 실력이 좋아졌다는 것은 "정답을 낼 수 있는 확률"을 의미하지만, 여기서 말하는 것은 "자신의 실수를 깨닫고 멈춰 설 수 있는 확률"입니다. 후자는 에이전트로서 장시간 작업을 맡기는 상황에서 결정적인 역할을 합니다.
왜 그럴까요? 단순화된 구체적인 예로 생각해 보겠습니다. 10단계의 작업을 에이전트에게 맡겼을 때, 각 단계에서 5%의 확률로 오류를 "맞다"고 믿고 다음으로 진행하는 모델이 있다고 가정해 봅시다 (설명을 돕기 위해 각 단계의 실패는 독립적이라고 가정합니다. 실제 에이전트의 실패는 이전의 오류를 끌어오기 때문에 독립적이지 않지만, 감을 잡기에는 충분합니다). 10단계를 통과할 때, 한 번도 속임수 없이 완주할 수 있는 확률은 약 $0.95^{10} \approx 60%$까지 떨어집니다. 이 "간과율(miss rate)"이 4분의 1(5% $\rightarrow$ 1.25% 정도)로 줄어든다면, 완주율은 $0.9875^{10} \approx 88%$까지 치솟습니다. 사슬이 길어질수록 단 한 곳의 신뢰성 차이가 엄청난 결과로 이어지는 것입니다.
이것이 Dynamic Workflows(동적 워크플로우)의 전제 조건이 되고 있다는 것이 저의 견해입니다. 수백 개의 서브 에이전트(Sub-agent)를 병렬로 실행하고 결과를 통합하는 메커니즘은, 개별 에이전트가 "자신의 출력을 의심할 수 있음"을 토대로 합니다. 도중에 누군가가 아무렇지 않게 거짓 성공 보고를 올리는 집단에게 750,000행의 코드 이식을 맡길 수는 없습니다.
공식적으로도 스태프 엔지니어의 증언을 통해 "계획이 앞뒤가 맞지 않으면 거부해 온다", "자신의 실수를 스스로 잡아낸다"는 특성이 강조되었습니다. 똑똑함을 자랑하는 것이 아니라, 신뢰성에 지면을 할애하고 있다는 점에 이번 릴리스의 성격이 드러나 있습니다.
Anthropic은 이와 함께 얼라이먼트(Alignment, 정렬) 평가에 대해서도 언급하며, 친사회적(prosocial) 특성에서 과거 최고치를 기록했고, 미스얼라인(misaligned)된 행동의 발생률이 이전 세대보다 대폭 낮아졌다고 밝혔습니다. "정직함"과 "안전성"을 별개의 문제가 아니라, 동일한 신뢰성이라는 축으로 다루고 있다는 점이 일관적입니다.
Opus 4.8에서는 응답 품질과 속도 및 레이트 소비(rate consumption) 사이의 균형을 사용자가 선택할 수 있는 effort라는 제어 기능이 전면에 등장했습니다. 설정은 high(기본값), xhigh, max의 3단계입니다.
여기서 흥미로운 점은 기본값의 이동입니다. Opus 4.7의 기본값은 xhigh에 해당했으나, 4.8의 기본값은 high로 낮아졌습니다. 그럼에도 불구하고 공식 측은 "코딩 태스크에서 4.8의 high는 4.7의 기본값과 거의 동일한 토큰 수를 사용하면서도 성능은 더 뛰어나다"라고 설명합니다.
이것은 무엇을 의미할까요? 동일한 예산(토큰 수)으로 더 좋은 결과를 낼 수 있게 되었다는 뜻입니다. 다시 말해, 효율이 높아진 만큼을 "기본값을 가볍게 만드는" 방향으로 사용하고, 무거운 처리가 필요할 때만 사용자가 xhigh / max로 끌어올리는 설계로 전환한 것입니다.
왜 이런 설계인지 생각해보면 시사하는 바가 있습니다. LLM의 추론 비용은 결국 "얼마나 많은 생각 시간(토큰)을 사용하는가"에 비례합니다. 기존에는 모델이 일률적으로 "전력을 다해 생각"하거나 개발사가 정한 고정값으로 움직였습니다. effort는 그 사고량을 사용자 측에서 조절할 수 있는 수도꼭지로 만든 것입니다.
실무에서의 활용법은 대략 다음과 같이 정리할 수 있습니다.
high (기본값): 일상적인 코딩, 리뷰, 조사. 속도와 비용의 균형이 좋음
xhigh: 어려운 설계 판단, 장시간 실행되는 워크플로우, 단번에 높은 정밀도를 내고 싶을 때
max: 토큰을 아끼지 않고 최상의 결과를 추구해야 하는 국면. 난제의 마지막 마무리
여기서 주의할 점은 effort가 "항상 높다고 좋은 것"은 아니라는 점입니다. 간단한 태스크에 max를 사용하면 얻을 수 있는 품질 차이는 미미한데 비용과 레이트 소비만 늘어납니다. 수도꼭지인 이상, 계속 틀어놓는 것은 낭비입니다. 태스크의 난이도에 대해 필요 충분한 effort를 선택하는 운영 판단 자체가 앞으로의 비용 관리의 일부가 될 것이라고 느낍니다.
API에서 이행할 경우에는 사고(thinking)와 관련된 사양 변경에도 주목해야 합니다. 공식 문서에 따르면, Opus 4.8은 모델이 사고량(thinking amount)을 적응적으로 결정하는 방식을 전제로 하고 있으며, 기존 방식처럼 명시적인 thinking budget을 지정하거나 temperature / top_p / top_k를 기본값 이외로 지정하는 것이 허용되지 않는 경우가 있다고 합니다. 이전 세대용으로 만들어둔 요청을 그대로 던지면 거부될 수 있으므로, 이행 시에는 파라미터 취급 방식을 공식 사양에서 확인해 두는 것이 안전합니다. 컨텍스트는 입력 1M 토큰, 최대 출력 128K 토큰으로 길어서, 장시간 에이전트(Agent) 실행을 뒷받침하는 토대가 됩니다.
화려하지는 않지만, 에이전트 개발자에게 실질적으로 유효한 변화는 Messages API의 변경입니다. Opus 4.8에서는 system 엔트리를 messages 배열 안에 배치할 수 있게 되었습니다.
공식 설명은 다음과 같습니다.
개발자는 프롬프트 캐시(Prompt Cache)를 깨뜨리지 않고, 사용자 턴(user turn)을 거치지 않고도 태스크 도중에 Claude에 대한 지시를 업데이트할 수 있다. 하네스(Harness) 내에서 에이전트 실행 중에 권한, 토큰 예산, 환경 컨텍스트를 업데이트하는 용도로 사용할 수 있다.
이것이 왜 중요할까요? 프롬프트 캐시의 메커니즘을 떠올려 보면 이해가 쉽습니다. LLM API는 동일한 서두(Prefix)를 재사용할 때 캐시를 적용하여 비용과 레이턴시(Latency)를 낮춥니다. 그런데 기존에는 system 명령이 요청의 맨 앞에 고정되어 있었습니다. 중간에 지시를 교체하려고 하면, 맨 앞부분이 바뀐다는 것은 곧 캐시가 통째로 무효화된다는 문제를 야기했습니다.
장시간 구동되는 에이전트의 경우, 이것은 은근히 뼈아픈 제약이었습니다. "여기서부터는 쓰기 권한을 제거한다", "남은 토큰 예산은 이만큼이다", "환경이 바뀌었으니 이 전제를 따른다"와 같은 업데이트를 실행 중에 끼워 넣고 싶은 상황은 빈번하게 발생합니다. 이를 매번 캐시를 버려가며 수행하는 것은 비용 측면에서도, 지연 측면에서도 수지가 맞지 않습니다.
messages 배열 안에 system 엔트리를 둘 수 있다는 것은, 대화 도중에 "여기서부터 지시가 바뀝니다"라는 표식을 캐시를 보존한 채로 삽입할 수 있다는 뜻입니다. 언뜻 보기에는 니치(Niche)한 변경 같지만, 이는 후술할 Dynamic Workflows와 같이 "실행 중에 상황이 동적으로 변한다"는 전제의 메커니즘을 현실적인 비용으로 돌리기 위한 토대가 됩니다. 단일 기능이 아니라, 에코시스템 전체를 지탱하는 배관(piping)이라고 이해하면 그 위치가 보입니다.
단, 아무 곳에나 자유롭게 둘 수 있는 것은 아닙니다. 배치에는 규칙(예를 들어 사용자 턴 직후에 배치해야 한다는 제약 등)이 있으므로, 구현 시에는 공식 문서에서 허용되는 위치를 확인한 후組み込む(구현)하는 것을 권장합니다. 사양을 잘못 파악하면 기대했던 캐시 보존이 작동하지 않거나 요청이 거부될 수 있습니다.
이 부분이 이번의 핵심입니다. Dynamic Workflows는 Claude가 복잡하고 다단계인 태스크를 여러 개의 병렬 서브 에이전트(Sub-agent)를 오케스트레이션(Orchestration)함으로써 일괄적으로 처리하는 메커니즘입니다. Claude Code(CLI · Desktop · VS Code 확장)와 Claude API를 통해 리서치 프리뷰(Research Preview)로 제공되고 있습니다.
업무 도입을 검토할 경우 제공 범위에 주의가 필요합니다. 이용은 Max · Team · Enterprise와 같은 상위 플랜이 전제되며, Enterprise에서는 관리자가 활성화하기 전까지는 꺼져 있는 등 조직 측의 설정이 관여합니다. API에 대해서도 Anthropic 직계 외에 Amazon Bedrock · Google Vertex AI · Microsoft Foundry를 경유한 이용이 상정되어 있습니다. 프리뷰 단계이므로 제공 조건은 변할 수 있으니, 도입 전에 최신 공식 정보로 대상 플랜과 활성화 절차를 확인하시기 바랍니다.
공식 설명을 분해하면 대체로 다음과 같은 흐름이 됩니다.
- Claude가 프롬프트를 분석하여 실행 계획을 동적으로 수립한다.
- 작업을 여러 개의 서브 태스크(Sub-task)로 분해하여 병렬의 서브 에이전트에게 할당한다.
- 각 에이전트가 독립적인 관점에서 문제에 접근한다.
- 특정 결과에 대해 다른 에이전트가 반증을 시도한다 (Adversarial한 검증).
- 답이 수렴할 때까지 반복한다.
- 통합하기 전에 결과를 검증 단계에 거친다.
주목해야 할 점은 네 번째 단계인 「반증을 시도함 (Attempting to falsify)」입니다. 이는 단순한 병렬화 (Parallelization, 같은 일을 나누어 하는 것)가 아니라, 의도적으로 부정하는 역할을 별도의 에이전트 (Agent)에게 맡기는 설계입니다. 하나의 에이전트가 "버그를 발견했다"라고 보고하면, 다른 에이전트가 "그것이 정말 버그인가, 재현 가능한가"를 의심합니다. 다수결이나 적대적 리뷰 (Adversarial review)를 거침으로써, 그럴듯해 보이기만 하는 오류가 최종 결과물에 섞여 들어가는 것을 방지합니다.
앞서 언급한 「정직함 (Honesty)」의 개선이 여기서 빛을 발합니다. 검증역이 쉽게 영합하지 않고 자신의 불확실성을 솔직하게 나타낼 수 있기 때문에, 이러한 상호 체크 (Mutual check)가 의미를 갖습니다. 동료의 출력에 휩쓸려 모두가 똑같은 실수를 하며 고개를 끄덕이는 식이라면, 몇 번을 검증해도 의미가 없습니다.
기존의 병렬 처리나 멀티 에이전트 (Multi-agent) 방식은 보통 처리 형태를 인간이 미리 결정해 두는 방식이었습니다. "이 세 가지를 병렬로 실행"이라고 고정적으로 작성하는 방식입니다. Dynamic Workflows의 「동적 (Dynamic)」이라는 표현은, 그 형태 (무엇을 병렬로 하고, 무엇을 직렬로 하며, 몇 개를 생성할지)를 Claude가 태스크 (Task)를 확인한 후 스스로 결정한다는 점을 가리킵니다.
이 차이는 매우 큽니다. 사전에 작업 형태를 알 수 없는 태스크――예를 들어 "이 리포지토리 (Repository)의 버그를 찾아내라"와 같이, 실행해 보기 전까지는 몇 개가 발견될지 알 수 없는 업무――의 경우, 고정적인 계획으로는 놓치는 부분이 생깁니다. 동적으로 "발견된 개수만큼 검증 에이전트를 생성"할 수 있어야 비로소 규모에 따른 망라 (Coverage)가 가능해집니다.
실운용에서 효과적인 것은 중간 과정의 저장입니다. 공식 문서에 따르면 "실행 진행에 따라 상태가 저장되므로, 중단된 작업 (Job)은 처음부터 다시 시작하는 것이 아니라 멈춘 지점부터 재개한다"라고 합니다.
수백 개의 에이전트가 몇 시간에서 며칠 동안 실행되는 처리에서는, 도중에 연결이 끊기거나 에러로 인해 멈추는 일이 피할 수 없습니다. 그때마다 처음부터 다시 시작한다면 대규모 태스크는 현실적으로 운영할 수 없습니다. 체크포인트 (Checkpoint)와 재개 기능은 장시간 오케스트레이션 (Orchestration)을 「실용」의 영역으로 올리기 위한 필수 요건이며, 이것이 프리뷰 (Preview) 단계부터 포함되어 있다는 점에서 진정성이 느껴집니다.
설득력 있는 실례로, Bun의 메인테이너 (Maintainer)인 Jarred Sumner 씨가 Bun을 Zig에서 Rust로 이식하는 데 Dynamic Workflows를 사용한 사례가 소개되어 있습니다. 결과는 기존 테스트 스위트 (Test suite)의 99.8%가 통과된 상태로, 약 750,000행의 Rust 코드를 11일 만에 완료했다는 것입니다.
이 숫자의 의미를 곱씹어 보겠습니다. 75만 행 규모의 언어 이식은 통상적으로 상당한 기간과 인력이 소요되는 작업입니다. 그것을 11일 만에 해냈습니다. 공식 측에서 "분기별로 계획했던 작업이 며칠 만에 끝난다"라고 표현하는 것은 바로 이런 종류의 사례를 의미합니다.
다만, 이를 "누구나 11일이면 할 수 있다"라고 해석하는 것은 성급하다고 생각합니다. Bun처럼 명확한 테스트 스위트가 존재하고, 이식 대상과 원본 간의 대응이 비교적 구조적으로 이루어질 수 있다는 조건이 갖춰졌기에 가능한 숫자이기도 합니다. "99.8% 통과"의 이면에는 남은 0.2%를 채우는 인간의 판단과 테스트 자체의 품질이라는 전제가 있습니다. 사례의 놀라움은 올바르게 받아들이되, 자신의 태스크가 이 조건에 얼마나 근접해 있는지는 냉정하게 살펴볼 필요가 있습니다.
마지막으로 간과해서는 안 될 주의사항입니다. 공식은 명확하게 경고하고 있습니다.
Dynamic Workflows는 일반적인 Claude Code 세션보다 훨씬 더 많은 토큰 (Token)을 소비할 가능성이 있다.
이는 당연한 결과입니다. 수백 개의 서브 에이전트 (Sub-agent)가 각각 사고하고, 여기에 검증역이 반증을 위해 추가로 사고하기 때문에, 토큰 소비량은 일반적인 대화 1회와는 차원이 다릅니다. effort 파라미터와 마찬가지로, "강력하니까 항상 쓰는 것"이 아니라 "규모와 난이도가 부합할 때 사용하는" 도구입니다.
여기서 앞서 말한 effort나 Fast mode 이야기와 연결됩니다. 주의할 점은 Fast mode가 결코 "저렴한" 것이 아니라는 점입니다. 입력 $10 / 출력 $50으로, 표준 요금($5 / $25)의 두 배 단가이며, 어디까지나 기존 Fast mode보다 3분의 1로 낮아졌다는 뜻입니다. 속도를 돈으로 사는 옵션이 현실적인 가격대로 내려왔다고 이해하는 것이 정확합니다. 효율화 (동일 예산 내 고품질), 속도 옵션의 저렴화 (Fast mode 가격 인하), 소비 제어 (effort)――이것들은 별개의 대책처럼 보이지만, 「대량으로 병렬 실행하는 시대」를 경제적으로 성립시키기 위한 포석으로서 일렬로 늘어서 있습니다.
지금까지 개별적으로 살펴본 기능들을 첫 번째 질문으로 돌아가 다시 하나로 묶어보겠습니다.
- 정직함의 향상: 긴 체인(Chain)에서도 신뢰를 유지할 수 있는 에이전트의 토대
- effort 파라미터: 사고량 = 비용을 사용자가 제어하는 수도꼭지
- Messages API의 system 엔트리: 실행 중인 지시사항 업데이트를 캐시를 깨뜨리지 않고 수행하는 배관
- Dynamic Workflows: 그 위에서 수백 개의 에이전트를 동적으로 오케스트레이션 (Orchestration)
- Fast mode 가격 인하: 대량 소비를 전제로 한 사용 방식에 대한 경제적 뒷받침
이것들은 별개의 발표가 아니라, "인간이 붙어 있지 않아도, 길게·대규모로·스스로 오류를 수정하며 달리는 에이전트"라는 동일한 목적지를 향하는 부품들처럼 보입니다. 순수한 능력 향상 그 자체는 공식 측에서 "겸손하지만 확실한 개선 (modest but tangible)"이라고 표현할 정도로, 세대를 단번에 뛰어넘는 도약은 아닙니다. 그럼에도 함께 제공된 기능군을 종합해 보면, 평가의 무게 중심이 "얼마나 똑똑한가"에서 "얼마나 맡길 수 있는가"로 조금씩 이동하고 있다는 흐름을 느낄 수 있는 릴리스라고 저는 받아들였습니다. 물론 이것은 하나의 해석일 뿐이며, 단순히 순리적인 마이너 업데이트 (Minor Update)로 보는 관점도 충분히 가능하다고 생각합니다.
마지막으로, 현장에서의 활용 방법을 정리해 둡니다. 어디까지나 하나의 가이드라인으로 읽어 주시기 바랍니다.
일상적인 코딩 및 리뷰: 기본값인 high로도 충분한 경우가 많습니다. 우선 여기서 시작하여, 부족함을 느낄 때 높이는 운영 방식이 낭비가 적다고 생각합니다 -
어려운 설계 판단이나 장시간 태스크: xhigh를 검토합니다. 단 한 번의 정밀도가 후속 공정의 재작업 비용보다 큰 가치를 갖는 상황에서 효과적입니다 -
Dynamic Workflows: 대규모 이식, 리포지토리(Repository) 전체 감사, 포괄적인 검증 등 "규모 그 자체가 과제"인 태스크용입니다. 토큰 소비가 차원이 다르게 늘어난다는 점을 고려하여, 작게 테스트한 후 확장하는 것이 안전합니다 -
비용 감각: effort도 Workflows도 "강력함 = 상시 사용해야 함"을 의미하지 않습니다. 태스크의 규모와 난이도에 효과가 부합하는지를 매번 판단하는 자세가 결국 가장 효율적이라고 생각합니다
새로운 모델이 나올 때마다 벤치마크(Benchmark) 수치를 쫓기 쉽지만, Opus 4.8에 대해서는 "숫자 이면에서 어떤 사용법을 상정하고 있는가"를 읽어내는 것이 실제 가치에 더 가까워지는 길이라는 생각이 듭니다.
