[데브코스] 최종 프로젝트 회고

약 6개월간의 데브코스는 파이널 프로젝트로 불태우면서 끝이 났다.
3주라는 꽤나 짧은 기간동안 필수 요구사항을 모두 만족하기 위해 밤낮없이 프로젝트에만 몰두했었다.
처음 사용해보는 기술 스택 적용, 처음 만난 백엔드팀과의 협업, 디자이너 부재 등등 막막함으로 시작했던 프로젝트를 결국 배포까지 했다는 사실이 2021년 가장 뿌듯한 일 top3안에 들지 않을까.
가성비는 부족하지만 가심비는 max였던 수많은 삽질의 과정을 돌이켜보고자 한다.

# 짧은 요약

🔗 금나와라 뚝딱_배포 URL
🔗 Github Repo

프로젝트의 초기 기획은 '선물하기 서비스'였다.
기존의 서비스들과의 차이점은 선물을 전달하되 받는 사람이 '랜덤' 또는 '뽑기'와 같은 방식으로 선물을 가져간다는 것이다.
지난 프로젝트에서 SNS 서비스를 구현했기 때문인지 이번에는 커뮤니티성보다는 선물 주고받기라는 '기능' 자체에 집중하였다.

주요 기능은 다음과 같다.

• 소셜 로그인
• 이벤트 생성﹒조회﹒삭제
• 랜덤 선물 받기
• 선착순 선물 뽑기
• 받은 선물 조회 및 저장하기

# 기술 스택 선정

• 개발 환경: Node.js 14.17.6
• 언어: Typescript
• 라이브러리: react 17.0.2
• 상태관리: react context api
• 스타일링: emotion 11.5.0
• UI 테스트: storybook 6.3.12
• 배포: Netlify
• 협업: Git, Github, Jira, Notion, Slack

...비하인드

1. 나의 경우 맥 M1을 사용하면서 노드 12버전을 설치했었는데, 노드 14버전 이하는 지원되지 않아 에러가 발생했었다. 결론적으로 팀원들과 노드 버전을 14.17.6 버전으로 통일하였다.
2. 이번 프로젝트는 백엔드팀과 협업하는 만큼 코드 작성 단계에서 타입을 명확히 가져가는 것이 좋겠다고 생각해 타입스크립트를 적용하기로 했다.
   (호기롭게 도전했으나 ts의 타입에러는 개발과정에서 상당한 고통을 주었다.)
3. emotion으로 CSS in JS를 도입하여 별도로 스타일시트를 만들지 않고 js 파일 안에서 동적으로 스타일 작업이 가능하였다. CSS는 globals.css 파일에서 전역 스타일링에만 사용하기로 했다.
   (props에 따라 동적으로 css를 입힐 수는 있었지만, styled-component로만 통일하기에는 불필요한 스타일 관련 props가 늘어나게 되어 오히려 styled-component의 단점을 발견했달까.. 결국 inline style과 함께 사용하다보니 통일성이 없어진 점이 아쉽다.)
4. Storybook을 사용하여 컴포넌트별로 테스트를 함으로써 이슈를 미리 파악하고 팀원 간 구현 결과를 공유하기 용이했다.
   (하지만 브라우저에서는 실행되지만 storybook에서는 에러가 나는 경우가 있어 관련 이슈를 해결하다보니 테스트에 너무 많은 시간을 쓴 것 같기도 하다.)
5. 상태관리 시 react context를 사용한 것은 이번 프로젝트에서 전역적으로 관리되어야하는 상태가 많지 않았기 때문이다. user 정보 정도만 전역으로 관리하면 되는 상황에서 redux를 사용하는 것은 오버스펙이라는 생각에 userContext 정도만 만들어 두고 사용하였다.

# 고난과 역경

1. 개발 이슈

하나씩 포스팅으로 정리할만한 이슈들을 모아보았다.

• [React] setState에 대한 오해 바로잡기
• [React] Hooks의 의존성이 왜 중요한지
• [Next.js] Link(a태그)와 router.push
• [Typescript] 정적 이미지 파일 모듈로 활용하기
• [Javascript] dynamic import

2. 협업 이슈

with FE

프론트팀 내에서의 이슈는 우선순위를 정하는 것이었다. 기간이 짧았던 만큼 의사결정 주기 또한 짧았기 때문에 1주마다 스프린트 기간을 가져갔음에도 1주일 안에서의 우선순위를 또 정할 필요가 있었다.
그러나 몇번의 프로젝트를 통해 느낀 것은 프로젝트 배포 일정 맞추기라는 최종 보스 앞에서는 코드 퀄리티도, 스타일링도, 치명적이지 않은 이슈들도 결국 후순위가 되어버린다는 점.
결국 특정한 기준, 누군가의 주장에 따라 우선순위를 정하는 것이 아니라 우리가 처음 목표로 했던 '배포 일정을 맞출 수 있는가'에 지장이 없다면 진행하고, 그렇지 않다면 과감히 미루었다. (기술부채 득템!)

with BE

초기에 최대한 꼼꼼히 요구사항을 정해도, 개발 중에 추가 논의 사항이 생기는 것은 어쩔 수 없다. 그 과정에서 백엔드와 프론트엔드 중 어느 쪽에서 가져갈 이슈인지 애매한 것들이 문제가 되었다. 그 때마다 멘토님들께 현업에서의 처리 방식에 대해 조언을 구하거나 다같이 토론하며 해결했다.
(다행히 모든 팀원이 원만한 커뮤니케이션 기술 보유자여서 신속한 논의 후 빠른 결론을 도출해낼 수 있었다.)

ex. 소셜로그인 api 요청과 s3 업로드는 백엔드에서 담당, 데이터 조회 시 필터링은 백엔드﹒정렬은 프론트에서 담당, etc..

# 내가 배운 것들

1. resolve 스킬

이슈기반으로 프로젝트 진행을 하다보니 PR을 올리면 관련 이슈를 resolve하게 된다.
그 resolve 하나를 위해서 필요한 스킬은 바로 팀원들과 소통하기였다.
코멘트로 코드리뷰를 남기는 것 뿐만 아니라 이해되지 않는 부분은 바로바로 물어보고 더 좋은 방법을 제시하면서 그 과정에서 지식적으로도, 커뮤니케이션 적으로도 가장 많이 배울 수 있었다.

2. memo 스킬

지난 프로젝트에서 많은 이슈를 겪은데 비해 기록으로 남기지 않았던 것이 한으로 남았었다. 그래서 이번에는 반드시! 이슈를 기록해두고 싶었다. 완벽하게 정리하자는 완벽주의를 버리고 아주 사소한 것이라도 키워드나 관련 링크, 이런 이슈가 있었고 이렇게 해결했다 정도를 목표로.
그렇게 팀원들과 동기적으로 공유하지 못한 이슈는 노션에 남겨두곤 했는데 비슷한 상황에서 유용한 자료가 되어주었다.

3. scheduling 스킬

그동안 나의 약점으로 일정관리의 어려움을 꼽곤 했다. 특히 해보지 않은 일은 일정 산정이 더 어려웠기 때문이다. 이번 프로젝트에서는 스프린트를 1주일 단위로 가지고 갔다(보통은 2주 정도라고 들었다). 일주일 안에서의 세부 일정 관리는 여전히 힘들었지만 매주의 스프린트 목표는 모두 달성할 수 있었다.
+물론 하루의 밤낮이 바뀌는 등 생활적인 측면에서는 바람직하지 못했지만.. 또 어딘가에 몰두해서 살 수 있어서 그저 행복했다!

# 앞으로의 숙제

이번 프로젝트를 통해서 체득한 지식들이 많다. 그 중 제대로 정리해두고 싶은 것들 몇가지를 남겨보자면,

• SSR과 CSR과 그 사이 어딘가의 Next.js (Next를 더 잘 써보고 싶다.)
• React의 상태관리 (+Hooks를 통한 최적화)
• JWT 토큰 관리 방법 (사용자 인증에서의 보안 이슈)

직접 타입스크립트나 React + Next.js를 써보면서 신기했던 것도 많고해서 더 공부해보고 싶어졌다.
물론 이번 프로젝트 리팩토링도 계속하고 있다. 잔여 이슈를 모두 해결하는 것이 목표다!