유료 AI 구독도 하루아침에 잠긴다 — 클라우드 AI 가용성 리스크
새벽 3시에 마감 작업 중이었습니다. Claude API로 코드 리뷰 자동화 스크립트를 돌리고 있었는데, 갑자기 429 Too Many Requests 에러가 떴어요. 분당 요청 한도를 넘겼다는 거였죠. 유료 구독 중인데도요. 그날 저는 업무를 남의 계정 상태에 맡겨뒀다는 걸 뼈저리게 느꼈습니다. 제 생각엔, AI가 얼마나 똑똑한가만 따지고 "내 업무가 남의 시스템 가용성에 묶여 있다"는 구조 리스크를 안 따지는 게 더 큰 함정이에요. 능력보다 의존성 설계가 먼저입니다.
레이트리밋은 유료 구독 여부와 상관없이 걸립니다
클라우드 AI 서비스는 레이트리밋이라는 장치로 요청 속도를 제한해요. OpenAI 공식 문서를 보면 RPM(분당 요청 수), TPM(분당 토큰 수), RPD(일일 요청 수) 같은 단위로 한도가 걸립니다. 이 한도는 조직 레벨과 프로젝트 레벨에서 정해지는 거라, 개인이 유료 요금제를 쓴다고 해서 무제한이 되는 게 아니에요.
제가 관리하는 자동화 파이프라인은 하루 세 번 돌아가는데요, 한 번은 오전 6시에 429 에러를 받고 1시간 동안 멈췄습니다. 그날 우연히 다른 팀원이 같은 조직 계정으로 대량 테스트를 돌리고 있었던 거예요. 제 스크립트엔 문제가 없었지만, 조직 전체 한도가 먼저 차서 제 작업이 차단됐죠. OpenAI는 Tier 시스템으로 사용량에 따라 한도를 올려주긴 하지만, Tier 5라 해도 월 $200,000 한도가 있습니다. 그 안에선 여전히 분당·일일 제한이 살아 있어요.
커뮤니티에선 ChatGPT Pro 월 $200 구독 사용자가 채팅 몇 개 삭제했더니 60분간 잠겼다는 보고도 있었습니다. 정확한 원인은 확인 못 했지만, 유료 구독이 모든 제한을 없애주는 건 아니라는 방증이죠.
유료 구독은 한도를 늘려줄 뿐, 의존성을 없애주진 않습니다
Tier가 올라가면 한도가 늘긴 하지만, 무제한이 되는 건 아니거든요. Tier 1은 월 $100, Tier 5는 월 $200,000까지인데, 그 안에서도 분당 토큰 제한·일일 요청 제한이 각각 따로 걸려요. 제가 쓰는 GPT-4 모델은 분당 150,000 토큰 한도였는데, 긴 문서 10개를 한꺼번에 넣으면 금방 차더라고요.
조직 레벨 제한은 제가 통제할 수 없습니다. 같은 조직에 속한 다른 사람이 갑자기 큰 작업을 돌리면, 제 스크립트가 먼저 막히는 거예요. OpenAI 문서에도 "조직 레벨 한도는 프로젝트 간 공유된다"고 명시돼 있어요. 유료 요금제는 한도를 늘려줄 뿐, 의존성 구조 자체를 없애주진 않습니다.
AI를 버리지 말고 exit-ability를 설계하세요
제 주장은 러다이트가 아니라 exit-ability 설계예요. 업무가 특정 벤더 하나에만 묶여 있으면, 그 벤더의 장애·정책 변경·계정 문제가 곧바로 내 업무 중단으로 이어지잖아요. 그걸 줄이는 방법은 세 가지입니다.
첫째, 중요한 대화와 산출물은 로컬에 사본을 남기세요. ChatGPT Temporary Chat은 30일 후 자동 삭제되고, 계정 잠금이나 실수 삭제 시 복구 방법이 없어요. 저는 중요한 프롬프트와 응답을 .txt 파일로 저장합니다. 3개월 전 대화를 다시 꺼낼 일이 생길 때마다 그게 살려줬어요.
둘째, 벤더 교체가 가능한 인터페이스를 쓰세요. 저희 파이프라인은 어댑터 레이어를 하나 뒀습니다. 설정 파일에서 provider: "openai" 를 provider: "anthropic" 으로 바꾸면 Claude로 전환돼요. 실제로 OpenAI가 429를 연속으로 뱉을 때, Claude로 임시 전환해서 작업을 이어간 적이 있습니다.
셋째, 오프라인 폴백을 준비하세요. 저희는 코드 리뷰 자동화가 실패하면 체크리스트 파일을 자동 생성해서 사람이 수동으로 체크할 수 있게 했어요. AI가 멈춰도 업무는 멈추지 않는 구조죠.
중단 비용을 따지면 개인도 exit-ability가 필요합니다
작업이 중단되는 순간의 비용을 따져보세요. 마감 2시간 전에 AI가 막히면 어떻게 되나요? 제 경우엔 새벽 마감 작업이 1시간 멈췄을 때, 그 시간을 메우려고 다음 날 일정을 3시간 미뤘습니다. 로컬 사본 하나 안 남겨뒀다가 대화 기록이 날아가면, 그걸 재구성하는 데 또 시간이 들어요.
exit-ability 설계가 거창한 건 아니에요. 중요한 대화 .txt 로 저장하는 데 10초, 어댑터 레이어 만드는 데 30분이면 충분합니다. 벤더 교체 시뮬레이션도 한 번만 해보면 돼요. 실제로 갈아타는 게 아니라, 갈아탈 수 있다는 걸 확인하는 게 목적이거든요. 저는 3개월마다 한 번씩 OpenAI와 Claude 사이를 왔다갔다 해봅니다. 그러면 어느 쪽이 막혀도 당황하지 않아요.
구체적인 리스크 대응 — 로컬 백업·중립 프롬프트·한도 모니터링
세 가지를 추천합니다. 첫째, 로컬 백업 루틴을 만드세요. ChatGPT나 Claude 대화 중 중요한 건 매주 금요일에 한 번씩 내보내기하는 거예요. 자동화할 수도 있고, 수동으로 해도 5분이면 됩니다.
둘째, 벤더 중립적 프롬프트 템플릿을 쓰세요. 특정 모델에만 동작하는 프롬프트는 그 모델이 막히면 쓸모없어집니다. 저는 프롬프트 앞부분에 모델 공통 컨텍스트를 두고, 뒷부분에만 모델별 최적화를 넣어요. 그러면 80%는 어디서나 돌아가요.
셋째, 한도 모니터링을 켜세요. OpenAI API는 응답 헤더에 x-ratelimit-remaining-requests 같은 필드를 넣어줍니다. 이걸 로그로 남겨두면, 한도가 얼마나 남았는지 실시간으로 볼 수 있어요. 저는 남은 요청이 10% 밑으로 떨어지면 Slack 알림이 오도록 해뒀습니다.
의존성을 설계하지 않으면 리스크가 설계합니다
ChatGPT Temporary Chat은 30일 후 자동 삭제됩니다. 학습 옵트아웃을 켜도 마찬가지예요. OpenAI 데이터 관리 FAQ에 명시돼 있죠. 계정이 잠기거나 정책이 바뀌면, 그 기록은 영영 복구할 수 없어요. 여러분의 AI 의존 업무는 내일 계정이 잠기면 어떻게 되나요?
능력 비교만 하지 말고, 의존성 구조를 먼저 점검해보세요. 중요한 대화 하나만 로컬에 저장하는 것부터 시작하면 됩니다. 벤더 교체 시뮬레이션도 한 번 해보시고요. AI가 똑똑한 건 맞지만, 그 똑똑함이 남의 계정 상태에 묶여 있다는 걸 잊지 마세요. 저는 그걸 새벽 3시에 배웠습니다.