고급 프로젝트: GlobalNomad

📢 프로젝트 소개

• 프로젝트 인원 : 프론트엔드 5명
• 기간 : 25.01.17 - 25.02.26
• 프로젝트 : 사용자가 체험을 등록하고 예약할 수 있는 온라인 체험 예약 서비스
• GitHub: https://github.com/codeitFE11-part4-team2/globalnomad
• 협업 : GitHub, Notion, Discord
• 기술 스택 : React, Next.js(App Route), Tailwind CSS

 

👩🏻‍💻 내 역할

• 페이지네이션 공통 컴포넌트 구현
• 체험 상세 페이지 구현

 

💻 프로젝트 과정

🔗 API 연동 – Swagger 기반 백엔드 API 사용

이번 프로젝트에서는 코드잇 측에서 제공한 Swagger 문서를 기반으로 한 API를 사용했습니다. Swagger 문서는 명세가 잘 정리되어 있었기 때문에, 빠르게 데이터 구조를 파악하고 프론트엔드에서 필요한 요청을 구현할 수 있었습니다.

🧩 컴포넌트 구조와 역할 분담

프로젝트는 다음과 같은 페이지 단위로 구성되어 있었으며, 각각을 컴포넌트 중심으로 분할하여 개발했습니다.

• 메인 페이지
• 로그인/회원가입 페이지
• 체험 상세페이지
• 내 정보
• 후기 작성
• 예약 내역/관리
• 체험 등록/관리/수정
• 예약 현황

컴포넌트는 재사용성과 유지보수성을 고려하여 기능 단위로 나누었으며, 각 기능별 디렉토리 구조를 통해 파일 관리를 체계화했습니다.

---

🎓 문제 및 해결 과정

문제 (1) - 체험 예약 흐름 설계의 복잡성

1. 문제

체험 예약 기능을 구현하면서 다음과 같은 복합적인 요구사항을 만족시켜야 했습니다:

1. 사용자가 날짜, 시간, 인원을 입력해야만 예약 가능하도록 구성
2. PC, 태블릿과 모바일 UI를 동시에 고려하여 UX를 설계
3. 사용자가 이미 예약한 시간대는 예약 불가능해야 하며, 이를 사용자에게 명확히 안내할 수 있어야 함

특히 사용자의 예약 내역을 제외한 시간만을 보여주기 위해 백엔드에서 제공하는 두 API (전체 예약 가능 시간, 나의 예약 내역)를 비교하여 UI에 반영 가능한 시간만 필터링하는 과정이 필요했습니다. 그러나 이 비교 로직은 단순하지 않았습니다. 두 API는 별도로 제공되기 때문에 비동기 요청 간 타이밍 보장, 데이터 동기화, 그리고 형식이 다른 시간 정보 비교 로직을 직접 구현해야 했고, 그 과정에서 UI와 상태의 일치가 꼬이는 문제가 발생했습니다.

 

2. 해결방식

예약 기능을 구현하는 과정에서, getAvailableSchedules()로 전체 예약 가능 시간대를 가져오고, fetchMyReservations()를 통해 사용자의 기존 예약 내역도 함께 불러왔습니다. 이후 format과 filter를 활용하여 두 데이터를 비교하고, 중복되는 시간대를 제거한 뒤 실제로 예약 가능한 시간만 UI에 표시하려고 했습니다. 그러나 비동기 데이터 처리 순서 문제와 비교 로직의 복잡성으로 인해 필터링이 정상적으로 작동하지 않았고, 원하는 대로 UI에서 사전에 예약 불가 시간을 제거하는 데에는 실패했습니다. 이에 따라 사용자가 이미 신청한 시간대를 선택했을 경우, 예약 시도 시점에서 alert()을 통해 불가능하다는 안내 메시지를 출력하는 방식으로 대체했습니다.

 

기본적으로 다음과 같은 흐름으로 예약 가능 시간대를 필터링하려고 시도했습니다:

getAvailableSchedules()를 통해 전체 예약 가능 시간대를 받아오고, fetchMyReservations()를 통해 현재 사용자의 예약 내역을 받아왔습니다. 이후 두 데이터셋을 format()과 filter() 등을 사용해 날짜 및 시간 형식을 맞추고, 중복된 시간대를 제거한 리스트를 UI에 표시하려고 했습니다. 하지만 이 접근은 다음과 같은 문제점이 있었습니다

• 두 비동기 요청의 순서를 보장하지 않음: UI가 먼저 렌더링되거나, 하나의 데이터가 늦게 도착하면서 null, undefined, 혹은 빈 배열 상태로 잘못된 필터링이 일어남
• 형식 불일치와 비교 로직의 복잡성: 시간 정보가 단순 문자열이 아닌 startTime, endTime 쌍으로 제공되어, 두 리스트를 비교하는 로직이 단순히 format()이나 filter()만으로는 안정적으로 작동하지 않음

결과적으로 UI에서 예약 가능한 시간만 미리 제거하는 데 실패했으며, 대신 사용자가 이미 예약한 시간대를 선택할 경우 예약 시도 시점에서 alert()으로 안내하는 방식으로 제한을 걸어야 했습니다.

 

3. 결과

예약 흐름의 주요 부분은 대부분 정상적으로 동작했지만, 사용자 예약 내역과 전체 스케줄을 완전히 비교해 사전에 필터링하는 로직에는 실패했습니다. 대신 예약 단계에서 alert를 통해 예약 불가능 안내를 제공하는 방식으로 구현을 마무리했습니다.

 

→ 개선 방향

다음과 같은 구조로 개선하는 것이 바람직하다고 판단했습니다:

1. React Query의 비동기 흐름 관리 기능을 활용
   useQuery를 사용하여 두 API(getAvailableSchedules, fetchMyReservations)를 각각 독립적으로 호출하되, 두 데이터가 모두 성공적으로 fetch되었을 때에만 렌더링 또는 필터링 로직을 실행하도록 구성합니다.
2. React Query의 캐싱 기능 활용
   동일한 사용자 혹은 동일한 월 기준으로 반복해서 예약 정보를 요청하는 경우, React Query가 내부적으로 데이터를 캐싱하고 재요청을 방지하거나 최소화하여 불필요한 로딩과 중복 요청을 줄일 수 있도록 합니다.
3. 두 데이터의 구조적 차이를 명확히 분석하고 비교 로직을 리팩토링
   단순히 format()과 filter()로 비교하는 것이 아니라, 예약 가능 시간은 { date, times: [{ startTime, endTime }] } 구조, 내 예약 내역은 { date, startTime, endTime } 구조이므로 날짜 + 시간 조합을 기준으로 중첩 루프 혹은 해시맵 등으로 비교하는 방법을 사용해 보는 것도 좋을 것이라고 생각합니다. 중첩 루프는 두 배열을 각각 순회하면서 하나하나 직접 비교하는 방식이고, 해시맵은 비교 대상 데이터를 사전에 Map 형태로 정리해두고, 빠르게 조회하는 방식으로, 초기에는 중첩 루프도 괜찮지만, 조금 복잡하더라도 해시맵을 선택하여 리팩토링해 보는 것도 좋을 것 같습니다.
4. 필터링된 데이터만 AvailableTimes 컴포넌트에 전달

 

문제 (2) - 후기 목록 로딩 성능 및 페이지네이션

1. 문제

후기가 많아질수록 모든 리뷰 데이터를 한 번에 렌더링하면 초기 로딩 시간이 길어지고, 사용자 입장에서 리스트 탐색이 불편해질 수 있었습니다. 또한 후기 평균 평점, 총 리뷰 수 등 메타 정보를 함께 제공해야 했기 때문에, 데이터 처리와 렌더링 흐름의 분리도 필요했습니다.

 

2. 해결방식

후기 목록은 ReviewList 컴포넌트에서 fetchReviews() API를 통해 현재 페이지 기준의 데이터만 가져오도록 분리하였으며, useState와 useEffect를 활용해 currentPage, totalPages, totalCount, averageRating 등의 상태를 개별적으로 관리하면서 후기 목록과 메타 정보를 함께 구성하였습니다. 또한, 사용자가 직접 페이지를 넘길 수 있도록 커스텀 Pagination 컴포넌트를 도입해 UX를 개선했고, 후기 개수가 3개 이하일 경우에는 Pagination이 렌더링되지 않도록 조건부 처리를 적용하여 불필요한 UI 노출을 방지하였습니다.

 

3. 결과

후기 데이터가 많아도 한 페이지에 3개씩만 렌더링되도록 구성하여 렌더링 성능과 사용자 가독성이 향상되었고, 페이지를 넘겨가며 후기를 자연스럽게 탐색할 수 있는 구조가 완성되었습니다. 또한 평균 평점과 총 후기 수를 상단에 노출함으로써 사용자 신뢰를 높이는 효과도 있었습니다.

 

문제 (3) - 이미지 렌더링 다양성 및 확대 기능

1. 문제

체험에 등록된 이미지가 1개 또는 여러 개인 경우 레이아웃이 깨지거나 사용자 경험이 일관되지 않을 수 있었습니다. 모바일에서는 슬라이더 방식, 데스크탑에서는 여러 이미지 배치가 필요했으며, 이미지 클릭 시 확대 기능도 요구됐습니다.

 

2. 해결방식

BannerImage 컴포넌트에서 이미지 개수에 따라 서로 다른 레이아웃으로 조건부 렌더링을 적용했고, 모바일에서는 react-slick 기반 슬라이더를 적용했습니다. 모든 이미지에는 클릭 시 확대되는 모달 기능을 추가하여 사용자 경험을 개선했습니다.

 

3. 결과

모바일과 데스크탑 모두에서 일관된 UI를 제공하면서 다양한 이미지 탐색이 가능해졌고, 사용자가 체험 정보를 더 깊이 이해할 수 있도록 시각적 정보 전달력을 높일 수 있었습니다.

 

→ 개선 방향 : 확대 모달의 접근성 향상(키보드 접근 가능 여부, 닫기 버튼 외 클릭 시 닫기 방지 처리 등)을 추가로 고려할 수 있음.

 

문제 (4) - 서브 이미지 배치 구조의 반복성과 비효율성

1. 문제

체험 상세 페이지에서 서브 이미지의 수(1~4장)에 따라 각기 다른 레이아웃을 적용해야 했습니다.

이미지가 1개일 땐 전체 영역에 단일 이미지, 2개일 땐 세로로 분할, 3개일 땐 상단 1 + 하단 2, 4개일 땐 2x2 형태의 정사각형 격자 레이아웃으로 구성되었습니다.

 

2. 해결방식

SubImageBanner 컴포넌트 내부에서 이미지 수를 기준으로 if-else 조건 분기를 사용하고, 각 케이스마다 div + Image 구성으로 다른 레이아웃을 수동 구현했습니다. 2장, 4장 케이스는 for 문으로 반복 렌더링을 구현했으며, 3장 케이스는 분할 방식이 더 복잡해 직접 배치 구조를 명시했습니다. 이 로직을 구현하는 과정에서 if 조건과 for 문을 각 케이스마다 반복적으로 사용하는 구조가 만들어졌고, 추후 이미지 배치가 변경될 경우 유지보수가 어렵다는 한계가 있었습니다.

 

3. 결과

기획된 모든 이미지 케이스를 정확히 구현했고, 사용자는 이미지 수에 따라 시각적으로 안정적인 콘텐츠 탐색이 가능했습니다. 특히 모바일/PC에서도 반응형으로 잘 작동했고, 클릭 시 확대 모달까지 제공하면서 전반적인 UX 완성도는 높았습니다.

하지만 코드 구조가 조건 분기와 반복 로직의 결합으로 복잡했고, 재사용이나 확장에 불리한 점이 있었습니다.

 

→ 개선 방향

단순히 구현을 넘어서 재사용성과 유지보수성, 코드 구조를 고려한 개선이 필요하다고 판단했습니다.

 

• Grid 또는 Flex 기반으로 레이아웃 구성 단순화
  • 이미지 수에 따라 Grid의 grid-template-areas 또는 grid-auto-flow 속성을 조정해 구현할 수 있을 것이라 생각합니다. 이를 통해 조건 분기 없이도 반복적 구조를 선언적으로 표현 가능합니다. 특히 2x2, 1+2 형태는 Grid에서 쉽게 처리가 가능합니다.
• map 기반 반복 렌더링 적용
  • 현재는 for 문과 하드코딩된 코드가 혼합되어 있는데, 이를 map으로 추상화하면 더 간결하고 확장 가능한 구조 가능합니다.

 

 

문제 (5) - 카카오 지도 구현과 리액트 버전 충돌

1. 문제

체험 상세 페이지에서 위치 정보를 시각적으로 제공하기 위해 카카오 지도 API를 적용하려 했으나, react-kakao-maps-sdk 라이브러리가 React 18 이상과 호환되지 않아 렌더링 오류와 타입 충돌이 발생했습니다.

 

2. 해결방식

라이브러리 사용 대신 스크립트를 동적으로 삽입해 카카오 지도 SDK를 로드하는 방식으로 전환했습니다. useEffect 내부에서 window.kakao.maps.load()를 사용해 지도 객체를 생성하고, 주소를 기반으로 좌표 변환 후 마커를 표시하는 방식으로 직접 구현했습니다.

 

3. 결과

React 버전 이슈를 해결하면서도 안정적인 지도 렌더링이 가능해졌고, 불필요한 라이브러리 의존성을 제거할 수 있었습니다. 사용자에게 체험 위치를 시각적으로 보여주며 정보 전달력을 높이는 데 기여했습니다.

 

---

🎓 배운 점/느낀 점

1. 예약 기능 흐름의 UX 설계와 상태 연결 경험

사용자가 날짜 → 시간 → 인원 수 → 예약까지 단계적으로 진행하는 흐름을 구현하면서, 각 상태 간의 연결성과 UI 반응 속도를 조율하는 것이 얼마나 중요한지를 실감했습니다. 사용자 경험을 고려해 조건부 렌더링 및 모달 컴포넌트 분리 등을 적용하며, UX 중심의 로직 구성 방식에 익숙해졌습니다.

 

2. React Query 실전 적용 경험

예약 가능 시간과 사용자 예약 내역을 병렬적으로 비동기 호출하고, 이를 기반으로 렌더링을 구성하는 과정에서 React Query의 캐싱 및 상태 관리 능력을 실감했습니다. 해당 흐름은 팀원의 도움을 받아 구현했으나, 이후 비동기 데이터 흐름의 설계 방법에 대해 큰 인사이트를 얻을 수 있었습니다.

 

 

3. 동적 지도 및 캘린더 구현을 통한 외부 도구 활용 능력 향상

체험 상세 페이지에서 사용자가 위치를 직관적으로 확인할 수 있도록 카카오 지도를 도입했는데, 기존 react-kakao-maps-sdk 사용 시 React 18과의 호환성 문제로 인해 직접 script 태그를 통해 SDK를 동적으로 로드하고 useEffect 내에서 안전하게 처리하는 방식으로 전환했습니다. 또한 예약 가능한 날짜를 표시하기 위해 react-calendar 라이브러리를 활용했고, 예약 가능 여부에 따라 날짜 선택 UI가 달라지도록 커스터마이징하여 실용적인 캘린더 UI를 구현했습니다. 외부 라이브러리의 장점과 한계를 모두 경험하면서, 상황에 따라 적절한 구현 방식을 선택하는 감각도 함께 익힐 수 있었습니다.

 

---

😢 아쉬운 점

1. React Query에 대한 미숙함

상태 캐싱과 병렬 비동기 호출에 강력한 React Query의 장점을 체감했지만, 사용 경험이 부족해 직접 활용보다는 팀원의 구현을 참고하는 데에 그쳤습니다. 이후에는 스스로 상태 관리 흐름을 설계하고 React Query를 적극 활용해보고자 합니다.

 

2. 이미지 레이아웃 조건 처리의 아쉬움

서브 이미지가 1~4장일 경우 배치 방식이 달라지도록 조건 분기를 적용했지만, 이를 모두 for문과 분기 처리로 구성하면서 코드가 장황해졌습니다. 반복되는 조건 처리보다는 좀 더 선언적이고 유연한 방식으로 리팩터링할 여지가 있었고, 이후 유지보수 측면에서도 다소 복잡한 구조가 된 점이 아쉬웠습니다.

 

3. 예약 시간 필터링의 반영 실패

사용자가 이미 예약한 시간대를 사전에 제거하려고 했지만 실패했고 결국 예약 시도 시점에 alert로 안내하는 방식으로 구현했습니다. 초기 기획 단계에서 API 흐름과 데이터 구조를 더 명확히 파악했더라면 UI 단계에서 완성도 높은 결과를 구현할 수 있었을 것이라는 아쉬움이 남습니다.

 

4. 팀원 이탈로 인한 일정 지연

프로젝트 후반부, 한 팀원과의 연락이 갑자기 어려워져 해당 파트의 진행이 일시적으로 지연되었습니다. 구현 자체가 복잡한 부분은 아니었지만, 팀원의 복귀를 기다리는 동안 일정이 조금 늦춰졌지만, 다행히 잘 마무리 할 수 있었습니다. 사전에 흐름에 대한 공유가 어느 정도 이루어졌기 때문에 큰 문제 없이 마무리할 수 있었지만, 일정 리스크를 줄이기 위한 사전 공유와 백업 체계의 중요성을 체감할 수 있었습니다.