WIL 0711 ~ 0717 10주차 회고

MVP개발을 하는 3주 동안 어떤 기술을 다뤄봤나

1. 상태 관리를 위한 redux와 react-query
2. github action
3. 배포
4. recoil

1. 상태 관리를 위한 redux와 react-query

이번 프로젝트에서는 상태관리를 위해 redux와 react-query를 사용했다.
redux를 선택한 이유는 무겁긴 하지만 상태 관리에 확실하며 thunk를 써야 하는 것이 아니라면 redux를 사용하는 것도 크게 나쁘지 않을 것 같다고 판단했다. 가장 큰 이유는 내게 익숙하기 때문이다.

react-query를 사용한 이유는 우선 전역 상태관리를 할 데이터가 많지 않기 때문에 redux-thunk는 쓸데없는 코드를 많이 작성할 것 같다는 생각이 들었고, 새로운 기술을 학습해보고자 선택을 했다.
또한 프로젝트에서 각 데이터를 호출하는데 다양한 조건에서 호출할 수 있고 자동으로 refetch를 할 수 있다는 점에서 react-query가 이번 프로젝트와 성향이 더 맞다고 판단했다.

2. github action

그 전 프로젝트에서도 github action을 시도해보고 싶었지만, 이번에 처음으로 시도해봤다.
*그 전에 시도하지 못한 이유는 *

1. 일주일이라는 시간이 너무 짧다고 느껴졌다.
2. 라이브러리라는 착각에 익히는 게 오래 걸릴 것 같다는 생각이 들었다.
   

이번 프로젝트에서 진행한 이유
처음 배포를 amplify로 진행했었는데 자동 배포에 매력을 느끼게 됐다.

git에서 action은 어떤 기능일지 궁금한 적이 있었는데, github action이 action을 이용한 것이라는 것을 처음 알았고 설정하는 것에서 많이 막혔지만, 꾸역꾸역 테스트한 결과 연결을 성공했고 100%라고는 말할 수 없지만 어느 정도 흐름을 파악할 수 있었다.

3. 배포

배포는 S3, Route 53, cloudFront를 이용하여 https 환경으로 배포했다.
기존에는 Amplify로 배포를 진행했었는데, S3로 변경한 이유는 테스트하는 과정에서 http로 테스트를 해야 하는 상황이 있었고, 두 방법 모두 유지하기에는 비용적이나 관리 측면에서 그렇게 효율적으로 느끼지 못해 S3로 전환하여 배포했다.

4. recoil

처음에는 redux를 전역 상태 관리 툴로 이용을 했다. 프로젝트를 진행하면서 변경되는 기획과 추가 기능에 대해 구상을 해본 결과 전역 상태 관리할 데이터가 거의 없다. 있어도 클라이언트 데이터만 존재할 뿐
이 상황에서 redux는 무겁기만 한 의미 없는 라이브러리가 된 것 같았다. 따라서 새로운 상태 관리 툴을 찾다 react-query와 recoil에 조합을 사용하는 작은 프로젝트들을 많이 봤고, 나 또한 recoil을 이용해 보기로 했다.
사용법이 너무 어렵거나 redux코드가 길었다면 변경에 고민이 있었겠지만 둘 다 해당되지 않았기 때문에 팀원과 회의 후 과감히 변경하였다.

이번 주를 돌아보며

MVP 중간발표를 진행했다. 그동안 방향을 자주 잃었지만 열심히 달린 것 같다. 이번 3주보다 다음 2주가 더 바쁠 것 같다는 생각이 든다. 그리고 중간발표를 준비하면서 막판에 맘먹고 에러를 찾으니 너무 많은 에러를 발견하고 짧은 시간 내에 수정하는 게 쉽지 많은 않았던 것 같다.
나름 중간을 왔다는 생각도 들고 진짜 뭘 만들고 있다는 생각이 들면서 나쁘지 않은 기분이었던 것 같다.

앞으로는 에러 처리를 확실하게 보이는 건 그때그때 수정하는 게 답이다. 물론 에러 위치나 에러 이유를 잘 설명해주지만 나중에 다 찾는데 오래 걸리는 것 같다.

다음 주 목표!

우선 추가 기능을 한 주에 몰아서 다 작성하자는 의견이 나왔다. 내일 간단한 기획을 하고 바로 달려들 것 같다.
다음 주 안에 PC버전 기능까지 다 완성하는 게 목표이다. 그 이후로는 반응형을 고려하면서 더 단단한 프로젝트를 만들어보자