원점에서 다시 멋진 모바일 엔지니어링 팀 만들기
Joining MyRealTrip
저는 백엔드 엔지니어를 시작으로 안드로이드 시니어 엔지니어를 거쳐 모바일 팀 리더가 되었으며, 17년 동안 다양한 경험을 쌓은 후 마이리얼트립에 입사하게 되었습니다. 신종 코로나바이러스 감염증(COVID-19)의 2차 대유행으로 인해 여행업계는 힘든 시기를 보내고 있었지만, 저를 포함한 많은 지인분들이 여행에 목말라 있었고 언젠가는 돌아올 여행업을 위해서 새로운 도전이 큰 의미가 있을 거라는 믿음이 있었습니다. 그리고 여행 테크 플랫폼 회사로서 진화하려는 마이리얼트립의 비전 또한 많이 공감할 수 있었으며 회사의 적극적인 투자유치 및 국내/해외여행의 시장규모를 생각해 볼 때 꽤 매력적으로 느껴졌습니다.
Reforming Mobile Engineering Team
2020년 12월, 마이리얼트립에 입사하면서 모바일 엔지니어링 팀(이하 모바일 팀) 리더를 맡게 되었습니다. 모바일 팀을 비롯해 많은 팀 구성원들의 큰 기여로 비즈니스가 지속적으로 성장해 왔고, 더 나은 시스템을 구축하기 위해 새로운 목표를 가지고 팀 빌딩이 필요한 시기였습니다. 하지만 아쉽게도 COVID-19의 장기화로 인해 재택 근무가 일상이 되었고, 이로 인해 팀 구성원들간의 소통은 부족했고 저를 포함한 신규입사자분들의 온보딩, 업무인수인계, 프로젝트 진행이 원활히 진행되기 힘든 상황이었습니다. 아마도 코로나 시국에 많은 회사들이 이러한 고충을 겪고 있을거라고 생각되고, 마이리얼트립도 다르지 않았습니다.
카이젠(Kaizen) 경영 철학의 구루인 이마이 마시키에 의하면 도요타 같이 린을 적용하는 기업에서 모든 관리자들은 하루에 1시간정도 현장에 낭비가 있는지 확인하러 갈 필요가 있다고 하였습니다. 이것은 실제로 현장 주변을 돌아다니라는 것이 아니라 현장이 어떻게 운영되고 있는지를 확인해 보라는 것이며, 그냥 지나치면서 보는 것이 아니라 한군데를 잡고 오랜 시간 관찰해보는 것(Muda Walk)입니다. 그리고 여러가지 관점에서 현재 가치 흐름의 상태를 이해하고 프로세스들에서 낭비를 찾아내는 지속적인 개선 리스트(Gemba Walk)를 만들 수 있습니다.
앞으로 건강하고 멋진 엔지니어링 팀을 만들고 원 팀으로서 끈끈한 관계를 유지하기 위해 자체적인 기술논의 및 백엔드 엔지니어들간의 소통도 활발하게 진행할 수 있는 방안들이 필요했고 우리가 효율적으로 업무를 진행하기 위해서 무엇을 개선하면 좋을지 지속적으로 관찰을 하기로 하였습니다. 예측할 수 있는 것들을 최대한 사전에 방지하고, 예측할 수 없는 것들은 빠르게 인지하는 방법을 찾기 위해 우리는 지금 어느 지점이 서 있는지 확인이 필요했습니다. 이에 적합한 로드맵을 팀 구성원들과 함께 논의하여 정하게 되었고 최우선으로 아래와 같은 프로세스들을 개선하고자 집중하였습니다.
- 비정기적 모바일 배포
- 리소스가 고려되지 않은 업무 배정 & 불분명한 업무 프로세스
- 서비스 메트릭의 부재
1. Policies
첫째, 정기배포 일정을 전사에 공유하고 이에 따라 개발 — QA — 배포가 이루어지도록 프로세스를 확립하였습니다. PO분들을 비롯하여 많은 분들이 모바일 애플리케이션(이하 모바일 앱) 릴리즈 시점에 대한 문의가 지속적으로 들어왔고, 정해지지 않은 배포일정으로 추가적인 스펙을 수시로 요청 받거나 웹 배포 일정과 겹치는 등 명확하지 않은 공유로 인해 서비스 예측이 쉽지 않았습니다. 이러한 모바일 배포에서 커뮤니케이션/운영의 비효율적인 부분을 개선하고자 하였습니다.
둘째, 높은 유지보수비용을 줄이고 빠른 대응이 가능하도록 모바일 배포 정책을 보완했습니다. 자동 업데이트 및 특정기간 업데이트율을 확인하고, Production에 유지할 앱 버전의 개수를 제한하는 등 모바일 배포 프로세스를 개선하였습니다. 더불어, 새롭게 추가된 혹은 업데이트된 모든 기능들을 집중하여 현재는 단일 QA 프로세스로 구축하고 있지만 추후에는 도메인 서비스별로 병렬로 테스트할 수 있는 환경을 제공할 수 있도록 준비할 예정입니다. 그리고 모바일 앱 릴리즈 이후 발생하는 이슈들을 빠르고 효율적으로 대응하기 위해서 크리티컬한 Funnel을 정의하고 중요도, 치명도를 구분하여 이를 적용하였습니다.
- 앱 버전별 선택/강제 업데이트
- 커뮤니케이션이 없어도 예측 가능한 앱 릴리즈 날짜
- 제한적인 Production 버전관리
- Old API deprecation
- 중요도, 치명도에 따른 장애 정책/이슈 대응
2. Tech Stack
프로젝트 아키텍처의 alignment는 팀 빌딩을 할 때 중요한 부분 중 하나입니다. 악명 높은 안티 패턴인 갓(God) 클래스/오브젝트(너무 많은 일을 하면서 매우 복잡해서 더 이상 아무것도 건드릴 엄두를 내지 못하는 클래스)를 벗어나 관심사의 분리(Separation of concerns)를 통해 여러 구성원들이 함께 유연한 시스템을 만들어 가야합니다. MVC/MVP/MVVM/MVI 각각의 패턴의 장단점을 이해하고 팀 구성원들이 생각하는 MV* 패턴의 역할을 함께 정의해보며 엔지니어들간의 Gap을 줄여야 합니다.
단순히 ‘트랜디한 MVI를 적용해 봅시다’ 보다는 우리가 생각하는 MVVM은 Clean Architecture와 함께 Model(Repository+Use case), View(Event Handling) 그리고 ViewModel(Dispatching)이라는 명확한 원칙을 제시하고 Testable한 코드, 재활용할 Components 등을 분리하는 등 면밀한 논의를 통해 우리는 사례와 샘플코드로 서로의 생각의 차이를 점차적으로 줄여가고 있습니다.
그 뿐만 아니라 관심사의 분리, 기능별 리패키징, 유닛테스트, 성능측정, AB 테스트, 모듈화, 시스템 자동화, 디자인 시스템 등의 다양한 주제에 대해서 지속적인 논의와 앞으로의 로드맵을 그리고 있습니다. 이후 포스팅에서 관련 토픽들을 하나씩 구체적으로 다루어 보도록 하겠습니다.
3. Workflow
요즘 엔지니어들은 코드 리뷰 프로세스에 대해 잘 알고 있을거라고 생각합니다. 코드 리뷰는 앞으로 반영될 코드를 다른 엔지니어에게 요청하여 코드를 점진적으로 검토하고 이를 개선하여 코드를 푸시할 때 모두가 더 편안함을 느낄 수 있게 합니다. 하지만, 현실은 그렇지 않다는 경험을 마이리얼트립에서도 비슷한 사례로 겪을 수 있었습니다.
많은 코드의 수정이 이미 발생했고 QA와 릴리즈 시간이 얼마남지 않은 상황에서 동료 엔지니어의 피드백이 좋지 않았다면 이를 되돌리기에는 또 다른 리스크가 되기도 합니다. 그리고 해당 코드의 배경지식이 없는 엔지니어에게 코드 리뷰를 요청해 진행할 경우 코드 리뷰가 지연이 되거나 코드 리뷰를 형식적으로 진행하는 경우들도 쉽게 찾아볼 수 있습니다.
이를 개선하고자 기능(설계) 리뷰 단계를 두어 구현 이전에 동료 엔지니어와 함께 신규 기능을 이해하고 이에 대해 논의할 시간을 충분히 가지고 올바른 방향의 구현방식을 결정하고 이를 토대로 업무 일정을 산정하도록 하였습니다. 기능 리뷰 단계를 도입하자 전반적으로 코드의 품질이 올라갔고 특히 새로 개발되는 Feature에 대해 실제 개발에 참여하지 않은 개발자들의 이해도가 높은 수준으로 올라가는 변화가 있었습니다. 이로 인해 기존에는 주로 비즈니스 로직만 확인하던 피상적인 코드 리뷰에서 이제는 해당 기능이 왜 들어갔고 어떠한 역할을 하는지에 대해 좀 더 깊은 이해를 가지게 되는 긍정적인 효과가 있었습니다.
4. Onboarding
마이리얼트립에는 버디(동료 엔지니어) 프로그램을 통한 온보딩 프로세스가 있습니다. 버디는 신규입사자에게 회사소개, 개발환경 셋팅 및 업무 인수인계를 진행하고, 오피스 투어, 팀원과 함께 점심식사, 티타임 등을 통해 친밀감을 높이고 회사에 안정적으로 적응할 수 있도록 합니다.
하지만, COVID-19로 인해 재택근무가 일상이 된 시기에 버디 프로그램이 원활하게 진행되기가 쉽지 않았습니다. ‘궁금하신 게 있으면 언제든지 편하게 물어보세요.’라는 친절하게 말씀해주셨지만, 코로나 시국에 입사한 저 또한 신규입사자로서 옆자리에서 쉽게 물어볼 수 있는 것들 조차 미팅을 요청하거나 지속적으로 질문하는 것에 대한 미안함을 갖게 되고 무엇을 물어봐야할지 그 자체를 고민하는 시간이 길어지는 부분들이 힘들었습니다.
이를 개선하고자 단계별로 신규입사자들이 알아야할 기술/비기술 토픽들을 날짜별로 체크리스트를 제공하여 몇 주에 걸쳐 여러 단계의 미션을 클리어하고, 버디들과 정기적인 미팅을 하며 최종적으로 기능개발 shadowing 혹은 SUS following을 통해 마이리얼트립의 적응이 아니라 구성원으로 소프트 랜딩(Soft-landing) 할 수 있도록 하고 있습니다.
5. Resolving root cause with technology
우리는 엔지니어로서 주어진 문제를 해결할 때, 단순히 기능개발을 하기보다는 확장가능하고 안정적인 시스템을 만들기 위해 노력해야합니다. 그러기 위해서는 우리 시스템의 문제점이 어디에 있는지 정확히 알아야 합니다. 소화가 잘 되지 않는데, 두통약을 먹으면 해결할 수 없듯이 아픈 부위를 찾아서 올바른 처방, 즉 기술적으로 이를 개선해야 합니다.
마이리얼트립은 로그데이터의 중요성을 인지하고 자체 로그 플랫폼을 통해 로그를 수집 하고 있으며, 기본적인 활성 사용자 수(Active User), Crash-free rate 지표 뿐만 아니라 각 핵심 Funnel들의 지표를 구성하여 컨디션을 모니터링할 수 있도록 하였습니다. 모바일 앱 릴리즈 이후에 움직이는 지표를 확인함으로서 성과 기여도를 확인할 수 있었고, 예상하지 못했던 트랜드를 캐치하기도 하고 이슈들을 확인 할 수 있게 되었습니다.
더 나아가 지표를 통해 고객이 가장 많이 사용하는 대표적인 화면의 성능이 기대하는 만큼 나오지 않는다는 것을 알게 되었습니다. 이는 API를 비롯해 모바일 앱의 구조가 뒷받침되지 않아서 고객에게 제공되는 기능들을 추가할 때마다 성능이 느려질 수 밖에 없다는 것을 확인할 수 있었고 우리는 이를 해결하기 위해 Server-driven UX를 도입하는 등 문제의 근본 원인을 찾아 기술력으로 이를 해결하고 있습니다. 그리고 매주 지표들을 팀 구성원들과 함께 확인하며 모바일 서비스의 상태를 진단하고 앞으로의 방향성을 함께 공유합니다. 이를 통해 팀 구성원들 스스로 서비스에 대한 책임감과 소유권(Ownership)을 가지고 업무를 임할 수 있도록 노력하고 있습니다.
6. Technical and Life Growth
보통 대부분의 회사에서의 업무는 기획으로부터 시작되고 엔지니어링 팀은 이를 잘 구현하기 위한 목적조직으로 이루어집니다. 우리는 조금 더 주도적으로 움직이기 위해 플랫폼별로 조직을 구성하고, 단순히 주어진 개발업무만 진행하는 것이 아니라 사용 중인 프로젝트 아키텍처의 개선점을 논의를 하기도 합니다. 앞으로 Dynamic UX를 제공하기 위한 방안, 그리고 데이터 로깅을 손쉽게 남길 수 있는 방법 등의 모바일 플랫폼을 개선하고 이로 인해 효율적인 모바일 앱을 제공하기 위해 노력하고 있습니다. 또한 새롭게 런칭된 OS의 신규 기능들을 공유하고 흥미로운 기능들을 개발하기 위한 아이디어 회의를 요청하기도 하고, 개발시 좋은 Tip들을 공유하거나 컴퓨팅에 효율적인 앱을 전파하기도 합니다.
또한 팀 구성원들은 가족 다음으로 일상생활에서 많이 마주치며 생활하는 사람들로서 개발적인 주제 외적으로도 트랜디한 토픽들, 메타버스 등과 같은 흥미로운 IT 기술에 대한 토픽들, 재무관점에 우리가 알아야할 것들 등을 서로 공유하며 다양한 각도에서 서로의 시야를 넓힐 수 있도록 장려하고 있습니다. 2021년 현재까지 우리는 70여건의 개발/비개발 관련에 토픽을 공유하며 하루하루를 성장하고 있습니다.
The Secret to a Successful Engineering Team
‘좋은 팀장이란 어떤 팀장일까요?’ 긴 시간 동안 팀장으로서 업무를 진행해 왔지만 저 역시 좋은 팀장으로 성장하기 위해 항상 고민하고 팀 구성원들과 많은 이야기를 나누고 있습니다. 먼저 마이크로매니징(Micromanaging)을 줄이고 명확한 목표와 제한된 조건(가용한 리소스 등)을 명시함으로서 지속적인 명료한 커뮤니케이션을 통해 공감대를 형성해야한다고 생각합니다. 그리고 신뢰감과 책임감을 보여주고 구성원들에게 소유권을 갖도록 함으로써 설령 잘못된 의사결정을 내리더라도 어떻게 수습하고 성장할 수 있는지 가이드 하는 것이 필요합니다. 또한 구성원들에게 강요하기 보다 스스로 먼저 고민하고 실행할 시간을 보장하여 창의성을 발휘할 공간을 남겨둘 필요가 있습니다. 방임이 아니라 위임하고 지속적인 피드백을 제시하며 원팀(One Team)으로 가는 길을 제시하려고 합니다.
3. Workflow에서 소개한 것처럼 높은 코드 품질을 유지하고 발생할지 모를 리스크를 줄이기 위해, 팀 구성원들에게 코드 리뷰를 넘어 기능 리뷰 프로세스를 가이드하고 있습니다. 최근에는 코드 리뷰 프로세스를 지키려는 회사들이 많이 있습니다. 하지만, 원칙이 없거나 형식적인 코드 리뷰를 진행하거나 혹은 잘못된 설계로 인해 돌이킬 수 없는 코드(일정으로 인해)와 접할 수 있습니다. 이를 최소화하기 위해서 도메인/레거시 시스템의 이해도가 높은 엔지니어와 미리 논의를 하고 방향성을 찾는 게 필요하다고 생각합니다. 누군가는 시간 낭비일 뿐이라고 기능 구축에 집중해야한다고 이야기 할 수 있지만, 확장성, 안정성 등 미래를 염두하는 것이 우리에게 얼마나 중요한지는 아무리 강조해도 지나치지 않습니다. 물론 일부 프로젝트는 더 빠르게 속도를 내야하는 프로젝트가 있겠지만, 가장 빠르게 생산성을 높을 수 있는 길은 바른 길로 가는 것이라고 확신합니다.
공감대의 형성, 지속적인 피드백, 기능/코드 리뷰 등은 모두 대화에서 비롯합니다. 다른 동료 엔지니어들은 어떻게 생각하는지 파악하고, 나의 생각을 공유하면서 팀 구성원들간의 신뢰를 쌓을 수 있을거라고 생각합니다. 서로 건설적인 피드백을 주고 받으며 앞으로 발생할 수 있는 상황들을 미리 예측하고 이에 대한 후속 조치를 함께 고민하는 것을 장려하고 있습니다. 한 명이 단독적으로 혁명적인 일을 해내는 것도 중요하지만, 그 혁명을 만들어가는 과정 혹은 그 이후에 더 뛰어난 방법을 도출하여 서로 윈윈하는 개발문화를 만들어 나아가는 것이 장기적으로 팀에 큰 힘이 될 수 있습니다.
모바일 팀은 제가 입사한 이후로 2021년 9월초 현재 팀원 10명이 되었고, 10월 중순 입사확정자를 포함하면 약 15명 이상 규모의 팀이 될거라고 예상하고 있습니다. 모바일 팀의 슬로건 ‘Reinvent Travel By Effortless Mobile Experience’에 걸맞게 손쉬운 모바일 경험을 통해 여행을 혁신할 준비를 하고 있습니다.
To close…
마이리얼트립이 트래블 테크 플랫폼 회사로 진화하기 위해서는 아직 시간이 필요하다고 생각합니다. 전/현 모바일 팀을 리딩하면서 배웠던 모범 사례들을 모든 엔지니어링 팀에 전할 수 있도록 노력하면서, 하루가 다르게 빠르게 발전하는 신기술들을 어떻게 현실적으로 우리의 시스템에 도입을 할 수 있을 지 함께 고민하고 있습니다. 그리고 지금까지 해 오던 방식을 뛰어 넘어 새로운 세대의 뛰어난 엔지니어들과 팀을 성장시킬 수 있을거라는 기대감을 가지고 있습니다. 저희 팀 구성원들이 저보다 훨씬 더 잘할 거라고 믿어 의심치 않습니다. 모바일 팀에서 함께 마이리얼트립 서비스와 팀을 성장시킬 분들의 많은 지원 바랍니다. :)
마이리얼트립은 지금 슈퍼채용 중! (~2021년 9월 30일까지) https://super-recruit.myrealtrip.com/
