클라우드 비용, 정말 숨만 쉬어도 나가는 걸까요?
안녕하세요, 15년 차 개발자이자 여러분의 멘토입니다. 오늘은 우리 지갑을 위협하는 아주 현실적인 이야기를 해보려고 합니다. 혹시 월말에 AWS 청구서를 받아보고 "어? 내가 뭘 썼길래?" 하며 등골이 서늘해진 경험, 한 번쯤 있으시죠? 저도 신입 시절, 테스트용으로 띄워둔 고사양 EC2 인스턴스를 주말 내내 켜두었다가 팀장님께 불려 갔던 아찔한 기억이 있습니다. 그때 커피 100잔 값은 날렸을 겁니다. ☕
클라우드의 가장 큰 장점은 '쓴 만큼 낸다(Pay-as-you-go)'는 것이지만, 반대로 말하면 '안 꺼도 낸다'는 무서운 진실이 숨어 있습니다. 특히 개발 서버나 스테이징 환경은 업무 시간(주 40~50시간) 외에는 사실상 좀비처럼 전기만 먹는 경우가 허다합니다. 일주일은 168시간입니다. 만약 평일 업무 시간에만 서버를 켠다면, 이론적으로 약 70% 이상의 비용을 절감할 수 있다는 계산이 나옵니다.
단순히 "서버 끄세요"라고 말하려는 게 아닙니다. 바쁜 개발자가 매일 아침저녁으로 콘솔에 들어가서 버튼을 누르는 건 불가능하죠. 우리는 '자동화'를 해야 합니다. 오늘은 AWS에서 미사용 인스턴스를 자동으로 스케줄링하여 비용을 획기적으로 줄이는 방법, 그 원리와 실전 노하우를 아주 깊이 있게 파헤쳐 보겠습니다.
💡 핵심 포인트: 개발/테스트 환경의 서버를 업무 시간에만 켜두는 '인스턴스 스케줄링'만 잘해도, 전체 EC2/RDS 비용의 60~70%를 절약할 수 있습니다. 이건 선택이 아니라 필수입니다.
왜 스케줄링이 비용 절감의 핵심일까요? (원리 이해)
많은 분들이 비용 절감이라고 하면 'Reserved Instance(RI)'나 'Savings Plan(SP)' 같은 약정 할인을 먼저 떠올립니다. 물론 훌륭한 방법입니다. 하지만 개발/스테이징 환경처럼 사용량이 들쭉날쭉하거나, 언제 사라질지 모르는 리소스에 1년, 3년 약정을 거는 건 위험 부담이 큽니다. 유연성이 떨어지니까요.
스케줄링은 'On-Demand(온디맨드)' 요금제의 특성을 역이용하는 전략입니다. AWS의 과금 체계는 초 단위(또는 시간 단위)입니다. 리소스가 'Running' 상태일 때만 과금되죠. 'Stopped' 상태에서는 EBS 볼륨(저장 공간) 비용만 나가고, 컴퓨팅 비용은 0원입니다. 이 원리를 이용해 비업무 시간에 컴퓨팅 비용을 '0'으로 만드는 것이죠.
📉 구체적인 절감 효과 분석
실제 데이터를 바탕으로 이야기해볼까요? m5.large 인스턴스(시간당 약 $0.1)를 서울 리전에서 한 달 동안 쓴다고 가정해봅시다. (가격은 변동될 수 있으니 비율로 보세요)
- 24시간 가동 시: 24시간 × 30일 = 720시간 과금 (약 $72)
- 업무 시간 스케줄링 (월-금, 09:00~19:00): 10시간 × 22일 = 220시간 과금 (약 $22)
보이시나요? 단순히 끄고 켜는 것만으로 비용이 약 70%나 줄어듭니다. 만약 인스턴스가 10대, 100대라면 그 차이는 어마어마하겠죠. 제가 컨설팅했던 A 스타트업의 경우, 개발 서버 50대를 스케줄링 적용한 첫 달에만 클라우드 비용을 400만 원 가까이 줄였습니다. 이 돈이면 팀 회식을 몇 번이나 할 수 있는지 아시죠? 🍖
실전 전략: 무엇을, 어떻게 제어할 것인가?
무턱대고 모든 서버를 끄면 안 됩니다. 새벽에 배치가 도는 서버도 있을 것이고, 글로벌 팀과 협업하느라 24시간 켜져야 하는 서버도 있습니다. 그래서 가장 먼저 해야 할 일은 '대상 식별'과 '태깅(Tagging)'입니다. 기술적인 구현보다 이 '정책 수립'이 훨씬 중요합니다. 제 경험상, 정책 없이 스크립트부터 돌렸다가 개발팀 전체가 "서버 왜 죽었어!" 하고 아우성치는 상황, 분명히 옵니다.
🏷️ 태그(Tag) 기반의 제어 전략
AWS 리소스에 태그를 붙이는 건 단순한 이름표 붙이기가 아닙니다. 이것은 자동화의 '트리거(Trigger)'이자 '안전장치'입니다. 저는 보통 다음과 같은 태그 전략을 추천합니다.
- Key: `Schedule` 또는 `AutoOnOff`
- Value: `OfficeHours`, `AlwaysOn`, `WeekendOff`
이렇게 태그를 달아두면, 스크립트나 자동화 도구가 이 태그를 스캔합니다. `Schedule=OfficeHours` 태그가 붙은 녀석들만 골라서 아침 9시에 켜고, 저녁 7시에 끄는 식이죠. 태그가 없거나 `AlwaysOn`인 리소스는 건드리지 않습니다. 이렇게 하면 실수로 프로덕션(운영) 서버를 끄는 대참사를 막을 수 있습니다.
구현 방법 비교: 어떤 도구를 써야 할까?
스케줄링을 구현하는 방법은 크게 3가지가 있습니다. 각각 장단점이 뚜렷하니 여러분 팀의 상황에 맞춰 골라야 합니다.
| 방법 |
장점 |
단점 |
추천 상황 |
| AWS Instance Scheduler (솔루션) |
기능 강력, DynamoDB로 일정 관리, 검증된 아키텍처 |
초기 설정 복잡, CloudFormation 이해 필요, 약간의 비용 발생 |
관리할 인스턴스가 많고 체계적인 관리가 필요한 중/대규모 팀 |
| Lambda + EventBridge (DIY) |
완전 커스터마이징 가능, 매우 저렴, 가벼움 |
코드를 직접 짜고 유지보수해야 함, 예외 처리 직접 구현 |
개발자 위주 조직, 단순한 On/Off 로직만 필요할 때 |
| SaaS 도구 (예: Skeddly) |
UI가 직관적, 코드 작성 불필요, 빠른 설정 |
유료(사용량 기반), 외부 서비스에 권한 부여 필요 |
인프라 엔지니어가 부족하거나 관리가 귀찮은 소규모 팀 |
⚠️ 트러블슈팅: 이것 때문에 실패합니다 (주의사항)
스케줄링을 처음 적용할 때 90%가 겪는 문제들이 있습니다. 미리 알고 피하세요.
1. Auto Scaling
댓글
댓글 쓰기