우아한 Cloud FinOps 여정

1 month ago 14

클라우드는 이제 기업의 성장과 혁신을 뒷받침하는 핵심 인프라로 자리 잡았습니다.

새로운 서비스를 빠르게 실험하고, 트래픽 변화에 따라 유연하게 확장하며, 글로벌 시장에도 손쉽게 진출할 수 있도록 해주죠. 하지만 비용 측면에서는 기존 온프레미스 환경과 전혀 다른 도전에 직면하게 되었습니다.

과거에는 서버를 직접 구매해 데이터센터에 설치했기 때문에 예산에 맞춰 지출을 통제하기가 비교적 쉬웠습니다. 반면 클라우드는 필요한 만큼 빌려 쓰고, 사용한 만큼 비용을 지불하는 종량제 방식입니다. 초기 투자 부담은 줄었지만, 매달 비용 변동이 크고 원인을 분석하기도 복잡합니다.
게다가 빠른 배포와 확장을 중시하는 개발팀과 비용 예측과 통제를 중시하는 재무팀의 요구가 동시에 충돌하면서, 속도와 비용의 균형을 찾는 일이 기업 전체의 과제가 되었습니다. 이러한 맥락에서 데이터 기반의 비용 분석과 효율화, 그리고 조직 차원의 책임 문화를 가능하게 하는 FinOps가 오늘날 중요한 화두로 떠오르고 있습니다.

우아한형제들 역시 지난 3년간 이 과제에 집중해 왔습니다. 외부에서 흔히 접할 수 있는 FinOps 소개 자료보다 더 구체적이고, 실제 대규모 클라우드 환경에서 MSP 없이 직접 실행한 경험을 공유하려 합니다. 이 글이 효과적인 FinOps를 고민하는 분들에게 실질적인 참고가 되길 바랍니다.

일반적으로 생각하는 FinOps

FinOps에 대한 일반적인 이해는 다음과 같은 내용으로 요약될 때가 많습니다.

Financial + DevOps의 합성어
클라우드 비용 절감 행위

이 정의들이 완전히 틀린 것은 아니지만, FinOps라는 업무의 본질을 충분히 설명하는 데는 다소 부족함이 있습니다.
오늘은 우아한형제들이 FinOps를 어떻게 정의하고 이해하며 활용하고 있는지를 자세히 이야기해보겠습니다.

우리가 생각하는 FinOps

FinOps를 기업의 비즈니스와 기술 간 상관관계를 분석하고, 기술이 효과적으로 사용되고 있는지 데이터를 통해 입증하며, 비효율성을 찾아내 최적화하는 과정이라고 정의합니다.

이 설명이 처음에는 조금 추상적으로 느껴질 수 있습니다만, 이제 본격적으로 풀어가 보겠습니다.
FinOps를 이해하려면 다음 세 가지 핵심 요소를 알아야 합니다.

"비용 절감"과 "비용 최적화"의 차이를 명확히 인지하기
FinOps가 클라우드를 포함한 IT 자원 전반에서 비용 최적화를 실행하는 활동이라는 점
모든 이러한 활동이 궁극적으로 고객 경험을 개선하고, 회사의 성장 기반을 마련하는 데 기여한다는 점

비용 최적화와 FinOps

Gartner는 두 용어를 다음과 같이 정의합니다. 의미를 살리기 위해 원문을 그대로 가져왔습니다.

비용 절감(Cost cuts) : short-term move to decrease expenses
비용 최적화(Cost optimization) : a continuous, business focused discipline aimed at maximizing business value while reducing costs.
(출처: Gartner, Cost Optimization Done Right — Even in a Volatile Economy)

간단히 말해, 비용 절감은 비즈니스 영향을 깊이 고려하지 않고 지출을 단순히 줄이는 단기적 전략입니다.
반면 비용 최적화는 비즈니스 가치와 그 장기적이며 지속 가능한 성장 가능성까지 고려하며 실행해야 하는 전략입니다.
핵심적으로 비용 최적화는 회사의 성장 방향과 비즈니스 목표를 중심으로 이루어진다는 점에서 차별화됩니다.

그렇다면 FinOps란 정확히 무엇일까요? FinOps Foundation에서는 이를 다음과 같이 정의합니다. 역시 원문 그대로를 참고했습니다.

an operational framework and cultural practice which maximizes the business value of cloud and technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.
(출처: FinOps Framework by FinOps Foundation)

여기에서도 명확한 공통점이 발견됩니다. FinOps는 클라우드 및 기술 영역에서 비용 절감이 아닌 비용 최적화를 목표로 하는 활동입니다. Gartner의 정의와 마찬가지로, 비즈니스 가치를 극대화하는 것이 FinOps의 본질이며 핵심입니다.

따라서 FinOps라는 개념은 단순히 클라우드에서 비용을 줄이는 것이 아니라, 기술과 재정을 아우르며 회사의 장기적인 성장을 도모하는 중요한 과정임을 알 수 있습니다.

FinOps를 통한 고객 경험 개선 및 기업 성장

앞서 설명했듯, FinOps는 비즈니스 관점을 기반으로 한 비용 최적화를 목표로 합니다. 그렇다면 여기서 말하는 "비즈니스 관점을 고려한다"는 것은 어떤 의미일까요?

아래 이미지는 Amazon의 Cost Optimization Flywheel입니다.
이 그림은 기업 성장을 위해 필요한 요소들이 서로 시너지를 이루며 선순환 구조를 형성하는 과정을 설명합니다.

(출처: Amazon Cost Optimization Flywheel)

이 중에서 우리는 FinOps를 통해 Lower Cost Structure라는 항목에 기여하게 됩니다.
즉, 판매원가를 줄이면 합리적인 가격으로 상품을 제공할 수 있다는 것입니다. 이러한 가격 인하는 고객들에게 더 나은 구매 경험을 제공하며, 자연스럽게 트래픽 증가로 이어집니다. 트래픽이 증가하면 판매자가 늘어나고, 이에 따라 고객들이 선택할 수 있는 상품의 폭도 넓어지게 됩니다. 이 모든 요소는 서로 맞물려 작동하며, 기업과 서비스의 성장을 가속화하는 선순환 구조를 완성합니다.

따라서 FinOps는 단순히 비용을 절감하기 위한 활동에 그치지 않습니다.
이는 비즈니스 관점에서 비용 최적화라는 행위를 통해 고객 경험을 개선하고, 나아가 서비스 및 기업 성장에 기여하는 전략적 활동이라고 볼 수 있습니다.

앞서 우리는 FinOps의 핵심이 비즈니스를 고려하며 가치를 극대화하는 데 있음을 강조했습니다. 이제 "비즈니스를 고려한다는 것"이 무엇을 의미하는지, 구체적인 사례를 통해 살펴보겠습니다.

비즈니스를 고려하지 않은 비용 절감 접근

FinOps를 단순히 비용 절감의 관점에서 바라본다면, 첫 번째 차트처럼 클라우드 비용 변화 추이에만 초점을 맞춰 분석할 수 있습니다. 해당 그래프는 A, B, C 기업의 지난 5년간 클라우드 비용 변화를 보여줍니다.

이 관점에서 바라보면 B 혹은 C 기업이 효과적으로 FinOps를 수행한 것으로 해석될 가능성이 높습니다. 이유는 비용이 감소하거나 일정 수준에서 유지되고 있기 때문입니다. 하지만 이들이 실제로 FinOps를 가장 효과적으로 수행한 기업이라 말할 수 있을까요?

비즈니스를 고려한 비용 최적화 접근

IT 서비스의 핵심 목표 중 하나는 트래픽 증가입니다. 트래픽은 매출과 직접 연결되기 때문에 매우 중요한 지표인데요. 이를 반영해 트래픽 데이터를 추가하고 분석을 확장한 결과가 두 번째 차트에 나타나 있습니다. 빨간색 선은 인입 트래픽의 변화 추이를 나타냅니다.

분석 결과 A 기업은 클라우드 비용이 증가했지만, 트래픽 증대 효과가 그 비용 증가를 상회하는 수준을 보였습니다. B 기업은 유지된 클라우드 비용에도 불구하고 트래픽이 감소하면서 성과가 악화되기 시작했고, C 기업은 클라우드 비용과 트래픽의 증감 추이가 유사하게 비례했습니다.

비용과 트래픽 모두를 고려하면 어떤 기업이 FinOps를 잘 수행했다고 생각하시나요?

마지막으로, 세 번째 차트에서는 "트래픽 1건당 클라우드 비용(= 클라우드 비용 ÷ 트래픽 수)"이라는 새로운 단위 지표를 도출했습니다. 이는 트래픽 처리 단가를 나타내는 지표로, 값이 낮을수록 비용 효율성이 높은 것으로 평가할 수 있습니다.

결과적으로 A 기업은 단위 비용 측면에서 가장 효율적인 FinOps 전략을 구현한 사례로 평가되었습니다. 초기 분석에서는 단순히 클라우드 비용 증가만 바라봤을 때 A 기업의 FinOps가 실패한 것처럼 보였지만, 트래픽 데이터와 단위비용을 함께 고려하자 성과의 방향성이 완전히 바뀐 것을 알 수 있습니다.

이를 통해 FinOps는 단순히 비용 절감 이상으로, 비즈니스 성과와 연계된 분석이 필요하다는 점을 확인할 수 있습니다.

비즈니스를 고려하는 FinOps란

이 사례는 비즈니스를 고려하며 비용 최적화를 이루는 접근 방식을 보여줍니다. 단순한 비용 감축이 아닌, 비즈니스 성장과 클라우드 비용의 상관관계를 분석하고, 단위비용의 효율성을 측정하는 것, 바로 이것이 진정한 FinOps의 방향성입니다.

예를 들어 트래픽이 급증하여 클라우드 비용이 2배로 증가하였음에도 불구하고, 트래픽은 16배, 매출은 8배 증가한 상황을 가정할 수 있습니다. 이 때 단순히 클라우드 비용이 2배 증가했다는 점에만 주목하여 추가 비용 절감을 모색할 것인지, 아니면 클라우드를 비즈니스 성장의 핵심 수단으로 활용하여 트래픽을 16배 증가시키고 매출을 8배 성장시키는 데 기여했으며, 동시에 트래픽 1건당 처리 비용을 25% 최적화했다는 점을 강조할 것인지에 대한 선택은 FinOps 담당자의 몫입니다.

우리는 두 가지 중 후자를 선택했습니다. 비용 절감보다 성장과 효율성을 함께 본다는 관점이죠. 이것이 FinOps의 본질과 목표에 더 가깝다고 생각합니다. 단순히 비용 증가만을 따로 떼어 평가하면 전체적인 상황을 이해하기 어렵습니다. 비즈니스 지표를 함께 추적하며 상관관계를 분석하고 클라우드 운영의 효율성을 측정해보는 접근법을 제안합니다. 이는 단순한 비용 절감의 논리를 넘어 비즈니스 성장을 고려한 전략적 비용 최적화를 가능하게 합니다.

단위경제와 FinOps KPI

FinOps에서는 단위경제(Unit Economics)가 핵심 개념입니다. 위 사례에서 언급된 "트래픽 1건 처리 비용(클라우드 비용 / 트래픽 수)"은 이를 설명하는 대표적인 방식 중 하나입니다. 클라우드 비용과 비즈니스 성과 간 상관관계를 정량적으로 분석함으로써 효율성과 가치를 평가하는 방법입니다.

저희는 FinOps KPI를 설계할 때 주로 단위경제를 활용하며, 이는 기업의 업종과 특성에 맞춰 다양하게 적용 가능합니다. 예를 들어 전사적인 FinOps KPI는 다음과 같은 형태로 설정될 수 있습니다.

주문 1건 처리 비용
= 클라우드 비용 ÷ 주문 수
배송 1건 처리 비용
= 클라우드 비용 ÷ 배송 수
Page view 1건 처리 비용
= 클라우드 비용 ÷ Page view 수
매출 대비 클라우드 비용 비율
= 클라우드 비용 ÷ 매출

이러한 단위경제 기반의 지표들은 클라우드 비용 효율성을 비즈니스 성과와 연결시켜 평가하는 도구로 매우 유용하며, FinOps의 최종 목표인 비즈니스 가치 극대화의 기반이 됩니다.

이 목표를 달성하기 위해 조직 차원의 접근이 필수적이며, 특히 개발팀에게 KPI를 설정할 때 좀 더 구체적이고 기술적인 기준을 활용하는 것이 중요합니다. 각 개발팀에 부여할 KPI는 아래와 같은 방식으로 세부적으로 나눠 설정할 수 있습니다.

리소스 탄력성
= 팀의 시간 단위 리소스 변동량과 처리 트래픽 건수 간의 상관관계를 수식화
트래픽 1건 처리 비용
= 팀의 클라우드 비용 ÷ 팀이 처리한 트래픽 건수 (ELB Request Count 등)
트래픽 1GB 처리 비용
= 팀의 클라우드 비용 ÷ 팀이 처리한 트래픽 데이터 양 (DataTransfer in/out Bytes 등)
조직의 핵심 트랜잭션 1건 처리 비용
= 팀의 클라우드 비용 ÷ 핵심 트랜잭션 처리 건수 (주문개발팀: 주문 처리 건수, 검색개발팀: 검색 건수 등)

그러면 FinOps KPI를 단순히 비용 절감액으로 설정했을 때 어떤 문제가 발생할 수 있을까요?

사례 1
A팀은 매년 꾸준히 서비스를 최적화해왔지만, 운영 서비스의 규모와 SLA가 높은 탓에 비용이 상대적으로 크고, 반면 B팀은 최적화에 관심을 두지 않으면서도 운영 서비스의 규모가 작아 비용이 적게 발생합니다. 결과적으로 매년 최적화 목표가 A팀에만 집중적으로 할당됩니다. 이러한 접근 방식이 과연 공정하며 지속 가능한 방법일까요?

사례 2
C팀은 전월까지 100원이었던 비용이 이번 달부터 서비스 확장으로 인해 500원까지 증가했습니다. 이후에도 단순히 400원의 비용 증가를 이유로 지속적인 비용 절감 압박을 받아야 했습니다. 이러한 방식이 올바른 방향일까요?

이때 단위경제를 활용하면 이러한 문제를 보다 효과적으로 해결할 수 있습니다. 예시를 통해 살펴봅시다.

개선된 사례 1
트래픽 1건 당 처리 비용을 분석해보니 다음과 같은 결과가 도출되었습니다.

(A팀) API 건당 처리 비용 → 1원 = 클라우드 비용 500원 ÷ API 처리 건수 500건
(B팀) API 건당 처리 비용 → 5원 = 클라우드 비용 50원 ÷ API 처리 건수 10건
그동안 비용 최적화를 신경 쓰지 않았던 B팀은 A팀에 비해 API 건당 처리 비용이 5배 높은 원인을 파악하게 됩니다. 조사 결과 B팀은 트래픽 기반 Scale-in/out 정책을 설정하지 않아 비효율이 발생했습니다. 물론 API 특성에 따라 차이는 있겠지만 이처럼 단위경제를 활용하면 서비스 규모에 따른 운영비용 격차를 조정하고, 팀 간 비교 및 개선 방향을 도출할 기회가 생깁니다.

개선된 사례 2
데이터 분석 결과 C팀은 서비스 확장 이후 기존보다 10배 더 많은 API를 처리하고 있었습니다. 증설 과정에서 최적화를 통해 효율성을 개선했으며, 결과적으로 API 건당 처리 비용은 기존 대비 50% 감소한 것을 확인했습니다. 이제는 400원의 비용 증가에 대해 압박받지 않았죠.

이처럼 단위경제는 비즈니스와 클라우드를 접목하여 효율성을 측정할 수 있는 기준을 제공합니다. 전 조직 단위에서는 매출 증가를 지원하는 핵심 비즈니스 지표(주문 건수, PV 등)를 활용하는 것이 적합하며, 개발팀에서는 팀에서 담당하는 주요 API 처리 건수나 트래픽 처리 용량을 기반으로 설정하는 방식이 효과적입니다.

FinOps KPI와 개발팀 간 효과적인 소통

단순히 비용 절감을 목표로 설정하여 전달하는 것이 효과적인 경우도 있습니다. 특히 기업이 급격히 성장하는 동안 한 번도 비용 최적화를 고려해보지 않았던 경우라면 이런 접근이 이해될 수 있습니다. 하지만 조직이 반복적으로 비용 절감이라는 단순 목표를 부여받게 되면, 결국 구성원의 업무 동기가 점차 낮아지는 문제가 발생합니다.

이유는 명확합니다. 조직은 이미 매년 비용 최적화 작업을 수행했음에도 불구하고, 지속적으로 가용성, 성능, 품질을 고려할 시간조차 주어지지 않은 채 같은 비용 절감 목표만 다시 부여받습니다. 게다가 설정된 절감 목표의 근거조차 불투명하다면, "왜 우리가 이 작업을 여전히 해야 하는가?"라는 의문이 자연스럽게 생깁니다.

제 경험으로 볼 때, 개발팀과의 소통에서는 단순한 비용 감축 대신 단위 경제 기반 데이터를 활용하는 것이 훨씬 효과적이었습니다. 예를 들어, "개선된 사례 2"처럼 팀이 과거부터 현재까지 API 1건당 처리 비용의 추이를 보게 되었을 때, 처리 효율이 저하된 것이 확인된다면 개발팀은 이것이 발생한 원인을 엔지니어링적으로 분석하기 시작했습니다.

비용 추이가 계속 증가한다는 자료만 제시했을 때는 신규 서비스 출시, 시스템 증설, 데이터 이관 작업 등이 원인이라고 말하며 문제 해결에 적극적이지 못했던 것과는 매우 다른 반응이었습니다.

두 가지 접근법을 비교해 보면, 각각의 메시지는 다음과 같이 전달됩니다.

"비용이 과거에 비해 1억 원 증가했으니 5천만 원이라도 절감 가능할까요? 검토 부탁드립니다."
"서비스 확장으로 비용이 상승한 것은 자연스러운 결과입니다. 하지만 리소스의 처리 효율성을 유지하는 것은 중요합니다. 증가한 API 1건당 처리 비용을 이전 수준으로 최적화할 수 있도록 검토 부탁드립니다."

어떤 방식이 더 설득력 있으며, 개발팀의 엔지니어링적 도전 의식을 불러일으킬 수 있을까요? 물론 후자의 접근이 반드시 최선이라고 단언할 수는 없지만, 경험상 전자의 방법보다는 훨씬 효과적으로 개발팀과 협력할 수 있었습니다.

결론적으로 FinOps의 핵심은 개발팀과 조율하는 데 있으며, 그들이 이 작업을 왜 실행해야 하는지를 명확히 이해시켜야만 효과적인 협업이 가능해집니다. 이러한 관점에서 단위 경제를 활용한 FinOps KPI는 개발팀과의 소통을 더 원활하게 만드는 데 실질적인 도움이 될 것입니다.

저희가 정의하는 FinOps의 개념과 중요성을 설명드렸습니다. 이번에는 FinOps 활동을 통해 얻은 성과를 구체적으로 보여드리겠습니다.

저희는 여러 차례 외부에서 FinOps 성과를 발표하며 이를 공유해왔고, 항상 단위 경제를 기반으로 한 FinOps KPI 관점에서 결과를 제공해왔습니다. 이제 이 글을 읽으신 여러분께서는 왜 우리가 이러한 방식으로 성과를 공유했는지를 충분히 이해하실 수 있으리라 믿습니다.

2022년 말 FinOps를 본격적으로 착수한 이후, 주요 지표들에서 모두 개선된 결과를 확인할 수 있었습니다. 전사적으로 가장 많은 관심을 기울이고 있는 3가지 FinOps KPI는 다음과 같습니다.

주문 1건 처리 비용
트래픽 1건 처리 비용
매출 대비 클라우드 비용 비율

이 중 가장 중요하게 고려하는 요소는 주문 1건 처리 비용입니다. 주문은 매출을 창출하는 핵심 지표로, 주문에 이르는 모든 과정의 효율성을 최적화하는 것이 가장 중요하다고 판단하고 있습니다.

또한 트래픽 1건 처리 비용도 분석하고 있습니다. 주문은 고객 경험의 최종 결과물이기 때문에, 그 과정이 반영된 지표도 필요한 것으로 보고 있습니다. 예를 들어, 고객이 장바구니에 음식을 담았으나 최종적으로 주문까지 이어지지 않았다고 해도, 메인 화면 접속이나 음식 검색, 장바구니 담기 과정에서 서비스 트래픽이 발생하기 때문에 이를 측정하는 것이 중요합니다. 트래픽은 다양한 방식으로 산출되며, AWS 기준으로는 CloudFront Request 건수와 Public ELB Request 건수 등을 활용하고 있습니다.

마지막으로 매출 대비 클라우드 비용을 보조적으로 살펴보고 있습니다. 이 지표는 앞서 언급한 핵심 지표만큼 중요하지는 않지만, 클라우드 비용의 증가가 회사의 비즈니스 성장 대비 지나치게 가파르지 않은지를 확인하기 위한 목적으로 활용되고 있습니다.

앞서 우리가 고민한 FinOps의 개념과 그 결과를 공유했습니다. 이제 실제로 FinOps를 실행하며 어떤 과정을 거쳤고, 어떤 고민들이 있었는지 자세히 살펴보겠습니다.

우리가 적용한 FinOps Framework와 The Frugal Architect를 먼저 소개합니다.

FinOps Foundation의 FinOps Framework

FinOps 분야에서 가장 대표적인 프레임워크로 꼽히는 것이 바로 FinOps Foundation의 FinOps Framework입니다.

일반적으로 외부에서 FinOps를 설명할 때 자주 언급되는 것이 이 프레임워크의 Inform → Optimize → Operate 단계로 구성된 순환 구조입니다. 이는 정보를 가시화하고, 최적화하며, 조직 변화를 통해 이를 운영하라는 방향성을 제시합니다.

하지만 이러한 단계들은 실무자 입장에서 보면 다소 추상적이고 상위 개념에 가까운 특징이 있습니다. How와 What에 대한 구체적인 내용은 포함되지 않은 것이죠. 그렇기 때문에 FinOps를 실질적으로 실행할 때는 해당 프레임워크의 Domain과 Capability 영역에 집중하는 것이 중요합니다. 이는 일종의 기능 명세서 역할을 하며, 실행 과정을 체계적으로 지원합니다.

아래의 이미지는 FinOps Foundation Framework의 전체 개요를 보여줍니다. 이미지 우측 하단에서는 네 개의 주요 Domain과 22개의 Capability가 명시되어 있으며, 각 요소는 상세한 정의와 구현 방법을 안내합니다.

FinOps Framework 개요
(출처: FinOps Framework by FinOps Foundation)

예를 들어 "Understand Usage & Cost" 영역의 Allocation 기능에는 다음과 같은 내용이 포함됩니다. 이 부분은 편의를 위해 일부 발췌하여 번역했습니다.

Capability 정의
각 조직의 담당자에게 클라우드 비용(직접 비용 및 공유 비용)을 배분하는 방법

조직별로 비용을 부과하는 전략 : CMDB 연동, Showback과 Chargeback 정의
태그 설정 및 메타데이터 전략 : 계정 단위 리소스 분리, 표준화된 태그 명명 규칙 등
공유 비용 배분 전략 : 중앙 플랫폼 비용, 네트워크 비용, 지원 비용 등 배분 방식

측정 KPI

조직 단위로 할당된 비용 비율
태그 지정되지 않은 비용 비율
배포 단계에서 태그가 누락된 비율
메타데이터 정확도 비율

성숙도 진단:

Crawl 단계
- 전체 비용 중 약 50%만 배분 가능, 공유비용은 세금·지원 등 단순 항목만 처리
- 계정·프로젝트 단위의 단순 비용 배분, 태깅 불일치·누락 많음
- CSP 기본 툴 활용, KPI는 수동 관리, 개발팀은 직접비용만 인식
Walk 단계
- 전체 비용의 75% 배분 가능, 서비스 단위까지 구체적 할당
- 문서화된 할당·태깅 전략 존재, 주요 영역은 일관되지만 전체 적용은 미흡
- 공유비용 분배 모델 도입, KPI 이해했지만 자동화는 미흡
Run 단계
- 전체 비용의 75%-100%를 세밀하게 배분, 태깅·메타데이터 자동화 정착
- 실시간에 가까운 분석·자동화 체계로 KPI와 비용 할당 관리
- 개발·재무 모두 비용 전반을 인지하며, Chargeback/Showback 완전 수행

할당과 분배라는 Capability의 정의와 관련해 무엇을 고려해야 하는지, 결과를 측정하는 KPI는 무엇인지, 그리고 회사의 성숙도를 어떻게 평가할 수 있는지가 기술되어 있습니다.

이를 기반으로 각 Capability를 구체적으로 구현해야 합니다. 위 이미지에 제시된 예시를 참고해 간단한 작업 단계를 고민할 수 있습니다.

Tagging의 표준화는 어떻게 설정해야 할까? 또한 이를 CMDB와 연계할 수 있는 방법은 무엇일까?
조직의 비용을 정확히 할당하기 위해 CMDB가 반드시 필요한가? 그렇다면 우리 내부의 CMDB 시스템은 제대로 운영되고 현행화되고 있는가?
우리 조직에는 Showback과 Chargeback 방식 중 어떤 모델이 더 적합할까? 만약 Showback을 선택한다면, 이를 성공적으로 구현하기 위해 어디서 시작해야 할까? 각 부서가 정확한 비용을 쉽게 이해하도록 하기 위한 방법은 무엇일까?
플랫폼의 중앙 배포 및 모니터링과 같은 공통 자원들은 공유 비용으로 분류해야 하는가? 공유 비용으로 설정한다면, 이를 개별 서비스에 어떻게 공정하게 분배할 것인가? 또한, 기술적으로 Tagging이 지원되지 않는 비용(예: CloudWatch GetMetric API 등)은 어떤 방식으로 처리해야 할까?
현재 조직까지 할당 가능한 Tagging 비율은 몇 %이고, 궁극적으로 달성하고자 하는 목표 수치는 얼마로 설정할 것인가?

이러한 고민을 거쳐 FinOps Foundation Framework를 효과적으로 활용하여 FinOps 플랫폼을 직접 구축했습니다. 모든 Capability의 명세서를 철저히 검토하며, 우리에게 필요한 기능과 구현 방향을 세심하게 고민했습니다.

만약 처음 시작 단계에서 방향성 설정이나 업무 누락이 걱정된다면, FinOps Framework에 대한 이해를 바탕으로 특히 Capability 항목을 적극적으로 참고하는 것을 추천합니다. Framework는 명확한 지침과 구조를 제공해줄 뿐만 아니라 조직의 목적에 맞는 효율적인 실행 기반을 마련하는 데 도움을 줄 것입니다.

Amazon의 The Frugal Architect: 비용 인지 아키텍처의 중요성

2023년 AWS re:Invent 행사에서 Amazon CTO Dr. Werner Vogels는 비용 인지 아키텍처(Cost-aware Architecture)와 FinOps의 7가지 원칙을 발표했습니다. 그는 비용을 아키텍처 설계에서 주요 고려 요소로 삼아야 한다는 점을 강조하며, 지속 가능하고 효율적인 시스템 구축 방법론을 설명했습니다. 아래는 7개의 주요 원칙에 대한 요약입니다.

비용도 성능, 보안, 확장성처럼 아키텍처의 설계의 중요한 기준으로 삼아라.
오래 가는 시스템은 기술적으로 잘 만든 시스템이 아니라, 비즈니스 목적과 맞물린 비용 구조를 갖추고 있다.
아키텍처 설계는 늘 Trade-off이다. 성능, 안정성, 비용 사이에서 현명한 균형을 찾아야 한다.
보이지 않으면 알 수도 없다. 가시성이 곧 통제력이다.
태깅, 오토스케일링 등 비용 통제 장치를 포함하여 설계한 시스템은 돈이 낭비되는 것을 막을 수 있다.
비용 최적화는 한 번에 끝나는 일이 아니다. 지속적으로 관찰하고 조정해나가야 한다.
시스템이 잘 운영되고 있다해서 비용까지 최적인 것은 아니다. 항상 수치를 검증하라.

7개의 원칙을 살펴보면 FinOps Foundation Framework와 유사한 점이 상당히 많음을 알 수 있습니다. 이를 통해 비용을 고려한 비즈니스 중심의 아키텍처 설계, 비용의 측정·가시화·관찰의 중요성, 최적화의 점진적인 접근 방식 등 여러 핵심 요소를 재확인할 수 있습니다.

그중에서도 특히 인상 깊었던 사례 두 가지를 추가로 공유하고자 합니다.

전기계량기 위치 비교
(출처 : Amazon The Frugal Architect)

첫 번째는 비용 인지 문화를 강조하는 데 활용된 전기계량기 사례입니다.
이미지에 나와 있는 두 건물 중 왼쪽은 3000kWh를 사용했지만, 오른쪽은 2000kWh만 사용했습니다. 이 차이를 분석해보니, 왼쪽 건물은 전기계량기가 지하에 있어 거주자들이 전력 사용량을 제대로 인식하지 못했던 반면, 오른쪽 건물은 1층에 전기계량기를 설치해 거주자들이 실시간으로 전력 소비를 관찰할 수 있었습니다. 이 사례는 측정과 관찰이 가능해야 최적화를 실행할 수 있다는 점을 명확히 보여줍니다.

단위경제와 요청 비용 분석
(출처 : Amazon The Frugal Architect)

또 다른 사례는 Amazon의 단위경제 및 FinOps KPI와 관련된 내용입니다.
Amazon은 Microservice 단위로 처리된 요청 수와 비용 간의 상관관계를 추적하며, 이를 단위 경제로 환산해 요청 처리 비용의 감소 추세를 발표했습니다. 이는 단순히 비용 절감만이 아니라, 효율성을 제대로 측정하는 것이 얼마나 중요한지를 보여주는 대표적인 사례라 할 수 있습니다.

물론 이 외에도 다양한 사례가 있지만, 더욱 상세한 내용을 확인하기 위해서는 YouTube 영상이나 The Frugal Architect 웹사이트를 직접 접속해보는 것을 권장합니다. 비록 FinOps Foundation Framework의 Capability 수준까지 구체적인 구현 방법을 다루진 않더라도, FinOps 수행에 있어 매우 유용한 원칙과 실제 사례를 제공한다는 점은 분명합니다.

2개 프레임워크를 기반으로 한 실제 기능 구현

위에서 언급된 두 개의 프레임워크를 바탕으로 다양한 결과물이 도출되었습니다:

FinOps 플랫폼 구축
비용 인지 아키텍처 및 문화 구현
비용 최적화를 통한 FinOps KPI 지표 개선

아래에서는 이러한 두 프레임워크를 실제로 어떻게 활용했는지, 그리고 이를 기반으로 어떤 결과물을 만들어냈는지를 소개하겠습니다.

이제부터는 앞서 언급한 두 가지 프레임워크를 기반으로 직접 구현한 결과물을 소개하겠습니다. FinOps 성숙도를 향상시키기 위해 해당 프레임워크를 어떻게 활용했는지, 그리고 이를 통해 어떤 결과를 도출했는지 자세히 설명드리도록 하겠습니다.

FinOps 플랫폼 구축

우리는 더 나은 FinOps 활동의 실행을 위해 자체적인 FinOps 플랫폼을 구축하였습니다. FinOps의 핵심 Capability를 구현하기 위해 내부 데이터를 자유롭게 연동하고 분석하여 인사이트를 도출하는 FinOps Data Lake 구성의 필요성을 느꼈습니다. 기존 상용 FinOps 솔루션은 외부 데이터 연동 및 커스터마이징에 제한이 많아 우리의 요구를 충족하지 못했습니다.

이미지는 현재 FinOps 플랫폼에서 수집하는 데이터와 이를 기반으로 구현된 FinOps Capability를 나타내고 있습니다. 이를 통해 플랫폼의 주요 역할을 확인할 수 있습니다. 이제 Capability별로 구현된 내용을 자세히 살펴보겠습니다.

FinOps Capability 중심의 플랫폼 구현

데이터 수집

통합 데이터 수집: 청구데이터 원본인 CUR 외에도 CMDB, 주문수, AD 조직정보 등 10개 이상의 데이터를 한곳으로 모아 FinOps Data Lake 역할을 수행합니다.
데이터 가공: 원본 청구데이터의 태그를 기준으로 CMDB 및 AD에서 조직 정보를 끌어와 연결합니다. RI/SP 할인의 금액을 공정하게 배분하도록 비용을 커스터마이징합니다.
데이터 경량화: 청구데이터는 기본적으로 시간 단위로 이루어지며, 컬럼 수가 300개 이상, 데이터 건수는 억 단위에 달합니다. 이를 효율적으로 경량화하기 위해 시간/일/월 단위로 통계화하고 필수 컬럼만 선별하여 데이터 규모를 최소화합니다.

할당/분배

조직별 비용 할당: 가공된 청구데이터를 기반으로 운영팀 단위로 비용을 할당하며, 대표이사부터 파트까지 원하는 조직 레벨로 비용을 확인할 수 있습니다.
RI/SP 할인액 분배: RI/SP 할인이 공정하게 배분되는 커스터마이징된 비용 값을 활용합니다.
다양한 비용 보기 옵션 제공: 서비스, 운영 환경, 단위 손익 등 원하는 단위로 비용을 볼 수 있도록 지원합니다.
공유 자원 비용 배분: 중앙 모니터링 플랫폼 비용을 각 개발팀의 사용량에 따라 균등하게 배분하고 이를 개발팀의 비용에 포함시켜 제공합니다.
태깅 미지원 서비스 처리: 태깅이 지원되지 않는 서비스는 해당 운영팀을 식별하여 청구데이터 상에서 귀속시킵니다.

보고 및 분석

조직별 주간/월간 비용 메일 발송: 조직 단위로 집계된 주간 및 월간 비용 데이터를 제공하며, 이를 공유합니다.
FinOps 대시보드 제공: 조직별로 단위경제 관점에서 분석할 수 있는 대시보드를 구축했습니다.

이상 현상 관리

조직별 이상탐지 메일 발송: 조직별로 집계된 청구데이터에서 이상 현상이 발생할 경우 즉각적으로 해당 조직에 알림 메일을 발송합니다.
실시간 이상 탐지 및 슬랙 알림: 청구데이터보다 신속한 이상탐지를 위해 AWS CLI를 활용하여 인스턴스를 10분 단위로 실시간 모니터링하고 추가적인 이상 탐지를 수행합니다.

단위 경제학

주문 처리 비용 모니터링: 수집된 주문 데이터를 기반으로 조직 전반의 주문 1건 처리 비용을 모니터링하고, 대시보드를 제공합니다.
트래픽 효율 분석: 각 팀별 트래픽 데이터를 통해 조직별 트래픽 1건 처리 비용과 효율성을 평가하고, 대시보드를 제공합니다.
비효율 발굴: 모든 데이터를 시간 단위까지 분석하여 비효율을 찾아냅니다.

예측

미래 비용 예측: ML Toolkit 및 자체 로직을 활용해 다양한 형태의 미래 비용 예측을 수행합니다. 이를 통해 예산 관련 결정과 커뮤니케이션 과정을 지원합니다.

예산 편성

단위경제 기반 전략: 주문 1건 처리 비용 목표와 예상 주문수를 곱하여 차년도 예산을 산정하는 방식으로 예산 편성 전략을 세웁니다.
워크로드 계획 포함: 주요 워크로드의 신규 도입 및 제거 계획도 예산에 반영됩니다.
예산 초과 여부 관리: 슬랙 알림 시스템을 통해 매일 예산 초과 여부를 모니터링합니다.

FinOps 플랫폼의 주요 Capability별 역할을 간략히 정리했습니다. 그렇다면 플랫폼을 구축한 후 어떤 점이 개선되었을까요? 대표적으로 아래와 같은 사항들이 실현되었습니다.

FinOps 플랫폼 도입 후 주요 개선사항

조직별 클라우드 비용 자동 조회
CMDB의 조직 정보를 Tag와 연결하고, 사용자가 소속한 조직의 비용만 자동으로 필터링하여 보여줍니다. 이제 더 이상 Tag를 수작업으로 필터링할 필요 없이 간편하게 조직별 비용을 확인할 수 있습니다.
청구 데이터(CUR) 맞춤 가공
내부 FinOps 정책에 따라 CUR을 자유롭게 편집할 수 있습니다. 예를 들어 RI/SP 할인 금액을 조직 간 공정하게 배분하거나, Tagging이 불가능한 특정 서비스에도 임의로 Tag를 추가하는 기능을 지원합니다.
단위 경제 및 FinOps KPI 활용
단위 경제는 비즈니스 지표와 밀접하게 연관되므로, 시중의 FinOps 도구로는 이를 처리하기 어려웠습니다. 외부 데이터와의 연계가 제한적이거나 원하는 방식으로 계산할 수 없는 상황도 많았습니다. 이제는 주문 수, 예산, 배포 이력 등 다양한 비즈니스 지표를 가져와 필요에 맞게 분석하고, FinOps KPI 기준으로 대시보드를 구성할 수 있습니다.
FinOps Data Lake 완성
FinOps 관련 데이터를 한곳에 통합하여 분석이 용이해졌습니다. 클라우드 비용 증감의 원인을 체계적으로 파악할 수 있게 되었으며, 기존에는 발견하지 못했던 새로운 인사이트를 도출할 기반도 마련되었습니다.
내/외부 시스템 연계성 개선
내부 시스템에서 필요한 비용 정보를 FinOps 정책에 맞게 가공하여 제공할 수 있게 되었으며, 외부 SaaS 플랫폼과의 연동도 훨씬 유연해져 FinOps 데이터 활용성과 커뮤니케이션의 선택 폭이 확대되었습니다.
비용 원화 환산 기능 지원
FinOps 플랫폼은 비용을 원화 단위로 조회할 수 있는 기능을 제공합니다. 달러 금액을 머릿속에서 환산하는 번거로움을 해소하고, 현실적으로 와닿는 비용 표현을 가능하게 했습니다. 예를 들어, $80,000 대신 1억 1,200만 원으로 표시해 더욱 직관적인 이해를 돕습니다.

비용 인지 아키텍처 및 문화 구현

FinOps 플랫폼을 구축하여 이전보다 FinOps 성숙도를 높이는 데 성공했지만, 여전히 전체 조직의 비용 인식 수준을 향상시키는 데 있어 한계를 느꼈습니다. 이는 일부 조직이 클라우드 비용에 대한 관심이 부족하거나, 각 개발팀에 명확한 클라우드 예산이 배정되지 않아 대시보드를 직접 확인하지 않는 경우가 많았기 때문입니다.

Amazon The Frugal Architect에서 소개된 전기계량기 사례처럼, 사용자들에게 비용을 지속적으로 피드백할 수 있는 시스템의 필요성을 절실히 느꼈습니다. 실제로 아래와 같은 질문을 던지면, 대부분의 팀이 정확하게 대답하기 힘든 상황이었습니다.

"소속된 조직의 클라우드 비용이 월 얼마 정도인지, 최근 증감 추이가 어떠한지 알고 계신가요?"

이에 따라 저희는 모든 조직이 클라우드 비용을 명확히 인식할 수 있도록 비용 인식 아키텍처를 설계하고자 했습니다. 이를 실현하기 위해 FinOps 플랫폼의 기능을 활용해 다음의 세 가지 접근 방식을 구현하였습니다. 이제 이를 공유해 보겠습니다.

조직별 클라우드 비용 주간/월간 공유 메일
조직별 클라우드 비용 이상탐지 메일
전사 일간 클라우드 비용 알림 슬랙

조직별 클라우드 비용 주간/월간 공유 메일

이 메일은 각 조직의 AWS 비용 데이터를 주기적으로 공유하며 피드백을 제공하기 위해 설계되었습니다. FinOps 플랫폼에서 계산된 조직별 데이터에 기반해 조직 계층을 생성하고, 이를 집계하여 메일로 발송합니다.

예시로 A 조직 산하에 B팀, C팀, D팀이 있으며, 각각의 비용이 100원, 200원, 300원이라면,

A 조직은 하위 조직의 총 사용 비용인 600원에 대해 메일을 수신합니다. 이 메일에는 하위 조직(B팀, C팀, D팀)의 모든 비용, 증감내역이 포함됩니다.
B팀, C팀, D팀은 자신의 팀에서 발생한 비용만 분석된 메일을 받습니다.

이를 위해 CMDB와 AD 조직 정보를 결합하여 운영팀 정보 및 상위/하위 조직 구조를 체계적으로 정리했습니다.

현재 전사의 모든 조직은 매주와 매월 간격으로 해당 비용 데이터를 이메일로 수신하고 있으며, 다음과 같은 정보를 포함합니다.

이전 주와 이전 월 대비 증감 비용, 증감을 발생시킨 서비스 태그 Top 3
장기적인 추세 분석을 위한 3개월 평균 비용 대비 증감 서비스 태그 Top 3
FinOps 플랫폼 상세 분석 대시보드 링크

이를 통해 사용자는 간단히 비용 증가 추세와 원인을 파악할 수 있으며, 이메일 하단의 "데이터 자세히 보기" 버튼을 눌러 FinOps 플랫폼 대시보드로 이동하여 상세 데이터를 확인할 수도 있습니다.
다음은 실제 메일 화면 예시입니다.
메일 주간 비용 공유

조직 클라우드 비용 이상탐지 메일

FinOps 비용 이상탐지 메일은 조직의 클라우드 비용에서 유의미한 증가가 감지된 경우 이를 즉각적으로 알리기 위해 발송됩니다.

이상의 조기 탐지는 비용 문제를 신속히 인식하고 해결하는 것이 핵심입니다. 일반적으로 각 팀은 주간 혹은 월간 단위로 비용 알림 메일을 받게 되지만, 이 방식은 이상 비용 대응 관점에서는 지연을 발생시킵니다.

이에 따라 매일 AWS CUR을 점검하여 특이사항이 발견되면 해당 조직에 즉시 이메일을 발송합니다. 오늘 발생한 비용이 전 주 동일 요일의 금액 대비 특정 임계치를 초과하게 되면 바로 알림이 제공됩니다. 이상현상이 팀의 의도된 업무가 아닌 경우에는 빠른 조치가 필요합니다.

더불어 이메일에는 증가한 비용의 주요 원인을 빠르게 확인할 수 있도록 특정 증가에 기여한 상위 3개 서비스 목록을 함께 표시합니다. 추가 분석이 필요할 경우, 하단의 "데이터 자세히 보기" 버튼을 클릭해 FinOps 플랫폼 대시보드로 이동, 비용 추이와 증감 원인을 보다 상세히 파악할 수 있습니다.

다음은 실제 메일 화면 예시입니다.

전사 일간 클라우드 비용 알림 슬랙

전사의 클라우드 비용 정보를 통합하여 슬랙 채널에 공유하는 방식입니다.

매일 전사의 클라우드 일별 비용을 모니터링함으로써 현재 추세를 기반으로 당월 비용을 예측하고 예산 초과 여부를 파악할 수 있습니다. 이와 함께 증감 원인 분석 링크를 통해 오늘의 비용 증가 이유를 FinOps 플랫폼에서 확인할 수 있습니다.

특히, 일일 비용에서 의미 있는 변화가 발생했을 경우 스레드에서 원인을 분석하고 담당자(CTO, 개발팀, 인프라팀, 재무팀 등)와 공유합니다.

슬랙 채널은 누구나 참여할 수 있으며, FinOps 담당자 간 데이터를 투명하게 공유하고 협력적인 대응을 위해 활용됩니다.

세 가지 방법으로 얻은 성과

이번에 시행한 세 가지 활동은 비용 인지 아키텍처의 정착과 조직 내 문화 확산을 목표로 진행되었습니다. 그 효과는 점점 가시화되고 있는데, 각 개발팀이 이전보다 비용 수준에 대해 훨씬 민감해졌고, 비용의 증감 추이를 명확히 파악할 수 있게 된 것이 대표적인 변화입니다. 비용 최적화를 시행한 경우, 그 결과에 대한 피드백을 받을 수도 있죠.

물론, 장기적인 관점에서 지속적으로 모니터링해야 하겠지만, 비용에 관련된 이상 탐지 또한 점차 긍정적인 변화를 보이고 있습니다. 과거에 비해 발생 건수는 감소하고, 조치 소요 시간도 짧아지는 추세를 나타냅니다. 특히 의도치 않게 발생하는 비용 낭비(예를 들어 성능 테스트용 인스턴스를 주말 동안에도 활성화 상태로 두는 등)에 대해 빠르게 피드백을 받을 수 있어 동일한 실수가 반복되지 않는 환경이 마련되었다는 점이 의미 있습니다.

또한, 저희는 개발팀의 피로도를 최소화하면서도 비용 관리 관련 피드백을 효율적으로 전달할 방법을 끊임없이 고민하고 있습니다. 예를 들면 피드백 전달 도구로 슬랙 대신 이메일을 선택한 이유 역시 이러한 맥락에서 결정된 사항입니다. 개발팀이 업무 부하를 느끼지 않으면서도 중요한 정보를 놓치지 않도록 하기 위한 접근이라 할 수 있겠습니다.

이 모든 활동은 단순히 비용 절감이 아니라 조직 전체가 더 스마트하게 의사 결정을 내려나갈 수 있는 기반을 만드는 데 목적이 있습니다. 앞으로도 지속적인 개선과 최적화를 통해 더 높은 수준의 비용 인지 문화를 형성할 계획입니다.

비용 최적화를 통한 FinOps KPI 개선

FinOps 플랫폼을 성공적으로 구축하고 비용 인식 문화를 확산시키며 기반을 다져왔습니다. 이제는 비용 최적화에 주력해야 할 단계에 접어들었습니다. 하지만 이러한 작업은 단계를 나누어 순차적으로 진행하기보다는 병렬적으로 수행하는 것이 더 효과적입니다. 비용 최적화란 모든 데이터를 완벽히 준비된 상태에서 시작하는 것이 아니라, 현재 사용 가능한 데이터를 기반으로 점진적이고 반복적인 접근을 통해 이루어지는 과정입니다.

클라우드 비용의 계산 방식은 일반적으로 아래와 같이 정의됩니다.

클라우드 비용 = 사용량 x 단가

하지만 우리는 이를 조금 더 확장하여 두 가지 요소를 추가했습니다. 하나는 비용 이상현상에 신속하게 대응하는 역량이고, 다른 하나는 외부 지원 프로그램을 최대한 활용하는 능력입니다.

클라우드 비용 = 사용량 x 단가 – 비용 이상현상 대응 – 크레딧 및 일회성 할인 프로그램

결국 비용 최적화란 이 계산식의 네 가지 핵심 요소 중 하나 이상을 개선하거나 효과적으로 관리함으로써 달성됩니다. 이제 각 구성 요소별로 구체적인 접근 방식과 진행 상황을 함께 살펴보겠습니다.

사용량 최적화

사용량은 EC2의 사용 시간, S3의 저장 용량, 그리고 DataTransfer의 전송량 등 서비스 사용량 지표를 뜻합니다. 간단히 말해, 클라우드가 제공하는 각 제품을 얼마나 활용했는지를 측정하는 단위입니다. 이는 제품별 요금 체계에 따라 계산되어 비용 분석의 주요 기준이 됩니다.

사용량 최적화는 클라우드 관리에서 가장 까다로운 부분 중 하나입니다. 이 과정은 계약 변경이나 RI/SP 구매와 같은 비개발적인 방법으로 해결되지 않으며, 직접적으로 자원 활용도를 조정해야 한다는 점에서 어려움을 더합니다.

최적화의 가장 큰 난제는 적정 사용량을 정확히 파악하는 방법입니다. Rightsizing을 권장하거나 비활성 시간대에 워크로드를 끄라는 일반적인 조언이 있지만, 이를 현실적으로 어떻게 구현할지는 명확히 제공되지 않는 경우가 많습니다. 일부는 최근 4주간의 CPU 사용률의 Peak와 Average를 기준으로 삼고, 또 다른 일부는 Disk I/O나 NW 입출력 데이터를 분석하기도 합니다. 서비스 특성마다 접근 방식이 달라지기 때문에, 모든 상황에 적용 가능한 해답은 존재하지 않습니다.

우아한형제들에서는 전사적으로 "탄력성(Elasticity)"을 핵심 지표로 채택하여 사용량 관리를 분석하고 있습니다. 탄력성은 트래픽 변화에 따라 리소스가 얼마나 유연하게 Scale-in/out이 되는지를 평가하는 지표입니다.

위 그림에서 빨간색 선은 트래픽 양을, 파란색 선은 클라우드 리소스 사용량을 나타냅니다. 두 값이 1:1 비율로 일치한다면 이상적인 탄력적 운영이라 볼 수 있습니다. 이 접근법은 사용자가 직접 인스턴스를 관리하는 AWS 서비스(예: EC2, RDS, OpenSearch, ElastiCache 등)에 특히 적합합니다. 대부분의 기업은 이러한 서비스에서 상당한 비용을 지출하며, 동시에 가장 큰 낭비와 최적화 가능성이 존재합니다.

탄력성을 주요 지표로 삼는 데는 다음과 같은 이유가 있습니다.

절대값 기준의 최적화 가이드는 서비스 특성을 반영하지 못해 어렵고 부정확합니다.
예를 들어, CPU 사용률은 절대적인 지표입니다. 어떤 서비스는 Peak CPU가 10%만 되어도 Scale-out이 필요할 수 있고, 다른 서비스는 Peak CPU가 40%까지 가야 Scale-out이 적합할 수 있습니다. 이는 각 서비스의 특성에 따라 다르게 나타납니다. FinOps 담당자는 전사 개발팀에 최적화 가이드를 제공해야 하지만, CPU 사용률을 기준으로 권장 사항을 제시할 수 있을까요? 만약 가능하다면 몇 %를 기준으로 해야 할까요? EC2 Auto Scaling Group(ASG)을 사용하는 경우에는 평균 CPU 사용률을 기준으로 삼아야 할까요? 이런 접근법은 개발팀의 검토 부담을 크게 증가시키며 여러 문제를 초래합니다.
실제 Compute Optimizer나 Trusted Advisor에서 제공하는 Rightsizing 추천 데이터를 가지고 최적화를 요청하더라도, 검토에 많은 시간이 소요되며 실행 비율이 낮다는 점에서도 이를 확인할 수 있습니다.
서비스별 트래픽과 인스턴스 사용량의 관계를 분석함으로써 상대적 최적화 값을 도출하면, 서비스 특성이 반영되어 보다 정확한 가이드를 제공할 수 있습니다.
탄력성은 동일한 시스템에서 발생하는 트래픽과 사용량 변화를 추적하는 상대적 지표입니다. 서비스를 하나의 고정된 변수로 간주하고 시간대별 효율만 비교하기 때문에 더 이상 서비스의 특성을 따로 고려할 필요는 없습니다.

예를 들어, A라는 서비스가 있다고 가정해봅시다. 오후 6시부터 7시까지 트래픽이 가장 많을 때 c6i.2xlarge 인스턴스 10대를 활용해 총 10GB의 트래픽을 처리한다고 해봅니다. 반면, 트래픽이 가장 적은 시간인 새벽 5시에도 여전히 동일한 10대의 인스턴스를 운영하지만, 처리되는 트래픽은 단 1GB로 감소합니다. 이처럼 트래픽 변화와 인스턴스 사용량이 전혀 비례하지 않는 상태는 매우 비탄력적이라 할 수 있습니다.

이를 근거로 해당 서비스를 최적화 대상으로 식별할 수 있습니다. 오후 6시에서 7시 사이를 분석해 본 결과, 인스턴스 한 대당 최대 1GB의 트래픽을 처리할 수 있다는 사실을 확인했습니다. 그렇다면 새벽 5시에 단 1GB의 트래픽을 처리하기 위해서는 인스턴스 1대만으로도 충분하지 않을까요? 가용성을 고려한다고 하면 적어도 2~3대까지라도 Scale-in을 시도해볼 수 있지 않을까요?
물론 비정상 트래픽 발생시 방어로직은 갖춰놓았다는 전제 하에서 말입니다.

단위경제 관점에서 효율성에 집중할 수 있습니다.
단위경제로 환산하면 인스턴스당 트래픽 처리량이라는 지표를 활용하게 됩니다. 이는 단순히 비용 절감을 넘어 효율성을 개선하는 최적화 접근 방식입니다. 비용 절감만을 목표로 하지 않고, 효율성을 기반으로 분석 및 개선하는 것이 저희의 목표입니다.
탄력성 계산은 CUR 데이터만으로도 손쉽게 가능합니다.
CloudWatch와 CUR 데이터를 복잡하게 결합하지 않아도 됩니다. CUR에서는 인스턴스에 부착된 Tag를 통해 해당 인스턴스의 DataTransfer in/out bytes를 쉽게 확인할 수 있습니다. 시간 단위로 Tag별 인스턴스를 사용한 데이터와 트래픽 정보를 조회할 수 있기 때문에 모든 서비스의 탄력성을 일괄적으로 진단할 수 있고, 권장 Scale-in 수량도 간편히 산출 가능합니다.

우아한형제들에서는 전사적으로 새벽 시간 및 점심 시간에 트래픽 변화에 맞춰 자동으로 Scale-in을 수행하고 있습니다. 모든 서비스의 인스턴스 수량은 탄력성 지표를 기반으로 산출되었으며, 각 운영팀의 검증 과정을 거쳐 배포 시스템에 일괄 적용되었습니다. 그 결과 대부분의 EC2 서비스가 매일 최대 30% 이상의 자동 Scale-in을 성공적으로 진행하고 있습니다.

이외에도 제품별로 다양한 사용량 최적화 사례가 있지만, 최적화 활동의 핵심이 바로 탄력성에 있다고 믿습니다. 단순한 비용 절감보다는 비용 효율성, 즉 단위 경제를 기준으로 자원의 사용량을 최적화하는 것이 우리의 궁극적인 목표입니다.

단가 최적화

단가를 최적화할 수 있는 방법은 일반적으로 아래 세 가지로 나눌 수 있습니다. 각각의 방법에 대해 구체적으로 설명드리겠습니다.

EDP 등 클라우드 사용 계약 조건 개선
RI/SP 구매 및 커버리지 강화
제품별 단가 최적화 작업

1. EDP 계약 조건 개선

EDP(Enterprise Discount Program)는 특정 금액 이상의 클라우드 사용을 약정하고 이에 따라 할인을 받을 수 있는 계약 방식입니다. 일정 규모 이상의 비용 발생이 예상되는 경우, 최소 사용량을 약속함으로써 더 큰 할인 혜택을 누릴 수 있습니다.

EDP의 가장 큰 장점은 별도의 운영 영향을 주지 않고 대부분의 리소스에 대해 할인 혜택을 받을 수 있다는 점입니다. 일반적인 비용 최적화 작업은 운영 서비스에 영향을 미칠 가능성이 있지만, EDP는 단순히 계약 방식으로 이루어지므로 운영 안정성에 영향을 주지 않습니다.
할인율은 약정된 사용량과 계약 기간에 따라 결정되며, 이 방식은 투입 대비 효과가 가장 뛰어난 단가 절감 방법입니다.

그러나 최소 약정 사용량 조건이 있기 때문에, 실제 사용량이 약정치에 미치지 못할 경우에도 일정 금액을 지불해야 합니다. 따라서 계약 체결 시 신중한 약정 사용량 계산이 필수적이며, 최적화를 위한 유연성을 확보할 방안을 마련해야 합니다.
특히 약정 사용량에 묶여 최적화 기회를 활용하지 못하는 상황은 반드시 피해야 합니다. 이를 위해 약정 단계에서 충분한 여유량을 계산한 뒤 계약에 임하는 것이 중요합니다.

2. RI/SP 구매 및 커버리지 최적화

RI(Reserved Instances)와 SP(Savings Plans)는 인스턴스 서비스의 단가를 할인하여 비용 효율을 극대화하는 주요 프로그램입니다. 이를 구매하고 활용하는 과정은 FinOps 담당자에게 중요한 과제로, 커버리지를 최대화하면서 동시에 자원 활용률을 높이는 것이 핵심입니다.

커버리지를 확대할 때 RI/SP가 불필요하게 소비되지 않도록 활용률을 철저히 관리해야 합니다. 따라서 저희는 비용 절감을 목표로 설정된 커버리지 기준을 조정하며, 일반적으로 RI/SP의 총 커버리지는 약 70%를 목표로 삼습니다. 실제 구매는 시간대별 사용 패턴을 분석하여 최소, 평균, 최대 사용량을 산출한 뒤, 보수적으로 최소 사용량의 75~80% 수준에서 RI/SP를 구매합니다. 이를 통해 전체 평균 커버리지를 안정적으로 70%로 유지하며 낭비를 최소화합니다.

또한, 구매 전략을 유연하게 가져가기 위해 분할구매 방식을 적극 활용합니다. RI/SP의 구매 주기를 짧고 빈번하게 설정함으로써 최적화를 유리하게 가져갈 수 있습니다. 이렇게 하면 만료 시점이 계속 발생하기 때문에 사용량의 추세를 기반으로 구매량을 유연하게 조정할 수 있습니다. 예를 들어 사용량이 감소할 경우 지속 만료되는 RI/SP의 갱신 구매를 중단하고, 증가가 예상될 경우 갱신과 함께 추가 구매하는 방식입니다. 이러한 전략은 워크로드 변화와 비용 절감 목표를 반영하여 RI/SP 낭비를 줄이고 목표 커버리지를 안정적으로 확보하는 데 효과적입니다.

EC2 인스턴스의 경우 RI보다는 SP가 유리한 선택이고, Instance SP와 Compute SP를 혼합 활용하는 것이 바람직합니다. 인스턴스 패밀리마다 Instance SP와 Compute SP의 할인율 차이가 다르기 때문에 운영 환경에 맞춰 적절한 SP를 선택하는 것이 중요합니다. 일부 패밀리는 두 유형 간 할인율 차이가 약 7%로 적은 반면, 다른 경우 최대 15%까지 큰 차이가 발생할 수 있습니다. 이러한 변수에 따라 회사 환경에 최적화된 SP 선택이 비용 절감 효과를 극대화합니다.

저희는 경험과 데이터를 기반으로 효율적인 구매 전략을 지속적으로 발전시키고 있으며, [8-7. RI/SP 구매 전략] 파트에서 보다 상세한 내용을 다루고 있습니다.

3. 제품별 단가 최적화 작업 수행

이제는 계약 기반 접근 방식이 아닌 제품별 단가 최적화를 통해 비용 효율을 극대화하는 방법입니다. 대표적인 사례로 EC2의 Spot 인스턴스 활용, S3의 Intelligent Tiering 적용 등이 있습니다. 이러한 방법은 사용량(예: EC2 대수, S3 저장 용량)은 유지하면서도 단가를 할인받아 비용을 절감하는 전략을 뜻합니다. 대부분 SLA 수준을 일부 낮춤으로써 단가를 할인받는 방식이 주를 이룹니다.

단가 최적화는 탄력성처럼 명확한 핵심 지표를 설정하지 않고, 모니터링을 중심으로 진행합니다. 제품별로 단가를 월별로 추적하며 분석하는 데 초점이 맞춰져 있습니다.

예를 들어 EC2의 시간당 단가 추적을 간단히 설명해보겠습니다.

(8월) EC2 시간당 단가: 0.5원 = EC2 비용: 1,000원 / EC2 사용량: 2,000시간
(9월) EC2 시간당 단가: 0.6원 = EC2 비용: 1,500원 / EC2 사용량: 2,500시간

이를 통해 시간당 단가가 20% 상승한 것을 확인할 수 있습니다. 이에 따라 아래와 같은 원인들을 추정하고, 트러블슈팅을 시도할 수 있습니다:

RI/SP 변동 여부: 8월과 9월의 RI/SP 커버리지, 활용률 및 할인 총액 분석
EDP 계약 영향: 두 달의 EDP 할인 총액 검토
Spot 인스턴스 변동 여부: Spot 인스턴스 커버리지와 할인 총액 변화를 확인
EC2 평균 Size 증가 여부: EC2 평균 Size 변화는 정규화 요인(Normalization Factor)으로 검토
인스턴스 패밀리 사용량 변화 여부: EC2 인스턴스 패밀리별 사용량 총합 파악

의외로 단가에 많은 요소가 영향을 미치지 않나요? 이러면 총 비용 및 사용량을 위주로 분석하는 것과 크게 차별성이 없습니다.

그래서 FinOps 담당자는 이렇게 모니터링을 하는 것보다는 더 상세한 단위로 분석하는 것이 좋습니다.
CUR 및 Cost Explorer 기준으로 제품별(ProductName or ProductCode)로 UsageType까지만 보게 되더라도 좋고, Operation까지 봐도 됩니다. 이 셋의 컬럼이 결합되면 SKU와 같은 역할을 하게 됩니다.

이제 UsageType을 추가한 예시를 살펴보겠습니다:

(8월) EC2 APN2-BoxUsage:c6i.2xlarge 단가: 0.5원 = 비용: 100원 / 사용량: 200시간
(9월) EC2 APN2-BoxUsage:c6i.2xlarge 단가: 0.8원 = 비용: 200원 / 사용량: 250시간

여기서 "APN2-BoxUsage:c6i.2xlarge"는 서울(APN2) 리전에서 사용된 c6i.2xlarge 인스턴스 타입을 의미합니다. 시간당 단가가 30% 상승했음을 확인할 수 있습니다.

이에 따라 원인을 다음과 같이 추정할 수 있습니다:

RI/SP 변동 여부: 8월과 9월의 RI/SP 커버리지, 활용률 및 할인 총액 분석
EDP 계약 영향: 두 달의 EDP 할인 총액 검토

해당 분석 방식에서는 주요 원인 요소들이 대폭 축소됩니다. 특히 UsageType 값을 활용하면 인스턴스 타입이 고정되며 "BoxUsage"는 Spot 인스턴스가 아니라는 정보를 포함하고 있기 때문에 추가 변수들이 제거됩니다. 만약 Spot 인스턴스였다면 UsageType 값에 "SpotUsage"라는 항목이 표시됩니다.

그래서 FinOps 담당자는 최소 UsageType 단위로 단가 모니터링을 진행하는 것이 효과적입니다. 이를 통해 RI/SP 할인 및 EDP 할인 영향도를 쉽게 분리할 수 있고, 단가 상승 시 RI/SP 추가 구매나 기타 단가 최적화를 고려할 수 있기 때문입니다. 이렇게 사용량 모니터링과 역할을 명확히 분리하여 보다 효율적인 모니터링 및 대응이 가능합니다.

4. 비용 이상현상 대응

비용 최적화 활동에서 흔히 간과되기 쉬운 요소 중 하나는 바로 비용의 이상현상입니다. 이를 적시에 인지하고 대응하는 것은 단위 경제 관점에서도 효율성을 유지하는 데 중요한 역할을 합니다. 불필요한 비용이 발생하면 전반적인 효율성이 악화될 수 있으므로 이를 최소화하는 것이 핵심입니다.

이를 위해 FinOps팀은 비용 이상탐지 체계를 구축하고 이를 팀원들에게 공유하여 직접적으로 조치를 취할 수 있도록 지원하는 것이 필요합니다. 특히 비용 이상을 인지하는 시간과 조치하는 시간을 효율적으로 관리하는 것은 주요 과제 중 하나입니다.

비용 이상현상을 식별하기 위해 다음 4가지 수단을 주로 활용합니다.

FinOps 이상탐지 메일 [앞의 5-2 목차에 포함]
전사적으로 공유되는 클라우드 비용 일간 알림 슬랙 채널 [앞의 5-2 목차에 포함]
AWS CLI 기반 실시간 비용 이상탐지 슬랙
모든 청구 데이터(CUR)은 특성상 약 3일 이후에 정확한 비용 정보를 확인할 수 있습니다. 이는 D+3 시점에서 이상탐지가 이루어진다는 한계를 가지고 있으며, 아무리 빠르게 대응하더라도 3일 동안 이상의 지속이 불가피합니다. 이를 극복하기 위해 AWS CLI를 활용하여 실시간 모니터링 체계를 구축하는 방법을 채택할 수 있습니다.
저희는 FinOps 플랫폼을 기반으로 AWS CLI(EC2 describe-instances API 등)를 활용하여 EC2, RDS, OpenSearch, ElastiCache 인스턴스의 목록을 10분 간격으로 수집하고, 단가표를 바탕으로 10분 단위 비용을 계산해 최근 4주 평균 대비 증가 여부를 판단합니다. 비용이 임계치를 초과하면 서비스와 운영팀 정보를 포함해 슬랙 알림 채널에 메시지를 발송합니다. 이를 통해 D+3의 탐지 시점을 M+10 수준으로 크게 단축시키며, 불필요한 비용 발생을 최소화할 수 있었습니다.
AWS Cost Anomaly Detection 기능 사용
AWS Budget 서비스에서 제공하는 기본 비용 이상탐지 기능도 유용하게 활용됩니다. 이 기능은 AWS 서비스 및 UsageType 단위로 설정된 임계치를 초과하여 사용량이 발생했을 때 즉각 알림을 제공합니다. 또한 Root cause 분석 기능을 통해 예상되는 증가 원인을 파악할 수 있습니다. 이러한 알림은 설정한 이메일로 전달되며, 필요 시 슬랙 특정 채널로도 연동이 가능해 관리가 편리합니다. 초기 FinOps팀이라면 설정 과정이 간편하다는 점에서 가장 우선적으로 사용해볼 만한 기능이라고 생각합니다.

FinOps팀은 위에 언급된 방법들을 서로 교차 검증하며 효과적인 이상탐지를 실시하고 있으며, 현재는 개발팀의 피드백을 바탕으로 이상탐지 임계치를 직접 조정할 수 있는 기능 도입을 검토 중입니다. 또한, 신규 서비스 개설이나 기존 서비스 증설과 같은 변화를 자동으로 감지할 수 있는 시스템도 추가적으로 연구하고 있습니다.

5. 일회성 할인(크레딧 활용)

CSP(AWS, Azure, GCP 등)에서 제공하는 크레딧 프로그램을 직접 요청해 비용을 최적화하는 방법입니다. 이 방식은 일회성으로만 비용 최적화가 가능하지만 서비스 장애와 같은 리스크가 없고, 공수도 적기 때문에 실용적으로 활용할 수 있습니다.

예를 들어 클라우드의 특정 신기능을 PoC하거나, 다른 CSP에서 이전하는 프로젝트를 진행할 경우 크레딧을 요청하는 것을 고려해볼 만합니다. 또한 비용 증가로 인해 보류했던 프로젝트도 크레딧을 통해 최소한의 비용으로 실행할 기회를 얻을 수 있습니다.

요청 과정에서 실패해도 손해볼 것은 없습니다. 크레딧 요청 자체는 비용이 들지 않기 때문입니다.

이번에는 FinOps 여정을 통해 얻은 주요한 깨달음들을 공유하려고 합니다.

FinOps를 담당하는 분들이라면 한 번쯤 고민하거나 앞으로 고민하게 될 문제들일 것입니다. 이에 대해 저희 팀이 어떤 방식으로 고민하고 해결했는지, 혹은 현재 해결해 나가고 있는지를 공유드리겠습니다.

Tagging 방법론

FinOps에서 Tagging은 핵심적인 작업이라 할 수 있습니다. 서비스와 팀에 속한 리소스를 명확히 구분하지 못한다면, 단위 경제를 기반으로 한 서비스 효율성을 측정할 수 없을 뿐만 아니라 비용 최적화를 실행하는 것도 불가능해집니다.

현재 저희는 Tagging 비율을 90% 이상으로 유지하고 있습니다. 이는 리소스에 적절한 태그가 부여되어 있을 뿐 아니라, 그 태그를 통해 해당 리소스가 어떤 팀의 소속인지까지 식별 가능한 상태를 의미합니다. 특히, 팀 정보는 과거의 데이터를 반영하는 것이 아니라 최신 조직도 기준으로 유효한 데이터를 사용합니다.

이와 관련해 저희가 준수하고 있는 Tagging 규칙에 대해 공유드리겠습니다.

FinOps 관점에서 우리는 다음 세 가지 태그를 주요하게 활용합니다. 이는 배포 시스템에서 필수로 설정해야 하는 태그 값으로, 아래와 같이 구성됩니다:

Service, Role, Zone

예를 들어 FinOps 팀의 특정 서비스를 설정한다고 가정하면 태그 값은 다음과 같이 지정됩니다.

Service: finops
Role: finops-api
Zone: dev

여기서 한 가지 의문이 생길 수 있습니다. 태그에는 팀 정보가 포함되어 있지 않습니다. 바로 이 지점에서 CMDB가 필요하게 됩니다. 우리는 태그에 조직 정보를 직접 입력하지 않고, CMDB를 통해 관리합니다. 태그에 조직 정보를 상수값으로 넣어버리면 조직 개편이나 담당자 변경 등과 같은 변동 사항에 제대로 대응할 수 없고, 결국 데이터의 신뢰성을 잃게 되기 때문입니다.

CMDB는 태그와 연동하여 조직 정보를 효율적으로 관리합니다. 예를 들어 Service와 Role 태그에 대응되는 조직 정보는 다음과 같이 관리됩니다. 이때 조직 정보는 Active Directory(AD)와도 연동됩니다.

Service: finops
Role: finops-api
Zone: dev
운영팀: FinOps팀
팀원: 김배민, 홍배민, 박배민

이에 따라 우리는 FinOps 플랫폼에서 CMDB 연동을 최우선 과제로 진행했고, 이를 통해 태그 단위의 비용 확인을 넘어 조직 단위에서도 비용을 쉽고 명확하게 분석할 수 있게 되었습니다. 또한 추가로 AD 정보를 가져와 매니저 정보, 조직 계층, 공용 이메일 주소 등 부가적인 정보를 보완하고 있습니다.

다만 CMDB 운영에는 언제나 데이터 현행화라는 어려움이 따릅니다. 이를 해결하기 위해 내부 인프라 팀이 현행화 프로세스를 철저히 구축하고 잘 운영하고 있습니다. 흐름은 다음과 같습니다.

AWS 리소스에 Service와 Role 태그가 부착되지 않았거나
부착된 Service 또는 Role 태그에 해당하는 운영팀 정보가 CMDB에 없을 경우
해당 리소스를 생성한 사용자에게 Slack 메시지를 자동으로 발송하여 조치를 요구

이 프로세스 덕분에 우리는 필수 태그값을 누락 없이 부착하고, 조직 정보를 CMDB로 분리함으로써 변화하는 조직 환경에도 유연하게 대응할 수 있게 되었습니다. 동시에 CMDB 현행화 문제도 효과적으로 해결하고 있으며, 운영상의 안정성과 효율성을 더욱 높이고 있습니다.

그 결과 Tagging 비율을 90% 이상 유지하고 있습니다.

AWS 비용 체계 이해: Unblended, Amortized의 본질적 차이와 활용법

AWS의 Cost Explorer를 열어보면 다음과 같은 5가지 비용 유형을 접할 수 있습니다. 익숙한 듯 낯선 이 용어들을 별다른 설명 없이 정확히 파악하기란 쉽지 않습니다.

Unblended cost
Amortized cost
Net unblended cost
Net amortized cost
Blended cost (Net 비용을 지원하지 않고, 실무적 활용처가 거의 없어 설명 제외)

저 또한 CUR을 직접 분석해보기 전까지는 알 수 없었기에 이 목차에서는 Unblended cost와 Amortized cost의 본질적인 차이, 그리고 Net 값의 의미를 중심으로 설명하며 각 비용 유형의 계산 방식 및 활용 방안을 명확히 이해할 수 있도록 안내하고자 합니다.

Unblended와 Amortized의 차이에 대한 오해

많은 글에서 일반적으로 제시하는 설명이 있습니다.

Unblended cost는 상각되지 않은 비용이기에 RI 비용이 매월 1일에 일괄 발생한다.
Amortized cost는 매월 1일에 발생한 RI 비용을 월 전체로 분배하여 처리한다.

위 설명이 완전히 틀린 것은 아니지만, Unblended와 Amortized cost의 핵심적인 차이를 제대로 설명하고 있지는 않습니다. 또한, 각각의 비용을 어떤 상황에서 어떻게 활용해야 하는지에 대한 명확한 가이드도 부족합니다. 그렇다면 Unblended는 언제 사용하고 Amortized는 어떤 경우에 적용해야 비용을 정확히 산출할 수 있을까요? 그리고 Net은 과연 무엇을 의미하는 걸까요?

Unblended와 Amortized의 원리 이해

먼저 AWS 비용 구조를 간단히 살펴보는 것이 좋겠습니다. 기본적으로 모든 청구액은 아래 산식으로 구성됩니다.

최종 청구액 = 원가(사용량 × 단가) – RI/SP 할인 – EDP 할인

결론적으로 청구 금액을 이루는 위 세 가지 구성 요소를 어떤 방식으로 반영할 것인지에 따라 적합한 Cost 옵션을 선택하면 됩니다.

EDP 할인 비용:
No Tag로 귀속 EDP 할인 비용:
혜택받은 Tag에 귀속

RI/SP 발생 비용: No Tag로 귀속	Unblended	Net Unblended
RI/SP 발생 비용: 혜택받은 Tag에 귀속	Amortized	Net Amortized

다음의 조건에 따라 2×2 형태로 총 4가지 비용이 결정되는 구조입니다.

RI/SP 발생 비용을 No Tag로 처리할지 아니면 혜택 받은 Tag에 직접 귀속시킬지
EDP 할인 비용을 No Tag로 처리할지 아니면 혜택 받은 Tag에 직접 귀속시킬지

조금 더 구체적인 예를 들어 설명하겠습니다.
다음과 같은 조건을 가정해 봅니다.

전사에는 "finops-api"라는 Tag를 가진 서비스만 존재합니다.
EC2 인스턴스는 총 10대가 있으며, 이 중 8대는 예약 인스턴스(RI)로 적용중입니다.
모든 EC2는 c5.2xlarge 타입으로 운영 중이며, 인스턴스 1대당 비용은 20원입니다.
RI는 30%의 할인율이 적용되어 1대당 비용이 14원입니다.
EDP 계약을 통해 전 제품 10%의 할인 혜택을 받고 있습니다.

먼저 Unblended Cost의 예시입니다.

전사의 AWS 비용은 136.8원 입니다.
"finops-api" 서비스의 비용은 40.0원 입니다.
No Tag 비용은 96.8원 입니다.

ProductName LineItemType InstanceType Tag 사용량 단가 총액

AWS EC2	RI 구매 발생 비용	c5.2xlarge	(No Tag)	8	14.0	112.0
AWS EC2	RI 적용 인스턴스 비용	c5.2xlarge	finops-api	8	0	0
AWS EC2	일반 인스턴스 비용 (RI 미적용)	c5.2xlarge	finops-api	2	20.0	40.0
AWS EC2	EDP 할인 금액	c5.2xlarge	(No Tag)			-15.2
						136.8

Net Unblended Cost의 예시입니다.

전사의 AWS 비용은 136.8원 입니다.
"finops-api" 서비스의 비용은 36.0원 입니다.
No Tag 비용은 100.8원 입니다.
Unblended 대비 EDP 할인률 10%가 서비스에 직접 귀속되어 "finops-api" 서비스의 비용이 10% 할인되었습니다.

ProductName LineItemType InstanceType Tag 사용량 단가 총액

AWS EC2	RI 구매 발생 비용	c5.2xlarge	(No Tag)	8	14.0	100.8
AWS EC2	RI 적용 인스턴스 비용	c5.2xlarge	finops-api	8	0	0
AWS EC2	일반 인스턴스 비용 (RI 미적용)	c5.2xlarge	finops-api	2	20.0	36.0
AWS EC2	EDP 할인 금액	c5.2xlarge	(No Tag)
						136.8

Amortized Cost의 예시입니다.

전사의 AWS 비용은 136.8원 입니다.
"finops-api" 서비스의 비용은 152.0원 입니다.
No Tag 비용은 -15.2원 입니다.

ProductName LineItemType InstanceType Tag 사용량 단가 총액

AWS EC2	RI 구매 발생 비용	c5.2xlarge	(No Tag)	8
AWS EC2	RI 적용 인스턴스 비용	c5.2xlarge	finops-api	8	14.0	112.0
AWS EC2	일반 인스턴스 비용 (RI 미적용)	c5.2xlarge	finops-api	2	20.0	40.0
AWS EC2	EDP 할인 금액	c5.2xlarge	(No Tag)			-15.2
						136.8

Net Amortized Cost의 예시입니다.

전사의 AWS 비용은 136.8원 입니다.
"finops-api" 서비스의 비용은 136.8원 입니다.
No Tag 비용은 0원 입니다.

ProductName LineItemType InstanceType Tag 사용량 단가 총액

AWS EC2	RI 구매 발생 비용	c5.2xlarge	(No Tag)	8
AWS EC2	RI 적용 인스턴스 비용	c5.2xlarge	finops-api	8	14.0	100.8
AWS EC2	일반 인스턴스 비용 (RI 미적용)	c5.2xlarge	finops-api	2	20.0	36.0
AWS EC2	EDP 할인 금액	c5.2xlarge	(No Tag)
						136.8

CUR 데이터를 기반으로 표를 4가지 형태의 Cost 계산 방식을 모두 보여드렸습니다. 전사의 비용 관점에서 보면 4가지 Cost 모두 차이는 없지만, finops-api 서비스의 비용은 각 Cost 방식에 따라 상당한 차이를 보이고 있습니다. 바로 이 부분이 중요한 핵심입니다.

finops-api 서비스의 비용

사용 원가: 200.0원
Unblended Cost: 40.0원
Net Unblended Cost: 36.0원
Amortized Cost: 152.0원
Net Amortized Cost: 136.8원

원가까지 포함해 5가지의 Cost 모두가 큰 차이를 보이고 있습니다.

LineItemType에서 "RI 구매 발생 비용"은 FinOps 팀이 구매한 RI 비용을 나타냅니다. Unblended 기준으로는 이 비용이 No Tag로 처리되기에 각 개발 팀에 RI 비용이 전가되지 않습니다. finops-api 서비스의 "RI 적용 인스턴스 비용" 항목을 확인해 보면 RI로 커버된 8대 인스턴스가 청구 금액이 0원이 되는 것을 알 수 있습니다. 사실상 RI 할인율 30%가 적용된 EC2 비용이 청구되어야 하지만, 해당 비용은 No Tag 항목인 "RI 구매 발생 비용"으로 처리된 결과입니다. EDP 할인까지 서비스에 반영한 Net Unblended 방식에서도 마찬가지입니다.

따라서 Tag 단위로 비용을 분석할 때, Unblended와 Net Unblended 방식은 매우 정확하지 않습니다.
RI/SP의 혜택을 받는 서비스는 RI 비용을 전가받지 않고 무료로 사용하게 되어 실제 비용보다 훨씬 낮게 계산됩니다. 이는 서비스별 비용 산출 시 큰 혼란이나 오해를 초래할 수 있습니다.

Amortized 사례를 살펴보면, Unblended와 달리 No Tag인 "RI 구매 발생 비용"을 0원 처리하며, 이 비용을 finops-api 서비스의 "RI 적용 인스턴스 비용"에 올바르게 반영합니다. Net Amortized로 넘어가면 EDP 할인까지 직접 finops-api 서비스에 귀속되어 가장 정확한 finops-api의 비용이 산출되죠.

결국 Tag 단위로 비용을 분석할 때, Amortized와 Net Amortized 방식을 사용하는 것이 가장 정확합니다.
RI/SP의 혜택을 받는 서비스에 RI 비용이 제대로 전가되기 때문에 Unblended처럼 무료로 인스턴스를 사용하는 사례가 없어집니다. RI/SP 할인을 받은 서비스의 최종 청구액이 정확히 산출되죠.

마찬가지로, 이러한 논리는 SP에도 동일하게 적용됩니다.

우리가 Unblended와 Amortized를 활용하는 방법

각 비용이 계산되는 원리와 이를 통해 발생하는 차이를 이전에 설명드렸습니다. 이번에는 각 비용의 활용처에 대해 말씀드리고자 합니다.

저희는 Net이 아닌 Unblended와 Amortized cost는 잘 활용하지 않습니다. EDP 할인은 모든 서비스에 적용되는 할인인데, 이를 굳이 No Tag 비용으로 귀속시켜 제외하고 싶지 않기 때문입니다. 이는 할인 혜택을 받는 각 서비스에 직접 귀속되는 것이 가장 정확하다 판단했습니다.

Net Unblended와 Net Amortized 비용은 상황에 따라 아래와 같이 활용합니다.

Net Unblended 비용: Invoice와의 정합성을 100% 보장하여 전사의 비용을 가장 정확하게 보고 싶을 때, 외부 기관에 정확한 비용을 제출해야 할 때
Net Amortized 비용: Invoice와는 약간 비용이 다르더라도 Tag 단위로 비용을 세분화해서 보고 싶을 때, 조직 단위로 비용을 분석해야할 때

FinOps 업무를 진행하면 회사 전체를 대상으로 한 비용 관리보다는 특정 조직이나 태그 단위로 세분화된 비용을 제공하는 일이 더욱 중요해지는 경우가 많습니다. 이 때문에 Net Amortized 비용을 활용하는 사례가 비교적 많습니다.

여기까지 비용 간 본질적인 차이점과 계산 방식, 그리고 적합한 사용 상황에 대해 정리했습니다. 이 내용을 바탕으로 상황에 맞게 적절한 비용 기준을 선택하여 활용할 수 있기를 기대합니다.

Kubernetes 비용을 Pod 수준까지 분석하기: Split Cost

기존 Kubernetes 비용 분석의 어려움

AWS는 한동안 EKS(Kubernetes)의 비용을 상세히 분석할 수 있는 도구를 제공하지 않았고, Worker Node(EC2) 단위까지만 비용 분석이 가능했습니다. EKS의 클러스터와 노드 수준에서의 비용은 파악할 수 있었지만 그 내부를 들여다보는 기능은 부족했죠.

이 문제의 원인은 CUR과 Cost Explorer가 기본적으로 청구 비용을 확인할 수 있는 도구로 설계되어 있다는 데 있습니다. AWS는 EKS에서 노드 역할을 수행하는 EC2에만 비용을 청구하기 때문에 내부에서 Pod를 운영하는 방식은 상관하지 않습니다. 이러한 이유로 Pod와 관련된 상세 정보는 청구 데이터(CUR)에 포함되지 않았던 것입니다.

Split Cost: Kubernetes 비용 상세 분석 기능 출시

2024년 4월, AWS는 청구 데이터(CUR)에 EKS의 Pod 수준까지 비용 데이터를 적재할 수 있는 새로운 기능을 추가했습니다.

이 기능은 기존 EKS 노드(EC2)의 청구 비용 데이터를 그대로 유지하면서, Pod 수준의 데이터를 추가로 기록해주는 방식으로 작동합니다. 비용 중복을 방지하기 위해 Pod 수준의 비용은 Split Cost라는 새로운 컬럼으로 분리되었습니다.

Split Cost의 가장 큰 장점은 비용 정합성이 뛰어나다는 점입니다. 이는 CUR과 100% 일치하며, EC2의 원가 기준뿐만 아니라 Net Amortized cost(RI, SP, EDP 할인을 적용한 가격) 기준에서도 정확성이 확인됩니다. 더불어 모든 Pod의 비용을 합산하면 정확히 EC2 노드의 총 비용과 일치하게 됩니다. 이런 방식은 기존의 3rd-party Kubernetes 비용 분석 도구에서는 구현하기 어려웠던 부분입니다.

Node의 비용을 각 Pod에 분배하는 개념의 Cost 입니다. 3가지의 Cost 개념이 있습니다.

Split cost: 각 Pod의 비용입니다. 요청한 vCPU와 MEM를 기준으로 Node의 비용을 분배받습니다.
Split Unused cost: Pod들에 자원을 분배하고 남은 Node 자원의 비용입니다.
Total Split cost: Split cost와 Split unused cost를 합친 개념으로, Node의 Split Unused cost까지 포함해 Pod들에게 할당합니다.

Split Cost는 아래의 단위까지 비용을 확인할 수 있습니다. Kubernetes의 대부분 단위를 지원합니다.

EKS Cluster
EKS Node
Namespace
Deployment
Workload Type
Workload Name
Pod Name

Split Cost 계산의 원리

c6i.4xlarge의 단일 Node로 구성된 EKS 클러스터를 예로 들어보겠습니다. 이 클러스터의 월 비용을 1,000원으로 가정합니다.

클러스터는 총 16개의 vCPU와 32GB의 메모리를 포함합니다.
AWS는 vCPU와 메모리의 가격을 9:1 비율로 책정합니다.
따라서 vCPU는 개당 56.25원(900원 / 16 vCPU), 메모리는 GB당 3.125원(100원 / 32GB)으로 계산됩니다.
Pod가 요청한 vCPU와 메모리 사용량은 청구 데이터(CUR)에 기록되고, 이 단가를 곱하여 Pod별 비용(Split cost)이 산출됩니다.
만약 Node의 일부 자원이 유휴 상태였다면, 사용하지 않은 vCPU와 메모리에 대한 비용은 Split Unused cost로 분배됩니다.

Split Cost 활용 시 고려할 사항

Split Cost는 CUR에서만 제공되는 기능으로, Cost Explorer에서는 조회할 수 없습니다. 만약 Split Cost 데이터를 확인하려면 Athena를 통해 CUR을 직접 쿼리하거나, QuickSight 기반의 대시보드를 SCAD와 함께 구성하거나, 외부 플랫폼으로 연동하여 분석하는 방식이 필요합니다. 저희는 자체적으로 FinOps 플랫폼을 보유하고 있어 이를 통해 데이터를 연동하고 분석하고 있습니다.

Pod 비용은 계산을 거친 후 각자 특정 Label을 부여받는데, 이 Label은 기존의 태깅 규칙과 동일하게 설정함으로써 소속된 조직을 식별할 수 있습니다. 이후 조직별로 Pod의 Split Cost를 배분하는 것이 바람직합니다. 하지만 Pod의 Label 값은 일반적인 태그와는 달리 아직 AWS CUR에 기록되지 않는 특징이 있습니다. 따라서 Pod, Replicaset, Deployment 이름 등을 바탕으로 Label 값이나 조직 정보를 추론해야 하는 한계가 존재합니다.

또한 Node의 유휴 비용(Split Unused cost)을 어떤 대상에게 분배할 것인지에 대한 문제도 고민해야 합니다. 저희는 Pod에 관한 비용은 개발팀에게 귀속시키고, Pod에 할당되지 않은 Node의 유휴 비용은 Kubernetes 클러스터 운영팀에게 귀속시키는 방안을 계획하고 있습니다.

RI/SP 할인의 공정한 배분 방법: Custom cost

FinOps 팀이 조직 전체에서 RI/SP를 구매할 때 고려해야 할 중요한 요소들이 있습니다. RI/SP는 매 시간 전사 서비스에 거의 무작위로 적용되며, 특정 팀이 혜택을 받는 반면 다른 팀은 그렇지 못하는 상황이 발생합니다. 이런 상황을 어떻게 공정하게 해결할 수 있을까요? 이는 앞서 소개한 Net Amortized Cost로는 해결하기 어려운 문제입니다.

문제 사례 1

A팀과 B팀이 있습니다.
A팀은 EC2 200원 정도를 사용하고, B팀은 EC2 150원 정도를 사용합니다.
그런데 A팀이 사용하는 인스턴스에만 SP가 적용되었고, 결과적으로 A팀은 40%를 할인 받아 120원이 되었습니다.
이제 A팀은 EC2 비용이 120원이 되고, B팀은 EC2 비용이 150원이 됩니다.

이 사례에서 A팀이 특별히 잘 한 것은 없고, B팀이 못 한 것도 없습니다.
전사 중앙조직에서 구매한 RI/SP가 이 때 A팀에 적용되었을 뿐입니다.

문제 사례 2

C팀이 갑자기 비용 이상탐지 메일을 받았습니다.
데이터를 분석해 보니 사용량은 그대로인데, 오늘의 비용만 갑작스럽게 증가했습니다. 확인 결과, 단가가 높게 책정된 이유는 오늘 SP 혜택이 갑자기 다른 팀의 인스턴스에 적용됐기 때문입니다. 이는 C팀이 통제할 수 없는 영역에서 발생한 비용 증가였고 어떠한 조치도 할 수 없었습니다. 이 때부터 C팀은 일별 비용 추이를 신뢰하지 못했습니다.

발생 문제

위 두 사례 모두 RI/SP로 인해 비용 분석 과정에서 혼란이 발생할 수 있음을 보여줍니다.

사례 1에서는 B팀이 A팀보다 사용량이 적은데도 불구하고 높은 비용을 지출하게 되면서 상대적으로 불리한 위치에 놓일 수 있습니다. 이는 B팀 입장에서 불합리하다고 느낄 여지가 있으며, 비용 최적화에 대한 압박을 받을 가능성이 있습니다.

사례 2에서는 초기에 정상적으로 할인 혜택을 받던 팀이 갑작스럽게 할인 적용에서 제외되면서, 매일 RI/SP 상태를 꼼꼼히 확인해야 하는 번거로움과 스트레스가 발생합니다. 결국 비용을 신뢰하지 못 하고, 모든 비용 데이터를 무시할 수 있는 상황도 발생할 수 있습니다.

해결 방안

이를 해결하기 위해 FinOps 담당자는 두 가지 방식 중 하나를 선택할 수 있습니다.
RI/SP 할인 금액을 각 팀의 사용량에 따라 재분배
RI/SP 할인금액 80원을 각 팀의 사용량만큼 재분배할 수 있습니다. A팀은 45.7원의 할인, B팀은 34.3원의 할인을 적용 받게 되죠 (예: 45.7원 = 80원 x (200원 / (200원 + 150원))

RI/SP 할인 금액을 특정 팀에 귀속시키지 않고 No Tag로 처리
RI/SP 할인금액을 80원을 어느 팀에도 귀속시키지 않게 No Tag로 처리할 수 있습니다. A팀, B팀은 각자의 사용 원가인 200원, 150원을 할당받고, No tag cost로 -80원을 처리할 수 있죠.

저희는 두 번째 방식을 채택하여 FinOps 플랫폼에서 비용 재분배를 진행하고 있습니다. 이는 기존에 제공되는 Unblended, Amortized, Blended cost 방식으로는 이 문제를 효과적으로 해결하기 어렵기 때문에, 새로운 비용 개념인 "Woowa Custom cost"를 도입한 것입니다.

현재 FinOps 플랫폼에서는 이 Woowa Custom cost를 기본 비용 계산 기준으로 활용하여 위와 같은 사례를 완전히 제거할 수 있도록 했습니다.

비용최적화의 절감액을 정확하게 산출하는 방법

효율적인 비용 절감을 위해 정확한 절감액을 계산하는 방법에 대해 알아보겠습니다. 편의상 이전 섹션인 [8-4. RI/SP 할인의 공정한 분배]에서 다루었던 사례를 동일하게 사용하여 설명하겠습니다.

문제 사례

A팀의 인스턴스를 제거하면 절감 비용은 얼마일까?

이 부분은 흔히 오해를 불러일으킬 수 있는 문제입니다. 많은 사람들이 자연스럽게 A팀의 현재 비용인 120원을 절감액으로 생각하겠지만, 실제 정답은 200원입니다.

SP는 제약 조건 내에서는 어떤 인스턴스든 자유롭게 적용된다는 특징이 있습니다. 만약 A팀의 인스턴스를 제거하면 어떤 변화가 생길까요? 기존에 A팀에 적용되던 SP 할인액 80원이 B팀의 인스턴스 비용에 적용됩니다.
따라서 B팀의 인스턴스 비용인 150원이 SP 할인을 받아 70원이 됩니다. 이로 인해 원래 총 지출 비용이 270원이었던 것이 70원으로 줄어드니, 절감액은 200원이 되는 것입니다.

[8-4. RI/SP 할인의 공정한 배분]에서 다뤘던 예시처럼 이해하면 쉽습니다.
RI/SP 할인액은 분리되어 있는 개념이고, 각 서비스의 원가가 실제 절감액이 되는 것이죠.

A팀 : 200원
B팀 : 150원
RI/SP 할인액 : -80원

절감 비용은 RI/SP를 제외하고 산출해야 한다

이 사례에서 보듯이, 절감액은 RI/SP 할인이라는 특정 변수를 배제하고 계산해야 정확합니다. 많은 경우 Net Amortized 및 Net Unblended 비용 모두 이를 해결할 수 없습니다.
저희는 앞서 소개했던 Woowa Custom Cost 방식을 통해 이를 해결하며, 모든 최적화 작업에서 기대 절감액을 산출할 때 활용하고 있습니다.

청구 원본 데이터(CUR) 분석

CUR이란 무엇인가

CUR(Cost Usage Report)은 클라우드 비용 청구 데이터를 원본 상태로 제공하며, 모든 수치와 근거가 상세히 기록된 보고서입니다. 이는 비용 분석을 위한 가장 세밀한 데이터로 간주됩니다. 일반적으로 사용되는 Cost Explorer는 CUR 데이터를 기반으로 요약 및 시각화를 제공하는 도구입니다.

CUR이 필요한 이유

시간 단위 분석의 어려움: 기본적인 Cost Explorer나 MSP의 시각화 도구는 시간별 서비스 패턴을 분석하는 데 취약합니다. 트래픽 변화에 따른 리소스 사용을 최적화하기 위해 24시간 패턴 분석이 필요한 경우, 기존 도구만으로는 이를 효율적으로 수행하기 어렵습니다.
제한적인 Group by 기능: AWS Cost Explorer에서는 Group by를 한 번에 한 가지 필드만 사용할 수 있어 복잡한 데이터 분석에는 한계가 존재합니다. 실제로 대부분의 문제는 하나의 기준으로만 분석해서는 충분한 결론을 얻기 어려운 경우가 많습니다.
필드의 부족: CUR에는 약 300개의 컬럼이 존재하지만, Cost Explorer와 같은 도구에서는 이 중 10% 내외만 활용 가능하여 충분한 심층 분석 및 인사이트 도출에는 제약이 따릅니다.

CUR의 활용 방법

CUR 데이터를 자유롭게 활용하려면 두 가지 대표적인 방식으로 활용할 수 있습니다.

Athena를 통한 데이터 분석: AWS가 권고하는 아키텍처를 따라 Athena를 사용해 CUR 데이터를 쿼리 및 분석하는 방식입니다.
직접 FinOps 플랫폼 구성: 저희도 초기에는 Athena를 활용했지만, FinOps Data Lake 구성의 필요성을 느껴 자체적으로 FinOps 플랫폼을 구축하여 데이터를 가져와 분석합니다.

CUR이 어렵다면 핵심 필드로 시작해보자

CUR 데이터는 처음 접할 때 컬럼이 많아서 혼란스러울 수 있습니다. 하지만 우선 아래 핵심 필드와 값 위주로 분석을 시작하면 보다 명확한 흐름을 잡을 수 있습니다. 대부분의 경우 이 필드들로 Group by를 수행하면 원하는 결과를 얻을 수 있습니다.

주요 필드:
ProductName, UsageType, Operation, LineItemDescription, Tag
주요 값:
UsageAmount, NetUnblendedCost, NetAmortizedCost

각 컬럼의 간략한 설명입니다.

ProductName: 특정 AWS 서비스명을 나타냅니다. 예를 들어 "Amazon Elastic Compute Cloud"와 같은 값이 있습니다.
UsageType: 해당 AWS 서비스의 특정 기능을 구체화한 값으로, 예를 들면 "APN2-BoxUsage:c6i.2xlarge"는 APN2 리전(서울)에서 사용된 일반 c6i.2xlarge 인스턴스를 나타냅니다.
Operation: AWS 서비스 기능의 상세 단위를 나타냅니다. 예를 들어 S3에서는 "GetObject", "PutObject"와 같은 값으로 기능을 더 분류합니다.
LineItemDescription: 해당 기능이 청구되는 기준을 텍스트 형식으로 설명합니다. 예를 들어 "$0.384 per on demand linux c6i.2xlarge instance hour"와 같은 값이 기록되는데, c6i.2xlarge 인스턴스를 1시간 사용했을 때 $0.384가 청구된다는 뜻입니다.
UsageAmount: 서비스를 실제로 사용한 양을 나타냅니다. 예를 들어 c6i.2xlarge 인스턴스를 2시간 사용했다면 해당 값은 2로 기록됩니다.
NetUnblendedCost 및 NetAmortizedCost: 앞서 6-2 목차에서 언급했던 청구 비용 항목입니다. 이는 Cost Explorer에서도 확인할 수 있는 주요 비용 데이터이며, 동일한 값이 기록됩니다.

CUR 데이터는 효율적인 비용 관리를 가능하게 해주는 강력한 도구입니다. 핵심 필드를 중심으로 시작해 점차 분석 범위를 확장하면 비용 최적화를 극대화할 수 있습니다.

RI/SP 구매 전략

중앙 FinOps 조직을 통한 구매가 가장 효율적이다

RI/SP는 전체 Linked Account 사용량을 종합적으로 관리할 수 있는 FinOps 조직이 구매하는 방식이 더 적합합니다. 이를 통해 낭비를 최소화하고 할인 혜택을 최대로 활용할 수 있습니다.

만약 각 Linked Account를 운영하는 개별 팀이나 조직 단위로 RI/SP 구매 권한을 부여한다면, RI/SP 공유 옵션을 비활성화해야 합니다. 그렇지 않으면 내가 구매한 RI/SP가 다른 서비스에 적용되거나, 반대로 다른 조직이 구매한 RI/SP가 내 서비스에 사용되는 비효율적인 상황이 발생할 수 있습니다. 이는 전사적으로 과도한 구매로 이어질 위험이 있습니다.

인스턴스 규모가 커질수록 RI/SP 낭비 위험은 줄어들며, 보다 공격적인 커버리지 정책을 적용하기가 용이합니다. 세무적 이슈가 없는 한 RI/SP는 전사적으로 공유 옵션을 활성화한 뒤, 중앙 조직에서 일괄적으로 구매하는 방식이 가장 효과적입니다.

자주, 소규모로 분할 구매하는 것이 최적이다

RI/SP는 항상 낭비의 가능성을 내포하고 있습니다. 이러한 위험을 최소화하려면 구매를 세분화하고 가능한 한 자주 진행하는 것이 중요합니다.

예를 들어, EC2 인스턴스 1,000대를 운영하는 회사가 목표 Coverage를 80%로 설정하고 SP를 구매한다고 가정해 보겠습니다.

A사는 초기 목표 Coverage를 80%로 설정하고, EC2 800대를 커버하는 SP를 하루에 일괄 구매했습니다. SP의 기간은 1년으로 고정되었습니다.
B사는 같은 목표 Coverage 80%를 설정했지만, SP를 소규모로 나누어 분할 구매했습니다. 매일 약 2.2대 분량의 SP를 구매해 최종적으로 1년간 EC2 800대를 커버하도록 조치했습니다.

첫 번째 방식은 1년 동안 SP가 고정되어 있으므로 20% 이상의 최적화나 리소스 감소를 수행하기 어렵습니다. 장기간 묶여 있는 SP는 FinOps 작업에서도 유연성을 떨어뜨릴 수 있습니다.

반면 두 번째 방식은 초기에는 할인 혜택이 상대적으로 적을 수 있지만, 1년 후에는 Coverage를 85-90%로 상향 조정하며 단가와 비용을 최적화할 여지가 더 커집니다. 또한 감소하는 EC2 수량에 맞춰 SP를 유연하게 줄여나갈 수 있습니다. 매일 2.2대 분량의 EC2 SP가 자동 만료되기 때문에 필요하지 않을 경우 재구매를 중단하면 됩니다. 이러한 방식은 언제든 SP 수량을 조정할 수 있어 보다 공격적인 구매 계획을 세울 수 있는 점에서 이점이 있습니다.

저희 역시 이러한 분할구매 전략을 활용하고 있습니다. 다만, 사람이 직접 수행하기에는 번거롭기 때문에 AWS CLI API를 활용하여 자동 구매 시스템을 구현하거나, RI/SP 자동구매 솔루션을 도입하는 것을 추천합니다.

구매 수량 산정 시 시간 단위까지 고려해야 한다

RI나 SP를 구매할 때 주의해야 할 점은 최소 단위가 시간이라는 점입니다. 많은 경우 Cost Explorer와 같은 도구를 활용하여 일 단위 사용량을 기준으로 구매 결정을 내리지만, 시간대별로 사용량 변동이 많은 리소스가 존재하므로 이를 꼼꼼히 확인해야 합니다.

예를 들어 EC2의 사용량이 시간대에 따라 Scale-in/out 되는 상황을 가정해 봅시다.

00-09시: 100대
09-16시: 120대
16-00시: 200대

Cost Explorer에서 평균 사용량을 일 단위로 분석하면 하루 사용량이 약 139대로 계산됩니다. 이 평균치를 기준으로 우리가 80% 커버리지를 목표로 RI/SP를 111대 정도 구매했다고 가정하면, 다음과 같은 문제가 발생합니다.

00-09시에 11대의 RI/SP가 꾸준히 낭비됩니다.
09-16시에 커버리지가 92.5%가 되어 RI/SP 낭비 위험이 있는 상황이 발생합니다.

저희는 이러한 상황에서 하루 중 최소 사용 시간을 분석한 뒤, 해당 수량을 기준으로 약 80%의 커버리지를 목표로 RI/SP를 구매합니다. 위의 예시라면 최소 사용량은 100대가 되고, 저희는 80대 정도의 RI/SP를 구매하게 됩니다.

이렇게 시간 단위를 고려하여 RI/SP 구매를 진행하면 낭비를 최소화할 수 있을 것입니다.

EC2는 RI보다 SP가 유리하며, Instance SP와 Compute SP를 혼합하여 전략적으로 활용하는 것이 좋다

Standard RI와 Instance SP의 할인율은 동일하며, Convertible RI와 Compute SP의 할인율은 같습니다. Standard RI는 Instance SP에 비해 뚜렷한 이점이 없으며, Convertible RI와 Compute SP 역시 마찬가지입니다. SP는 RI에 비해 더 높은 자유도를 제공합니다.

RI의 유일한 차별점은 AWS Marketplace에서 거래가 가능하다는 점입니다. 그러나 국내에서 이를 적극적으로 활용하는 기업 사례는 확인하지 못했습니다. 이는 미국 계좌를 요구하며, 세금 처리 관련 절차가 복잡하기 때문으로 추정됩니다. Marketplace 거래를 고려하지 않는 경우 EC2에서는 RI를 구매할 이유가 없습니다.

인스턴스 패밀리에 따라 Instance SP 혹은 Compute SP가 더 유리할 수 있습니다. 예를 들어, c5 인스턴스의 경우 1년 기준 Instance SP의 할인율은 37%이며 Compute SP는 22%로, 두 옵션 간 15%의 할인율 차이가 있습니다. 반면 m6g 인스턴스의 경우 Instance SP는 36%, Compute SP는 29%로, 그 차이가 7%에 불과합니다.

결론적으로 저희는 인스턴스 특성을 고려하여 c5 인스턴스는 Instance SP로 우선 커버하며, m6g는 Compute SP로 커버하는 전략을 채택합니다. Instance SP는 잠재적 위험이 따르지만, c5의 경우 할인율 차이가 15%로 충분히 큰 편이라 가치가 있다고 판단합니다. 반면, m6g는 할인율 차이가 7%로 비교적 적기 때문에 위험 대비 활용할 이유가 없다고 판단하고 있습니다.

지금까지 모든 SP를 가장 안정적인 Compute SP로만 적용하는 전략을 사용해 왔다면, 앞으로는 인스턴스 패밀리별 할인율을 세부적으로 분석하여 Instance SP를 혼합 활용할 가능성을 검토하면 비용 절감 효과를 극대화하는 데 도움이 될 것입니다.

월별 클라우드 비용 분석 시 반드시 필요한 일수 보정

클라우드 비용 분석은 흔히 월 단위로 이루어지는 경우가 많습니다. 이는 CSP나 MSP가 월간 리포트를 제공하거나 예산을 월 단위로 관리하는 관행이 일반적이기 때문입니다. 그러나 월별 분석에서 흔히 간과되는 점이 하나 있습니다. 바로 월마다 일수가 다르다는 사실입니다.

왜 일수 차이가 중요한가요?

겉보기에는 30일 혹은 31일의 차이가 크지 않다고 느껴질 수 있습니다. 그러나 이 미묘한 차이가 비용 분석에서는 상당한 영향을 미칩니다. 예를 들어, 한 달이 30일인 경우와 31일인 경우를 비교하면 이는 약 3.3% 정도의 증감률 차이를 만들게 됩니다. 즉 단순히 월간 비용만 보고 상승이나 하락을 판단하면 잘못된 결론에 도달할 가능성이 있습니다.

예를 들어볼까요?
11월과 12월 사이 특정 서비스의 비용이 2.0% 증가했다고 보고되었다고 가정합니다. 숫자만 보면 12월에 실제로 비용이 늘어난 것처럼 보입니다. 그러나 일수 차이를 보정하여 다시 계산하면 오히려 비용이 1.3% 감소합니다. 이런 오류는 잘못된 비용 해석으로 이어져 비즈니스 의사 결정에 영향을 줄 수 있습니다.

월별 비용 비교 시 일수 보정 방법

비용 분석에서 일수 차이를 보정하는 방법은 크게 두 가지입니다.

일별 비용으로 환산하여 비교
월간 비용을 동일한 일수로 변환하여 비교

예를 들어 A 회사의 클라우드 비용이 11월에 600원, 12월에 606원이라고 가정해보겠습니다.

일수 조정을 하지 않은 경우
12월의 비용은 11월 대비 약 1% 증가한 것으로 보일 것입니다.
일별 평균 비용으로 비교하면
11월은 하루 평균 비용이 20원, 12월은 하루 평균 비용이 약 19.54원이 되어 실제로는 약 2.3%의 비용 감소로 나타납니다. 정확한 증감률이지만 월 규모를 이해하기 어려울 수 있습니다.
월간 비용을 고정 일수 기준으로 변환하는 방식
이는 비교적 직관적인 대안을 제공합니다. 이를 통해 A 회사의 11월 비용은 608.3원(20원 × 365일 ÷ 12개월), 12월 비용은 594.3원(19.54원 × 365일 ÷ 12개월)로 변환됩니다. 이 방식으로 동일한 약 2.3% 감소를 확인할 수 있으며, 동시에 비용 규모를 직관적으로 유지할 수 있습니다.

결론적으로 저희는 마지막 방법을 추천드립니다. 실제로 저희는 FinOps 플랫폼의 월간 비용 비교 대시보드에서 세 번째 방식인 일 평균 보정 기능을 활용하고 있습니다.

이 방법은 월간 비용의 전체 규모를 명확히 유지하면서도 일수 조정을 통해 보다 신뢰성 높은 분석을 가능하게 합니다. 이를 통해 비용 변화의 원인을 정확히 파악하고, 더 현명한 의사 결정 과정을 지원할 수 있습니다.

지금까지 우아한형제들에서 정의한 FinOps의 개념과 이를 어떻게 구현했는지에 대한 과정을 공유드렸습니다. 궁극적으로 우리가 지향하는 바를 요약하면 아래 그림으로 표현할 수 있습니다.

두 가지 프레임워크를 기반으로 FinOps 플랫폼을 구축하고, 이를 통해 비용을 인지하는 아키텍처 문화를 전 개발자에게 전파합니다. 그 결과, 각 개발팀이 단위 경제를 기반으로 비용 최적화를 스스로 수행할 수 있도록 유도하는 것이 우리의 목표입니다.