
Claude Opus 4.8 출시 ─ 내 코드의 허점을 놓치지 않게 된 AI에게 진심으로 감탄한 이야기
요약
Anthropic의 Claude Opus 4.8 출시 소식과 주요 업데이트 내용을 다룹니다. 이전 버전 대비 향상된 코딩 성능과 에이전트형 작업 능력, 그리고 정직함 강화 및 effort 제어와 같은 실무적 변화를 분석합니다.
핵심 포인트
- SWE-bench Pro 기준 69.2%의 높은 코딩 성능 달성
- effort 제어 및 dynamic workflows 등 실무적 기능 강화
- 단순 성능 향상을 넘어 신뢰할 수 있는 작업 방식으로 진화
- GPT-5.5, Gemini 3.1 Pro 등 경쟁 모델과의 성능 비교
이 기사의 대상 독자
- AI 코딩 지원을 일상적으로 사용하며, 최신 모델의 차이점이 궁금한 사람
- "또 마이너 업데이트겠지"라고 생각하면서도, 만일을 위해 내용을 확인하고 싶은 사람
- effort 제어(effort control)나 dynamic workflows 등, 신기능의 활용법을 실무적인 관점에서 알고 싶은 사람
- 벤치마크(Benchmark) 수치뿐만 아니라 "그래서 결국 뭐가 좋은 거야?"를 한국어로 읽고 싶은 사람
이 기사를 통해 얻을 수 있는 것
- Claude Opus 4.8이 Opus 4.7에서 무엇을 바꾸었는지에 대한 전체상
- 핵심 기능(정직함의 강화·effort 제어·dynamic workflows)의 의미와 활용 구분
- 가격·속도·API의 실무적 임팩트
- 사용을 시작할 때 빠지기 쉬운 함정과 대처법
이 기사에서 다루지 않는 것
- 타사 모델과의 우열을 단정 짓는 랭킹 (벤치마크는 출처를 명시하여 소개하는 것에 그침)
- Claude Mythos 계열의 상세 내용 (일반 제공 전이므로 언급하는 정도에 그침)
- 프롬프트 엔지니어링 (Prompt Engineering)의 일반론
아침에 평소처럼 RTX5090을 장착한 Windows PC 앞에 앉아 코딩 지원 모델 선택지를 살펴보고 있는데, 낯선 이름이 늘어나 있었다. Claude Opus 4.8. 이전 버전인 Opus 4.7이 출시된 지 겨우 41일밖에 지나지 않았다1. 솔직히 "어, 벌써?"라는 소리가 절로 나왔다.
지금까지 나는 AI 코딩 지원을 팀에 새로 합류한 유능한 동료와 같은 존재라고 생각했다. 지시하면 움직이지만, 가끔 자신만만하게 틀리기도 하고, 내가 허점을 찾아내어 잡아줘야 한다. 편리하지만, 결국은 내가 리뷰한다는 전제하에 존재하는 존재. 이 기사를 통해 그 '동료'라는 비유로 Opus 4.8을 이야기해 나가려 한다. 그렇게 하면 이야기가 훨씬 쉽게 이해될 것이다.
결론부터 말하자면, 이번 업데이트로 이 동료는 성격이 상당히 어른스러워졌다. 화려한 신기술이 늘어났다기보다, 일하는 방식 자체가 신뢰할 수 있는 방향으로 변했다는 느낌이었다.
본 기사의 스펙 및 기능 기술은 Anthropic의 공식 발표(2026년 5월 28일) 및 각 미디어 보도에 기반한다. 벤치마크 수치는 출처를 명시하며, 검증되지 않은 숫자를 추측으로 작성하지 않도록 노력하고 있다.
공식 발표는 이곳.
먼저, 이 동료가 '기초 체력'을 얼마나 끌어올렸는지부터 살펴보자.
새로운 동료를 맞이하면 가장 궁금한 것은 "그래서 전임자보다 일을 잘해?"라는 점이다. Anthropic의 발표와 각 미디어의 보도를 정리하면, 기초 체력은 착실히 올라가고 있다.
| 항목 | Opus 4.7 | Opus 4.8 | 출처 |
|---|---|---|---|
| 에이전트형 코딩 (SWE-Bench Pro) | 64.3% | 69.2% | 9to5Mac / MacRumors 보도 |
| ... |
SWE-bench Verified 계열의 에이전트형 코딩 평가에서 Opus 4.8은 약 69%를 기록했다. MacRumors의 보도에 따르면, 이 수치는 GPT-5.5나 Gemini 3.1 Pro를 상회하는 한편, 터미널 조작 계열의 코딩에서는 GPT-5.5가 앞서고 있다고 한다2. 즉, 모든 영역에서 독주하고 있는 것은 아니다. 이 점은 솔직하게 적어둔다. 찬양 기사라고 해서 과장하는 것은 동료에게도, 독자에게도 실례다.
그럼에도 불구하고 코딩·추론·컴퓨터 조작·지식 작업(Knowledge work)·금융 분석 등 여러 영역에서 골고루 전임자를 앞서고 있는 것은 사실이며, 화려하지는 않지만 견실한 밑바탕이 되고 있다.
위 수치는 공식 발표 페이지의 비교표(이미지) 및 각 미디어 보도에서 가져온 것이다. 평가 하네스(Evaluation harness, 채점 환경)가 다르면 수치는 변한다. 공식 각주에서도 터미널 계열 벤치마크는 하네스에 따라 스코어가 변할 수 있음을 명시하고 있다. 벤치마크 수치는 "조건부 지표"로 읽는 것이 건전하다.
하지만 이번의 진짜 관전 포인트는 벤치마크 수치 그 자체가 아니다. Anthropic이 릴리스의 맨 앞에 내세운 것은 훨씬 수수하지만, 훨씬 효과적인 이야기였다. 그것이 바로 "정직함"이다.
신입 엔지니어에게 흔히 나타나는 문제 중 가장 곤란한 유형은 "못 하면서도 할 수 있다고 말하는" 타입이다. 리뷰를 해보니 전혀 작동하지 않는데, 본인은 자신만만하다. 이런 동료는 심장에 해롭다.
Opus 4.8이 가장 강화한 부분은 바로 이 정직함 부분이었다. 공식 표현을 인용하겠다.
Opus 4.8은 이전 모델보다 자신이 작성한 코드의 결함을 아무런 언급 없이 그대로 통과시킬 확률이 약 4배 낮다.
이를 번역하면,
Opus 4.8은 자신이 작성한 코드의 결함을 아무 말 없이 간과해 버릴 확률이 이전 세대에 비해 약 4분의 1로 줄어들었다.
'4분의 1'이라는 표현이 구체적이어서 좋다. 완벽해졌다고 말하는 것이 아니다. 간과하는 일이 줄어들었고, 스스로 "이 부분은 수상합니다"라고 신고하게 되었다는 이야기다. 실제로 사용해 봐도, 억지로 "완성했습니다"라고 선언하지 않고, "이 부분은 테스트되지 않았으니 확인해 주세요"라고 덧붙이는 경우가 늘어났다는 인상을 받는다.
정렬(Alignment) 평가에서도 친사회적(Prosocial) 특성이 신기록을 세웠다고 보고되었다.
사용자의 자율성을 지원하고 사용자의 최선의 이익을 위해 행동하는 것과 같은 친사회적 특성 지표에서 새로운 최고 수준에 도달했다.
나아가 기만이나 악용 가담과 같은 바람직하지 않은 행동의 발생률이 전임 모델인 Opus 4.7보다 대폭 낮아졌으며, 현재 가장 잘 정렬된 모델인 Claude Mythos Preview3와 동등한 수준까지 떨어졌다고 한다. VentureBeat의 보도에 따르면, 약 2,600회의 시뮬레이션 조사 세션에 기반한 미스얼라이먼트(Misalignment) 점수가 Opus 4.7의 2.5 전후에서 Opus 4.8에서는 1.9 전후로 떨어져, 제한적 제공 중인 Claude Mythos와 거의 비슷해졌다고 한다.
이것이 왜 기쁜 일인지 도식화하면 다음과 같다.
리뷰의 기점이 "인간이 전부 의심하며 접근하는 것"에서 "동료가 먼저 신고해 주는 것"으로 바뀐다. 이는 작업 전체의 신뢰 비용을 낮추는, 미미하지만 본질적인 개선이다. 칭찬하고 싶은 부분은 바로 여기다. 점수의 소수점 자리보다 이쪽이 훨씬 더 효과적이다.
이 "스스로 불확실성을 신고하는" 성질은, 장시간 계속 돌려두는 비동기 에이전트(Asynchronous Agent) 운용일수록 빛을 발한다. 아무도 보고 있지 않는 사이에 오류가 겹겹이 쌓이는 것이 자율 에이전트의 가장 큰 공포이기 때문이다.
정직함 다음으로는, 그 동료에게 "얼마나 진심을 다할지"를 지시할 수 있게 된 이야기를 해보자.
우수한 동료라도 모든 태스크에 전력을 다하면 곤란할 때가 있다. "이 상수 이름 좀 바꿔줘" 같은 가벼운 요청에 설계부터 다시 검토하며 깊이 고민한다면, 시간과 비용이 낭비된다. 반대로 무거운 설계 판단은 신중하게 생각해주길 바란다.
Opus 4.8 출시와 함께, claude.ai와 Cowork에서 effort(노력량) 제어를 사용할 수 있게 되었다. 모델 선택기 옆에 응답에 얼마나 힘을 쏟을지를 결정하는 컨트롤이 붙는다. 이는 모든 플랜에서 이용 가능하다.
- 높은 effort: 더 빈번하게, 더 깊이 생각한 뒤 답변한다. 품질 중시.
- 낮은 effort: 빠르게 답변한다. 속도 제한(Rate limit) 소모도 완만하다.
Opus 4.8의 기본값은 high effort이다. Anthropic에 따르면, 코딩 태스크에서는 Opus 4.7의 기본값과 비슷한 토큰 소모량으로 더 높은 성능을 낸다고 한다. 즉 "같은 연비로 마력이 높아진" 상태다.
더 높은 설정도 선택할 수 있다. Claude Code에서는 "extra"(xhigh)와 "max"가 준비되어 있으며, 어려운 태스크나 장시간의 비동기 워크플로우에는 "extra"가 권장된다. 높은 effort 쪽은 토큰 소모가 늘어나기 때문에, Claude Code 측의 속도 제한도 상향 조정되었다.
effort와 출력의 이미지는 다음과 같다.
이것은 요컨대 동료에게 "이번에는 대충 해도 돼", "이번에는 제대로 부탁해"라고 한마디 덧붙일 수 있게 되었다는 뜻이다. 매니지먼트 경험이 있는 사람일수록 이 한마디의 가치를 알 것이라 생각한다.
effort를 높이면 높일수록 좋은 것은 아니다. 가벼운 태스크에 max를 지정하면 품질은 거의 변하지 않으면서 토큰과 속도 제한만 잡아먹는다. 태스크의 무게에 맞춰 effort를 조절하는 것이 지갑에도, 속도 제한에도 친절한 방법이다.
그리고 이 동료가 혼자 감당할 수 없는 거대한 태스크를 위해 준비된 것이 바로 다음의 dynamic workflows이다.
여기까지는 "한 명의 우수한 동료"에 대한 이야기였다. dynamic workflows는 그 동료에게 팀을 이끌 권한을 부여하는 기능이라고 생각하면 이해하기 쉽다.
research preview(연구 프리뷰)로 제공되는 이 기능에서는 Claude Code가 작업 계획을 세우고, 단일 세션 내에서 수백 개의 병렬 서브 에이전트(sub-agent)를 실행한다. 그리고 각 서브 에이전트의 출력을 스스로 검증한 뒤, 인간에게 보고한다.
공식 측에서 제시한 예시가 상당히 강렬한데, Opus 4.8과 dynamic workflows를 결합한 Claude Code는 수십만 행 규모의 코드베이스 이전을 착수부터 머지(merge)까지 일관되게 수행할 수 있다고 한다. 심지어 기존 테스트 스위트(test suite)를 합격 기준으로 사용하면서 말이다.
MCP(Model Context Protocol)적인 에이전트 확장 흐름을 따라온 사람이라면, 이것이 '단발적인 똑똑한 모델'에서 '자율적으로 분업하는 팀'으로 나아가는 한 걸음이라는 것을 알 수 있을 것이다. 병렬로 수백 개의 서브 에이전트를 통솔하고, 심지어 스스로 검증한 뒤에 결과물을 돌려준다. 팀 리더로서의 동료라는 비유가 딱 들어맞는다.
dynamic workflows는 research preview 단계이며, Claude Code의 Enterprise / Team / Max 플랜 사용자에게 제공된다. 모든 사용자가 즉시 사용할 수 있는 것은 아니라는 점에 주의해야 한다. 연구 프리뷰 단계의 기능은 사양이 변경될 수 있다.
기능에 대한 이야기가 이어졌으니, 여기서 현실적인 '비용과 속도' 이야기로 넘어가 보자.
아무리 우수한 동료라도 인건비가 끝없이 치솟는다면 계속 고용할 수 없다. 이 부분이 Opus 4.8에서 은근히 강력하게 작용하는 포인트인데, 통상 이용 가격은 Opus 4.7과 동일하게 유지되었다.
| 항목 | 입력 (100만 토큰) | 출력 (100만 토큰) |
|---|---|---|
| 통상 이용 | 5달러 | 25달러 |
| fast mode | 10달러 | 50달러 |
성능은 올라갔는데 가격이 그대로라는 것은 실질적인 가격 인하와 같다. 게다가 fast mode는 기존 모델의 fast mode와 비교했을 때 2.5배 빠른 속도로 작동하며, 심지어 3배 더 저렴해졌다.
fast mode의 비용을 단순화하여 식으로 살펴보자. 입력 토큰 수를 $T_{in}$, 출력 토큰 수를 $T_{out}$(둘 다 100만 토큰 단위)이라고 하면, 1회당 대략적인 비용 $C$는 다음과 같다.
C = 10 \times T_{in} + 50 \times T_{out} \quad [\mathrm{USD}]
여기서 핵심은 '3배 저렴하다'는 변화다. Anthropic은 기존과 동일한 처리에 대해 대략적으로
C_{\text{new}} \approx \frac{1}{3}\, C_{\text{old}}
가 되었다고 설명한다. 속도가 필요한 대화형 용도에서 비용이 3분의 1이고 2.5배 빠르다면, 지금까지 예산 문제로 포기했던 실시간 용도가 단번에 현실적이 된다. '빠른 동료는 비싸다'는 전제가 깨진 것이 매우 크다.
API의 모델 문자열은 claude-opus-4-8이다. 기존에 Opus를 사용 중인 코드라면 모델 지정 부분만 교체하여 바로 테스트해 볼 수 있다. 가격이 동결되었으므로, 우선 실제 환경과 유사한 작은 작업(job)으로 체감 성능을 비교해 보는 것을 추천한다.
더불어 개발자를 위해 Messages API의 작지만 반가운 개선 사항도 포함되었다. 다음 실무 섹션에서 다루겠다.
여기서부터는 새로운 동료를 실제로 어떻게 부릴 것인가에 대한 실무 편이다. 복사해서 바로 테스트할 수 있는 형태로 남겨두겠다.
Python에서 API를 호출하는 최소 예제다. 기존 Opus 이용자로부터의 이전은 모델명을 교체하는 것이 기본이다.
클릭하여 소스 코드 전개 (Python / Messages API 최소 예제)
import anthropic
client = anthropic.Anthropic() # API 키는 환경 변수 ANTHROPIC_API_KEY 사용 권장
resp = client.messages.create(
...
이번 개발자 대상 업데이트에서, Messages API가 messages 배열 안에 system 엔트리를 수용할 수 있게 되었다. 지금까지 시스템 지시(system instruction)는 최상위 레벨에 고정되어 있어 중간에 변경하기가 번거로웠다. 새로운 사양에서는 작업 도중에 Claude에게 내리는 지시를 업데이트할 수 있다. 게다가 프롬프트 캐시(prompt cache)를 깨뜨리지 않고, 사용자 턴(user turn)을 거치지 않고도 가능하다.
에이전트를 실행하는 도중에 권한, 토큰 예산, 환경 컨텍스트(environment context) 등을 동적으로 수정하는 식의 활용이 상정되어 있다. 장시간 실행하는 에이전트일수록 효과적인 개선이다.
클릭하여 소스 코드 전개 (messages 배열 내에 system 엔트리를 삽입하는 이미지)
# 주의: 이는 API의 새로운 동작 개념을 보여주는 의사 코드(pseudo-example)입니다.
# 실제 필드 사양은 공식 문서를 확인하십시오.
messages = [
...
위의 내용은 새로운 동작의 개념을 보여주기 위한 의사 코드(pseudo-code)이다. 필드명이나 요청 형식의 정확한 사양은 반드시 공식 문서에서 확인하기 바란다.
최신 사양은 모델 개요 페이지가 1차 정보가 된다.
실무에서 헷갈리기 쉬운 effort 선택 방법을 태스크의 무게에 따라 정리해 두었다.
| 태스크의 무게 | 권장 effort | 이유 |
|---|---|---|
| 가벼운 수정・명명 변경・정렬 | low〜high (기본값) | 속도와 비용을 우선. 품질 차이가 나기 어려움 |
| ... |
여기까지 갖춰지면 첫날부터 어느 정도 일을 해줄 수 있다. 다만, 새로운 동료에게는 반드시 첫 만남의 어긋남이 있기 마련이다. 다음에서 그것을 없애보자.
새 멤버를 맞이한 첫 주에 발생하기 쉬운 트러블을 대처법과 함께 표로 정리했다.
| 증상 | 원인 | 대처 |
|---|---|---|
| 모델명을 찾을 수 없다는 에러 | 문자열 타이포 (typo) | claude-opus-4-8을 정확하게 지정 (하이픈 구분) |
| 예상보다 토큰 소비가 많음 | 기본값이 high effort | 가벼운 태스크는 effort를 낮춘다. 태스크의 무게에 맞춘다 |
| dynamic workflows를 사용할 수 없음 | 플랜/제공 범위의 제약 | Enterprise / Team / Max 플랜인지 확인. research preview 단계 |
| 「완성」이라고 하지 않고 확인을 요청함 | 정직성 강화에 따른 사양 | 버그가 아니라 개선 사항. 신고한 지점을 우선적으로 리뷰한다 |
| ... |
마지막 행은 은근히 중요하다. Opus 4.7에 있었던 코멘트의 장황함이나 도구 호출(tool calling) 문제는 Opus 4.8에서 수정되었다고 Devin을 만드는 Cognition이 공식 코멘트로 언급했다⁵. 4.7 시대에 작성한 회피용 프롬프트가 4.8에서는 오히려 방해가 될 가능성이 있다. 교체했다면 우선 순수한 상태로 테스트해보는 것이 좋다. 전임자를 위한 매뉴얼을 신임에게 떠넘기지 말라는 당연한 이야기이기도 하다(;゚д゚) 멍하니.
본문에 나온 용어를 처음 접하는 사람을 위해 정리해 둔다.
| 용어 | 의미 |
|---|---|
| 에이전트형 코딩 (Agentic Coding) | AI가 자율적으로 도구를 사용하여 코드의 읽기·쓰기·실행·수정을 진행하는 평가/작업 형태 |
| ... |
Claude Opus 4.8을 한 차례 써보고 찬양하고 싶은 것은, 신기능의 화려함이 아니라 동료로서의 신뢰성이 높아졌다는 점이다. 요점을 되짚어 본다.
- 벤치마크는 여러 영역에서 전임자를 확실히 앞선다. 다만 모든 영역에서 독보적인 1위는 아니다.
- 최대의 진보는 정직성이다. 자신의 코드의 허점을 놓칠 확률이 이전 세대 대비 약 4분의 1로 줄었다.
- effort 제어를 통해 「힘을 들이는 정도」를 지시할 수 있게 되었다.
- dynamic workflows를 통해 수백 개의 병렬 서브 에이전트(sub-agent)를 통솔하는 팀 리더가 될 수 있다.
- 가격은 그대로 유지, fast mode는 2.5배 빠르고 3배 저렴하다. 실질적인 가격 인하 효과다.
- 4.7용 회피 프롬프트는 일단 제거하고 테스트해야 한다.
개인적으로 가장 와닿았던 것은 제3절의 정직성이다. AI가 「했습니다」라고 당당하게 말해놓고, 리뷰에서 전부 의심하며 에너지를 소모했던 경험이 몇 번인가... orz. 그 동료가 「이 부분은 자신이 없습니다」라고 먼저 말해주는 것만으로도 공동 작업의 체감은 완전히 달라진다.
점수 소수점 아래를 다투는 단계에서, 안심하고 일을 맡길 수 있는가라는 단계로. Opus 4.8은 그 수수하지만 본질적인 방향으로 제대로 발을 내디딘 업데이트였다. 솔직히 경의를 표할 수밖에 없다. (웃음)
참고로 Anthropic은 수주 내에 Mythos 클래스의 모델을 모든 고객에게 제공할 예정이라고도 밝혔다. 우수한 동료 위에 더 격이 높은 존재가 대기하고 있는 셈이다. 속보가 나오면 다시 따라가 보고 싶다.
최신 최상위 모델에 대해서는 여기.
에이전트 확장 기술의 기반에 대해서는 MCP 기사도 참고 바람.
로컬에서 LLM을 구동하는 이야기에 관심이 있다면.
최신 AI・GPU・로컬 LLM 소식은 X에서도 발신하고 있습니다. 괜찮으시다면 팔로우를 부탁드립니다.
⁵ TechCrunch 보도에 따름. Opus 4.7 출시 후 41일 만이라는, Anthropic으로서는 통상적인 경우보다 빠른 업그레이드 간격이었다. https://techcrunch.com/2026/05/28/anthropic-releases-opus-4-8-with-new-dynamic-workflow-tool/ ↩
-
MacRumors의 보도에 의함. SWE-Bench Pro에서 GPT-5.5 및 Gemini 3.1 Pro를 상회하는 한편, 터미널 기반 코딩 (Terminal-based coding)에서는 GPT-5.5가 앞서고 있다고 함. https://www.macrumors.com/2026/05/28/anthropic-claude-opus-4-8/ ↩
Claude Mythos Preview는 사이버 보안 (Cybersecurity)상의 이유로 일반 제공되지 않으며, Project Glasswing의 일환으로 일부 조직에서 이용 중인 최상위 클래스의 모델임. ↩
VentureBeat의 보도에 의함. 약 2,600회의 시뮬레이션 조사 세션에 기반한 미스얼라이먼트 스코어 (Misalignment score)에서, Opus 4.7의 약 2.5에서 Opus 4.8에서는 약 1.9로 낮아졌다고 함. https://venturebeat.com/technology/anthropics-claude-opus-4-8-is-here-with-3x-cheaper-fast-mode-and-near-mythos-level-alignment ↩
Anthropic 공식 발표 페이지에 게재된 Cognition (Devin)의 Scott Wu 씨의 코멘트에 의함. Opus 4.7에서 나타났던 코멘트의 장황함과 도구 호출 (Tool calling) 문제가 수정되었다고 언급함. ↩
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기