Claude Sonnet 5 리뷰: 지금 쓰는 모델에서 갈아타야 할까요?
해당 블로그는 Juan Pablo Flores, Gowtham Kishore Vijay 원저자의 글 'Claude Sonnet 5 review: Should you switch?'을 번역한 것입니다. 더 나은 이해를 위해서 약간의 의역이 반영되었습니다.
Anthropic이 미드티어 라인의 최신 모델인 Claude Sonnet 5를 공개했습니다. 이 글은 단순한 질문 하나에 답합니다. 지금 쓰는 모델에 머무를지, 아니면 이 모델로 올라탈지입니다.
Sonnet 5가 갑자기 튀어나온 건 아닙니다. 저희는 지난 한 달간 블로그에서 새 모델들을 잇달아 리뷰해 왔습니다.
- Opus 4.8은 길고 여러 단계로 이어지는 코딩에서 저희가 테스트한 최고의 모델이었습니다. 리뷰 지시를 글자 그대로 따를 만큼 신중했죠. 다만 비용이 더 들었고 규모가 큰 작업에서 주로 값을 했습니다.
- Fable 5는 스스로 코딩하는 쪽으로 한층 더 기울었고 여러 파일에 걸쳐 계획하고 만드는 일을 마다하지 않았습니다. 다만 가격과 제한된 접근성 탓에 저희 기본 리뷰 경로에는 들이지 못했습니다.
- NVIDIA의 Nemotron 3 Ultra는 반대 방향으로 갔습니다. 빠르고 요점에 충실하며 에이전트 환경 안에서 빠른 시도를 여러 번 던지도록 만들어진 오픈 모델입니다.
Sonnet 5는 Anthropic 제품군의 다른 모델들과 결이 비슷합니다. 인내심 있고 꼼꼼하며 행동에 앞서 문제를 끝까지 생각해 보는 쪽을 선호합니다.
코드를 작성하고 만드는 일에서 Sonnet 5는 이 등급에서 저희가 다뤄 본 가장 뛰어난 모델이며 설레는 마음으로 올라탈 만한 업그레이드입니다. 리뷰 쪽은 좀 더 트레이드오프에 가깝습니다. 더 깔끔하고 날카로운 코멘트를 만들어 내지만 저희가 현재 프로덕션에서 돌리는 이전 모델들보다 버그를 더 적게 잡고 리뷰당 비용도 조금 더 듭니다.
다행인 점은 그 대부분을 튜닝할 수 있다는 것이고 많은 팀에게 이 이동은 충분히 해 볼 만합니다. Sonnet 5의 새로운 점, 코드를 작성하고 리뷰할 때의 성능, 그리고 갈아탈 이유가 있는지를 하나씩 짚어 보겠습니다.
Claude Sonnet 5의 새로운 점
Sonnet 5는 이전 버전보다 더 깊이 생각합니다. 여러분 입장에서는 예전 모델이라면 포기했을 어려운 문제까지 풀어낸다는 뜻입니다.
Sonnet 5에는 사고 '노력(effort)' 다이얼이 있어서 필요 없을 때는 단계적으로 낮추거나 끌 수 있습니다. 예산을 지켜 주는 기능이죠. 놓친 버그의 대가가 큰 까다로운 리뷰에서는 노력을 올리고 굳이 깊은 사고에 비용을 치르고 싶지 않은 일상 작업에서는 낮추거나 끄면 됩니다.
작업 도중에 자신의 지시를 다시 쓸 수도 있습니다. 긴 에이전트 작업에서는 모델이 더 많이 알아 갈수록 목표가 옮겨 가기 마련인데 첫 계획에 갇힌 모델은 더 이상 맞지 않는 지시를 계속 밀어붙입니다. Sonnet 5는 대신 자신의 계획을 갱신하기 때문에 엉뚱한 길로 새서 시간과 토큰을 태우는 실행이 줄어듭니다.
보안과 사이버 주제를 둘러싼 새로운 안전 가드레일도 함께 실렸습니다. 좋은 쪽은 위험한 출력이 줄어든다는 점입니다. 함정은 진짜 보안 작업이 종종 필터에 걸릴 수 있다는 것이고 그 분야를 다룬다면 가끔 나오는 거절을 감안하셔야 합니다.
Sonnet 5를 가장 쉽게 그려 보는 방법은 중급 엔지니어를 떠올리는 것입니다. 실제로 동작하고 요청한 수준으로 돌아가는 코드를 내보내는 데 어쩌면 조금 과할 정도로 신경 쓰는 엔지니어죠. 이 한 가지 특성이 이 모델이 하는 일 대부분을 좌우하며 저희가 거듭 목격한 네 가지 습관으로 드러났습니다.
- 기능보다 테스트를 먼저 쓰는 경향이 있습니다.
- 이미 동작하는 해법도 한참 더 다듬습니다.
- 자신의 계획을 의심합니다. 때로는 필요 이상으로요.
- 작은 작업에 작은 프로젝트로 답합니다.
Claude Sonnet 5가 코드를 작성하는 방식
Sonnet 5의 코드 작성 능력은 대부분의 팀이 업그레이드하고 싶어질 거라고 저희가 보는 가장 큰 이유입니다. 리뷰 수치로 넘어가기 전에 이 모델이 무언가를 밑바닥부터 만들 때 어떻게 행동하는지 살펴보면 도움이 됩니다. 저희는 빠르게 붙일 수 있는 기능부터 명확한 경로가 없는 어려운 문제까지 저희가 매일 하는 일을 그대로 맡겨 봤습니다.
어느 날 저녁, 저희는 어려운 작업 하나를 맡기고 식사를 하러 자리를 비웠습니다. 그 작업은 모델에게 코드를 작성하고 그 위에서 시뮬레이션을 돌리며 결과가 가능한 한 좋아질 때까지 출력을 계속 튜닝하도록 요구했습니다. 돌아왔을 때는 끝나 있거나 막혀 있을 거라고 예상했습니다. 둘 다 아니었습니다. 모델은 저희의 어떤 재촉도 없이 여전히 스스로 문제를 풀어 가고 있었습니다.
모델은 애플리케이션 전체를 혼자 만들어 냈습니다. 그렇게 오래 돌아간 이유는 단순합니다. 어쩌다 동작한 첫 번째 답이 아니라 최선의 답을 좇으며 자신의 해법을 한 번 또 한 번 계속 정리했기 때문입니다. 예전에는 더 비싼 모델에서만 볼 수 있던 종류의 모습이고 미드티어 모델이 이걸 해내는 장면은 꽤 의미가 있습니다.
앞서 말한 그 성실함이 바로 Sonnet 5가 길고 열린 작업에 강한 이유입니다. 한 줄짜리 변경에서는 거슬리던 느림이 정해진 단계 수가 없는 작업에서는 강점으로 바뀝니다. 에이전트 루프에 잘 맞는데 모델에게 단순한 목표를 건네면 결과를 보고하기 전까지 몇 라운드에 걸쳐 여러 접근을 시도하고 테스트하며 스스로 결과를 개선하도록 맡길 수 있습니다.
Anthropic이 직접 쓴 효과적인 에이전트 만들기 가이드는 이를 평가자 루프(evaluator loop)라고 부릅니다. 모델이 결과를 만든 뒤 그것을 비평하고 개선하기를 반복하는 방식이죠. 그런 워크플로를 만들고 계시다면 한 번 읽어 볼 만합니다. Sonnet 5는 이 루프가 사고방식 자체에 배선되어 있어서 이전 모델들이 표류하거나 포기하는 탓에 에이전트 코딩을 미뤄 오셨다면 이번 릴리스가 그 상황을 바꿔 놓습니다.
테스트를 습관처럼 다룹니다
대부분의 모델은 Sonnet 4.6을 포함해 테스트를 나중에 할 귀찮은 일로 취급합니다. Sonnet 5는 테스트를 먼저 쓰고 그 위에 기능을 얹은 다음 끝났다고 판단하면 전체를 한 번 실행하는 경향이 있습니다. 저희가 본 자기 점검은 바로 이 순서에서 곧장 나옵니다. 테스트를 한 번도 돌리지 않으면 테스트와 코드 사이의 충돌을 잡아낼 수 없는데 이 모델은 늘 테스트를 실행합니다. 멀쩡해 보이던 코드가 일주일 뒤에 깨진 경험이 있으시다면 그 차이를 금방 체감하실 겁니다.
그 각별한 신중함의 대가
Sonnet 5가 들이는 각별한 신중함은 파일 수와 토큰 사용량으로 드러납니다. 작은 걸 요청해도 많은 게 돌아옵니다. 별도의 헬퍼들과 기능 자체보다 긴 테스트 파일을 보게 되죠. 큰 기능에서는 그게 좋은 엔지니어링처럼 보입니다. 한 줄짜리 변경에서는 스스로를 못 말리는 모델처럼 보입니다.
저희가 보기에 Sonnet 5는 Sonnet 4.6보다 느렸는데 Sonnet 5가 수행하는 추가 사고 때문일 가능성이 큽니다. 분 단위의 시간을 꼼꼼함과 맞바꾸는 셈이고 이는 켜 두고 돌리는 긴 작업에서 값을 합니다. 작은 변경을 기다릴 때는 확실히 답답하죠. 4.6이 빠른 답을 돌려주는 자리에서 5는 더 나은 답을 위해 계속 일하고 그 차이는 자잘한 작업에서 가장 크게 느껴집니다. 작은 참고 사항이 두 가지 있습니다. 4.6보다 토큰을 더 쓰며 여전히 명료하지만 말수가 좀 더 많습니다. 또한 좋은 계획을 세워 놓고는 작업 도중에 저희가 바라는 것보다 자주 다시 씁니다. 빌드 작업에서 이 중 어느 것도 결격 사유는 아니지만 자잘한 수정 더미에 이 모델을 붙이기 전에 알아 둘 만합니다.
Claude Sonnet 5가 코드를 리뷰하는 방식
대규모로 코드를 리뷰하는 일이 저희가 하는 일이라 이 부분에 가장 마음이 쓰입니다. 이제 AI는 많은 팀이 내보내는 코드의 상당 부분을 작성하고 그런 코드에는 신중한 두 번째 눈이 필요합니다. 저희가 오픈소스 풀 리퀘스트 470개를 살펴본 결과 AI가 공동 작성한 PR은 사람만 작성한 PR보다 약 1.7배 더 많은 이슈를 안고 있었고 한 2025년 연구에서는 AI에 크게 의존하는 팀에서 리뷰 시간이 91% 늘었습니다. 이제 리뷰를 맡는 모델은 팀이 얼마나 빨리 내보내는지를 좌우하는 큰 요인입니다.
저희는 Sonnet 5를 하니스(harness)에 추가하고 알려진 버그가 담긴 고정된 풀 리퀘스트 세트인 표준 벤치마크에 투입해 몇 개를 잡아내는지, 코멘트가 얼마나 깔끔한지를 측정했습니다. 저희가 이런 리뷰를 어떻게 구성하는지는 AI 코드 리뷰를 위한 컨텍스트 엔지니어링 글에서 더 읽어 보실 수 있습니다.
코멘트가 훨씬 깔끔합니다
Sonnet 5의 코멘트는 더 깔끔하고 발견 사항이 잡음이라기보다 실제 버그인 경우가 더 많았습니다. 저희 벤치마크에서 정밀도는 Sonnet 4.6의 약 29%에서 대략 38%에서 40% 수준으로 올랐습니다. Sonnet 4.6은 정반대로 움직입니다. 거의 모든 것에 코멘트를 달고 여러분에게 그 잡동사니 속에서 건질 것을 골라내라고 떠넘깁니다. 사소한 것 하나하나까지 지적한다는 이유로 리뷰어를 꺼 버린 적이 있으시다면 주의가 필요한 부분만 짚어 주는 일이 얼마나 중요한지 이미 아실 겁니다.
버그 탐지에서 솔직히 인정할 부분
저희 리뷰 하니스 안에서 Sonnet 5는 현재 프로덕션 구성보다 버그를 더 적게 잡습니다. '버그를 찾아냈는가'를 엄격하게 보는 기준에서 저희 베이스라인은 약 57%를 잡고 Sonnet 5는 50~51% 언저리에 도달합니다. 저희를 놀라게 한 건 잡음이 더 많은 리뷰어인데도 Sonnet 4.6이 둘 중 어느 쪽보다 많은 약 63%를 잡았다는 점입니다. 코멘트로 여러분을 파묻어 버리는 그 모델이 버그도 가장 적게 놓친 셈이죠. Sonnet 5의 노력 다이얼을 올려도 점수는 거의 움직이지 않았고 비용은 대략 두 배가 됐습니다. 더 많은 유형과 변형의 코멘트를 인정하는 느슨한 기준에서는 높은 노력이 발견 사항을 현재 베이스라인과 대체로 비슷한 수준까지 되돌렸지만 뚜렷하게 앞서지는 못했습니다.
코멘트 속에 숨은 잡음도 조금 있습니다. Sonnet 5는 높은 노력으로 돌릴 때 저희 베이스라인보다 nitpick을 서너 배 더 많이 달고 Sonnet 4.6보다도 거의 80% 더 답니다. 가장 좋은 코멘트는 더 깔끔하게 읽히지만 그걸 찾으려면 사소한 코멘트들을 더 많이 지나쳐야 합니다. 저희는 사고를 끈 상태로도 시험해 봤습니다. 어떤 작업에서는 베이스라인과 맞먹었고 어떤 작업에서는 조금 미끄러졌습니다. 그래서 가장 중요한 코드만 아니라면 사고를 끄고 저렴하게 돌려도 거의 잃는 것 없이 처리할 수 있는 가벼운 리뷰 작업의 부류가 존재합니다. 여기서 얻을 교훈은 Sonnet 5가 약한 리뷰어라는 게 아닙니다. 오히려 더 조용하고 더 신중한 리뷰어이며 리뷰 잡음에 허덕이는 팀에게는 그편이 더 나은 거래인 경우가 많습니다.
Claude Sonnet 5 vs 지금 쓰는 모델
필요한 게 순수한 커버리지이고 그 코멘트들을 헤쳐 나갈 여력이 있다면 Sonnet 4.6을 택하세요. 더 적고 날카로운 코멘트, 그리고 실제로 코드를 작성해 줄 훨씬 강한 파트너를 원한다면 Sonnet 5를 택하세요. Sonnet 4.6은 버그를 조금 더 찾아내고 Sonnet 5는 여러분의 주의를 훨씬 덜 낭비합니다.
Sonnet 5와 플래그십 모델 비교
가장 어려운 작업을 위해 팀들이 곁에 두는 Opus 제품군 같은 플래그십 모델과 견주면 Sonnet 5는 훨씬 적은 비용으로 리뷰 품질에서 거의 비슷한 성과를 냅니다. 더 저렴한 어떤 것도 충분치 않아서 지금 플래그십 요금을 내고 계신 거라면 Sonnet 5를 살펴볼 만합니다. 테스트하는 동안 토큰 청구액은 지켜보세요. 이만큼 생각을 많이 하는 모델은 자신이 아낀 비용을 되먹을 수 있거든요. 노력을 최대로 끌어올리는 건 그중 가장 나쁜 선택이었습니다. 의미 있게 더 많은 버그를 찾지도 못한 채 비용만 대략 두 배로 늘렸으니 기본값으로 최상위 등급에 손대지는 마세요. Claude Opus 4.7이 AI 코드 리뷰에서 의미하는 것을 리뷰했을 때도 같은 패턴을 봤습니다.
Claude Sonnet 4.6이냐 Claude Sonnet 5냐: 빠른 결론
대부분의 팀에게 답은 '네'입니다. Sonnet 5는 같은 등급에서 저희가 써 본 가장 흥미로운 코딩 모델입니다. 나중에 깨질 무언가를 건네느니 몇 분 더 들이는 쪽을 택하는 신중한 동료처럼 일하고 그 본능 덕분에 실제 빌드 작업을 하는 사람이라면 누구에게나 4.6보다 분명히 한 단계 위입니다.
쉽게 말해, 실제 소프트웨어를 작성하거나 출시하고 자신의 작업을 스스로 테스트하며 어려운 문제를 풀릴 때까지 붙잡는 모델을 원한다면 지금 갈아타세요. 노력을 중간(medium)으로 두면 최상위 요금 없이 이점의 대부분을 얻습니다. 그리고 오로지 품질 때문에 플래그십 요금을 내고 계신다면 다음 갱신 전에 Sonnet 5를 지금 쓰는 모델과 나란히 붙여 보세요. 지출의 일부만으로 같은 성과를 낼 수도 있으니까요.
기다리는 편이 나은 유일한 집단은 지연 예산이 빡빡하고 자잘한 디프가 많은 고처리량 팀입니다. 더 느리고 더 신중한 이 모델의 스타일이 아직 값을 못 하는 워크플로거든요.
완벽하지는 않고 리뷰에서 뒤처지는 지점은 저희가 솔직하게 밝혔습니다. 하지만 코드를 작성하고 리뷰하는 강점이 그 단점을 어렵지 않게 앞섭니다. 업그레이드할 이유를 기다려 오셨다면 바로 이것입니다.
AI가 만든 코드 품질의 전체 그림이 궁금하신가요? 저희 State of AI vs Human Code Generation 리포트를 읽어 보시고 팀들이 실제로 AI 개발 도구를 어떻게 쓰는지도 살펴보시거나 IDE에서 CodeRabbit을 무료로 사용해 보세요.
같은 맥락의 다른 모델 리뷰가 궁금하시다면 Opus 4.8 벤치마크 결과와 Claude Fable 5 모델 리뷰, Claude Opus 4.7이 AI 코드 리뷰에서 의미하는 것을 함께 보시기를 추천 드립니다.