Attraction
| 이름 | Attraction [어트랙션] |
|---|---|
| 설명 | Gmail 기반 뉴스레터 통합 관리 서비스 |
| 유형 | 팀 프로젝트 |
| 인원 구성 | 프론트엔드 3명, 백엔드 3명 |
| 역할 | 프론트엔드 개발, 디자인 시스템 구축, UI/UX 디자인 총괄 |
| 기간 | 2024.04 ~ 2025.01 |
| 상태 | 서비스 종료됨 |
| 도메인 | https://attraction.run deprecated |
| GitHub | https://github.com/Atractorrr/Attraction-FE |
| MAU | 50명 대 (Beta) |
| 사용 기술 |
|
| 기여 |
|
| 관련 포스트 | |
| 비고 | 구름톤 트레이닝 6회차 파이널 프로젝트 인기상 수상 |
목차
프로젝트 소개
어트랙션은 기존 뉴스레터 시스템을 사용하면서 느꼈던 정보의 파편화, 불편한 UI 및 UX, 개인 맞춤형 시스템의 부재 등 다양한 문제를 해결하고자 구축하게 된 뉴스레터 통합 관리 서비스입니다. 어트랙션은 아래의 소개 이미지와 같은 핵심 기능들로 상기의 다양한 문제들을 해결하려 하였습니다.
| 어트랙션 소개 이미지 | ||
|---|---|---|
시연 영상
역할
사용 기술
기술적 고민
Next.js
TypeScript
Tanstack Query
MSW
모노레포 (pnpm workspace)
TailWindCSS & Shadcn/UI
Husky & commitlint
아쉬웠던 점
전반적인 기술 이해도 부족
디자인 시스템 재구성
클라이언트 상태 관리 라이브러리의 부재
저희는 프로젝트 초기 기획을 보고 클라이언트 상태가 크게 없고 대부분이 서버 상태 관리 로직으로만 구성되어 있다고 판단하여 Redux나 Zustand 같은 클라이언트 상태 관리 라이브러리 없이 Tanstack-Query만 사용하여 서버 상태 관리 위주로 로직을 작성한 후, 만약 클라이언트 상태를 관리할 상황이 생기면 React의 Context-API를 사용하는 것으로 합의하였습니다. 하지만 Context-API로 모두 커버가 될 것이라는 저희 예상과는 다르게 생각보다 로직을 작성하며 크고 작은 부분에서 클라이언트 상태를 관리할 일이 많았고, 그때마다 Context-API를 사용하거나 useState 훅 위주로 로직을 작성했더니 몇 가지 문제점이 있었습니다.
그중 가장 큰 문제는 렌더링 최적화와 그에 따른 보일러 플레이트 코드의 증가였습니다. Context-API는 Redux나 Zustand 같은 클라이언트 상태 관리 라이브러리와는 다르게 렌더링 최적화를 지원하지 않았습니다. Context-API는 컨텍스트로 관리하는 상태가 변경된다면 해당 상태와는 관련 없는 하위 컴포넌트들도 모두 리렌더링 시켰고, 이를 해결하기 위해 실제 상태로 구성된 컨텍스트와 이를 수정하는 Dispatcher 컨텍스트를 분리시켜 주어야 했습니다. 이때 발생하는 보일러 플레이트 코드는 둘째치더라도 해당 조치만으로는 다른 클라이언트 상태 관리 라이브러리들과 달리 완벽하게 렌더링 최적화를 지원할 수 없었고, 결과적으로 생산성 저하와 유지 보수성 저하로 이어지게 되었습니다.
인사이트
해당 프로젝트는 제가 처음 프론트엔드 개발자로써 참여한 팀 프로젝트였고, 기획, 디자인, 개발 등 분야를 가리지 않고 정말 열정적으로 기여했던 프로젝트였지만 들였던 노력과는 반대로 결과가 좋지 못했습니다.