Claude Opus 4.7 vs Opus 4.6 실무 비교 2026 — 코딩 에이전트·비용·마이그레이션 판단표

Posted on by

Claude Opus 4.7은 2026년 4월 16일 일반 제공됐고, API 모델 ID는 claude-opus-4-7이다. Opus 4.6과 가격표는 같지만, tokenizer·effort·API 파라미터가 바뀌어 운영 비용과 오류 지점은 다시 봐야 한다.

처음엔 가격표가 제일 반가웠다.

입력 100만 토큰당 5달러.

출력 100만 토큰당 25달러.

Opus 4.6과 같다는 문장을 보면 마음이 잠깐 편해진다.

그런데 문서를 더 읽으면 바로 편하지 않아진다.

모델 단가는 같아도 토큰 계산이 달라질 수 있다.

temperature, top_p, top_k를 비기본값으로 넣으면 400 에러가 날 수 있다.

기존 thinking.budget_tokens 방식도 그대로 가져가면 안 된다.

그리고 xhigh effort가 새로 생기면서 코딩 에이전트의 품질·비용·지연시간 균형점이 다시 움직였다.

이번 글은 출시 뉴스 요약이 아니다.

이미 Opus 4.7 핵심 변경점은 따로 정리해뒀다.

이번엔 Opus 4.6을 이미 쓰던 사람이 4.7을 어디에 먼저 켜고, 어디는 fallback을 남겨야 하는지 보는 운영 판단표다.

먼저 답을 짧게 적으면 이렇다.
Claude Opus 4.7은 어려운 코딩, 장기 에이전트, 고해상도 비전 작업에는 바로 테스트할 만하다.
다만 기존 API 서비스는 모델명만 바꾸지 말고 thinking, sampling parameter, token count, effort, image token 예산을 같이 점검해야 한다.

지금 결론

Opus 4.7은 Opus 4.6의 자연스러운 후속 모델이다.

Anthropic도 공식 발표에서 Opus 4.7을 Opus 4.6 대비 고급 소프트웨어 엔지니어링, 어려운 장기 작업, 지시 준수, 자체 검증이 좋아진 모델로 설명한다.

Claude API 문서에서도 Opus 4.7은 현재 가장 강한 일반 공개 모델로 분류된다.

특히 복잡한 추론과 agentic coding이 주 용도다.

하지만 운영자는 “더 강함”이라는 말만 보고 바로 기본값을 바꾸면 안 된다.

같은 가격표라도 tokenizer가 바뀌면 입력 토큰 수가 달라진다.

높은 effort에서 생각이 길어지면 출력 토큰과 지연시간도 달라진다.

API 파라미터가 바뀌면 기존 wrapper가 조용히 깨지는 게 아니라 400 에러로 넘어질 수 있다.

그래서 나는 이렇게 나눈다.

사용 상황 4.7 전환 판단 effort 시작점 4.6 fallback
큰 코드베이스 버그 추적 먼저 테스트 high 유지
장기 Claude Code 작업 적극 테스트 xhigh 유지
코드 리뷰와 보안성 검토 테스트 가치 큼 high 또는 xhigh 유지
단순 질답·짧은 요약 굳이 Opus 4.7 아님 medium 이하 필요
기존 제품 API backend 신중 전환 high부터 실측 필수
이미지·스크린샷 분석 적극 테스트 high 필요
비용 민감한 대량 처리 제한 테스트 medium 필수

이 표의 핵심은 “4.7이 좋냐”가 아니다.

좋은 모델은 맞다.

질문은 “어떤 작업에서 4.7의 추가 추론이 비용을 이기냐”다.

모델 비교는 팬심으로 시작할 수 있다.

운영 전환은 로그로 끝내야 한다.

이게 안 되면 다음 달 청구서가 조용히 코드 리뷰를 해준다.

그 리뷰는 보통 친절하지 않다.

Opus 4.6은 어떤 기준선이었나

Opus 4.6은 2026년 2월 5일 발표됐다.

Anthropic은 당시 Opus 4.6을 코딩, 장기 에이전트 작업, 큰 코드베이스, 코드 리뷰, 디버깅에서 이전 모델보다 강화된 모델로 설명했다.

Opus 계열에서 처음으로 1M token context window beta를 붙인 것도 4.6이었다.

나중에 2026년 3월 13일 Claude 블로그는 Opus 4.6과 Sonnet 4.6의 1M context가 일반 제공으로 전환됐다고 안내했다.

그때 실무 포인트는 분명했다.

긴 문맥 자체보다 모델 라우팅이 중요해졌다.

기본 정리와 넓은 문서 읽기는 Sonnet으로 보내고, 복잡한 판단과 긴 출력만 Opus로 올리는 구조가 가능해졌다.

Opus 4.6의 장점은 크게 세 가지였다.

첫째, 1M context 덕분에 코드베이스·문서·로그를 한 세션 안에 오래 들고 갈 수 있었다.

둘째, 128k max output 덕분에 긴 설계서나 마이그레이션 계획서를 한 번에 뽑기 쉬웠다.

셋째, adaptive thinking과 effort control 덕분에 속도와 깊이를 조절할 여지가 있었다.

Claude Code 쪽에서는 Agent Teams도 같이 주목을 받았다.

여러 Claude Code 인스턴스를 병렬로 돌려 코드베이스 조사, 리뷰, 리서치를 나눌 수 있는 흐름이었다.

그래서 Opus 4.6은 그냥 더 똑똑한 챗봇이라기보다 장기 실행 코딩 작업의 운영 모델에 가까웠다.

이 기준선을 알아야 4.7 변화가 보인다.

4.7은 4.6을 대체하는 새 이름이 아니라, 4.6에서 가장 비싸고 어려운 작업을 더 안정적으로 밀어붙이기 위한 업그레이드다.

다만 장점이 커진 만큼 설정면도 더 예민해졌다.

Opus 4.7에서 달라진 핵심

공식 자료 기준으로 Opus 4.7의 큰 변화는 여섯 개다.

첫째, Anthropic은 4.7이 Opus 4.6보다 어려운 소프트웨어 엔지니어링 작업에서 개선됐다고 설명한다.

둘째, 장기 실행 agentic work에서 더 높은 자율성과 일관성을 강조한다.

셋째, 지시 준수와 자체 검증이 좋아졌다고 말한다.

넷째, 고해상도 이미지 지원이 들어왔다.

다섯째, xhigh effort가 추가됐다.

여섯째, API 마이그레이션에서 깨질 수 있는 지점이 생겼다.

특히 고해상도 비전은 숫자로 차이가 보인다.

이전 Claude 모델의 이미지 한계는 긴 변 1568px, 약 1.15MP 수준이었다.

Opus 4.7은 긴 변 2576px, 약 3.75MP까지 지원한다.

스크린샷 기반 computer-use agent, 복잡한 다이어그램, 표가 빽빽한 문서 이미지에서는 체감이 날 수 있다.

좌표도 실제 픽셀과 1:1로 맞는다고 문서가 설명한다.

이건 UI automation이나 bounding box 후처리에는 꽤 실용적인 변화다.

대신 이미지 토큰 예산은 다시 봐야 한다.

고해상도 이미지는 좋은 만큼 더 많이 먹는다.

문서에 따르면 전체 해상도 이미지는 이전 모델보다 최대 약 3배 많은 image token을 쓸 수 있다.

그래서 이미지 워크플로우에서는 “더 잘 보니까 무조건 원본으로 넣자”가 답이 아니다.

정밀 좌표가 필요한 스크린샷은 원본.

대략 구조만 보는 문서는 downsample.

이렇게 정책을 나눠야 한다.

비교표로 보면 어디가 바뀌었나

아래 표는 Opus 4.6 사용자가 바로 확인해야 할 차이만 뽑은 것이다.

항목 Opus 4.6 Opus 4.7 운영 판단
출시일 2026-02-05 2026-04-16 4.7은 직접 후속
API 모델명 claude-opus-4-6 claude-opus-4-7 모델 ID 교체 필요
가격 $5/M input, $25/M output 동일 단가만 같음
context 1M 지원 1M 지원 둘 다 장기 작업 가능
max output 128k 128k 긴 출력 장점 유지
주요 강점 코딩, 장기 작업, 1M context 더 어려운 코딩, 장기 agent, 비전, memory 고난도 작업 우선
effort low/medium/high/max 중심 xhigh 추가 코딩은 high/xhigh 실험
thinking budget 방식 사용 가능 adaptive 중심 코드 수정 필요
sampling parameter 관성적으로 사용 가능 비기본값 400 가능 payload 정리 필요
token count 기존 tokenizer 새 tokenizer 비용 재측정 필요
image resolution 1568px / 1.15MP 수준 2576px / 3.75MP 비전 워크플로우 재설계

여기서 제일 오해하기 쉬운 건 가격이다.

공식 pricing page에는 Opus 4.7과 Opus 4.6이 같은 가격으로 나온다.

그런데 Opus 4.7은 새 tokenizer를 쓴다.

Claude API 문서는 같은 고정 text가 이전 모델 대비 최대 약 35% 더 많은 token으로 잡힐 수 있다고 설명한다.

또 높은 effort에서는 생각이 더 길어질 수 있다.

즉, 가격표는 같지만 실제 비용은 workload별로 다르다.

이 문장 하나만 기억해도 사고를 꽤 줄인다.

단가가 같다는 말은 청구서가 같다는 뜻이 아니다.

코딩 에이전트에서는 4.7을 어디에 먼저 켜야 하나

내 기준에서 Opus 4.7 첫 투입 후보는 단순 생성이 아니다.

어려운 조사, 긴 디버깅, 리팩터링 계획, 코드 리뷰다.

왜냐면 Opus 4.7의 장점은 “한 번에 더 예쁜 답변”보다 “긴 작업에서 덜 놓치는 것” 쪽에 가깝기 때문이다.

예를 들어 Claude Code에서 이런 작업은 4.7 테스트 가치가 높다.

  • 실패한 테스트 로그를 여러 번 따라가며 원인 후보를 좁히는 작업
  • 큰 저장소에서 관련 파일을 찾고 설계 의도를 추론하는 작업
  • PR diff를 읽고 실제 버그 가능성을 찾아내는 코드 리뷰
  • migration plan을 만들고 순서·롤백·검증을 같이 설계하는 작업
  • subagent가 만든 결과를 합쳐 최종 판단을 내려야 하는 작업

반대로 이런 작업은 굳이 Opus 4.7부터 켤 필요가 없다.

  • 짧은 README 문구 다듬기
  • 단순 함수 설명
  • 작은 JSON 변환
  • 이미 답이 뻔한 boilerplate 생성
  • 실패 비용이 낮은 초안 브레인스토밍

이런 건 Sonnet이나 더 저렴한 모델로 시작해도 된다.

Opus 4.7은 비싼 모델이다.

비싼 모델은 비싼 문제에 써야 한다.

특히 xhigh는 기본 답변 품질 옵션이 아니라 작업 난이도 옵션으로 보는 게 맞다.

내가 바로 적용한다면 이렇게 시작하겠다.

작업 시작 모델 시작 effort 성공 기준
대형 버그 조사 Opus 4.7 high 원인 후보 수, 재시도 횟수 감소
장기 리팩터링 계획 Opus 4.7 xhigh 단계 분해, rollback plan, test plan 품질
PR 리뷰 Opus 4.7 high false positive 유지, recall 개선
문서 이미지 분석 Opus 4.7 high 표·좌표·다이어그램 오독 감소
짧은 코드 설명 Sonnet 계열 medium 비용과 latency 우선

여기서 중요한 건 모델명보다 평가 지표다.

“더 똑똑한 것 같다”는 운영 지표가 아니다.

운영 지표는 성공률, 재시도, 사람이 고친 줄 수, latency, token, tool error다.

내 느낌보다 로그가 더 차갑다.

보통 차가운 쪽이 맞다.

비용은 이렇게 실측해야 한다

Opus 4.7 비용 비교는 단순 계산으로 끝나지 않는다.

공식 가격표만 보면 Opus 4.6과 4.7은 같다.

하지만 실제 비용은 아래 다섯 가지가 같이 움직인다.

첫째, 입력 text token count.

둘째, output token count.

셋째, thinking 사용 여부.

넷째, effort level.

다섯째, image token.

그래서 전환 테스트는 최소한 같은 prompt를 세 번 돌려야 한다.

Opus 4.6 baseline.

Opus 4.7 high.

Opus 4.7 xhigh.

각 결과에서 아래 값을 기록한다.

항목 기록 이유
input tokens tokenizer 변화 확인
output tokens 더 길게 생각하고 쓰는지 확인
latency 사용자 대기시간 확인
tool calls 도구 사용 경향 확인
tool errors agent 안정성 확인
retry count 실무 재작업 비용 확인
human edit time 최종 생산성 확인
pass/fail 작업 성공 여부 확인

여기서 input token은 반드시 count_tokens endpoint 기준으로 다시 보는 게 좋다.

클라이언트에서 문자 수로 대충 추정하는 코드는 4.7에서 위험해질 수 있다.

문서도 client-side token estimation을 다시 테스트하라고 권한다.

이미지 워크플로우라면 image token도 따로 본다.

고해상도 지원이 좋아졌다고 모든 이미지를 원본으로 던지면 비용이 조용히 불어난다.

원본이 필요한 이미지와 downsample해도 되는 이미지를 나눠야 한다.

내가 쓴다면 최소 예산표는 이렇게 만든다.

워크로드 4.6 비용 기준 4.7 예상 리스크 대응
긴 코드베이스 리뷰 안정 text token 증가 가능 max_tokens headroom 확대
xhigh 리팩터링 없음 output token 증가 가능 task budget 실험
스크린샷 분석 기존 한계 image token 증가 downsample 정책
API 대량 처리 안정 400 error + token 증가 parameter audit
Claude Code daily 체감 좋음 더 깊게 생각해 느려질 수 있음 high/xhigh 분리

비용 최적화는 모델을 아끼는 게 아니다.

비싼 모델이 이기는 문제만 고르는 것이다.

이걸 안 하면 좋은 모델을 사놓고 잡일 시키는 상황이 된다.

그건 사람 조직에서도 비싸다.

모델 조직에서도 똑같다.

마이그레이션에서 깨지는 부분

Opus 4.7 전환에서 가장 조심할 부분은 API payload다.

모델 ID만 바꾸는 건 쉬워 보인다.

하지만 기존 코드가 오래된 습관을 품고 있으면 바로 깨질 수 있다.

첫 번째는 thinking 설정이다.

Opus 4.6에서 쓰던 thinking: {"type": "enabled", "budget_tokens": N} 방식은 4.7에서 지원되지 않는다.

4.7은 thinking: {"type": "adaptive"}와 output_config.effort로 조절하는 쪽으로 옮겨야 한다.

예시는 이런 모양이다.

client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

두 번째는 sampling parameter다.

4.7부터는 temperature, top_p, top_k를 비기본값으로 넣으면 400 에러가 난다.

가장 안전한 방법은 request payload에서 빼는 것이다.

예전부터 temperature=0를 determinism 용도로 넣던 wrapper가 있다면 이 부분부터 확인해야 한다.

세 번째는 thinking content display다.

4.7은 thinking content를 기본적으로 omitted로 둔다.

streaming UI에서 reasoning progress를 보여주던 제품은 갑자기 긴 침묵처럼 보일 수 있다.

필요하면 thinking.display를 "summarized"로 명시해야 한다.

네 번째는 assistant prefill이다.

migration guide는 assistant message prefill을 제거하고 structured outputs, system prompt instruction, output_config.format 같은 대안을 쓰라고 안내한다.

다섯 번째는 max_tokens다.

tokenizer 변화 때문에 기존 max token 여유가 부족해질 수 있다.

특히 compaction trigger나 긴 output을 기대하는 agent loop는 headroom을 더 줘야 한다.

전환 체크리스트로 줄이면 이렇다.

  • 모델명을 claude-opus-4-7로 바꾼다.
  • temperature, top_p, top_k를 request에서 제거한다.
  • thinking.budget_tokens를 adaptive thinking + effort로 바꾼다.
  • reasoning 표시 UI가 있으면 display: summarized 여부를 정한다.
  • assistant prefill 사용 여부를 찾는다.
  • client-side token estimation을 다시 검증한다.
  • max_tokens와 compaction trigger를 다시 잡는다.
  • 이미지 input이 있으면 resolution과 token 예산을 다시 잡는다.
  • high, xhigh, max effort별 비용과 성공률을 비교한다.
  • 4.6 fallback route를 남긴다.

이 중 하나라도 자동화 코드에 숨어 있으면 배포 후에만 보인다.

배포 후에만 보이는 설정은 대체로 기분이 나쁘다.

그러니 검색은 지금 하는 게 싸다.

xhigh는 언제 쓰나

Opus 4.7의 새 effort level 중 눈에 띄는 건 xhigh다.

공식 migration guide는 coding과 agentic use case에서 xhigh를 좋은 시작점으로 제안한다.

다만 이걸 모든 요청의 기본값으로 두면 안 된다.

xhigh는 “항상 더 좋은 답변 버튼”이 아니라 “더 어려운 작업에 더 많은 생각을 허용하는 버튼”에 가깝다.

나는 아래처럼 쓸 것 같다.

effort 적합한 작업 피해야 할 작업
low 짧고 범위가 좁은 작업 다단계 추론
medium 비용 민감한 일반 작업 책임 큰 판단
high 대부분의 실무 코딩·리뷰 극단적 장기 작업
xhigh 복잡한 refactor, agent loop, 어려운 bug hunt 짧은 질답
max 내부 eval로 이득이 확인된 난제 기본값 사용

특히 low와 medium에서는 4.7이 요청 범위를 더 엄격하게 지킨다고 문서가 말한다.

이건 장점이자 리스크다.

간단한 작업에서는 비용을 줄인다.

복잡한 작업에서는 덜 생각할 수 있다.

그래서 prompt로 억지로 길게 생각하라고 하는 것보다 effort를 올리는 게 맞다.

반대로 단순 작업에 xhigh를 걸면 모델이 너무 정성스럽게 삽질할 수 있다.

성실한 삽질은 여전히 삽질이다.

비싼 삽질이면 더 슬프다.

4.7이 4.6보다 실무적으로 나은 경우

첫 번째는 어려운 코드 리뷰다.

PR에서 단순 스타일이 아니라 상태 전이, 권한 경계, 비동기 오류, race condition을 봐야 한다면 4.7 테스트 가치가 크다.

초기 테스터 사례들도 code review와 bug finding에서 4.6 대비 개선을 언급한다.

다만 이 수치는 각 회사 내부 benchmark가 많다.

우리 workflow에서는 직접 재야 한다.

두 번째는 긴 agent loop다.

도구를 여러 번 쓰고, 실패를 복구하고, 중간 판단을 바꿔야 하는 작업이다.

4.7은 장기 작업의 일관성, 자체 검증, progress update가 개선됐다고 설명된다.

Claude Code에서 긴 작업을 맡기는 사람에게는 바로 테스트할 이유가 있다.

세 번째는 고해상도 비전이다.

스크린샷, UI, 차트, 복잡한 technical diagram은 4.7의 해상도 확장이 직접 영향을 준다.

특히 computer-use agent가 화면을 보고 좌표를 찍는 경우에는 1:1 pixel coordinate가 도움이 된다.

네 번째는 문서·슬라이드·워크 문서 편집이다.

공식 문서는 .docx redlining, .pptx editing, chart analysis, figure analysis 같은 knowledge work에서 개선을 말한다.

우리 블로그 파이프라인이나 문서 자동화 쪽에서도 이건 눈여겨볼 만하다.

다섯 번째는 memory-heavy workflow다.

발표문은 4.7이 file system-based memory를 더 잘 쓴다고 설명한다.

Obsidian이나 프로젝트 메모를 들고 긴 세션을 이어가는 작업에서는 이 부분이 중요하다.

다만 이 역시 “공식 설명”과 “내 볼트에서 실제로 덜 까먹는지”는 별개다.

운영자는 좋다는 말을 믿되, 바로 청구서에 연결하지는 않는다.

4.6을 남겨야 하는 경우

4.7이 나왔다고 4.6을 바로 지울 필요는 없다.

fallback은 겁이 많아서 남기는 게 아니다.

운영을 아는 사람이 남기는 것이다.

첫 번째는 기존 API가 4.6 payload에 맞춰져 있을 때다.

특히 sampling parameter, old thinking budget, prefill을 쓰는 코드라면 4.6 route를 유지해야 한다.

두 번째는 비용 예측성이 더 중요할 때다.

4.7은 단가는 같지만 token count가 달라질 수 있다.

대량 처리에서는 이 차이가 월말에 크게 보일 수 있다.

세 번째는 prompt가 4.6의 느슨한 해석에 맞춰져 있을 때다.

4.7은 더 literal하게 지시를 따른다고 문서가 설명한다.

잘 쓴 prompt에는 장점이다.

애매한 prompt에는 결과 변화다.

네 번째는 짧고 단순한 작업이다.

모든 작업이 Opus 4.7을 필요로 하지는 않는다.

고급 모델을 켜는 순간 latency와 비용도 같이 후보가 된다.

다섯 번째는 cloud provider별 가용성이 아직 팀 운영 조건과 맞지 않을 때다.

Anthropic API, Bedrock, Vertex, Microsoft Foundry 모두에서 사용할 수 있다고 발표됐지만, 실제 region, endpoint, pricing, preview 표기는 플랫폼별로 다시 확인해야 한다.

특히 기업 환경에서는 모델 자체보다 배포 경로가 더 느릴 때가 있다.

이럴 땐 4.6을 안정 경로로 남기고, 4.7은 실험 경로로 두는 게 맞다.

모델 전환은 용감하게 할 일이 아니다.

측정 가능하게 할 일이다.

내 워크플로우라면 이렇게 테스트한다

이번 글의 직접 확인 범위는 API benchmark 실행이 아니다.

공식 문서, 기존 TECHTAEK 4.7 전환 글, Opus 4.6 1M context 글, 그리고 blog pipeline 기준을 대조해 운영 전환표를 만든 것이다.

그래서 “4.7이 내 코드에서 몇 퍼센트 더 좋았다”라고 말하지 않는다.

그건 다음 실측에서 해야 할 일이다.

내가 바로 실측한다면 태스크는 세 개로 나눈다.

첫 번째는 bug hunt다.

실패 테스트 로그와 관련 파일 몇 개를 주고 root cause를 찾게 한다.

비교 기준은 원인 후보 정확도, 불필요한 파일 탐색 수, 재시도 횟수다.

두 번째는 refactor plan이다.

작은 repo가 아니라 변경 범위가 여러 모듈에 걸친 작업을 준다.

비교 기준은 단계 분해, rollback plan, test plan, 사람 수정 시간이다.

세 번째는 review session이다.

의도적으로 edge case가 있는 diff를 주고 review recall과 precision을 본다.

비교 기준은 실제 버그 탐지, false positive, 놓친 문제다.

각 태스크는 네 경로로 돌린다.

경로 목적
Opus 4.6 기존 설정 baseline
Opus 4.7 high 기본 전환 후보
Opus 4.7 xhigh 어려운 작업 후보
Sonnet 4.6 또는 저비용 모델 비용 기준선

이렇게 돌려야 “4.7이 좋다”가 아니라 “4.7을 어디에 쓰면 돈값을 하는지”가 보인다.

특히 Claude Code에서는 사람이 최종 리뷰하는 시간이 중요하다.

AI가 10분 더 생각해도 사람이 30분 덜 고치면 이긴다.

반대로 AI가 멋지게 길게 썼는데 사람이 그대로 다시 읽느라 시간이 늘면 진 것이다.

생산성은 모델 토큰이 아니라 사람 시간으로 닫힌다.

실수 TOP 5

1. 가격표만 보고 비용이 같다고 착각한다

Opus 4.7과 Opus 4.6의 공식 단가는 같다.

하지만 4.7은 새 tokenizer를 사용한다.

같은 text가 이전 모델보다 최대 약 35% 더 많은 token으로 잡힐 수 있다고 문서가 설명한다.

또 effort가 높으면 생각과 출력이 늘 수 있다.

따라서 비용 비교는 단가가 아니라 실제 token log로 해야 한다.

2. temperature=0를 그대로 둔다

기존 wrapper에 temperature=0이 기본값으로 들어가 있는 경우가 많다.

Opus 4.7은 temperature, top_p, top_k 비기본값을 받으면 400 에러를 낼 수 있다.

가장 안전한 마이그레이션은 payload에서 제거하는 것이다.

결정론이 필요하면 parameter가 아니라 prompt와 평가 harness를 조정해야 한다.

3. old thinking budget을 그대로 쓴다

thinking: {"type": "enabled", "budget_tokens": N} 방식은 4.7에서 그대로 쓰면 안 된다.

adaptive thinking과 output_config.effort로 옮겨야 한다.

이건 단순 문법 변경이 아니라 비용·latency 정책 변경이다.

4. 고해상도 이미지를 무조건 원본으로 넣는다

Opus 4.7은 이미지를 더 잘 본다.

그렇다고 모든 이미지를 원본으로 던질 이유는 없다.

정밀 좌표가 필요한 UI screenshot과 단순 참고용 문서는 다르다.

이미지 input 정책을 나누지 않으면 token 비용이 오른다.

5. 4.6 fallback을 너무 빨리 지운다

새 모델 전환에서 fallback은 보험이다.

특히 API backend, 자동화 배치, 고객-facing workflow는 4.6 route를 남겨야 한다.

4.7이 더 좋아도, 장애 순간에는 이미 검증된 경로가 필요하다.

멋진 모델보다 빠른 rollback이 더 실무적일 때가 많다.

언제 바로 바꿔도 되고 언제 기다려야 하나

바로 바꿔볼 만한 곳은 실패해도 복구가 쉽고, 4.7의 장점이 잘 드러나는 작업이다.

예를 들면 개인 Claude Code 세션, 내부 code review 보조, 리팩터링 계획 초안, 문서 이미지 분석이다.

이런 곳은 4.7을 켜보고 결과를 비교해도 부담이 작다.

반대로 기다려야 하는 곳은 자동화된 production route다.

특히 고객 요청을 처리하거나, 비용이 대량으로 쌓이거나, reasoning stream을 UI에 보여주는 서비스는 한 번에 바꾸면 안 된다.

기존 request payload audit이 먼저다.

그다음 shadow test.

그다음 일부 traffic.

마지막으로 default 전환이다.

내 기준은 아래와 같다.

단계 할 일 통과 기준
1단계 payload audit breaking parameter 0개
2단계 token count 비교 비용 증가 허용선 정의
3단계 3개 대표 태스크 실측 품질·사람시간 개선 확인
4단계 fallback route 유지 배포 rollback 가능
5단계 default 전환 7일 로그 안정

모델 업데이트가 빠를수록 이 절차가 더 중요해진다.

매번 감으로 바꾸면 팀은 모델을 쓰는 게 아니라 모델 출시 일정에 끌려다닌다.

좋은 도구를 쓰는 일과 도구에 휘둘리는 일은 다르다.

차이는 보통 체크리스트 한 장에서 갈린다.

FAQ

Q1. Claude Opus 4.7은 Opus 4.6보다 무조건 좋은가?

A. 공식 자료 기준으로 Opus 4.7은 Opus 4.6보다 어려운 코딩, 장기 에이전트, 고해상도 비전, 지시 준수, 자체 검증에서 개선된 모델이다. 다만 모든 작업에서 무조건 더 경제적인 것은 아니다. 단순 작업이나 비용 민감한 대량 처리에서는 4.6 또는 Sonnet 계열이 더 맞을 수 있다.

Q2. 가격이 같으면 그냥 4.7로 바꾸면 되나?

A. 아니다. 공식 단가는 둘 다 입력 100만 토큰당 5달러, 출력 100만 토큰당 25달러다. 하지만 4.7은 새 tokenizer를 사용해서 같은 text가 최대 약 35% 더 많은 token으로 잡힐 수 있고, 높은 effort에서는 output token과 latency가 늘 수 있다.

Q3. Claude Code에서는 어떤 effort로 시작하는 게 좋나?

A. 복잡한 코딩과 agentic task는 high 또는 xhigh부터 테스트하는 게 좋다. 짧은 질문이나 단순 수정은 medium으로 충분할 수 있다. max는 내부 eval에서 실제 이득이 보일 때만 쓰는 편이 안전하다.

Q4. 기존 API에서 가장 먼저 확인할 부분은?

A. temperature, top_p, top_k, thinking.budget_tokens, assistant prefill을 먼저 찾는 게 좋다. Opus 4.7에서는 sampling parameter 비기본값이 400 에러를 만들 수 있고, thinking 방식도 adaptive thinking과 effort 중심으로 바뀐다.

Q5. Opus 4.7의 고해상도 비전은 어디에 유용한가?

A. 스크린샷 기반 agent, UI 좌표 판단, 복잡한 다이어그램, 차트, 문서 이미지 분석에 유용하다. 긴 변 최대 2576px, 약 3.75MP까지 지원하고 좌표가 실제 픽셀과 1:1로 맞는다고 문서가 설명한다. 다만 image token 비용은 다시 봐야 한다.

Q6. 4.6 fallback은 얼마나 오래 남겨야 하나?

A. 개인 작업은 짧게 남겨도 되지만, API backend나 자동화 배치는 최소 1주일 이상 로그를 보며 남기는 게 좋다. token count, latency, 400 error, tool error, 사람 수정 시간을 비교한 뒤 default를 바꾸는 편이 안전하다.

Q7. Opus 4.7과 Sonnet 4.6은 어떻게 나눠 쓰면 되나?

A. 넓은 문서 정리, 초안, 반복 처리, 비용 민감한 작업은 Sonnet 계열을 먼저 쓴다. 복잡한 판단, 장기 agent loop, 큰 코드 리뷰, 고해상도 vision, 실패 비용이 큰 리팩터링은 Opus 4.7을 테스트한다. 모든 작업을 Opus로 보내면 모델 라우팅의 장점이 사라진다.

공식 출처

관련 글