다짐 - 운동할 땐 다짐부터
작년 11월부터 국내 1위 운동시설 플랫폼 다짐을 서비스하는 스톤아이에 신입개발자이자 유일한 앱 개발자로 합류했다. 사실 나는 스톤아이에 합류하기 전부터 다짐을 이용해왔던 '찐고객'이었다. 가격이 투명하게 공개되어 있고, 헬스장 여러군데를 사실상 한 곳 가격으로 이용할 수 있다는 점이 당시 내 페인포인트를 정확하게 충족시켜줬기 때문이다. 그렇게 하루종일 운동과 코딩만하며 RN 개발자를 지망하고 있던 나는 우연히 채용플랫폼에 올라온 스톤아이의 구인공고를 보게 되었는데, '내가 좋아하는 서비스를 직접 개발하고 싶다'라는 심정으로 넣은 지원서가 합격으로 이어질거라곤 당시에는 정말 몰랐다. (근데 직원이라서가 아니라 다짐 진짜 좋음)
다짐이 기술 전환을 결정한 이유
메인 프로덕트인 다짐의 개발자로 일하는 상상을 하며 지원서를 넣었는데, 정작 스톤아이가 나에게 기대하는 업무는 다짐의 관리가 아니었다. 스톤아이는 4개의 모바일 앱을 서비스하고 있었는데, 그 중 다짐은 kotlin과 swift로 작성된 네이티브 앱이었고, 다짐매니저 관리자용 앱은 ionic capacitor로 제작된 웹앱이었으므로 자연스럽게 나는 RN으로 제작된 '다짐매니저 회원용 예약앱'과 '다짐파트너'를 담당하게 될 예정이었다.
사실 객관적으로 생각해보면 신입개발자로서 꽤나 좋은 환경이었다. 내가 담당하게 될 다짐매니저 회원용 예약앱과 다짐파트너는 특수한 사용자들을 타겟으로 만들어진 서비스이기 때문에 사용자수가 많지 않은 편이다. 즉, 기능을 구현하고 배포하는데 있어서 상대적으로 부담이 적었다. 서비스 사이즈 자체가 큰 편도 아니라 주어진 시간 안에 필요한 코드를 파악하기에도 수월했다. 무엇보다 코드 스타일이나 기술 스택 선정에 있어서 내 의견이 적극 반영됐기 때문에 마음껏 쓰고 싶은 코드를 쓸(쌀) 수도 있었다. 하지만 그럼에도 불구하고 다짐을 향한 미련은 마음 한켠에 남아 사라지지 않고 있었다.
다시 본론으로 돌아오자면, 다짐의 기술 전환은 사소한 계기로부터 시작됐다. 다짐에 초대코드 입력 이벤트를 오픈하자는 기획이 나왔다. 메인 페이지들은 모두 웹뷰로 처리할 예정이었기에 버튼 몇개 추가하고, api 및 웹뷰 연동만 해주면 되는 간단한 작업이 예상됐다. 개인적으로 'RN 개발자라면 네이티브도 알아야지!'라는 신념을 갖고 있기 때문에 이 작업이 아주 좋은 기회가 될 것이라고 생각했고, 당당하게 내가 이 프로젝트를 맡겠다고 선언했다.
그리곤 바로 절망을 맛보게 된다. 레포를 다운로드 받고 내 컴퓨터에서 프로젝트를 빌드하기까지 ios/android 각각 며칠씩이나 소요됐던 것이다. 어찌저찌 빌드는 성공시켰지만, 안그래도 생소한 네이티브 코드인데다가 꽤 큰 사이즈의 오래된 서비스다보니 간단한 화면간 이동조차 쉽사리 구현할 수 없었다. 네이티브 베이스에 RN뷰까지 포함하기 위해 채택한 모노레포 구조의 알수없는 버그들도 개발을 어렵게 하는 원인 중 하나였다. 결과적으로 만만하게 생각했던 기능이 실제 배포되기 까지 2주 이상 소요되어 버렸다.
이 경험 이후로 CTO님과 많은 대화를 나누었다. 다짐을 두고 CTO님이 가지고 계셨던 본래 계획은 앞으로 추가되는 기능은 RN으로 구현하는 것이었지만, 레거시 코드들과 모노레포에서 기인한 버그를 한차례 겪은 뒤, 이 계획은 현실적으로 어렵다고 판단했다. 그렇게 우스갯소리로 입에 달고 있던 '차라리 앱을 새로 만드는게 빠르겠다'라는 말이 설득력을 얻기 시작했다. 앱을 새로 만들어서 갈아끼운다는게 뚝딱뚝딱하면 되는 간단한 작업은 아니었지만, 이대로는 앞으로 다짐을 건드리는건 사실상 불가능에 가깝다고 판단했다. 다짐을 언제까지고 방치할 수 없었기 때문에(당시 기준 최근 2년간 다짐은 큰 업데이트가 없었다고 한다.) 2023년 2분기에는 다짐 스프린트가 예정되어 있었고, 그렇기에 빠르게 결정해야만 했다. 그 결과 3개월이라는 시간 안에 다짐을 RN으로 전환하자는 결정을 내리게 되었다. 앞으로 지속적으로 고통받느니 3개월동안 짧고 굵게 고통받고 끝내자는 통칭 <알보칠 프로젝트>는 이렇게 시작되었다.
왜 RN이었을까
다짐의 기술 스택을 RN으로 결정한 이유는 크게 3가지였다.
-
접근성
너무나 당연하지만 알보칠 프로젝트를 주도했던 내가 React Native 개발자였다. 당시에는 내 전문성을 100% 발휘할 수 있는 React Native외에 다른 기술 스택을 검토할 시간적 여유가 없었다. 또한 여차하면 팀내 웹개발자 분들이 코드를 볼 수 있다는 점도 스타트업 관점에서는 굉장히 큰 이점이다. -
생산성
RN을 활용하면 하나의 코드로 ios와 android 앱을 모두 만들 수 있으며, 심지어 변경사항을 바로바로 확인할 수 있는 hot reload 덕분에 단일 네이티브 앱 개발보다도 빠른 생산성을 확보할 수 있다. 또한, 이미 스톤아이의 다른 앱 서비스들은 React Native로 작성되어있었고, 웹은 Next를 사용했기 때문에 다른 프로젝트의 코드를 재사용할 수 있다는 이점도 크다고 판단했다. -
유지보수성
React Native의 가장 큰 메리트는 바로 코드푸시가 가능하다는 점이다. 수시로 기능 업데이트, 변경사항, 버그픽스가 필요한 초기 서비스에게 코드푸시는 가뭄의 단비같은 기술이다. 코드푸시 덕분에 내가 제어할 수 없는 스토어 심사를 건너뛰고 바로바로 서비스에 변경사항을 적용할 수 있기 때문에, 빠르고 린한 프로덕트 관리가 가능해진다.
알보칠 프로젝트, 그 이후
그렇게 입사 후 2달도 되지 않은 내가 맡은 첫번째 대형 프로젝트는 다짐 앱을 처음부터 새롭게 만드는 알보칠 프로젝트가 되었다.(이제와서 생각해보면 수습기간도 끝나지않은 신입개발자에게 메인 프로덕트의 제작을 처음부터 맡긴다는게 어떻게 가능했는지 조금 의아하지만 아무렴 감사하다.)그리고 다행히도, 1월 중순 지라에 태스크를 잡은지 정확하게 두달만인 3월 중순, 첫번째 QA에 들어갔고, 이후 점진적 배포를 통해 약 3달만에 성공적으로 앱 교체를 완료했다.
다짐 알보칠 프로젝트로 인해 나는 엄청난 성장을 이뤘고, 이제 다짐은 기존에 갖고 있던 고질적인 문제를 극복해냈다. 프로젝트의 영향은 여기서 그치지 않았다. 다짐매니저 관리자용 앱을 담당하시던 동료 웹 개발자 분이, 이 과정을 지켜보시더니 다짐의 코드를 참고해 관리자용앱을 RN으로 전환하는 관리자용 앱 알보칠 프로젝트를 진행하셨다. 누군가가 내가 짠 코드를 참고해서 프로젝트를 진행한다는 사실이 꽤나 짜릿하고 뿌듯했는데, 사실 이 글을 쓰게 된 진짜 이유도 그 연장선이라고 볼 수 있다. 다짐을 새롭게 만드는 과정에서 고민하고 알게된 것들을 블로그를 통해 기록하고 공유하고 싶었다. 그런 의미에서 후속으로는 조금 더 기술적인 내용들을 다뤄보려고 한다.
- 앱 교체하기
- 네비게이션 셋팅하기
- 디자인 시스템 구축하기
- 모달 리팩토링
- 웹뷰 셋팅하기
- 로딩 다루기
안녕하세요!
게시글이 매우 도움이되서 천천히 다 읽어보게 되네요!
현재 리엑트 네이티브로 서비스 런칭 준비중입니다.
처음 구축환경을 expo와 cli가 있는데 의견들이 굉장히 많아서
다짐에서는 어떤방식으로 했는지 궁금합니다!
expo이후에 리젝하신건지도 궁금합니다