프론트엔드 개발 포트폴리오 | 개발자 사이트 프로젝트 매칭 커뮤니티

내일배움캠프 4기 웹 개발 과정 React 트랙 수료생 최종 프로젝트 ‘Detto’를 소개합니다.
프론트엔드 개발 포트폴리오 | 개발자 사이트 프로젝트 매칭 커뮤니티
Contents
Develop Together, Grow Together, Detto
🏗 아키텍처
🛠️ 기술적 의사결정
⭐️ 주요 기능
🚀 트러블 슈팅 및 최적화
👨‍👩‍👧‍👦 팀원소개

Develop Together, Grow Together Detto

  • 디토는 개발자를 위한 사이드 프로젝트 팀 매칭 플랫폼입니다.
  • 현재 모집 중인 사이드 프로젝트들을 포지션 별 확인할 수 있습니다.
  • 프로젝트 모집 글에 지원하고 초대받는 과정을 통해 더 좋은 시너지를 낼 수 있는 팀원을 만날 수 있습니다.
 
➡️ Detto 서비스 둘러보기 (데스크탑/모바일 환경에서 이용 가능)
 

 

🏗 아키텍처

notion image
 

📍 주요 기능 중 지원하기 로직 플로우

아래 플로우에 대한 상세 설명은 발표회에서 들으실 수 있습니다. 🙂
notion image

 

🛠️ 기술적 의사결정

기술
설명
React
페이지 이동이 잦은 서비스 특성과 개발의 편의성을 따졌을 때, 1. SPA의 장점인 매끄러운 페이지 전환 2. 컴포넌트 재사용을 통해 개발의 효율성을 높이고 유지보수를 용이하게 할 수 있음 위와 같은 이유들로 Vanilla JS가 아닌 React를 채택
TypeScript
명시적인 타입 지정으로 코드의 안전성을 높이고 발생할 수 있는 런타임 에러를 사전 방지하기 위해 채택
Recoil & React Query
프로젝트의 규모와 3주간의 개발 기간을 고려했을 때, 1. 상대적으로 보일러 플레이트가 적음 2. 리액트 문법과 유사하기 때문에 러닝 커브가 낮음 3. React Query의 캐싱을 통해 서버 리소스 절약 가능 위와 같은 이유들로 클라이언트 상태 관리는 Recoil, 서버 상태 관리는 React Query를 채택
Emotion
개발의 효율성을 따져 css-in-js 중 번들 사이즈를 고려하여 가장 크기가 작은 Emotion 채택
React Helmet Async
SPA인 React의 SEO에 취약한 특성을 보완하기 위해 선택
Firebase Firestore
noSQL 비관계형 데이터베이스로, 데이터 변경이 많은 초기 개발 단계 또는 추후 새로운 기능을 추가할 때 데이터 필드를 추가/제거하기 용이하다는 장점이 있음. 그 중 접근성이 좋고 규칙이 간단하며 구글에서 제공하기 때문에 안정성이 높은 Firestore 채택
Yarn Berry
npm, yarn과 비교하여 패키지 용량 감소작업의 편리성이 높다는 점에서 Yarn Berry 채택

 

⭐️ 주요 기능

📌 프로젝트 찾기

  • 포지션 별로 필터링 된 프로젝트를 확인할 수 있습니다.
    • notion image
 

📌 프로젝트 지원 / 초대

  • 유저는 참여하고 싶은 프로젝트에 지원할 수 있습니다.
  • 작성자는 지원자 목록에서 함께 하고 싶은 지원자를 프로젝트에 초대할 수 있습니다.
 
지원하기
지원하기
초대하기
초대하기
 

📌 쪽지 / 알림

  • 유저는 다른 유저에게 쪽지를 보내고 받으며 커뮤니케이션 할 수 있습니다.
  • 프로젝트에 초대되거나, 지원한 프로젝트가 마감한 경우 알림이 갑니다.
쪽지 보내기
쪽지 보내기
쪽지 확인, 알림
쪽지 확인, 알림
 

 

🚀 트러블 슈팅 및 최적화

📉 useQuery 캐싱을 이용하여 서버 요청 횟수 45% 감소

대다수의 페이지에서 컴포넌트가 마운트 될 때마다 서버 요청이 한 번 이상씩 이루어지던 현상 지속.
불필요한 서버 요청으로 인해 성능 이슈 발생 가능성 ⬆️  최적화 결정
 
🚧  해결
  • 사용되고 있는 모든 useQuries, useQuery에 staleTime 적용
  • defaultOptions 로 cacheTime 적용
  • refetchOnWindowFocus: false → 화면의 포커스가 변경될 때 캐싱 된 데이터 사용
staleTime이 적용된 쿼리 중 하나
staleTime이 적용된 쿼리 중 하나
 
❗️ 결과
  • 쪽지/알림 창에서 staleTime 동안 서버 요청을 하지 않게 됨.
  • 프로젝트 게시글 3개 조회 시 서버 요청 횟수 45% 감소
📊
staleTime, cacheTime 적용 전후 비교
 
 
 
 

💌 쪽지 데이터 설계 변경으로 DB 접근 횟수, 서버 요청 횟수 감소

쪽지함의 초기 데이터 설계 후 발생한 문제점 몇 가지 중 일부
  • 동일한 쪽지 두 개씩 저장
  • 사용자 문서 내에 각 쪽지가 field로 저장되기 때문에, firebase의 쿼리 기능을 사용할 수 없음
  • inbox/outbox 컬렉션이 나누어져 있어 서버 요청이 두 번씩 이루어짐
 
🚧 해결
  • notes라는 하나의 컬렉션에 sender, receiver 정보 저장
inbox/outbox 컬렉션에서 하나로 통합된 notes 컬렉션 구조
inbox/outbox 컬렉션에서 하나로 통합된 notes 컬렉션 구조
쪽지 데이터 설계 변경 의사결정 과정
쪽지 데이터 설계 변경 의사결정 과정
 
❗️결과
  • firebase 쿼리 사용 가능
  • DB 접근 횟수와 서버 요청 횟수 절감
 
 
 
 

📸 이미지 사이즈 최적화로 라이트하우스 퍼포먼스 96점으로 향상

구글 라이트하우스 측정 결과 성능 점수가 떨어지는 원인 중 하나 이미지 사이즈
로컬 이미지 및 업로드되는 이미지 사이즈 감소 필요성 체감
notion image
 
🚧  해결
  • 메인 배너 등의 로컬 이미지 파일 확장자를 webp, webm으로 교체
  • react-image-file-resizer 라이브러리를 이용해 프로젝트 썸네일, 프로필 이미지를 webp로 압축하여 업로드하도록 변경
 
❗️ 결과
  • 로컬 이미지 사이즈 기존 파일 대비 총 62% 감소
  • 구글 라이트하우스 퍼포먼스 점수 70점 → 96점으로 크게 향상
notion image
 
notion image
 
 

 

👨‍👩‍👧‍👦 팀원소개

포지션
이름
담당 역할
깃허브 / 메일
frontend
성효진
프로젝트 일정관리, 로그인/회원가입, 쪽지/알림 UI&로직
frontend
이유정
디자이너 소통 담당, 마이페이지 UI&로직, 공개 프로필 로직
frontend
배성완
메인 페이지 배너, 캘린더, 슬라이더 UI&로직
frontend
이상원
팀원찾기, 프로젝트 작성/수정, 공통 모달, 토스트 메세지 UI&로직
frontend
이정은
공개프로필 UI, 프로젝트 상세보기 UI&로직, 프로젝트 자동 마감 로직
designer
위하연
데스크탑,모바일 UI/UX 디자인, 로고/배너 디자인

 
Share article
Subscribe Newsletter
Stay connected for the latest news and insights.
RSSPowered by inblog