[세종시 버스 정보 시스템 앱] 프로젝트 회고 (1) - React Native 도입

 

BMS에 대한 정보는 여기에 포스팅이 되어 있습니다.

[스마트 시티] BIMS(Bus Information Management System)

📢 프로젝트 소개

• 프로젝트 인원 : 6명 (프론트엔드 3명, 백엔드 2명)
• 프로젝트 : 세종시의 초정밀 버스 앱
• 협업 : Gitea, Notion, Jandi
• 기술 스택
  • Frontend : React-Native, Typescript, Redux Tool-kit, Socket, 
  • Backend : Spring Boot, JPA, MySQL, Websocket, Redis

👩🏻‍💻 나의 역할

• 프론트엔드 개발 (구독, 알람, 즐겨찾기, 더보기 화면 개발)
• 프로젝트 셋팅 (보일러 플레이트, 컨벤션, 디자인패턴 구성)
• 컴포넌트 가이드 및 래퍼런스 담당

💭 프로젝트 설명

이 프로젝트는 세종시의 버스를 초정밀로 실시간으로 정보를 제공해주는 서비스 입니다. 즐겨찾기와 구독등을 통해 내가 구독한 버스에 대해서 실시간 알람을 보고 버스의 이동경로를 추적하는 앱 서비스 입니다.

 

🚩 프로젝트 과정

1. 기획

우리 팀이 원래 맡지 않았던 프로젝트가 있었는데, 다른 팀이 사업을 따왔지만 인력과 기술 면에서 부족하여 우리 팀이 화면 개발을 맡게 되었습니다.

(어차피 마침 인천시 데이터 포털 프로젝트를 마치면서 시간적 여유가 생겨 바로 투입할 수 있었다..ㅠㅠ)

 

화면 디자인과 기획안이 이미 마련되어 있었지만, 기능과 기술력을 고려하여 조율과 협의가 필요했습니다. 우리 팀 내에는 앱 개발 및 Native 환경에 대한 전문 지식이 전무한 상태였기 때문에, 어떤 프레임워크를 사용해야 하는지와 그것이 어떻게 작동하는지에 대한 이해도 부족한 상황이었습니다.ㅠ

 

 

 

2. 기술 선정 과정

주어진 기간이 한 달이 조금 넘는데, 앱 개발 경험이 없는 상황에서 React Native와 Flutter를 비교하며 공부해야 했습니다.

(물론, Android와 ios 를 직접 개발할 수 있겠지만 그러한 기술이 팀내 할 수 있는 사람이 없었다..)

 

빠르게 개발을 하면서도 완성도를 높이기 위해 우리 팀의 현재 상황을 면밀히 분석하고 고려해야 했습니다.

 

 

이렇게 분석을 토대로 결국 해야할 것을 따져보면 다음과 같은 알고리즘을 도출하였습니다.

if (다룰 수 있는 언어가 유일하다 || 배우는 것에 두려움이 있다.){

    가장 자신있는 언어의 Framework를 이용; // React -> 웹앱으로 하는 것
}
else if(다룰 수 있는 언어가 유일하다 || 자신 있는 언어가 명확하다){
	
    해당 언어의 Framework를 이용; // React -> 웹앱으로 하는 것
    
}else if(다양한 언어가 가능하며 선택에서 고민된다){
	
    if(내가 가고 싶은 기업이 있다){
    	 
        해당 기업이 이용, 개발자 채용 시 공고하는 Framework를 이용; // pass
            
    }else if(내가 해보고 싶은 Framework가 있다){
    	
        해당 Framework를 이용; // React Native 
            
    }else if(내가 만들고 싶은 웹의 특징을 안다){
    	
        만들고 싶은 웹의 특징과 Framework 들의 특징을 비교하여 이용; // React Native
            
    }else{ //됐고, 난 잘 모르겠다
    	가장 래퍼런스와 대중적인 Framework 것을 이용 // React Native
    }
}

 

따라서, 우리가 선택했던 것은 React Native를 선택하는 것이 최적의 판단이라고 생각했다.

3. 설계 

피그마

 

처음에 화면 시안을 받아 살펴본 당시에는 큰 기능이 없어 보였습니다.  (이때까지만해도 앞날은 어떠할지 모른채..) 
당시에는 앞으로의 개발 과정을 예측할 수 없었기 때문에 기능이 제한적으로 보였습니다. 예상했던 것보다는 실제로 구현해야 할 기능이 더 많았습니다. 소켓을 통해 서버로부터 데이터를 받아오는 정도라고 예상했지만, 실제로는 그렇지 않았습니다.

 

4. 프로젝트 세팅

📌 Expo CLI 에서 RN CLI 전환 

프로젝트를 설정할 때도 공부가 부족하여 몇 차례의 시행착오를 겪었습니다. 처음이라는 점과 시간적 리소스가 부족한 상황에서 편안하게 시작하고자 초기에는 Expo를 선택했습니다.

React Native와 Expo에 대한 정보는 이곳에서 포스팅을 하였습니다.

[RN] React Native와 Native (feat. Expo-CLI vs. React-Native-CLI)

 

 

하지만, 문제가 있었는데, 주요 기능 사실상 메인 기능은 Kakao Map API 를 사용해야 했다. 

https://apis.map.kakao.com/

 

그러나 지도 조작 등의 기능을 구현하는 과정에서 JavaScript 코드로는 지원되지 않는 기능이 있었습니다. 이에 따라 Android 또는 iOS 코드를 수정해야 하는 상황이 발생했습니다. 이러한 상황에서는 결국 React Native CLI를 사용하는 것이 올바른 선택이었습니다.

프로젝트 설정은 이곳에서 포스팅을 하였습니다.

[RN] React Native boilerpate 설정 가이드

 

 

📌 프로젝트 구조 설계

 

이전의 인천 데이터 포털 프로젝트를 하면서 회고를 통해 K-T-P에서 도출방안을 최대한 반영하여 다시 설계를 조정하면서 시작하였습니다.  

 

이전 프로젝트의 회고

 

버튼 하나를 만들더라도 모든걸 추상화하기 보다는 기능 또는 UI를 고려하며 분리 하는 방식으로 컴포넌트를 설계했습니다. 또한,  대시 케이스로 작성하며 앞부분에는 UI 모양 또는 기능을 나타내고, 뒤에는 공통의 관심사를 나타내어 관리와 보기가 편하도록 설계하였습니다.

atoms > buttons

 

또한, 최대한 라이브러리를 사용하는 것은 지양하고 컴포넌트는 아니지만 프로젝트내 내에서 사용할 수 있는 것들은 modele화하여 사용하도록 하였습니다.

 

📦modules
 ┣ 📜alert.module.ts
 ┣ 📜async-storage.module.ts
 ┗ 📜lodash.module.ts

 

 

그리고 이처럼 Data 로직과 UI 껍데기 부분을 담당하는 화면 로직은 분리 시키고 일정 컨벤션에 따라 개발을 하면서 유지 보수와 기능 고도화를 할때도 변경에 용이할 수 있도록 설계하고자 하였습니다.

 ┣ 📂favorite
 ┃ ┣ 📂controllers
 ┃ ┃ ┣ 📜useFavoriteChooseViewController.ts
 ┃ ┃ ┣ 📜useFavoriteEditViewController.ts
 ┃ ┃ ┗ 📜useFavoriteViewController.ts
 ┃ ┣ 📂screens
 ┃ ┃ ┣ 📜choose.view.tsx
 ┃ ┃ ┣ 📜edit.view.tsx
 ┃ ┃ ┗ 📜index.view.tsx
 ┃ ┗ 📂style
 ┃ ┃ ┗ 📜index.style.ts
 ┣ 📂subscribe
 ┃ ┣ 📂controllers
 ┃ ┃ ┣ 📜useSubscribeAddView.ts
 ┃ ┃ ┣ 📜useSubscribeSettingViewController.ts
 ┃ ┃ ┗ 📜useSubscribeViewController.ts
 ┃ ┣ 📂screens
 ┃ ┃ ┣ 📜add.view.tsx
 ┃ ┃ ┣ 📜index.view.tsx
 ┃ ┃ ┗ 📜setting.view.tsx
 ┃ ┗ 📂style
 ┃ ┃ ┗ 📜index.style.ts