Claude Opus 4.8 사용법: 모델만 바꿨는데 체감이 없는 이유와 effort 설정법

Claude Opus 4.8로 바꿨는데 결과가 생각보다 비슷하게 느껴지나요?

그럴 수 있습니다. 새 모델을 쓴다고 해서 모든 작업의 결과가 자동으로 좋아지지는 않습니다. 특히 이전과 똑같은 프롬프트, 똑같은 설정, 똑같은 작업 방식으로 쓰면 체감 차이가 약할 수 있습니다.

짧게 말하면 이렇습니다.

Anthropic은 2026년 5월 28일 Claude Opus 4.8을 공개하면서 세 가지를 함께 강조했습니다.

1. Opus 4.7 대비 여러 벤치마크와 협업 능력이 개선되었습니다.
2. claude.ai에서 사용자가 작업별로 effort를 조절할 수 있게 되었습니다.
3. Claude Code에는 더 큰 작업을 다루기 위한 dynamic workflows 기능이 추가되었습니다.

그리고 Claude 공식 문서에서는 Opus 4.8을 쓸 때 특히 effort 조절, 응답 길이 조절, 문자 그대로의 지시 해석, 도구 사용, 코드리뷰 프롬프트를 다시 점검하라고 안내합니다.

즉 이번 업데이트의 핵심은 “새 모델이 나왔다”에서 끝나지 않습니다. 사용자가 모델에게 얼마나 깊게 생각할지 정하고, 어떤 방식으로 일을 나눠 맡길지까지 같이 봐야 합니다.

먼저 결론부터

Claude Opus 4.8을 제대로 쓰려면 아래 세 가지만 기억하면 됩니다.

이 세 가지가 맞아야 “벤치마크는 좋은데 왜 나는 모르겠지?”라는 느낌이 줄어듭니다.

왜 새 모델인데 체감이 약할까?

가장 흔한 이유는 세 가지입니다.

첫째, 작업 난이도에 비해 생각할 깊이를 낮게 둔 경우입니다.

오탈자 수정, 짧은 요약, 문장 톤 변경은 깊은 추론이 필요하지 않습니다. 이런 작업은 낮은 effort로도 충분합니다. 반대로 버그 원인 분석, 구조 설계, 긴 문서 분석, 대규모 리팩터링은 여러 가능성을 비교해야 합니다. 낮은 effort로 처리하면 답은 빠르게 나오지만 깊이가 부족할 수 있습니다.

둘째, 요청이 너무 추상적인 경우입니다.

“잘 정리해줘”, “AI 티 안 나게 해줘”, “뻔하지 않게 해줘” 같은 요청은 사람이 보기에는 자연스럽지만 기준이 흐립니다. 무엇을 잘했다고 볼지, 어떤 표현을 피해야 할지, 결과물이 어느 정도 길이여야 하는지 알기 어렵습니다.

셋째, 큰 작업을 한 번에 완성하려고 하는 경우입니다.

AI는 만능 자동완성기가 아니라 함께 일하는 작업자에 가깝습니다. 초안, 검토, 수정, 검증을 나누면 결과가 더 안정됩니다. 특히 Claude Code에서는 이 차이가 큽니다.

effort는 무엇인가요?

effort는 쉽게 말해 Claude가 한 작업에 얼마나 많은 토큰을 쓰며 답할지 조절하는 설정입니다. 결과의 꼼꼼함과 속도, 비용 사이의 균형을 잡는 장치라고 보면 됩니다.

낮게 두면 더 빠르고 가볍게 답합니다. 가벼운 작업에 좋습니다.

높게 두면 더 깊게 분석하고, 도구도 더 많이 사용할 수 있습니다. 복잡한 작업에 좋습니다.

공식 문서 기준으로 Opus 4.8의 API 기본값은 high입니다. high는 effort를 따로 지정하지 않았을 때와 같은 동작입니다. 코딩과 에이전트형 작업은 xhigh에서 시작하는 것을 권장하고, 대부분의 지능 민감 작업은 최소 high를 권장합니다.

작업별 effort 추천표

아래 표는 처음 시작할 때 기준으로 삼기 좋은 가이드입니다. 실제 옵션 이름은 사용하는 환경에 따라 조금 다를 수 있습니다.

핵심은 “항상 최고 설정”이 아닙니다. 작업의 크기와 위험도에 맞게 바꾸는 것입니다.

Claude Code의 ultracode는 뭔가요?

Claude Code를 쓰다 보면 ultracode라는 표현을 볼 수 있습니다. 이때 주의할 점이 있습니다.

ultracode는 API에서 받는 별도의 effort 값이 아닙니다. 공식 effort 값은 low, medium, high, xhigh, max입니다.

공식 문서에 따르면 Claude Code의 ultracode 모드는 xhigh effort와 멀티 에이전트 워크플로우 실행 권한이 함께 묶인 모드에 가깝습니다. 그래서 블로그나 문서에서 effort를 설명할 때는 ultracode를 독립적인 API 설정처럼 말하지 않는 것이 좋습니다.

실무에서는 이렇게 이해하면 됩니다.

Opus 4.8에서 특히 잘 맞는 요청 방식

Opus 4.8은 복잡한 작업에서 판단력과 협업 능력이 좋아졌다고 소개되었습니다. 하지만 모델이 좋아졌다고 해서 애매한 요청까지 알아서 명확한 기준으로 바꿔주지는 않습니다.

공식 prompting 문서에서도 Opus 4.8은 지시를 더 문자 그대로 해석하는 경향이 있다고 설명합니다. 특히 낮은 effort에서는 요청한 범위 안에서만 움직이기 쉽습니다. 그래서 적용 범위를 분명히 말하는 것이 중요합니다.

아래처럼 요청을 바꿔보세요.

좋은 프롬프트는 멋진 문장이 아닙니다. 기준이 분명한 문장입니다.

특히 아래 네 가지를 넣으면 결과가 안정됩니다.

1. 원하는 결과물의 개수
2. 각 항목의 길이
3. 적용 범위
4. 모르면 어떻게 표시할지

예를 들어 이렇게 요청할 수 있습니다.

이 내용을 실무자용 체크리스트로 정리해줘.

조건:
- 핵심은 5개만 뽑아줘.
- 각 항목은 제목 1줄, 설명 2문장 이내로 써줘.
- 모든 섹션에 같은 형식을 적용해줘.
- 바로 실행할 수 있는 행동으로 써줘.
- 근거가 부족한 내용은 추측하지 말고 “확인 필요”라고 표시해줘.

이렇게 쓰면 모델이 무엇을 해야 하는지 훨씬 명확해집니다.

응답이 너무 길거나 짧을 때

Opus 4.8은 작업이 얼마나 복잡한지에 따라 응답 길이를 조절하는 경향이 있습니다. 간단한 질문에는 짧게 답하고, 열린 분석 작업에는 길게 답할 수 있습니다.

그래서 콘텐츠 작업에서는 길이 기준을 같이 주는 것이 좋습니다.

답변은 5개 항목으로만 정리해줘.
각 항목은 제목 1줄, 설명 2문장 이내로 써줘.
예시는 꼭 필요한 경우에만 1개만 넣어줘.

반대로 분석이 너무 얕다면 프롬프트로 억지로 길게 만들기보다 effort를 high나 xhigh로 올리는 것이 먼저입니다.

Claude Code에서는 한 번에 맡기지 마세요

Claude Code를 쓸 때도 마찬가지입니다.

“이 기능 만들어줘”라고 한 번에 맡기면, 모델은 나름대로 해석해서 구현합니다. 작은 기능이면 괜찮을 수 있습니다. 하지만 코드베이스가 커질수록 의도와 다른 방향으로 갈 가능성이 커집니다.

Anthropic은 Opus 4.8과 함께 Claude Code의 dynamic workflows도 소개했습니다. 큰 작업을 계획하고, 여러 하위 작업으로 나누고, 검증까지 이어가는 방향입니다. 우리도 일상적인 Claude Code 사용에서 같은 원리를 작게 적용할 수 있습니다.

관련 코드를 먼저 읽고, 현재 구조와 데이터 흐름을 요약해줘.
아직 파일은 수정하지 마.

가능한 해결 방법을 3가지로 비교해줘.
각 방법의 장점, 단점, 수정 범위를 알려줘.
추천안도 하나 골라줘.

추천안으로 진행하되, 변경 범위를 최소화해줘.
기존 패턴을 우선 따르고, 관련 없는 리팩터링은 하지 마.

방금 변경한 내용을 코드리뷰 관점으로 다시 확인해줘.
버그 가능성, 누락된 케이스, 테스트 필요 항목을 우선순위로 알려줘.

가능한 검증을 실행하고, 통과한 항목과 확인하지 못한 항목을 나눠서 알려줘.

이 루틴을 쓰면 결과가 훨씬 안정됩니다. 핵심은 모델에게 “바로 만들라”고 하는 것이 아니라, 읽고 판단하고 고치고 검증하게 하는 것입니다.

바로 쓰는 프롬프트 템플릿

아래 템플릿은 그대로 복사해서 써도 됩니다.

코드리뷰 요청

이 변경사항을 코드리뷰 관점으로 봐줘.

우선순위:
1. 실제 버그가 날 수 있는 부분
2. 보안 또는 데이터 손실 위험
3. 성능 문제
4. 유지보수성이 떨어지는 부분
5. 테스트가 필요한 부분

형식:
- 발견한 이슈는 중요도가 낮아 보여도 먼저 모두 보고해줘.
- 각 이슈마다 심각도와 확신도를 표시해줘.
- 파일명과 위치를 함께 알려줘.
- 순수 취향 차이나 네이밍 취향은 제외해줘.
- 확실하지 않은 내용은 추측하지 말고 “확인 필요”라고 표시해줘.

디버깅 요청

아래 오류의 원인을 추적해줘.

진행 방식:
1. 오류 메시지에서 확인할 수 있는 사실만 먼저 정리해줘.
2. 가능한 원인을 가능성이 높은 순서로 3개 제시해줘.
3. 각 원인을 확인하는 방법을 알려줘.
4. 바로 코드를 고치기 전에, 어떤 파일을 봐야 하는지 먼저 말해줘.

디자인 개선 요청

이 화면을 실무 서비스 기준으로 개선해줘.

기준:
- 첫 화면에서 사용자가 해야 할 행동이 분명해야 해.
- 장식보다 정보 구조를 우선해줘.
- 버튼, 입력창, 상태 표시가 빠지지 않게 봐줘.
- 모바일에서 텍스트가 겹치거나 잘릴 가능성도 확인해줘.
- 기본적인 크림색 배경이나 테라코타 계열 포인트 컬러에 기대지 말고, 서비스 성격에 맞는 시각 방향을 먼저 제안해줘.

결과 형식:
- 문제점 5개
- 개선 방향 5개
- 바로 적용할 수 있는 UI 문구 예시

긴 문서 분석 요청

이 문서를 실무자가 빠르게 판단할 수 있게 분석해줘.

형식:
1. 핵심 요약 5줄
2. 중요한 주장 5개
3. 실행 가능한 액션 5개
4. 리스크 또는 확인 필요 사항
5. 내가 추가로 물어봐야 할 질문

주의:
근거가 없는 내용은 추측하지 말고 “확인 필요”라고 표시해줘.

자주 묻는 질문

마무리

Claude Opus 4.8은 분명 좋아진 모델입니다. 하지만 모델만 바꾼다고 일하는 방식까지 자동으로 바뀌지는 않습니다.

실무에서 체감하려면 세 가지를 같이 봐야 합니다.

첫째, 작업 난이도에 맞는 effort를 고릅니다.

둘째, 애매한 표현 대신 결과 기준과 적용 범위를 구체적으로 줍니다.

셋째, Claude Code에서는 읽기, 비교, 구현, 리뷰, 검증을 나눠서 진행합니다.

좋은 모델을 고르는 것에서 끝내지 말고, 좋은 작업 방식까지 함께 설계해보세요. 그때부터 Opus 4.8의 차이가 더 분명하게 느껴집니다.