이번엔 누가 할래? 쓸모 있는 랜덤피커 만들기
⛳️ 목표
1.
쉽고 쓸모있는 토이 프로젝트를 통해 성취감과 자신감을 얻도록 한다.
2.
CRUD와 배포 과정에 익숙해질 수 있도록 한다.
3.
emotion을 적용하며 각 스타일 라이브러리들의 장단점을 알 수 있다.
4.
반응형 디자인과 다크모드를 구현해 데스크탑 및 모바일 환경에서 원활히 사용할 수 있도록 한다.
결과물
기술 스택
•
개발 언어: TypeScript React
•
스타일: Emotion
•
빌드: Vite
•
배포: Vercel
요구사항
메인 화면
참여자 설정 화면
참여자 확인 화면
로딩 화면
당첨자 확인 화면
TIL
기술 스택
Vite vs. Webpack 빌드 도구 선택
빌드 도구? 모듈 번들러?
emotion vs. styled components 스타일 라이브러리 선택
@emotion/styled vs. @emotion/css 비교
[미적용] Storybook을 활용한 디자인 시스템 구축
빌드와 배포
빌드 및 배포 과정
로컬에서 배포 환경 preview
[미진행] SEO 작업
환경 세팅
TypeScript, React, Emotion, Vite
node 최신 버전 (nvm)
Node.js, nvm, npm
스타일
웹 폰트 전역 설정
CSS 스타일 속성 직접 설정 vs. 변수 선언 및 변수 할당
React
React.FC
React 이벤트 타입
Mount / Unmount
기능 구현
트러블슈팅
리팩토링
회고
Keep
일단 이 프로젝트에 앞서 세웠던 목표들은 거의 이룬 것 같아서 만족한다. 앞으로도 매 프로젝트를 할 때마다 몇 가지 목표를 세우고, 그 목표를 이룰 수 있도록 달려보는 게 효과적일 듯 하다.
A to Z 온전히 혼자 해 본 프로젝트였기에 만족감이 크다. 지난 팀 프로젝트 때 환경 세팅과 전역 설정, 배포에 적극적으로 참여하지 못했기 때문에 이번에는 꼭 내 손으로 해보고 싶었다. 다행히 이번 프로젝트 덕분에 0부터 1까지 모두 (찍먹이라도) 해봤다는 자신감을 얻을 수 있었다.
쉽고 쓸모 있는 토이프로젝트를 만들면서 ‘메이커’로서의 성취감과 자신감을 얻었다. 사실 지난달에 슬럼프가 크게 왔어서 개발을 놔야 하나 고민까지 할 정도였는데, 이를 극복하고자 시도했던 게 이 랜덤 피커 프로젝트였다. 슬럼프에서 조금씩 나올 때쯤 ‘그래, 난 메이커가 되고 싶었지’ 뭔가를 만들어야겠다는 생각이 들었다. 다행히 굉장히 몰입하고 즐겁게 만들었다. 우아한테크코스 코딩테스트 불합격 이후로 내가 생각한 것보다 자신감이 떨어져 있었는데, 개발하는 이유를 다시 한번 되새겨 준, 나를 일으켜준 고마운 프로젝트다.
프로젝트 관리는 Github Projects를 통해 관리했는데, 지난 팀 프로젝트에서 써보았을 때도 좋았지만 혼자 프로젝트할 때도 현재 하고 있는 것, 해야 하는 것들이 명확히 보여 처지지 않고 일하기 좋았다.
GPT에 너무 의존하나 싶은 생각이 들어 이번 프로젝트에서는 스스로 고민하고, 적용하고, 삽질하는 시간을 더 끌어 보았다. 결과적으로는 이렇게 고민하는 과정에서 ‘사고(thinking)’라는 행위를 더 많이 해본 것 같다. 어쨌든 개발자로서 중요한 역량 중 하나가 어떤 환경에서든 사고할 줄 알고, 해결하는 능력이라 생각한다. GPT 등의 툴을 활용하면 좋지만, 또 너무 의존하면 생각하지 못하는 개발자가 될 것 같은 두려움이 든다. 의존이 아닌 활용. 기억하자.
우아한 테크코스 프리코스 미션을 할 때 들였던 습관인데, 프로젝트를 하면서 들었던 생각과 고민, 참고 자료, GPT의 답변, 에러 메시지와 해결 과정까지 모조리 노션에 적어두는 것이다. 그때그때 정리되지 않은 형태로라도 미루지 않고 정리를 해놓으면 프로젝트 이후 더 좋은 복기를 하고, 다시 한번 내 것으로 만들 수 있기 때문이다. 일단 빠르게 만들어 놓고 정리는 나중에 하는 것. 이것도 기억하자.
처음에는 요구사항 정리와 Figma에 레이아웃을 그려보는 것을 굳이 해야 하나 싶었는데, 우선 간단한 프로젝트이니 두 가지 다 해보았다. 결론적으로는 앞으로도 프로젝트에 앞서 이 두 가지를 모두 할 것 같다. 개인마다 스타일이 다르겠지만 나는 요구사항이 보다 명확한 것을 선호한다. 그렇지 않으면 개발하면서 로직이나 스타일을 중간에 바꾸는 게 매우 번거롭기 때문이다. 머릿속에 그려놓고 그걸 코드로 짜는 건 어느 정도 경험과 역량이 쌓였을 때 가능할 것 같고, 지금은 하나하나 만들어가면서 하는 게 좋은 것 같다.
Problem
계속 느끼는 거지만 앞으로 CSS를 더 자유자재로 쓸 줄 알아야겠다. 이번에는 컴포넌트들을 다 직접 만들었는데 그러면서 CSS 속성들을 복습할 수 있었다. flex 등 각 CSS 속성들의 특징이나 효과를 (외울 필요는 없지만 적어도) 잘 알고, 그때그때 잘 활용하는 게 프론트엔드 개발자로서는 매우 중요하겠다. 앞으로 과제 테스트 전형도 많이 볼 텐데 그때 레이아웃 만드는데에서 시간을 다 써버리면 매우 슬플 것 같다.
문제 해결에 필요 이상의 시간을 써버리는 바람에, 문제 해결을 할 때 생각하는 로직을 정리한 적이 있다. (이 이야기는 추후 트러블슈팅 관련해 별도의 글로 발행할 예정인데) 배포 환경에서 svg 파일이 렌더링 되지 않아 이 이슈를 해결하느라 하루 중 상당한 시간을 썼었다. 결론적으로 그 이슈는 엄청 중요하지도 않았고, 다른 방법이 있었기에 그만큼의 시간을 쓰지 않아도 되었기에 시간을 낭비했다고 생각한다. 물론 삽질 경험도 중요하고 값지긴 하나, 앞으로는 지금 해결하는 문제가 그만큼 deserve 한지는 의식적으로 고민해 보아야 한다고 느꼈다.
책 추천 큐레이션 서비스를 만들었던 팀 프로젝트에서 React Quill Editor 관련 에러를 해결할 때가 생각났다. 그때 당시 거의 이틀에 걸쳐 디버깅을 하고, 해결하는 데에 엄청나게 서칭하고 시도도 많이 했다. 그 에러는 무조건, 어떻게 해서든 해결했어야 했다. 왜? CRUD가 서비스의 핵심 로직이었기 때문이다. (그래서 결국 해결함!)
하지만 이번 svg 이슈는 달랐다. 그저 다크모드의 토글에 넣을 이모지일뿐이었다. 사실 꼭 svg일 필요가 없었을뿐더러, 꼭 그 이모지일 필요도 없었는데 소중한 내 시간을 낭비해 버렸다. 결론적으로 svg는 포기하고, 이모지를 font 형태로 불러와 내가 원하는, 같은 결과를 같은 만들어 낼 수 있었다. 지금 생각해 보면 더 일찍 다른 방법을 택했어도 되었을 텐데 왜 그렇게 매달렸을까? 떠올려보면 그때 당시 꼭 해결해 보겠다는 승부욕, 그리고 해결이 되지 않는 이유가 너무 궁금해 꼭 해결해야겠는 호기심 등이 있었던 것 같다.
물론 의미 없는 삽질은 아니었고, 앞으로 할 삽질들도 모두 의미가 없다고 하기에는 어렵다. 삽질을 하면서 (좋게 말하자면) 엄청 몰입했고, vite 환경에서 svg 사용을 하기 위해서는 별도의 라이브러리를 사용하고 vite.config.ts와 tsconfig.json에 추가 설정을 해주어야 하는 등의 지식도 쌓을 수 있었다. 헤매던 문제를 해결하지 못해 여전히 찝찝함은 남아있지만.. 결국에는 다른, 그것도 아주 간편한 방법을 생각해 내서 원하는 결과를 만들었음에 만족한다. (다만, 블로그 글을 통해 잘 아는 누군가가 있다면 도움을 받아 언젠가는 해결을 꼭 해보려 한다)
Try
그렇게 정리한 문제 해결의 생각 로직은 아래와 같다. 앞으로 문제가 오랜 시간 동안 풀리지 않으면 아래의 로직을 떠올려 보면 좋겠다.
1. 이 시간을 쓸 만큼 중요한가
•
내 시간을 그만큼 쓸만한 중요한 로직인가?
•
아니라면 과감히 버리는 것도 용기고 전략이다.
2. 대체 가능한가
•
다른 방법으로 같은 결과를 낼 수 있는가?
•
할 수 있다면 다른 방법을 적극적으로 시도해 보자.
이번 프로젝트에서는 별도의 브랜치를 파지 않고 모두 main에 푸시했다. 처음에 develop 브랜치를 파서 → pull request를 날리고 → 스스로 merge를 했는데, 혼자 하는 프로젝트인데 무슨 의미가 있나 싶어 main에 다 푸시했다. 이후 프로젝트가 끝나고 보니, 내가 뭘 했는지는 칸반이나 커밋 기록에 다 남아있지만, PR의 형태로도 기록을 남겼다면 더 좋았겠다는 생각도 들었다. 더 나아가, 앞으로 실무에서 많이 쓸 Git이나 PR 본문 작성도 연습해 볼 겸, 포트폴리오에 남길 프로젝트라면 PR 기록도 누군가 볼 수도 있기도 하니 다음 프로젝트에서는 혼자 하는 프로젝트라도 별도의 브랜치를 따서 PR을 남겨 보려 한다.
생각보다 상태 관리, React hook을 잘 모르고 있었어서 이번에 다크모드 상태관리를 해보면서 다시 익혔다. 이번 프로젝트는 Context API를 사용했지만, 다음 프로젝트에서는 Redux나 Recoil로 더 복잡한 상태관리를 해보아야겠다. 더불어, 이번 프로젝트에서는 찍먹만 했던 웹 표준/웹 접근성과 반응형도 다음 프로젝트 때 더 적용해보고자 한다.
다음 프로젝트에서는 0부터 ‘진짜 1’을 경험해보고자 한다. 여기서 진짜 1은, 배포 후 운영 및 유지보수를 말한다. 이번 프로젝트는 쉬운 1이었다. 그냥 vercel로 간편하게 배포만 하면 되었고, 유효성 검사나 버그 수정도 적당한 선에서 마무리했다. (물론 더 해서 더 많이 배워도 좋지만 다음 퀘스트를 깨야하기에..)
아마 다음 프로젝트는 npm 라이브러리나 extension을 만들 것 같다. 누군가가 (감사하게도) 이슈를 올려준다면 직접 해결하고, 혹은 새로운 기능을 제안받아 더 발전시켜 보는 경험을 하고자 한다.
프론트엔드 개발자로서 코딩 실력은 물론, 사용자와의 인터렉션을 통해 나도, 서비스도 더 발전시키는 것이 중요한 것 같다. 내 선에서 예상하지 못했던 사용자의 의견을 어떻게 수용하며 고민하고, 해결할지 직접 부딪혀보는 개발자가 되고 싶다.