본 게시글은 Elice에서 7.4일부터 7.24일까지 진행된 2차 프로젝트에 대한 게시글입니다:)
프로젝트 Github: https://github.com/SeolJaeHyeok/Rabbit-Hole
💡 기획
Rabit-Hole 프로젝트를 기획하게 된 계기는 내가 지금 느끼는 목마름을 해결해 줄 수 있는 부분이 될 것이라고 생각했기 때문에 기획했다.
많은 레이서들이 디스코드를 통해 질문하고 답변을 받고 있었는데 이러한 방식이 개인적으로는 별로 효율적이지 못하다고 생각했다.
실제로 디스코드 상에서 이전 질문에 대한 답변을 찾는 것이 꽤나 불편하기도 했고 서버 내에 굉장히 많은 채널들이 존재해서 어떤 채널에서 원하는 정보를 얻어야 하는지도 불편했다.
더군다나 이제 막 코스를 시작한 AI 기수의 단체 채팅방에 들어가 이러한 커뮤니티의 필요성에 대해서 간단히 조사를 해봤는데 상당히 긍정적인 반응을 얻을 수 있었다.
그래서 우리 팀은
레이서들의 원활한 레이스를 위한
레이서들의 앞길에 한 줄기 빛이 될
보다 효율적인 학습을 위한
레이서의, 레이서에 의한, 레이서를 위한
엘리스 레이서 지망생 및 수강생의 정보 공유 및 네트워킹을 위한 커뮤니티 서비스
를 만들기로 결정했다.
🛠 설계
지난 1차 프로젝트 때는 기본적으로 주어진 스켈레톤 코드가 있었고 이를 이해하기 위한 시간을 따로 가졌어야 했다.
하지만 2차 프로젝트는 처음부터 끝까지 직접 만들어야 했기 때문에 기획과 설계에 많은 시간을 할애하게 됐다.
개인적으로 나는 스켈레톤이 주어지는 것보다 처음부터 직접 만드는 게 더 좋다 😂
✔️ 개발 스택 정의
개발 스택을 정의할 때 고려한 점들은 총 4가지다.
- React vs Next
- CRA vs Vite
- Server State Management
- JavaScript vs Typescript
1. React vs Next
먼저 Next를 이용할 것인지에 대해서 팀원들과 이야기를 했다.
사실 Next를 사용하는 주된 이유가 SEO에서 React보다 강점을 가지고 있기 때문이라고 생각했고 우리는 서비스의 타겟층을 엘리스의 레이서들로 설정했기 때문에 SEO의 이점을 굳이 얻을 필요가 없을 것이라고 생각했다.
Next를 사용하자는 팀원이 있었지만 Next를 사용하게 된다면 얻을 수 있는 이점들이 우리 프로젝트와 큰 관련이 없을 것이라고 이야기해서 React를 사용하기로 결정했다.
이처럼 기술을 도입함에 있어 무작정 도입하는 것이 아니라 명확한 이유
다시 말해, 실제로 이 기술이 가지고 있는 장점이나 철학이 우리가 가려고 하는 방향과 맞는지를 판단하고 도입하는 의사결정 과정이 꼭 필요하다고 생각했다.
2. CRA vs Vite
그동안 CRA로 프로젝트를 셋업하여 주로 개발을 진행했었는데 지난 스터디 때 진행한 프로젝트에서 Vite (❗️빗이라고 발음, 바이트 아님)을 이용해 처음 프로젝트를 진행하고 이번에도 Vite을 사용하기로 결정했다.
Vite의 장점은 빠른 개발 서버 속도, Native ESM을 이용한 HMR(Hot Module Replacement)을 지원 등이 있지만 내가 실제로 Vite의 장점을 체감할 수 있었던 것은 프로젝트 빌드가 엄청 빠르다는 것이었다.
내 기억 상으로는 정확하지는 않지만 빌드가 10초가 채 걸리지 않았던 것 같다.
3. Server State Management
개발을 하면서 수많은 API 요청들이 일어나고 이러한 요청들을 최소화함으로써 프로젝트의 성능을 개선시키려고 노력했다.
그러기 위해 데이터 캐싱 등을 통해 서버의 부하를 줄이고 서버에서 받아온 데이터를 효율적으로 관리할 수 있는 React Query 도입하기로 결정했다.
그리고 실제로 React Query의 도입으로 캐싱이 필요한 데이터를 선별하고 이를 캐싱해 의미 없는 요청(ex.동일한 데이터에 대한 다른 요청)이 줄어드는 효과 발생했다.
또한 백그라운드에서 데이터를 관찰하고 이를 통해 stale한 데이터를 fresh한 데이터로 업데이트 해줄 수 있었기 때문에 도입을 결정하게 됐다.
이렇게 처음 react-query를 사용해봤지만 제대로 react-query 를 사용했다고는 말하기 어려울 것 같다.
GET 요청을 할 때는 병렬 요청(ex. useQueries)등을 사용하거나 staleTime을 조정해 데이터를 캐싱하고 invalidateQueries를 이용해 화면을 리렌더링했으나
POST나 DELETE 요청에서 사용하는 useMutation은 사용하지 못했다.
만약 개발할 수 있는 시간적인 여유가 조금만 더 있었다면 제대로 공부해보고 적용하고 싶었지만 아쉽게도 적용해보지 못했다.
그래서 다음에 기회가 된다면 react-query에 대해서 제대로 공부해서 프로젝트에 적용해보고 싶다 👍
4. JavaScript vs Typescript
개인적으로 요즘은 Typescript가 필수 역량이 된 것 같다.
그리고 나 또한 Typescript를 통해 프로젝트를 하는 것을 좋아하고 Typescript를 사용해본 적 없는 팀원이 있다면 아는 부분은 가르쳐 주면서 Typescript로 프로젝트를 진행하는 편인 것 같다.
물론 처음 사용하다면 보면 이게 무슨 타입이지 하면서 타입 찾아보다가 개발 시간이 늘어나기도 하고 Anyscript가 될 정도로 any를 남발되는 경우가 있지만
Typescript를 사용할 수 있는 환경에서 개발을 하게 된다면 모르는 타입을 알아내 수정할 수 있는 시도를 할 수 있기 때문에 가능하다면 Typescript를 사용하는 환경에서 개발을 하는 것이 좋다고 생각한다 👍
이 외에 다른 스택(상태 관리, 스타일 등)은 팀원들과 이야기해서 스무스하게 정했다.
🖌 와이어 프레임 제작
기획이 구체화 됐고 개발 스택이 정해진 후 먼저 프로젝트의 와이어 프레임 작업을 진행했다.
그동안 피그마를 이용해서 웹사이트의 와이어 프레임을 작업해 본 적이 없었기에 처음에는 적응하는 데 엄청 고생했던 기억이 난다 😂 디자이너분들 존경합니다.. 👏
많은 우여곡절을 겪으면서 와이어 프레임을 완성했고 이 안에서 공통 되는 컴포넌트들을 추출했다.
완성된 피그마는 여기에서 확인할 수 있습니다:)
📖 Schema 정의
프로젝트에 필요한 모델을 정의하고 이에 맞는 Schema를 정의하는 작업을 했다.
Schema를 백엔드 개발자끼리 정의를 하니까 개발을 하면서 Schema가 빈번하게 수정이 되는 경우가 1차 프로젝트에서 일어났었다.
스키마에 필드가 하나가 추가되면 해당 데이터를 사용하는 프론트 코드를 모두 수정해야하기 때문에 백엔드와 소통을 통해 스키마가 수정되는 일을 최소화 시키려고 노력했다
1차 프로젝트에서 벌어졌던 대참사(?)를 다시 경험하고 싶지 않았기에 이번에는 백엔드 초기 설계 단계(ex. ERD 제작, API 명세)에도 참여하여 많은 소통을 했다 😂
🖥 구현
구현은 크게 네 가지로 진행했다.
첫 번째, 공통 컴포넌트 제작
두 번째, 제작한 컴포넌트를 이용하여 페이지 작업
세 번째, 자체적인 QA를 거친 후 디버깅
네 번째, 배포
1. 공통 컴포넌트 제작
먼저 Figma에 완성된 와이어 프레임을 보고 공통 컴포넌트를 추출했다.
총 13개의 컴포넌트가 추출되었고 이를 3~4개씩 분배하여 먼저 구현을 했다.
개인적으로 이 과정을 통해서 조금 더 확장성과 재사용성을 고려한 컴포넌트를 설계할 수 있는 능력을 키울 수 있어서 좋았다.
예를 들어, select box를 작업한다고 가정 했을 때,
이 컴포넌트를 다른 사람이 사용할 때의 예상되는 기능들
다시 말해, select box 안의 option을 선택했을 때 어떤 행동(ex. API request)을 하는 것을 상정하여 컴포넌트를 설계하다보니 자연스레 재사용성과 확장성을 고려한 컴포넌트를 설계할 수 있었던 것 같다.
✔️
여담으로 select box를 Figma에 정의된대로 스타일링 하는게 상당히 번거로운 작업이었는데 프로젝트 코치님께 여쭤보니 현업에서는 select box는 브라우저가 제공하는 디자인 그대로 사용하는 경우가 많다고 하셨다 😱특히 select box를 스타일링할 경우 모바일 화면에서 이상하게 나올 가능성이 있다고 얘기해 주셔서 이후에는 select box는 되도록이면 스타일링 안하려고 한다 😂
2. 페이지 작업
공통 컴포넌트를 제작하고 이제 페이지 작업에 들어갔다.
피그마에 정의된 페이지를 분담하여 작업하고 PR을 올리고 리뷰하고 머지하는 방식으로 진행을 했다.
나는 크게
- Register Page
- Main Page
- Project Gallery Page
- Project Detail Page
- My Page - Profile, Project, Board
7개 정도의 페이지와 3~4개의 Form을 만들었는데
꽤나 많은 분량의 작업이었음에도 공통 컴포넌트 설계를 잘해놔서 생각보다 짧은 시간 안에 페이지 작업을 완료할 수 있었다.
처음 우리의 MVP 계획은
1차 MVP: 기획, 설계, 디자인, 공통 컴포넌트 제작 - 1주차
2차 MVP: 페이지 작업 완료 - 2주차
이와 같이 설정하고 3주차에는 디버깅과 배포를 하기로 했었다.
사실 처음 계획을 설정했을 때는 과연 2주차 안에 페이지 작업을 끝낼 수 있을까 약간은 의구심이 들었지만 목표 기한 내에 작업을 끝낼 수 있었다.
이 작업을 통해서 재사용성과 확장성을 고려하는 것의 중요성을 다시 한 번 새길 수 있었다.
3. 디버깅
페이지 작업이 끝나고 대망의 디버깅 시간이 돌아왔다.
버그를 잡아내는 시간이 생각보다 오래 걸릴 수 있기 때문에 최대한 많은 시간을 확보하는게 우선적인 목표였고 앞선 과정들을 통해 약 3일 간의 시간을 확보할 수 있었다.
많은 문제들이 있었지만 크게 정의하면 아래와 같은 문제가 있었다.
- Markdown Editor 강제 포커싱 문제
- react-hook-form default value 문제
- 좋아요 실시간 적용 문제
- 조회수 중복 증가 문제
Trouble Shooting에 대한 자세한 내용은 여기에서 볼 수 있습니다.
4. 배포
이번 프로젝트에서 백엔드 코치님이 도커를 활용하여 배포를 해보라고 강력하게 추천해주신 덕에 도커를 이용하여 배포를 진행하게 됐다.
도커에 익숙하지 않았기 프론트엔드 배포는 다른 팀원이 맡아서 해주셨는데 엄청 고생하셔 가지고 괜히 미안한 마음이 컸다.
그리고 한편으로는 도커와 쿠버네티스 그리고 클라우드 컴퓨팅에 대해서 공부해야겠다고 마음을 먹게 됐다.
✔️
이 프로젝트가 끝나고 약 한달 뒤
카카오와 구름에서 진행한 구름톤이라는 해커톤에 참여하여 클라우드 컴퓨팅에 대해서 전반적인 개념과 흐름을 배울 수 있었다..!구름톤과 관련된 글을 여기에서 볼 수 있습니다:)
🎉 마무리
엘리스를 진행하면서 이렇게 열심히 했던 적이 없었던 것 같다.
자는 시간 빼고는 항상 게더 타운에 상주하면서 팀원들과 소통하고 문제들을 공유하면서 프로젝트를 하나하나 발전시켜 왔다.
이 프로젝트를 하면서 뼈저리게 느꼈던 점이 동료의 중요성이다.
기본적으로 우리는 개발을 잘하지 않는다.
그래서 당연히 실수가 잦고 코드의 퀄리티도 낮을 수 밖에 없다.
그렇기 때문에 옆에 있는 팀원들과 함께 혼자라면 보이지 않을 문제를 찾아내고 코드를 개선시키고 문제를 해결해 같이 성장하는 것이다.
만약 이런 과정들이 없었다면 프로젝트를 회고하는 지금 아..! 진짜 열심히 했구나 가 아니라 뭔가 찝찝한데.. 조금만 더 열심히 해볼걸 이라는 감정이 남아있었을 것이다.
같이 성장하는 것의 가치 를 느낄 수 있었던 프로젝트였다.
