TL;DR — 혼자 사업을 꾸리며 청구서를 들여다봤더니, 요금이 매겨지는 단위와 실제로 일이 처리된 단위가 계속 어긋나 있었습니다. 비용의 대부분은 '일'이 아니라 '틈'에서 나왔어요. 그래서 요즘은 코드를 최적화하기 전에, 청구 단위와 작업 단위 사이의 간격부터 먼저 봅니다.

작은 AI 사업을 혼자 운영합니다. 어느 날 클라우드 청구서를 제대로 뜯어볼 일이 있었어요. 금액 자체는 감당 못 할 수준이 아니었는데, 이상한 게 하나 있었습니다.

실제로 한 일은 얼마 안 되는데, 청구된 양은 그것보다 한참 컸어요.

처음엔 "일이 많았나 보다" 하고 넘기려다가, 항목을 하나씩 분해해봤습니다. 그랬더니 공통된 모양이 보였어요.

요금이 붙는 단위와, 일이 처리되는 단위가 다르다

정리하면 이렇습니다. 클라우드에서 돈은 대체로 **"네가 얼마나 일했는가"가 아니라 "네가 자원을 얼마나 점유했는가"**로 매겨집니다. 이 둘은 같아 보이지만, 실제로는 계속 어긋나요. 제가 겪은 어긋남을 몇 가지 유형으로 나눠보면요.

① 올림 과금 — 24초 작업에 1분이 매겨진다.
짧은 자동화 작업이 하나 있었습니다. 실제 실행 시간은 20초대였어요. 그런데 요금은 '분 단위 올림'이었습니다. 24초든 59초든 1분으로 계산되죠. 하루에 이 작업이 수십 번 돌면, 실제 연산 시간의 몇 배가 청구됩니다. 작업을 아무리 빠르게 만들어도, 최소 과금 단위 아래로는 못 내려가요.

② 예열 비용 — 0.4초를 쓰려고 90초를 데워둔다.
무거운 모델을 쓰는 구간이 있었습니다. 실제 추론은 1초도 안 걸려요. 그런데 그 1초를 빠르게 처리하려면 미리 자원을 '데워' 둬야 하고, 한 번 데우면 일정 시간 동안 켜진 채로 대기합니다. 그 대기 시간이 실제 일한 시간보다 훨씬 길었어요. 요금은 데운 시간 전체에 붙습니다. 정작 '일'이 차지하는 비중은 1%도 안 됐어요.

③ 상시 대기 — 하루 한 번 오는 요청 때문에 24시간 켜둔다.
빠른 응답을 위해 항상 켜두는 자원이 있습니다. 그런데 실제 요청은 뜸했어요. 켜두는 이유는 "요청이 왔을 때 느리면 안 되니까"인데, 요청이 하루에 몇 번뿐이라면 나머지 시간은 아무 일도 안 하면서 요금만 발생시키고 있는 겁니다.

④ 잊힌 점유 — 아무 일도 안 하는데 계속 돌아간다.
가장 뼈아팠던 유형이에요. 잠깐 테스트하려고 켜둔 게, 끄는 걸 깜빡해서 오래 방치돼 있었습니다. 요청은 0건. 처리한 일도 0건. 그런데 점유는 계속되고 있었어요. '일한 만큼'이 0인데 요금은 계속 나오는 극단적인 경우죠.

공통점 — 비용은 '일'이 아니라 '틈'에 있었다

네 가지를 늘어놓고 보니 공통점이 뚜렷했습니다.

제가 그동안 비용을 줄이려고 하면 본능적으로 작업 자체를 최적화하려 했어요. 코드를 더 빠르게, 연산을 더 효율적으로. 그런데 위의 어느 경우도, 작업을 빠르게 만드는 걸로는 해결이 안 됐습니다.

  • 올림 과금은 작업을 24초에서 10초로 줄여도 여전히 1분으로 청구돼요.
  • 예열 비용은 추론을 두 배 빠르게 해도 대기 시간이 그대로면 그대로입니다.
  • 상시 대기와 잊힌 점유는 애초에 '일'이 거의 없거나 0이에요. 최적화할 작업 자체가 없죠.

비용은 일이 처리되는 곳이 아니라, 일과 일 사이의 '틈'에서 나오고 있었습니다. 대기하는 시간, 올림으로 버려지는 시간, 켜두고 안 쓰는 시간. 청구서의 진짜 주인공은 그 틈이었어요.

그래서 기준이 하나 바뀌었습니다

거창한 절감 전략은 없어요. 대신 청구서를 볼 때 던지는 질문이 바뀌었습니다.

예전엔 **"이 작업을 어떻게 더 빠르게 만들지?"**를 먼저 물었어요. 지금은 **"내가 요금 내는 단위와, 실제로 일이 처리되는 단위가 얼마나 벌어져 있지?"**를 먼저 묻습니다.

이 질문을 항목마다 던지면 대응이 자연스럽게 갈려요.

  • 틈이 크고 일이 뜸하면 → 상시 켜둘 이유가 있는지부터 다시 봅니다. 조금 느려도 되는 구간이면, 필요할 때만 켜지게 두는 편이 대체로 쌉니다.
  • 올림 단위에 걸리면 → 잔 작업을 여러 번 돌리는 대신 묶어서 한 번에 처리합니다. 최소 과금 단위를 덜 건드리게요.
  • 예열이 비싸면 → 그 예열이 정말 매번 필요한지, 아니면 '느려도 괜찮은' 경로로 흘려보낼 수 있는지 나눕니다.
  • 잊힌 점유는 → 이건 최적화가 아니라 점검의 문제예요. 켤 때 '끌 조건'을 같이 정해두지 않으면, 사람의 기억에 의존하는 순간 언젠가 방치됩니다. 켜는 규칙만 있고 끄는 규칙이 없는 게 진짜 원인이더라고요.

혼자 하는 사업이라 더 그런 것 같아요

규모가 큰 회사면 이런 틈은 누군가 전담해서 봅니다. 그런데 혼자 하면, 청구서를 읽는 사람도 나 하나예요. 그래서 "왜 이렇게 나왔지?"를 넘겨짚고 지나가기 쉽습니다. 금액이 아직 작을 때는 특히요.

그런데 이 틈들은 트래픽이 늘면 같이 커지는 성질이 있어요. 지금 작다고 두면, 규모가 커졌을 때 가장 먼저 새는 곳이 됩니다. 그래서 금액이 작을 때 구조를 한 번 봐두는 게, 나중에 큰 수술을 피하는 길이더라고요.

짧게 요약하면 이래요. 클라우드에서 요금은 일한 만큼이 아니라 점유한 만큼 붙습니다. 그러니 비용을 줄이고 싶으면, 일을 더 빠르게 만들기 전에 — 내가 무엇에 요금을 내고 있고, 그중 실제로 일이 처리된 몫이 얼마인지, 그 간격부터 재보세요.

혼자 작은 사업을 꾸리며, AI와 함께 일하고 그 과정을 기록합니다. 오늘의 질문 하나 — 여러분의 청구서에서 '일한 만큼'과 '점유한 만큼'은 얼마나 벌어져 있나요?