Claude Sonnet 5 마이그레이션: 1M 컨텍스트와 adaptive thinking 적용 체크리스트

Claude Sonnet 5 마이그레이션에서 가장 먼저 볼 것은 성능 수치가 아니라 동작 변경이다. Anthropic의 Claude Platform release notes에 따르면 Claude Sonnet 5는 2026년 6월 30일 출시됐고, 1M 토큰 컨텍스트와 128k 최대 출력 토큰을 지원한다. 하지만 adaptive thinking이 기본값으로 켜지고, 기존 manual extended thinking 설정은 제거되며, temperature·top_p·top_k 같은 비기본 sampling parameter는 400 오류를 반환한다. 또한 새 tokenizer 때문에 같은 텍스트가 약 30% 더 많은 토큰으로 계산될 수 있다고 안내되어 있다.

새 모델로 바꿀 때 가장 흔한 실수

LLM 모델 교체에서 흔한 실수는 모델명만 바꾸고 배포하는 것이다. 응답 품질이 좋아질 것이라고 기대하지만, 실제 운영에서는 API 오류, 비용 증가, latency 변화, 평가 지표 악화가 먼저 보일 수 있다. Sonnet 5는 특히 기존 Sonnet 4.6이나 4.5에서 넘어오는 팀이 주의해야 할 변경점이 많다.

첫 번째는 thinking 설정이다. 기존에 thinking: { type: "enabled", budget_tokens: N }처럼 명시적 예산을 주던 코드는 더 이상 그대로 동작하지 않는다. Sonnet 5에서는 adaptive thinking이 기본값이고, 수동 extended thinking 설정은 400 오류를 낸다. SDK 래퍼나 공통 request builder에 이 설정이 박혀 있으면 전체 서비스가 실패할 수 있다.

두 번째는 sampling parameter다. temperature를 낮춰 일관성을 높이거나 top_p를 조정하던 팀은 요청이 거부될 수 있다. 모델이 좋아졌는지보다 먼저 ‘우리 요청이 유효한가’를 확인해야 한다.

세 번째는 토큰 증가다. Anthropic은 새 tokenizer가 같은 텍스트에 대해 약 30% 더 많은 토큰을 만들 수 있다고 설명한다. 긴 문서 분석, RAG, agent trace, tool result를 많이 넣는 서비스는 비용과 context limit 계산을 다시 해야 한다.

1M 컨텍스트는 만능이 아니다

Claude의 context window 문서는 1M 컨텍스트가 더 복잡하고 긴 입력을 다룰 수 있게 해주지만, 컨텍스트가 많다고 자동으로 더 좋은 결과가 나오지는 않는다고 설명한다. 토큰이 늘수록 accuracy와 recall이 떨어지는 context rot 문제가 있기 때문에, 무엇을 컨텍스트에 넣을지 관리하는 것이 중요하다.

실무에서는 1M 컨텍스트를 ‘모든 것을 넣어도 되는 공간’으로 쓰면 안 된다. 오히려 더 엄격한 context engineering이 필요하다. 큰 로그 파일, 전체 저장소, 오래된 대화 기록, 중복 문서 조각을 무작정 넣으면 모델은 더 많은 노이즈 속에서 답해야 한다.

추천하는 구조는 다음과 같다.

• 고정 정책: prompt caching 대상으로 분리
• 최신 사용자 요청: 항상 포함
• 검색 결과: top-k를 작게 유지하고 중복 제거
• 도구 출력: 원문 전체보다 요약과 근거 위치 중심
• 이전 대화: 최근 결정과 변경 사항만 압축
• 대형 파일: 필요한 줄 범위, 함수, 섹션만 선택

1M 컨텍스트는 긴 입력을 허용하는 보험이지, 정보 정리를 대체하는 기능이 아니다.

마이그레이션 전에 코드에서 제거할 것

Sonnet 5로 바꾸기 전에는 공통 API 클라이언트를 먼저 검사해야 한다. 서비스 코드 곳곳에서 모델 파라미터를 직접 넣는 구조라면 위험하다. request builder 한 곳에서 모델별 허용 옵션을 관리하는 방식으로 정리하는 것이 좋다.

확인해야 할 항목은 다음과 같다.

- thinking.type == "enabled" 형태의 수동 extended thinking 설정
- thinking.budget_tokens 고정값
- temperature, top_p, top_k 비기본값
- 모델별 max_tokens 상한 하드코딩
- 200k 컨텍스트 기준으로 잘라내던 오래된 truncation 로직
- 토큰 계산을 구버전 tokenizer 기준으로 캐시한 코드

특히 기존 테스트가 ‘응답이 온다’ 정도만 확인한다면 부족하다. 400 오류가 나는 파라미터 조합을 배포 전에 잡아야 하므로, 실제 production request shape를 샘플링해서 staging에서 검증하는 절차가 필요하다.

비용 계산을 다시 해야 하는 이유

토큰이 약 30% 늘 수 있다는 말은 단순히 입력 비용만 늘어난다는 뜻이 아니다. rate limit, latency, 캐시 효율, context window 여유가 함께 바뀐다. 예를 들어 기존에 150k 토큰으로 계산되던 요청이 195k가 될 수 있다. 1M 모델이라면 limit에는 여유가 있지만, 비용과 처리 시간은 달라진다.

RAG 서비스에서는 chunk 크기와 top-k도 다시 봐야 한다. 기존 chunk가 1,000토큰 기준이었다면 새 tokenizer에서 실제 토큰 수가 늘어날 수 있다. top-k 20개를 넣던 검색 파이프라인은 비용이 과해질 수 있다. 반대로 1M 컨텍스트를 활용해 더 많은 근거를 넣고 싶다면, 단순히 top-k를 늘리는 대신 문서별 요약, 중복 제거, section reranking을 먼저 해야 한다.

운영 지표는 최소한 다음을 모델 교체 전후로 비교해야 한다.

• 평균 입력 토큰과 p95 입력 토큰
• 평균 출력 토큰과 p95 출력 토큰
• 요청당 비용
• p50/p95 latency
• 400 오류율
• rate limit 오류율
• 캐시 hit rate
• 평가셋 점수와 사람 수정률

이 수치를 보지 않고 ‘신모델이니까 더 좋다’고 배포하면 비용 증가를 뒤늦게 발견한다.

adaptive thinking을 운영에 맞게 받아들이기

adaptive thinking은 모델이 요청별로 사고량을 동적으로 조정한다는 점에서 편리하다. 하지만 운영 관점에서는 변동성이 생긴다. 어떤 요청은 빠르게 끝나고, 어떤 요청은 더 많은 thinking을 쓰며 비용과 latency가 늘 수 있다.

따라서 서비스는 요청을 위험도와 시간 제한으로 나눠야 한다. 실시간 채팅처럼 응답 시간이 중요한 작업은 timeout과 fallback을 명확히 둔다. 백오피스 분석, 코드 리뷰, 긴 문서 검토처럼 시간이 더 걸려도 품질이 중요한 작업은 더 넓은 여유를 둔다.

또한 이전 assistant turn의 thinking block이 context window에 남는 모델군이 있다는 점도 봐야 한다. 장기 대화형 agent에서는 thinking까지 누적되면 컨텍스트가 빠르게 커질 수 있다. 대화가 길어지는 서비스라면 서버 사이드 compaction, 요약, 도구 출력 축약을 기본 기능으로 넣어야 한다.

배포 전략: 한 번에 갈아타지 말 것

안전한 마이그레이션은 4단계로 진행한다.

1. 정적 검사: 금지된 파라미터와 구버전 thinking 설정을 코드에서 제거한다.
2. 오프라인 평가: 기존 요청 샘플을 Sonnet 5에 돌려 오류율, 비용, 품질을 비교한다.
3. 부분 트래픽: 낮은 위험의 요청 5~10%만 새 모델로 보낸다.
4. 작업별 확대: 품질·비용이 확인된 작업부터 점진적으로 늘린다.

여기서 중요한 것은 rollback 기준이다. 예를 들어 p95 latency가 30% 이상 늘거나, 요청당 비용이 40% 이상 증가하거나, 400 오류율이 0.5%를 넘으면 자동으로 이전 모델로 되돌리는 식의 기준이 있어야 한다.

마이그레이션 체크리스트

Claude Sonnet 5 전환 전에 아래 항목을 완료하자.

• 공통 API 클라이언트에서 수동 extended thinking 설정을 제거했는가
• temperature, top_p, top_k 비기본값 요청이 남아 있지 않은가
• 실제 production request 샘플로 400 오류 테스트를 했는가
• 새 tokenizer 기준으로 입력·출력 토큰과 비용을 다시 계산했는가
• RAG chunk 크기, top-k, reranking 기준을 재검토했는가
• 장기 대화에서 compaction과 tool output 축약 전략이 있는가
• p50/p95 latency와 요청당 비용을 이전 모델과 비교했는가
• 부분 트래픽 배포와 rollback 기준을 정의했는가
• 품질 평가셋에서 기존 모델 대비 개선·악화 케이스를 기록했는가

Sonnet 5의 1M 컨텍스트와 adaptive thinking은 강력하지만, 운영 코드를 그대로 둔 채 모델명만 바꾸는 방식과는 맞지 않는다. 먼저 요청 형식과 비용 모델을 정리하고, 다음으로 context engineering을 손봐야 한다. 그 과정을 거치면 Sonnet 5는 긴 문서 분석, 복잡한 agent workflow, 코드 리뷰에서 충분히 의미 있는 업그레이드가 될 수 있다.