버즈빌 안드로이드 개발자는 이렇게 일합니다

Image not Found

안녕하세요, 버즈빌 Output 팀의 Dio입니다.

버즈빌의 주요 제품 중 하나는 광고 지면을 모바일 플랫폼(안드로이드, iOS)에 쉽게 적용할 수 있는 SDK이고 이를 통해 Native, Interstitial, Feed, Lockscreen 등의 지면을 제공합니다. 버즈빌의 안드로이드, iOS 개발자는 바로 이 SDK의 개발을 책임지게 됩니다. 일단 앞서 소개해 드린 광고 지면을 개발하며 UI/UX를 개선하는 것이 첫 번째 역할이고, 새로운 광고 지면이나 UI도 주기적으로 탐색합니다. 그리고 이런 기능을 모바일 디바이스에서 효율적으로 제공하기 위한 노력도 지속하며, 동시에 매체사의 다른 개발자나 기획자 같은 SDK의 고객이 어떻게 하면 SDK를 편하게 사용할 수 있을지도 계속 고민합니다. 또한 이런 지면들을 활용해 버즈빌에서 직접 만든 앱인 허니스크린도 운영하고 있고, 이를 통해 실제 앱 사용자 경험도 개선합니다. 이번 글에서는 버즈빌의 안드로이드 개발자가 이런 제품들을 개발하기 위해 어떻게 일하는지를 소개해 드리려고 합니다. 제가 주로 담당하는 안드로이드 개발 과정을 중심으로 서술한 글이지만, iOS 개발자의 일하는 방식도 이와 흡사하기 때문에 iOS 개발자분들께도 흥미로운 내용이 많으리라 생각합니다.

Feed 지면의 예시


SDK 개발 프로세스

버즈빌 안드로이드 개발자들은 주로 스프린트 방법론을 기반으로 한 과정으로 업무를 진행합니다. 스프린트는 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를 작성해 코드 리뷰 요청 이전에 주변 개발자 동료들과 먼저 논의를 시작하기도 합니다.

신규 입사자의 첫 PR을 격렬히 환영하는 의미로 88개의 댓글이 달리며 코드 리뷰가 진행되는 현장

코드 리뷰 규칙에 대해서도 간단히 소개해보겠습니다. 버즈빌 코드 리뷰의 규칙은 기본적으로는 구글에서 제시하는 코드 리뷰 가이드를 따릅니다. 하지만 이 가이드의 모든 규칙을 엄격하게 따른다기보다는 그 안에 담긴 철학과 원칙을 중요하게 생각합니다. 또한 버즈빌 내부 상황에 맞게 수정하거나 추가해서 사용하는 규칙도 있으며, 각 팀의 상황에 맞게 일부 변형한 관례를 적용하기도 합니다. 예를 들어 위의 스크린샷에서 “[OUT-840]”은 Pull Request를 Jira card와 연결하기 위해 Pull Request 제목에 붙이는 접두사입니다.

마치며

지금까지 버즈빌 안드로이드 개발자가 일하는 방식에 대해 간략하게 소개해드렸습니다. 짧은 글을 통해 저희가 일하는 방식을 온전히 소개해드리는 것은 어려운 일이지만, 그래도 이 글을 통해 버즈빌 개발자의 일하는 방식을 조금이나마 느끼셨으면 좋겠네요. 애드테크, SDK 개발 등 일반적으로 접하기 힘든 일들을 해나가는 저희의 일하는 모습을 앞으로도 자주 소개해드리도록 하겠습니다. 지금까지 읽어주셔서 감사합니다.

버즈빌 개발자 지원하기 (클릭)

버즈빌 테크 리크루터와 Coffee Chat하기 (클릭)

You May Also Like

post-thumb

배포를 안전하게 - 카나리 배포, 롤백

배포에서 속도와 안전성 두 마리 토끼를 잡기란 쉽지 않습니다. 이 글에선 버즈빌에선 어떻게 안전성 문제를 해결했는지 소개합니다. 배포를 우아하게 - 원-클릭 배포 배포를 안전하게 - 카나리 배포 전략, 롤백 배포를 빠르게 - DIY(Deploy It Yourself) …

Read Article
post-thumb

배포를 우아하게 - 원-클릭(one-click) 배포

일반적으로 런타임 환경이 늘어날 수록 배포 시스템의 복잡성은 높아지기 마련입니다. 이 글에선 버즈빌에선 어떻게 문제를 해결했는지 소개합니다. 배포를 우아하게 - 원-클릭 배포 배포를 안전하게 - 카나리 배포 전략, 롤백 배포를 빠르게 - DIY(Deploy It …

Read Article
버즈빌, 아마도 당신이 원하던 회사!

지원하기