Claude Sonnet 5 달라진 점과 상위 모델 선택 기준

Claude Sonnet 5 업데이트, 무엇이 달라졌는지 확인하기

2026년 7월, Anthropic이 Claude Sonnet 5를 출시했습니다. Claude Code를 쓰다 보면 어느 날 갑자기 응답 스타일이 달라졌다고 느끼는 경우가 있는데, 대부분 이런 모델 업데이트가 원인입니다.

내가 지금 어떤 모델을 쓰고 있는지 모르면, 문제가 생겨도 원인을 좁히기 어렵습니다. 실제로 커뮤니티에서도 "어제까지 잘 되던 프롬프트가 갑자기 이상해졌다"는 질문이 모델 업데이트 시기마다 반복해서 올라오네요.

이런 혼란을 줄이려면 업데이트 소식이 들릴 때마다 내 환경을 한 번씩 점검하는 습관이 필요합니다.

가장 먼저 할 일은 현재 모델 확인입니다. Claude Code 실행 후 /model 명령어를 입력하면 현재 세션에서 사용 중인 모델이 표시됩니다.

여기서 Sonnet 5가 기본값으로 잡혀 있는지, 아니면 이전 버전인 Sonnet 4.6이 그대로 유지되고 있는지 볼 수 있습니다. 명령어 하나만 입력하면 되기 때문에 10초도 안 걸리는 작업이지만, 이걸 확인하지 않고 "왜 결과가 이상하지"라며 한참을 헤매는 경우가 의외로 많습니다.

 

 

플랜에 따라 기본 모델이 자동으로 바뀌는 시점이 다릅니다. 구독 갱신 시점이나 CLI 업데이트 시점에 따라 아직 이전 모델이 기본값인 경우도 있네요.

CLI 버전이 오래되면 새 모델 선택지가 아예 안 보일 수 있으니, 터미널에서 claude --version으로 버전을 확인하고 npm update -g @anthropic-ai/claude-code로 업데이트하는 것이 우선입니다. 업데이트 후에는 터미널을 완전히 닫고 다시 여는 것도 잊지 마세요.

간혹 업데이트가 반영되지 않은 상태로 이전 버전이 계속 실행되는 경우가 있기 때문입니다.

Sonnet 5의 핵심 변화는 크게 세 가지입니다. 첫째, 긴 작업에서 맥락 유지력이 좋아졌습니다.

파일 여러 개를 오가며 수정할 때 앞에서 한 작업을 잊는 빈도가 줄었습니다. 둘째, 도구 호출(tool call)의 정확도가 올라갔습니다.

파일을 수정하다 엉뚱한 위치를 고치는 실수가 눈에 띄게 감소했습니다. 셋째, 같은 작업 기준 응답 속도가 빨라졌습니다.

제가 직접 써보니 체감이 가장 큰 부분은 속도였습니다. 이전에는 큰 파일을 수정할 때 기다리는 시간이 은근히 길었는데, Sonnet 5는 확실히 답답함이 덜하네요.

다만 출시 직후에는 응답 스타일이 미묘하게 달라져서 기존에 만들어둔 프롬프트(prompt)가 예상과 다르게 동작하는 경우도 있었습니다. 이건 새 모델이 나쁘다는 뜻이 아니라, 같은 문장을 해석하는 방식이 조금 달라졌다는 의미입니다.

며칠 써보면서 프롬프트를 조금씩 다듬으니 오히려 이전보다 결과가 안정적으로 나왔습니다.

Sonnet 5와 이전 모델의 실질적인 차이

버전 숫자만 보면 무엇이 좋아졌는지 감이 안 옵니다. 실사용 기준으로 이전 세대인 Sonnet 4.6과 비교해 보겠습니다.

코드 작성 품질부터 보겠습니다. 단순한 함수 작성이나 버그 수정 수준에서는 두 모델의 차이가 크지 않습니다.

차이가 벌어지는 지점은 여러 파일에 걸친 수정 작업입니다. 예를 들어 함수 이름을 바꾸면서 그 함수를 쓰는 파일 5개를 함께 고쳐야 하는 상황이라면, Sonnet 5가 누락 없이 처리하는 비율이 더 높습니다.

이전 모델은 4개까지 고치고 마지막 1개를 빼먹는 식의 실수가 가끔 있었는데, 이런 부분에서 신뢰도가 올라간 것이 실무에서는 꽤 큰 차이로 느껴집니다.

에이전트(agent) 작업에서도 차이가 있습니다. Claude Code가 스스로 파일을 찾고, 테스트를 돌리고, 결과를 보고 다시 수정하는 반복 작업을 시켜보면, 이전 모델은 중간에 방향을 잃는 경우가 종종 있었습니다.

Sonnet 5는 이런 장기 작업에서 이탈이 줄었구요, 실패했을 때 같은 실수를 반복하는 빈도도 낮아졌습니다. 테스트가 실패하면 실패 원인을 읽고 접근을 바꾸는 모습이 이전보다 자연스러워졌습니다.

비용 측면도 중요합니다. API 기준으로 Sonnet 계열은 상위 모델인 Opus 계열보다 토큰(token, AI가 글을 처리하는 단위)당 요금이 훨씬 저렴합니다.

구독 플랜 사용자라면 사용량 한도 소진 속도에서 차이가 납니다. 같은 한도라도 Sonnet 5를 쓰면 Opus 대비 훨씬 많은 작업을 할 수 있습니다.

하루 종일 Claude Code를 붙잡고 작업하는 분이라면 이 차이가 체감으로 크게 다가올 겁니다.

주의할 점도 있네요. 모델이 바뀌면 같은 프롬프트에 대한 답변 형식이 달라질 수 있습니다.

자동화 스크립트에서 Claude의 출력 형식을 그대로 파싱하고 있었다면, 모델 업데이트 후 스크립트가 깨질 수 있으니 확인이 필요합니다.

제 경험상 일상적인 코딩 작업의 90% 정도는 Sonnet 5로 충분했습니다. 오히려 습관적으로 상위 모델을 쓰다가 한도가 일찍 소진되는 것이 더 흔한 문제였네요.

기본은 Sonnet으로 두고, 필요할 때만 올리는 방식이 합리적이라고 생각합니다.

상위 모델 Opus로 바꿔야 하는 순간

그렇다면 언제 상위 모델을 써야 할까요. 무조건 비싼 모델이 좋다는 생각은 버리는 것이 좋습니다.

판단 기준을 상황별로 정리하겠습니다.

첫 번째, 설계 단계입니다. 새 프로젝트의 구조를 잡거나, 여러 방식 중 어떤 접근이 나은지 판단해야 할 때는 상위 모델이 확실히 낫습니다.

이런 작업은 정답이 하나가 아니고, 여러 조건을 동시에 고려해야 하기 때문입니다. Claude Code의 플랜 모드(plan mode)로 설계를 검토할 때 Opus를 쓰면 빠뜨리는 경우의 수가 줄어듭니다.

설계 단계의 실수는 나중에 고치려면 코드를 대량으로 갈아엎어야 하기 때문에, 이 단계에서만큼은 모델 비용을 아끼지 않는 것이 결과적으로 이득입니다.

두 번째, Sonnet이 반복해서 실패하는 문제입니다. 같은 버그를 두세 번 시도해도 못 잡는다면, 같은 모델로 계속 재시도하는 것보다 모델을 올리는 것이 시간을 아낍니다.

세션 중에 /model 명령어로 모델을 바꾸면 대화 맥락을 유지한 채 이어서 작업할 수 있습니다. 재시도 횟수에 대한 기준을 미리 정해두면 판단이 쉬워지네요.

저는 "같은 문제 2회 실패면 모델 전환"이라는 나름의 규칙을 정해두고 씁니다.

 

 

세 번째, 코드 리뷰나 보안 점검처럼 놓치면 비용이 큰 작업입니다. 이런 작업은 실수 하나의 대가가 크기 때문에, 모델 요금 차이보다 정확도가 우선입니다.

결제 로직이나 사용자 정보를 다루는 코드를 검토할 때가 대표적인 예시입니다.

반대로 상위 모델이 필요 없는 작업도 명확합니다. 오타 수정, 주석 추가, 간단한 함수 작성, 파일 정리 같은 작업은 Sonnet 5로 충분합니다.

이런 작업에 Opus를 쓰는 것은 동네 마트에 트럭을 몰고 가는 것과 같습니다.

제가 정착한 방식은 이렇습니다. 평소에는 Sonnet 5를 기본으로 두고, 설계 논의와 막힌 문제에서만 Opus로 전환합니다.

이렇게 쓰니 한도 걱정 없이 하루 종일 작업할 수 있었구요, 품질 차이도 거의 느끼지 못했습니다.

모델 전환 후 문제가 생겼을 때 대처법

모델을 바꾸거나 업데이트된 후에 문제가 생기는 경우가 있습니다. 자주 겪는 상황과 해결 방법을 정리하겠습니다.

먼저 새 모델이 선택지에 안 보이는 경우입니다. 원인은 대부분 두 가지입니다.

CLI 버전이 오래됐거나, 현재 플랜에서 해당 모델을 지원하지 않는 경우입니다. claude --version으로 버전을 확인하고 업데이트한 뒤 재시작하면 대부분 해결됩니다.

그래도 안 보이면 구독 플랜의 모델 지원 범위를 확인해야 합니다. 플랜별 지원 모델은 Anthropic 공식 문서에 정리되어 있으니, 업데이트 소식이 나오면 한 번씩 확인해 보는 것이 좋습니다.

다음은 응답 품질이 이전과 달라진 경우입니다. 모델 업데이트 직후에는 기존 CLAUDE.md 파일의 지시가 예전만큼 잘 안 먹히는 느낌이 들 수 있습니다.

이럴 때는 CLAUDE.md의 지시문을 더 구체적으로 다듬는 것이 효과적입니다. 새 모델은 모호한 지시를 다르게 해석할 수 있기 때문에, "간결하게 작성"보다 "함수당 주석 1줄 이하"처럼 명확한 기준을 주는 것이 좋습니다.

지시문을 수치나 구체적인 조건으로 바꿔두면 이후 모델이 또 바뀌어도 흔들림이 적어집니다.

세션 중간에 모델을 바꿨더니 작업 흐름이 끊긴 느낌이 드는 경우도 있습니다. 모델 전환 자체는 대화 기록을 유지하지만, 모델마다 같은 맥락을 해석하는 방식이 미묘하게 다릅니다.

중요한 작업이라면 전환 직후에 "지금까지 한 작업을 요약해줘"라고 요청해서, 새 모델이 맥락을 제대로 파악했는지 확인하고 진행하는 것이 안전합니다. 요약이 실제 작업 내용과 다르다면, 그 자리에서 바로잡아 주고 진행하면 됩니다.

 

 

마지막으로 특정 모델을 기본값으로 고정하고 싶은 경우입니다. 설정 파일에서 기본 모델을 지정해두면 매번 /model을 입력할 필요가 없습니다.

프로젝트별로 다른 모델을 기본값으로 둘 수도 있어서, 무거운 프로젝트는 Opus, 가벼운 프로젝트는 Sonnet으로 나누는 운영도 가능합니다. 팀 단위로 작업한다면 설정 파일을 저장소에 함께 올려두는 방법으로 팀원 전체의 모델 환경을 통일할 수도 있습니다.

제가 직접 겪어보니 모델 업데이트 직후 일주일 정도는 결과물을 평소보다 꼼꼼히 확인하는 습관이 도움이 됐습니다. 새 모델이 대체로 더 낫긴 하지만, 내 작업 방식과 궁합이 맞는지는 직접 써봐야 알 수 있네요.

다음에 또 새 모델이 나와도, 오늘 정리한 확인 순서대로 점검하면 당황할 일은 없을 겁니다.