Claude Opus 4.7 출시 — adaptive thinking 전환과 3가지 breaking change

4월 16일, Anthropic이 Claude Opus 4.7을 공개했다. 가격표는 입력 100만 토큰당 5달러, 출력 100만 토큰당 25달러로 Opus 4.6과 완전히 동일하지만, 어제 돌아가던 budget_tokens 코드는 오늘 400 에러로 터진다. 이유는 단 하나, adaptive thinking(적응형 추론)이 Opus 4.7의 유일한 추론 모드가 됐기 때문이다.

나는 아침에 프로덕션 봇의 모델 ID를 claude-opus-4-6에서 claude-opus-4-7로 한 글자만 바꿨다가 전체 파이프라인이 멈추는 걸 목격했다. 문제는 이게 로그에 "model deprecated" 같은 친절한 경고를 찍어주지 않는다는 점이다. 그냥 400 Bad Request가 나오고, 에러 메시지를 열어야 비로소 thinking.type 필드가 거절됐다는 사실을 알 수 있다. 이번 글은 그 한 글자 뒤에 숨어 있던 세 가지 breaking change를 해부한다.

Opus 4.7 스펙 한 페이지 요약

먼저 숫자부터. 모델 ID는 claude-opus-4-7, 컨텍스트 윈도우는 100만 토큰(1M), 최대 출력은 12.8만 토큰, 지식 컷오프는 2026년 1월이다. 비전 입력은 긴 변 기준 2,576픽셀까지, 약 3.75 메가픽셀을 지원하는데 이는 이전 Claude 모델 대비 픽셀 기준 3배 이상이다. 배포 채널은 공식 Claude API, Amazon Bedrock(리서치 프리뷰), Google Vertex AI, Microsoft Foundry 네 곳이다.

가격은 입력 5달러, 출력 25달러로 Opus 4.6과 같다. 그러나 같은 숫자가 곧 같은 청구서를 의미하지 않는다. Opus 4.7은 새 tokenizer(토큰화기)를 탑재했고, 동일한 텍스트가 1.0배에서 1.35배 사이로 더 많은 입력 토큰으로 잘린다. 공식 문서 툴팁에 따르면 Opus 4.6에서는 100만 토큰이 영어 약 75만 단어 분량이었지만, Opus 4.7에서는 같은 100만 토큰이 약 55.5만 단어로 줄어든다. 콘텐츠가 한국어나 코드일수록 이 배율이 크게 튀는 걸 내 Trading 봇 로그에서 확인했다. 단가가 그대로인데 같은 프롬프트가 잘릴 때 토큰 수가 늘어나면, 실제 월 청구서는 최대 35% 오른다. 공식 배율 범위를 반영해 보수적으로 잡아도 20% 전후의 인상은 각오해야 한다.

Anthropic은 이 외에도 "instruction following이 현저히 개선됐다"와 "Opus 4.6 대비 agentic coding에서 step-change 수준 향상"을 공식 문구로 내걸었다. multi-session memory도 개선 대상에 올랐다. 함께 공개된 Claude Mythos Preview는 초대제 Project Glasswing 경로로만 제공되는 별도 모델인데, UK AISI 평가에서 "통상 20 인간 시간이 걸리는 32단계 네트워크 시뮬레이션을 자율적으로 실행"한 기록이 언급됐다. 여기까지가 헤드라인이고, 문제는 이제부터다.

Breaking change 1 — adaptive thinking이 유일한 추론 모드다

지금까지 Claude의 extended thinking API는 thinking: {type: "enabled", budget_tokens: 10000} 형태로 호출했다. Opus 4.7은 이 형태를 400 Bad Request로 거절한다. 대체 경로는 adaptive thinking 공식 문서가 규정한 thinking: {type: "adaptive"}뿐이다. budget_tokens 필드 자체가 거부된다.

코드로 비교하면 차이가 분명하다. 기존 코드는 다음과 같다.

const response = await client.messages.create({
  model: "claude-opus-4-6",
  max_tokens: 16000,
  thinking: {
    type: "enabled",
    budget_tokens: 10000,
  },
  messages: [{ role: "user", content: task }],
});

for (const block of response.content) {
  if (block.type === "thinking") {
    console.log(block.thinking);
  }
}

Opus 4.7로 옮기면 이렇게 바뀐다.

const response = await client.messages.create({
  model: "claude-opus-4-7",
  max_tokens: 16000,
  thinking: { type: "adaptive", display: "summarized" } as any,
  output_config: { effort: "high" } as any,
  messages: [{ role: "user", content: task }],
});

타입을 "adaptive"로 고정하고, budget_tokens 대신 output_config.effort로 추론 강도를 조절한다. SDK 타입 정의가 아직 따라오지 못해 당분간 as any 캐스팅이 필요하다. Opus 4.6과 Sonnet 4.6에서는 기존 type: "enabled"가 deprecated 상태로 아직 동작하지만, 새 코드에 남겨두면 다음 분기 마이그레이션 리스트에 그대로 축적된다.

adaptive 모드의 숨겨진 보너스는 interleaved thinking(도구 간 추론)이 기본 켜진다는 점이다. 에이전트가 tool call 사이사이에 추론 블록을 삽입해, 검색 결과를 본 뒤에 다음 검색어를 고쳐 잡는 식의 흐름이 API 한 줄로 가능해진다. 이 부분이 "agentic coding step-change" 주장의 구조적 근거다.

또 하나 바뀐 디폴트: Opus 4.7에서는 thinking 자체가 기본 OFF다. 명시적으로 thinking: {type: "adaptive"}를 넣지 않으면 추론 블록이 아예 생성되지 않는다. "기본적으로 추론이 켜져 있었다"는 기억을 가진 사람이 모델 ID만 바꾸면, 비싼 추론이 은근슬쩍 꺼진 상태로 몇 시간 동안 낮은 품질의 답변을 받게 된다.

Breaking change 2 — thinking.display 기본값이 조용히 바뀌었다

두 번째 지뢰는 더 악질이다. thinking.display의 기본값이 Opus 4.6의 "summarized"에서 Opus 4.7의 "omitted"로 바뀌었다. 이 한 줄이 바뀌면, 응답의 thinking 블록에서 block.thinking 필드가 빈 문자열로 돌아온다. 에러는 나지 않는다. 그냥 사용자에게 추론 과정을 보여주던 UI가 어느 날부터 빈 공간을 띄울 뿐이다.

내 LLMTrio 프로젝트에서 "Claude가 어떻게 생각했는지" 펼쳐 보여주던 토글 컴포넌트는 배포 후 30분 만에 피드백이 들어왔다. "추론창이 비었다." 원인을 찾기 위해 서버 로그를 뒤지다가, 응답에는 thinking 블록이 존재하지만 내부 문자열만 비었다는 걸 발견했다. 해결은 한 줄이다. thinking: {"type": "adaptive", "display": "summarized"}를 명시적으로 넣으면 된다.

다행히 encrypted signature 필드는 그대로 돌아온다. 다중 턴(multi-turn) 대화에서 이전 추론을 다음 요청에 다시 주입하는 경로는 display 값과 독립적으로 동작한다. Anthropic이 "omitted"를 기본값으로 바꾼 이유는 스트리밍 응답의 first-token-to-text 지연을 줄이기 위해서다. 추론 요약을 생성하고 포맷하는 비용이 사라지면, 사용자가 첫 글자를 보기까지 걸리는 시간이 줄어든다. 챗봇이라면 합리적 디폴트이지만, 리서치 도구나 에이전트 관찰용 UI를 만드는 입장에서는 명시적 옵트인을 강제하는 변경이다.

Breaking change 3 — 새 tokenizer가 청구서를 1.35배까지 밀어올린다

세 번째는 직접 눈으로 확인하지 않으면 놓친다. Opus 4.7은 새 tokenizer를 탑재했고, 같은 입력 문자열이 "콘텐츠 유형에 따라 대략 1.0배에서 1.35배" 더 많은 입력 토큰으로 잘린다. 가격은 동일한데 토큰 수가 늘어나니 결과적으로 같은 작업의 단가가 최대 35% 상승한다.

구체 숫자로 환산하면 이렇다. Opus 4.6 환경에서 월 입력 500M 토큰을 쓰던 서비스는 월 2,500달러를 지출했다. 동일 요청을 Opus 4.7로 옮기면 최악 시나리오 기준 입력 675M 토큰이 집계되며 월 3,375달러가 청구된다. 산술적 차이 875달러가 tokenizer만 바뀌어서 발생한다. Anthropic은 공식 문서에서 영어 기준 100만 토큰이 Opus 4.6에서는 75만 단어, Opus 4.7에서는 55.5만 단어에 해당한다고 명시했는데, 이게 거의 1.35배 배율과 일치한다.

나는 Opus 4.6 대비 한국어 텍스트와 TypeScript 코드가 특히 심하게 밀리는 걸 관찰했다. 어제 사주 앱에서 2,312 토큰이 나오던 동일한 프롬프트가 Opus 4.7에서는 3,014 토큰으로 계측됐다. 1.30배 증가다. 한글이 많은 콘텐츠나 타입이 복잡한 코드베이스를 다룬다면, 모델 ID를 바꾸기 전에 migration guide의 tokenizer 변경 섹션을 먼저 검토하고, 실제 샘플 프롬프트로 토큰 수 차이를 측정해야 한다. 단가 동결이라는 마케팅 문구 뒤에는 입력 토큰 인플레이션이 숨어 있다.

xhigh — 새로운 effort 레벨과 Claude Code의 기본값

budget_tokens가 사라진 자리에 effort 레벨이 들어왔다. Opus 4.7의 effort는 low, medium, high(기본), xhigh(Opus 4.7 전용 신설), max 다섯 단계다. output_config: {effort: "xhigh"} 형태로 전달한다. xhigh는 Opus 4.7에서만 쓸 수 있고, 추론과 출력의 깊이를 high와 max 사이에 정밀하게 맞추고 싶을 때 쓰라는 의도로 도입됐다.

여기서 Claude Code 유저가 주의해야 할 포인트가 있다. 오늘자 업데이트로 Claude Code는 모든 플랜에서 기본 effort를 xhigh로 올렸다. 공지 없이 바뀐 값이다. 즉 동일한 /plan, /implement 류 명령이 어제보다 체감 지연이 길어지고, tokenizer 1.35배와 맞물려 청구서가 눈에 띄게 오를 수 있다. 요금이 민감한 사람은 프로젝트 설정에서 effort를 high로 내려 사용하는 편이 현재로서는 합리적이다. 같은 시점에 Claude Code는 여러 프로젝트를 한 화면에서 관리하는 통합 인터페이스를 선보였고, Microsoft Word 베타 통합까지 예고했다. 나는 현재 Claude Code 전자책을 쓰고 있는 입장이라, 다음 주 초안에 xhigh 기본값 주의 항목을 추가해 두기로 했다.

그 외 — 디자인 도구 동시 공개와 Figma 주가

Opus 4.7 출시일에 맞춰 Anthropic은 웹사이트와 프레젠테이션을 만드는 자체 AI 디자인 도구를 공개했다. The Information이 4월 14일 단독 보도로 이 제품을 선행 공개했고, 같은 날 Figma와 Wix의 주가가 각각 2%에서 4% 사이로 하락했다. Opus 4.7이 단일 모델 업데이트가 아니라 Anthropic의 제품 스택 확장이라는 신호다. 1인 개발자 입장에서는 좋은 소식이다. 랜딩 페이지 시안을 대여섯 장씩 만들어야 하는 일이 에이전트 한 줄로 줄어든다.

오늘 해야 할 체크리스트

Opus 4.7로 옮길지 말지 지금 결정할 필요는 없다. 다만 옮긴다면 다음 순서를 지키는 게 안전하다. 첫째, 기존 thinking.type = "enabled" 호출을 전부 찾아 "adaptive"로 치환하고 budget_tokens를 삭제한다. 둘째, display: "summarized"를 명시해야 기존 UI가 빈 공간이 아닌 상태로 유지된다. 셋째, 실제 샘플 프롬프트로 토큰 수 변화를 측정해 월 청구서 영향을 사전에 계산한다. 넷째, Claude Code를 쓴다면 effort를 high로 내려 두고 필요할 때만 xhigh로 끌어올린다.

한 글자짜리 model ID 변경이 세 줄짜리 breaking change를 끌고 온다.

가격표는 그대로인데 실제 비용과 응답 품질은 한 번에 흔들린다. Opus 4.7 마이그레이션은 기능 업그레이드가 아니라 API 재설계에 가깝다는 감각으로 접근해야 덜 아프다.

참고 자료

매일 아침 AI 뉴스를 이메일로 받아보세요. spoonai.me 뉴스레터 구독