클로드 오퍼스(Opus) 4.7 출시 | 달라진 점과 바로 확인할 부분

이번 업데이트에서 바로 봐야 할 변화

클로드 오퍼스 4.7은 Anthropic이 현재 일반 공개 중인 모델 가운데 가장 강한 모델이라고 내놓은 버전입니다. 공식 문서 기준으로 보면 1M 컨텍스트, 최대 출력 128k, adaptive thinking, 각종 도구 사용 환경은 이어가면서 코딩과 장기 작업, 비전, 메모리 활용 쪽을 더 밀어 올린 형태입니다.

이번 업데이트에서 눈에 띄는 변화는 다섯 가지입니다. 첫째, 코딩과 에이전트 작업 쪽 성능을 강하게 밀고 있습니다. 둘째, 고해상도 이미지 지원이 들어갔습니다. 셋째, xhigh effort가 새로 추가됐습니다. 넷째, 전체 작업 흐름에 대한 task budget 베타가 생겼습니다. 다섯째, API 쪽에서는 이전 방식 그대로 쓰면 깨질 수 있는 항목이 생겼습니다.

그래서 이번 글은 “성능이 좋아졌다”는 말보다 무엇이 실제로 달라졌는지, 어디서 바로 차이가 나는지, 기존 사용자가 뭘 먼저 고쳐야 하는지에 맞춰 정리하는 쪽이 더 낫습니다.

가격은 그대로인데 왜 비용 얘기가 나오나

공식 가격표만 보면 Opus 4.6과 같습니다. 입력 100만 토큰당 5달러, 출력 100만 토큰당 25달러입니다. 겉으로는 가격 인상이 없으니 부담이 그대로라고 느끼기 쉽습니다.

문제는 토큰 계산 방식입니다. 공식 문서에서는 Opus 4.7이 새 토크나이저를 써서 같은 텍스트라도 이전보다 대략 1배에서 1.35배 정도 더 많은 토큰으로 계산될 수 있다고 안내합니다. 즉 단가는 그대로인데, 실제 청구 기준이 되는 토큰 수는 늘어날 수 있다는 뜻입니다.

이 차이는 프롬프트가 긴 팀일수록 더 민감합니다. 대용량 문서를 계속 넣거나, 긴 시스템 프롬프트와 긴 대화 이력을 매번 붙이는 방식이라면 체감 비용이 올라갈 수 있습니다. 반대로 이전보다 한 번에 더 잘 끝나서 재시도 횟수가 줄면 총비용은 크게 차이 나지 않을 수도 있습니다. 결국 중요한 건 가격표보다 실제 워크로드 기준 토큰 사용량입니다.

코딩과 에이전트 작업은 얼마나 달라졌나

이번 발표에서 Anthropic이 가장 세게 밀고 있는 영역은 코딩과 에이전트 작업입니다. 공식 설명을 보면 복잡한 소프트웨어 엔지니어링, 긴 작업을 이어가는 능력, 검증과 복구를 포함한 장기 흐름에서 Opus 4.6보다 좋아졌다는 쪽에 초점이 맞춰져 있습니다.

이게 왜 중요하냐면, 실무에서 체감 성능은 한 번 멋진 답을 내놓는 것보다 중간에 덜 멈추는지, 잘못 갔을 때 다시 돌아오는지, 끝까지 검토하는지에서 갈리는 경우가 많기 때문입니다. 특히 코드 리뷰, 멀티파일 수정, 디버깅, 도구를 섞어 쓰는 작업은 정답률 숫자 하나만으로 평가하기 어렵습니다.

초기 사용 반응도 비슷합니다. 군더더기 래퍼 함수가 줄었다, 잘못된 가정을 밀어붙이기보다 다시 확인하는 편이다, 긴 작업에서 흐름이 덜 끊긴다는 식의 평가가 나옵니다. 딱 잘라 말하면 “엄청 달라졌다”보다 덜 헛돌고 덜 부풀린다는 쪽에서 체감이 먼저 온다는 얘기입니다.

또 한 가지는 도구 사용 성향입니다. 공식 문서에서는 Opus 4.7이 기본적으로 도구를 덜 쓰고 reasoning을 더 쓰는 방향이라고 설명합니다. 대신 effort를 올리면 도구 사용도 더 늘어날 수 있습니다. 이미 자동화 파이프라인을 짜둔 팀이라면 이 차이 때문에 같은 프롬프트도 결과 흐름이 달라질 수 있습니다.

이미지와 문서 읽기는 왜 주목받나

Opus 4.7은 Claude 계열에서 처음으로 더 높은 해상도의 이미지를 다룰 수 있게 됐습니다. 공식 문서 기준 최대 해상도는 긴 변 2576픽셀, 약 3.75메가픽셀 수준입니다. 이전 한계보다 확실히 올라간 수치입니다.

이 변화는 단순히 이미지가 더 선명하게 보인다는 정도가 아닙니다. 복잡한 스크린샷, 작은 글자가 많은 문서, 차트와 기술 도표, 컴퓨터 사용 에이전트 화면처럼 세부 정보가 중요한 작업에서 의미가 큽니다. 좌표도 실제 픽셀과 1:1로 맞춰진다고 설명돼 있어, 화면 위 특정 위치를 찍는 작업도 이전보다 단순해집니다.

그래서 화면 읽기, 문서 검토, 슬라이드 수정, 차트 확인, 도표 해석이 필요한 팀은 이번 업데이트를 더 주의 깊게 보는 분위기입니다. 반면 아무 이미지나 무조건 원본 해상도로 넣는 방식은 비용 면에서 비효율이 커질 수 있습니다. 고해상도 이미지는 그만큼 토큰도 더 많이 쓰기 때문입니다.

결국 이 기능은 “있으면 좋다”가 아니라 터미널 캡처, 문서 이미지, UI 화면 분석이 실제 업무에 들어가는 사람에게는 바로 쓸 만한 개선에 가깝습니다.

API 사용자가 꼭 체크할 변경사항

이번 모델에서 가장 조심해야 할 부분은 API 변경입니다. 기존 Opus 4.6 코드를 거의 손대지 않고 모델명만 바꾸면 끝날 것 같지만, 실제로는 확인할 항목이 적지 않습니다.

첫째, extended thinking budget 방식이 빠졌습니다. 이전처럼 thinking에 budget_tokens를 주는 코드는 Opus 4.7에서 400 에러가 날 수 있습니다. 이제는 adaptive thinking을 켜고 effort로 깊이를 조절하는 방식으로 바꿔야 합니다.

둘째, temperature·top_p·top_k를 비기본값으로 넣으면 에러가 날 수 있습니다. 특히 예전 습관대로 temperature 0을 넣어두던 코드가 있다면 먼저 점검해야 합니다. 공식 문서는 가장 안전한 방법으로 이 파라미터들을 요청에서 아예 빼는 쪽을 권합니다.

셋째, thinking 내용은 기본적으로 생략됩니다. reasoning 과정을 화면에 보여주던 제품이라면 이전보다 답이 늦게 시작되는 것처럼 느껴질 수 있습니다. 넷째, 새 토크나이저 때문에 max_tokens와 컨텍스트 압축 기준도 다시 잡아야 합니다.

추가로 프롬프트 해석 방식도 달라졌습니다. Opus 4.7은 이전보다 지시를 더 문자 그대로 따르는 편이라, 예전에는 적당히 알아서 보정하던 모호한 문장이 이제는 그대로 반영될 수 있습니다. 구조화 출력이나 추출 작업에는 장점이지만, 느슨한 프롬프트를 오래 써온 팀이라면 결과가 꽤 달라질 수 있습니다.

초기 반응은 어떻게 갈리나

초기 반응은 전체적으로 긍정적인 편입니다. 특히 코딩, 장기 작업 지속성, 도구 사용 정확도, 화면과 문서 읽기 쪽에서 기대감이 큽니다. “기존보다 끝까지 해준다”, “코드가 덜 복잡하다”, “실패해도 다시 수습한다”는 식의 반응이 반복됩니다.

다만 모든 평가가 한 방향은 아닙니다. 커뮤니티 일부에서는 긴 컨텍스트에서 필요한 정보를 끄집어내는 능력, 즉 장문 회수 성능 쪽은 아쉽다는 지적도 나옵니다. 이런 평가는 특히 아주 긴 문맥을 한 번에 몰아넣고 그 안에서 정확한 회수를 기대하는 사용자에게 더 민감할 수 있습니다.

그래서 이 모델을 볼 때는 “무조건 상위 호환”보다는 어떤 작업에서 좋아졌고 어떤 작업은 다시 확인해야 하는가로 보는 편이 맞습니다. 코딩과 에이전트 흐름은 좋아졌다고 보는 쪽이 우세하지만, 초장문 회수 성능이 핵심인 사용자는 실제 데이터로 한 번 더 비교해보는 편이 안전합니다.

누가 바로 써볼 만한가

코딩 비중이 높은 사람, 멀티스텝 자동화나 에이전트 작업을 많이 돌리는 팀, 화면 캡처·문서 이미지·차트 분석이 중요한 사용자는 Opus 4.7을 빠르게 테스트해볼 만합니다. 이쪽은 이번 업데이트가 왜 나왔는지 비교적 분명하게 드러나는 구간입니다.

반대로 기존 프롬프트가 느슨하게 짜여 있거나, 긴 문맥에서 특정 정보를 안정적으로 회수하는 작업이 핵심이거나, 토큰 예산이 아주 빡빡한 환경이라면 바로 전면 교체보다는 샘플 워크로드로 먼저 비교하는 편이 낫습니다.

정리하면 이렇습니다. 코딩·에이전트·비전 중심이면 빠르게 검토할 가치가 크고, 기존 프롬프트 안정성과 장문 회수가 더 중요하면 검증 후 넘어가는 편이 맞습니다.