프로젝트 시작
현재 수강 중인 엘리스 트랙에서 마지막 프로젝트를 진행하게 되었습니다. 프로젝트 팀원은 총 6명. 백엔드 2명 프론트 4명으로 생각보다 프론트엔드 비중이 좀 높았습니다.
3주라는 시간 동안 한 개의 프로젝트를 기획-개발-배포해야 하는 일정이라 개인적으로 일정이 좀 빠듯하겠다는 생각을 했습니다. 금요일 저녁에 팀이 꾸려지고, 당장 월요일부터 개발을 시작해야 하는 거라 아이디어 짜기가 제일 힘들었습니다.
기획 아이디어를 짤 때 내가 평소 생활에서 가장 불편한 점이 뭘까에 대해 집중을 하고 기획 아이디어를 구체화시켰습니다. 주어진 환경에서 복잡한 비즈니스 로직이 필요한 서비스나 외부에서 제공되는 로우 데이터가 요구되는 서비스는 주어진 환경에서 구현하기 힘들다는 판단이 되었습니다.
평소에 하루를 기록하는 습관을 길렀으면 좋겠다고 생각을 했고, 하루 결산을 하는 템플릿이 있으면 좋겠다 생각했습니다. 노션이 있지만, 노션이 생각보다 무거워서 서비스가 빠르지 못한 것 같은 불편함을 느꼈습니다. (개인적으로 컴퓨터 성능이 좋지 못하고, 노션 활용을 잘 못해서 일 수도 있습니다) 그래서, 하루 기록을 하고, 그것을 통계까지 내주는 서비스가 있으면 좋겠다는 생각이 들어서 일일 결산 서비스를 구상하게 되었습니다.
23:59
감사하게도 팀원들이 제가 말한 아이디어를 좋게 봐주었고 함께 구체화했습니다. 서비스는 모바일 퍼스트가 아닌 웹 퍼스트를 전제하고 기획을 했습니다. 하루 마무리 일기를 적는데 모바일보다는 웹이 더 편하지 않을까...라고 가정했습니다. (왜냐하면 서비스의 기획이 제가 필요한 서비스라고 생각을 했기 때문..)
모든 페이지를 위 이미지와 같이 추상화하며 작성을 하면서 기획을 했습니다. 페이지별로 필요한 기능이 무엇인지에 대해 함께 구현해야 할 기능을 구체화했습니다. 페이지별로 구현해야 할 기능에 대해 체크리스트를 만든 것들을 보고 프론트와 백에 주고받아야 할 API가 무엇인지 어떤 데이터를 요청하고 전송할 것인지 API 명세를 추상적이게나마 함께 이야기했습니다.
디자인
가장 큰 문제는 디자인이었습니다. 피그마를 통해 와이어 프레임을 빙자한 페이지별 UI 구성을 했는데 디자이너는커녕 피그마를 다뤄본 사람이 전무해서 진짜 추상적으로만 디자인을 할 수밖에 없었습니다. 디자이너의 필요성을 절절하게 느꼈던 한 주였습니다... 나름 편안하고 몽글몽글한 분위기를 풍기는 서비스였으면 좋겠다는 모두의 주장에 서로 레퍼런스를 찾고 테마 색과 폰트를 정하고 일단 개발하자라는 생각으로 개발 스택 선택에 들어갔습니다.
개발 스택 선택
*프론트엔드 개발 스택만 선정했습니다.
개발 스택을 선택할 때 가장 중요하게 여긴 것이 타당한 이유를 가지고 스택을 선정하자였습니다. 단순히 이 라이브러리를 배웠으니까, 남이 좋다고 하니까라는 생각 보다 우리가 기획하는 서비스에 가장 잘 맞는 fit이 무엇인지를 고려해서 선택하자 했습니다.
전체 개발 언어 및 라이브러리
전체적인 라이브러리와 언어는 React + TypeScript를 통해 개발하기로 했습니다. 우선 기획에서 나온 얘기로 랜딩 페이지 없어 로그인/비로그인 유저 모두 서비스 체험이 가능하도록 개발하기로 했습니다. 그리고 일일 결산이라고 해도 깊게 들여다보면 유저 혼자서 사용하는 CRUD 기능과 약간의 통계(?)를 보여주는 기능밖에 없었기에 CSR 형식으로 서비스를 제공하는 것이 가장 알맞을 것이라 생각했습니다. TypeScript의 경우에는 정적 타이핑을 통해 에러를 미연에 방지할 수 있기 때문에 선정했습니다.
상태관리
상태 관리에는 전역 상태 관리와 서버 상태 관리 2가지를 좀 더 편하게 해줄 라이브러리를 생각했습니다. 전역 상태 관리로 생각한 라이브러리는 Recoil과 Redux이고, 서버 상태 관리 라이브러리로는 RTKQuery, SWR, React-Query였습니다.
우선 Recoil과 Redux 둘 중에 하나를 선택해야 했습니다. 이번 서비스에서 전역적으로 상태 관리할 데이터의 양과 형태에 대해 생각을 했습니다. Modal 창 다크 모드, 작성 컴포넌트에서 저장될 입력값(?) 정도밖에 없다고 판단되었습니다. 따라서 보일러 플레이트 코드가 많고, 많은 양의 데이터를 다룰 때 유리한 Redux보다는 러닝 커브가 낮고 좀 더 직관적인 Recoil을 사용하기로 했습니다.
서버 상태 관리 중 RTKQuery는 Recoil을 선택하면서 자동으로 누락이 되었습니다. 이제 SWR과 React-Query 둘 중 하나를 선택해야 하는데, 두 라이브러리의 스펙을 비교해 본 결과 SWR이 좀 더 빠르고 fetch가 많은 서비스에 알맞고, React-Query는 업데이트가 좀 많이 일어나는 서비스에 적합하다는 이야기가 있어서 단일 유저의 CRUD를 제공하는 저희 서비스의 특성상 SWR이 좀 더 적합하다는 판단에 SWR을 선택했습니다.
Style
스타일 관련 라이브러리는 emotion, MUI Components, Styled-Components, tailwindcss 등 CSS-in-JS, css framework 등 다양한 형태의 선택지가 있었습니다. 하지만 css framework를 사용하게 된다면 스타일 커스텀에 있어서 자유도가 떨어진다는 단점이 있습니다. 하지만, 디자인이 단점인 저희 팀의 특성상 약간의 정형화된 디자인 스펙이 있으면 훨씬 좋다고 생각했습니다. 그래서, 기본적인 스타일 가이드를 제공해 주면서 자유도가 높은 tailwindcss를 선택했습니다.
하지만 tailwindcss의 단점으로 꼽히는 좋지 않은 가독성과 css 파일처럼 여러 컴포넌트에 같은 디자인을 적용하기 위해서는 가독성 좋지 않은 코드를 반복해야 하는 단점이 있었습니다. 이를 보완하기 위해서 tailwind-styled-components라는 라이브러리 도입을 통해 tailwindcss에 styled-components를 씌워 놓은 듯한 라이브러리로, 현재 저희에게 필요한 정형화된 스타일과 깨끗한 디자인 코드를 모두 만족시켜줄 수 있는 라이브러리라 판단되어 선택했습니다.
저희가 갖고 있는 인사이트에서 서비스에 맞는 최선의 스팩을 선택했다 생각했지만, 각각 개발 경험이 다르다 보니까 새로운 라이브러리에 적응하는 기간도 즉 러닝 커브가 있을 거란 생각이 듭니다. (우선 저부터...)
고민
3일 정도 개발을 하면서 느낀 점이, 피그마를 통해 완벽한 디자인이 나온 것이 아니기 때문에 통일된 디자인이 없다 보니 공통으로 사용할 컴포넌트 제작에 약간 어려움이 있습니다. 즉, 모두 공통적으로 사용하는 컴포넌트가 있다면 생산성이 더 늘어날 텐데 디자인이 통일된 것이 아니다 보니까 어떠한 형식으로 컴포넌트를 생성할지 감이 잡히지 않습니다. 뭔가 디자인에 좀 더 시간을 쓰자니 개발을 하는 것이 좀 더 효율적이지 않나라는 생각이 들기도 합니다.
우선 개발을 다 하고 리팩토링을 하냐 vs 어느 정도 통일된 디자인을 뽑은 다음에 전자보다 더욱 효율적으로 개발을 하냐에 대한 딜레마가 이어지고 있습니다. 물론 둘 모두 정도의 차이가 가장 중요하겠지만, 공통된 컴포넌트 없이 각자 개발을 하는 것이 효율적인지에 대한 고민이 깊어지고 있습니다.
무엇이 팀적으로 더욱 효율적인지 빠른 판단이 필요할 것 같습니다.
