최근 Opus 4.6과 4.7의 요청·토큰 비교를 익명 집계로 볼 수 있는 보드가 나오면서, "새 모델이 더 잘하나?"보다 "같은 일을 시켰을 때 토큰과 행동이 어떻게 달라지나?"가 더 현실적인 질문이 됐습니다.1 지금 중요한 이유는 간단합니다. 모델 업그레이드는 벤치마크에서 실패하지 않고, 실제 워크플로에서 실패하기 때문입니다. 작은 응답 습관 하나가 팀의 시간을 아끼기도 하고, 반대로 잘 돌아가던 자동화를 조용히 망가뜨리기도 합니다.
Opus 4.7은 표면적으로는 4.6의 직계 업그레이드입니다. 가격은 같고, 1M 컨텍스트와 128K 출력 한도도 유지됩니다. 하지만 내부 동작은 꽤 달라졌습니다. 더 엄격한 지시 준수, 더 강한 장기 에이전트 작업, 더 높은 해상도의 비전, 새 토크나이저, 그리고 일부 API 동작 변경까지 들어왔습니다.23 그래서 판단 기준도 "더 좋다/나쁘다"가 아니라 "어떤 실수를 덜 하게 됐고, 어떤 비용을 더 내게 됐는가"로 바뀌어야 합니다.
좋아진 것은 정답률보다 재작업 비용이다
확인된 사실부터 보죠. Anthropic은 Opus 4.7이 코딩, 장기 에이전트 작업, 비전, 메모리 사용에서 개선됐다고 설명합니다. 공개된 수치에서도 SWE-bench Pro는 53.4%에서 64.3%, SWE-bench Verified는 80.8%에서 87.6%로 올랐고, MCP-Atlas 같은 에이전트 벤치마크도 큰 폭으로 상승했습니다.3 이미지 해상도는 약 1.15MP에서 3.75MP로 커졌습니다.2
실무적으로 더 중요한 건 성능표가 아니라 행동 변화입니다. 4.7은 지시를 더 문자 그대로 따르고, 장기 작업에서 자기 검증을 더 하며, 기본적으로는 툴 호출을 줄이고 추론을 더 쓰는 쪽으로 바뀌었습니다.2 이건 "한 번에 맞히는 확률"보다 "틀렸을 때 얼마나 비싸게 틀리는가"에 영향을 줍니다.
예를 들어 코딩 에이전트에서는 4.6이 그럴듯하지만 검증이 빈약한 수정안을 내는 문제가 있었다면, 4.7은 테스트·점검을 더 하면서 그런 재작업을 줄일 가능성이 큽니다. 반대로 짧고 단순한 자동화에서는 그 꼼꼼함이 과잉 처리로 느껴질 수 있습니다. 토큰도 더 쓰고, 응답이 늦어질 수 있습니다.
실제로 4.7은 새 토크나이저 때문에 같은 텍스트가 1.0~1.35배 토큰으로 계산될 수 있다고 공식 문서가 밝힙니다.2 가격표는 같아도 청구서는 같지 않을 수 있다는 뜻입니다. 익명 요청·토큰 비교 보드가 흥미로운 이유도 여기에 있습니다. 모델 변경의 체감은 "정답률"보다 "요청당 토큰 구조"에서 먼저 드러나기 쉽기 때문입니다.1
기능표보다 '못 견디는 실패'로 고르는 편이 정확하다
어떤 모델이 맞는지는 기능이 아니라 실패 모드로 정하는 편이 낫습니다.
코드 수정이 자주 깨지는 팀이라면 4.7 쪽이 더 맞습니다. CursorBench 70% 대 58%, SWE 계열 상승폭을 보면 특히 어려운 소프트웨어 작업에서 개선이 집중돼 있습니다.34 "한 번 더 고쳐야 하는 코드"가 비싼 조직일수록 업그레이드 이익이 큽니다.
비전이나 스크린샷 이해가 핵심이면 4.7이 사실상 기본 선택입니다. 해상도 자체가 크게 올라갔고, 좌표가 픽셀과 1:1로 맞춰져 컴퓨터 유스나 문서·차트 분석 파이프라인이 단순해졌습니다.2
반면 프롬프트가 오래 다듬어진 생산 자동화라면 이야기가 달라집니다. 4.7은 더 literal합니다. 4.6이 적당히 추론해 메워주던 빈칸을 4.7은 그냥 비워둘 수 있습니다.2 이건 품질 저하가 아니라 규칙 변경에 가깝습니다. 특히 JSON 출력, 엄격한 포맷, 항목별 지시가 많은 시스템에서는 좋아질 가능성이 크지만, "눈치껏 해줘"류 프롬프트는 오히려 깨질 수 있습니다.
또 하나는 긴 문맥입니다. 공식 마케팅 메시지는 장기 작업 개선에 초점이 맞춰져 있지만, 커뮤니티에서는 4.7의 장문맥 검색 성능 저하를 지적하는 논의도 있었습니다.5 이 부분은 공개 자료 해석이 엇갈리므로 단정할 수는 없습니다. 다만 "1M 컨텍스트 지원"과 "아주 긴 문맥에서 원하는 항목을 안정적으로 집어낸다"는 같은 말이 아니라는 점은 분명합니다. 긴 문서를 통째로 넣는 작업이 핵심이라면, 에이전트 성능만 보고 바로 바꾸기보다 자체 테스트가 먼저입니다.
그래서 4.6이 더 나은 팀도 있다
벤치마크상 더 강한 모델이 항상 더 좋은 운영 선택은 아닙니다.
첫째, 검증 비용이 있습니다. 4.7은 temperature, top_p, top_k 비기본값을 허용하지 않고, 4.6의 extended thinking budget도 더 이상 쓰지 않습니다.2 단순한 모델 교체가 아니라 API 계약 변경에 가깝습니다. 프로덕션에서 회귀 테스트가 필요한 이유입니다.
둘째, 신뢰 비용이 있습니다. 팀이 이미 4.6 출력 형태를 기준으로 후처리, 평가, 승인 루프를 맞춰놨다면, 더 좋은 답변보다 "예상 가능한 답변"이 중요할 수 있습니다. 특히 출력 형식이 downstream 시스템에 바로 연결되어 있으면 더 그렇습니다.
셋째, 비용 추정이 흔들립니다. 4.7은 토크나이저 변화와 노력 수준(effort) 증가가 겹치면 토큰 사용량이 달라질 수 있습니다.2 어떤 파이프라인에서는 모델 호출 수와 툴 호출 수가 줄어 총비용이 내려갈 수도 있지만,6 그건 보편 법칙이 아니라 워크로드별 결과입니다.
30분만에 해볼 수 있는 업그레이드 판별법
중요한 워크플로를 바로 바꾸지 말고, 대표 작업 4개만 비교해보면 됩니다.
첫째, 평소 가장 돈이 많이 드는 작업 2개를 고릅니다. 코드 수정, 긴 문서 분석, UI 스크린샷 해석, 툴 사용형 자동화처럼 실제 업무여야 합니다.
둘째, 품질만 보지 말고 네 가지를 같이 봅니다. 완료까지 걸린 총 토큰, 툴 호출 수, 출력 형식 안정성, 그리고 사람이 다시 손본 횟수입니다.
셋째, 4.7에서 특히 봐야 할 경고 신호는 이렇습니다.
프롬프트를 너무 문자 그대로 읽어 누락이 생긴다.
같은 입력인데 토큰이 예상보다 크게 늘어난다.
생각은 깊어졌지만 단순 작업에서 과하게 느리다.
긴 문맥에서 필요한 정보 집기가 불안정하다.
이 중 두 개 이상이 핵심 워크플로에서 보이면, 4.7을 전면 교체가 아니라 선택적 투입 모델로 보는 편이 낫습니다. 코딩 에이전트와 비전 작업은 4.7, 비용 민감한 짧은 자동화는 4.6 유지 같은 식입니다.
결국 지금 신경 써야 하는 사람은 "최신 모델을 쓰고 싶은 사람"이 아니라 "모델의 작은 습관 변화가 운영비와 실패 비용을 바꾸는 사람"입니다. 코드 에이전트, 문서 워크플로, 비전 파이프라인, 장기 자동화를 돌리는 팀이라면 Opus 4.7은 충분히 볼 가치가 있습니다. 하지만 이미 검증된 4.6 시스템을 가진 팀이라면, 질문은 하나입니다. 더 똑똑한 모델이 필요한가, 아니면 더 예측 가능한 시스템이 필요한가.
참고
1Anonymous request-token comparisons from Opus 4.6 and Opus 4.7
2What's new in Claude Opus 4.7 - Claude API Docs
5Claude Opus 4.7 Model Card | Hacker News
6Anthropic reveals new Opus 4.7 model with focus on advanced software engineering
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.