AB180 개발팀의 AWS 비용 관리 여정: 청구서 확인부터 Fin Ops 문화까지
(engineering.ab180.co)Gemini로 요약했습니다.
--
수많은 데이터를 처리하는 마케팅 성과 측정 솔루션 '에어브릿지'를 운영하며, 체계적인 AWS 비용 관리(FinOps) 문화를 만들어왔습니다. 그 과정에서 얻은 경험과 노하우를 공유합니다.
AB180의 비용 관리 운영 방식:
저희는 비용을 '관리'하기 위해 다음과 같은 프로세스를 운영하고 있습니다.
- 구글 시트 기반의 대시보드: 데이터를 쉽게 가공하고 공유할 수 있는 구글 시트를 활용해 대시보드를 구축했습니다. 태그별 비용 현황은 물론, 비용에 직접적인 영향을 주는 데이터 수집량까지 함께 표시하여 변동 원인을 직관적으로 파악합니다. 또한, Savings Plan 커버리지 현황을 시각화하고 계약 변경 시 결과를 미리 시뮬레이션하여 합리적인 의사결정을 돕습니다.
- 주기적이고 자동화된 비용 점검: 2주에 한 번, 30분 내외의 짧은 미팅을 통해 비용 변동 사항을 점검합니다. 미팅 자료 생성, 슬랙 알림, 회의록 작성 등 반복적인 업무는 최대한 자동화하여 효율을 높였습니다. 비용 변동이 크면 담당자가 구글 시트 댓글로 원인을 분석하고 공유하여 투명성을 확보합니다.
- 개발 전 예상 비용 산출: 새로운 기능 개발이나 아키텍처 변경 시, '테크 스펙(Tech Spec)' 문서에 예상 비용을 산출하도록 의무화했습니다. 이를 통해 개발 단계부터 비용을 고려한 더 나은 기술적 의사결정을 내릴 수 있습니다.
비용 관리 시스템의 고도화 과정:
지금의 시스템은 하루아침에 만들어지지 않았습니다. 다음과 같은 단계를 거쳐 발전했습니다.
- Phase 0 (청구서 확인): 처음에는 매달 청구서를 확인하는 수준에 그쳤습니다.
- Phase 1 (최소한의 분류): Name 태그를 활용해 리소스를 최소한으로 분류하기 시작했습니다.
- Phase 2 (태그 전략 고도화): Team, Service 등 명확한 정책 기반의 태그 전략을 수립했습니다. 가이드 배포만으로는 부족하여, IAM 정책과 연동해 태그 설정을 강제하고, 태그가 없는 리소스는 슬랙 봇으로 자동 알림을 보내는 메커니즘을 구축했습니다. 그 결과, 태그 없는 리소스 비용을 전체의 1% 미만으로 관리하게 되었습니다.
지난 여정에서 얻은 5가지 교훈:
- 상황에 맞는 엔지니어링이 중요합니다. 비용 통제를 위한 완벽한 시스템을 추구하기보다, 회사 규모와 상황에 맞는 '적절한' 수준의 관리 체계를 점진적으로 구축하는 것이 현명합니다.
- 비용 '통제'와 '최적화'는 다른 일입니다. 비용의 예측 가능성을 높이는 '통제'와 비용 자체를 줄이는 '최적화'는 명확히 다릅니다. 상황의 우선순위에 따라 무엇에 집중할지 결정해야 합니다.
- 과감하게 자동화해야 합니다. 단순 반복 업무를 자동화하는 것을 넘어, 동료들이 직접 데이터를 조회하고 문제를 파악하는 '셀프 서브(Self-serve)' 환경을 구축하면 생산성이 극대화됩니다.
- '메커니즘'을 만들어야 합니다. "태그를 잘 달자"고 말하는 대신, 태그가 없으면 리소스 권한이 부여되지 않는 것처럼 정책을 따를 수밖에 없는 '장치(메커니즘)'를 설계하는 것이 효과적입니다.
- FinOps는 결국 '문화'입니다. 비용 관리가 특정 담당자의 일이 아닌, 제품을 만드는 모두의 책임이라는 인식이 자리 잡도록 꾸준히 노력하고 문화를 만들어나가는 것이 가장 중요합니다.
오호.. 가장 기본적인 Tag만이라도 붙여놓으면 어느정도 되겠군요.. :)
그런데 RI나 SP 같은 것을 이용해서 줄이는건 기본으로 들어가는 것일까요....
어느정도가 우리 인프라에서 사용할 사이즈인가는 고민이 많이 되는 부분이긴하네요...
본문에서도 언급되는 내용이긴한데, 저는 따로 SP 시뮬레이터를 만들어서 최근 n일간의 workload를 기반으로 여기서 얼만큼 SP를 더 사야 "기존 비용 + Covered 되서 줄어들 비용 + Recurring 되서 낭비될 비용"이 가장 적어질지 계산하고 그걸로 의사 결정 했었어요.
현직 AWS kor 재직자입니다.
입사 후 가장 중요하게 듣는 교육 중 하나가 고객이 클라우드 비용을 적게 쓸 수 있는 방법을 고민하라는 것이 있는데, 가장 효과적인 방법 중 하나로 RI & SP 를 안내합니다.
RI는 몰라도 SP의 경우 여러 워크로드에 적용될 수 있어서 고정으로 나가는 비용이 있다면 충분히 고려해볼만 합니다. 심지어 저희는 예상되는 최적화 시점까지 고려해서 구매하기도 했었습니다... ㅋㅋ 예를 들어 9개월 뒤에는 최적화 완료되서 서버비가 반으로 줄어들 것 같으면 그래도 1년치 사두는게 더 이득이니까 사는 식으로요.