$38,000의 AWS Bedrock 청구서가 드러낸 AI 인프라 안전의 치명적 결함

대규모 언어 모델(LLM)과 AI 에이전트의 급격한 도입은 개발 워크플로우에 전례 없는 강력함을 가져다주지만, 동시에 잠재적으로 막대한 비용을 초래할 수 있는 새로운 실패 모드를 도입합니다. 최근 한 개발자는 거의 $38,000에 달하는 AWS Bedrock 청구서로부터 얻은 뼈아픈 교훈을 공유하며, 현재 사용량 기반 AI 인프라가 작동하는 방식의 치명적인 취약점을 드러냈습니다. 즉, 단순한 프롬프트 캐싱 설정 오류가 적절한 하드 세이프티 레일(hard safety rails) 없이 천문학적인 비용으로 이어질 수 있다는 점입니다.

이 사건은 AI 서비스를 활용하는 모든 이들, 특히 자동화된 에이전트 워크플로우를 사용하는 이들에게 중요한 경종을 울립니다. 플랫폼 수준의 보호 장치가 실제 상황과 일치하지 않을 때 발생하는 내재적 위험을 노출하며, 개발자와 클라우드 제공업체 모두가 AI 소비를 위한 금융 가드레일을 어떻게 구현할 것인지 재고해야 할 필요성을 강조합니다.

사건의 개요: 캐싱 실패로 인한 $38,000의 교훈

저자인 Zephyr0x는 로컬 코딩 에이전트(Droid)가 OpenAI-compatible API와 상호작용하고, LiteLLM을 통해 AWS Bedrock으로 라우팅되며, 최종적으로 Claude Opus 4.6을 사용하는 워크플로우를 상세히 설명했습니다. Claude와 Bedrock 모두 프롬프트 캐싱을 지원하므로, 프롬프트 캐싱이 토큰 사용량을 효율적으로 관리할 것이라는 기대가 있었습니다. 그러나 결과로 나온 청구서는 전혀 다른 양상을 보여주었으며, AWS 크레딧 적용 후에도 약 $29,875.19의 순 비용이 발생했습니다.

문제의 핵심은 출력 생성(output generation)이 아니라, 반복되는 캐싱되지 않은 입력(uncached input)이었습니다. 내역은 다음과 같습니다:

• 캐싱되지 않은 입력 토큰: 약 64.7억 토큰, 비용 약 ~$35,600
• 캐시 읽기 입력 토큰: 약 16.7억 토큰, 비용 약 ~$918
• 캐시 쓰기 입력 토큰: 약 1억 100만 토큰, 비용 약 ~$698
• 출력 토큰: 약 2,500만 토큰, 비용 약 ~$698

이는 일부 캐싱 활동이 발생했음에도 불구하고, 고빈도 에이전트 워크플로우에는 턱없이 부족했음을 명확히 보여줍니다. 비용의 대부분은 에이전트가 저장소 상태, 도구 스키마, 지침, 히스토리, 파일 내용 등 방대한 컨텍스트를 캐싱되지 않은 입력으로 반복해서 보냈기 때문에 발생했습니다.

안전의 환상: 소프트 신호 vs 하드 레일

저자가 강조한 가장 좌절스러운 측면 중 하나는 안전 메커니즘처럼 보이는 것들의 기만적인 성격입니다. 게시물은 이를 명확하게 설명합니다:

“프롬프트 캐싱이 지원됩니다”는 “당신의 실제 에이전트 스택이 프롬프트 캐싱을 올바르게 사용하고 있습니다”와 같은 뜻이 아닙니다. “예산 경고가 설정되었습니다”는 “지출이 중단됩니다”와 같은 뜻이 아닙니다. “크레딧이 적용됩니다”는 “당신의 잘못된 비용 구조를 조기에 발견할 수 있다”는 뜻이 아닙니다.

이것들은 LLM 에이전트에게는 단순히 부적절한 "적절한 안전 경계처럼 위장한 소프트 신호"로 설명됩니다. 자율 코딩 에이전트는 개발자가 잠든 동안에도 지속적으로 실행되며 방대한 컨텍스트를 축적하고 상당한 비용을 발생시킬 수 있습니다. 캐싱이 잘못 설정되었거나 부분적으로만 효과적일 때, 실패 모드는 단순한 비효율성이 아니라 걷잡을 수 없는 클라우드 청구서로 이어집니다.

클라우드 제공업체는 예상치 못한 비용 문제에들을 다뤄온 오랜 역사가 있지만, 현재의 AI 인프라 상태는 수십 년간의 교훈을를 통해 배운 것을 무가시화하는 듯합니다. 저자는 다음과 같이 지적합니다. "클라우드 제공업체는 '돈이 다 떨어진 후에 이메일을 보내주겠다'는 방식이 안전 메커니즘이 아니라는 것을 배우는 데 수십 년이 걸렸습니다."

하드 리미트(Hard Limits)의 절실한 필요성

이 사건은 현재 AI 서비스 제공 방식에서 근본적으로 누락락된 요소인 API 또는 플랫폼 수준에서의 하드웨어적이고 설정 가능한 지출 제한(hard, configurable spending limits)을 강조합니다. 저자는 왜 이러한 기본적인 가드레일이 없는지에 대해 다음과 같은 중요한 질문을을 것입니다:

• 왜 IAM principal은 월 최대 지출액을, 예를 들어 $200/month와 같이 제한할 수 없습니까?
• 왜 특정 모델의 일일 호출 횟수를 N회로 제한할 수 없습니까?
• 왜 워크플로우가 시간당 N개 이상의 캐싱되지 않은 입력 토큰을 보내는 것을 제한할 수 없습니까?
• 왜 미리 정의된 예산이 초과되었을 때 요청 처리를 중단하는 메커니즘이 없습니까?

이러한 하드 리미트가 없다면, AI 에이전트의 기본 운영 모드는 "터무니없이 위험한" 상태가 됩니다. 저자는 가드레일을 구현하지 않은 개인적인 책임을 인정하면서도, 플랫폼의 설계가 "매우 정상적인 통합 과정의 실수가 실사 차량 크기의 인보이스로 변할 수 있게" 만든다는 점을 강조합니다.

AI 에이전트를 위한 신뢰할 수 있는 가드레일 구축하기

이 경험은 커뮤니티가 강력한 솔루션을 개발하고 공유할 것을 촉구하는 긴급한 행동 촉구입니다. 저자는 특히 다음과 같은 기존의 신뢰할 수 있는 가드레일에 대해 질문합니다:

• IAM deny rules
• API gateways with custom logic
• Token-budget proxies
• Per-workflow kill switches

AI 에이전트가 일상적인 개발 및 프로덕션 환경에 더 깊이 통합될수록, 이러한 선제적이고 예방적인 조치의 필요성은 무엇보다 중요해집니다. 사후 경보 알림이나 올바른 프롬프트 캐싱의 가정을 가정하는 것은 더 이상 유효하지 않습니다.

핵심 요약

$38,000의 AWS Bedrock 청구서는 사용량 기반 AI 서비스를 사용하는 모든 이들에게 다음과 같은 몇 가지 중요한 교훈훈을 상래기합니다:

• 프롬프트 캐싱은 체크박스 항목이 아닙니다. 특정 에이전트 스택 내에서 효과적으로 작동하는지 확인하기 위해 엄격격한 검증과 모니터링이 필요합니다.
• 예산 경고는 킬 스위치(kill switch)가 아닙니다. 그것은 사후 통보를 제공할 뿐, 예방을 제공하지 못합니다.
• 크레딧은 보호 장치가 아닙니다. 도움이 될 수는 있지만, 잘못된 비용 구조를 효율성을 가효리하게 가려버릴 수 있습니다.
• 하드 지출 제한(Hard spend limits)은 필수적입니다. AI 에이전트가 일반적인 인프라로 안전하게 통합될 수 있도록 하기 위해서는, 사용량 기반 AI 백엔드가 강력하고 설정 가능한 하드 리미트가 필요합니다. 현재의 기본 설정은 너무 위험합니다.