조리복 프로젝트 - 아이디어 빌딩 및 초기 환경 설정

Sally·2022년 12월 15일
7

조리복

목록 보기
1/4
post-thumbnail

토이프로젝트의 시작

토이프로젝트를 시작하게 되었다. 우아한테크코스도 마무리가 된 이후에 SSR에 대해서 배워야지 라는 생각을 계속해서 하고 있었다.
그 이유는, "새로운 것에 대해서 궁금해서" 그런 단순한 계기였다.

저 SSR은 왜 뜨고 있는것인가에 대해서는 이론적인 이유는 알고 있지만, 내가 직접 체험을 해보지 않았으니 마음에 와닿지 않았다. 이게 정말 빠른건지도 모르겠고...

SSR이 어떻게 구현되고 있는 건지 현직에 계신 분들에게 많이 질문도 하고 다녔지만 주변에 귀동냥으로 듣는 것으로는 왠지 성에 차지 않았다.


"더... 더 자세히 알고싶어! SSR 궁금해!! "

그런 계기로 토이프로젝트를 시작하게 되었다😅

이번 프로젝트에서 얻고자 하는 것

하리와 세지가 토이프로젝트를 같이 하게 되었다(소중한 우리 동료들😘)
그리고 우리는 프론트개발자로써 모두 모였지만 풀스택에 도전해보기로 하였다.

이렇게 결심하게 된 이유는 과거의 경험이 크다.

우아한테크코스에서 팀 프로젝트를 진행하면서, 백엔드와의 소통 시에 막히는 부분들이 몇 군데 존재하였다.
예를 들어 기능을 어떻게 할지 합의를 하거나 api 설계에 백엔드와 같이 논의하게 되면 프론트엔드는 어느 순간 백엔드의 토론을 구경하고 있을 때가 있었다. 데이터베이스 테이블을 이렇게 만들고 어떻게 해야 api 기능에 맞게 효율적으로 데이터를 찾아올것이냐 이 api가 가능하냐 라는 이야기를 할 때에 가만히 들으면서 기다리는 경우들이 있었다.

하지만 이럴 때 대화에 끼고 우리 서비스에 더 발전적인 방향으로 의견을 내고 싶었다.
해당 api가 정말 가능한지, 이렇게 응답값을 받을 수 있는지 미리미리 판단해 의견을 백엔드에게 내고 싶었다.
추가로, 본격적으로 현직에 나가기 전 서버까지 찍먹을 해본다면 백엔드와의 소통할 때에 더 유연해지지 않을까 라는 생각도 있었다.

기술 스택

  • Typescript
    이제는 자바스크립트로 작성된 파일을 보면 낯설어졌다.
    타입스크립트가 어렵긴 해도, 타입안정성을 확보할 수 있어서 장기적으로는 유지보수에 더 유리할것이라고 생각되어 선택하였다.
  • Next.js
    토이프로젝트의 시작이라고 할 수 있는 SSR을 위한 프레임워크이면서 팀원들 모두 리액트에 익숙한 상태이기 때문에 React의 프레임워크인 Next로 프론트를 개발하기로 결정하였다.
  • Emotion
    팀원들 모두 Emotion에 익숙한 상태라는 것이 가장 컸고, css prop을 통해서 prop값마다 다르게 스타일링을 줄 수 있어서 선택하게 되었다.
  • Jotai
    Recoil에서 벗어나 찾아낸 전역상태관리 도구이다. 팀원들 중 아무도 Jotai를 사용한 경험이 없었지만, Recoil를 사용하면서 느꼈던 단점에는 모두 공감했기 때문에 다른 도구를 찾게되었다. Recoil이 공식 문서도 잘 되어있고 hook처럼 문법을 사용하기 때문에 편리한 점이 있다. 하지만 리액트 쿼리를 사용하기로 하였기 때문에 Recoil의 서버 상태관리를 제공해주는 기능이 필요없었고 우리에게 필요없는 기능들 때문에 커진 용량이 부담스러웠다. 그래서 그의 대체재로 용량이 가볍고 hook의 문법과 유사하게 문법을 제공하는 Jotai를 선택하게 되었다. 후보군에 Zustand도 있었지만 공식문서가 그나마 더 잘 되어 있는 Jotai를 사용하게 되었다.
  • React-Query
    Emotion과 마찬가지로 팀원들 모두 익숙한 상태라는 것이 컸다. 그리고 사용했을 때에 리액트쿼리와 사랑에 빠진 것 같다. (개인적으로는) 서버상태관리를 하는 게 너무 편하다. 리덕스로 했을 때에 생성하는 보일러플레이트 코드가 싹 빠지니 코드도 간결하다. hook으로 빼서 관리하는 것도 개인적으로는 컴포넌트단이 깔끔해져서 마음에 들었다.
  • Storybook
    스토리북의 초기설정은 삽질을 많이 했어야 했고, 어떤 패키지를 설치하면 충돌나는 부분들도 있어서 사용하면서 짜증나는 부분들이 있었다. 하지만 CDD (Component - Drived - Development)를 위해서는 꼭 깔아야하고 해당 부분에서는 만족도가 높았기 때문에 포기하지 못했다. 컴포넌트 만들고 어떻게 보여지는지 컴포넌트단에서 호출안해도 볼 수 있는게 개발에 많은 도움이 되었기 때문이다.
  • MSW
    풀스택으로 개발하기 때문에, 우리에게 익숙한 프론트부터 개발하기로 협의를 봐서 API mocking이 필수적이였다. 그 이전에는 모두 API mocking으로 결과를 봐야하니 말이다.
  • Nest
    Next와 이름이 비슷해, 팀원들끼리 이름으로 장난 좀 쳤다. 넥스트 네스트....
    백엔드개발 도구로 선택하였다. 일단 나를 제외한 팀원들은 Node.js를 통해서 백엔드를 개발해본 경험이 있었다. 그래서 Express나 Node로 하면 속도감 있게 할 수 있겠지만 Nest가 타입스크립트로 개발이 가능하다는 점과 Node의 프레임워크라는 점에서 배워볼 가치가 있다고 고려되어 선택하게 되었다.

아이디어 빌딩

아이디어는 설날에 맞춰서 출시하기 위한 아이디어로 선정하였다.
현재 거의 (준)방학이기 때문에 개발일정이 늘어지기 쉬워서 아이디어를 설 전에 출시하지 않으면 무의미해져버리는 것으로 잡아 긴장감있게 하기 위해서였다.

아이디어 구체화 피그마로 화면 그리기, API 설계까지 하루만에 끝을 냈다😱

이제 도가 텄구나? 우리 팀원들.... (우테코에서 제대로 훈련됐다)

아이디어는
새해맞이 계획 공유서비스 라고 말하면 될 것 같다.

자세한 내용은 미리 말하면, 서프라이즈가 안 되니깐 추후에 공개할 예정이다 후후 😎

초기 환경 설정

다들 초기설정 이제는 쉬울지 알았다...
하지만 언제나 사람은 망각의 동물이랬던가? 그것도 아니면 그냥 처음 써보는 기술이 많았던 탓일까?
쉽게 끝날줄 알았던 초기 환경 설정은 생각 외로 늘어졌다.

일단, 패키지 매니저 도구를 처음에 pnpm으로 설정하여 시작하였다.
하지만 문제가 생겼다. Next설치까지는 어찌저찌 됐는데 Storybook이 말썽이였다.
Next와 Storybook의 조합도 좋지 않았나 보다. yarn과 같은 도구를 사용하면 쉽게 깔렸었던 Storybook이 pnpm으로 깔자 설치가 되지 않았다. 그래서 yarn-berry로 교체하여 깔았다.

힘겹게 설치하고나니, Next에서 모듈들을 찾아내지 못하고 있었다ㅠㅠ 정확히는 타입에러를 발생시키고 있었다.

우리 팀은 하나의 가설을 세우게 된다. tsconfig설정을 잘못했거나, yarn-berry의 잘못이거나
tsconfig를 열심히 뜯어 고쳤지만 나아질 기미가 보이지 않았다.
결국 2시간 만에 yarn-berry에서 npm으로 넘어가게 되었다.
이젠 잘 되더라....
처음 부터 npm나 yarn으로 했으면 문제가 없었을 것을..! 약간은 허탈했다.

시간적 여유가 있었다면 yarn-berry나 pnpm에 좀 더 도전해서 해결했겠지만, 현재는 새로운 프레임워크 때문에 배울 것도 시간적 여유도 없었기에 npm으로 합의를 보게 되었다.

3개의 댓글

comment-user-thumbnail
2022년 12월 16일

샐리 그만 잘해~~~

답글 달기
comment-user-thumbnail
2022년 12월 16일

샐리와 하리.. 어딘가 익숙한 조합이네요..

답글 달기
comment-user-thumbnail
2023년 2월 24일

상태 관리 라이브러리 고민 중이었는데 Jotai를 비교해주신 부분이 큰 도움이 되었습니다. 자세하면서도 필요한 내용만 깔끔히 잘 정리하시는 것 같아요!

답글 달기