AWS 비용 최적화 Part 1: 버즈빌은 어떻게 월 1억 이상의 AWS 비용을 절약할 수 있었을까
버즈빌은 2023년 한 해 동안 월간 약 1.2억, 연 기준으로 14억에 달하는 AWS 비용을 절약하였습니다. 그 경험과 팁을 여러 차례에 걸쳐 공유합니다. AWS 비용 최적화 Part 1: 버즈빌은 어떻게 월 1억 이상의 AWS 비용을 절약할 수 있었을까 (준비중) …
Read Article안녕하세요, 버즈빌 Output 팀의 Dio입니다.
버즈빌의 주요 제품 중 하나는 광고 지면을 모바일 플랫폼(안드로이드, iOS)에 쉽게 적용할 수 있는 SDK이고 이를 통해 Native, Interstitial, Feed, Lockscreen 등의 지면을 제공합니다. 버즈빌의 안드로이드, iOS 개발자는 바로 이 SDK의 개발을 책임지게 됩니다. 일단 앞서 소개해 드린 광고 지면을 개발하며 UI/UX를 개선하는 것이 첫 번째 역할이고, 새로운 광고 지면이나 UI도 주기적으로 탐색합니다. 그리고 이런 기능을 모바일 디바이스에서 효율적으로 제공하기 위한 노력도 지속하며, 동시에 매체사의 다른 개발자나 기획자 같은 SDK의 고객이 어떻게 하면 SDK를 편하게 사용할 수 있을지도 계속 고민합니다. 또한 이런 지면들을 활용해 버즈빌에서 직접 만든 앱인 허니스크린도 운영하고 있고, 이를 통해 실제 앱 사용자 경험도 개선합니다. 이번 글에서는 버즈빌의 안드로이드 개발자가 이런 제품들을 개발하기 위해 어떻게 일하는지를 소개해 드리려고 합니다. 제가 주로 담당하는 안드로이드 개발 과정을 중심으로 서술한 글이지만, iOS 개발자의 일하는 방식도 이와 흡사하기 때문에 iOS 개발자분들께도 흥미로운 내용이 많으리라 생각합니다.
버즈빌 안드로이드 개발자들은 주로 스프린트 방법론을 기반으로 한 과정으로 업무를 진행합니다. 스프린트는 2주 주기로 진행되며, 한 스프린트가 종료되면 실행 가능한 SDK와 앱을 빌드합니다. 빌드가 나온 후에는 QA 과정이 이어지며, QA가 완료된 이후에는 버즈빌에서 직접 운영하는 앱에서부터 실제 배포를 진행합니다.
버즈빌에서는 계층 기반으로 팀이 구성되어 있습니다. 그래서 안드로이드 개발자들도 제품에 따라 여러 팀에 나뉘어 소속됩니다. 각 팀에서는 팀의 장단기 목표에 맞게 매 스프린트마다 할 일을 계획하고, 개발자들도 팀원으로서 계획에 참여하며 각자의 목표를 합의하고 설정합니다. 목표가 정해지면 2주간 스프린트를 진행하게 되며, 스프린트가 완료되면 그다음 주에 새로운 버전의 빌드를 만들고 QA 단계로 넘어가게 됩니다.
앱 빌드와 SDK 배포는 백엔드에서의 배포와 마찬가지로 ChatOps를 활용합니다. 슬랙에서 예약된 커맨드를 입력하면 botkit 기반으로 개발된 내부 챗봇 서비스에 해당 요청이 전달되어 CI 서비스를 통해 앱 빌드나 SDK 배포가 시작됩니다.
버즈빌의 안드로이드 프로젝트는 하나의 저장소에 여러 모듈이 포함된 <모노 리포 - 멀티 모듈> 구조로 구성되어 있습니다. 이 과정에서 Pull Request를 테스트하거나 SDK 라이브러리를 배포하는 데에는 고려할 사항이 매우 많은데요, (예시: 멀티 모듈 SDK 버전 관리) 이런 부분에 필요한 로직을 직접 구성한 Gradle task나 CI 서비스, 그리고 배포 파이프라인에 직접 개발하여 사용하고 있습니다.
앞서서 언급했듯이 기본적인 팀 구조는 계층 기반으로 구성되어 있지만 같은 직무의 개발자들끼리도 항상 교류하며, 안드로이드 그리고 iOS 개발자들도 가깝게 소통합니다. 1~2주에 한 번씩 정기적인 미팅을 통해 코드의 중요한 변경 점이나 흥미로운 이슈 및 해결 과정, 그리고 설계에 대한 고민 등을 공유하며 논의합니다. 새로운 기술에 관한 관심도도 전반적으로 높아서, 정기적인 미팅에서 개발자들이 소개하거나 자유롭게 스터디를 조직해서 조금 더 깊게 새로운 기술을 탐색합니다. 이렇게 학습한 기술은 치열한 검토 후에 실제 제품에도 적용됩니다.
코드 리뷰도 버즈빌의 중요한 개발 문화입니다. 개인적으로는 활발한 코드 리뷰를 운영하는 데 가장 중요한 것은 규칙보다도 문화라고 생각하는데, 버즈빌은 이 문화가 아주 잘 정착되어 있습니다. Pull Request 작성자는 코드 리뷰를 철저히 받기 위해 최대한 많은 정보를 Pull Request에 담으려 하고, 리뷰 요청을 받은 개발자도 꼼꼼한 리뷰를 하기 위해 최대한 노력합니다. 코드 구조나 디자인 패턴에 대한 고민과 설계가 필요한 상황이라면, Draft Pull Request를 만들거나 간단한 Design Document를 작성해 코드 리뷰 요청 이전에 주변 개발자 동료들과 먼저 논의를 시작하기도 합니다.
코드 리뷰 규칙에 대해서도 간단히 소개해보겠습니다. 버즈빌 코드 리뷰의 규칙은 기본적으로는 구글에서 제시하는 코드 리뷰 가이드를 따릅니다. 하지만 이 가이드의 모든 규칙을 엄격하게 따른다기보다는 그 안에 담긴 철학과 원칙을 중요하게 생각합니다. 또한 버즈빌 내부 상황에 맞게 수정하거나 추가해서 사용하는 규칙도 있으며, 각 팀의 상황에 맞게 일부 변형한 관례를 적용하기도 합니다. 예를 들어 위의 스크린샷에서 “[OUT-840]”은 Pull Request를 Jira card와 연결하기 위해 Pull Request 제목에 붙이는 접두사입니다.
지금까지 버즈빌 안드로이드 개발자가 일하는 방식에 대해 간략하게 소개해드렸습니다. 짧은 글을 통해 저희가 일하는 방식을 온전히 소개해드리는 것은 어려운 일이지만, 그래도 이 글을 통해 버즈빌 개발자의 일하는 방식을 조금이나마 느끼셨으면 좋겠네요. 애드테크, SDK 개발 등 일반적으로 접하기 힘든 일들을 해나가는 저희의 일하는 모습을 앞으로도 자주 소개해드리도록 하겠습니다. 지금까지 읽어주셔서 감사합니다.
버즈빌은 2023년 한 해 동안 월간 약 1.2억, 연 기준으로 14억에 달하는 AWS 비용을 절약하였습니다. 그 경험과 팁을 여러 차례에 걸쳐 공유합니다. AWS 비용 최적화 Part 1: 버즈빌은 어떻게 월 1억 이상의 AWS 비용을 절약할 수 있었을까 (준비중) …
Read Article들어가며 안녕하세요, 버즈빌 데이터 엔지니어 Abel 입니다. 이번 포스팅에서는 데이터 파이프라인 CI 테스트에 소요되는 시간을 어떻게 7분대에서 3분대로 개선하였는지에 대해 소개하려 합니다. 배경 이전에 버즈빌의 데이터 플랫폼 팀에서 ‘셀프 서빙 데이터 …
Read Article