들어가며
수많은 데이터를 처리하는 '에어브릿지(Airbridge)' 서비스 특성상, AWS 인프라 비용을 잘 관리하는 것은 저희에게 매우 중요한 과제입니다. 사업 초기에는 성장에 집중하느라 비용 관리에 많은 리소스를 투입하기 어려웠지만, 회사가 성장하고 데이터 트래픽이 늘어남에 따라 비용 지출이 크게 늘었고, 체계적인 비용 관리의 필요성을 절실히 느끼게 되었습니다.
일반적인 트러블 슈팅 방법이나 코딩 패턴과 같은 것들과 달리 이런 노하우의 영역의 정보는 인터넷 검색을 통해 얻을 수가 없었습니다. 그러다보니 글에서는 간단하게 요약했지만 지금의 비용 관리 시스템을 구축하기까지는 정말 긴 시간이 걸렸습니다.
이 글에서는 저희가 어떻게 AWS 비용을 관리하는지를 자세히 소개하고, 그 과정에서 겪은 시행착오와 교훈을 공유합니다. 정말 가장 좋은 방법으로 운영하고 있는 것이 맞을지에 대해서는 물음표가 있고, 그래서 이런 노하우들을 잘 공개하지 않는게 아닌가 합니다. 하지만 작은 정보라도 절실했던 예전 우리 팀을 생각했을 때 누군가에게는 조금이라도 도움이 되지 않을까 싶어서 공개해보기로 했습니다. 도움이 되는 분들이 계시길, 그리고 또 저희의 방식을 보고 더 좋은 방법들도 공유해주시는 분이 나타나길 바랍니다.
결과 미리 보기: Fin Ops 대시보드
본격적인 이야기에 앞서, 저희가 현재 어떤 대시보드를 통해 데이터를 확인하고 비용을 운영하는지 먼저 보여드리는 것이 이해에 도움이 될 것 같습니다.
한 가지 저희 조직의 특징을 말씀드리면, 저희는 데이터를 분석할 때 구글 시트를 즐겨 사용합니다. 구글 시트는 여러 장점이 있습니다. 원천 데이터를 올려두면 가공이 쉽고, 다른 시트의 데이터를 불러와 활용하기도 편리합니다. 간단한 시각화는 물론, 셀마다 코멘트를 달아 부가 설명을 덧붙일 수도 있죠. 이런 이유로 저희는 대부분의 대시보드를 구글 시트로 만들어 사용하고 있습니다.
아래는 저희가 실제 비용 점검 미팅에서 활용하는 대시보드입니다. 팀, 환경, 서비스, 애플리케이션 등 태그(Tag)별, 일자별 비용을 한눈에 확인할 수 있습니다.
왼쪽에 흐리게 처리된 부분은 저희가 수집한 데이터의 양을 나타냅니다. 색상으로 데이터 양의 많고 적음을 표시했는데, 붉은색은 높음, 푸른색은 낮음을 의미합니다. 저희 서비스는 수집한 데이터 양에 따라 비용이 결정되는데, 일자별 편차가 큰 편입니다. 따라서 데이터 수집량을 함께 보아야 비용 변동을 효율적으로 리뷰할 수 있습니다.
다음은 어떤 리소스에서 비용이 많이 발생하는지 보여주는 Top View입니다. 리소스별 총비용, 일간/월간 평균 비용, 그리고 전체 비용에서 차지하는 비중(%)을 보여줍니다. 이를 통해 어떤 리소스의 최적화 우선순위가 높은지 빠르게 파악할 수 있습니다.
%/%/%/%로 표기된 항목은 태그 처리가 안 되었거나, 태그는 되어 있지만 비용 비중이 작아 기타 항목으로 합쳐둔 비용입니다. 보시다시피 2.42%로 상당히 낮은 비중을 차지합니다. 그동안 태그 관리에 힘쓴 덕분에, 태그가 누락되어 집계된 비용은 1% 미만입니다. 구글 시트의 성능 한계상 너무 많은 데이터를 올리기 어려워, 태그가 있더라도 비중이 작은 항목들을 합쳐두었기 때문에 2.42%로 나타난 것입니다.
주요 운영 프로세스
1) 주기적인 비용 점검
저희는 2주 간격으로 비용 점검을 진행합니다. 다소 잦다고 느끼실 수도 있지만, 비용 점검을 중요하게 생각하기 때문이기도 하고, 주기가 이보다 길어지면 변동 사항을 추적하기 어렵기 때문에 2주로 자리 잡았습니다. 사람은 보통 2주 전의 일은 잘 기억하지만, 한 달만 지나도 가물가물해지기 마련이니까요. 또한, 임팩트가 큰 비용 변동이 뒤늦게 발견될 경우 손실이 커질 수 있는데, 2주마다 점검하면 이를 조기에 방지할 수 있습니다.
점검 주기가 짧은 만큼, 많은 부분을 자동화했습니다. 앞서 보여드린 시트의 스냅샷 생성, 댓글을 통한 논의, 심지어 회의록 작성까지 자동화되어 있습니다.
위 캡처는 2주마다 미팅에 필요한 시트와 노트를 생성하고 슬랙(Slack)으로 알려주는 봇입니다. 덕분에 2주에 한 번 진행되는 미팅이지만, 실제 소요 시간은 30분 이내로 매우 짧습니다.
구글 시트의 댓글 기능을 활용하여, 팀, 환경, 서비스, 애플리케이션별 비용을 점검하고 큰 변동이 있을 경우 그 사유를 코멘트로 작성합니다. 위 이미지처럼 갑자기 비용이 증가하여 붉게 표시된 항목에는 담당자가 직접 원인을 분석하여 댓글을 남깁니다.
비용 급증의 원인을 파악해 보면 RI(Reserved Instance)나 Savings Plan이 제대로 적용되지 않은 경우도 있습니다. 이럴 때는 다음 계약 물량을 어느 정도로 가져갈지 함께 논의합니다.
위 차트는 구글 시트에서 Savings Plan 현황을 시각화한 것입니다. 푸른색은 SP로 처리되는 비용, 붉은색은 처리되지 않는 비용, 노란색은 실제 사용량이 계약량보다 적어 손실(shortfall)이 발생하는 비용을 의미합니다. 계약 수량을 변경했을 때 커버리지가 어떻게 달라지는지 바로 시뮬레이션해 볼 수 있도록 만들어, 계약에 따른 결과를 쉽게 예상할 수 있도록 했습니다.
2) 개발 전 예상 비용 산출
제품 특성상 새로운 기능을 추가하거나 기존 기능을 변경할 때 워크로드에 큰 변화가 생기고, 이는 곧 비용 변동으로 이어질 수 있습니다.
과거에는 이벤트 처리 로직을 비효율적으로 작성했다가 나중에 IO 비용이 급증한 것을 뒤늦게 발견하는 경험을 하기도 했습니다. 이러한 경험이 쌓이면서, 개발 단계에서 예상 비용을 미리 산출하는 것이 얼마나 중요한지 깨닫게 되었습니다. 예상 비용을 바탕으로 더 나은 아키텍처를 고민하거나, 경우에 따라서는 기능 개발을 포기하는 등 합리적인 의사결정을 내릴 수 있습니다.
저희 제품 개발 프로세스에는 '테크 스펙(Tech Spec)'을 작성하는 단계가 있습니다. 위 캡처는 테크 스펙의 일부로, 개발자가 직접 예상 비용을 산출한 내용입니다. 이 문서를 통해 비용 최적화 작업을 함께 계획하거나, 다른 접근 방식에 대한 논의가 자연스럽게 이루어집니다. 또한, 테크 스펙은 팀에 공유되기 때문에 주기적인 비용 점검 시에도 변경 사항을 파악하는 데 큰 도움이 됩니다.
3) 필요에 따른 최적화 계획 수립
일상적인 점검 외에도, 때로는 별도의 최적화 계획을 수립합니다. 이는 간단한 수정으로 해결되지 않는, 시스템 언어 마이그레이션처럼 많은 리소스가 투입되는 대규모 작업들입니다.
상당한 엔지니어링 리소스가 필요한 만큼, 프로덕트 개발 로드맵이나 비즈니스 상황을 종합적으로 고려하여 신중하게 진행 여부를 결정합니다.
비용 관리 시스템 고도화 과정
지금의 시스템이 처음부터 완벽했던 것은 아닙니다. 저희의 비용 관리 시스템 역시 여러 단계를 거쳐 발전해왔습니다.
Phase 0: 청구서만 들여다보던 시절
가장 처음에는 매달 날아오는 AWS 청구서를 확인하는 것이 전부였습니다. 가끔 AWS Cost Explorer에 들어가 "이번 달엔 왜 이렇게 많이 나왔지?" 하고 살펴보는 정도였죠. 아마 많은 초기 스타트업이 비슷한 상황일 거라 생각합니다.
Phase 1: 최소한의 분류 시작
비용 사용량이 늘고 변동이 잦아지면서, 비용을 더 상세하게 들여다볼 필요성을 느꼈습니다. 그래서 Name 태그를 좀 더 적극적으로 추가하기 시작했습니다. 아주 기초적인 수준이었지만, 당시에는 팀과 시스템 규모가 작았기 때문에 Name 태그만으로도 비용을 리뷰하고 최적화 계획을 세우는 데 큰 무리가 없었습니다.
Phase 2: 태그(Tag) 전략 고도화 및 적용
하지만 시스템이 복잡해지고 팀이 커지면서 Name 태그만으로는 비용을 추적하기 불가능해졌습니다. 비용을 더 정밀하게 추적하고 통제하기 위해, 본격적으로 태그 전략을 세우고 고도화하기 시작했습니다.
먼저 Team, Environment, Service, Application 등 명확한 기준을 담은 태그 정책을 수립하고, 모든 팀원이 이를 따르도록 가이드를 배포했습니다. 하지만 예상대로, 가이드 배포만으로는 정책이 잘 지켜지지 않았습니다.
그래서 태그 설정에 강제성을 부여하기로 했습니다. 태그 기반으로 IAM 권한 제어가 가능한 리소스에 대해서는, Team 태그가 있어야만 권한을 부여하도록 정책을 변경했습니다. 이 정책을 적용한 뒤부터는 대부분 리소스의 담당 팀을 쉽게 파악할 수 있게 되었습니다.
다음으로, 비용 점검 미팅에서 태그 설정이 미흡한 리소스를 파악하고 그 비중을 점차 낮춰나가는 목표를 세웠습니다. 또한, 이 과정을 사람이 최대한 신경 쓰지 않아도 되도록, 태그가 없는 리소스가 발견되면 슬랙으로 자동 알림을 보내는 봇을 만들어 활용했습니다.
그 결과, 태그가 설정되지 않은 리소스에서 발생하는 비용 비중을 전체의 1% 미만까지 낮출 수 있었습니다.
지난 여정에서 얻은 5가지 교훈
1) 상황에 맞는 적절한 수준의 엔지니어링이 필요하다.
지금처럼 통제가 잘 되는 시스템을 만들기까지는 굉장히 많은 노력이 들어갔습니다. 최대한 사람의 개입을 줄이도록 개선했지만, 여전히 어느 정도의 관리 리소스는 필요합니다.
과거에는 시스템이 알림을 주면 사람이 대응하게 만들어, 사람의 손을 전혀 타지 않는 완전 자동 통제 시스템을 만들고자 한 적도 있었습니다. 하지만 잘 되지 않았습니다. 비용 통제는 귀찮고 번거로운 일이며, 당장의 개발 우선순위에 밀리기 쉽기 때문입니다. 결국, 담당자가 지속해서 팔로업하는 과정이 필수적이라는 결론을 내렸습니다.
따라서, 비용 변동이 크지 않고 예측 가능하다면 비용 통제를 위해 엔지니어링 리소스를 계속 투입하기보다 비즈니스에 필요한 개발을 우선하는 것이 나을 수 있습니다. 예를 들어, 월 비용이 몇 십 달러 수준이고 변동도 거의 없다면, 이를 통제하고 최적화하는 데 드는 개발 리소스가 더 비쌀 것입니다.
이 글을 읽는 분들도 각자의 상황에 맞는 적정 수준의 엔지니어링을 고민해보시길 권해드립니다.
2) 비용 '통제'와 '최적화'는 다른 일이다.
비용 통제는 비용 사용의 예측 가능성을 높이는 것이고, 비용 최적화는 비용 자체를 줄이는 것입니다. 둘 다 많은 리소스가 드는 별개의 작업입니다.
만약 당장 비용을 줄이는 것이 시급하다면, 비용 현황 파악이 다소 비효율적이더라도 일단 원인을 찾아 최적화 작업을 먼저 진행하는 것이 맞습니다. 잘 통제되는 운영 환경을 만드는 데는 오랜 시간과 지속적인 리소스가 투입되기 때문입니다. 반면, 장기적으로 비용을 안정적으로 관리하는 것이 중요하다면, 효율적인 통제를 위한 자동화와 운영 프로세스를 먼저 구축해야 합니다.
3) 자동화, 자동화, 그리고 또 자동화.
어찌 보면 뻔한 이야기일 수 있지만, 자동화는 아무리 강조해도 지나치지 않습니다. 여기서 말하는 자동화는 단순히 비용 데이터를 처리하고 알림을 보내는 것을 넘어, 동료들이 질문 없이 스스로 데이터를 조회하고 문제를 파악할 수 있는 '셀프 서브(Self-serve)' 환경을 만드는 것까지 포함합니다.
태그가 없는 리소스를 찾아서 설정 요청을 하는 일을 매일 반복한다고 상상해보세요. 이런 단순 반복 작업을 사람이 직접 처리하면 시간도 많이 들고, 개발자들의 참여도 역시 떨어집니다. 특히 커뮤니케이션이 필요한 일은 생산성을 더욱 저하시킵니다. 저희 경험상, 아주 사소한 부분이라도 하나씩 자동화할 때마다 확실히 생산성이 눈에 띄게 좋아졌습니다. 회의록을 자동으로 만들어주는 것과 같이 '이런 것까지?' 싶을 정도로 과감하게 자동화해보시길 추천합니다.
4) '메커니즘'이 필요하다.
태그 설정을 예로 들어보겠습니다. "태그를 잘 답시다"라고 아무리 강조해도, 사람들은 저절로 태그를 잘 달기 시작하지 않습니다. 안 달아도 당장 문제가 없으니까요. 그렇기 때문에 태그를 설정하지 않으면 안 되게 만드는 장치, 즉 메커니즘이 필요합니다.
저희의 경우, IAM 권한 제어에 태그를 활용하여 개발 시 태그 설정을 의무화하고, 비용 점검 시 태그 현황을 관리하는 강제성을 부여함으로써 정책을 정착시킬 수 있었습니다. 정책을 선언하는 것을 넘어서 메커니즘을 만들면 훨씬 더 효율적으로 실행할 수 있습니다.
5) FinOps는 결국 '문화'다.
기능 개발, 모니터링, 세일즈 등 비즈니스 전반에 걸쳐 비용에 영향을 미치는 활동은 무궁무진합니다. 이 모든 것을 시스템으로 막는 것은 비효율적이고 거의 불가능합니다. 하지만 구성원 모두가 비용의 중요성을 인지하고 함께 신경 쓰는 문화가 자리 잡으면, 누가 시키지 않아도 자연스럽게 비용이 관리되기 시작합니다.
그렇다면 문화는 어떻게 만들어야 할까요? 코드 리뷰나 테스트 코드 작성 문화가 "오늘부터 합시다!"라고 해서 바로 정착되지 않는 것처럼, FinOps 문화 역시 누군가의 꾸준한 헌신이 필요합니다. 그 중요성을 계속 강조하고, 동료들을 이끌어주는 노력이 쌓여야 합니다. 저희도 지금의 문화가 자리 잡기까지 정말 오랜 시간이 걸렸습니다. 조급해하지 않고 꾸준히 노력한다면, 분명 긍정적인 변화를 만들 수 있을 것입니다.
마치며
AB180 개발팀의 비용 관리 여정은 아직 현재 진행형입니다. 저희는 지금도 더 효율적인 방법을 찾기 위해 끊임없이 고민하고 실험하고 있습니다. 이 글이 FinOps로 고민하는 다른 스타트업들에게 조금이나마 영감과 용기를 드릴 수 있었기를 바랍니다.
ᴡʀɪᴛᴇʀ
Juhong Jung @toughrogrammer
Software Engineer @AB180
