Claude 자동화의 과금 방식이 오늘(6월 15일)부터 변경됩니다: 예상치 못한 비용 발생을 피하기 위한 빠른 체크리스트

Claude의 유료 플랜에 대한 변경 사항이 오늘인 2026년 6월 15일부터 적용됩니다. 월간 요금이 인상되는 것은 아닙니다. 변경되는 점은 기존에 하나의 풀(pool)에서 차감되던 사용량이 두 가지로 분리된다는 것입니다. 즉, 사람이 대화에 참여하는 부분과 프로그램이 독자적으로 실행되는 부분으로 나뉩니다. 자세한 내용은 Anthropic의 고객 센터에 나와 있으며, 이 포스트의 모든 수치와 범위는 해당 페이지를 바탕으로 합니다.

2026년 6월 15일부터 Claude Agent SDK 및 claude -p 사용량은 더 이상 Claude 플랜의 사용량 제한(usage limits)에 포함되지 않습니다. 귀하의 구독 사용량 제한은 동일하게 유지되며, Claude Code, Claude Cowork 및 Claude의 대화형 사용을 위해 예약된 상태로 유지됩니다.

https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan

영향을 받는 쪽은 두 번째 부분입니다. 만약 귀하가 구독 플랜 내에서 자동화(automation)를 실행해 왔다면, 해당 사용량의 일부는 오늘부터 정액제 풀(flat-rate pool)에서 벗어나 종량제(metering) 방식으로 전환됩니다. 정확히 말하면, 새로 부여된 월간 크레딧(monthly credit)을 초과하여 사용하는 부분은 표준 API 요율로 청구되거나 중단됩니다. 만약 앱이나 터미널을 통해 채팅만 한다면, 귀하에게 변하는 것은 아무것도 없습니다.

가장 먼저 정확히 파악해야 할 것은 귀하의 사용량 중 어느 부분이 범위(scope)에 포함되는가 하는 점입니다. 이를 잘못 파악하면 계속 실행하고자 했던 자동화가 중단되거나, 예상치 못한 비용이 발생할 위험이 있습니다. 이 포스트는 당일 즉시 조치할 수 있는 예상치 못한 비용 방지 체크리스트를 제공하며, 이후부터 자동화를 어떻게 설계해야 하는지에 대한 더 큰 질문으로 연결합니다.

무엇이 바뀌는가

한 가지 기준을 세워야 합니다: 사람이 직접 타이핑하며 응답을 기다리고 있는가, 아니면 프로그램이 사람을 대신하여 Claude를 호출하고 있는가? 전자는 이전과 동일하게 귀하의 구독 사용량 제한을 사용합니다. 후자가 바로 새로운 월간 크레딧이 커버하는 영역입니다.

다음은 공식적인 세부 분류입니다.

사용 방식	6월 15일부터 변경되는 사항
웹, 데스크톱 또는 모바일 앱에서의 Claude 대화	구독 방식 유지. 변경 사항 없음
...

앱을 열어 채팅을 하거나, 터미널에서 Claude Code에 타이핑하고 답변을 기다리는 경우라면, 6월 15일 이후에도 이전과 동일하게 보일 것입니다. 이러한 방식은 귀하의 구독 사용량 제한 (subscription usage limits)에서 계속 차감되며, 새로운 크레딧 (credit)에는 전혀 영향을 주지 않습니다. 만약 귀하가 이 경우에 해당한다면, 오늘 당장 해야 할 일은 없습니다.

경계선은 귀하가 Claude를 수동으로 조작하느냐, 아니면 코드가 대신 조작하게 하느냐에 달려 있습니다. 쉘 스크립트 (shell script)나 크론 (cron)에서 claude -p를 실행하거나, Agent SDK를 기반으로 자체 제작한 앱을 운영하거나, Claude Code를 GitHub Actions CI 단계에 연결하는 경우 등이 해당됩니다. 만약 이 중 익숙한 내용이 있다면, 아래의 체크리스트가 귀하를 위한 것입니다.

왜 두 가지로 분리되었는가

체크리스트를 확인하기 전에, 배경 지식을 파악하면 판단을 내리는 데 도움이 됩니다. Anthropic이 이유를 직접적으로 밝히지는 않았으므로, 다음 내용은 공지 사항이 시사하는 바에 대한 저의 해석임을 참고하십시오.

정액제 구독 풀 (flat-rate subscription pool)은 종량제 API 가격 책정 (metered API pricing)을 따라야 하는 프로그래밍 방식의 사용 (programmatic use)을 원래보다 훨씬 저렴하게 실행할 수 있게 해주었습니다. 대화와 달리, 자동화 (automation)는 인간의 타이핑 속도에 얽매이지 않습니다. 스크립트나 에이전트 (agent)는 멈추지 않고 연속적으로 요청을 보내기 때문에, 동일한 월간 요금 내에서도 토큰 소비 (token consumption)가 급격히 증가합니다. 정액제 풀은 이러한 끊임없는 소비를 흡수해 왔습니다. 대신 종량제 API 가격 책정을 통해 동일한 작업을 수행한다면, 작업이 실행되는 시간이 길어질수록 그 격차는 더 벌어집니다.

다시 말해, 정액제 요금제는 사실상 자동화 비용을 보조(subsidizing)하고 있었던 셈입니다. 대화는 인간이 멈추기 때문에 자연스러운 한계치가 존재하지만, 자동화에는 그러한 제동 장치가 없습니다. 두 가지를 동일한 풀에 유지하면, 자동화를 가장 많이 사용하는 사용자가 가장 큰 할인 혜택을 받게 되며, 비용과 가격 사이의 격차는 계속해서 커지게 됩니다.

이러한 해석은 보조금(subsidy)을 종료한다는 의미로 읽히며, 이는 타당해 보입니다. 대화형 부분은 정액제 (flat rate) 내에 유지되지만, 코드가 스스로 실행되는 부분은 실제 비용을 추적하는 종량제 (metering) 방식으로 이동합니다. 대화와 자동화는 애초에 비용 구조가 달랐기 때문에 서로 다른 지갑(wallets)으로 분리된 것입니다. 이는 가격 인상이라기보다, 그동안 섞여 있던 것들을 분리하는 과정에 가깝습니다.

이러한 해석은 이 포스트의 후반부 결정 사항들로 이어집니다. 자동화는 더 이상 정액제에 포함된 부가 서비스가 아닙니다. 이제 자동화는 비용을 염두에 두고 설계해야 하는 대상이 되었습니다.

예상치 못한 요금 청구를 피하기 위한 체크리스트

본인이 적용 대상인지 확인하고, 예상치 못한 요금 청구나 갑작스러운 서비스 중단을 피하기 위해 오늘 바로 확인해야 할 사항들을 정리했습니다. 다음 순서대로 검토하면 본인이 어느 쪽에 속하는지, 무엇을 설정해야 하는지 알 수 있습니다.

첫째, 귀하의 일상적인 사용 방식이 상호작용형 (interactive)인지 비상호작용형 (non-interactive)인지 확인하십시오. 앱이나 웹에서의 채팅, 터미널이나 IDE에서 Claude Code에 타이핑하고 답변을 기다리는 것, Claude Cowork 등이 이에 해당합니다. 만약 사용 패턴이 이와 같다면 적용 대상이 아니므로 나머지 사항은 신경 쓸 필요가 없습니다. 대부분의 사용자는 여기서 해당 사항이 끝납니다.

둘째, 스스로 실행되는 모든 지점을 찾으십시오. cron이나 쉘 스크립트 (shell script)에서 claude -p를 호출하고 있습니까? Agent SDK를 기반으로 구축된 자체 제작 스크립트나 앱 (Python 또는 TypeScript)이 있습니까? Claude Code가 CI, 특히 GitHub Actions에 연결되어 있습니까? 이 모든 것이 적용 대상입니다. 백그라운드에서 조용히 실행되는 것들이 놓치기 가장 쉬우므로, 작업 정의 (job definitions), crontab, 리포지토리 워크플로 (repository workflows)를 한 번씩 열어 확인해 볼 가치가 있습니다.

셋째, 모든 제3자 도구 (third-party tools)의 인증 경로를 확인하십시오. 에디터 확장 프로그램이나 외부 에이전트 도구가 귀하의 Claude 계정에 연결되어 있고, 귀하의 구독을 통해 Agent SDK로 인증을 수행한다면 적용 대상입니다. 귀하가 직접 claude -p를 작성한 적이 없더라도, 배후에서 비상호작용형 호출을 수행하는 도구가 있다면 포함됩니다.

넷째, 인증 방식이 구독(subscription)을 통한 것인지 또는 API 키(API key)를 통한 것인지 확인하십시오. 이미 Claude Platform API 키로 인증하는 자동화는 이번 변경 사항의 적용 범위(out of scope)에서 제외됩니다. 사용한 만큼 지불하는 방식(Pay-as-you-go)의 과금은 월간 크레딧(monthly credit)의 영향을 받지 않고 계속 유지됩니다. 이것이 귀하가 적용 대상인지 여부를 결정짓는 마지막 분기점입니다.

만약 대화형(interactively)으로만 사용한다면, 오늘 당장 해야 할 일은 없습니다. 오직 자동화, 제3자 도구(third-party tools), 또는 에이전트 SDK(Agent SDK)를 사용하면서 구독 인증(subscription authentication) 방식으로 실행 중인 경우에만 다음 단계로 넘어갑니다.

영향을 받는 경우, 어떻게 해야 하는가

수행해야 할 작업은 시간축에 따라 두 단계로 나뉩니다. 오늘 완료해야 하는 당일 조치(same-day fix)와 시간을 두고 진행하는 심층적인 재작업(deeper rework)입니다. 첫 번째 조치는 자동화가 중단되는 것을 방지하기 위한 임시방편(stopgap)이며, 진정한 해결책은 두 번째 단계에 있습니다.

빠른 조치: 크레딧을 수령하고 중단 방식 결정하기

대상 플랜에는 월간 크레딧이 제공됩니다. 공식 명칭은 "에이전트 SDK 크레딧 (Agent SDK credit)"이지만, SDK를 직접 작성하는 사람에게만 국한되지 않습니다. cron이나 CI에서의 claude -p 호출, GitHub Actions 통합, 그리고 위에서 확인한 제3자 도구들은 모두 동일한 이 크레딧을 사용합니다. SDK를 전혀 만지지 않더라도, 무언가가 Claude를 비상호작용형(non-interactively)으로 실행하고 있다면 귀하는 적용 대상입니다. 크레딧 금액은 귀하의 플랜 월간 요금과 동일합니다.

플랜	월간 크레딧
Pro	$20
...

사용자 수 기반(seat-based)의 엔터프라이즈(Enterprise) 플랜의 경우, 프리미엄(Premium) 시트는 대상이지만 스탠다드(Standard) 시트는 대상이 아닙니다. 귀하의 계정을 통해 크레딧을 한 번 수령(일회성 옵트인, opt-in)하면, 그 이후에는 매 결제 주기마다 자동으로 갱신됩니다. 6월 15일부터 대상 사용자에게는 수령 방법이 안내된 이메일이 발송될 예정입니다.

여기서 경로가 갈립니다. 자동화를 계속 사용할 계획이라면, 가장 먼저 해야 할 일은 해당 이메일을 놓치지 않고 크레딧을 수령하는 것입니다. 반대로 자동화에 대한 비용 청구를 피하고 싶거나 자동화가 중단되어도 상관없다면, 서둘러 수령할 필요는 없습니다. 우선 자동화를 계속 실행할 것인지 자체를 결정하는 것부터 시작하십시오.

다음으로, 크레딧(credit)이 소진되었을 때 어떤 일이 발생할지 결정해야 합니다. Agent SDK 사용량은 이 크레딧에서 가장 먼저 차감되며, 그 이후의 동작은 설정에 따라 달라집니다. "추가 사용(Extra Usage)"을 활성화하면, 초과분은 표준 API 요율로 청구되며 자동화는 계속 실행됩니다. 이를 활성화하지 않으면, 크레딧이 소진되는 즉시 요청이 중단되며 크레딧이 갱신될 때까지 중단 상태가 유지됩니다.

중단되어서는 안 되는 프로덕션 워크플로(production workflow)의 경우, 자동화를 계속 실행할 수 있도록 추가 사용을 활성화하는 것이 더 안전한 선택이지만, 예상치 못한 거액의 청구서가 발생할 여지가 있습니다. 중단되어도 지장이 없는 실험적인 자동화의 경우, 의도적으로 이 기능을 꺼두어 크레딧이 절대 넘지 않는 지출 상한선(spending ceiling) 역할을 하게 할 수도 있습니다. 즉, "중단되었을 때의 타격이 얼마나 큰가"와 "예상치 못한 요금 청구가 얼마나 두려운가" 사이에서 무게를 재는 것입니다.

이와 함께 크레딧의 제약 사항도 유의하십시오. 크레딧은 사용자당 부여되며, 팀 전체가 통합하거나 공유할 수 없습니다. 크레딧은 매월 초기화되며, 사용하지 않은 크레딧은 이월되지 않습니다. 팀 단위로 자동화를 실행한다면 "모두가 한 사람의 크레딧을 사용하는" 방식은 불가능하며, 이 점을 반드시 염두에 두어야 합니다.

더 깊은 수준의 재작업: 설계 결정으로서의 인증 경로 선택

빠른 해결책(quick fix)은 주어진 크레딧 범위 내에서 버티는 것에 관한 것이었습니다. 더 깊은 수준의 재작업은 자동화가 어떤 인증 경로(authentication path)를 따를 것인지 기초부터 다시 고려하는 것입니다.

Anthropic은 월간 크레딧을 "개별적인 실험 및 자동화에 적합한 규모"로 정의합니다. 이를 반대로 해석하면, 공유된 프로덕션 자동화는 이 크레딧 범위 내에 들어오도록 설계되지 않았다는 뜻입니다. 실제로 Anthropic은 프로덕션 자동화를 실행하는 팀에게 Claude Platform API 키를 사용할 것을 권장합니다. API 키 사용은 이번 변경 사항의 범위 밖입니다. 즉, 종량제(pay-as-you-go) 방식이 계속 유지되며 별도의 월간 크레딧은 부여되지 않습니다.

이 지점에서 앞서 언급한 "자동화는 더 이상 부가적인 요소가 아니다"라는 해석이 빛을 발합니다. 자동화를 구축할 때 구독 인증(subscription auth)을 사용할지, API 키 인증(API-key auth)을 사용할지는 비용 구조와 한계 상황에서의 동작 방식을 모두 결정짓는 설계 결정(design decision)이 되었습니다.

인증 경로 (Auth path)	비용 청구 방식 (How cost reads)	한도 도달 시 (When you hit the limit)
구독 인증 (Subscription auth, Agent SDK credit)	월간 요금제 비용과 동일한 월간 크레딧 제공, 매월 초기화	추가 사용 설정이 꺼져 있으면 중단, 켜져 있으면 표준 API 요율로 계속 진행
API 키 인증 (API-key auth, Claude Platform)	선불 크레딧 잔액에서 사용한 만큼 결제 (pay-as-you-go)	잔액 소진 시 중단, 자동 충전 (auto-reload)을 통해 계속 진행 가능

가벼운 실험이나 개인용 보조 자동화의 경우, 구독 크레딧(subscription credit)으로 충분히 커버할 수 있습니다. 크레딧 소진 시 작동이 중단되는 방식은 절대 넘지 않을 지출 상한선(spending ceiling) 역할을 합니다. 반면, 중단되었을 때 타격이 큰 운영 환경(production)용 자동화나 팀 전체가 공유하는 워크플로우의 경우, API 키 인증(API-key auth)을 관리하기가 더 쉽습니다. 사용량이 청구 항목으로 직접 나타나므로 파악이 명확하며, 자동 충전(auto-reload) 및 사용량 알림(usage alerts)을 통해 잔액을 관리할 수 있기 때문입니다. 두 방식 모두 잔액이 소진되면 중단되지만, 구독 인증은 요금제 비용에 묶인 고정된 풀(flat pool)인 반면, API 키는 사용자가 직접 충전하는 잔액입니다. 운영 환경에서 무언가를 안정적으로 실행하려면, 상한선이 요금제 비용에 고정되지 않은 API 키가 더 많은 운영상의 자유(operational freedom)를 제공합니다.

제기할 만한 반론

위의 설명에 대해 몇 가지 반론이 떠오릅니다. 그 반론들을 제기하고 각각에 대해 답변해 보겠습니다.

반론 1: 그냥 모든 것을 API 키로 처리하면 되잖아요

그럼 그냥 모든 것을 API 키로 처리하고 두 개의 지갑을 걱정하는 일을 그만두면 안 되나요?

여기에는 일리가 있는 부분이 있습니다. API 키로 통합하면 대화 (conversation)와 자동화 (automation) 모두 동일한 종량제 (pay-as-you-go) 과금 방식을 따르게 되므로, 구독 크레딧과 API 잔액을 별도로 관리할 필요가 없습니다. 하지만 대화의 경우, API 키로 전환하는 것이 비용이 더 많이 드는 경향이 있습니다. 구독 모델은 사용 한도 내에서 대화가 정액제 (flat-rate)로 제공되어 사실상 무제한으로 이용할 수 있도록 설계되었습니다. 이를 사용량 기반의 API 가격 책정 (metered API pricing) 방식으로 옮기면, 기존에 월간 요금에 포함되었던 모든 대화 턴 (conversational turn)이 토큰당 과금 (per-token billing) 방식으로 바뀌게 됩니다. 대화는 구독의 정액제를 유지하고, 부하가 큰 자동화 부분만 API 키로 분리하는 것이 현실적인 착륙 지점입니다.

반론 2: 내 자동화는 가벼우니까 괜찮다

내 자동화는 가벼우니까, 나에게 부여된 크레딧 범위 내에 들어오겠죠?

많은 경우 그렇습니다. 가끔씩만 스크립트를 실행한다면 부여된 크레딧으로 충분합니다. 문제는 자신의 소비량을 모르는 상태에서 "아마 괜찮을 것이다"라고 추정하는 것입니다. 에이전트 (agent)를 지속적으로 실행하거나 CI에서 자주 호출한다면, 예상보다 빠르게 크레딧을 소진할 수 있습니다. "범위 내에 들어온다"는 판단이 맞더라도, 한 번은 근거를 확인하는 것이 안전합니다. 체크리스트에서 확인한 실행 빈도를 바탕으로, 변경 사항이 적용된 후 결제 화면의 실제 소비량과 대조해 보십시오.

반론 3: 결국은 가격 인상 아닌가

뭐라고 부르든 간에, 결국 이건 가격 인상 아닌가요?