사이트 주소: https://moving-web.site/ko
깃허브 주소: ‣, https://github.com/jbinyim/6th-Moving-4Team-BE
1. 프로젝트 개요
Moving은 사용자가 손쉽게 여러 이사업체의 견적을 비교하고, 자신에게 가장 적합한 전문가를 선택할 수 있도록 돕는 스마트 이사 비교 플랫폼입니다.
기존의 복잡하고 불투명했던 이사 견적 과정을 간소화하여, 사용자가 원하는 조건(이사 유형, 지역, 일정 등)에 맞는 전문가를 빠르게 찾을 수 있습니다.
또한 기사님(이사업체) 입장에서도 효율적인 고객 매칭이 가능해, 투명한 거래 환경과 편리한 서비스 경험을 제공합니다.
2. 담당한 작업
| (FE) |
(BE) |
| 대기 중인 견적 페이지 |
대기 중인 견적 조회 API |
| 받았던 견적 페이지 |
받은 견적 조회 API |
| 대기 중인, 받았던 견적 상세 페이지 |
내 견적 상세 조회 API |
| 커뮤니티 페이지 |
견적 확정하기 API |
| 커뮤니티 상세 페이지 |
커뮤니티 생성, 조회, 삭제 API |
| 커뮤니티 생성 페이지 |
커뮤니티 댓글 생성, 조회 삭제 API |
3. 기술적 성과
| Frontend |
Backend |
Deployment |
Etc |
| Next.js |
Node.js |
EC2 |
Sentry |
| TypeScript |
Express.js |
RDS |
Deepl |
| Tailwind |
TypeScript |
S3 |
Jest |
| Tanstack Query |
PostgreSQL |
Route53 |
|
|
PrismaORM |
Github Action |
|
|
|
Vercel |
|
4. 문제점 및 해결 과정
- 중첩 배열 문제
- 문제점 : API에서 받아온 데이터가 "요청 별로 여러 견적서"가 들어있는 2차원 배열 구조라 map으로 렌더링하면 UI가 깨지거나 경고 발생.
- 해결책 : flatMap을 사용해서 2차원 배열을 1차원으로 평탄화.
- 배운점 : map만 쓰면 중첩 배열이 생기므로 부모-자식 구조의 데이터를 한번에 펼쳐서 렌더링할 때 flatmap이 적합함을 배웠다.
- 복합 조건 기반 견적 데이터 처리
- 문제점: 견적 시스템의 전체 프로세스를 사용자에게 직관적으로 보여주는 것이 가장 중요한 과제였습니다. 견적 요청부터 기사 수락, 최종 선택까지의 모든 단계를 하나의 페이지에서 조회할 수 있도록 구현해야 했습니다.
- 해결책:
- 이사 카테고리(소형/가정/사무실), 날짜, 장소 정보로 견적 요청
- 여러 기사들의 견적 수락 상태 관리
- 매칭 완료/미완료 상태에 따른 데이터 분류
- 카테고리별, 확정 견적 여부에 따른 조건부 렌더링
순서대로 분리하여 코드 작성
- 배운점: 이 과정에서 백엔드와의 긴밀한 협업을 통해 복잡한 조건의 API 호출을 최적화하고, 사용자 경험을 해치지 않으면서도 정확한 데이터를 제공할 수 있도록 구현했습니다.
5. 협업 및 피드백
- 효과적인 협업 경험
- 체계적인 PR 규칙 수립: 팀 전체가 일관된 코드 품질을 유지할 수 있도록 명확한 규칙 설정
- Top-down 방식의 개발: 전체 아키텍처를 먼저 설계한 후 세부 구현으로 진행하여 개발 속도 향상
- 매일 오전 데일리 스크럼: 정기적인 소통을 통한 진행 상황 공유 및 이슈 해결
- 개선이 필요했던 부분
- 의사소통 부족으로 인한 비효율성을 경험했습니다. 겹치는 컴포넌트를 각자 개발한 후 나중에 통합하거나, 추가 기능을 개별적으로 결정하여 시간이 촉박해지는 상황이 발생했습니다
6. 코드 품질 및 최적화
- 프론트엔드 측면에서는 SEO와 웹 접근성을 개선하는 데 중점을 두었다. 메타 태그와 구조화된 데이터를 적절히 활용하여 검색 엔진 친화적인 페이지를 구현했고, 시맨틱 태그 사용과 속성 적용을 통해 다양한 사용자 환경에서도 접근성이 보장되도록 했다. 이러한 개선은 단순히 검색 노출 향상뿐 아니라 더 많은 사용자가 서비스에 원활히 접근할 수 있도록 돕는 기반이 되었다.