Final Project - (2) 2020_0130

오늘 엔지니어님과 킥오프 미팅을 통해 팀원들과 그동안 논의했던 프로젝트의 전반적인 기획에 대해서 체크를 받았다.

특히 팀원들과 논의가 많았던 기술 스택과 기타 DB 스키마나 궁금했던 사항들을 많이 체크를 받았다.

 

킥오프 미팅에서 기술 스택에 대해서 많은 질문을 하고 엔지니어님이 말해주신 것과 팀원과의 회의를 토대로 프론트엔드 쪽 기술 스택을 다음과 같이 하기로 하였다.

 

1. React native

일단 우리가 만드려는 프로젝트가 앱이고 네이티브 언어 (swift, object-c, java)로 직접 만들면 좋겠지만, 프로젝트 기간도 기간이고 아무래도 러닝커브가 높기 때문에 리액트 네이티브를 사용해야 할 것 같다.

 

여기서 또 이슈가 있는데 리액트 네이티브에서 expo cli를 사용할 것이냐 아니면 react-native cli를 사용할 것이냐에 대한 이슈가 있었다. expo cli는 일단 리액트의 CRA와 같은 것으로 모든 초기 설정을 다 잡아준다. 그래서 프로젝트를 시작하기에 매우 편하다. 반면에 앱이 무거워질 수가 있고, 외부 api나 모듈 사용에 제한이 있는 것 같다. react-native cli의 경우에는 expo cli와 장단점이 반대로 직접 모든 것을 세팅해야하기 때문에 필요한 것만 넣을 수 있어서 앱이 가벼운 편이지만, 초기 세팅에 시간 투자가 많이 필요하다.

 

팀원들과 회의를 통해서 expo cli를 사용하기로 하였는데 그렇게 된 가장 큰 요인은 프로젝트 기간이다. 기간이 한정적이기 때문에 세팅에 많은 시간을 들이기 어렵고, 리액트 네이티브 자체도 처음 접하는 스택이라 공부할 것이 많기 때문에 효율과 시간을 고려해서 expo cli를 사용하기로 하였다. 

 

쓰다보니 expo cli가 별로라는 느낌이 있는데 expo cli도 초기 세팅에 있어서 정말 강력하기 때문에 나쁘다고는 생각되지 않는다.

하지만 정말 큰 프로젝트라던지 그런 것을 개발하려면 아무래도 expo보단 react native cli로 개발하는 것이 성능 면이나 기타 다른 이슈에서 좀 더 좋을 것이라고 생각 된다.

 

나중에 시간이 나면 react-native cli를 공부해서 프로젝트를  해보는 것으로 하고 지금은 expo cli를 사용해야겠다.

 

2. Redux (or MobX)

상태 관리가 필요할까 해서 둘 중에 무엇을 써야할지 엔지니어님께 물어보았다. 그런데 전에 이 둘의 차이점을 찾아보면서 느낀 것이 이정도의 프로젝트에 상태관리 라이브러리가 필요할까? 이였다.

 

물론 배우는 입장에서 상태 관리를 프로젝트에 잘 도입하면 당연히 좋겠지만 리덕스의 경우 러닝커브가 어느정도 있는 편이고 mobx 또한 리덕스에 비해 편하고 사용하기 쉽다지만 둘다 처음 접하는 입장에서는 러닝커브가 어느정도 있을 수 밖에 없다.

 

엔지니어님은 리액트의 context api를 써보는게 어떻겠냐고 제안을 하셨다. 사실 단순히 전역 상태관리만 사용하기위해 (우리 프로젝트 규모에서) 리덕스를 사용하는 것은 리덕스의 용도와 성능에 비해 과한 느낌이 있는 것 같기도 하고 (mobx도) context api를 활용할 수 있으면 그것을 사용하는게 더 좋아보이긴 했다. 또한 항상 입이 닿도록 말하는 프로젝트 기간 내에 적용하기위해서는 러닝커브도 잘 고려해야 하므로 context api로 기우는 것 같았다. 

 

하지만 팀원분들과 회의를 통해 상태 관리에 관한 것은 도입을 안하기로 결정하였다. 사실 꿈은 크고 말로는 이런저런 스택을 다 써놨지만 실상은 리액트 네이티브 하나 하기도 벅찰 듯...하다. 그래서 프로젝트의 완성도를 위하여 빼기로 결정하였다.

 

그래서 리덕스는 나중에 배워서 활용해본는 것으로...마음 먹었다. 그래도 이러한 정보들을 찾아보면서 apollo client라는 키워드도 알게 되어서 나름의 수확이 있었던 것 같다. 리덕스 또는 아폴로 클라이언트는 나중에 공부해보는 것으로 하자!

 

3. React hook

리액트 훅은 사실 킥오프 진행을 하면서 기술 스택에 대한 두려움? 또는 완성도에 대한 우려로 인하여 적용을 안하는 방향으로 하려고 했는데 팀원들과 논의를 통해서 좀 더 챌린지하게 가져가는게 좋지 않을까 하여 도입하기로 하였다. 

 

사실 요즘 거의 React hook을 많이 쓰는 추세(?)이고 대부분이 react hook으로 대체되고 있다고 해서 우리도 도입해서 프로젝트를 진행해보는 것이 좋을 것 같아서 팀원들과 논의 끝에 사용할 기술스택으로 확정되었다. 좀 걱정이 되긴하지만 열심히 해서 잘 사용하고 내 것으로 만들 수 있도록 많이 노력할 것이다. 

 

4. Typescript

타입스크립트는 프론트와 백엔드 모두 도입하기로 결정하였다.

 

first project를 할 때 eslint에 airbnb 스타일을 적용해서 했었는데 그때 props의 타입을 모두 체크 했었었다.

그때 들었던 생각이 이럴바에 타입스크립트를 아예 적용시키는게 낫지 않을까? 생각은 했었다.

(사실 타입스크립트도 아직 잘 모른다..ㅋ)

 

아무튼 타입스크립트는 한번 사용해본 팀은 다시 자바스크립트로 돌아가지 않는다고 할 정도로 사용해본 사람들의 만족도가 높은 것으로 알고 있고, 자바스크립트의 느슨함을 체크하여 에러와 디버깅을 줄이고 코드 생산성 및 코드 퀄리티를 좋게 만들어준다고 알고 있다. 때문에 예전부터 사용해보고 싶은 마음이 계속 있었고 이번 프로젝트를 통해서 타입스크립트가 어떤 것이고 왜 많은 사람들이 사용하는지 제대로 알아 보고 싶다.

 

 

 

이밖에도 백엔드 부분에서 우리가 결재 모듈을 사용하는 것을 넣어놨는데... 엔지니어님이 결재 관련 부분만 한명이 전담해도 한달 내내 잡고 있어야 된다고해서... 결재는 실제 결재가 아닌 이러한 식으로 된다 정도로 테스트 식으로 구현하기로 하였고, DB 스키마도 변경이 조금 있었다.

 

그리고 배포도 이슈가 있어서 (ios 배포가 많이 까다로움) 일단 안드로이드 배포(된다면) 까지만 해보는 것으로 목표를 재조정했다.

 

그전에 고려했던 자동배포 또한 프로젝트의 완성도(서비스)를 가져갈 것이냐 아니면 시스템 구축을 가져갈 것이냐에 대한 논의를 통해서 프로젝트의 완성도를 좀 더 높이자고 해서 자동배포도 빼기로 하였다.

 

이번 킥오프 미팅을 통해서 프로젝트의 범위가 어느 정도 확정되고 기술 스택도 거의 확정되어서 이제 본격적으로 프로젝트를 시작해 볼 수 있을 것 같다.