2026 Claude Sonnet 5 출시: AI 코딩, 비싼 모델만 쓰면 돈 새는 팀입니다
Claude Sonnet 5가 나왔다는 소식보다 더 중요한 건, 이제 개발팀이 AI 모델을 “느낌”으로 고르면 안 된다는 점입니다.

2026년 6월 30일, Anthropic이 Claude Sonnet 5를 공식 발표했습니다.
발표 문구만 보면 익숙합니다.
여기까지만 읽으면 반응은 거의 정해져 있습니다.
개발자는 바로 써보고 싶어 합니다.
팀장은 “그럼 우리도 기본 모델 바꾸면 되나?”라고 생각합니다.
대표는 조금 더 과감하게 갑니다.
나는 여기서 한 번 멈춰야 한다고 봅니다.
Sonnet 5는 그냥 지나치기 어렵습니다. AI 코딩과 에이전트 작업을 많이 돌리는 팀이라면, 이번 주 회의 안건에 올라와도 이상하지 않습니다.
그런데 “싸고 좋은 새 모델 나왔네”에서 멈추면 곤란합니다.
내가 이번 발표를 보면서 제일 먼저 든 생각은 이쪽입니다.
AI 코딩은 이제
“무슨 모델이 제일 좋냐” 싸움이 아니라
“어떤 작업에 얼마짜리 추론을 붙일 거냐” 싸움으로 넘어갔습니다.
일단 가격표부터 봐야 합니다. 꽤 세게 들어왔습니다
공식 발표 기준으로 Sonnet 5는 2026년 8월 31일까지 인트로 가격이 적용됩니다.
- 입력 토큰: 100만 토큰당 2달러
- 출력 토큰: 100만 토큰당 10달러
- 2026년 9월 1일부터는 입력 3달러, 출력 15달러
같은 Anthropic 라인업에서 Opus 4.8은 입력 5달러, 출력 25달러입니다. Fable 5는 입력 10달러, 출력 50달러입니다. Haiku 4.5는 입력 1달러, 출력 5달러입니다.
가격만 훑으면 Sonnet 5는 “딱 중간”처럼 보입니다.
그런데 개발팀 비용표에서는 이 중간값이 꽤 크게 작동합니다.
작업 예시 Sonnet 58월 31일까지 Sonnet 59월 1일부터 Opus 4.8 Fable 5
| 입력 50만 + 출력 5만 토큰 | 약 1.5달러 | 약 2.25달러 | 약 3.75달러 | 약 7.5달러 |
| 입력 100만 + 출력 20만 토큰 | 약 4달러 | 약 6달러 | 약 10달러 | 약 20달러 |
| 입력 300만 + 출력 60만 토큰 | 약 12달러 | 약 18달러 | 약 30달러 | 약 60달러 |
위 계산은 API 공개 단가를 단순 적용한 예시입니다. 실제 청구액은 캐시, 배치, 지역, 제품별 크레딧 정책, 프롬프트 구조에 따라 달라질 수 있습니다.
이 정도면 팀 안에서 바로 얘기가 나옵니다.
“그냥 Sonnet 5를 기본으로 깔아도 되겠는데?”
나는 이 판단 자체는 꽤 타당하다고 봅니다.
특히 8월 31일까지는 실험하기 좋습니다. 팀 전체가 Sonnet 5를 기본 모델로 써보고, 어떤 작업에서 성공률이 올라가는지, 어떤 작업에서 비용이 튀는지 로그를 모으기에 딱 맞는 구간입니다.
다만 여기서 한 가지를 빼먹으면 안 됩니다.
Sonnet 5가 싸졌다는 말과, 아무 작업에나 막 돌려도 된다는 말은 완전히 다릅니다.
싸졌는데도 비용이 튈 수 있는 이유
나는 Sonnet 5 발표문을 보고 바로 API 릴리즈 노트를 열었습니다.
실제로 팀에서 돈이 새는 지점은 보통 이런 문서에 숨어 있습니다.
- Sonnet 5는 1M 토큰 컨텍스트를 지원합니다.
- 최대 출력은 128k 토큰입니다.
- adaptive thinking이 기본으로 켜집니다.
- 기존 manual extended thinking 방식은 제거됐습니다.
- temperature, top_p, top_k 같은 샘플링 파라미터를 임의로 바꾸면 에러가 납니다.
- 새 토크나이저 때문에 같은 텍스트가 약 30% 더 많은 토큰으로 잡힐 수 있습니다.
여기서 마지막 항목은 그냥 넘어가면 안 됩니다.
그러니까 가격표만 보고 “입력 2달러면 싸네”로 끝내면 안 됩니다.
예전 모델에서 100만 토큰으로 잡히던 요청이 Sonnet 5에서는 130만 토큰으로 잡힐 수 있습니다. 그러면 8월 31일까지의 인트로 가격에서도 입력 비용은 2달러가 아니라 2.6달러로 움직입니다. 출력까지 같이 늘면 차이는 더 커집니다.
물론 이게 무조건 나쁘다는 뜻은 아닙니다.
토크나이저가 바뀌고 성능이 좋아졌다면, 더 많은 토큰을 쓰더라도 한 번에 끝나는 작업이 늘 수 있습니다. 세 번 실패하던 일을 한 번에 끝내면 전체 비용은 오히려 줄어듭니다.
그래서 팀 운영에서는 질문을 이렇게 바꿔야 합니다.
토큰 단가가 낮아졌는가?
물론 봐야 합니다.
그런데 진짜 질문은 따로 있습니다.
한 작업을 끝내는 총비용이 줄었는가.
Sonnet 5를 “기본 모델”로 보는 건 괜찮습니다
내가 팀에서 모델 정책을 정한다면 Sonnet 5는 기본 후보에 올립니다.
특히 이런 작업에는 가장 먼저 붙여볼 만합니다.
- PR 설명 초안 작성
- 테스트 케이스 후보 만들기
- 중간 난이도 버그 재현
- 작은 리팩터링 계획 세우기
- 이슈를 개발 가능한 단위로 쪼개기
- 로그와 에러 메시지에서 원인 후보 좁히기
- 사내 라이브러리 사용 예시 만들기
이런 작업들은 너무 싼 모델만 쓰면 사람이 다시 붙잡고 고쳐야 합니다. 반대로 너무 비싼 모델을 쓰면 일은 되는데 돈을 너무 쉽게 씁니다.
Sonnet 5는 딱 이 사이를 노리는 모델입니다.
Anthropic도 발표에서 Sonnet 5가 Sonnet 4.6보다 넓은 비용-성능 선택지를 제공하고, 일부 작업에서는 Opus 4.8 수준에 닿는다고 설명합니다. 이 말은 “항상 Opus를 대체한다”가 아니라 “작업에 따라 effort를 조절하라”에 가깝습니다.
여기서 내가 더 보는 단어는 모델명이 아니라 effort입니다.
낮은 effort로 빠르게 볼 작업이 있고, 높은 effort를 써야 할 작업이 있습니다.
모든 작업에 높은 effort를 걸면, 그건 생산성 향상이라기보다 예산을 태우는 쪽에 가깝습니다.

비싼 모델을 없애자는 말은 아닙니다
Sonnet 5가 좋아졌다고 해서 Opus나 Fable급 모델이 필요 없어지는 건 아닙니다.
오히려 비싼 모델은 더 아껴 써야 합니다. 대신 쓸 때는 확실히 써야 합니다.
이런 작업은 여전히 더 강한 모델이나 사람의 깊은 리뷰가 필요합니다.
- 장애 원인이 여러 시스템에 걸쳐 있는 경우
- 보안·권한·결제·개인정보가 얽힌 변경
- 아키텍처 선택이 장기 유지보수 비용을 바꾸는 경우
- 레거시 코드에서 숨은 도메인 규칙을 건드리는 경우
- 한 번 잘못 배포하면 롤백 비용이 큰 경우
이런 작업을 싼 모델에 맡기는 건 절약이 아닙니다.
당장 청구서는 줄어들 수 있습니다. 대신 나중에 장애 대응, 고객 공지, 데이터 복구, 주말 출근으로 비용을 냅니다.
반대로 간단한 문서 정리나 테스트 후보 생성에 매번 최고급 모델을 쓰는 것도 이상합니다.
비싼 모델은 없애는 게 아니라 게이트를 세워야 합니다.
사람이 승인해야 하는가?
더 강한 모델을 쓰면 실제로 재작업이 줄어드는가?
이 질문에 답이 있을 때 비싼 모델을 쓰면 됩니다.
그냥 “제일 똑똑하니까”는 이유가 약합니다. 이제 모델 비용은 개인 장난감 값이 아니라 팀 예산 항목입니다.
GitHub도 같은 쪽으로 움직이고 있습니다
이번 일을 Anthropic 발표 하나로만 보면 반쪽입니다.
GitHub도 6월 30일에 Claude Sonnet 5를 Copilot에서 사용할 수 있게 한다고 발표했습니다. VS Code, Visual Studio, Copilot CLI, GitHub Copilot cloud agent, JetBrains, Xcode, Eclipse 같은 여러 표면에서 선택 가능하다고 안내했습니다.
같은 날 JetBrains AI Assistant 안에서 Copilot Agent를 선택할 수 있다는 발표도 나왔습니다. 여기서도 눈에 들어오는 건 단순한 모델 추가가 아닙니다. 모델을 고르고, reasoning depth를 조절해서 속도·깊이·비용을 맞춘다는 쪽입니다.
그리고 또 하나가 있습니다.
GitHub는 cost center 단위의 사용자별 AI 크레딧 예산도 발표했습니다. 예를 들어 플랫폼 엔지니어링 팀은 사용자당 250달러, 나머지는 40달러 같은 식으로 팀별 예산을 다르게 둘 수 있다는 설명까지 들어 있습니다.
이 발표들이 같은 날 몰린 건 우연처럼 보이지만, 방향은 하나입니다.
AI 코딩은 이제 “누가 어떤 모델을 쓸 수 있느냐”보다 “어떤 작업에 얼마짜리 추론을 허용할 것인가”의 문제가 되고 있습니다.
GitHub가 따로 공개한 Copilot agentic harness 글도 같은 쪽을 가리킵니다.
모델이 똑똑한 건 출발점입니다. 실제 성과는 도구, 컨텍스트, 워크플로를 어떻게 엮는지에서 갈립니다. 그래서 GitHub 글도 token efficiency를 계속 끌고 옵니다.
개발팀이 여기서 놓치면 안 되는 지점이 있습니다.
모델만 바꾸면 끝나는 게 아닙니다. 같은 모델이라도 어떤 컨텍스트를 넣는지, 어떤 도구를 붙이는지, 몇 번 재시도하는지, 사람이 어디서 승인하는지에 따라 결과와 비용이 달라집니다.
내가 개발팀에 적용한다면 이렇게 나눕니다
나는 기준을 이렇게 잡습니다.
모델을 사람 직급처럼 보지 않습니다.
작업의 실패 비용으로 봅니다.
1단계: 싸고 빠른 모델로 충분한 작업
문서 요약, 릴리즈 노트 초안, 단순 로그 정리, 에러 메시지 설명, 반복 포맷 변환 같은 작업은 굳이 Sonnet 5부터 쓸 필요가 없습니다.
이런 작업은 Haiku급이나 더 가벼운 모델로도 잘 끝나는 경우가 많습니다.
여기서 강한 모델을 쓰는 건 고급 드릴로 종이컵에 구멍 뚫는 느낌입니다. 되긴 됩니다. 그런데 그럴 이유가 별로 없습니다.
2단계: Sonnet 5를 기본으로 둘 작업
일상적인 개발 업무는 Sonnet 5가 가장 현실적인 기본값이 될 가능성이 큽니다.
PR 리뷰 보조, 테스트 후보 생성, 중간 난이도 버그 조사, 작은 리팩터링, 이슈 분해, CLI 기반 작업 자동화 같은 구간입니다.
개발팀이 처음부터 모든 작업을 최고급 모델로 보내면 비용 통제가 어렵습니다. 반대로 너무 약한 모델만 쓰면 결과가 애매해서 사람이 다시 해야 합니다.
Sonnet 5는 이 중간 구간에 꽤 잘 맞습니다.
3단계: Sonnet 5 high effort 또는 Opus급을 붙일 작업
복잡한 장애, 오래된 코드베이스의 근본 원인 추적, 테스트가 없는 레거시 리팩터링, 여러 서비스가 얽힌 변경은 더 조심해야 합니다.
이 구간에서는 Sonnet 5를 높은 effort로 돌리거나, Opus급 모델을 붙이는 게 맞을 수 있습니다.
단, 자동 승인하면 안 됩니다.
AI가 만든 답은 초안이고, 최종 책임은 사람과 팀에 남아 있습니다. 특히 운영 DB, 결제, 권한, 보안은 “모델이 강하니까 괜찮겠지”로 넘기면 안 됩니다.
4단계: 사람의 판단이 먼저인 작업
기술 선택, 제품 방향, 팀의 품질 기준, 고객에게 공지할 장애 설명, 데이터 삭제나 권한 변경 같은 작업은 AI가 도와줄 수는 있어도 주인이 되면 안 됩니다.
이건 모델 성능 문제가 아닙니다.
책임의 문제입니다.

팀장이 지금 해야 할 일은 모델 교체가 아니라 비용 로그 설계입니다
Sonnet 5가 나왔으니 바로 기본 모델을 바꾸는 팀이 많을 겁니다.
그 자체가 나쁘지는 않습니다.
하지만 그냥 바꾸면 한 달 뒤에 이런 대화가 나옵니다.
누가 이렇게 많이 썼지?
근데 실제로 뭐가 좋아졌지?
이 대화가 나오기 시작하면 이미 늦습니다.
처음부터 아래 항목을 남겨야 합니다.
- 어떤 작업 유형에 어떤 모델을 썼는가
- 입력·출력 토큰이 얼마나 나왔는가
- 한 번에 성공했는가, 몇 번 반복했는가
- 사람이 수정한 비율은 어느 정도였는가
- 운영 장애나 리뷰 반려로 이어졌는가
- prompt caching이 실제로 먹혔는가
- 고비용 모델 사용은 누가 승인했는가
이걸 남기지 않으면 모델 논쟁은 감정 싸움이 됩니다.
어떤 개발자는 “Sonnet 5면 충분하다”고 말합니다.
다른 개발자는 “그래도 Opus가 더 잘한다”고 말합니다.
둘 다 맞을 수 있습니다.
다만 작업 이름이 빠지면 논쟁만 길어집니다. PR 설명인지, 장애 원인 추적인지, 보안 변경인지가 빠진 모델 논쟁은 거의 결론이 안 납니다.
AI 코딩 비용 관리는 모델 가격표가 아니라 작업별 성공률 장부에서 시작합니다.
8월 31일까지는 테스트 기간으로 쓰는 게 좋습니다
Sonnet 5의 인트로 가격은 2026년 8월 31일까지입니다.
이 기간은 그냥 할인 기간이 아니라, 팀 기준을 만들 수 있는 유예 기간에 가깝습니다.
나는 이 기간을 무조건 “전면 도입”으로 쓰기보다, 팀별 기준을 만드는 시간으로 쓰는 편이 낫다고 봅니다.
첫 2주
Sonnet 5를 기본 모델로 놓고, 기존 Sonnet 4.6이나 Opus로 하던 일 중 일부를 옮겨봅니다. 대신 작업 유형을 반드시 기록합니다.
3~4주차
반려된 결과를 봅니다. 실패한 작업, 사람이 많이 고친 작업, 토큰이 튄 작업을 모읍니다.
5~6주차
모델 라우팅 규칙을 만듭니다. 예를 들어 단순 문서화는 가벼운 모델, 일상 코딩은 Sonnet 5, 운영 리스크가 있는 변경은 Sonnet 5 high effort 또는 Opus급 모델에 사람 승인 필수 같은 식입니다.
7~8주차
9월 1일 이후 가격으로 다시 계산합니다. 인트로 가격에서만 맞는 모델 운영이라면, 표준 가격 전환 후에는 다시 흔들립니다.
이걸 안 하고 그냥 “새 모델 좋다”로 들어가면, 9월 이후 비용표를 보고 다시 회의해야 합니다.
내 결론은 이렇습니다
Claude Sonnet 5는 AI 코딩팀에게 꽤 좋은 기본값 후보입니다.
특히 8월 31일까지는 적극적으로 실험해볼 만합니다. 가격도 좋고, 1M 컨텍스트와 에이전트 작업 성능도 매력적입니다.
하지만 나는 “이제 Sonnet 5만 쓰면 된다”는 식으로 정리하고 싶지는 않습니다.
그 결론은 너무 편합니다.
개발팀에 필요한 건 새 모델 이름보다 모델 사용 규칙입니다.
어떤 작업은 싼 모델로 끝내야 합니다.
어떤 작업은 Sonnet 5가 딱 맞습니다.
어떤 작업은 비싼 모델과 사람의 승인 게이트가 필요합니다.
AI 코딩을 잘하는 팀은
가장 비싼 모델을 쓰는 팀이 아닙니다.
싼 추론으로 끝낼 일에 돈을 태우지 않고,
비싼 실수 앞에서는 아끼지 않는 팀입니다.
팀에서 바로 써볼 체크리스트
- Sonnet 5를 기본 모델 후보로 두되, 8월 31일까지 실험 로그를 남긴다.
- 작업 유형별로 모델을 나눈다. 문서, 테스트, PR, 버그, 장애, 보안 변경을 같은 모델로 처리하지 않는다.
- 토큰 단가가 아니라 작업 완료당 비용을 본다.
- 새 토크나이저로 토큰 수가 늘 수 있다는 점을 예산 계산에 넣는다.
- prompt caching이 먹히는 구조로 공통 컨텍스트를 정리한다.
- 고비용 모델은 승인 기준을 둔다.
- AI가 만든 코드는 작성자와 리뷰어가 책임진다는 원칙을 유지한다.
- 9월 1일 표준 가격 전환 전에 팀별 사용량을 다시 계산한다.
참고한 자료
- Anthropic - Introducing Claude Sonnet 5
- Claude Platform Docs - API release notes
- Claude Platform Docs - Pricing
- GitHub Changelog - Claude Sonnet 5 is generally available for GitHub Copilot
- GitHub Changelog - Copilot Agent in JetBrains AI Assistant
- GitHub Changelog - Per-user AI credit budgets for cost centers
- GitHub Blog - Evaluating the Copilot agentic harness
'AI' 카테고리의 다른 글
| 앱인토스, 사업자부터 봐야 합니다 (0) | 2026.07.02 |
|---|---|
| 메타는 올랐고 반도체는 무너졌다 (0) | 2026.07.02 |
| AI 툴은 깔았는데, 왜 개발팀은 그대로일까 (0) | 2026.06.30 |
| AI 코딩 딸깍론, 일정 줄이면 망합니다 (1) | 2026.06.29 |
| n8n으로 AI 숏폼 공장 만들기 전, 먼저 막아야 할 것들 (0) | 2026.06.29 |