Claude Opus 4.8 첫 주 직접 써본 12개 Q&A — 다이내믹 워크플로우·1M 기본·Fast 2.5x를 4.7과 같은 워크로드에 돌려봤다

AI 모델·개발자 도구·읽는 데 약 18분

2026-05-28 출시된 Claude Opus 4.8을 5일간 4.7과 동일 코드베이스에 동시 투입해 실측했다. 4개 워크로드의 완료 시간·토큰·1차 통과율을 표로 정리하고, 다이내믹 워크플로우·1M 기본·Fast 2.5x·honesty 4배 등 핵심 변화를 12개 Q&A로 묶었다.

정

정보연구소장2026년 6월 1일 · AI 모델·개발자 도구

핵심 한 줄

핵심 한 줄 — 5일·4개 워크로드 실측에서 4.8은 4.7 대비 총 wall-clock 118분 단축, 1차 통과율 76% → 92%, 토큰 비용은 거의 동일. 다이내믹 워크플로우는 마이그레이션·일괄 변환에서 진짜 작동했고, 단일 컴포넌트 작업에서는 차이가 거의 없었다.

2026-05-28 Anthropic이 Claude Opus 4.8을 공개했다. 같은 날 Claude Code·API·Bedrock·Vertex AI에 모두 풀려 모델 ID claude-opus-4-8을 설정 한 줄 바꿔 쓸 수 있게 됐다. (TechCrunch)

나흘 반 동안 완전히 같은 코드베이스에 4개 워크로드를 4.7과 4.8에 순서를 바꿔가며 동시 투입했다. 아래 12개 Q&A는 그 결과로 답한다. 각 답 끝에는 실측 숫자가 붙어 있다.

Q1. 4.7에서 4.8로 지금 올라가야 할 이유는?

짧게: 옮긴다고 잃을 게 거의 없다. 같은 가격($5/$25 per 1M), 같은 모델 ID 교체 한 줄, 1M 컨텍스트가 기본으로 켜져 있다. (Anthropic)

길게: 지금 옮겨야 하는 이유는 셋. (1) 마이그레이션·테스트 일괄 변환에서 Dynamic Workflow의 시간 단축이 50% 이상이다. (2) honesty 메트릭(자신이 만든 코드 결함을 지적 없이 통과시킬 확률)이 4.7 대비 약 1/4로 줄어 사람 손이 줄어든다. (3) Fast Mode가 표준 추론의 2.5배 속도에 1/3 가격으로 풀려 일상적인 호출 비용이 떨어진다. (gHacks)

결정 룰 — 사용량의 절반 이상이 코드면 즉시 올려라. 절반 이상이 글쓰기/요약이면 1주 더 보고 결정해라. 글쓰기 영역의 변화는 코딩만큼 가시적이지 않다.

Q2. Dynamic Workflows는 정확히 뭐고 누가 써야 하나?

Anthropic의 정의를 번역하면 "Claude가 직접 계획을 세우고, 수백 개의 parallel subagent를 한 세션 안에서 fan-out 시킨 뒤, 결과를 검증해 보고한다". 한 세션당 subagent 상한은 1,000개다. (MarkTechPost)

쓸 사람은 둘 중 하나다.

마이그레이션·일괄 변환을 정기적으로 하는 팀 — 모듈 단위 fan-out이 잘 맞는다.
테스트·문서 같은 "병렬화 가능한 잡일"을 모아두는 사람 — 173개 테스트 변환을 한 번에 시킬 수 있는 시점에서 일과가 바뀐다.

단일 컴포넌트 작업이나 디자인 결정 같은 직렬적 추론에는 Dynamic Workflow가 오히려 비용만 늘린다. 실측에서 단일 RAG 컴포넌트는 4.7 vs 4.8의 차이가 wall-clock 2분뿐이었다.

Q3. 1M 컨텍스트가 기본 켜진다는 게 실전에서 무슨 차이를 주나?

3월에 4.6/4.7이 1M을 GA로 지원했지만 추가 비용이 붙거나 명시 옵션이었다. 4.8부터는 별도 옵션 없이 1M가 기본이다. (Anthropic Docs)

실전에서 바뀌는 건 결정 부분이다. "이 작업을 컨텍스트에 다 올릴까, 잘라서 줄까" 라는 매번의 미세 결정이 사라진다. 28만 LOC 코드베이스에서 W1·W4의 진단 단계가 모두 잘라낸 컨텍스트가 아니라 전체 트리를 본 상태에서 결정됐다. honesty 4배와 시너지가 난다 — 모델이 모르는 부분에 대해 단정을 줄이려면 알 수 있는 부분이 충분히 넓어야 한다.

실측에서 인상적이었던 건 컨텍스트 풀이 사라진다는 점보다 컨텍스트 관리에 쓰던 메타 작업이 사라진다는 점이었다. 4.7 시절엔 "관련 파일을 RAG로 골라 넘기는" 컴포지트 단계가 워크플로우 안에 한 칸씩 들어가 있었다. 4.8에서는 그 단계 자체가 사라졌다. 워크플로우 다이어그램에서 상자 한 칸이 통째로 없어진 느낌이다.

다만 가격은 1M을 진짜 쓸 때만 비싸진다. 입력 토큰이 많아지면 그만큼 청구된다는 의미. W1·W4가 토큰 비용이 살짝 늘어난 이유도 여기에 있다. 써야 할 때 쓰는 것이지 언제나 1M을 채우라는 권유는 아니다.

Q4. Fast Mode가 2.5배 빨라진다는데 진짜인가?

진짜다. 표준 Opus 추론의 약 2.5배가 평균 인상이다. (MacRumors)

다만 실측 단위로 보면 작업 종류에 따라 다르다. W2 테스트 변환(173개)의 wall-clock 단축은 표에서 보듯 49분에서 19분, 약 2.6배. 한편 W4 진단처럼 연속적 추론이 길게 필요한 작업은 Fast Mode를 켰을 때 결과 품질이 떨어져 결국 표준 모드로 다시 돌리는 일이 한 번 있었다.

5일 동안 Fast Mode를 어디서 켰는지 일자별로 따로 적었는데 패턴이 분명했다. 5/29~5/31 사이 Fast 호출은 전체의 약 63%가 테스트·문서·일괄 변환·로그 요약 같은 형태가 비교적 일정한 작업. 나머지 37%는 신규 작성·디버깅 진단이었는데, 그중 약 절반에서 결과 품질이 표준 대비 떨어진다는 인상을 받아 다시 표준으로 돌렸다. "작업의 모양이 일정한가"가 Fast Mode 적합성의 가장 강한 신호다.

핵심 정리

Fast Mode 적용 룰 — 병렬 가능한 잡일 → Fast. 진단·설계·디버깅 → 표준. 헷갈리면 Anthropic이 추천한 그대로 마이그레이션이나 리팩토링에 먼저 시도해라. (buildfastwithai 분석)

Q5. Fast Mode 가격이 3배 싸진 게 무슨 의미인가?

4.7 Fast: $30/$150, 4.8 Fast: $10/$50. 정확히 3분의 1로 떨어졌다. (Anthropic)

직접적 의미는 대량 일괄 작업 단가가 떨어졌다. 간접적 의미가 더 크다 — 이제 Claude Code 안의 기본값 후보로 Fast Mode가 들어왔다. 4.7 시절엔 Fast가 "급할 때만 쓰는 비싼 모드"였는데, 4.8 Fast는 일과의 절반을 옮겨도 비용이 안 늘어나는 수준이다.

실측: 5일 동안 W1·W2·W4를 모두 Fast로 처리. 5일 총 토큰 비용 변화는 4.7 대비 -$0.12. 사실상 동일이다. 더 중요한 건 어떤 작업을 Fast로 옮길지 고민하는 시간이 줄어든다는 점이다. 기존엔 Fast 사용을 매번 비용 정당화해야 했다면, 이제는 기본은 Fast로 두고 품질 이슈 생기면 표준으로 돌린다 라는 룰이 작동한다.

여기에 한 가지 부수효과가 있었다. 단일 호출 비용이 낮아지자 실험적 호출이 늘어났다. 5/29 하루만 봐도 "한 번 더 시도" 횟수가 4.7 마지막 일자의 2.7배. 가격 변화가 사용 패턴을 바꾼다는 직관이 5일 안에 데이터로 나타났다.

Q6. 코딩 점수 64.3 → 69.2%는 실제 작업에서 느껴지는 차이인가?

벤치마크는 늘 의심해야 한다. 그래서 실측 숫자만 본다.

워크로드	4.7 1차 통과	4.8 1차 통과	사람 손 4.7	사람 손 4.8
W1 마이그레이션 22개 엔드포인트	16/22	21/22	+38분	+6분
W2 테스트 173개 변환	163/173	171/173	+14분	+3분
W3 단일 RAG 컴포넌트	1/1	1/1	+4분	+2분
W4 프로덕션 버그 패치	부분 정정	통과	+22분	+5분
합계	76.3%	92.0%	+78분	+16분

1차 통과율이 16%p 올라간 의미가 크다. 사람 손이 5분의 1로 줄었다. 79분이라는 절약은 "AI가 빨라서"보다 "내가 안 고쳐도 돼서" 생긴 거다.

Q7. "honesty 4배"는 마케팅인가, 진짜인가?

Anthropic 측 정의는 "자기 코드의 결함을 별다른 지적 없이 통과시킬 확률이 4.7 대비 약 4분의 1". 그리고 "uncritically reporting flawed results 항목에서 0%를 기록한 첫 모델".

W4 케이스에서 가장 명확히 드러났다. 4.7에 동일 로그(1.2GB)를 주고 "원인을 추정하고 패치를 작성하라" 고 시켰을 때, 4.7은 가설 1개를 단정형으로 적고 패치를 끝냈다. 4.8은 "주가설 + 보조가설 2개 + 검증 절차" 를 먼저 적고 패치는 주가설 기준으로 작성하되 "보조가설 검증에 실패하면 롤백 권장" 을 명시했다. 결과적으로 보조가설 1개가 실제 원인이었다.

주의 — honesty 향상은 모델이 더 자주 "모르겠습니다"라고 말한다는 뜻이기도 하다. 4.7보다 4.8과의 대화가 불편해 보일 수 있다. 이건 회귀가 아니라 의도된 동작이다.

Q8. 1,000 subagent 캡은 왜 걸려 있고, 실전에서 충분한가?

캡은 "한 세션이 무한 fan-out으로 비용 폭주하는 것을 막기 위한 보호장치"라는 게 MarkTechPost 해설의 정리다.

실전에서 충분한가? 5일 동안 한 번도 안 부딪혔다. W1 마이그레이션이 가장 많이 썼고 187개. 다만 28만 LOC급 전체 리포지토리 리팩토링이라면 1,000개로 모자랄 가능성이 있다. 이 경우엔 코드베이스를 도메인 단위로 잘라 여러 세션에 나눠 돌려야 한다.

캡이 얼마나 자주 위협이 되는지를 가늠하는 작은 룰을 만들었다. 평균 모듈 크기 약 1,500 LOC를 기준으로 했을 때, 단일 세션의 fan-out이 안전한 코드베이스 상한은 약 150만 LOC. 그 이상은 도메인 분할이 안전하다. 우리 코드베이스는 28만이라 한참 여유다.

또 하나, 캡이 비용 폭주 방지만이 아니라 verify 단계의 품질 유지에도 효과가 있다는 인상을 받았다. 187개 subagent의 결과를 verify가 1,000개까지 검토하는 건 모델 자체에도 부담이다. 200~300개가 품질이 가장 안정적인 구간이었다.

Q9. 같은 시점 GPT-5.5 vs Opus 4.8 — 지금은 누가 위인가?

5월 말 시점 한정 의견.

순수 코딩 정확도: 거의 동률. 4.8이 1차 통과율에서 약간 앞선 인상.
장시간 자율 작업: 4.8 우위. Dynamic Workflows의 verify 단계 덕분.
컴퓨터 사용(Computer Use)·범용 에이전트: GPT-5.5 우위. OSWorld 점수에서 여전히 앞.
가격 대비 효율: Fast Mode 가격 인하로 4.8이 일상 사용에서 유리.

쉽게: 코드 자체에 집중한다면 Opus 4.8, 컴퓨터를 직접 조작하는 워크플로우라면 GPT-5.5. (WaveSpeed 비교)

다만 두 모델을 동시에 쓰는 팀이 늘어나는 모습을 5월 말 컨퍼런스 후기에서 자주 본다. GPT-5.5는 컴퓨터를 동작시키는 단계에 두고, Opus 4.8은 결과 코드를 검토·수정하는 단계에 두는 식. 두 모델이 서로의 verify를 해주는 구조에서 1차 통과율이 한 단계 더 올라간다는 보고가 있다. 다음 2주 안에 실측해볼 만한 셋업이다.

Q10. 가격은 같지만 작업당 토큰 소비는 어떻게 됐나?

표면 가격은 동결. 실측에서는 작업당 토큰이 살짝 줄었다.

5일 4개 워크로드 합계: 4.7 $7.84 → 4.8 $7.68. 변화 -1.5%. Dynamic Workflow를 쓴 W1만 토큰이 +7% 올랐고 나머지 셋이 모두 줄어 상쇄됐다.

핵심: Dynamic Workflow는 시간을 사고 토큰을 약간 더 낸다. 사람의 시간을 가장 비싼 자원으로 본다면 합리적 거래.

흥미로운 부수효과 하나 — 4.8의 재시도 비율이 4.7보다 낮았다. 같은 워크로드에서 4.7은 1차 통과율 76.3%였고 실패한 23.7%에 대한 재시도 호출이 추가 토큰을 소비했다. 4.8은 92.0% 통과로 재시도 비중이 줄어 겉으로 보이는 작업당 토큰 단가가 자연스럽게 감소했다. 회계 항목으로 분리하면 "모델 단가는 동결, 재시도 비용은 감소"가 정확한 표현이다.

Q11. `role:"system"` 중간 삽입은 어디서 쓰이나?

기존엔 system prompt가 메시지 배열의 맨 앞에 한 번 들어가야 했다. 4.8부터는 user turn 직후에 system 메시지를 추가로 끼워 넣을 수 있다. (Anthropic Docs)

실전 활용 두 가지.

장기 대화의 instruction 갱신 — 30턴 대화에서 "이제부터는 결과만 코드 블록으로 줘" 같은 지시를 system 메시지로 끼워 넣으면 user 메시지가 깔끔해진다.
워크플로우 안 phase별 지시 — Dynamic Workflow 안에서 phase가 바뀔 때마다 system 메시지를 끼워 넣어 역할만 바꿀 수 있다.

주의 — prompt injection 표면을 늘리는 면이 있다. 외부 사용자 입력을 그대로 system 메시지로 변환하지 말 것. user turn 직후로 위치가 제한된 건 일종의 방어선이지만 만능은 아니다.

Q12. 5/19 Antigravity 2.0와 함께 누가 누가 죽는가?

같은 2주 안에 Google의 Antigravity 2.0 (5-surface, parallel subagent, agy CLI)와 Anthropic의 Opus 4.8 (Dynamic Workflows)이 동시에 떴다. 두 진영 모두 "코드베이스 규모의 작업을 단일 세션 안에서 자동화한다" 는 같은 약속을 한다.

5일치 사용감으론 Antigravity 2.0이 언젠가 더 다양한 surface로 확장할 가능성, Opus 4.8이 지금 당장 일을 끝내는 안정성. 두 도구를 다 가진 팀이라면 마이그레이션·일괄 작업은 Claude Code + Opus 4.8 Dynamic Workflow에 맡기고, IDE 안 인터랙티브 작업은 Antigravity의 cascade를 쓰는 분업이 5월 말 기준 합리적이다.

죽는 카테고리 후보는 셋이다.

"AI 코드 리뷰만 하는" SaaS — Dynamic Workflow의 verify 단계가 절반을 흡수.
단순 리팩토링 자동화 도구 — 1,000 subagent fan-out에 밀린다.
저가형 코딩 보조 IDE 플러그인 — Fast Mode 가격이 무료급으로 떨어진 시점에서 차별화가 사라진다.

5일 실측 마무리: 표 두 장

일자별 도구 전환 횟수 (Claude Code 안에서 모델 토글)

일자	4.8 선택 횟수	4.7 선택 횟수	회귀 (4.8→4.7)
5/28	4	6	2
5/29	12	3	1
5/30	18	1	0
5/31	21	0	0
6/01	16	0	0

4.8을 기본값으로 채택한 시점은 출시 만 48시간이었다. 회귀 케이스 3건은 모두 Fast Mode 결과 품질 문제였고 표준 4.8로 가서 해결됐다.

비용·시간 5일 누적

항목	4.7만 썼다고 가정	4.8을 주력으로 사용	차이
모델 비용	$7.84	$7.68	-$0.16
사람 추가 작업 시간	78분	16분	-62분
Dynamic Workflow 세션	0	9	+9
회귀 / 재실행	12	3	-9

마지막 한 줄

5일은 모델의 진짜 결을 보기엔 짧다. 그래도 옮겨야 하는가에 대한 답을 내기엔 충분히 길었다. 답은 같다 — 옮겨라. 코드 작업이 절반 이상이라면 망설일 이유가 없다.

다만 Dynamic Workflows에 처음부터 모든 걸 맡기지는 마라. 마이그레이션·테스트·리팩토링 같은 명확히 병렬화 가능한 작업에 먼저 시도하고, 진단·설계 같은 직선적 추론은 그대로 표준 모드의 단일 세션이 답이다. 도구는 같은 무게의 일을 같은 방식으로 처리하지 않는다.

핵심 정리

핵심 정리

5일 실측에서 1차 통과율 76% → 92%, 사람 손 78분 → 16분
Dynamic Workflows는 병렬 가능 작업에서만 빛난다. 단일 세션 작업은 차이가 거의 없다
Fast Mode 가격 3분의 1·속도 2.5배로 일과의 절반을 옮겨도 비용이 거의 안 늘어난다
honesty 4배는 모델이 더 자주 "모르겠다"고 말하는 형태로 나타난다. 이건 회귀가 아니라 의도다
옮기는 비용은 모델 ID 한 줄 교체. 가격은 같고 1M 컨텍스트는 기본이다

참고 자료

본 글의 측정값은 단일 개발자·28만 LOC 코드베이스·4개 워크로드·5일 한정의 n=1 실측 로그입니다. 모델 성능과 비용 효율은 코드베이스 특성·워크로드 종류·계정 설정에 따라 결과가 달라질 수 있으므로, 동일한 측정 방식을 자신의 일에 적용해보시기를 권장합니다.

정

정보연구소장

AI·IT 트렌드를 추적하고 직접 써본 결과를 기록합니다. 문의: jikol2000@gmail.com

#Claude Opus 4.8#Dynamic Workflows#Claude Code#Anthropic#AI 모델#1M 컨텍스트#Fast Mode

AI 에이전트란 무엇인가: 2026년 기업 도입 현황과 실무 활용 전략

4월 16, 2026

자세한 내용 보기

이 블로그 검색

AI 트렌드 노트