5월 중순에 예고되었던 Claude의 과금 변경이 오늘 2026년 6월 15일부터 시작됩니다. 당시 "6월 15일부터 변경된다"는 뉴스를 본 기억이 있는 분들도 있을 것입니다. 그 변경이 드디어 시행일을 맞이했습니다. 월간 요금 자체가 인상되는 것은 아닙니다. 변경 내용은 Anthropic의 공식 도움말 센터에 기재되어 있습니다. 본 기사의 수치나 대상 범위는 모두 이 페이지를 바탕으로 합니다.

2026년 6월 15일부터, Claude Agent SDK와

claude -p

의 사용은 Claude 플랜의 사용 제한(Usage limits)에 카운트되지 않게 됩니다. 구독(Subscription) 사용 제한은 동일하게 유지되며, Claude Code, Claude Cowork, 그리고 Claude의 대화형 사용을 위해 예약된 상태로 남습니다.

지금까지 하나의 사용 범위 내에서 처리되었던 이용이, "사람이 대화하는 부분"과 "프로그램이 자동으로 돌리는 부분"의 두 가지로 나뉩니다.

오늘부터 영향을 받는 것은 후자입니다. 구독 플랜 내에서 자동화를 돌리고 있던 사람에게는, 오늘부터 일부 이용이 정액제 범위 밖으로 나가 종량제(Pay-as-you-go) 대상이 되기 시작합니다. 정확하게는, 새롭게 부여되는 월간 크레딧(Monthly credits)을 다 쓴 만큼 종량제로 전환되거나 정지되는 형태입니다. 반대로, 앱이나 터미널에서 대화형으로 사용하고 있을 뿐이라면 지금까지와 다를 바 없습니다.

첫 번째 관문은 "자신의 어떤 이용이 대상인지"를 올바르게 구분하는 것입니다. 이 부분을 잘못 판단하면, 멈추고 싶지 않은 자동화가 멈추거나 예상치 못한 과금이 발생할 수 있습니다. 이 기사에서는 불필요한 과금을 방지하기 위한 확인 절차를 당일의 응급 처치로서 제시한 뒤, 그 너머에 있는 "자동화를 어떻게 다시 설계할 것인가"까지 연결하여 정리합니다. 이번 분리는 정액제 플랜 안에서 자동화 에이전트(Agent)를 막연하게 돌릴 수 있었던 시대에 일단락을 짓는 것이기도 하기 때문입니다.

어떻게 변하는가

구분의 기준은 하나입니다. "사람이 화면을 향해 대화하고 있는가" 아니면 "프로그램이 사용자를 대신해 자동으로 호출하고 있는가"입니다. 전자는 기존처럼 구독 사용 범위를 계속 사용하며 아무것도 변하지 않습니다. 후자가 신설되는 월간 크레딧의 대상이 됩니다.

공식 구분은 다음과 같습니다.

평소 Claude를 앱으로 열어 대화하거나, 터미널에서 Claude Code와 대화하며 코드를 작성하는 방식의 사용이라면 6월 15일 이후에도 지금까지와 같습니다. 이것들은 구독 사용 범위를 계속 사용하며, 신설된 크레딧과는 관계가 없습니다. 여기에 해당되는 분들은 오늘은 특별히 할 일이 없습니다.

분기점은 Claude를 "자신의 손으로 조작하고 있는가" 아니면 "코드로 조작하게 하고 있는가"에 있습니다. 전자는 구독 범위 그대로이며, 후자가 크레딧의 대상입니다. 쉘 스크립트(Shell script)나 cron으로 claude -p를 돌리고 있거나, Agent SDK를 사용한 자체 앱이 있거나, GitHub Actions의 CI에 Claude Code를 포함시키고 있는 경우. 이 중 하나라도 해당된다면 이후의 확인 절차가 유효합니다.

왜 두 가지로 나뉘었는가

확인 절차에 들어가기 전에, 이 변경의 배경을 파악해 두면 판단이 흔들리지 않습니다. 참고로, 여기서부터는 공식이 이유를 명시한 것이 아니라, 발표 내용을 통해 추측할 수 있는 이유를 정리한 것입니다.

구독의 정액제 범위는 본래 API 종량제로 작동해야 할 프로그램 이용을 상당히 저렴하게 돌릴 수 있는 상태를 허용해 왔습니다. 대화와 달리 자동화는 인간의 입력 속도에 얽매이지 않습니다. 스크립트나 에이전트는 쉬지 않고 연속해서 요청(Request)을 보낼 수 있기 때문에, 동일한 월간 범위 내에서도 소비 토큰(Token)량이 크게 불어납니다. 정액제 범위는 이 "멈추지 않는 소비"를 그대로 흡수하고 있었습니다. 동일한 처리를 API의 종량제로 실행했을 경우와 비교하면, 계속 돌릴수록 차이가 벌어지는 구조입니다.

즉, 정액제 플랜이 자동화 비용을 실질적으로 대신 부담하고 있었다고 볼 수 있습니다. 대화형 이용은 인간의 손이 멈추는 만큼 소비에 상한이 생기지만, 자동화에는 그러한 자연스러운 제동 장치가 없습니다. 양자를 같은 틀에 넣어두면, 자동화 헤비 유저일수록 저렴하게 이용하는 혜택이 커지며 비용과 요금의 차이가 벌어지게 됩니다.

이번 분리는 이러한 '대신 부담'을 그만두는 변경이라고 보면 맥락이 통합니다. 사람이 대화하는 부분은 기존처럼 정액제 안에 두고, 코드가 자동으로 돌리는 부분은 실제 비용에 가까운 종량제로 옮기는 것입니다. '대화'와 '자동화'로 지갑을 나눈 이유는, 두자의 비용 구조가 애초에 다르기 때문일 것입니다. 가격 인상이 아니라, 섞여 있던 것을 분리했다고 보는 것이 적절할 것 같습니다.

이러한 관점은 후반부의 판단에 그대로 영향을 미칩니다. 자동화는 이제 '정액제에 포함된 덤'이 아니라, 비용을 의식하며 설계해야 하는 대상이 되었기 때문입니다.

불필요한 과금을 방지하는 확인 절차

대상 여부를 구분하여 불필요한 과금이나 예기치 않은 중단을 방지하기 위해, 오늘 중으로 확인해야 할 사항을 절차로 정리했습니다. 순서대로 따라가다 보면 자신이 어느 쪽에 속하며 무엇을 설정해야 하는지 알 수 있습니다.

먼저, 일상적인 사용 방식이 대화형인지 비대화형인지 확인합니다. 앱이나 웹에서의 채팅, 터미널이나 IDE에서 입력하고 응답을 기다리는 Claude Code, Claude Cowork. 이것들뿐이라면 대상이 아니므로 이후의 확인은 필요 없습니다. 대부분의 사람은 여기서 끝날 것입니다.

다음으로, 자동 실행 중인 부분을 찾아냅니다. cron이나 쉘 스크립트(shell script)에서 claude -p를 호출하고 있지는 않은지. Agent SDK를 사용한 자체 스크립트나 앱(Python 또는 TypeScript)이 있는지. CI, 특히 GitHub Actions에 Claude Code를 포함시키지는 않았는지. 모두 대상입니다. 평소에는 의식하지 못한 채 돌아가고 있는 것일수록 놓치기 쉬우므로, 잡(job) 정의나 crontab, 리포지토리(repository)의 워크플로우를 한 번 열어서 확인해 볼 가치가 있습니다.

이어서, 서드파티(third-party) 도구의 인증 경로를 확인합니다. 에디터 확장 기능이나 외부 에이전트 도구에서 Claude 계정을 연동한 경우, 그것이 Agent SDK를 통해 구독 인증을 하고 있다면 대상입니다. 직접 claude -p를 작성하지 않았더라도, 도구가 백그라운드에서 비대화형 호출을 하고 있다면 과금 대상이 됩니다.

마지막으로, 해당 인증이 구독 방식인지 API 키 방식인지 확인합니다. 이미 Claude Platform의 API 키로 인증하고 있는 자동화는 이번 변경의 대상이 아닙니다. 종량제 과금이 기존처럼 유지되며, 월간 크레딧 한도에도 영향을 받지 않습니다. 대상 여부를 가르는 최종적인 분기점은 바로 여기에 있습니다.

대화형으로만 사용하고 있다면 오늘은 더 이상 할 일이 없습니다. 자동 실행이나 서드파티 도구, Agent SDK 중 하나에 해당하면서 구독 인증으로 작동하는 경우에만 다음 대응으로 넘어갑니다.

해당될 경우, 어떻게 대응해야 하는가

대상인 경우 해야 할 일은 시간 축에 따라 두 단계로 정리할 수 있습니다. 오늘 중으로 끝내는 응급 처치와, 본격적으로 임해야 하는 근본적인 재검토입니다. 전차만으로도 자동화가 멈추는 것은 막을 수 있지만, 이는 임시방편일 뿐 본질적인 해결은 후자에 있습니다.

응급 처치: 크레딧을 청구하고, 중단 여부를 결정하기

대상 플랜에는 월간 크레딧이 부여됩니다. 공식 명칭은 'Agent SDK 크레딧'이지만, 대상은 SDK를 직접 작성하는 사람에 국한되지 않습니다. 앞서 확인한 cron이나 CI의 claude -p, GitHub Actions, 서드파티 도구를 통한 이용도 모두 이 동일한 크레딧에서 소비됩니다. SDK를 직접 다루지 않더라도 비대화형으로 Claude를 돌리고 있다면 대상입니다. 플랜의 월정액과 동일한 금액의 크레딧이 들어옵니다.

Enterprise 플랜에서 시트(seat) 기반인 경우, Premium 시트는 대상이지만 Standard 시트는 크레딧 대상이 아닙니다. 크레딧은 계정에서 한 번만 청구(opt-in)하면 이후에는 청구 주기마다 자동으로 갱신됩니다. 6월 15일 이후, 대상 사용자에게는 청구 절차를 안내하는 메일이 발송될 예정입니다.

여기서 방침이 두 가지로 나뉩니다. 자동화를 앞으로도 계속 사용할 것이라면, 이 메일을 놓치지 않고 청구를 완료해 두는 것이 첫 번째 단계입니다. 반대로, 이를 계기로 자동화 과금을 피하고 싶거나 중단해도 상관없다면 서둘러 청구할 필요는 없습니다. 자신이 자동화를 앞으로 계속 돌릴 것인지부터 결정해야 합니다.

다음으로, 크레딧을 모두 사용한 후의 동작을 결정해 두어야 합니다. Agent SDK 이용은 이 크레딧에서 가장 먼저 차감되며, 초과분에 대한 처리는 설정에 따라 달라집니다. '추가 사용량 (Additional usage)'을 활성화해 두면, 초과분은 표준 API 레이트 (API rate)로 종량 과금되어 자동화가 중단되지 않습니다. 활성화하지 않으면 크레딧이 소진되는 시점에 요청이 중단되며, 다음 갱신 시점까지 작동하지 않습니다.

중단되면 곤란한 운영 환경 (Production) 워크플로우라면, 추가 사용량을 활성화하여 지속시키는 편이 안전합니다. 다만 예상치 못한 고액 청구가 발생할 여지는 남습니다. 중단되어도 상관없는 실험적인 자동화라면, 굳이 활성화하지 않고 크레딧을 예산의 상한선으로 기능하게 하는 방법도 있습니다. 즉, '중단되었을 때 곤란한가'와 '예기치 못한 과금이 두려운가'를 저울질하여 결정하게 됩니다.

이와 함께 크레딧의 제약 사항도 파악해 두어야 합니다. 크레딧은 사용자별로 부여되며, 팀 단위로 풀 (Pool)을 만들거나 공유할 수 없습니다. 매달 리셋되며, 미사용분은 다음 달로 이월되지 않습니다. 팀 단위로 자동화를 돌리고 있는 경우, '누군가의 크레딧을 전원이 함께 사용한다'는 운영 방식은 성립하지 않는다는 점을 유념해야 합니다.

근본 대응: 인증 경로를 설계 판단으로서 다시 선택하기

응급 처치는 주어진 크레딧 범위 내에서 조절하는 이야기였습니다. 근본적인 재검토는 애초에 자동화를 어떤 인증 경로에 태울 것인가라는 지점부터 다시 생각하는 것입니다.

공식 측은 이 월간 크레딧을 '개별적인 실험과 자동화를 위한 규모'로 정의하고 있습니다. 뒤집어 말하면, 공유된 운영 환경의 자동화는 크레딧만으로는 감당할 수 없도록 상정되어 있다는 뜻입니다. 실제로 공식은 운영 환경의 자동화를 돌리는 팀에게 Claude Platform의 API 키 (API key)를 사용할 것을 안내하고 있습니다. API 키로 인증하는 이용은 이번 변경 대상에서 제외되며, 종량 과금이 기존과 동일하게 유지되고 월간 크레딧은 부여되지 않습니다.

여기서 핵심이 되는 것이 앞서 언급한 '자동화는 이제 덤이 아니다'라는 관점입니다. 자동화를 구축할 때, 구독 인증 (Subscription authentication)과 API 키 인증 (API key authentication) 중 어느 쪽을 선택하느냐가 비용 구조와 한도 도달 시의 동작을 좌우하는 설계 판단이 되었습니다.

가벼운 실험이나 개인의 보조적인 자동화라면 구독 인증의 크레딧 범위 내에서 해결됩니다. 월간 크레딧을 다 쓰면 멈추는 동작을, 그 이상의 과금이 발생하지 않는 예산 상한선으로 활용할 수 있기 때문입니다. 반면, 중단되면 업무에 지장을 주는 운영 환경의 자동화나 팀에서 공유하여 돌리는 워크플로우는 API 키 인증 쪽으로 맞추는 것이 다루기 쉬울 것입니다. 소비량이 그대로 과금에 반영되어 파악하기 쉽고, auto-reload나 사용량 알림을 통해 잔액을 관리할 수 있기 때문입니다. 둘 다 잔액이 떨어지면 멈춘다는 점은 같지만, 구독 인증은 플랜 금액에 묶인 정액제 형태의 범위이고, API 키는 직접 충전한 잔액이라는 차이가 있습니다. 운영 환경에서 안정적으로 돌리려면, 범위의 상한이 플랜 금액에 고정되지 않는 API 키가 운영의 자유도가 더 높을 것입니다.

예상되는 반론

지금까지의 정리와 관련하여 몇 가지 반론이 있을 수 있습니다. 이를 미리 제시하고 각각에 대해 답변하겠습니다.

반론 1: 전부 API 키로 몰아넣으면 되지 않나

그렇다면 전부 API 키로 통일하면 두 개의 지갑을 신경 쓸 필요가 없지 않느냐는 질문입니다.

일리가 있는 말입니다. API 키로 통일하면 대화와 자동화 모두 동일한 종량 과금으로 처리할 수 있어, 구독 크레딧 범위와 API 잔액을 따로 관리하는 번거로움이 사라집니다. 하지만 대화 이용의 경우, API 키로 몰아넣으면 손해를 보기 쉽습니다. 구독 모델은 사용 제한 범위 내라면 대화를 정액제로 무제한 사용할 수 있도록 설계되어 있기 때문입니다. 이를 API 키의 종량제로 옮기면, 기존에 월간 요금에 포함되었던 대화 한 번 한 번이 토큰 단위의 과금으로 변하게 됩니다. 대화는 구독의 정액제에 두고, 무거운 자동화만 API 키로 분리하는 것이 현실적인 타협점이 될 것입니다.

반론 2: 내 자동화는 가벼워서 범위 내에 들어온다

내 자동화는 가벼우니까 부여되는 크레딧 범위 내에서 해결되지 않겠느냐는 질문입니다.

대부분의 경우에는 그렇습니다. 가끔 스크립트를 실행하는 정도라면 부여되는 크레딧으로 충분합니다. 문제는 자신의 소비량을 파악하지 않은 채 "아마 충분할 것이다"라고 추측하고 있다는 점입니다. 에이전트 (Agent)를 상시 구동하거나, CI (지속적 통합)에서 빈번하게 호출하고 있다면 예상보다 빠르게 할당량을 다 써버릴 수 있습니다. 크레딧 범위 내에 들어온다는 판단 자체는 맞더라도, 그 근거를 한 번 확인해 두는 것이 안전합니다. 확인 절차를 통해 파악한 자동 실행 빈도를 시행 후의 청구 화면에서 실제 소비량과 대조해 보는 것이 좋습니다.

반론 3: 결국은 가격 인상

명목이 무엇이든, 결국은 가격 인상 아닌가요?

무거운 자동화를 정액제 범위 내에서 돌리던 사용자에게는 확실히 실질적인 부담 증가입니다. 저렴하게 이용하던 부분이 실제 비용에 가까워지기 때문입니다. 하지만 이는 불합리한 가격 인상이라기보다, 왜곡을 바로잡는 과정으로 보는 것이 더 정확할 것입니다. 지금까지는 정액제 구독 (Subscription)이 자동화 비용을 대신 부담해 주었으며, 헤비 유저일수록 더 큰 혜택을 받는 구조였습니다. 이번 분리를 통해 대화는 정액제, 자동화는 실비용이라는 본래 있어야 할 형태로 가까워졌다고 할 수 있습니다. 대화 중심의 사용자는 사용량이나 편의성에 변화가 없으며, 영향을 받는 것은 혜택이 컸던 계층에 한정됩니다. 일괄적인 가격 인상이 아니라, 보조금이 적용되었던 부분이 제거되었다고 파악하는 것이 정확합니다.

자동화 설계를 재검토할 기회

확인과 대응을 마쳤다면, 그 다음에 남는 것은 설계의 문제입니다. 이번 변경은 자동화 설계를 재검토할 좋은 계기가 됩니다.

지금까지도 운영 시스템에 포함되는 자동화는 API 키 (API Key)를, 개인 스크립트는 구독 인증 방식인 Claude Code를 사용하는 식으로 구분하여 사용해 왔습니다. 다만, 구독 인증으로 실행하는 한 그 선택이 비용으로 직결되지는 않았습니다. 정액제 할당량이 자동화 비용을 흡수하고 있었기 때문입니다. 6월 15일 이후부터는 경로의 선택이 곧바로 비용과 가용성 (Availability)으로 직결됩니다.

자체적으로 에이전트를 구축하여 운영하는 사람일수록 이 영향은 클 것입니다. 판단의 기준은 세 가지가 있습니다.

• 중단되었을 때 문제가 되는가
• 소비량을 예측할 수 있어야 하는가
• 팀 단위로 공유하며 운영하는가

이 세 가지 기준에 비추어 어떤 워크플로우 (Workflow)를 구독 인증 크레딧 범위에 남기고, 어떤 것을 API 키로 옮길지 분류하게 됩니다. 중단되어도 괜찮은 실험적인 작업은 크레딧 범위를 예산 상한선으로 사용하고, 중단되면 안 되는 운영 환경이나 공유 워크플로우는 API 키로 옮겨 소비량을 예측하기 쉽게 만듭니다. 이번 시행을 계기로 자신의 자동화 환경을 한 번 정리해 볼 가치가 있습니다.

결론적으로 말하자면, 자동화를 "정액제 안에서 막연하게 돌아가는 것"으로 취급할 수 있었던 시대가 여기서 끝난다는 뜻입니다. 이전에는 에이전트를 구동하더라도 비용이 정액제 안에 녹아 있어 보이지 않았습니다. 앞으로는 자동화에 항상 비용이 따라다닙니다. 구동할수록 비용이 발생하는 만큼, 그 자동화가 비용에 걸맞은 효과를 내고 있는지를 설계 단계부터 고민해야 합니다.

오늘 해야 할 응급 처치는 간단합니다. 자신이 대상인지 확인하고, 대상이라면 크레딧을 청구받는 방식과 중단 방법을 결정하는 것입니다. 그뿐입니다. 다만 그 이후에는 자동화의 비용과 효과를 어떻게 바라볼 것인가라는 숙제가 남습니다. 정액제 안에 숨겨져 있던 자동화 비용이 표면으로 드러난 것, 그것이 이번 변경의 진짜 본질이라고 생각합니다.

Discussion