앤트로픽, Claude Sonnet 4·Opus 4 API 6월 15일부로 종료 — 안 옮긴 프로덕션은 그냥 멈춘다

"내일부터 이 모델 안 됨" — 개발자한테 제일 무서운 종류의 뉴스

자, 이건 화려한 신모델 출시 뉴스가 아니야. 오히려 그 반대인데, 개발자한테는 어떤 출시보다 발등에 불 떨어지는 종류의 소식이지. 앤트로픽이 2026년 6월 15일부로 Claude Sonnet 4와 Opus 4를 API에서 완전히 내렸어. 그것도 부드러운 단종이 아니라, 그날 이후 해당 모델을 API로 호출하면 곧장 에러가 반환돼. 마이그레이션을 안 해둔 프로덕션 앱은 그냥 멈춘다는 뜻이야.

상황을 정리하면 이래. 앤트로픽은 이걸 갑자기 통보한 게 아니야. 4월 14일에 미리 두 모델의 6월 15일 은퇴를 공지했어. 약 두 달의 시간을 준 거지. 대상은 처음 출시됐던 핀(pinned) 버전, 즉 특정 날짜로 고정된 Sonnet 4와 Opus 4 모델이야. 대체재는 같은 계열의 더 새로운 세대 — Sonnet 4.6과 Opus 4.8 — 이고.

여기서 안심할 사람도 있고 발등에 불 떨어질 사람도 있어. 일반 Claude.ai 사용자와 Claude Code 관리형 환경은 영향이 없어. 거기선 앤트로픽이 알아서 모델을 최신으로 잡아주거든. 반면 API로 특정 모델 버전을 콕 찍어 호출하던 개발자는 직접 손을 봐야 해. 코드 안에 'claude-sonnet-4-...' 같은 옛 모델 문자열이 박혀 있으면, 6월 15일부터 그 호출이 깨지는 거야.

그래서 오늘 풀 이야기는 이거야. 왜 AI 회사가 잘 쓰던 모델을 일부러 죽이는지, 마이그레이션이 실제로 얼마나 번거로운지(스포: 보통은 한 줄이야), 그리고 이번에 같이 바뀐 '요금 체계'가 왜 더 조용히 중요한지. 개념 몇 개만 잡으면 돼.

등장인물 — 앤트로픽, '핀 버전', 그리고 마이그레이션

먼저 앤트로픽. Claude를 만드는 회사인데, 모델을 계속 새 세대로 갈아치우는 중이야. AI 모델은 소프트웨어처럼 버전이 계속 올라가는데, 옛 버전을 영원히 굴리는 건 회사 입장에서 비용이야. 컴퓨팅 자원을 옛 모델에 묶어두느니, 더 좋고 효율적인 신모델로 사용자를 옮기고 옛것을 정리하는 게 합리적이지. 그래서 주기적으로 '모델 은퇴(deprecation)'를 단행해.

다음 주인공은 사람이 아니라 개념인데, 바로 **'핀(pinned) 버전'**이야. 개발자가 API로 모델을 부를 때, 'claude-sonnet-4-20250514'처럼 특정 날짜가 박힌 정확한 버전을 지정할 수 있어. 이걸 핀이라고 해. 핀을 쓰면 "내가 테스트한 바로 그 모델"이 안 바뀌어서 결과가 일관되는 장점이 있지만, 반대로 그 버전이 은퇴하면 직접 바꿔줘야 한다는 책임이 따라와. 이번에 깨진 게 바로 이 핀 호출이야.

세 번째 주인공은 마이그레이션(migration), 즉 옛 모델에서 새 모델로 갈아타는 작업이야. 무섭게 들리지만, 사실 대부분의 경우 마이그레이션은 코드 속 모델 이름 문자열 한 줄을 새 모델로 바꾸는 것이 거의 전부야. 'claude-sonnet-4-...'를 최신 Sonnet으로 고치고, 출력이 예전과 비슷하게 나오는지 테스트한 뒤 배포하면 끝이지. 다만 '한 줄'이라도, 그 한 줄을 안 바꾸면 서비스가 멈춘다는 게 핵심이야.

이 셋의 관계를 한 문장으로 묶으면 이래. 앤트로픽이 옛 세대를 정리하면서, '특정 버전을 콕 찍어 쓰던' 개발자에게 '한 줄짜리 숙제'를 던졌고, 그 숙제를 안 한 앱은 6월 15일부로 멈춘다. 이게 이야기의 뼈대야.

핵심 내용 — 정확히 뭐가 바뀌었나

말로 풀면 흩어지니까, 확인된 사실을 표로 보자.

항목	내용
종료 모델	Claude Sonnet 4, Claude Opus 4 (초기 핀 버전)
종료일	2026년 6월 15일 (유예 없음)
사전 공지	2026년 4월 14일 (약 2개월 전)
종료 후 동작	해당 모델 API 호출 시 즉시 에러 반환
영향 없는 곳	일반 Claude.ai 사용자, Claude Code 관리형 환경
영향 받는 곳	옛 모델 핀을 직접 호출하던 API 사용 앱
대체 모델	최신 세대 (Sonnet 4.6 / Opus 4.8 등)
마이그레이션	대개 모델 문자열 한 줄 교체 + 출력 테스트
또 하나의 변화	구독 요금제의 프로그래밍 방식 사용이 별도 월별 크레딧 풀로 이전

표를 한 줄씩 보자. 우선 **'유예 없음(no grace period)'**이 핵심이야. 보통 단종은 "이제 권장 안 함, 그래도 당분간은 됨" 식의 부드러운 과정이 많은데, 이번엔 6월 15일부터 호출이 바로 에러를 뱉어. 즉 "조금 더 쓰다가 천천히 옮기자"가 안 통해. 안 옮긴 프로덕션은 그날 멈추는 거지.

두 번째로 **'일반 사용자·Claude Code는 영향 없음'**이 의미 있어. 네가 그냥 Claude.ai 채팅을 쓰거나 Claude Code로 코딩하는 거라면 아무것도 안 해도 돼. 앤트로픽이 그쪽은 알아서 최신 모델로 굴리거든. 발등에 불 떨어진 건 어디까지나 'API에 옛 버전 문자열을 직접 박아 둔' 개발자들이야. 누가 영향받고 누가 안 받는지 구분이 명확하다는 게 그나마 다행이지.

세 번째로 진짜 조용히 중요한 게 **'요금 체계 변화'**야. 구독 요금제를 통한 프로그래밍 방식(API) 사용이 별도의 월별 크레딧 풀로 옮겨갔거든. 이건 모델 종료와는 다른 축의 변화인데, 같은 6월 15일에 같이 터져서 'June 15에 두 개의 데드라인'이라고 불려. 모델만 바꾸면 끝이 아니라, 과금이 어떻게 계산되는지도 다시 확인해야 한다는 뜻이야.

각자의 이득 — 누가 뭘 얻고 잃나

앤트로픽의 이득부터 보자. 옛 모델을 정리하면 컴퓨팅 자원을 신모델에 집중할 수 있어. AI 추론은 비싼데, 구버전·신버전을 동시에 떠받치는 건 낭비거든. 사용자를 더 좋고 효율적인 최신 모델로 몰아주면 회사 입장에선 비용도 줄고 제품 품질도 일관되게 관리하기 쉬워져. 모델 라인업을 깔끔하게 유지하는 건 장기적으로 합리적인 선택이야.

개발자 입장의 손익은 양면이야. 손해는 분명해 — 갑자기 마이그레이션이라는 숙제가 생겼고, 안 하면 서비스가 멈쳐. 특히 옛 모델 문자열을 여러 곳에 박아둔 큰 코드베이스라면 다 찾아 바꾸는 게 귀찮지. 근데 이득도 있어. 최신 세대(Sonnet 4.6·Opus 4.8)는 대개 더 똑똑하고 효율이 좋으니까, 강제로 옮기는 김에 성능이 올라가는 셈이거든. '울며 겨자 먹기'지만 먹고 나면 영양가는 있는 거지.

그리고 의외의 교훈을 얻는 쪽은 모든 API 소비자야. 이번 일은 'AI 모델은 영원하지 않다'는 걸 다시 일깨워줬어. 특정 버전에 깊이 의존하는 설계는 그 모델이 은퇴하는 순간 리스크가 돼. 그래서 앞으로는 "모델 이름을 한 곳에서만 관리한다", "은퇴 공지를 모니터링한다", "정기적으로 신모델로 테스트해 둔다" 같은 운영 습관이 중요해진다는 걸 다들 체감하는 계기가 됐지.

종합하면, 앤트로픽은 자원 효율, 개발자는 (귀찮지만) 성능 업그레이드를 얻어. 다만 '한 줄 교체'가 정말 한 줄로 끝나느냐는 코드베이스마다 다르고, 요금 체계 변화까지 겹쳐서 이번 6월 15일은 개발자들이 꽤 분주했던 날이야.

과거 유사 사례 — 성공과 실패

'API 버전 단종'은 AI만의 일이 아니야. 클라우드·결제·지도 같은 모든 주요 API 서비스가 주기적으로 옛 버전을 죽여왔어. 성공 사례는 '충분한 사전 공지 + 명확한 마이그레이션 가이드'를 준 경우야. 앤트로픽이 4월 14일에 미리 알리고, 무엇이 영향받고 무엇이 안 받는지 문서로 정리한 건 이 정석을 따른 거지. 미리 알려주면 개발자도 욕은 해도 대비는 할 수 있으니까.

근데 실패 사례도 똑똑히 봐야 공정해. 사전 공지를 했어도, 정작 그 공지를 못 본 개발자는 데드라인 당일 서비스가 깨지고 나서야 알게 돼. "메일로 알렸는데?"와 "그 메일을 다들 봤나?"는 완전히 다른 문제거든. 그래서 큰 변화일수록 한 번의 공지로 끝내지 않고, 데드라인이 다가올수록 반복 알림과 대시보드 경고를 주는 게 더 친절한 운영이야. '유예 없음'은 특히 이 지점에서 비판받기 쉬워.

또 하나의 균형 잡힌 시각은 '안정성 vs 최신성'의 영원한 딜레마야. 핀 버전을 쓰는 건 '내가 검증한 그 모델이 안 바뀌니 결과가 일관된다'는 안정성을 위해서야. 근데 그 대가가 '은퇴하면 직접 옮겨야 하는 책임'이고. 반대로 '최신 모델 자동 추적' 설정을 쓰면 옮길 일은 없지만, 모델이 말없이 바뀌어 결과가 달라질 위험을 안아. 정답은 없고, '내 서비스가 일관성과 최신성 중 뭘 더 중시하느냐'에 달려 있어.

그래서 균형 잡힌 결론은 이래. 앤트로픽의 사전 공지·문서화는 정석을 따랐지만, '유예 없음'은 못 본 개발자한테 가혹할 수 있다. 과거 사례가 알려주는 교훈은, API 의존은 곧 '벤더의 일정에 내 서비스가 묶인다'는 뜻이고, 그래서 '갈아탈 수 있게' 설계해 두는 게 최선의 방어라는 것 하나야.

경쟁자 카운터 플레이

앤트로픽이 옛 모델을 칼같이 자르면, 경쟁자들은 어떻게 나올까? 첫 번째는 '우리는 더 오래 지원한다'는 포지셔닝이야. 일부 경쟁사는 "우리는 옛 모델을 더 길게, 더 부드럽게 유지한다"며 안정성을 중시하는 기업 고객을 노릴 수 있어. 자주 갈아타는 게 부담인 보수적 조직한테는 '오래 가는 버전'이 의외의 매력 포인트거든.

두 번째는 마이그레이션 전환 유도야. 개발자가 어차피 코드를 손봐야 하는 이 순간이, 경쟁사한텐 기회야. "어차피 모델 문자열 바꿀 거면, 우리 모델로 바꿔보는 건 어때?"라고 들어올 수 있지. 단종 시점은 사용자가 가장 갈아탈 마음이 열리는 때라, 경쟁사들이 마이그레이션 가이드와 호환 레이어를 들고 영업하기 좋은 타이밍이야.

세 번째는 '모델 추상화 도구'의 부상이야. 여러 AI 제공사를 같은 코드로 부를 수 있게 해주는 라이브러리·프록시가 이런 때 빛을 봐. 모델 이름을 한 곳에서만 관리하면, 특정 모델이 은퇴해도 설정 한 줄로 갈아탈 수 있거든. 이번 같은 강제 마이그레이션을 몇 번 겪으면, 개발자들은 자연히 '벤더 종속을 줄이는 추상화 레이어'에 끌리게 돼.

그리고 잊지 말 변수, 신뢰의 문제. 모델 은퇴 자체는 정상적인 운영이지만, '유예 없음'을 반복하면 개발자들이 "이 회사 모델은 언제 또 갑자기 끊길지 모른다"는 불안을 갖게 돼. 반대로 예측 가능하고 친절하게 전환을 관리하면 그게 곧 신뢰 자산이 되고. 그러니 이런 단종 운영의 질은 단순한 기술 이슈를 넘어, 장기적으로 개발자 생태계의 충성도를 가르는 문제이기도 해.

그래서 뭐가 달라지는데 — 입장별로

개발자·엔지니어라면. 당장 할 일은 두 가지야. 첫째, 코드에서 옛 모델 핀 문자열을 다 찾아 최신 모델로 바꾸고 출력을 테스트해. 둘째, 구독 요금제로 API를 돌리고 있었다면 과금이 별도 크레딧 풀로 바뀐 걸 확인해. 그리고 앞으로를 위해선, 모델 이름을 설정 한 곳에서만 관리하는 구조로 바꿔두면 다음 단종 때 훨씬 편해져. 한 줄 바꾸면 끝나게 미리 설계해 두는 거지.

기업 의사결정자라면. 교훈은 'AI 의존은 곧 벤더 일정에 묶이는 것'이라는 거야. 핵심 서비스가 특정 모델 버전에 깊이 박혀 있으면, 그 모델이 은퇴할 때마다 긴급 작업이 발생해. 그러니 모델 교체를 전제로 한 설계(추상화, 멀티 벤더, 회귀 테스트)를 평소에 깔아두는 게 리스크 관리의 핵심이야. 그리고 벤더의 '단종 정책'이 얼마나 예측 가능하고 친절한지도, 도입 평가 기준에 넣을 만해.

일반 관찰자라면. 이 사건의 의미는 'AI 모델은 제품이 아니라 살아 움직이는 서비스'라는 걸 보여준다는 거야. 우리가 쓰는 AI는 어느 날 조용히 더 좋은 버전으로 바뀌고, 옛 버전은 은퇴해. 화려한 신모델 발표 뒤편에는 늘 이런 '옛 모델 정리'가 따라온다는 걸 알면, AI 산업이 실제로 어떻게 굴러가는지가 더 입체적으로 보여.

세 입장을 관통하는 한 줄은 이거야. AI 모델은 영원하지 않다 — 그러니 '갈아탈 수 있게' 만들어 두는 게 가장 싼 보험이다. 이번 6월 15일이 그 교훈을 개발자 모두에게 다시 새긴 날이었지.

🥄 남은 궁금증 세 가지

— 나 영향 받는 거 맞아? 네가 Claude.ai 채팅이나 Claude Code 관리형 환경만 쓴다면 아무 영향 없어. 거긴 앤트로픽이 알아서 최신 모델로 굴려주거든. 영향받는 건 'API로 claude-sonnet-4-... 같은 옛 버전을 직접 콕 찍어 호출하던' 경우야. 코드에 그런 문자열이 박혀 있는지부터 검색해 보면 바로 알 수 있어.

— 마이그레이션 진짜 한 줄이면 끝나? 대개는 모델 이름 문자열 한 줄 바꾸고 출력 테스트하면 끝이야. 근데 '대개'지 '항상'은 아니야. 모델이 바뀌면 답변 스타일이나 형식이 미묘하게 달라질 수 있어서, 프롬프트나 후처리를 조금 손봐야 할 때도 있어. 그래서 바꾸고 끝이 아니라, 중요한 케이스 몇 개로 결과가 예전과 비슷한지 확인하고 배포하는 게 안전해.

— 왜 유예 기간도 없이 그렇게 칼같이 끊어? 회사 입장에선 옛 모델을 계속 떠받치는 게 컴퓨팅 비용이라서 그래. 4월 14일에 미리 공지해서 약 두 달을 준 거고, 그쯤이면 충분하다고 본 거지. 다만 공지를 못 본 개발자한텐 가혹할 수 있어서, '유예 없음'은 비판의 여지가 있는 선택인 것도 사실이야. 예측 가능성과 비용 효율 사이의 트레이드오프인 셈이고.

참고 자료

• Model deprecations — Claude API Docs
• Claude Sonnet 4 and Opus 4 Deprecation: What You Need to Do Before June 15 — MindStudio
• Two Claude Deadlines Hit June 15: What AI Builders Must Do — Enterprise DNA
• Anthropic Claude model deprecations on June 15, 2026 — Make Help Center
• Models overview — Claude API Docs

수치는 발표 시점 기준이라 바뀔 수 있어.