우리가 생각하는 FinOps
OpsNow는 FinOps와 관련된 제품과 서비스를 제공하는 회사이다. 하지만 우리가 과연 FinOps라는 것을 얼마나 정확히 알고 이 서비스를 제공하고 있는지부터 생각해 볼 필요가 있어서 내 경험을 바탕으로 이 글을 쓴다.
흔히 FinOps는 "반드시 필요하다", "대세다", "없어서는 안된다" 라고 말한다. 이러한 이야기들이 회사 내부에서 나오고 있지만, “정말 FinOps가 반드시 필요한지” 의문에서부터 시작하는 것이 맞지 않을까 싶다. “OpsNow FinOps을 도입해야만 클라우드 비용을 줄일수 있나?” OpsNow 구성원 나도 이런 생각을 하는데 다른 사람들은 더 의문이 들 것 같다. 먼저 위 질문에 대한 나의 대답은 “아니오” 이다. 그렇지만 FinOps는 반드시 필요한 것이라는 생각이다. 내 대답이 정답이 아닐 수 있고, 경험이 완전한 해답이라고 할 수는 없지만, 경험을 기반으로 몇 가지 이야기를 하고 개인적인 생각에 대한 흐름을 정리하고자 한다.
클라우드로의 첫 발: 서버 수를 늘리며 문제를 해결하는 유토피아 경험
나는 2012년부터 한국에서 누구나 알 만한 큰 회사의 클라우드팀 개발과 운영 리드를 맡았다. 이 클라우드팀은 회사의 미래 성장 동력을 위하여 만들어 진 것이었는데, 클라우드 세계에 대한 나의 첫 인상은 클라우드는 유토피아라는 것이었다.
클라우드팀 개발 운영 리드 이전의 나는 커널 시스템 개발 엔지니어로서 매일 매일 메모리 1byte와의 전쟁, 성능 1s를 개선 하기 위해 아무도 알아주지 않는 어둠의 개발 세계에서 갇혀 지냈다. 그러나 클라우드 세계로 와보니 메모리가 문제가 생기면 그 근본을 해결 하는게 아니라 서버 수를 늘리고, 성능을 문제가 생기면, 좋은 사양으로 올리면 되는, 그런 신세계에 입문하게 되었다. 이러한 신세계의 기쁨은 어둠의 개발 세계에서 일해 본 사람들이 아니고서야 이해하기 힘들거다.
클라우드팀의 개발과 운영은 처음에는 Cloud의 C도 모르는 나를 포함하여, 외부에서 클라우드를 경험하고 온 새로운 멤버들과 함께 시작되었고, 우리는 개인, 조직, 회사가 함께 성숙해지는 과정을 겪었다. 여러 비용효율화 TF(Task Force)를 운영하고, 생산성 향상을 위해서 인하우스 솔루션을 도입하며 결국 놀라운 금액을 절감한 TF의 실질적 행동대장이 되었던 기억이 난다. 이 과정에서 내가 느낀 점을 바탕으로, 우리가 과거에 어떻게 비용을 줄이고 업무를 진행했는지, 그리고 그것이 어떻게 클라우드 외 다른 사람들과의 효율성과 연계되었는지, 이 모든 것이 현재 'FinOps'라고 불리는 개념과 어떻게 연결되는지 살펴보겠다.
2012년-13년 클라우드 서비스 확장의 황금기
2012-13년 당시만 해도 FinOps라는 개념 자체가 없었기 때문에, 우리는 클라우드로 이전하면서 상당한 비용을 지출하게 하는 시발점을 맞이하게 되었다. 그때만 하더라도 클라우드의 비용이 매우 저렴한 것으로 생각했다. 여러 서버 위에서 자체적으로 개발한 모듈을 활용하고, 자원 관리 및 기술 집약을 통해 대규모 인프라를 운영하는 과정에서 시간당 데이터 트랜잭션은 어마어마했고, 다뤄야 할 데이터도 수페타 데이터 환경에서 상상을 초월하는 수준이어서 매우 큰 비용을 사용하는 세상이었고, 이게 당연하다는 착각속에 있었다. 아마도 2015년까지는 이러한 방식으로 비용을 사용했다고 기억한다.
하지만 정말 클라우드에 대한 이해 부족 때문에 그렇게 많은 비용을 사용한 것이었을까? 사실 수십억 명의 사용자를 대상으로 이미지와 파일 전송을 관리하고, 개발과 운영을 병행한다는 건 클라우드와 대용량 처리에 대한 기술적 노하우 없이는 쉽지 않은 일이었다.
당시에는 급성장하는 서비스들이 하나둘씩 클라우드로 이전하던 시기였고, 서비스의 안정성과 성능을 높이기 위한 다양한 시도와 기술 개발이 활발히 이루어지고 있었다. 돈보다 ‘확장성’이 더 중요했던 시기였고, 무엇이 맞는지도 모르고 그냥 ‘지르고 보는’ 황금기였다고 생각한다.
이게 가능했던 건, 다들 잘 몰랐기 때문이었다. 서로 잘 몰랐다는 건 곧, 비용을 집행하는 부서나 그걸 바라보는 부서 모두 클라우드나 인프라에 대한 이해도가 낮았다는 뜻이다. 바꿔 말하면, 경영진이나 재무팀 등을 설득하기 쉬운 시절이기도 했다.
예를 들어 몇 가지를 떠올려보면, 당시엔 MSA(마이크로서비스 아키텍처)라는 구조가 뭔지도 몰랐고, 문제가 생기면 그냥 서버 증설하고 사양만 늘리면 된다고 생각했다. 왜 DB가 중요한 지도 잘 몰랐다. “이슈는 이슈로 덮는다”는 식의 시대였다.
이 시절 여러 경험을 했는데, 예를 들어 대용량 데이터 트래픽을 핸들링하기 위한 기술적 방법론, IO 처리에 대한 이해, “데이터는 그냥 쿼리로 뽑아오면 되는 거 아냐?” 같은 초보적인 생각들, 대용량 트래픽으로 문제가 발생했을 때 개발적으로만 해결하면 된다고 믿고 운영을 무시했던 태도 등등.의 경험이다.
가장 기억에 남는 경험 중 하나는, 개발 코드 수정 배포를 임의로 진행해서 서비스 오픈 직전까지도 안정화가 안 되었고, 결국 오픈 보고를 해야 하는 당일까지 2박 3일간 서비스 전면 장애를 겪었고, 서비스가 탄생하기도 전에 죽게 만들 뻔한 경험이다. 이 때, 사실 개발 코드상의 문제는 해결되었지만, 이미 적재된 트래픽이 해소가 될 때까지 문제를 지속시킨다는 것을 처음 알게 되었고, 결국 ‘운영의 묘미’로 서버를 내렸다 올렸는데, 이 결정을 내리는 데까지 꼬박 2박 3일이 걸렸다.
이렇게 온갖 욕을 먹는 경험 덕분이었는지 몰라도, 클라우드 전문가는 아니지만 클라우드 역사의 잔재와 경험으로 체화된 숙련공으로 발전하는 계기가 된 것 같다. 지금 생각해보면, 정말 많은 서비스를 직접 만들고 운영했던 이 시기는 값진 경험이었다. 어떻게 하면 서비스 확장이라는 미명하에 돈을 방만하게 쓸 수 있는지, 어떻게 하면 상위 경영진을 그럴듯하게 설득할 수 있는지도 알게 되었던, 그런 시기였다.
2014년 전사적 클라우드 비용 절감 - FinOps 개념과 유사한 활동의 시작
2014년부터는 글로벌 경기의 불확실성 등으로 인해, 전사적으로 ‘비용 절감’이라는 화두 아래 본격적인 클라우드 비용 절감 활동이 시작되었다. 당시에는 단순히 예산 대비 30% 삭감이라는 표면적인 목표 아래 본격적인 비용 절감 활동을 시작했던 것으로 기억한다.
이러한 비용 절감의 흐름 속에서, 클라우드 환경의 복잡한 비용 구조는 더욱 부각되기 시작했다. 클라우드는 기존의 회계나 재무 방식과는 전혀 다른 속성을 가지고 있었기 때문이다. 회계나 재무 분야에서는 일반적으로 연간 예산 범위 내에서 비용을 운영하는 방식이지만, 클라우드 환경에서는 실시간으로 사용량이 변동되며 정확한 비용과 예산 예측이 어려웠다. 클라우드 사용량과 비용이 천문학적으로 증가하던 시기에는 이러한 특성으로 서비스 품질을 유지하기 위해 과도하게 높은 사양을 유지하거나, 초반에 설계된 구조에서 비용을 효율화 하기 위한 구조 개선이 어렵다는 사유로 서비스의 개선없이 계속 유지 운영하는 일이 반복되었다.
당시 경영진이나 재무 부서는 이를 ‘불가피한 지출’, 즉 그레이 존(Grey Zone)이라고 부르며 어쩔 수 없이 비용을 투입하는 상황으로 받아들였다. 마치 밑 빠진 독에 물 붓는 듯한 느낌으로 지속적으로 비용을 사용하였다. 재무는 ‘알아서 잘 쓰겠지’ 하며 예산을 세웠지만, 막상 집행이 시작되면 예상치 못한 지출이 계속 발생했고, 그제서야 심각성을 인식하게 되는 구조였다. 당시만 해도 ‘투자’라는 인식이 강해, 불만이 있어도 대체로 그냥 넘어가는 분위기였다.
그러던 중 '비상 경영'이라는 키워드와 함께 조직 전반에 강도 높은 비용 절감 압박이 시작되었다. 이 당시 클라우드 집단에 있음에도 불구하고 FinOps라는 개념 자체는 존재하지 않았다. 대신, 경영 혁신과 비용 절감이라는 원론적인 목표 하에 일괄적인 30% 삭감을 요구받았고, 이를 달성하지 못할 경우 임원들의 KPI와 평가에 영향을 주겠다는 압박이 시작되면서 조직은 비용에 관심을 갖기 시작했다.
비용 절감 활동의 첫 단계는 현황 파악이었다. 비용과 자원을 관리하는 담당자는 있는지, 어떤 방식으로 자원이 사용되고 있는지부터 파악하기 시작했다. 조직 간의 복잡한 이해관계로 인해 이러한 정보 수집에는 수개월이 소요됐고, 당시 클라우드 서비스 제공 업체(CSP) 역시 사용자에게 비용과 자원 사용 현황을 명확히 제공하지 못하는 시기였다.
또한, 내부 역량만으로는 한계가 있다는 판단하에 외부 진단을 병행하는 시기였다. 이에 따라 외부 CMP 도입과 함께 비슷한 같은 여러 툴들에 대한 POC(Proof of Concept) 및 자체 개발을 시작했으며, 맥킨지나 액센츄어 등의 외부 컨설팅 업체가 개입하여 300-400여 가지 항목에 대한 점검을 통해 본격적인 진단을 시작하게 되었다. 수백개의 엑셀 파일을 펼쳐놓고 조직장들에게 사용 내역을 하나하나 추궁하던 시절 이었다. 돌이켜 보면, 이런 행동이 의미가 없지는 않았지만, 서비스를 모르는 상황에서 일방적인 대화에 가까웠고, 진단하는 부서와 골이 깊어지는 계기가 되었던 것 같다. “너희들이 이 서비스를 잘 알아? ” 하는 심정이 자리 잡고 있었던 시기였다.
앞서 언급한 것처럼, 비용절감활동에서 문제 인지의 시작은 현황 파악이었다. 조직별로 클라우드를 사용해 본 사람이라면 알겠지만, 관리되지 않은 클라우드 환경에서는 단순히 비용 인보이스만을 확인할 수 있을 뿐, 자세한 정보 파악이 어려워 큰 혼란을 겪는다. 이런 배경 속에서 우리는 가장 먼저 이 정보를 수집하고 정리하는 단계부터 시작하게 되었다.
그리고 이 과정에서부터 서서히 '기득권'이라는 것이 형성되기 시작했다. 현황을 가장 먼저 파악하고 경영진에게 보고하는 조직이 상대적으로 더 큰 영향력을 갖게 되면서 일종의 ‘갑’ 포지션을 점유하게 된 것이다. 이러한 구조가 정착되면 오히려 신뢰가 무너지고, '골이 깊어지는' 문제가 생기는 경우도 있었다. 그 과정을 지켜보는 것도, 당시에는 꽤 흥미로운 일이었다.
정보 수집이 끝나면 "우리가 이 비용을 제대로 쓰고 있는가?"라는 질문으로 넘어가게 된다. 이론적으로 메모리, IO, CPU 등의 사용 현황을 분석하여, 사용률이 낮은 자원은 낭비 요소로 판단하고 일괄적으로 자원을 축소하거나 삭제하는 조치를 취했다. 그러나 클라우드 운영에 적합한 설계가 처음부터 제대로 되지 않았고, 서비스에 대한 충분한 도메인 지식 없이 무리하게 추진하는 자원 축소는 대규모 서비스 장애로 이어질 수 있었다. 특히 서비스의 본질을 충분히 이해하지 못한 상태에서 진행한 위와 같은 접근은 예기치 못한 문제를 일으키는 주요 원인이 되었다. 앞서 언급했듯이, 문제는 또 다른 문제로 덮는 악순환을 만들기도 했다.
자원을 급격히 줄인 후 발생한 서비스 장애로 인해, 각 조직 담당자들은 예산을 통제하는 부서에 강하게 반발했고, "비용을 줄이면 당신들이 이 서비스 장애에 책임을 질 수 있느냐"는 말이 오가며 갈등이 번번히 발생했다. 결국 이러한 갈등 상황에서 조직은 적절한 타협선에서 비용 절감을 단행하거나, 반발에 굴복하는 두 가지 선택지 중 하나를 선택하도록 강요 받았다.
이러한 와중에 나름 잘 나가는 서비스가 없어지는 사건이 발생하기도 했다. 반대로, 가장 많은 비용을 사용하는 다른 서비스는 줄일 요소가 많이 있음에도 불구하고, 미래 투자 가치나 여러 이해관계로 인해 계속 유지되기도 했다. 이 서비스는 지금도 잘 운영되고 있는 것으로 알고 있다.
2015년-18년 멀티클라우드를 통한 비용 분산 및 CSP와 할인율 협상
2015년에서 2018년까지는 ‘비용’이라는 단어를 중심으로, 서비스에 대한 이해 부족과 복잡한 이해관계로 인해 비용 절감 접근 방식에 변화가 생기기 시작했다. 개인적인 견해이긴 하지만, 이 변화는 두 가지 방식으로 나누어졌던 것 같다.
첫째는 CSP(Cloud Service Provider)와의 할인율 협상이었고 이를 통해 내부 관리의 어려움을 할인율을 통해 일정 부분 상쇄하는 효과를 가졌다. 이것은 대기업이 CSP에 상당한 매출을 올려주고 있기에 가능한 방법이었다.
두 번째 방식은 RI(Reserved Instance)를 통한 할인 적용이었다. 당시 SP(Savings Plan)가 등장하기 전이라 중앙에서 RI를 일괄 관리하고 이를 조직별로 배분하는 방식으로 비용 절감을 시도했다. 그러나 RI 관리의 복잡성과 혜택에서 제외된 부서들의 불만은 심각한 문제로 부각되었다. 특히 초기에는 노하우 없이 RI를 운영하다 보니, 제대로 관리되지 않은 RI와 낮은 커버리지로 인해 오히려 비용 폭탄이 되는 경우도 있었다. 이러한 경험은 왜 현재 FinOps에서 중요하게 생각하는 RI나 SP와 같은 항목들이 자동 관리되어야 하는지를 잘 보여준다.
결국 비용 관리 전략은 멀티 클라우드를 통한 비용 분산과 CSP(Cloud Service Provider)와의 협상으로 발전하게 되었다. 이러한 접근은 오늘날 FinOps 전략과도 맞닿아 있지만, 당시에는 직원들의 클라우드 및 비용 관리에 대한 성숙도가 충분하지 않아 많은 불만이 제기되었다.
또한 AWS 등 주요 CSP에서 신규 서비스 도입 시 제공하는 크레딧 혜택 덕분에, 일부 조직에서는 솔루션 교체 시도를 간헐적으로 진행하기도 했다. 이 일련의 과정에서 기존에 경험하지 못했던 다양한 신규 솔루션과 멀티 클라우드 환경을 접하게 되면서 기술적으로는 큰 성장의 계기가 되었지만, 개인적인 시각에서는 결국 가장 큰 수혜자는 CSP들이었다. 왜냐하면, 그 당시만 해도 대규모 트래픽과 데이터를 실질적으로 운영하는 기업이 거의 없었기 때문에, CSP 입장에서는 실전에서의 노하우를 얻을 수 있는 아주 좋은 기회였기 때문이다. 이 경험들을 기반으로 CSP들은 더욱 빠른 발전을 이루게 된다.
한편, 클라우드 서비스의 사용량과 데이터는 계속해서 증가했고, 여러 비용 절감 노력이 있었음에도 불구하고 다시 비용이 증가하는 현상이 나타나기 시작했다. 결국 주요 서비스들을 제외하고는, MAU(월간 사용자 수)가 일정 수준 이하이거나 매출 기여도가 낮은 서비스들에 대한 비용 절감 압박이 심화되었다. 이에 따라 운영과 개발 조직은 생존을 위해 아키텍처와 성능 개선에 대한 치열한 고민을 시작했고, 제한된 예산 안에서 인프라와 개발 혁신이 이뤄지기 시작했다. (운영 또한 포함된다)
이 시기를 기점으로 일부 조직에서는 ChatOps, EKS 기반의 선진 구조 도입, 테라폼 활용, 외부 SaaS 솔루션 사용, 서버리스 아키텍처 전환 등 보다 진보된 클라우드 아키텍처로의 전환이 본격화되었다. 비용을 줄이면서도 성능을 보장하기 위한 노력은 말 그대로 '미친 듯한 매달림' 수준이었다.
그 전까지는 일부 기술 리더가 전체를 이끄는 구조였고, 조직 내 클라우드 성숙도 편차도 매우 심했다. 하지만 이 시기를 기점으로 서비스를 담당하는 인력의 개발·운영·비용 관리에 대한 전반적인 성숙도가 빠르게 높아지기 시작했다. 특히 무중단 운영, 사용자 컴플레인 대응, 기능·솔루션 비교 분석 및 도입 실패 경험, 그리고 운영 실패로 인한 야근과 재무팀 호출 등 다양한 압박 속에서,어떻게든 생존하기 위한 실질적인 전략을 찾기 시작했다. 다시 말해, 운영을 위한 개발로 전환된 셈이다.
그리고 이렇게 실행하다 보니, 이전에 우리가 얼마나 많은 자원과 인력을 비효율적으로 쓰고 있었는지 스스로 인지하게 되었다. 이러한 자각은 결국 '업무의 극악의 자동화'라는 방향으로 이어졌고, 자동화를 위한 기술 및 운영 혁신이 본격화되었다. 이유는 간단하다. 그렇지 않으면 일이 너무 많아 결국 쓰러질 수밖에 없었기 때문이다.
이러한 값진 경험들은 주변 조직과의 생존을 위한 기술 교류와 ‘기술 멋부림’을 심화시키는 계기가 되었고, 나아가 부서 간 경쟁과 압박으로 이어졌다. “우리가 더 잘한다”, “더 적은 인력으로”, “더 적은 비용으로 서비스를 안정적으로 운영한다”는 식의 경쟁이 시작된 것이다.
2019년 클라우드 비용 빅절감 프로젝트 - 본격적인 FinOps 활동 시작
이후 시간이 흘러 몇년뒤에 전사적으로 클라우드 비용 빅 절감이라는 프로젝트가 탑다운 미션으로 떨어졌다. “많이 쓰니 많이 줄여라”는 단순하지만 강력한 메시지였다. 이 때부터 본격적인 FinOps 활동이 시작되었다고 볼 수 있다. 처음에는 막막했으나, 최적화와 효율화, RI/SP 도입, EDP 협상 등 사용 가능한 모든 카드를 총동원해 대응했다.
조직별 이해관계 충돌로 인해 프로젝트는 자주 난관에 부딪혔다. 이를 타개하기 위해 두 가지 전략을 병행했다. 하나는 클라우드 전문가로 구성된 팀이 각 서비스 아키텍처를 철저히 리뷰하는 것이었고, 다른 하나는 재무팀 주도로 FinOps 유사 도구를 강제 도입해 투명한 데이터를 확보하고 진단을 시작하는 접근이었다.
처음에는 흔히 알고 있는 보편적 방식, 즉 미사용 자원 정리나 Right Sizing 등으로 접근을 시도했지만, 이는 곧 한계에 부딪혔다. 과거와 달리 클라우드 성숙도가 높아지고, 서비스 품질에 대한 책임 소재 문제가 대두되면서 단순한 접근 방식은 결국 실패로 돌아갔다. 아무리 보기 좋은 데이터를 가지고 간다 하더라도, 해당 서비스에 대한 깊은 이해와 책임을 요구하는 문제에 부딪히게 되면, 이를 압박하는 부서조차 주저하게 되는 상황이 발생했다.
그래서 새로운 방식이 필요했다. 지금은 CSP들이 기본으로 제공해서 당연하다고 생각하는 자원 스케줄링이나 스팟 인스턴스 관리 기능이 있지만, 당시에는 CSP에도 이러한 기능이 없었기 때문에 우리는 이를 직접 개발해야 했다. 이를 입증하기 위해 마루타 프로젝트를 선정하고, 실제 동작 여부보다 “FinOps 방식의 가능성”을 보여주는 것이 목적이었기에 3개월간의 준비 과정을 거쳐 테스트에 들어갔다. 이게 동작되는지 아닌지는 중요 하지 않았다. FinOps도입을 전파하기 위한 수단이 필요 했던 시절이다. 내부적으로 나름 완성도 있게 만든다고 했지만, 짧은 기간에 만든 솔루션은 각종 버그와 후폭풍을 동반했고, 인내심이 필요한 과정이었다.
우여곡절 끝에 직접 개발한 여러 효율화 솔루션 —자원 스케줄링 기능과 당시 오픈소스를 뜯어고쳐 만든 스팟(spot.inst)관리 도구 등—을 통해 효율화 수단을 마련했다. 이걸 내부에서 개발 운영하고 있는 과제를 마루타 삼아서, 3개월간의 극악의 효율화를 실행했고, 이로부터 도출된 데이터를 기반으로 타 조직에도 강제적으로 해당 도구들을 적용하기 시작했다. 단순한 도구 도입을 넘어 서비스 구조를 근본적으로 재설계했으며, 인력 효율성을 진단하기 시작했다.
물론 이 과정을 "FinOps 툴의 효과"라고 거창하게 표현하긴 했지만, 실제로 비용 절감에 가장 큰 기여를 한 건 데이터 구조 전환, 아키텍처 현대화, 인력 쇄신 등 구조적인 변화였다. 이 일련의 활동들은 내가 공격자 포지션을 갖을 수 있게 해주었으며, 나에게 클라우드 서비스 개발자에서 클라우드 운영 책임자로의 전환 계기를 만들어주었다.
이 경험을 통해 얻은 교훈은, 전 조직을 움직일 필요는 없다는 것이다. 핵심 몇 개 조직의 변화를 만들어내고, 그 결과를 기반으로 경영진과 재무팀에 비용 절감 효과 및 예측 데이터를 제시하며 이후 각 조직의 담당 임원들에게 비용 절감을 KPI로 할당하면서 참여를 유도했고, 진단 조직은 클라우드 서비스에 대한 높은 이해도와 기술적 신뢰성을 바탕으로 각 부서에 필요한 실행 수단을 제공했다. 이러한 접근 방식은 지금의 FinOps 철학—협업 기반의 비용 최적화, 예측 가능한 의사결정, 실행 가능한 도구와 프로세스—과 매우 일치한다고 볼 수 있다.
사실, FinOps 도구 자체보다 그 후속 여파로 단행한 절감이 훨씬 컸다. 그 시절 가장 많이 받은 질문은
“이런 방식으로 효율화를 하면 RI/SP보다 더 절감이 되느냐?”,
“EDP보다 더 할인이 되냐?”였다.
실제로 당시 기준으로는 오히려 역전 현상이 자주 발생했다. 하지만 중요한 건 현재가 아니라, 미래 구조 변경 후 발생할 장기적 절감 효과였다. 이걸 납득시키기 위한 논쟁과 설득은 치열했다.
문제는, 지속적인 관리 없이는 이 모든 노력이 쉽게 무너질 수 있다는 점이다. 조금만 관리가 느슨해져도 다시 원상복구 되거나, 기술적 부채가 누적되고, 비용은 흔들리기 시작한다. 한번 불신이 생기면, 향후 FinOps 도입 자체를 거부하는 분위기로 번지게 된다. 즉, 지속적인 노력과 혁신이 없으면 다시 다이어트처럼 요요현상이 생긴다. 이런부분이 FinOps의 생태계에서 매우 중요한 포인트다.
또한, 아무리 잘하고 있다고 하지만, 외부 요인등에 의해서 무용지물이 되는 경우도 자주있다. 대표적인게 환율이다. 예를 들어, 2021년까지 효율화와 구조 변경을 통해 일정 수준의 절감 성과를 냈지만, 환율 상승으로 인해 그 효과가 전부 상쇄된 사례도 있었다.
기껏 월 10억을 줄였더니 환율때문에 역전되어서 재무에서는 “비용 절감 한거 맞아?” 이런식의 일방적 소통등도 빈번하게 생긴다 (이럴때는 결국 사람을 줄이는 악순환이 생기기도 한다 ) 아마 최근 세계 경제 및 한국의 환율등으로 과거와 비슷한 일을 겪는 사례가 나올거라고 보인다. 역사는 되풀이 된다.
암튼, 지금까지의 이야기는 과거의 경험이다. 이 경험을 약간 정리 하면, 항상 시작은 경영진의 위기 의식에 의해서 추궁이 시작되고, 움직이지 않을때 조직의 KPI등의 미션과 예산이라는 통제 아래 움직이기 시작했다. 물론 자체적으로 잘 운영하고 있는 조직도 있다. 이 경우에는 굳이 외부에서 도구나 방식을 강제하지 않는다. 이미 잘하고 있기 때문에, 괜히 건드려서 흐름을 깨지 않는 것이 낫기 때문이다.
또한, 기능적으로 보면 요즘의 비용 분석, 이상 탐지, 자원 추천, 멀티 클라우드 비교, 성능 분석, 네트워크 진단 등 우리가 흔히 아는 기술적 방법론은 이미 보편화된 상태다. 실제로 문제를 인식하는 순간, 대부분은 이와 같은 기술적 접근부터 시도하게 된다.
현재 비용절감을 하는 과정 - 단일 서비스 운영 조직 vs. 여러 서비스 관리 조직
자, 그럼 이제 과거의 경험을 바탕으로 현실 세계에서 실제로 비용 절감이 어떻게 이루어지는지 살펴보자. 우리는 과연 그 과정을 제대로 알고 있을까? 여기서부터 이야기를 시작해보려 한다.
앞서 언급했듯이, 항상 어떤 계기가 생긴다. 경영진이든 누구든, 누군가 비용과 자원 사용에 대해 문제를 제기한다. 운이 좋다면, 지적이 들어왔을 때 이를 제대로 이해하고 자발적으로 대응하면 되겠지만, 불행하게도 대부분의 경우 그렇지 않다. 사람들은 대개 하지 않으려고 한다.
그 이유는 명확하다. 일이 늘어나고, 욕을 먹을 수도 있다는 걸 알기 때문에, 그리고 이미 알고 있다 - 쓰면 더 썼지 줄이는 건 정말 어려운 걸 알고 있기 때문에, 그럼 결국 이 일은 세 가지 기본 축에서 움직인다. 수행을 하는 담당자, 진단하고 분석하는 담당자, 그리고 이 모든 걸 평가하고 의사결정을 내리는 담당자. 여기서 더 확장하면, 현재 FinOps Foundation에서 정의하는 페르소나들처럼 역할이 더욱 세분화된다.
하나의 예시를 들겠다,
“이번달 예산 무조건 20프로 삭감해. 특히 클라우드 비용부터 줄이자.”
위와 같은 목표가 할당되면, 담당자들은 무엇부터 할까.
“최근 3개월, 6개월, 1년간 클라우드 비용 쓴 것 모두 가지고 와봐”. 라며, 비용이 그동안 증가가 되었던, 아니던 간에 이 비용 데이터를 가지고 시작을 한다.
여기서 단일 서비스를 하는 조직과 여러개의 조직이 있는 경우는 접근법이 다르다.
단일 서비스를 하는 조직은 바로 어떤 자원이 가장 비용을 많이 쓰고 있는지 자원 현황 분석 부터 시작한다. 그리고 고민을 한다. “ 지금 이걸 줄일수 있을까?”
비용이 많이 나오는 영역은 보통 정해져 있다. DB(데이터베이스)나 네트워크 비용처럼 말이다. 일단 무언가 조치를 취하기 위해, 우리는 보통 먼저 사용하지 않는 자원부터 두들겨보기 시작한다. 그런데 막상 해보면 그로 인한 비용 절감 효과는 생각보다 크지 않다. 아니면, 운이 좋아서 큰 비용이 나가고 있는 관리하고 있지 않았던 리소스를 찾아낼 수도 있지만 그건 어디까지나 운일 뿐이다.
그 다음은, 리스트를 뽑는 작업이다. 어떤 리소스를 현대화, 즉 Right Sizing 할 수 있을지 열심히 찾아본다.
무엇인가 찾아보고 “이 정도면 줄이면 그래도 비용 줄였다고 이야기를 할 수 있지 않을까” 하는 생각으로 나름 준비를 하지만, 이내 고민이 생긴다.
“이거 줄이면 RI/SP 부족해지는 거 아니야?”,
“EDP 조건 어긋나서 shortfall 나면 어떡하지?”,
“RI/SP 언제 만료지? 그때까지 이게 가능할까?”
이런 고민이 생기면 이제 위의 것들은 어려우니, 우리가 쓰고 있는 전체 계정—운영계, 개발계 등—을 다시 들여다보기 시작한다. 물론 순서는 바뀔 수도 있지만, 결국 모든 계정을 하나하나 살펴보게 된다.
어느 정도 계정 등의 정리가 되면 보고는 통상 이렇게 자랑스럽게 진행된다.
"앞으로 이렇게 줄여 나가면 비용을 효과적으로 절감할 수 있습니다." 라고 통상적인 1차원적인 보고가 이루어지지만, 하지만 실제로 20% 이상을 줄이기는 쉽지 않다. 그럼 이제 선택의 기로에 선다.
정말 불필요한 서비스를 내려야 하나? 아니면 여기에 투입된 인력을 줄여야 하나?
그런데 어느 쪽이든 결코 쉬운 선택은 아니다.
그래서 개발과 운영 경험이 어느 정도 있는 사람이라면 여기서 본질적인 고민을 시작한다.
"이건 매출과도 연결된 문제인데, ROI 관점에서 우리 아키텍처나 설계 자체를 다시 손봐야 하지 않을까?"
이 지점부터 개발과 운영의 구조적 변화가 시작된다. 만약 이런 논의 없이 그대로 간다면, 이는 결국 '불가피한 비용 지출'이라는 이름으로 그레이존(Grey zone) 속에 방치되고, 조직은 계속해서 그 상태를 유지하게 된다.
_______________________________________________________________________________________________________________________________________
여러 서비스를 관리하는 조직이라면, 흐름은 유사하지만 시작점이 조금 다르다.
대부분의 조직에서는 “어느 조직이 가장 많이 쓰고 있지?”라는 질문에서 출발한다.
이 방식은 자연스럽게 가장 많은 비용을 사용하는 조직과, 그 조직을 책임지고 있는 관리자에게 초점이 맞춰진다.
물론 비용 지출이 정당한 사유에 기반하더라도, 상대적으로 잘 관리되고 있는 조직이 전체 비용 수치를 맞추기 위한 조정 대상이 되는 경우도 있다. 일종의 '칼을 맞는' 셈이다.
이후에는 대부분 앞서 언급한 방식—리스트 작성, 자원 정리, 계정 확인 등—을 그대로 따라가게 된다. 하지만 이 과정에서도 RI/SP 관리, 특정 조직에 대한 편애, 운영 노하우 차이 등으로 인해 조직 간 갈등이 발생하기 쉽다. 실제로는 특정 담당자에게 책임이 전가되는 형태로 번지기도 한다.
이쯤 되면 조직 내부에서는 자연스럽게 비용 배분 구조를 다시 검토하게 되고, 각 조직별 예산과 분배 내역을 두고 논쟁이 시작된다. 물론, 이 상황을 모두가 부정적으로 받아들이는 것은 아니다. 오히려 예산 체계가 명확해지는 점에서 반기는 조직도 있을 수 있다.
_________________________________________________________________________________________________________________________________________
그러나 개발과 운영에 대한 일정 수준 이상의 경험이 있는 사람이라면, 결국 본질적인 고민에 직면하게 된다. 비용은 매출과 직결되기 때문에 ROI(투자 대비 수익)를 고려하며, 우리의 아키텍처나 설계를 근본적으로 줄여야 하는 시점이 온 것은 아닐까 하는 질문을 던지기 시작한다. 이 시점부터 실제로 개발과 운영 방식에 변화가 생긴다.
반대로, 이런 고민 없이 단순히 "불가피한 비용 지출"이라는 명분으로 현 상태를 유지한다면, 이는 점점 지속적인 그레이존으로 진입하게 되고, 문제는 더 복잡해질 수밖에 없다.
_________________________________________________________________________________________________________________________________________
위의 사례는 대부분의 조직이 한 번쯤은 반드시 겪게 되는 현실적인 이야기라고 생각한다. 실행을 맡은 부서는 최대한 열심히, 때로는 일부를 감추며 업무를 추진하지만, 결과를 받아들이는 쪽은 오직 숫자만 본다. “숫자가 줄었느냐, 줄지 않았느냐”, 그게 전부다. 무엇을 어떻게 했는지는 고려되지 않는다.
이 시점부터 조직 내부에 불협화음이 생기기 시작한다.
우리가 백날 노력을 해봐야 노력의 대가 보다 숫자로만 판단한다고 생각하기시작하면, 이제 둘중 하나다. 비용 삭감을 대비 해서 일부러 부풀려서 작업을 하는 방법과, 현상태유지로 어떻게 대응할까이다. 이럴때 자원 과 비용 분석과 현황을 조율하기 시작한다.
이 예시를 기준으로 하면, 무엇이 되었던간에 FinOps라는것은 비용절감이 목표가 아니라 현재 우리가 잘 하고 있을지 아니면 이게 적정성을 가지고 운영을 하는지를 잘하는 지 현황을 파악하는것부터 시작을 하고 유관부서를 설득 하는 과정의 일련의 뫼비우스 띠처럼 움직인다고 볼수 있다.
항상 고민이 되는 건 바로 Right Sizing, Unused Resource 정리, Modernization 같은 접근 방식이다.
이런 자료를 기반으로 우리가 얼마나 비용을 효율적으로 쓰고 있는지를 파악할 수 있느냐고 묻는다면, 대답은 "그렇다"이다.
하지만 그 데이터를 기반으로 실제 운영 중인 서비스에 이를 곧바로 적용할 수 있느냐는 질문에는, 대답은 명확히 "아니다"이다.
대부분 운영과 서비스를 직접 책임지지 않는 부서에서는 쉽게 이야기를 하는 부분이기도 하다.
서비스 운영은 매우 보수적이기때문에 운영상에 생기는 이슈에 대해서는 항상 책임이라는 무거운 단어가 따라오게 된다. 차라리 이럴바에 돈을 더 내고 말지이다. 그래서 인프라 자원 확대등으로 인해서 비용이 더 늘어나는 케이스들도 생긴다. 이런 사이클이 반복되다 보니, 그럼 이런 가장 기본이 되어야할 부분을 제외하고 좀더 서비스운영에 영향을 미치지 않은 EDP / RI&SP를 미리 구매해서 비용 절감을 하는 방식으로 갈수 밖에 없다. 때로는 진보적으로 발전이되면, 스케쥴리처렁 안쓰는 시간대 서버를 내리고, 보다 값싼 자원을 교체 하는 Spot등도 고민을 한다. 하지만, 이것또한 서비스 운영과 책임이라는 울타리 안에서 책임을 벗어나기 힘들다. 물론 어느정도 성숙도가 있으면 이런 부분들을 자동화 해서 일하는 사람의 업무에 대한 선택과 집중을 고민하기도 한다.
그리고 그 다음으로 어프로치를 하는 경우가 책임에 대한 부여이다, 통제를 하든 투자를 하든 그걸 담당하는 부서의 미션으로 가도록 설정 하는거다. 왜냐 하면 이게 가장 쉽다.. 사람을 찍어 내리고 못하면 책임져 이거만큼 편하게 이야기 하는것도 없기때문이다. 그럼 이걸 할려면 어떻게 하지.. 엑셀로 하든, 사람 한땀 한땀 보면서 문서화를 통해, 정리 해서 찾아갈수 있다. 이것도 자원이나 조직이 작을경우 가능하다. 그래서 이런걸 잘 분류하고 관리 해서 볼수 있도록 Tag를 도입하여 잘 발라서 볼수 있도록 한다. 이렇게 하면 방대한 데이터에서 어느조직이 어떤 자원을 잘쓰는지를 잘 구분해서 좀더 쉽게 분석이 가능하게 되는거다.
하지만 이런걸 넣는다고 비용이 줄어들어 라고 하면 Yes or No이긴 하다. 결국 모든 액션을 하기 위해서는 사람이 들어가야 하는데, 이런 과정에서 본인의 책임이 없어지게 되면 하다가 중단하게 된다. 그래서 KPI등 조직의 미션과 예산 통제를 하기 시작한다. 이걸 통제를 못하면 무용지물이 되는 경우를 많이 보았기때문에, 그거에 대한 조직의 성과로 이야기를 많이 하는거다.
이런 상황이 되면, 줄일 수 있는 방법에 대해서 내부적으로 여러 가지 고민을 하게 된다. 서비스를 어떻게 하면 적은 비용으로 할지, 운영 관리 포인트도 어떻게 하면 더 효율적으로 해야 할지, 이걸 할려면 서비스의 이해와 현재 본인이 쓰고 있는 자원에 대한 코스트가 얼마나 비싼 건지를 인지 하게 하고 결국 Unit Economics로 발전하게 되는 것이다.
그리고 어느 순간 사람에 대한 효율성도 이야기가 나오게 시작한다. 결국 누군가 책임을 지고 움직이면 한다. 책임을 진다고 해도 잘 돌아가는 것은 아니다. 대부분 그 사람의 권한과 의지치가 어느 정도에 따라서 달라지는 경우도 많이 생긴다. 그리고 이 노력이 단기적으로 될수도 있고 오랜 시간이 걸릴 수도 있다. 하지만 조직은 생각한것처럼 문화가 정착되지 않은 시점에서 그렇게 유기적으로 움직이기가 쉽지 않기 때문에 이 책임을 어떤식이라도 분산을 할려고 한다. 좋게 말하면, 서로 싸우기 싫을때에는, 같이 일하고 협력하고 공동 작업으로 이야기를 한다라고 이야기를 하고 적이 되면, 서로 다른 핑계를 대기 시작한다. 이게 최근 핀옵스의 Framework이 기술 베이스와 기업의 비즈니스 성과 지표로 바뀌게 되는 이유라고 생각을 한다.
또한 이런 데이터가 재무를 책임지는 곳에서 이 데이터의 신뢰와 작업의 신뢰를 알기 위해서, Budget이라는 울타리에서, 계획된 예산 / 그리고 예측에서 얼마나 잘 쓰고 있는지를 설득하는 것이 매우 중요해졌고, 이 데이터의 신뢰도에 따라서, 각 조직의 자유도가 높아지지 않을까 싶다. 그리고, 이런 과정이 발전되면, 공통의 미션과 실행을 하는 부서의 communication이 가장 중요한게 발전되는 것 같다.
알아야 잘쓴다는 말이 있다. 가장 잘 아는 부서는 이 서비스를 운영하고, 개발하고 운영 관리 하는 부서이다. 앞에서 이야기 한 것처럼 이런 최근 FinOps Foundation의 새로운 Framework 변화가 이 것을 대변하고 있다 생각한다. 즉, 잘 모르면 왜 많이 쓰는지를 모른다. 과거에는 재무쪽에서만 비용이라는 단어로 이야기 하면 비용을 줄일수 있는 여지가 있었지만, 현재는 서비스를 운영하고, 개발하는 조직이 가장 잘 알아야 하는 이유 중 하나이다.
즉, 이런 여러 부서들이 Finops라는 명제 아래, 표면적으로 낭비되고 있는걸 찾아서 개선이라고 하지만, 결국에서 잘 알도록 도와주고 이걸 개선하여 투자 대비 효율적으로 더 잘쓰게 하는 개념으로 봐야 한다고 생각 한다. 그럼 이런 기조에서 FinOps의 도구는 시간과 노력 그리고 여러 사람들이 쓰는 도구를 하나의 목소리와 하나의 언어로 이야기를 하는 가장 기본적인 수단이라고 생각이 된다. 어떤 사람은 쓰는 돈만 보기도 하지만, 어떤사람은 기술 용어만 바라보기도 하고, 어떤 사람은 KPI등 달성율의 숫자만 관심이 있지만, 이걸 이루는 기준 데이터는 다 동일 하다..무엇이 되었건 돈을 지불하는 지불은 바뀐적이 없고, 이걸 쓴것에 대한 비용 계산의 원천 데이터의 로직도 바뀐적이 없다.
옵스나우처럼 각 모든 Finops의 도구들은 각자 기능들의 역할이 있지만 해당 기능들이 결코 하나의 기능만을 위해 만들어진게 아닌 유기적으로 하나의 언어를 제공하기 위한 수단이라고 생각해야 한다. 여기에 기능적 사용성등 차이는 천차만별로 있을수 있고 보고자 하는 내용도 서로 다르지만, 결국 잘쓰고 있냐, 더 잘할수 있냐를 도와줄수 있는 관점에서 모든 데이터가 보는 관점은 다르지만 하나의 이야기로 해야 한다. “잘 쓰고 있는거 맞지”, 그리고 ”같은 언어로 이야기 하는게 맞지” 라고.
현재 우리 옵스나우는 이제 FinOps을 이해하고 도입을 하고자 하는 도움이 되어야 하는 위치이다. 사람들은 어떤 툴을 쓰던 상관 없다. FinOps을 이해를 할라면, FinOps에 대해 얼마나 정확하게 이해하고 있는지 점검할 필요가 있다. 그 뒤 어떤 툴이든 수단을 도입을 할려면, 이러한 일련의 과정들을 어느정도 알고 있는 상태에서 시작되어야 한다. 앞에 개인 과거 사례에도 언급을 했지만, 나는 FinOps이론을 몰라도… 시도를 했다. 무수한 실패 및 성공을 반복적으로 하면서 시도를 했었고, 거기에 FinOps의 단어아래 포장하고 있다. 즉, 기업 자체는 이론 자체가 부족해서가 아니라, 조직 내부의 경험과 도전 의지, 운영적 이해, 각 담당하는 서비스 본질, 그리고 어떻게 같이 일해야 하는지 깊은 고민이 함께 뒷받침되지 않았기 때문이다. 이론은 구글에서 찾아보면. 잘 정리 되어있다. 머리로만 알고 아는 척하는것은 한계가 있다.
옵스나우는 다행히도 MSP인 베스핀글로벌에서 겪었던 많은 운영 경험과 고객의 요구를 기반으로 성장해왔다. 이런 경험을 토대로 FinOps의 영역에서 하나의 목소리로 FinOps를 이야기 위해 거듭 발전하고 있다. 아직은 가야 할길은 많이 있지만 이런 경험이라는 재산아래 서비스를 고도화 시키고 있다.
하지만 내부에서 Finops의 업을 하는 사람은 해당 업에 대한 깊은 고민과 경험을 바탕으로 비용 통제 및 효율성을 고민하며 개발에 참여하는 사람이 얼마나 있는지 짚어 볼필요는 있다. 물론 잘하고 있다고 말하지만, 실제 경험을 해본 사람과 아닌것은 차이가 많이 난다. 이렇기 때문에, 과거 OpsNow 클라우드 비용 절감은 단순히 제품의 기능을 소개를 해 온적도 있지만, 이제는 각 기능의 필요성과 배경을 명확히 이해하고, 신뢰할 수 있는 데이터를 기반으로 조직이 효과적으로 액션을 취할 수 있는 스토리를 만드는 과정으로 발전 하고 있다. 과거에는 기능 위주로 갔지만, 지금은 전체 같은 언어로 볼수 있는 서비스로 진화하고 있고, 이걸 더 이해하고 잘 설명이 되는 방향으로 가고 있다고 생각한다.
우리는 조직 내부에서 실제로 클라우드를 분석하고 비용을 관리하며, 효과적으로 절감을 위해 고민하는 환경을 만들어왔는지 많은 고민을 하고 이걸 어떻게 더 잘 보여줄 수 있는지 노력이 필요한 기로에 서 있다. 제품과 서비스를 제공하는 는 입장에서 이 부분에 대한 철저한 이해와 경험은 필수적이다. 우리 이런 기능 있어요 하는 기능을 소개하는 수준을 넘어서, 우리가 진정으로 FinOps를 이해하고 실천하고 점검하고 이끌어야 하는게 OpsNow FinOps의 입장인 것 같다.
FinOps의 근본적인 시작은 관리되지 않은 클라우드 비용의 이해와 통제다. 많은 기업들이 FinOps 도입 시 비용 절감을 극대화할 수 있다고 기대하지만, 현실에서는 반드시 필요한 필수적인 요소보다는 선택적으로 활용되는 경우가 많다. 기업들은 이미 다양한 방식으로 비용 절감을 실천하고 있으며, 우리가 특별히 뛰어난 것은 아닐 수 있다.
비용 절감을 위한 방법론은 다양하다. CSP와의 대규모 할인 협상(EDP), RI/SP의 활용, 자원 효율화와 최적화 등은 기본적인 접근이며, 이는 FinOps 툴 없이도 가능한 일이다. 아니면 노동력으로 대체 해도 된다. 다만 이 과정은 시간과 노력, 비즈니스 도메인과 서비스에 대한 깊은 이해가 있을 때 더욱 효과적이다. 조직의 역량이 뒷받침된다면 서비스 구조를 리아키텍처링하고 성능 최적화를 통해 근본적으로 비용과 효율성을 향상시킬 수 있다.
그렇다면 왜 FinOps의 철학이 필요하고, 옵스나우와 같은 툴이 요구되는지 본질적인 고민이 필요하다. 클라우드 환경이 복잡해지고 조직이 커질수록 관리가 어렵고, 책임 소재가 불분명해져 방치되는 경우가 많다. 클라우드 비용 특성상 문제가 발견되었을 때 이미 상황이 악화된 경우가 많으며, 수정 및 조정에 상당한 시간과 노력이 들어간다. 지속적인 노력이 동반되어야 Finops가 제대로 돌아가는데 그걸 하기 위한 시작이 FinOps가 필요한 이유다.
FinOps는 비용과 자원을 주기적으로 모니터링하고, 문제 발생을 조기에 감지하여 리스크를 줄일 수 있게 한다. 이는 자원 효율화와 비용 최적화를 위한 첫걸음이다. 이 과정에서 조직 내 투명한 데이터 관리, 예산 통제, 거버넌스 관리 및 전반적인 Report를 통해 비용의 흐름을 명확히 아는 것이 필요하다. 이 단계에서 더 나아가 효율적이고 체계적인 관리를 위한 방법론과 협업 체계를 만드는 것이 FinOps의 본질이다.
이상적인 단계는 자동화를 도입하고, 전 조직이 같은 언어로 소통할 수 있게 하는 것이다. 그리고, 지속적인 사이클이 이루어져야 한다. 단순히 원타임으로 끝나는거면 굳이 FinOps / FinOps툴은 불필요하다. 지속적인 활동을 도움을 주기 위해 OpsNow의 FinOps가 가야 할 길을 어떤식으로 이런 문제를 풀고 제공해야 하는것이다. 기능의 개발되어서 우리도 되요가 아니라.
OpsNow FinOps가 가야 할 길
우리가 가야 할 길과 해야 할 것은 많다. 기술 트렌드가 과거와 달리 빠르게 변화하고 있고, 이걸 보완해야 하는게 우리이지만, 정작 우리 내부에서 기능 / 기술 이외의 것에 대한 본질을 이해하지 못하면, 아무리 AI등 첨단을 도입한다고 할지라도 오히려 새로운 AI 시대에 우리가 먹히는 역전 현상이 생길 것이고, 이미 생기고 있다고 본다. 또한, 클라우드의 성숙도가 과거와 달리 균등하게 발전된 시대에서 수준 높은 서비스와 제품의 경쟁력으로 갖기 위해서는 누구보다 내부에서부터 이런 본질을 잘 이해를 있어야 한다고 생각한다.
옵스나우가 국내 CMP 중 FinOps를 가장 잘하는 집단으로 자리를 잡아가는 과정에 있다. 여러 FinOps의 자격 보유, FinOps Certified Platform 획득등 기존의 기술만을 고집하던 상황에서 실제 어떤 메시지로 전달을 해야 하는지 고민을 하는 솔루션, 서비스로 거듭 발전하고 있다.
서비스가 발전하고 편해지면서, 대부분의 사람들은 과거와 달리 이게 어떻게 돌아가는지, 어떤식으로 구현되어서 쓰는지를 잘 모르고 있는 그대로 쓴다. 앞에서 이야기 했지만, 과거에는 자원 스케쥴링, Spot 기능은 당연한 기능이 아니었지만 이제는 당연한 기능이자 서비스이다. 즉, 기술의 진보가 사용자의 편의성을 제공했지만, 그걸 이해하고 운영을 해야 하는부분을 더더욱 멀어지게 만들어졌다고 본다.
지금도 클라우드가 편해지면 편해질수록 보여지는것만 볼려고 하고. 이걸 어떻게 동작을 할려고 이해를 하는경우가 드물다. 이런 부분은 이런 서비스를 제공해야 하는 우리가 파고 들어야 할 부분이기도 하다. 아는 만큼 보이기때문에, AI등을 통해 더 편리함을 원하는 세상이 되었지만, 그걸 이해하고 제대로 정보를 제공하는 사람들의 역할이 줄어든다고 본다. 이게 현재 우리가 짚어봐야 할 OpsNow FinOps의 부분의 시작점이라고 보여진다. 당연하다고 생각했던것들은, 항상 당연한게 아니였다. 그러나 우리가 이야기 하는 RI/SP의 자동관리가 어느 순간 당연한 기능이 되는 과정에 있듯이, 이러한 서비스의 당연함을 만들고 제공하는것도 우리여야 한다고 생각한다.
OpsNow가 클라우드 활용을 극대화하는 데 어떻게 도움이 되는지 궁금하신가요? 지금 확인해보세요.
FinOps Whitepaper 다운로드 – 더 스마트하게 비용을 절감할 수 있는 실용적인 팁과 인사이트를 받아보세요.
