뱅크샐러드 안드로이드 개발자는 무슨 일을 하나요?

뱅크샐러드 안드로이드 개발자는 높은 복잡도를 가진 서비스를 설계 및 구현하며, 실험을 통해 제품 기능과 성능을 개선합니다. 또 다양한 도구를 활용해 안드로이드 앱의 성능과 품질을 최적화하는 것에 집중하는데요.

뱅크샐러드 내에서 탄탄한 제품 개발을 지속할 수 있도록 다양한 인프라를 구축하고 개선하는 Android 팀의 일상, 함께 살펴볼까요?

뱅크샐러드 Android팀, 무엇이든 물어보세요!

Android 팀의 일상을 소개해 드리기에 앞서, “고객들은 무엇을 궁금해할까?”라는 질문을 던져 보았습니다. 우리가 알리고자 하는 에피소드도 좋지만, 뱅크샐러드에 합류하고 싶은 개발자나 디자이너가, 뱅크샐러드 서비스를 애용하는 유저가 궁금해하는 것들은 무엇인가를 고민하면서 말이죠.

그렇게 누구나 뱅크샐러드 팀에 궁금한 질문을 남길 수 있도록 Survey를 마련했습니다. 응답해 주신 모든 분들께 감사의 말씀을 전하며, 수집된 질문들 중 가장 궁금해 하는 질문 TOP 5에 대한 Android 팀의 답변을 소개해드립니다!

Q. 뱅크샐러드에서 개발 업무를 하며 가장 뿌듯했던 순간은 언제인가요?

A. 새로운 기능이나 개선 사항이 배포된 후, 고객으로부터 긍정적인 피드백을 받을 때 뿌듯해요! 뱅크샐러드는 단순히 개발을 완료하거나 배포하는 순간에 그치지 않아요. 배포 후에도 고객의 피드백과 데이터를 수집하여 분석하고, 고객 관점에서 개선되면 좋을 부분을 적극적으로 찾아 제품을 고도화해나가는데요. 이는 뱅크샐러드 앱 유저를 대상으로 만든 기능뿐 아니라 사내 구성원을 대상으로 한 자동화 및 다양한 개선에 대한 개발의 경우에도 마찬가지입니다.

고객 관점에서의 개선 포인트를 찾기 위해서는 팀원들이 직접 다양한 각도에서 서비스를 이용하며 발굴해내기도 하고, VoC로 유입되는 고객 한 분 한 분의 의견에서 아이디어를 얻어 개선 사항을 논의하기도 합니다. 이러한 과정을 거쳐 서비스가 개선된 후, 고객으로부터 좋은 피드백을 받거나 나아진 지표를 확인하게 되면 ‘고객으로부터 얻은 힌트에서 시작한 개선들이 결국 고객에게 좋은 경험을 선사하는구나’라는 인상적인 경험으로 이어지기도 하죠.

그 뿐만 아니라, 아이디어 및 기능 개발 과정에서 문제점을 찾아내거나 더 좋은 방법을 제안하여 실제 서비스에 적용할 때, 계획한 일정대로 문제없이 일이 착착 진행될 때도 뿌듯함을 느끼는데요. 이러한 제안과 개선, 자동화 방법론이 Android 범위를 넘어 다른 팀에서도 적극적으로 활용되는 때에는 뿌듯함이 배가 되곤 합니다!

Q. 핫픽스, 긴급 변경 사항이 발생 시 스토어를 통하면 늦어지는 경우가 많은데 어떻게 처리하나요?

A. 먼저, 핫픽스나 긴급 변경 사항은 없는 게 가장 좋겠죠. 🥳

하지만 언제나 모든 문제를 통제할 수는 없고, 사람이 만드는 제품이기 때문에 어디에선가 실수가 발생할 수 있어요. 핫픽스 혹은 긴급 변경 사항이 발생될 경우 웹이나 서버 배포에 비해 스토어 업데이트를 통하면 늦어질 수 있어요. 사실 앱 배포를 통한 문제 해결 방법의 더 큰 문제는, 배포되더라도 고객들이 앱을 다운받지 않으면 문제가 해결되지 않는다는 점인데요.

그렇기때문에 가장 중요한 부분은 문제를 경험하고 있는 고객에게 누구보다 빠르게 문제 상황을 공유하고 안내해 드리는 것이라고 생각합니다. 따라서 문제의 원인 파악과 함께 중요도에 따라 필요한 경우에는 고객분들께 미리 안내해 드리는 경우도 있고, 뱅크샐러드의 실험 플랫폼을 이용해 실험 변수를 조정하여 고객 흐름을 되돌려 문제를 즉시 해결하기도 하는데요. 그렇게 되면 실제 수정 작업은 일정대로 진행하며 특정 기능의 검증만 미루어 고객 경험에서의 피해를 최소화할 수 있게 됩니다.

하지만 긴급 변경 사항은 정책 변경, 계약 변경과 같이 코드를 잘못 짠 경우가 아니어도 충분히 발생할 수 있어요. 이런 문제에 유연하게 대처하기 위해서는 변경이 잦을 것으로 예상되는 기능은 웹 뷰 배포나 서버 응답 개선을 통해 즉시 반영이 가능하게 하는 전략을 취할 때도 있지만, 기본적으로는 핫픽스가 필요한 경우가 적을 수 있도록 Android / iOS 에서 배포되는 기능에 대한 Unit / UI Test 등의 커버리지 수준을 높이거나 스토어 점진적 배포 등의 다양한 전략을 취하고 있어요.

Q. Android 팀의 빌드시간, 코드라인 수, 모듈 관리 방식이 궁금해요!

A. 빌드시간의 경우, 최신 맥북 기준으로 개발용 빌드는 3분 정도만에 성공하고, 증분 빌드의 경우 30초 ~ 2분 정도로 모듈에 따라 다릅니다. 원래 이 정도의 속도는 아니었는데, 멀티 모듈 전환과 함께 레거시 코드 제거, 모듈 의존성 개선 작업, M1 빌드 검증 등의 작업을 통해 차근차근 개선해 왔고 지금도 지속적으로 개선하고 있어요.

코드라인 수의 경우, 언어 무관하게 프로젝트 전체를 더해보면 적은 수는 아닌데요. 그중 20% 정도는 자동 생성되는 API 요청 및 응답 코드이고, 20% 정도는 디자인 시스템에서 자동 생성 및 동기화되는 리소스 파일이에요. 네트워크 관련 코드의 경우, protobuf를 한 곳에서 관리하는 idl 리포지터리 글에서 알 수 있듯이 IDL이라는 저장소에서 Protobuf 문법으로 선언한 명세를 각 언어로 변환하고 있어요. Banksalad Android 앱에서는 Client - Server 간에 HTTPS 통신을 하고 있는데요. 기본적으로 Java로 생성되는 Protobuf Generated Code 대신, Kotlin - Retrofit 호환이 되는 Kotlin Generator 를 직접 구현하여 자동 생성하고 있어요. 그래서 통신용 명세가 정의된 코드가 20%가 넘지만, 서버와 호환되는 명세를 코드로 구현하는 수고는 전혀 필요하지 않아요. 언제 어떤 API가 필요해서 구현해야 할지 확인할 필요가 없어요, 이미 모두 코드에 있으니까요. :)

모듈 관리의 경우, 뱅크샐러드에서는 Clean Architecture와 Multi Module을 이용하여 모듈 레이어를 구성하고 있어요. Data, Domain 등의 레이어 별 모듈과 함께 Feature Module에 비즈니스 로직을 담아 재사용성을 챙기며 도메인을 분리하였고, 일부 모듈의 경우에는 라이브러리처럼 독자적인 생명 주기를 가지도록 구성하고 있어요. 또한 Banksalad Product Language용 모듈을 별도로 관리하고 있고, 앱 전반적으로 사용되는 리소스 또한 이곳에서 모두 정의되어 대부분의 경우 Feature Module 의 XML 리소스는 대부분이 레이아웃만 남고, 위에서 자동 생성된다고 이야기한 20%의 리소스 또한 이곳에서 생성하고 있어요.

이외에도 정말 다양한 시도를 통해 개발 생산성을 높이고 있어요. :)

Q. Android 팀, 컴포즈에 대해 어떻게 생각하시나요? 도입한다면 어느 곳 먼저 도입할 예정인가요?

최근 Android Compose 가 1.1.1 버전까지 나왔고, 이제는 꽤 안정적인 모습을 보여주고 있지 않나 생각하고 있는데요, 현재 서비스에 Compose가 적용되어 있지는 않지만 그리 멀리 있지도 않아요. 😉

사실 Android Chapter에서 선언형 UI에 대한 관심은 굉장히 높은 편인데요. Web의 React, iOS의 Swift-UI 뿐 아니라, Figma에서도 Component Swapping이 가능하기 때문에 Android 에서도 내부 컴포넌트가 교체 가능하면서도 구현하는 쪽에서도 선언형 Syntax를 가질 수 있게 하는 방법에 대해 많이 고민했고, 실제로 Compose-like 하게 DSL 문법을 구현하기 위해 Annotation Processor 를 통해 코드가 자동 생성되도록 해 왔기 때문이에요.

현재 Android Chapter는 새로운 기술을 도입할 때, 내부 사람들만 사용하는 기능 및 도구에서 먼저 자유롭게 제안을 하고 검토를 통해 프로덕션에 반영하고 있는데요. 따라서, 먼저 도입한다면 내부에서 활용중인 BPL 샘플 앱이나 사내 도구에서 시작하게 될 가능성이 높아요!

Q. 마지막으로 Android 팀의 인재상이 궁금해요!

A. 저희 뱅크샐러드는 이런 사람들과 함께 하길 고대하고 있어요.

제품의 생산자, 사용자 양쪽 관점에 모두 공감하는 사람
모든 제품에는 생산자와 사용자가 있죠. 크게는 뱅크샐러드를 만드는 개발자와 뱅크샐러드를 사용하는 사용자분들이겠지만, 작게 보면 하나의 함수를 만들고 사용하는 것에도 생산자와 사용자가 있는데요. 어느 쪽이든 반대쪽을 고려하지 않는 순간, 사용자를 생각하지 않는 제품이 되거나 돌이킬 수 없는 기술 부채를 만들게 될 수 있어요. 코드와 제품을 만드는 것은 한순간이지만, 읽히고 쓰이는 것은 수백 수만 번일 수 있기에, 사용자의 니즈를 파악하고 커뮤니케이션을 통해 조율하고 합의할 수 있는 분과 함께 일할 수 있다면… 그건 정말 행복이죠!

솔직함, 높은 오너십과 가시성을 가진 사람
우리는 제품을 만드는 과정에서 다양한 직군과 배경을 가진 사람들과 협업해요. 그렇기 때문에 각 팀에서 자신의 전문성을 통해 높은 오너십을 가지면서도, 서로 아는 것과 모르는 것을 투명하게 공유하여 서로가 서로에게 배움을 주며 성장할 수 있는 분들과 함께 일하고 싶네요! 이런 성장을 위해서는 솔직한 관찰과 피드백이 필수적인데요. 상대방을 존중하고 배려하면서 때로는 동료의 성장을 위해 솔직한 피드백을 주고받을 수 있는 문화에 더 좋은 에너지를 보태 주실 수 있는 분들을 언제든지 환영합니다!

익숙함 속에서도 낯선 시각으로 개선점을 찾아낼 수 있는 사람
보통은 현재 팀이 가진 루틴과 프로세스를 당연하게 생각하기 마련이고, 이런 부분이 새로운 제안과 변화에 대한 방해 요소로 작용하는 경우가 많아요. 하지만 우리는 스타트업이고, 대부분의 루틴이나 프로세스의 수명이 엄청나게 길진 않아요. 즉, 지금의 루틴과 프로세스보다 더 나은 방법을 언제나 찾을 수 있다는 것이죠. 익숙해진 현재를 낯선 시각으로 바라보며 더 나아질 수 있는 가능성의 조각을 발견하고, 그것을 현실에 반영하는 기술 역량이 합쳐진다면 무슨 일이든 해낼 수 있지 않을까 싶네요!

마치며

뱅크샐러드 Android 팀에 대한 궁금증은 많이 해소되셨나요? 뱅크샐러드 Android 팀에는 언제나 변화를 시도하고, 행동하고, 피드백을 통해 더 나은 방법을 찾아내는 주도적인 분들이 많습니다. 특히 제품 개선과 개발 생산성 증대를 위해 다방면으로 활약하는 모습을 자주 관찰할 수 있는데요.

든든한 팀원들과 함께 고객을 위한 제품을 만들어가고 싶은 분들은 아래 버튼을 클릭하여 채용 사이트도 방문해주세요. 채용 중인 다양한 포지션과 뱅크샐러드가 일하는 방식도 확인할 수 있습니다! 좋은 인연으로 만나 뵙길 바라며 오늘은 여기서 이만 인사드립니다. 감사합니다. :)