캘린더 라이브러리를 만들어 배포하며 배우고 느낀 점을 공유합니다.
⛳️ 목표
1.
일반 사용자가 아닌, 개발자에게 편리하고 유용한 라이브러리를 제공한다.
2.
일반 웹 서비스가 아닌, 라이브러리 제작 및 배포 과정의 A to Z를 체험하고 익숙해진다.
3.
Props 적극 사용으로 개발자들이 취향에 맞게 커스텀 할 수 있도록 한다.
4.
사용자에게 피드백을 받고 유지보수 및 운영하며 더 나은 라이브러리를 만든다.
결과물
비하인드
무엇을 만들까
평소 개발을 하면서 캘린더, 아코디언 등 많이 사용되는 UI들 중 하나 정도는 직접 내부 구현을 해보면서 원리를 알면 좋겠다고 생각했다.
그리고 지금까지 일반 사용자들을 위한 웹 서비스들을 만들어 왔다면, 이제는 개발자들을 위한 무언가를 만들어 보며 색다른 경험을 해보고 싶기도 했다. 후보로는 라이브러리, Chrome Extension, Mac 내장 프로그램 등이 있었는데, 이 중 라이브러리 배포를 선택했다. ‘개발자를 위한 무언가를 만들고 싶다’는 니즈와 더 배우고 싶은 기술 스택이 있다는 측면을 고려했기 때문이다. 더불어, 내가 직접 만든 라이브러리를 사용하는 개발자들이 이슈를 제보하면 그것을 수정하고 운영해 보는 경험도 재미있을 것 같았다.
어떤 라이브러리를 만들까
어쨌든 라이브러리를 만들기로 하고, 그 다음에는 어떤 라이브러리를 만들어야 할지 고민이 많았다. 처음엔 호기롭게 흔하지 않고 대단한 것(?)을 만들어보고 싶었다. 이미 너무 흔하고 널린 라이브러리는 만들어서 뭐하나 싶었기 때문이다. 하지만 한 편으로는 이런 생각이 들었다.
1.
‘내가 어렵고 복잡한 것을 만들 수 있는 역량을 갖추었는가? → 글쎄 그럼 쉬운 걸 만들자!
그럼 쉬운 걸 만들자!2.
‘흔하게 널린 라이브러리라도 누군가에게는 내가 만든 라이브러리가 필요하지 않을까? 그리고 나와 같은 사람들의 이런 생각들이 쌓이고 쌓여서 어쩌면 더 좋은걸 만들어내고, 이 개발 생태계를 조금이라도 발전시킬 수 있다면 좋지 않을까?’ → 좋은데? 그럼 흔한 거라도 괜찮다!
그럼 흔한 거라도 괜찮다!캘린더 라이브러리를 만들자
결론적으로, 만들기 쉽고 흔한 ‘캘린더’ 라이브러리를 만들기로 했다. 일단 처음이니까 상대적으로 난이도가 쉽고, 사람들이 자주 쓰는 것부터 만들어보기로 했다. 후보로는 사전, 번역기, 달력, 맞춤법 검사기, 버튼, 모달 등이 있었지만, 최종적으로 ‘캘린더’를 선택했다.
레퍼런스
디자인
노션의 캘린더 (라이트 모드 / 다크 모드)
문서화
캘린더
•
react-calendar → 가장 기본적인 달력 형태•
react-check-in-out-calendar → 체크인/체크아웃 표시 가능한 달력•
react-day-picker → 하고자 하는 형태와 가장 비슷한 달력 기술 스택
개발 언어
TypeScript React
스타일
Styled-Components
지난 random-picker 프로젝트에서는 Emotion을 사용했다. (정확히는 @emotion/styled) 개인적으로는 Emotion보다 Styled-Component가 사용하기 편하다는 점, 정보가 많은 점이 좋았다.
만약 Emotion이 여러 면에서 뛰어나다면 이번에도 Emotion을 사용하려 했으나, 성능이나 번들 크기 및 사용 방법에 있어 Styled-Components와 다른 점을 크게 못 느꼈기에 Styled-Components을 채택했다.
빌드
Vite
마찬가지로, 지난 프로젝트에 이어 이번에도 Vite를 선택했다. 선택한 이유는 아래와 같다.
개발 환경
Node.js v18.18.0로, npm v9.8.1를 사용했다.
요구사항
기능은 크게 네 가지로 나눌 수 있겠다.
사용자가 특정 날짜를 선택할 수 있다.
사용자가 특정 날짜를 입력할 수 있다.
사용자가 특정 달로 이동할 수 있다.
현재 달에 이전 달의 날짜와 다음 달의 날짜가 표시된다.
TIL
아래는 간단한 배움들만 기록하고, 자세한 내용은 별도의 포스팅으로 기록했으니 참고해주세요
설계
라이브러리 만드는 흐름부터 정리해 보기
CSS 속성
줄바꿈 동작 결정
스크롤바 숨기기에 사용되는 속성
styled-reset 사용하기
개발
.ts와 .tsx의 차이
React의 중요한 파일 3가지
빌드와 배포
src와 dist의 차이
배포 전 package.json 검토하기
배포 전 tsconfig.json 검토하기
배포 전 vite.config.ts 검토하기
회고
Keep
처음부터 라이브러리를 만들어야겠다고 마음을 먹은 건 아니었다. 평소 누군가가 개발한 라이브러리를 갖다 써보기만 했지, 직접 만들 생각은 못했다. 왜인지 라이브러리는 개발을 잘 하는 사람들만 만드는 느낌이었기 때문이다. 하지만 생각을 고쳐먹은 게, 복잡한 라이브러리만 있나?
아니다. 내가 React 같은 대단한 라이브러리를 만드는 것도 아니었다. 위의 비하인드 스토리에서도 언급한 것처럼 간단한 것부터 만들어 보자 생각했고, 결론적으로 지금은 만들어보길 참 잘했다는 생각이 든다. 그리고 앞으로도 종종 유용하고 쓰기 편한 라이브러리들을 지속적으로 만들어 배포할 생각이다.
현재 내가 사용하고 있는 라이브러리, 프레임워크, 서비스들은 처음부터 완벽하고 대단한 형태가 아니었을 것이다. 대단해 보이는 그것들은 사실, 숱하게 고민하고 시도하여 버전 업데이트를 거듭한 결과물인 것이다. 그러니 앞으로도 어렵다고 지레 겁먹지 말고, 모든지 일단 시작하고 한 단계 한 단계 나아질 생각을 해야겠다.
지난 프로젝트에서는 별도의 브랜치를 만들지 않고 모두 main 브랜치에 바로 push해서 별다른 작업 기록이 남지 않은게 아쉬웠다. 그래서 이번 프로젝트에서는 브랜치를 따로 파서 작업하고, Pull request를 남기고 직접 Merge했다.
이렇게 PR을 남기니 작업한 기록도 남길 수 있어 좋았다. 앞으로도 혼자 작업하더라도 이렇게 PR을 남겨서 어떤 작업을 했고, 무엇이 문제였으며, 어떻게 해결했는지 보다 구체적인 기록을 남겨 보아야지.
이번 프로젝트에서도 작업하면서 배운 점들, 에러 해결 과정 등을 그때그때 기록하고, 가능하면 정리까지 해두어서 블로깅하는 시간을 줄일 수 있었다. (블로깅하다가 에러를 재현하려면 그것 또한 귀찮은 일이 없다..) 무엇보다 이렇게 돌아보면서 하나하나 곱씹어가니 진짜 성장을 하는 느낌도 든다. 앞으로도 프로젝트를 하면서 기록만큼은 잘 남겨야겠다 생각했다.
Problem
빌드와 배포를 하면 할수록 package.json, tsconfig.json, vite.config.ts 등 문서들을 잘 작성해야 한다는 점을 절실히 깨달았다. 그동안 로컬에서만 작업하면 위의 문서가 크게 중요하진 않았는데, 빌드와 배포할 때 위의 문서 내용을 조금이라도 잘못 쓰면 시간이 굉장히 지체되었다.
앞으로는 어떤 항목을 넣어야 문제없이 배포될 수 있는지 조금이나마 알았으니, 다음에는 이 부분에 있어 시간을 줄여보고 싶다. 어느 하나라도 의미 없는 것은 없고, 코드와 기계는 거짓말을 하지 않는다!
기능 구현에 생각보다 시간이 오래 걸렸다. 고작 캘린더 하나 구현한다고 얕잡아 봤던 게 화근이었다. 개인적으로 스타일과 UI/UX에 집착적이기도 해서, 레이아웃을 구현하는 것도 시간이 꽤 걸렸을 뿐만 아니라, 기본적인 캘린더인데도 여러가지 면을 고려해야 한다는 점을 깨달았다.
특히 날짜는 숫자 계산이 들어가야 해서 코딩하면서 사소한 실수라도 치명적인(?) 버그를 불러왔다. 아무래도 날짜, 달력이라는 것은 절대적인 정보를 보여주는 것이기에 앞으로도 이런 부분은 더욱 신경써야겠다.
처음에는 라이브러리를 만드니까 개발자만을 위한다고 생각했다. 하지만 결국 UI 측면에서는 개발자 못지 않게 최종적으로 이 UI를 경험하는 엔드유저 또한 고려해야 한다는 점을 깨달았다. 물론 기능 관련 코드를 짤 때는 개발자를 배려 해야하는 건 맞지만, 어쨌든 그 개발자들도 결국은 서비스를 사용할 엔드유저를 위해 이 라이브러리를 사용할테니 말이다.
TypeScript, React 관련 에러들을 많이 마주하고, 모르는 개념은 찾아보면서 공부했는데 여전히 공부해야 하는 부분들이 많고, 역량을 많이 쌓아야겠다는 생각을 했다. 물론 개념을 많이 안다고 해서 에러를 방지할 수 있는 건 아니지만, 그래도 개발 속도를 높이고 더 촘촘한 코딩을 할 수 있으려면 개념 공부가 뒷받침 되어야겠다.
Try
앞으로도 꾸준히 버전 업데이트를 하면서 유지보수를 할 것인데, 모바일 환경 대응과 상태 관리 부분을 보완하거나, 더 다양한 optional props (e.g. dateFormat, language, startDay..) 들을 제공하여 사용자들이 취향과 상황에 맞게 캘린더를 사용할 수 있도록 하고자 한다.
이 프로젝트에서 배포가 제 1순위였기에 리팩토링은 컴포넌트를 쪼개거나 유틸 함수를 분리하는 정도로 진행했다. 하지만 아직 해야 할 것들이 남았다. 특히 현재 하나의 함수가 여러 역할을 하고 있는 경우가 종종 있어서, 함수가 하나의 역할만 하도록 리팩토링 하고자 한다.
그래야 재사용할 수 있는 함수와 그렇지 않은 코드를 분리하거나, 필요하지 않은 코드들이나 중복된 코드들을 쉽게 걷어낼 수 있을 것 같다.
더불어, 만들다보니 캘린더 하나인데 색깔이 너무 많아졌다고 느껴진다. 리팩토링을 하면서 불필요한 색깔을 줄이고, #25252 이런 식으로 하드코딩을 하기보다 mainColor 와 같이 변수명으로 나타내면 코딩하는데에 더 수월하고 미연의 실수를 방지할 수 있을 것 같다.