📌 1️⃣ Service Layer

Firestore와 API 호출 로직이 컴포넌트에 섞이면
재사용성과 유지보수성이 떨어진다고 판단했습니다.

그래서 데이터 접근 로직을 Service Layer로 분리하여
UI와 데이터 로직을 명확하게 분리했습니다.

📌 2️⃣ Custom Hook

데이터 fetching이나 상태 관리 로직이 여러 컴포넌트에 반복되는 문제가 있었습니다.

이를 해결하기 위해 Custom Hook으로 분리하여
로직 재사용성과 컴포넌트 단순화를 목표로 했습니다.

📌 3️⃣ Zustand 선택 이유

상태 관리 라이브러리를 선택할 때
Redux는 보일러플레이트가 많아 프로젝트 규모에 비해 과하다고 판단했습니다.

Zustand는 구조가 간단하면서도 전역 상태 관리가 가능해
현재 프로젝트 규모에 적합하다고 판단하여 선택했습니다.

📌 4️⃣ Firestore onSnapshot

초기에는 fetch 기반으로 데이터를 가져왔지만
데이터 변경 시 UI가 즉시 반영되지 않는 문제가 있었습니다.

이를 해결하기 위해 onSnapshot을 사용하여
실시간 데이터 반영 구조로 변경했습니다.

📌 5️⃣ 전체 구조 설계

유지보수성과 확장성을 가장 중요한 기준으로 두고 설계했습니다.

UI, 비즈니스 로직, 데이터 접근을 분리하여
각 레이어의 책임을 명확하게 나누는 구조로 구성했습니다.