Bada
Bada's Coding

Bada's Coding

제로베이스 프로젝트에 대한 회고

Bada's photo
Bada
·Sep 21, 2022·

4 min read

Table of contents

※ This page is about retrospection about my project. Because I need to get a job in Korea, I wrote in Korean.

전반적인 과정

저는 2022년 9월 21일 기준으로 제로베이스라는 곳에서 3기 프론트엔드 스쿨 과정을 수강하고 있습니다. 해당 과정에는 그룹 프로젝트를 하고 싶다고 신청을 하면 학원에서 4명을 짜주는 시스템이 있습니다. 그렇게 해서 4명으로 된 그룹이 만들어 졌는데요. 그중 한 명은 초기에 나갔고 나머지 3명이 진행을 했습니다. 그리고 강사 한 명이 이를 관리하는 형태로 갔습니다.

원래 한 그룹이 여러 프로젝트를 하는 방식이었지만 저는 해당 프로젝트를 끝으로 그룹을 나왔습니다. 이유는 백엔드 부분을 더 공부하고 싶었기 때문입니다.

제가 한 프로젝트는 강사님이 주도적으로 그 방향을 제시해 주셨고, 해당 프로젝트를 만드는 것이었습니다.

실제로 강사님이 만드신 사이트는 다음과 같습니다.

강사님께서 해당 사이트뿐만 아니라 강의, Notion, 회의를 통해 어떻게 만드는지를 상세하게 설명해 주셨습니다.

그럼 이제부터 이번 프로젝트를 통해 느꼈던 점, 배웠던 점을 적겠습니다.

Prettier 설정을 정했을 때 팀원들에게 의견을 물어보면서 정했음

처음에 강사님께서 제가 Prettier를 설정하게 하셨습니다. 물론 저 혼자서 제가 원하는 대로 정할 수 있었지만, 각자가 선호하는 방식이 있기 때문에 팀원들과 이야기를 나누면서 정했습니다.

Git을 사용할 때 branch를 활용하지 못한 점

이번 프로젝트를 할 때는 branch를 사용하지 않고 자신의 GitHub으로 해당 프로젝트를 fork를 해서 개발을 했습니다. 제가 branch로 하자고 말을 했지만, 팀원들이 fork를 하는 방식을 원했기 때문에 그렇게 했습니다.

태도의 중요성

제가 느끼기에 한 팀원은 뭔가 코드를 이해하고 짜는 것이 아니라 구현만 되게 짜는 것 같았습니다. 그리고 문제가 발생한 적이 있었는데, 상품 페이지에 접속할 때 다른 곳의 링크를 통해 들어오는 것은 가능했지만 직접 URL로 들어오는 것은 불가능했습니다. 제가 그 문제를 해결해 달라고 요청을 했지만 결국 그 팀원은 고치지 않았습니다. 제가 해당 코드를 확인하고 방향까지 알려주었음에도 불구하고 말이죠. 또한 그 팀원은 검색 기능을 구현하기로 하였지만, 결국 완벽하게 하지 못했습니다.

'그냥 실력이 없는 팀원이구나.'라고 생각하실 수 있겠지만 그 팀원이 처음부터 데드라인을 강조했다는 것을 말씀드리고 싶습니다. 기억은 정확하게 나지 않지만 2주나 3주 안으로 해당 프로젝트를 끝내자는 것이었습니다. 저는 이에 반대했습니다. 어떠한 상황이 벌어질지 모르기 때문이었죠. 어쨌든 저는 그 팀원이 그렇게 자신감을 보여서 그 팀원이 제일 잘할 줄 알았습니다. 하지만 그렇지 않더라고요. 저한테 그 팀원은 코드의 품질, 버그 등은 신경을 쓰지 않고 자신이 무엇인가를 만들었다는 사실을 과시하기에 바쁜 것처럼 보였습니다. 그리고 그 팀원을 보며 저는 그러한 개발자가 돼서는 안 되겠다는 생각을 했습니다. 그리고 그러한 태도 때문에 해당 팀원의 실력도 안 좋았던 것 같습니다. 빨리 만들기에 급급하다 보니 기초부터 공부해야 함에도 불구하고 그렇게 하지 않는 것이죠.

협업 툴

기본적으로는 Slack을 이용해서 문자를 주고받았습니다. 그리고 회의를 할 때는 Google Meet를 활용했습니다. 초반에는 Gather를 활용하기도 했습니다.

새롭게 배운 기술들

Vite를 알게 되었는데 Create React App에 비해 속도가 빨랐습니다.

프로젝트 단위로 Prettier를 설정하는 법을 알게 되었습니다.

TypeScript의 utility type에 대해 알게 되었습니다.

GitHub의 organization에 대해 알게 되었습니다.

TypeScript 파일 확장자인 tsx와 ts의 차이, 또는 JavaScript 파일 확장자인 jsx, js의 차이를 알게 되었습니다. 예전에는 이를 잘 몰라서 'store.tsx'와 같은 식으로 적었습니다.

Tailwind CSS를 처음 써보았습니다.

CSS 프레임워크에 대한 생각

이번 프로젝트에서 Tailwind CSS와 daisyUI를 썼는데요. 이에 대한 생각을 적어보겠습니다.

daisyUI의 경우 디자인을 자체적으로 제작해야 하는 회사의 입장에서는 프로토타이핑 단계에서는 쓰일지는 몰라도 배포 단계에서는 잘 쓰이지 않을 기술처럼 보였습니다.

daisyUI가 제공하지 않는 기능을 구현하기 위해서는 CSS를 알아야 한다고 생각했습니다. 예를 들어 반응형 페이지가 있습니다.

Tailwind CSS의 경우 태그에 많은 클래스를 넣어야 하므로 보기 좋지 않았습니다.

Tailwind CSS의 경우 다른 모듈에서 받아온 변수를 처리하지 못하는 것 같았습니다.

Tailwind CSS는 검색 기능이 잘 구현되어 있는 것 같았습니다.

까다로웠던 부분

Redux Toolkit의 createAsyncThunk

|이전의 방식만 알고 있었던 상태|

Redux의 경우 원래부터 공을 많이 들여 공부를 했습니다. Toolkit 이전의 방식도 익혔고요. React Redux를 쓰는 방식과 쓰지 않는 방식 둘 다 익혔습니다. 공부를 하던 중, 어떠한 분의 글을 통해 Thunk를 배웠는데 해당 방식은 옛날 방식이었습니다. 저는 그것이 너무 복잡해서 Thunk를 쓰지 않는 방식으로 비동기를 처리하는 것을 시도해 보았고 이에 대한 결과가 해당 페이지입니다.

그런데 이번에 마침 작업을 하면서 Redux Toolkit의 createAsynThunk에 대한 강의를 보게 되었고, 매우 만족했습니다. 그래서 먼저 제가 나름대로 간단한 프로젝트를 만들어 보았고, 그 후 해당 프로젝트에 적용하였습니다.

제가 나름대로 만든 간단한 프로젝트에 대한 페이지

|그 자체로 어려웠던 부분|

TypeScript를 통해 타입을 지정하는 것이 어려웠습니다. 특히 저는 extraReducers만 썼기 때문에 reducers를 쓰지 않고 했는데요. 이 때문에 계속 타입 오류가 생겼습니다. 다행히 공식문서를 보고 한 번 넣어봤는데, 되었습니다.

|다른 상태 관리 도구에 대한 생각|

최근 React Query, Recoil, Zustand 등이 Redux의 대안으로 뜨는 것 같은데요. 제 개인적으로는 Redux Toolkit이 그렇게 복잡하다는 생각은 들지 않았습니다. 다만 옛날 것, 요즘 것, 그리고 React-Redux 3개를 모두 공부하다 보니 짜증이 좀 나기는 했습니다.😅 저보고 선택하라고 하신다면 해당 기술의 난이도보다는 공식문서가 잘 되어 있는지를 우선적으로 고려할 것 같습니다.

검색 부분

검색의 경우 제일 어려웠던 점은 링크를 누르면 해당 상품 페이지로 이동하지 않는 것이었습니다. 그 이유를 알아보니 blur 이벤트가 click 이벤트보다 먼저 일어나기 때문에 클릭을 할 때쯤 클릭할 것이 사리지기 때문이었습니다. 어찌어찌해서 mousedown, mouseup 등을 알게 되었고, 이를 활용해서 해결을 했습니다.

 
Share this