AWS 비용 최적화 Part 1: 버즈빌은 어떻게 월 1억 이상의 AWS 비용을 절약할 수 있었을까
버즈빌은 2023년 한 해 동안 월간 약 1.2억, 연 기준으로 14억에 달하는 AWS 비용을 절약하였습니다. 그 경험과 팁을 여러 차례에 걸쳐 공유합니다. AWS 비용 최적화 Part 1: 버즈빌은 어떻게 월 1억 이상의 AWS 비용을 절약할 수 있었을까 (준비중) …
Read Article2021년 말에 시작했던 글이 어느새 2022년 말까지 흘러왔네요. 2022년 한 해 동안 버즈빌 제품팀이 일하는 방식에는 더욱더 많은 변화가 생겼습니다. 원래 기획했던 6부를 모두 정리하기에는 글 작성 속도보다 변화의 속도가 더 빨라서, 이번 3부에서 전반적인 내용을 짧게나마 정리하고 마무리하려고 합니다.
얼마전 OKR이 경쟁사를 느리게 만들려는 구글의 계략이라는 트윗에 구글 대표 순다 피차이가 “들켰다”라고 말해서 많은 좋아요를 받았습니다. (노.. 농담이겠죠?) OKR은 목표 달성을 위해 조직이 모두 집중할 수 있게 도와주기도 하지만, 잘못 운영될 경우 속도를 느리게 만들기 때문에 이런 음모론이 나오기도 합니다.
Oops. Finally someone figured it out:) https://t.co/gh36taeElF
— Sundar Pichai (@sundarpichai) July 2, 2022
이때 ‘느리다’는 부분을 잘 해석해야 합니다. 실제로 OKR을 과도하게 운영하느라 시간을 써서 실행을 느리게 만들 가능성도 있지만, 잘못 운영된 OKR로 인해 학습과 전환 속도를 늦추고 성장 엔진을 멈추게 만들 가능성도 있습니다. 전자의 경우 쉽게 눈에 띄어서 문제 파악과 개선도 빠르게 만들 수 있습니다. 반면 후자는 시간이 한참 흐른 뒤 알게 될 가능성이 높아서 훨씬 위험하다고 볼 수 있죠.
대표적으로 실수하는 것 중 하나는 할 일 리스트로만 구성된 KR입니다. 이번 분기에 할 일들의 리스트를 나열하고 완료 상태 만으로 KR을 측정하면 실제로 이 일들이 최종적인 목표에 어떤 영향을 미치는지 파악하기 어렵습니다. 이번 분기에 사용자 리텐션을 높이는 것을 목표로 잡고 5가지 기능을 구현하기로 계획을 세운 뒤, KR로 5가지 기능의 완료 상태를 측정하기로 했다고 가정해 보겠습니다. 첫 번째 기능을 빠르게 구현해서 라이브를 했습니다. 이 기능에 대한 사용자 피드백을 받아보니 사용자의 리텐션이 낮아지는 중요한 원인은 다른 곳에 있었습니다. 계획했던 5가지 기능은 이 문제를 해결할 수 없죠. 어떻게 해야 할까요? OKR 달성에 집착해서 원래 계획했던 일에만 집중한다면 OKR 달성률은 높지만 정작 사용자 리텐션은 낮아지는 결과가 생겨날 수도 있습니다.
우리는 KR과 Initiative(계획)를 분리할 필요가 있습니다. 이전 글에서 강조했듯 비전과 전략이 우선이고 로드맵과 계획은 그다음입니다. OKR을 정의했다면 이를 어떻게 추구할 것인지는 Initiative로 구성해야 합니다. Initiative는 상황과 학습 결과에 따라 빠르게 변경될 수 있습니다.
OKR + Initiative 예시:
Objective | Key Results | Initiatives |
---|---|---|
사용자 온보딩과 활성화 경험을 개선한다. | 프로필 작성 완료 비율을 60%에서 85%로 높인다. | • 작성된 프로필이 노출되는 화면을 늘린다. (PRD) • 프로필 기입 필드를 나눠서 단계별로 보여준다. (PRD) |
이런 Initiative와 찰떡궁합인 방법론 중 하나가 PRD(Product Requirements Document)입니다. PRD는 특정 제품 혹은 기능의 요구 사항을 정리한 문서입니다. 제품이 어떤 일을 왜 해야 하는지 정의하는 문서이기도 합니다. PRD는 제품의 목적, 풀고자 하는 문제, 요구 사항, 용례, 제약 사항 등을 포함합니다. 단, 구현 방법이나 UX, 디자인 같은 내용은 팀 내에서 더 좋은 방법을 찾을 수 있게 열어두고 PRD에서는 구체적으로 정의하지 않도록 주의해야 합니다.
이 OKR과 PRD의 조합은 버즈빌 제품팀이 많은 변화 속에서도 꾸준히 실행하려고 노력하고 있는 부분입니다.
지난 3분기 버즈빌에서 가장 많이 회자됐던 책은 ‘빨간 책’이라고 불리던 “성과를 내고 싶으면 실행하라.”였던 것 같습니다. 원제는 4 Disciplines of Execution인데, 번역된 제목이 약간 길고 조악해 보여서 겉표지의 색인 빨간 책이라고 불렀던 것 같네요. OKR을 운영하며 헤매던 부분을 잘 잡아준 책이 아니었나 싶습니다.
저자는 1) 가장 중요한 목표에 집중하라, 2) 선행 지표에 따라 행동하라, 3) 점수판의 강점을 활용하라, 4) 책무를 서로 공유하라 이렇게 네 가지 원칙을 제안합니다. 굉장히 간단해 보이는 원칙이지만 실제로 적용하기 위해서는 단순히 시스템 변경 이상의 노력이 들어갑니다.
버즈빌도 너무 많은 목표와 제어할 수 없는 후행 지표에 고통을 받고 있었습니다. 여전히 어려움을 겪는 부분도 있지만, 버즈빌 리더십 세션 도서로 선정된 이 책 덕분에 굉장히 많은 부분을 개선할 수 있었습니다. 회오리바람이라고 불리는 ‘해야 하지만 가장 중요한 목표 관련 과제는 아닌 업무’를 인정함으로써 오히려 목표를 좁히고 강력하게 추구할 수 있는 환경을 마련했으며, KR을 정할 때 제어할 수 있는 선행 지표를 찾기 위해 노력하게 되었고, 점수판을 통해 누가 언제 보더라도 가장 중요한 목표 관련한 현 상황을 한눈에 파악할 수 있게 되었습니다.
버즈빌 제품팀에서 실행하고 있는 몇 가지 사례를 들어보자면:
아이디어가 가장 싸다. 실행이 전부다. - 피터 드러커
아이디어에 집착하는 것은 사람의 본능인 것 같습니다. 뭔가 좋은 생각이 떠올랐을 때 너무 좋고 뿌듯하죠. 하지만 아이디어에 너무 집착하다 보면 가치를 만드는데 집중하지 못하고 아이디어에 갇히는 상황이 발생하기도 합니다. 고객이 가지고 있는 실제 문제를 해결하지 못하면 좋은 아이디어는 무덤으로 가게 됩니다. 생각한 것보다 더 많은 아이디어를 무덤으로 보내야 하지만, 생각보다 많은 아이디어는 제품화까지 된 다음 제품과 함께 무덤으로 갑니다. 문제보다 해결책에 집중하면 이런 문제가 발생합니다.
기회 솔루션 트리(Opportunity Solution Tree, OST)는 해결책 보다 기회에 집중할 수 있게 도와주는 도구입니다. 목표를 선정하고 목표 달성을 위한 기회를 나열한 뒤 기회 하단에 솔루션을 붙입니다. 우선순위를 선정할 때도 솔루션이 아니라 기회의 우선순위를 정렬하게 됩니다.
OST를 구성할 때 가장 주의해야 하는 부분 중 하나는 ‘기회’가 고객으로부터 시작되어야 한다는 것입니다. 고객 인터뷰 혹은 데이터에서 얻은 인사이트로 기회를 정의하지 않으면 원래 하고 싶었던 솔루션에 기회를 끼워 맞추는 상황이 벌어지기도 합니다. 이 부분이 워낙 쉬운 일이 아니기에 버즈빌에서도 OST를 실행할 때는 매우 주의해서 실행하고 있습니다.
린 스타트업(Lean Startup) 저자 에릭 리에스는 ‘가장 위험한 가정’의 중요성을 얘기합니다. 사업을 실행할 때 가장 위험한 가정을 중심으로 가설을 검증하고 실행해야 한다고 말하죠. 다른 모든 것이 잘 되더라도 가장 위험한 가정 하나가 잘못되면 모든 것이 동작하지 않을 테니까요.
사전 부검(Pre-Mortem)은 과제를 시작하기 전에 미리 미래를 시뮬레이션 함으로써 가장 위험한 가정을 도출하도록 도와줍니다. 성공했다면 왜 성공했을지, 실패했다면 왜 실패했을지 논의해 봄으로써 집중해야 할 부분을 찾는 것이죠.
서비스와 조직이 성장하면서 복잡성은 증가할 수밖에 없습니다. 단기 속도에만 집착해서 개발하다 보면 어느새 전체 조직이 느려지는 상황을 마주하게 됩니다. 노력하지 않으면 팀 간 의존성이 증가하면서 기능 하나를 기획하고 배포하는데도 신경 써야 할 것들이 점점 늘어나기 때문입니다.
팀 토폴로지는 팀이 인지 부하를 줄이고 자율적으로 빠르게 움직일 수 있도록 팀을 구성하는 방식을 제안합니다. Stream-aligned Team (SAT), Complicated Subsystem Team, Enabling Team, 그리고 Platform Team 이렇게 네 가지 형태의 팀을 정의하고, 팀 간 협업 방식을 제안합니다.
버즈빌은 팀 토폴로지를 버즈빌 상황에 맞게 적용하기 위해 노력하고 있습니다. 여러 스테이크홀더와 함께 이벤트 스토밍 워크샵을 진행함으로써 Bounded Context를 정의했고, 역 콘웨이 전략(Inverse Conway Maneuver)에 따라 제품 설계에 맞춘 팀 구성을 추구하고 있습니다. 물론 모든 상황에 동작하는 은총알은 없기 때문에 현재 조직 상황에 맞는 형태로 간소화해서 적용해 나가고 있습니다. 무엇보다도 팀의 구성을 논의하는 사람들이 팀 토폴로지의 개념을 함께 이해하고 논의한다는 것이 매우 중요하다고 생각됩니다.
업무 공유는 단순한 보고 이상의 의미를 가집니다. 업무 공유가 원활할수록 팀의 목표가 전사 목표와 정렬되고, 중심이 흔들리지 않으며, 변화에 빠르게 대응할 수 있습니다. 정렬은 매우 중요하지만 그만큼 소모적이고 어렵기도 합니다. 특히 업무 공유 시 각 청자 관점에서 중요한 부분을 간추리지 않으면 형식적인 보고가 될 가능성이 높습니다. 너무 많은 정보는 정보가 없는 것과 같기 때문입니다.
완벽함이란 더 이상 보탤 것이 남아 있지 않을 때가 아니라 더 이상 뺄 것이 없을 때 완성된다. - 앙투안 드 생텍쥐페리
버즈빌 제품팀은 PPP 형태로 주간 업무를 공유하고 있습니다. 업무 공유 시 OKR 지표를 해석하고, 진행 상황(Progress)을 공유하고, 마주한 문제(Problems)를 설명하며, 차주 계획(Plan)을 정리합니다. 어찌보면 당연한 항목임에도 신경쓰지 않으면 종종 놓치고는 하는데, PPP는 각 항목에 대해서 생각해보게 되는 계기를 마련해줍니다.
KPI, OKR, OMTM 등 목표와 측정 지표를 연결시키기 위한 노력은 매우 많습니다. 북극성 지표는 그중에서도 특히 제품과 비즈니스가 장기적으로 잘 성장하고 있는지 지켜보기 위한 하나의 측정 지표입니다. 북극성 지표는 매출과 연결되어야 하지만 매출이 지표가 되어서는 안됩니다. 매출은 고객이 가치를 구매하기 위해 지불하는 수단이기 때문입니다. 매출이 북극성 지표가 되면 단기적인 관점에서 성장이 장기적인 관점에서 악영향을 미칠 수도 있습니다.
버즈빌은 고객을 기준으로 전사 조직을 디맨드 그룹과 서플라이 그룹으로 나눴습니다. 주 고객이 다르기 때문에 북극성 지표도 달라야 합니다. 서플라이 그룹은 2021년 말 DA팀 리드 Ed의 주도 하에 특정 기준을 만족하는 주간 사용자 수로 북극성 지표를 정의하고 WVU라고 이름 붙였습니다. 해당 기준을 만족하는 사용자가 많아질수록 서플라이 그룹의 퍼블리셔 고객이 얻을 수 있는 가치(주로 광고 수익)가 눈에 띄게 높아지는 것을 확인했습니다. 디맨드 그룹은 북극성 지표를 찾아가고 있습니다. 제품팀 관점에서 특정 기준을 만족한 도달(Reach, 광고를 본 사용자 수)을 북극성 지표로 검토하고 있습니다.
버즈빌 제품팀은 이 밖에도 임팩트 매핑(Impact mapping), 사용자 여정 지도(User Journey Map), 린 고객 개발, 프리토타이핑(Pretotyping), 이벤트 스토밍, Q12 몰입도 조사 등 다양한 방법론을 적용해서 고객에게 더 큰 가치를 제공하고자 노력하고 있습니다. 물론 방법론은 도구일 뿐임을 잊지 않고 방법론의 기반이 되는 원칙과 목적에 집중하기 위해 노력하고 있기도 하고요.
글을 시작한 후 1년이 동안 정말 많은 변화가 있었습니다. 팀의 구성이 바뀌기도 하고, 팀 별 운영 방식이 바뀌기도 했습니다. 조직이 성장하면 성장통이 있기 마련이고, 그럴 때마다 빠르게 학습하고 유연하게 실행함으로써 성장을 가속화할 필요가 있습니다. 버즈빌 제품팀은 지난 1년 동안 이런 변화 속에 정말 많이 배우고 성장했던 것 같습니다.
우리가 일하는 방식이 당연히 유일한 정답은 아닐 것입니다. 하지만 성장 엔진을 구축하는 이 여정은 분명히 정답에 가까울 것입니다. 더 좋은 제품을 만들고 고객에게 더 많은 가치를 전달하기 위해 노력하는 버즈빌 모든 멤버에게 감사 인사를 드립니다. 세상에는 공짜 점심이 없고 은총알도 없죠. 앞으로도 끝없이 학습하며 빠르게 발전하는 버즈빌 제품팀이 되겠습니다. 많은 박수와 응원과 지원 부탁드립니다 🙂
버즈빌은 2023년 한 해 동안 월간 약 1.2억, 연 기준으로 14억에 달하는 AWS 비용을 절약하였습니다. 그 경험과 팁을 여러 차례에 걸쳐 공유합니다. AWS 비용 최적화 Part 1: 버즈빌은 어떻게 월 1억 이상의 AWS 비용을 절약할 수 있었을까 (준비중) …
Read Article들어가며 안녕하세요, 버즈빌 데이터 엔지니어 Abel 입니다. 이번 포스팅에서는 데이터 파이프라인 CI 테스트에 소요되는 시간을 어떻게 7분대에서 3분대로 개선하였는지에 대해 소개하려 합니다. 배경 이전에 버즈빌의 데이터 플랫폼 팀에서 ‘셀프 서빙 데이터 …
Read Article