요약
사용량만큼 요금을 받는 서비스는 한도에 닿으면 멈추는 하드 예산 상한을 기본으로 켜 둬야 합니다.
개발자 사이먼 윌리슨이 자신의 블로그에서 한 주장입니다. 코딩 에이전트로 유료 API를 쓰는 앱을 배포하기가 쉬워졌습니다. 그만큼 밤사이 폭주한 서비스가 예상 못 한 요금을 쌓는 일도 늘어날 것이라고 봤습니다.
왜 중요한가
- 비용 사고를 개발자 개인의 주의력에 맡기지 말고 서비스 기본값으로 막자는 제안입니다.
- AWS(9월)와 Google Cloud(7월)가 잇달아 지출 한도 기능을 내놓아 업계도 같은 방향으로 움직이고 있습니다.
핵심 내용
- 한도 근처에서 경고 메일만 보내서는 부족하고, 실제로 서비스를 멈춰야 한다고 했습니다.
- 상한 해제는 초과 요금 책임에 동의하는 문구를 사용자가 직접 확인하고 고르게(옵트인) 하자고 했습니다.
- 오류가 나면 곤란하다는 반론에는 대부분 1만 달러가 넘는 깜짝 청구서보다 오류를 택할 것이라고 답했습니다.
- AWS의 새 기능은 한도에 닿으면 그달 동안 프로젝트를 일시 중지하는 방식입니다.
- 코딩 에이전트가 상한을 지원하는 서비스를 권하고, 초보 개발자에게 상한 없는 서비스를 경고해야 한다고 했습니다.
HN 반응
- 상한이 급성장 때 서비스를 끊어 오히려 손해라는 지원팀 출신의 경험담에, 알림과 상한을 둘 다 선택지로 주면 된다는 반론이 여럿 붙었습니다.
- 기능이 늦게 나온 이유로는 과금 집계가 실시간이 아니고 저장 데이터까지 멈출지 정하기 어렵다는 설명이 나왔습니다.
예전에 이름만 대면 알 만한 백엔드 서비스의 지원팀에서 일한 적이 있는데, 거기에는 하드 예산 한도가 있었습니다.
안타깝게도 그건 악몽이었습니다. 티켓이 산더미처럼 쌓였고 소송하겠다는 협박까지 있었습니다. 자연스러운 성장, 바이럴, 큰 행사, 한도가 있는 줄 아무도 몰랐던 경우 등등 때문에 하필 최악의 순간에 서비스가 칼같이 끊긴 고객들이었습니다. 그 급증으로 얻었을 리드와 매출을 전부 날린 것도 모자라, 갑자기 서비스를 못 쓰게 된 기존 사용자들까지 화나게 만든 겁니다.
일반적으로는 하드 한도보다 알림을 쓰는 편이 훨씬 낫습니다. 최악의 경우(해커가 자격 증명을 탈취해서 비트코인을 채굴하는 따위)에도 나머지 사업은 영향을 받지 않고, 청구 부서와는 비교적 느긋하게 협상할 수 있으니까요.
이건 사람이 서비스를 운영한다는 전제입니다. AI 에이전트가 프로덕션 인프라를 마음대로 만지게 두고 있다면 완전히 새로운 문제가 줄줄이 생깁니다.
위험 감수 성향이 높은 기업이나 기회주의적인 개인에게는 아마 그렇겠죠. 저는 그냥 하드 예산 한도를 달라고요. 어느 한쪽만 지원할 필요 없이 고객이 원하는 걸 고르게 하면 되잖아요.
알림을 원해요? 설정하세요.
하드 한도를 원해요? 그것도 설정하세요.
(설정만 쉽고 눈에 잘 띄게 만들어 주세요)
제가 보기엔 선택지를 주면 사람들이 한도를 걸어 두거든요. 그러다 상황이 바뀌어서 대규모로 키우고 싶어져도 설정을 안 건드립니다. 이건 문서화와 프로세스의 문제라고 생각해요.
천 년 전, CI/CD가 판을 치기 전에는 사람들이 런칭 행사, 그러니까 go-live 이벤트를 했습니다. 팀들이 꼼꼼한 체크리스트를 챙겼고, 출시 전에 점검 회의를 열어서 부하 테스트도 확인했죠.
그렇다고 기본값은 하드 한도 없음으로 두고, 원하는 사람만 직접 켜게 하는 서비스를 만들지 못할 이유는 없습니다. "하드 청구 한도를 켜면 사용량이 월 할당량을 넘을 때 서비스가 중단된다는 점을 이해합니다" 같은 문장을 토씨 하나 안 틀리고 직접 입력한 다음 확인을 눌러야 하는 UI를 넣을 수도 있고요. 서비스 계약서든 약관 문구든 필요한 만큼 얼마든지 감싸면 됩니다.
하다못해 켜기 전에 위험을 인지했다는 확인서를 DocuSign 같은 방식의 PDF로 보내 서명받게 해도 됩니다. 그래도 화난 사람들이 가라앉을까요? 아마 아니겠죠. 소송 위험은 줄어들까요? 충분히 그럴 수 있습니다.
네, 중요한 지적입니다. 다만 AI 때문에 사정이 달라졌죠. 소프트웨어는 전통적으로 마진이 아주 높아서, 제공업체가 1만 달러짜리 청구서쯤은 의미 있는 손실 없이 털어낼 수 있었습니다.
고객 입장에서는 큰 숫자가 무섭고 패닉이 오지만, 제공업체 입장에서는… 고객이 청구서를 안 내는 일은 흔하고, 쫓아다니는 비용이 더 들어서 청구액을 포기하는 일도 늘 있습니다. 고객이 "그 사용량은 실수였어요" 하면 관계를 지키려고 탕감해 주는 게 대개 이득이고요. 어차피 못 받았을 큰 청구서를 탕감해 주면 고객은 여러분을 대단히 너그러운 곳으로 기억하고, 나중에 돈을 쓸 여유가 생겼을 때 평생 충성합니다.
그런데 토큰은 실제로 나가는 비용이 훨씬, 훨씬 큽니다. 서비스가 토큰을 감싼 래퍼에 불과한데 고객이 1만 달러어치를 써서 오픈AI에 5천 달러를 냈다면, 탕감하기가 훨씬 어려워집니다.
Google Cloud는 마진이 높은 서비스에서도 미납 청구서를 실제로 끝까지 받아내는 몇 안 되는 곳입니다.
Google Cloud는 끼칠 수 있는 피해도 크고 결제 시스템도 형편없을 수 있어서 가장 무섭기도 해요.
얼마 전에 Gemini용 선불 API 크레딧을 잔뜩 충전했는데, 어째서인지 연결된 계정들에서 결제 관련 문제가 터지면서 (크레딧 때문에) 잔액이 마이너스라고 뜨고 서비스를 중단하겠다는 거예요. 설정을 몇 개 초기화해서 겨우 해결했는데, 주로 그쪽 채팅 AI와 제 AI를 같이 써서 풀었어요(그쪽 AI는 상태 정보는 맞게 알려주는데 결론은 틀리게 내리더라고요).
aistudio.google.com, 일반 콘솔, Google Workspace 비즈니스 계정까지 전부 뒤죽박죽이에요. 계정이라도 동결되면 정말 큰일이라서, 앞으로는 차라리 openrouter에 돈을 내고 크레딧을 쓰려고요.
저한테 구글은 절대 안 쓸 뿐 아니라 다른 사람한테도 쓰지 말라고 말리는 유일한 클라우드 플랫폼입니다.
이유는 단순해요. 개인 gmail 계정이 온갖 말도 안 되는 이유로 동결됐는데 호소할 길이 전혀 없었다는 괴담이 여기 너무 많이 올라왔거든요. 다른 대형 서비스는 어떻게든 사람과 연락이 닿는데, 구글이 얽힌 건 불가능하고, HN이나 "레거시 미디어"에서 크게 소란을 피워도 소용없는 경우가 많습니다.
데이터센터가 서비스 제공업체보다 "컴퓨팅 허브"에 가까워지면 그것도 달라질 겁니다. 청구액의 상당 부분이 전기 요금이 되면 컴퓨팅 센터는 협상할 마진이 거의 없습니다. 전력 회사는 고객의 실수 따위 신경 쓰지 않으니까요.
전력 회사는 실시간으로 투명하게 볼 수 있는 계량기를 제공합니다.
제 휴대폰 요금제는 하드 한도에 도달하면 속도를 많이 낮춥니다. 그래도 어느 정도 연결은 됩니다. 절대 일어나지 않는 일은 추가 요금을 내야 하는 겁니다. 내가 내야 할 비용에 하드 한도를 걸어 주지 못하는 회사와는 거래하지 않을 겁니다. 한도에 가까워졌을 때 알림을 주는 건 괜찮지만, 제가 그 알림에 반응하지 않았다면 끝도 없이 돈을 내느니 차라리 서비스가 멈추기를 바랍니다.
그건 소프트 한도 아닌가요? "추가 비용 0"이라는 관점에서는 하드 한도겠지만, "기능은 여전히 돌아가되 성능이 떨어진 상태"라는 관점에서는 소프트 한도 같은데요.
간접적으로는 하드 한도입니다. 낮아진 속도로 한도에 도달한 뒤 데이터를 정확히 얼마나 쓸 수 있는지 계산할 수 있으니까요. 그게 진짜 하드 한도죠.
AWS 같은 곳들은 하드든 소프트든 기본 제공되는 한도가 사실상 0입니다.
취미로 앱을 만드는 입장에서는 아예 못 쓰는 것들이 있어요. 예를 들어 Cloudflare Workers가 그렇습니다. 얼마 전에 앱 PoC를 만들었는데, 불확실성 때문에 결국 집에서 호스팅했어요.
한도 자체는 아주 넉넉했지만, 악의적인 누군가가 장악하면 어쩌나 하는 걱정에 단 1분도 쓰고 싶지 않았습니다.
구체적인 사정을 모르니 단정할 수는 없지만, 그 교훈이 최선의 해법은 아닐 수도 있다는 생각이 듭니다.
그런 상황에서는 전력망에서 하듯이 기저 부하(base load)와 첨두 부하(peak load) 인프라로 나누는 쪽이 더 나은 접근일 수 있습니다.
기저 부하는 월 얼마를 내고 온전히 내 것으로 쓰는 실제 물리 서버가 맡고, 첨두 부하는 오토스케일링되는 동적 자원이 맡는 식입니다.
둘 다 고정 예산으로 운영하면 예산이 바닥나더라도 서비스가 "완전히 멈추는" 게 아니라 "느려지는" 정도로 저하될 겁니다. 그 정도는 공지된 SLA상의 다운타임에 해당하지 않을 가능성이 높고요.
제 말은 클라우드와 온디맨드가 유용하긴 하지만, 많은 경우 하이브리드 방식이 더 합리적일 수 있다는 겁니다. 물론 상황에 따라 다르겠지만요. 그쪽 제품의 요구 사항이 무엇인지는 제가 모르니까요.
피크 규모에 따라서는 기저 부하 쪽에 과부하가 걸리면 그대로 멈춰 버릴 수도 있습니다. 과부하일 때는 복구하려면 부하 차단(loadshedding)을 해야 하는데, 이는 지금 제안하신 것과 정확히 반대입니다.
그건 구체적인 시나리오와 용도에 따라 많이 달라지겠죠.
어떤 용도를 염두에 두고 계신가요? 제가 아는 한 떠오르는 용도는 전부 그 모델로는 안 됩니다. 밤 수요와 낮 수요(특정 시간대 기준) 사이의 일주기 변동이 너무 크거든요.
이런 악의적인 논쟁에는 별로 관심이 없지만, 제가 그렇게 받아들였다는 점은 짚어 두고 싶습니다.
그게 어떤 문제를 일으키는지는 이해하지만, 그럼 알림도 소용없다는 얘기 아닌가요? 그 회사들도 곧 서비스가 끊긴다는 무시무시한 문구의 알림을 놓쳤거나 무시했을 테고, 청구액이 너무 높아지고 있다는 무시무시한 문구의 알림도 똑같이 놓치거나 무시했을 텐데요.
맞아요. 특히 열린 인터넷에서는 첫 알림부터 파산까지 몇 분밖에 안 걸릴 수도 있잖아요.
저는 알림이 일반적으로 "훨씬 낫다"고 생각하지 않습니다. 요즘 최종 사용자들은 서비스가 한동안 멈추는 데 꽤 익숙해요. 별일 아니죠. 하지만 인프라 사고는 잠깐의 장애로는 일어나지 않을 방식으로 회사를 죽일 수 있습니다.
그리고 이건 물론 AI로 막 굴리는 사람들만의 문제가 아닙니다. 사람도 이런 사고를 스스로 충분히 잘 냈어요. 분산 서버리스 시스템은 어렵습니다.
알림은 누군가가 매번, 예외 없이 대응할 때만 의미가 있습니다. 권한을 가진 사람이 모든 알림에 대응하고 그걸 업무로 삼고 있지 않다면 알림은 쓸모가 없습니다. 물론 대응에는 그 알림이 무슨 뜻인지 이해하는 것도 포함되고요.
하드 한도보다 알림이 "훨씬 낫다"고 말하는 사람은 '알림 피로(alert fatigue)'부터 구글에서 찾아봐야 합니다.
알림은 약해요. 무시하거나 놓쳐도 아무 일도 안 일어나고, 그냥 돈만 $$$$$$$$$$ 더 나갈 뿐이죠.
돈을 쓸어 담는 클라우드 업체한테야 좋겠지만, 인프라를 운영하는 방식으로는 형편없습니다.
하드 한도는 (애초에 비용을 통제하도록) 제대로 구현하게 만들고, (한도 여유분을 건강하게 유지하도록) 모니터링도 제대로 갖추게 만듭니다.
그러니까 쓰레기 코드를 바이브 코딩으로 찍어내서 Github CI/CD로 아무 생각 없이 devops 하는 건 안 된다는 얘기입니다. 인프라를 실제로 생각하고 따져 봐야 하죠.
둘 다 하면 안 되나요? 알림이 붙은 소프트 한도를 걸고, 안전장치로 그보다 높은 하드 한도를 두면 되잖아요.
고객이 왜 알림을 선호할 수 있는지에 대한 논거는 타당합니다만...
그건 고객이 선택할 일이어야 합니다.
하드 예산 한도만, 혹은 알림만 하나로 못 박아 강요하는 건 잘못된 설계 결정입니다.
결국은 돈을 못 내는 고객 때문에 서비스 제공업체가 보는 평균 손실이 얼마냐에 달려 있습니다. 초과분을 고객이 내지 않는다면 모든 제공업체가 손실을 막으려고 하드 한도로 옮겨 갈 거예요. 모든 업체가 그렇게 하면 고객에게 선택권은 별로 없겠죠. 신용 조회를 먼저 거쳐서 한도를 높여 받는 정도를 빼면요.
시시한 관찰일 수도 있지만, "AI 에이전트가 프로덕션 인프라를 마음대로 만진다(yolo)"라는 문장을 실제로 읽기 전까지는 에이전트가 사실상 항상 YOLO 중이라는 걸 체감하지 못했어요! 하긴 당연하죠. 그게 걔네 존재 이유니까요.
아! 실제 예산은 스칼라값이 아니라 함수였네요. 하류(downstream)에 달린 함수요!
궁금한데요. 경험 없는 개발자가 인프라 설정을 잘못했거나 해킹당해서 생긴 거액의 청구서를 청구 부서가 대손으로 처리해 줄 가능성은 얼마나 되나요?