todo list 기획하기

솔로 프로젝트로 투두 리스트를 만들어보기로 했습니다. 많은 사람들이 처음 개발 공부를 하면서 만들어보게 되는 것인데 전 아직 제대로 만들어 본 적이 없었네요.

기획

디자인

디자인도 잘 모르고 망칠 것 같다는 생각에 항상 기존 서비스를 따라서 만들게 됩니다. 이번에는 마이크로소프트의 todo를 참고해서 디자인을 기획했습니다.

피그마를 이용해서 디자인 작업을 했는데, 전체 기능을 다 기획하기 보다는 대표적인 추가, 삭제 기능을 정도를 위주로 했고, 리액트로 개발할 때 참고할 정도의 디자인만 만들었습니다.

웹으로 만들기는 하지만, 뷰의 사이즈는 앱을 기준으로 만들었기 때문에, 리액트로 작업할 때도 모바일 디스플레이에 맞춰 먼저 완성하고 이후 반응형으로 수정할 생각입니다. 사실 처음 만들 때부터 반응형으로 만드는 것이 좋다고 생각하지만, 단순히 컴포넌트들의 너비만 늘리게 되면 뭔가 비어있는 느낌이 들어서 디자인을 조금 생각하고 만드는 것이 좋다고 판단했습니다.

로그인 기능

디자인 단계에서는 고려하지 않았던, 사용자 로그인 기능을 넣을 생각입니다. 로그인 된 사용자별로 가지고 있는 투두리스트를 화면에 보여줄 예정이고, 로그인 기능은 완전히 보안을 생각한 기능보다는 실제 백엔드와 협업을 할 때 고려하는 점이나 로그인 동작 방식을 흉내내는 식으로 만들 생각입니다. 서버에 로그인 요청과 유저 정보를 받아와서 사용하는 방식을 생각 중이고, 쿠키를 이용해서 로그인 기능을 구현할 것입니다. 사용자 정보는 데이터베이스를 이용할 것인데, 실제 RBMS인 MySQL이나 No SQL인 몽고 디비와 같은 데이터베이스를 서버에서 직접 다루게 되면 작업 시간이 서버에서 많이 소요될 것 같아서 supabase를 이용할 생각입니다. 물론 처음 사용하는 것이기 때문에 api docs를 참고해서 작업하기는 하지만, 그래도 충분히 사용할 수 있다는 생각입니다.

데이터베이스

현재 고민 중인 부분이 바로 데이터베이스입니다. todo list의 경우 큰 데이터가 저장되는 것이 아니고, 수정을 쉽게 할 수 있는 어플리케이션이라고 생각하기 때문에, todo 내용을 모두 데이터베이스에 저장하게 되면 서버와의 통신이 빈번하게 될 것이고, 데이터 베이스에서 반복적인 업데이트 작업이 있을 것이라고 생각됩니다. 데이터베이스에 crud작업을 하는 것이 어려운 것은 아니지만, 사용자가 이용할 때 뷰의 변화가 바로 반영이 되지 않는 경우가 있을 수 있어 고민이 되네요. 데이터 베이스 자체가 로컬 데이터 베이스가 아니기 때문에 약간의 딜레이가 있을 것이라 생각했기 때문입니다.

디자인에서 보았듯이, 중요한 데이터는 별 아이콘을 누르거나, 완료된 작업은 왼쪽 버튼을 누르는 식이 될텐데, 그럴 때마다 데이터 베이스에 접근해서 내용을 수정하는 방식이 괜찮을까하는 생각입니다. 대안으로는 브라우저의 로컬스토리지를 이용하는 방법이 있는데, 나쁜 방법은 아니라고 생각합니다만, 데이터 베이스를 이용해보고 싶은 마음은 아직 있네요. 또 다른 방법으로는 뷰에서 처리를 먼저 한 뒤에 시간을 두고 데이터 베이스에 반영하는 방식이 있겠네요. 현재 제일 고려하고 있는 방법입니다. 실제로 데이터 베이스에 반영되는 시간은 좀 걸리지만, 사용자 입장에서는 변화가 즉각 반영되고 있다고 생각하게 될 것입니다. 문제는 데이터 베이스에 반영되기 전에 브라우저를 닫거나 하는 경우 데이터의 무결성이 깨지게 될 것이라는 걱정이 있네요.

이런 고민으로 아직 todo 내용과 관련된 테이블을 만들지는 못했습니다. 그래도 유저 정보를 저장하는 테이블을 만들고 실험이 끝났기 때문에 로그인 기능만 완성되면 바로 클라이언트와 연결시킬 수 있을 것 같습니다.

클라이언트

어느정도 기획이 끝났으니, 앱을 만들 때 고려할 것을 생각해봅시다.

vite? cra?

앱은 리액트를 이용해서 만들 생각입니다. vite를 사용할까 생각했지만, 일단 익숙한 CRA를 이용해서 만들 생각입니다.

css

css작업은 css모듈을 이용할까 했지만, 먼저 styped-components에 좀 더 익숙해지고 싶은 생각이 있기 때문에 이것을 이용할 생각입니다.

라이브러리

네비게이션 바를 이용해서 오늘 할 일, 매일 할 일, 중요한 일을 보여줄 것이기 때문에 routing이 필요할 것이라 생각됩니다. 그래서 react-router-dom을 사용할 것입니다.

기본적으로 로그인 기능을 사용할 것이기 때문에 데이터를 전역에서 관리할 수 있게 reduxjs/toolkit을 사용할 것입니다. 리덕스에 익숙해지는 것이 필요하다고 생각해 로그인된 유저정보와 함께 todo items도 리덕스로 관리할 것인데, 기본적으로 상태 변경을 리덕스에서 한 번에 관리하기 쉽기 때문에 그런 것도 있습니다.

또한, 간단한 아이콘은 원래 font-awesome cdn을 이용했는데, 이번에는 react-icons라는 라이브러리를 사용해볼 생각입니다. 사용법은 어렵지 않고, 단지 무겁지 않을까하는 생각이지만, 그래도 크게 차이는 없을 것 같아서 사용해보려고 합니다.

데이터 패칭은 패치 요청을 커스텀하지 않기 때문에 fetch api를 사용해도 되고, axios를 사용해도 된다고 생각합니다. 일단 axios를 사용할 생각입니다.

서버

서버는 위에서 대충 어떤 식으로 진행할 지 언급했습니다. 제일 중요한 것은 데이터베이스 연동이라고 생각하고, 로그인 기능은 실제 로그인 서비스와 조금이라도 유사하게 만드는 것이 목표입니다.

라이브러리

서버 앱은 express를 이용해서 만들 생각입니다. 서버에 대해 조금은 알지만, 잘 한다고 생각은 안들고, nest.js는 사용한 적이 없기 때문에 그나마 익숙한 express를 이용할 것입니다.

기본적으로 origin이 리액트 앱과 다르기 때문에 cors처리를 해주는 것이 필요합니다. 그렇기 때문에 cors라이브러리를 사용해서 그 처리를 해줄 것입니다.

데이터베이스를 supabase를 이용할 것이기 때문에 그와 관련된 라이브러리들을 설치해서 사용해야 합니다. 어떤 것이 필요한지는 공식 홈페이지에 나와있어 쉽게 받을 수 있습니다.

데이터베이스를 사용할 때, api key와 database url이 필요하기 때문에 이를 저장할 .env파일을 사용할 것입니다. 서버에서 .env를 사용할 때 dotenv라이브러리를 사용하기 때문에 이를 이용할 것입니다.

유저 정보를 그대로 저장할 생각이었지만, 그래도 비밀번호를 좀 변환해야할 것 같아 crypto를 이용할 생각입니다. 또한, 로그인 기능을 쿠키로 구현할 것이라 cookie-parser도 사용해야 합니다.

대충 기획은 이렇게 끝난 것 같습니다. 이제 실제 앱을 만들면서 고민한 점이나, 알게된 것들을 계속해서 블로그에 남길 생각입니다. 사실 이 포스트를 쓸 때 기본적인 클라이언트 상에서의 CRUD기능은 완성된 상태이기 때문에 그 과정에서 있었던 고민들을 잊어버렸을 수 있지만, 기억을 더듬어 가면서 작성해보겠습니다.