클라우드 비용을 잡기 위한 첫 걸음
https://brunch.co.kr/magazine/cloud-finops
클라우드 비용은 어렵다.
클라우드 이전에 관리하던 방식은 단순했다. 비교적 단순했던 이유는 고정비용으로 처리가 가능했기 때문이다. 시스템을 구축하고 운영하기 위한 예산을 심의하고, 프로젝트를 실행하며 지출을 관리하면 된다. 소프트웨어, 하드웨어 자산이 구매되고, 고정 비용으로 지출이 발생되거나, 자산가치가 감소된다.
대부분의 회사에서 이견이 없이 관리될 수 있었다.
하지만, 클라우드와 SaaS (SW as a Service) 환경으로 이동 되면서, 고정비용으로 처리가 가능했던 인프라와 소프트웨어 비용이 시간당, 분당, 초당으로 변화되는 변동비용이 되어 버렸다.
동일한 금액, 동일한 로직으로 분배되어 있던 비용이 매달, 매일 변동되고 있는데 회계팀에서는 이 비용을 처리할 승인 근거, 지불 근거도 확신할 수 없다. IT팀과 머리를 맞대보고, 근거를 달라고 요청해 봐도 이전의 방식으로는 안된다는 것만 확인할 수 있을 뿐이다. 이대로는 놔둘 수는 없다.
오늘은 이런 상황에 처한 기업들이 가장 먼저해야 할 6가지를 설명해 보고자 한다.
1. 클라우드 비용 담당자 확보하기
2. 서비스 공급자가 제공하는 인보이스와 빌링 데이터 이해하기
3. 각각의 클라우드, SaaS 서비스를 통합하기
4. 단기 비즈니스 효과 측정을 위한 Unit Economy 확보하기
5. 예산과 비용 통제에 대한 거버넌스 규칙 만들기
6. 공급자의 할인 정책 이해하기
1. 클라우드 비용 담당자 확보하기
첫 걸음의 출발 지점은 담당자 확보하기가 되어야 한다. IT기획팀, Finance팀, 개발팀이 같이 모여야 한다. 개인적인 의견에서는 스크럼팀을 구성하여 클라우드 비용 뽀개기 같은 목적을 달성하기 위하여 몇 번의 스프린트를 거치면서 애자일하게 기업의 제도와 현황에 맞는 관리 방안을 확보하고, 향후 지속적으로 관리할 조직까지 만들어 가는 것이 가장 좋겠지만, 애자일 방식이나 문화가 아직 도입되지 않고 OKR 등의 목표 기반의 업무 실행이 낯설다고 하면, 전통적인 방식의 TF 팀이라도 만들어서 일정 기간이라도 체계를 잡고, 클라우드 비용 관리를 이해하는 사람을 육성 혹은 확보해야 한다. (내가 재직 중인 클라우드 비용관리 전문 인력의 도움을 받는 것도 좋은 방법이라고 생각한다.)
여하튼 비즈니스 증가에 따라 IT비용의 상당 부분이 클라우드와 SaaS 서비스로 이동되는데, 이에 대한 이해가 높은 사람을 확보하지 못하고 있다는 것은 IT 운영과 비즈니스 효율에 매우 크리티컬하다. 한명의 역량있는 전담자를 확보하고 있는 기업의 수도 많지 않고, 그나마도 담당자의 캐리어 성장이나 비용절감이나 정책도입 등에 대한 권한 임파워먼트도 경험이 없는 상황에서 여러 기업들에서 관련 업무의 경험자나 클라우드 전문가의 수요가 넘치기 때문에 리텐션이 매우 어려운 상황이다.
2. 서비스 공급자가 제공하는 인보이스와 빌링 데이터 이해하기
인보이스는 보통 몇 장으로 구성된 PDF 혹은 HTML 형태의 파일이 이메일로 날라온다. 회사가 가지고 있는 여러 계정을 통합해서 제공되기도 하고, 프로젝트 별로 지난 달의 사용 금액이 제공되기도 한다. 서비스 사용 비용, 크레딧 제공 금액, 할인 적용 금액, 서포트 플랜 금액, 기타 부가 서비스 비용이 제공된다. 이 내용을 가지고 비용 관리는 당연히 불가능하다. 어느 부서가 어느 프로젝트가 어떤 상품을 얼마나 사용했는지, 적절하게 사용했는지 무엇을 근거로 파악을 할 것 인가? 실제 클라우드 서비스를 공급하는 AWS, GCP, MS Azure 등의 클라우드 공급자는 매우 디테일한 미터링 근거 데이터를 당연히 제공한다.
경우에 따라 다르겠지만, 매우 불운하게도, 그 데이터의 세부 항목 라인 수가 수 십만, 수 백만 라인을 훌쩍 넘어가는 것이 문제다. 데이터는 있지만 이 데이터를 활용하기 전에 제대로 볼 수조차 없다. 우리 모두가 사랑하는 엑셀에서 로딩하는 라인 수는 엑셀 2003 까지의 버전의 경우 최대 65,536 라인을 입력할 수 있었으며, 아직까지 우리의 회계팀과 개발팀에서 가장 많이 사용되고 있는 2010, 2013, 2016 등의 이후 버전은 최대 1,048,576 라인을 올릴 수 있다. 물론, 사용하는 PC 의 메모리가 충분해야 이만큼의 데이터를 읽어서 합하고, 나누고, 매크로를 돌릴 수 있는 것이다. 현재 엑셀로 클라우드 비용 관리를 하고 있다는 것은 대부분 월 단위 혹은 주 단위 정도로 합계를 만든 비용을 임원 보고용 혹은 경비 지출용 서머리 리포트를 관리하고 있을 가능성이 크다. 우리가 비용을 모니터링하고 예측하고 이상비용을 찾는다는 목표를 위해 관리하고 가시화하고 인사이트를 도출한다는 것은 다양한 기준으로 월별 수 백만 라인의 상세한 데이터를 합치고, 분배하고, 분석해 주는 빌링 시스템이나 비용 관리 툴이 없이는 불가능하다.
3. 각각의 클라우드, SaaS 서비스를 통합하기
클라우드가 보편화 되면서 몇 년 간 계속 포함되는 트렌드 용어 중에 하나는 Multi Cloud, Hybrid Cloud 라는 단어이다. 다르게 표현하는 경우도 있겠지만, 대략적으로 Multi Cloud 는 AWS, GCP, Azure 와 같은 여러 Public Cloud Service Provider 가 제공하는 클라우드 서비스를 동시에 사용하는 것을 의미하고, Hybrid Cloud 는 좀 더 범위를 넓혀서 자체 데이터센터나 IDC 등에 기업 내부용으로 자체 투자하여 구축한 Private Cloud 와 AWS, GCP, Azure 와 같은 CSP 를 같이 사용하는 것을 의미한다.
목적인 비용 절감, 기술 보안, 확장성 등 여러 가지가 있지만, 문제는 위에서 언급한 수 백만 라인의 빌링 아이템의 소스가 여러 곳이 된다는 것이다. 당연히 데이터를 제공하는 주체에 따라서 데이터 형태로 구성도 다르고, 이를 통합하는 것이 엄청난 고난이 된다. AWS 에 근무하는 한 엔지니어가 Facebook 에 이런 글을 적은 적이 있다. "내가 매일 아침 What's New 를 읽어야 하는 회사에 다닐 줄은 몰랐다." 매일 경쟁적으로 새로운 서비스를 만들어 출시하고, AWS가 2015년 Summit 에서 하루 최고 1,079회 배포를 하고, 한 번 배포될 때 최대 30,000개의 호스트가 영향을 받는다고 발표했었다. 2015년 부터 2020년 지금까지 매일 AWS 엔지니어들이 What's New 를 읽고 있을테니, 그 변화의 빠르기와 폭은 상상이 안간다.
또 한가지 빠르게 증가하는 IT 비용 중 SaaS 서비스도 있다. 클라우드도 SaaS 가 있지만, 유명한 Workday, Salesforce.com 등 많은 SaaS 서비스들이 매일 비용이 새롭게 발생하고 비용 피크나 싱크가 생길 수 있는 변동비용 형태로 제공이 되고 있다. 다양한 클라우드 서비스와 SaaS 서비스의 비용 원천에 대한 이해와 통합이 없이는 비용 관리를 시작할 수가 없다.
4. 단기 비즈니스 효과 측정을 위한 Unit Economy 확보하기
Unit Economy 에 대해서는 좋은 글들이 많이 있기 때문에 별도의 언급은 하지 않는다. 간단하게 고객 1명을 얻기 위한 비용과 고객 1명이 나에게 주는 이익을 계산하는 정도로만 이해하고, 전통적인 매출, 비용, BEP의 손익분기 방식에서 많은 기업들, 특히 빠르게 비즈니스를 전개하고 성장하는 스타트업들이 Unit Economy 방식을 병행하거나 전환하더라는 정도로만 이해하고 넘어 가려고 한다. 사실 이러한 가치 산출 방식의 전환도 변동비용의 비중이 커지고 있는 클라우드와 SaaS 서비스의 영향이 크기 때문에 언급을 하는 것인데, CAC(Customer Acqusition Cost) 와 LTV (Life Time Value) 를 각 기업의 비즈니스 특성과 환경에 맞추어 계산을 할 때, 보통 Cost of Contract 는 CAC 에 포함되고, Cost of Service 는 LTV 계산에 반영이 된다. 단기 비즈니스 효과 측정이라는 말에서도 볼 수 있듯이 같은 IT 개발, 운영에 들어가는 비용이고 매일 발생하는 비용인데, 중복적으로 반영이 되거나 잘못된 항목으로 반영이 될 수 있다는 점만 명확하게 언급하고 넘어가려고 한다. 목적하는 바에 부합되게 Unit Economy 를 계산하려면, 클라우드 비용이 비즈니스 목적, 서비스, 발생시점에 따라 정확하게 배분되지 않으면, 엄청난 오차를 만들어 내는 경우가 많다.
5. 예산과 비용 통제에 대한 거버넌스 규칙 만들기
1~4 번 항목에 대하여 진행이 되고 있다면, 어느 정도 체계가 잡혀가고 있는 것이고, 이제는 상시적으로 운영할 수 있는 거버넌스 방법과 규정이 필요하다. 조직별, 프로젝트별로 할당된 예산 범위 내에서 운영이 되고 있는지 매일매일 체크가 되어야 한다. 당연히 사람의 눈으로 백만 라인의 데이터를 하나씩 체크할 수 없으나 방법을 찾아야 한다. 비용이 크게 발생하는 고사양의 VM 이나 Database, 빅데이터 서버 클러스터, GPU 머신 등의 개발 리소스는 생성을 제한할 수도 있고, 사용 시간을 최소화하기 위한 스케쥴을 강제화 할 수 도 있다. 계정이나 상품군 별로 예산을 책정하고 금액의 추이를 모니터링하고 미리 책정된 수준을 넘어갈 때 알럿을 발생시킬 수도 있다. 리소스를 생성할 수 있는 계정 권한을 제어하거나 한계를 부여하여 통제를 할 수도 있다. 그러기 위해서 가장 먼저 해야할 일은 각 리소스에 대한 태그 부여가 필요하고, 모든 리소스가 정해진 태깅 규칙이 반영되어 있는지 검사하는 것에서 부터 시작이 되어야 한다. 사실 수만개에 달하는 리소스에 일일히 태그를 붙이는 것이 쉽지 않은 것이지만, CMP 툴에서는 여러 계정의 리소스들에 편하게 태깅하고 언태깅하는 기능들과 자동으로 여러 정책들을 주기적으로 검사하고 리포팅 혹은 노티피케이션을 제공하는 기능들을 제공하고 있기 때문에 활용하는 것이 좋은 방법이다.
6. 공급자의 할인 정책 이해하기
마지막으로 이 방법만 우선 사용하고자 하는 기업들이 꽤 많이 있다. Reserved Instance 를 도입하면 On-Demand 대비 80% 까지 비용을 줄일 수 있다는 자극적인 마케팅 용어 때문인데, 사실 제약조건이 많이 있다. 기간 약정 혹은 사용량 약정 할인이라는 것이 결국 특정 조건이 일정한 기간동안 걸리는 것인데, 그 기간 동안 진짜 확실하게 그 사양의 머신이나 서비스를 사용한다는 확신을 갖기 어렵고, 정말 확신한다고 한다면, 약정이 아니라 아예 해당 사양의 서버를 직접 구매해서 소유해 버리는 것이 이익일 수도 있기 때문에 이런 저런 리스크와 조건을 따져 보면 쉽지 않은 결정이 된다. 원칙적으로 한번 체결한 약정할인 계약은 해지도 안된다고 되어 있기 때문에 기업 입장에서는 더 꼼꼼히 검토를 해야 할 것 같은 기분이 든다. 개발팀 입장에서도 해당 사양의 머신을 1년 혹은 3년간 고정적으로 사용할 것이냐고 재무팀이 물어온다면, 그렇습니다라고 대답하기가 참 어렵다. 사실 기업에 몸 담고 있는 입장에서 항상 도전적이고 긍정적인 목표를 달성하기 위해서 열심히 밤을 새워 매진하지만, 현실은 개발팀이 제공하는 IT 서비스가 커질 수도 있고, 없어질 수도 있으며, 심지어는 필요한 서버의 특성과 사양이 바뀌거나, 예를 들어 서비스가 딥러닝 기반으로 성장하여 GPU 머신으로 전환되어야 한다거나, 클라우드 사업자가 새로운 세대의 VM 을 출시하고 대대적인 프로모션을 실행한다던가 등의 상황이 벌어지고 있기 때문이다.
이러 저러한 이유들 때문에 결국 공급자와 Reserved Instance, Savings Plans, Enterprise Discount Plan 같은 약정할인 계약을 맺기 위해서는 사용량과 비용에 대한 시뮬레이션 혹은 모델링이 필요하게 되고, 이 또한 클라우드 서비스에 대한 전문적인 지식과 데이터 분석에 대한 전문적인 기술이 요구되어지는 상황이 된다. 물론 여러 CMP 시스템이나 MSP 서비스 제공자가 관련된 기능과 서비스를 제공하고 있기 때문에 이에 대한 도움을 받는 것이 의사결정이 많은 도움이 된다고 생각한다.
"Cloud 관리를 위한 FinOps" - 전체 내용 보기 (https://brunch.co.kr/@cebi750/17)
