diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 15a3a274..eba1440c 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -2,13 +2,7 @@
### 배포 링크
-
+https://youngh02.github.io/front_7th_chapter2-1/
### 기본과제
@@ -16,140 +10,140 @@
**상품 목록 로딩**
-- [ ] 페이지 접속 시 로딩 상태가 표시된다
-- [ ] 데이터 로드 완료 후 상품 목록이 렌더링된다
-- [ ] 로딩 실패 시 에러 상태가 표시된다
+- [x] 페이지 접속 시 로딩 상태가 표시된다
+- [x] 데이터 로드 완료 후 상품 목록이 렌더링된다
+- [x] 로딩 실패 시 에러 상태가 표시된다
- [ ] 에러 발생 시 재시도 버튼이 제공된다
**상품 목록 조회**
-- [ ] 각 상품의 기본 정보(이미지, 상품명, 가격)가 카드 형태로 표시된다
+- [x] 각 상품의 기본 정보(이미지, 상품명, 가격)가 카드 형태로 표시된다
**한 페이지에 보여질 상품 수 선택**
-- [ ] 드롭다운에서 10, 20, 50, 100개 중 선택할 수 있으며 기본 값은 20개 이다.
-- [ ] 선택 변경 시 즉시 목록에 반영된다
+- [x] 드롭다운에서 10, 20, 50, 100개 중 선택할 수 있으며 기본 값은 20개 이다.
+- [x] 선택 변경 시 즉시 목록에 반영된다
**상품 정렬 기능**
-- [ ] 상품을 가격순/이름순으로 오름차순/내림차순 정렬을 할 수 있다.
-- [ ] 드롭다운을 통해 정렬 기준을 선택할 수 있다
-- [ ] 정렬 변경 시 즉시 목록에 반영된다
+- [x] 상품을 가격순/이름순으로 오름차순/내림차순 정렬을 할 수 있다.
+- [x] 드롭다운을 통해 정렬 기준을 선택할 수 있다
+- [x] 정렬 변경 시 즉시 목록에 반영된다
**무한 스크롤 페이지네이션**
-- [ ] 페이지 하단 근처 도달 시 다음 페이지 데이터가 자동 로드된다
-- [ ] 스크롤에 따라 계속해서 새로운 상품들이 목록에 추가된다
-- [ ] 새 데이터 로드 중일 때 로딩 인디케이터와 스켈레톤 UI가 표시된다
-- [ ] 홈 페이지에서만 무한 스크롤이 활성화된다
+- [x] 페이지 하단 근처 도달 시 다음 페이지 데이터가 자동 로드된다
+- [x] 스크롤에 따라 계속해서 새로운 상품들이 목록에 추가된다
+- [x] 새 데이터 로드 중일 때 로딩 인디케이터와 스켈레톤 UI가 표시된다
+- [x] 홈 페이지에서만 무한 스크롤이 활성화된다
**상품을 장바구니에 담기**
-- [ ] 각 상품에 장바구니 추가 버튼이 있다
-- [ ] 버튼 클릭 시 해당 상품이 장바구니에 추가된다
-- [ ] 추가 완료 시 사용자에게 알림이 표시된다
+- [x] 각 상품에 장바구니 추가 버튼이 있다
+- [x] 버튼 클릭 시 해당 상품이 장바구니에 추가된다
+- [x] 추가 완료 시 사용자에게 알림이 표시된다
**상품 검색**
-- [ ] 상품명 기반 검색을 위한 텍스트 입력 필드가 있다
-- [ ] Enter 키로 검색이 수행된다
-- [ ] 검색어와 일치하는 상품들만 목록에 표시된다
+- [x] 상품명 기반 검색을 위한 텍스트 입력 필드가 있다
+- [x] Enter 키로 검색이 수행된다
+- [x] 검색어와 일치하는 상품들만 목록에 표시된다
**카테고리 선택**
-- [ ] 사용 가능한 카테고리들을 선택할 수 있는 UI가 제공된다
-- [ ] 선택된 카테고리에 해당하는 상품들만 표시된다
-- [ ] 전체 상품 보기로 돌아갈 수 있다
-- [ ] 2단계 카테고리 구조를 지원한다 (1depth, 2depth)
+- [x] 사용 가능한 카테고리들을 선택할 수 있는 UI가 제공된다
+- [x] 선택된 카테고리에 해당하는 상품들만 표시된다
+- [x] 전체 상품 보기로 돌아갈 수 있다
+- [x] 2단계 카테고리 구조를 지원한다 (1depth, 2depth)
**카테고리 네비게이션**
-- [ ] 현재 선택된 카테고리 경로가 브레드크럼으로 표시된다
-- [ ] 브레드크럼의 각 단계를 클릭하여 상위 카테고리로 이동할 수 있다
-- [ ] "전체" > "1depth 카테고리" > "2depth 카테고리" 형태로 표시된다
+- [x] 현재 선택된 카테고리 경로가 브레드크럼으로 표시된다
+- [x] 브레드크럼의 각 단계를 클릭하여 상위 카테고리로 이동할 수 있다
+- [x] "전체" > "1depth 카테고리" > "2depth 카테고리" 형태로 표시된다
**현재 상품 수 표시**
-- [ ] 현재 조건에서 조회된 총 상품 수가 화면에 표시된다
-- [ ] 검색이나 필터 적용 시 상품 수가 실시간으로 업데이트된다
+- [x] 현재 조건에서 조회된 총 상품 수가 화면에 표시된다
+- [x] 검색이나 필터 적용 시 상품 수가 실시간으로 업데이트된다
#### 장바구니
**장바구니 모달**
-- [ ] 장바구니 아이콘 클릭 시 모달 형태로 장바구니가 열린다
-- [ ] X 버튼이나 배경 클릭으로 모달을 닫을 수 있다
-- [ ] ESC 키로 모달을 닫을 수 있다
-- [ ] 모달에서 장바구니의 모든 기능을 사용할 수 있다
+- [x] 장바구니 아이콘 클릭 시 모달 형태로 장바구니가 열린다
+- [x] X 버튼이나 배경 클릭으로 모달을 닫을 수 있다
+- [x] ESC 키로 모달을 닫을 수 있다
+- [x] 모달에서 장바구니의 모든 기능을 사용할 수 있다
**장바구니 수량 조절**
-- [ ] 각 장바구니 상품의 수량을 증가할 수 있다
-- [ ] 각 장바구니 상품의 수량을 감소할 수 있다
-- [ ] 수량 변경 시 총 금액이 실시간으로 업데이트된다
+- [x] 각 장바구니 상품의 수량을 증가할 수 있다
+- [x] 각 장바구니 상품의 수량을 감소할 수 있다
+- [x] 수량 변경 시 총 금액이 실시간으로 업데이트된다
**장바구니 삭제**
-- [ ] 각 상품에 삭제 버튼이 배치되어 있다
-- [ ] 삭제 버튼 클릭 시 해당 상품이 장바구니에서 제거된다
+- [x] 각 상품에 삭제 버튼이 배치되어 있다
+- [x] 삭제 버튼 클릭 시 해당 상품이 장바구니에서 제거된다
**장바구니 선택 삭제**
-- [ ] 각 상품에 선택을 위한 체크박스가 제공된다
-- [ ] 선택 삭제 버튼이 있다
-- [ ] 체크된 상품들만 일괄 삭제된다
+- [x] 각 상품에 선택을 위한 체크박스가 제공된다
+- [x] 선택 삭제 버튼이 있다
+- [x] 체크된 상품들만 일괄 삭제된다
**장바구니 전체 선택**
-- [ ] 모든 상품을 한 번에 선택할 수 있는 마스터 체크박스가 있다
-- [ ] 전체 선택 시 모든 상품의 체크박스가 선택된다
-- [ ] 전체 해제 시 모든 상품의 체크박스가 해제된다
+- [x] 모든 상품을 한 번에 선택할 수 있는 마스터 체크박스가 있다
+- [x] 전체 선택 시 모든 상품의 체크박스가 선택된다
+- [x] 전체 해제 시 모든 상품의 체크박스가 해제된다
**장바구니 비우기**
-- [ ] 장바구니에 있는 모든 상품을 한 번에 삭제할 수 있다
+- [x] 장바구니에 있는 모든 상품을 한 번에 삭제할 수 있다
#### 상품 상세
**상품 클릭시 상세 페이지 이동**
-- [ ] 상품 목록에서 상품 이미지나 상품 정보 클릭 시 상세 페이지로 이동한다
-- [ ] URL이 `/product/{productId}` 형태로 변경된다
-- [ ] 상품의 자세한 정보가 전용 페이지에서 표시된다
+- [x] 상품 목록에서 상품 이미지나 상품 정보 클릭 시 상세 페이지로 이동한다
+- [x] URL이 `/product/{productId}` 형태로 변경된다
+- [x] 상품의 자세한 정보가 전용 페이지에서 표시된다
**상품 상세 페이지 기능**
-- [ ] 상품 이미지, 설명, 가격 등의 상세 정보가 표시된다
+- [x] 상품 이미지, 설명, 가격 등의 상세 정보가 표시된다
- [ ] 전체 화면을 활용한 상세 정보 레이아웃이 제공된다
**상품 상세 - 장바구니 담기**
-- [ ] 상품 상세 페이지에서 해당 상품을 장바구니에 추가할 수 있다
-- [ ] 페이지 내에서 수량을 선택하여 장바구니에 추가할 수 있다
-- [ ] 수량 증가/감소 버튼이 제공된다
+- [x] 상품 상세 페이지에서 해당 상품을 장바구니에 추가할 수 있다
+- [x] 페이지 내에서 수량을 선택하여 장바구니에 추가할 수 있다
+- [x] 수량 증가/감소 버튼이 제공된다
**관련 상품 기능**
-- [ ] 상품 상세 페이지에서 관련 상품들이 표시된다
-- [ ] 같은 카테고리(category2)의 다른 상품들이 관련 상품으로 표시된다
-- [ ] 관련 상품 클릭 시 해당 상품의 상세 페이지로 이동한다
-- [ ] 현재 보고 있는 상품은 관련 상품에서 제외된다
+- [x] 상품 상세 페이지에서 관련 상품들이 표시된다
+- [x] 같은 카테고리(category2)의 다른 상품들이 관련 상품으로 표시된다
+- [x] 관련 상품 클릭 시 해당 상품의 상세 페이지로 이동한다
+- [x] 현재 보고 있는 상품은 관련 상품에서 제외된다
**상품 상세 페이지 내 네비게이션**
-- [ ] 상품 상세에서 상품 목록으로 돌아가는 버튼이 제공된다
-- [ ] 브레드크럼을 통해 카테고리별 상품 목록으로 이동할 수 있다
-- [ ] SPA 방식으로 페이지 간 이동이 부드럽게 처리된다
+- [x] 상품 상세에서 상품 목록으로 돌아가는 버튼이 제공된다
+- [x] 브레드크럼을 통해 카테고리별 상품 목록으로 이동할 수 있다
+- [x] SPA 방식으로 페이지 간 이동이 부드럽게 처리된다
#### 사용자 피드백 시스템
**토스트 메시지**
-- [ ] 장바구니 추가 시 성공 메시지가 토스트로 표시된다
-- [ ] 장바구니 삭제, 선택 삭제, 전체 삭제 시 알림 메시지가 표시된다
-- [ ] 토스트는 3초 후 자동으로 사라진다
-- [ ] 토스트에 닫기 버튼이 제공된다
-- [ ] 토스트 타입별로 다른 스타일이 적용된다 (success, info, error)
+- [x] 장바구니 추가 시 성공 메시지가 토스트로 표시된다
+- [x] 장바구니 삭제, 선택 삭제, 전체 삭제 시 알림 메시지가 표시된다
+- [x] 토스트는 3초 후 자동으로 사라진다
+- [x] 토스트에 닫기 버튼이 제공된다
+- [x] 토스트 타입별로 다른 스타일이 적용된다 (success, info, error)
### 심화과제
@@ -157,44 +151,44 @@
**페이지 이동**
-- [ ] 어플리케이션 내의 모든 페이지 이동(뒤로가기/앞으로가기를 포함)은 하여 새로고침이 발생하지 않아야 한다.
+- [x] 어플리케이션 내의 모든 페이지 이동(뒤로가기/앞으로가기를 포함)은 하여 새로고침이 발생하지 않아야 한다.
**상품 목록 - URL 쿼리 반영**
-- [ ] 검색어가 URL 쿼리 파라미터에 저장된다
-- [ ] 카테고리 선택이 URL 쿼리 파라미터에 저장된다
-- [ ] 상품 옵션이 URL 쿼리 파라미터에 저장된다
-- [ ] 정렬 조건이 URL 쿼리 파라미터에 저장된다
-- [ ] 조건 변경 시 URL이 자동으로 업데이트된다
-- [ ] URL을 통해 현재 검색/필터 상태를 공유할 수 있다
+- [x] 검색어가 URL 쿼리 파라미터에 저장된다
+- [x] 카테고리 선택이 URL 쿼리 파라미터에 저장된다
+- [x] 상품 옵션이 URL 쿼리 파라미터에 저장된다
+- [x] 정렬 조건이 URL 쿼리 파라미터에 저장된다
+- [x] 조건 변경 시 URL이 자동으로 업데이트된다
+- [x] URL을 통해 현재 검색/필터 상태를 공유할 수 있다
**상품 목록 - 새로고침 시 상태 유지**
-- [ ] 새로고침 후 URL 쿼리에서 검색어가 복원된다
-- [ ] 새로고침 후 URL 쿼리에서 카테고리가 복원된다
-- [ ] 새로고침 후 URL 쿼리에서 옵션 설정이 복원된다
-- [ ] 새로고침 후 URL 쿼리에서 정렬 조건이 복원된다
-- [ ] 복원된 조건에 맞는 상품 데이터가 다시 로드된다
+- [x] 새로고침 후 URL 쿼리에서 검색어가 복원된다
+- [x] 새로고침 후 URL 쿼리에서 카테고리가 복원된다
+- [x] 새로고침 후 URL 쿼리에서 옵션 설정이 복원된다
+- [x] 새로고침 후 URL 쿼리에서 정렬 조건이 복원된다
+- [x] 복원된 조건에 맞는 상품 데이터가 다시 로드된다
**장바구니 - 새로고침 시 데이터 유지**
-- [ ] 장바구니 내용이 브라우저에 저장된다
-- [ ] 새로고침 후에도 이전 장바구니 내용이 유지된다
-- [ ] 장바구니의 선택 상태도 함께 유지된다
+- [x] 장바구니 내용이 브라우저에 저장된다
+- [x] 새로고침 후에도 이전 장바구니 내용이 유지된다
+- [x] 장바구니의 선택 상태도 함께 유지된다
**상품 상세 - URL에 ID 반영**
-- [ ] 상품 상세 페이지 이동 시 상품 ID가 URL 경로에 포함된다 (`/product/{productId}`)
-- [ ] URL로 직접 접근 시 해당 상품의 상세 페이지가 자동으로 로드된다
+- [x] 상품 상세 페이지 이동 시 상품 ID가 URL 경로에 포함된다 (`/product/{productId}`)
+- [x] URL로 직접 접근 시 해당 상품의 상세 페이지가 자동으로 로드된다
**상품 상세 - 새로고침시 유지**
-- [ ] 새로고침 후에도 URL의 상품 ID를 읽어서 해당 상품 상세 페이지가 유지된다
+- [x] 새로고침 후에도 URL의 상품 ID를 읽어서 해당 상품 상세 페이지가 유지된다
**404 페이지**
-- [ ] 존재하지 않는 경로 접근 시 404 에러 페이지가 표시된다
-- [ ] 홈으로 돌아가기 버튼이 제공된다
+- [x] 존재하지 않는 경로 접근 시 404 에러 페이지가 표시된다
+- [x] 홈으로 돌아가기 버튼이 제공된다
#### AI로 한 번 더 구현하기
@@ -203,74 +197,471 @@
## 과제 셀프회고
-
+React 없이 개발은 생각해본적 없었는데, 프레임워크의 소중함을 다시한번 느꼈습니다. 구현해야 할 코드 양이 꽤 많아 물리적인 시간도 많이 필요했고, 개념으로만 스치듯 알고 있던 내용과 부족한 부분을 자세히 살펴보지 못한채 완료하기 급급했던 점은 조금 아쉬움이 남았습니다.
+발제 주제를 보는 순간 React 없는 환경에서는 처음이었기 때문에 과연 가능할까 싶었는데, 반 정도는 React와 비슷했고 반 정도는 React의 고마움을 느꼈습니다. 처음 React를 접했을떄 흐름이 중간중간 끊어지는 느낌을 많이 받았었는데 그 부분이 많이 해소되었고, 편하게 사용했던 라우팅, 상태 관리 같은 기능들을 직접 구현하면서 프레임워크가 내부적으로 하고 있는 일에 대해 조금은 윤곽이 보였습니다.
+라우팅 하나 구현하는데도 History API를 공부해야 했고, 상태 관리 하나 만드는데도 Observer 패턴을 이해해야 했습니다. 하지만 이 과정에서 브라우저가 어떻게 동작하는지, 프레임워크가 내부적으로 무슨 일을 하는지 조금씩 보이기 시작했습니다.
### 기술적 성장
-
+**SPA형태의 페이지 이동 구현**
+
+당연하게 생각했던 SPA였는데 직접 구현해 보니 라우팅을 꼬이지 않도록 하기 위해 많은 신경을 썼습니다. 브라우저가 제공하는 History API를 사용하되, 중복 네비게이션을 방지하기 위해 현재 경로와 목표 경로를 비교하는 로직도 추가했습니다. 같은 경로로 이동하려고 하면 아무 동작도 하지 않아 불필요한 렌더링을 막았습니다.
+
+- History API(`pushState`, `popstate`)를 활용한 클라이언트 사이드 라우팅 구현
+- `history.pushState()`로 페이지 새로고침 없이 URL 변경
+
+GitHub Pages의 서브 경로 배포 환경(`/front_7th_chapter2-1/`)을 고려한 경로 정규화 로직을 구현해야 했습니다. 로컬환경에서는 그래도 History API로 어느정도 처리가 가능했는데, 배포를 하려다 보니, repo 경로가 생기며 배포 환경에서 라우팅이 깨지는 문제가 발생했습니다.
+
+=> 배포시점에 라우팅 깨지는 문제는 AI도움을 받아 해결했는데 아무래도 배포 환경에서 즉시 테스트가 어렵다 보니 시간이 꽤 소요되었습니다. 결국 라우팅 간에 정규화로직으로 보완하였습니다.
+
+여전히 브라우저가 내부적으로 어떻게 이걸 처리하는지는 아직 완전히 이해하지 못했습니다.
+
+- `history.pushState()`를 호출하면 브라우저의 주소창은 변경되는데, 왜 서버에 요청을 보내지 않는지?
+- 브라우저는 어떻게 "이건 실제 페이지 이동이 아니라 JavaScript가 URL을 변경한 것"이라고 구분하는지?
+- 뒤로가기 버튼을 누르면 `popstate` 이벤트가 발생하는데, 어떻게 처리되는건지?
+ 이런 부분들은 브라우저 엔진의 내부 동작과 관련된 것 같은데, 아직 그 레벨까지는 이해하지 못했습니다. 하지만 "History API를 사용하면 URL을 변경해도 페이지가 새로고침되지 않는다"는 것만 알아도 SPA를 구현하는 데는 충분했습니다.
+
+**상태 관리 패턴 학습**
+
+장바구니 기능을 구현하면서 Observer 패턴을 이해하고 적용해봤습니다. 처음에는 장바구니에 상품을 추가할 때마다 수동으로 UI를 업데이트하는 코드를 작성했는데, 이렇게 하니 코드가 여기저기 흩어지고 업데이트를 빠뜨리는 경우가 생겼습니다.
+
+- Observer 패턴을 활용한 장바구니 상태 관리 구현
+- `subscribe/notify` 구조로 상태가 변경되면 자동으로 구독자들에게 알림
+- 장바구니 모달, 헤더의 장바구니 아이콘 등 여러 곳에서 동일한 상태를 구독하여 자동 업데이트
+- LocalStorage와 연동하여 새로고침 시에도 데이터 유지
+
+Observer 패턴을 적용하고 나니 `cartStore.addToCart()`만 호출하면 관련된 모든 UI가 자동으로 업데이트되어서 코드가 훨씬 깔끔해졌습니다.
+
+직접 구현하면서 느낀 한계와 복잡함이 바로 React가 해결해주고 있던 문제들이었습니다. 예를 들어 상태가 변경될 때마다 어떤 UI를 업데이트해야 하는지 일일이 관리해야 했고, 이 과정에서 실수로 업데이트를 빠뜨리면 화면과 데이터가 불일치하는 버그가 발생했습니다. React의 자동 리렌더링이 얼마나 편리한 기능인지 새삼 깨달았습니다.
+
+**이벤트와 DOM 조작**
+
+React에서는 JSX와 가상 DOM 덕분에 직접 DOM을 건드릴 일이 거의 없었는데, Vanilla JS로 구현하면서 DOM 조작이 어려웠습니다. 특히 이벤트 위임 패턴을 활용해 `document.body`에서 모든 클릭 이벤트를 처리하고, `closest()` 메서드로 실제 타겟을 찾는 방식이 인상적이었습니다.
+
+React에서는 `onClick` prop만 넘기면 끝이었는데, 이벤트를 DOM마다 하나하나 적용해야 한다는게 많이 번거롭고 노가다 스러운느낌도 들었습니다.
+
+**URL 기반 상태 관리 (쿼리 파라미터 동기화)**
+
+React에서는 `useState`로 검색어나 필터 상태를 관리하지만, 이번 프로젝트에서는 URL 쿼리 파라미터를 상태 저장소로 활용되고 있다는걸 마지막에 가서 이해했습니다.
+
+- 새로고침해도 검색 조건 유지
+- URL 복사해서 공유 가능 (`/?search=노트북&category1=전자제품`)
+- 브라우저 뒤로가기/앞으로가기로 이전 검색 조건으로 돌아갈 수 있음
+- 별도의 상태 관리 라이브러리 없이도 상태 영속성 확보
+
+**무한 스크롤 구현 (AI 도움 많이 받음)**
+
+무한 스크롤은 이번 과제에서 가장 어려웠던 부분입니다. 개념은 이해했지만 실제로 구현하려니 고려해야 할 것들이 너무 많았습니다. 스크롤 이벤트를 감지해서 페이지 하단에 도달하면 다음 페이지 데이터를 불러오는 것까지는 간단했는데, 문제는 그 이후였습니다.
+
+가장 먼저 마주한 문제는 중복 요청이었습니다. 스크롤을 빠르게 내리면 같은 페이지를 여러 번 요청하는 현상이 발생했습니다. 이를 해결하기 위해 `isLoading` 플래그를 사용해서 로딩 중일 때는 추가 요청을 막아야 했습니다.
+두 번째 문제는 상태 초기화 타이밍이었습니다. 검색어나 카테고리를 변경했을 때 기존에 누적된 상품 목록을 초기화해야 하는데, 이 타이밍을 잘못 잡으면 화면에 이전 검색 결과가 잠깐 보이는 버그가 발생했습니다.
+세 번째는 페이지 전환 시 처리였습니다. 상품 상세 페이지로 갔다가 뒤로가기로 돌아왔을 때, 무한 스크롤 상태를 어떻게 유지할지 고민이 많았습니다. 처음부터 다시 로드할지, 아니면 이전 상태를 유지할지 결정해야 했습니다.
+
+솔직히 이 부분은 AI의 도움을 많이 받았습니다. 특히 `infiniteScrollState` 객체의 구조와 중복 요청 방지 로직은 AI가 제안한 코드를 기반으로 작성했습니다. 코드는 동작하지만 아직 완전히 이해하지 못한 부분이 있어서 추가 학습이 필요합니다.
### 자랑하고 싶은 코드
-
+**1. 라우터 구현 (`src/utils/router.js`)**
+
+동적 라우팅 파라미터를 정규표현식으로 변환하여 React Router와 유사한 방식으로 구현했습니다.
+
+- 동적 라우팅 파라미터(`:id`)를 정규표현식으로 변환하여 매칭
+- `toAppPath`와 `toBrowserPath` 함수로 앱 내부 경로와 브라우저 경로를 분리 관리
+
+```javascript
+const pathToRegex = (path) => new RegExp("^" + path.replace(/:\w+/g, "([^/]+)") + "$");
+
+export const findRoute = (pathname = "/") => {
+ const currentPath = toAppPath(pathname);
+ for (const route of routes) {
+ const match = currentPath.match(pathToRegex(route.path));
+ if (match) {
+ return { route, params: match.slice(1) };
+ }
+ }
+ return null;
+};
+```
+
+**2. 장바구니 상태 관리 (`src/store/cartStore.js`)**
+
+Observer 패턴을 활용하여 상태가 변경되면 자동으로 모든 구독자에게 알림이 전달되어 UI가 업데이트됩니다.
+
+- Observer 패턴으로 상태 변경 시 자동 UI 업데이트
+- LocalStorage 연동으로 새로고침 시에도 데이터 유지
+- 장바구니 모달, 헤더 아이콘 등 여러 곳에서 동일한 상태를 구독
+
+```javascript
+export const cartStore = {
+ state: { cart: loadStoredCart() },
+ observers: [],
+ subscribe(observerFn) {
+ this.observers.push(observerFn);
+ observerFn(this.state.cart);
+ return () => {
+ this.observers = this.observers.filter((observer) => observer !== observerFn);
+ };
+ },
+ notify() {
+ localStorage.setItem(CART_STORAGE_KEY, JSON.stringify(this.state.cart));
+ this.observers.forEach((observerFn) => observerFn(this.state.cart));
+ },
+};
+```
+
+**3. 이벤트 위임 패턴 (`src/main.js`)**
+
+모든 이벤트를 `document.body`에서 위임받아 처리하는 방식으로 구현했습니다. 동적으로 생성되는 요소에도 이벤트가 자동으로 적용됩니다.
+
+- 이벤트 리스너를 한 곳에서 관리하여 메모리 효율적
+- 동적으로 생성되는 요소에도 자동으로 이벤트 적용
+
+```javascript
+document.body.addEventListener("click", (e) => {
+ const target = e.target;
+
+ // 장바구니 모달 열기
+ const openCartModalBtn = target.closest("#cart-icon-btn");
+ if (openCartModalBtn) {
+ e.preventDefault();
+ openCartModal();
+ return;
+ }
+
+ // 상품 카드 클릭
+ const productCard = target.closest(".product-card");
+ if (productCard) {
+ push(`/product/${productCard.dataset.productId}`);
+ return;
+ }
+
+ // ... 기타 이벤트 처리
+});
+```
+
+**4. 배포 시 SPA 라우팅 설정**
+
+로컬에서는 완벽하게 동작하던 SPA가 GitHub Pages에 배포하니 새로고침하면 404 에러가 발생했습니다. 예를 들어 `/product/123` 페이지에서 새로고침을 누르면 "404 Page Not Found"가 떴습니다.
+
+```yaml
+# GitHub Actions에서 추가한 설정
+- name: Create SPA fallback
+ run: cp dist/index.html dist/404.html
+```
+
+이 두 줄을 추가하니 갑자기 모든 게 정상 동작했습니다. GitHub Pages의 특성을 이해하고 나니 해결책이 명확해졌습니다.
+
+**원인:**
+
+- 로컬 개발 서버(Vite)는 모든 경로 요청을 자동으로 `index.html`로 리다이렉트해줌
+- 하지만 GitHub Pages는 정적 파일 호스팅이라 `/product/123` 경로에 실제 파일이 없으면 404를 반환
+- SPA는 클라이언트 사이드 라우팅이므로 모든 경로에서 `index.html`을 반환해야 JavaScript 라우터가 동작함
+
+**해결:**
+
+- GitHub Pages는 404 에러 발생 시 `404.html` 파일을 보여줌
+- `404.html`을 `index.html`과 동일하게 만들면, 존재하지 않는 경로 접근 시에도 `index.html`이 로드됨
+- 그러면 JavaScript 라우터가 실행되어 올바른 페이지를 렌더링함
### 개선이 필요하다고 생각하는 코드
-
+**1. main.js의 이벤트 핸들러**
+
+현재 `main.js`에 모든 이벤트 핸들러가 집중되어 있습니다. 장바구니, 상품 카드, 카테고리 필터 등 모든 클릭/변경 이벤트를 하나의 파일에서 처리하고 있어 이부분 분리하거나 이벤트 처리 방법에 대한 고민이 필요합니다.
+
+```javascript
+// main.js에 모든 이벤트 핸들러가 집중되어 있음
+document.body.addEventListener("click", (e) => {
+ // 장바구니 추가, 삭제, 수량 변경
+ // 상품 카드 클릭
+ // 카테고리 필터 클릭
+ // 모달 열기/닫기
+ // ... 총 150줄 이상의 이벤트 핸들링 로직
+});
+```
+
+- 각 도메인별로 이벤트 핸들러를 분리하여 모듈화
+ - `src/events/cartEventHandlers.js`: 장바구니 관련 이벤트
+ - `src/events/productEventHandlers.js`: 상품 관련 이벤트
+ - `src/events/categoryEventHandlers.js`: 카테고리 필터 관련 이벤트
+- 각 핸들러 모듈에서 `init()` 함수를 export하여 main.js에서 초기화
+- 이벤트 위임 패턴은 유지하되, 로직을 도메인별로 분리하는 방식이 가능할 것 같은데, 여전히 이벤트 중복이나 id, class 등의 이름이 충돌 날 수도 있을 것 같아서 컴포넌트에서 등록/해제해야할지도 고민됩니다.
+
+**2. 무한 스크롤 성능 최적화 필요**
+
+현재 스크롤 이벤트를 직접 리스닝하고 있어 스크롤할 때마다 함수가 실행됩니다.
+(Intersection Observer) 등의 방식을 사용하여 개선이 필요합니다.
+
+**3. 컴포넌트 재렌더링 최적화**
+
+현재 컴포넌트들이 문자열 템플릿을 반환하고 `innerHTML`로 전체 DOM을 교체하는 방식입니다.
+
+- 상태 변경 시 전체 DOM을 교체하여 불필요한 리렌더링 발생
+- 스크롤 위치, 포커스 상태 등이 초기화될 수 있음
+- 이미지 재로딩으로 인한 깜빡임 현상 가능성
+ -> 변경된 부분만 업데이트하는 방식으로 개선이 필요한데 상태관리 등과 엮여서 어떻게 처리해야 할지 방향은 없는 상태입니다.
+
+```javascript
+const updateProductListDOM = () => {
+ const $productListContainer = document.querySelector("#product-container");
+ if (!$productListContainer) return;
+ $productListContainer.outerHTML = ProductList({
+ loading: false,
+ products: infiniteScrollState.accumulatedProducts,
+ hasMore: infiniteScrollState.hasMore,
+ totalCount: infiniteScrollState.totalCount,
+ });
+};
+```
### 학습 효과 분석
-
+- 프레임워크 없이 SPA를 구현하면서 React, Vue 같은 프레임워크가 내부적으로 어떻게 동작하는지 이해
+- History API, Observer 패턴, 상태 관리 등 웹 개발의 핵심 개념을 직접 구현하며 이해
+- URL 기반 상태 관리의 중요성과 구현 방법 학습
+
+**추가 학습이 필요한 영역**
+
+**1. 무한 스크롤**
+
+- 현재 구현은 AI의 도움을 많이 받아서 작성했기 때문에 내부 로직을 100% 이해하지 못함
+- 특히 `infiniteScrollState`의 상태 관리 흐름과 필터 변경 시 초기화 로직을 더 깊이 공부 필요
+- **Intersection Observer API** : 현재는 스크롤 이벤트를 직접 리스닝하는 방식인데, 무한 스크롤의 경우 Intersection Observer를 사용하는 경우가 많은 것 같음.
+
+**2. 컴포넌트 라이프사이클 관리**
+
+- 당장 동작을 위해 `innerHTML`로 전체 DOM을 교체하고 있는데 React의 생명주기를 이해하고 개선해야 함
+- React의 `useEffect`나 `componentDidMount/componentWillUnmount` 같은 개념을 Vanilla JS로 구현하는 방법
+- 컴포넌트가 마운트될 때 이벤트 리스너를 등록하고, 언마운트될 때 정리하는 패턴
+
+**3. 이벤트 버스 패턴**
+
+- 이벤트 버스 패턴을 사용하면 컴포넌트 간 결합도를 낮출 수 있다고 하는데...실제로 구현해보고 Observer 패턴과의 차이점을 체감해보고 싶음
+
+**4. DOM 조작**
+
+- 언제 어떤 메서드를 사용하는 것이 적절한지, 어떤 차이들이 있는지 추가 학습이 필요합니다.
### 과제 피드백
-
+**좋았던 점**
+
+쇼핑몰 사이트 이다보니 왠만한 기능들이 다 포함되어 경험해 볼 수 있었고, 화면녹화와 E2E테스트가 제공되어 일부 텍스트로 불명확했던 내용들이 명확해져서 좋았습니다.
+
+**모호하거나 애매했던 부분**
+어떤 기술이나 어떤 방향으로 학습해야할지 키워드라도 제공되면 좋을것 같습니다.
### AI 활용 경험 공유하기
-
+**AI 활용 방식**
+
+이번 과제는 스터디 과정이었기 때문에 AI에게 직접 코드를 작성해달라고 하기보다는, 구현 방향성을 물어보고 먼저 직접 구현해보려고 노력했습니다.
+
+예를 들어 URL 기반 상태 관리(쿼리 파라미터)를 구현할 때, AI가 이렇게 단계별로 가이드해줬습니다:
+
+**쿼리스트링 구현 흐름 (AI 가이드)**
+
+```
+1. 사용자가 검색 버튼 클릭 (또는 카테고리 선택)
+ ↓
+2. submit 또는 click 이벤트 발생
+ ↓
+3. 이벤트 핸들러에서:
+ - 검색어/필터 값 가져오기
+ - URLSearchParams 객체 만들기
+ - query.set('search', '노트북') ← 쿼리스트링에 추가!
+ - history.pushState(null, null, `/?${query}`) ← URL 변경!
+ - render() 호출 ← 화면 다시 그리기!
+ ↓
+4. render() 함수에서:
+ - location.search 읽기 (?search=노트북)
+ - URLSearchParams로 파싱
+ - query.get('search') → "노트북"
+ - getProducts({ search: "노트북" }) ← API 호출!
+ - 화면 업데이트
+```
+
+이런 식으로 AI가 큰 그림을 제시해주면, 그걸 바탕으로 직접 코드를 작성해보고, 막히는 부분이 생기면 다시 질문하는 방식으로 진행했습니다.
+
+전반적으로 AI가 방향성을 잡는 데 많은 도움을 줬습니다.
+
+**AI 도움을 많이 받은 부분**
+
+반면 무한 스크롤과 배포 시 라우팅 설정은 AI의 도움을 많이 받았습니다.
+
+**1. 무한 스크롤 구현**
+
+처음에는 개념만 이해하고 직접 구현하려 했는데, 스크롤을 빠르게 내리면 같은 페이지를 여러 번 요청하는 문제, 검색어 변경 시 기존 목록이 남아있는 문제 등이 계속 발생했습니다. 결국 ChatGPT에게 "무한 스크롤 구현 시 고려해야 할 사항과 상태 관리 구조"를 물어봤고, AI가 제안한 `infiniteScrollState` 구조를 기반으로 구현했습니다.
+
+특히 `isLoading` 플래그로 중복 요청을 방지하는 로직은 AI가 제안한 것을 그대로 사용했습니다. 코드는 동작하지만 아직 완전히 이해하지 못한 부분이 있어서 추가 학습이 필요합니다.
+
+**2. 배포 시 SPA 라우팅 설정 및 경로 정규화**
+
+GitHub Pages에 배포했을 때 두 가지 문제가 발생했습니다:
+
+1. **새로고침 시 404 에러**: `/product/123` 페이지에서 새로고침하면 404 에러 발생
+2. **배포 URL 경로 문제**: 로컬은 `localhost:3000/`인데 배포는 `youngh02.github.io/front_7th_chapter2-1/`로 서브 경로가 생김
+
+로컬에서는 완벽하게 동작했기 때문에 배포 환경에서만 발생하는 문제를 혼자 해결하기 어려웠습니다. 특히 배포할 때마다 확인해야 해서 디버깅이 힘들었습니다.
+
+ChatGPT에게 문제 상황을 설명하니 두 가지 해결책을 제시해줬습니다:
+
+**해결책 1: 404 폴백 설정**
+
+```yaml
+# GitHub Actions에 추가
+- name: Create SPA fallback
+ run: cp dist/index.html dist/404.html
+```
+
+**해결책 2: BASE_URL 경로 정규화 로직**
+
+AI가 `toAppPath`와 `toBrowserPath` 함수를 만들어서 로컬 경로와 배포 경로를 분리 관리하라고 알려줬습니다:
+
+```javascript
+// 로컬: "/" → 앱 경로: "/"
+// 배포: "/front_7th_chapter2-1/" → 앱 경로: "/"
+const toAppPath = (pathname) => {
+ // basePath를 제거하여 앱 내부 경로로 변환
+ const stripped = pathname.slice(basePath.length) || "/";
+ return normalizePath(stripped);
+};
+
+// 앱 경로: "/" → 배포: "/front_7th_chapter2-1/"
+const toBrowserPath = (appPath) => {
+ // basePath를 추가하여 브라우저 경로로 변환
+ return appPath === "/" ? `${basePath}/` : `${basePath}${appPath}`;
+};
+```
+
+이 정규화 로직 덕분에 로컬과 배포 환경 모두에서 라우팅이 정상 동작하게 되었습니다. 혼자서는 이런 접근 방식을 생각하기 어려웠을 것 같습니다.
+
+**느낀 점**
+
+AI는 방향성을 제시하고 막힌 부분을 돌파하는 데 큰 도움이 되었습니다. 하지만 AI가 제안한 코드를 그대로 복사하기보다는, 왜 그렇게 해야 하는지 이해하려고 노력하는 것이 중요하다고 느꼈습니다. 특히 무한 스크롤처럼 AI에 의존해서 구현한 부분은 나중에 다시 공부해서 완전히 내 것으로 만들어야겠다고 다짐했습니다.
## 리뷰 받고 싶은 내용
-
+### 1. main.js의 이벤트 핸들러 구조 개선 방안
+
+현재 `main.js`에 모든 이벤트 핸들러가 집중되어 있습니다 (약 150줄 이상). 장바구니, 상품 카드, 카테고리 필터 등 모든 클릭/변경 이벤트를 하나의 파일에서 처리하고 있는데요.
+
+```javascript
+// main.js
+document.body.addEventListener("click", (e) => {
+ // 장바구니 추가, 삭제, 수량 변경
+ // 상품 카드 클릭
+ // 카테고리 필터 클릭
+ // 모달 열기/닫기
+ // ... 등등 모든 이벤트 처리
+});
+```
+
+이를 도메인별로 분리하는 것이 좋을지, 아니면 현재처럼 중앙 집중식으로 관리하는 것이 더 나은지 궁금합니다. 혹은 이벤트 단위가 아니라 컴포넌트에서 등록/해제 등을 하는 방법도 가능할 것으로 보여서요, 분리한다면 어떤 기준으로 나누는 것이 좋을까요?
+
+### 2. 라우터의 경로 정규화 로직
+
+`router.js`에서 BASE_PATH를 고려한 경로 정규화를 구현했는데, 이 부분이 복잡하게 느껴집니다:
+
+```javascript
+const toAppPath = (pathname = "/") => {
+ const normalized = normalizePath(pathname);
+ if (basePath === "/") return normalized;
+ if (!normalized.startsWith(basePath)) return normalized;
+ const stripped = normalized.slice(basePath.length) || "/";
+ return normalizePath(stripped);
+};
+```
+
+배포 환경(GitHub Pages)에서 BASE_URL이 `/front_7th_chapter2-1/`처럼 서브 경로일 때를 대응하기 위한 로직인데, 더 간결하고 명확하게 작성할 수 있는 방법이 있을까요?
+
+### 3. 상태 관리 구조
+
+현재 프로젝트에서 상태 관리 방식이 일관되지 않아 고민입니다:
+
+**현재 구현 방식:**
+
+- **장바구니**: `cartStore` (Observer 패턴) - 여러 곳에서 구독하여 자동 UI 업데이트
+- **상품 목록 필터**: `infiniteScrollState` (단순 객체) - main.js에서 직접 관리
+- **상품 데이터**: `productCache` (Map) - 캐싱 용도로만 사용
+- **검색/필터 조건**: URL 쿼리 파라미터 - URLSearchParams로 관리
+
+```javascript
+// 장바구니 - Observer 패턴
+const cartStore = {
+ state: { cart: [] },
+ observers: [],
+ subscribe(fn) {
+ /* ... */
+ },
+ notify() {
+ /* ... */
+ },
+};
+
+// 무한 스크롤 - 단순 객체
+const infiniteScrollState = {
+ currentPage: 1,
+ isLoading: false,
+ accumulatedProducts: [],
+};
+
+// 상품 캐시 - Map
+const productCache = new Map();
+```
+
+**고민되는 점:**
+
+1. **상태 관리가 필요한 데이터의 기준**
+
+ 현재 장바구니는 전역 store + Observer 패턴 + UI 자동 업데이트로 관리하고 있습니다. 그렇다면 다른 UI 데이터들도 모두 이런 방식으로 관리해야 할까요?
+
+ - **상품 데이터 (product)**: 현재는 API 호출 후 바로 렌더링하고, `productCache`에만 저장합니다. 이것도 `productStore`로 만들어서 상태 관리를 해야 할까요?
+ - **검색/필터 조건**: URL 쿼리 파라미터로 관리 중인데, 이것도 별도 store가 필요할까요?
+ - **무한 스크롤 상태**: `infiniteScrollState` 객체로 관리 중인데, 이것도 Observer 패턴이 필요할까요?
+ - **모달 열림/닫힘 상태**: 현재는 DOM 조작으로만 처리하는데, 상태로 관리해야 할까요?
+
+ **어떤 데이터를 상태로 관리하고, 어떤 데이터는 그냥 두어야 하는지 기준이 궁금합니다.**
+
+2. **일관성 vs 적재적소**
+
+ - 모든 수정 가능한 UI 데이터를 Observer 패턴으로 통일하는 것이 좋을까요?
+ - 아니면 상황에 따하는 것이 합리적일까요?
+ - 예를 들어, 장바구니처럼 "여러 곳에서 구독이 필요한 경우"만 Observer 패턴을 쓰는 게 맞을까요?
+
+3. **상품 데이터 관리의 필요성 (중복 API 호출 문제)**
+
+ 현재 상품 데이터는 이렇게 흩어져 있습니다:
+
+ ```javascript
+ // main.js에서 API 호출 후 바로 렌더링
+ const products = await getProducts({ search, category1, sort });
+ $root.innerHTML = HomePage({ products });
+
+ // 캐싱만 하는 Map
+ const productCache = new Map();
+ productCache.set(product.productId, product);
+ ```
+
+ **문제점: 동일한 상품 데이터인데 API 조회가 너무 많이 발생합니다.**
+
+ 예를 들어:
+
+ - 홈 페이지에서 상품 목록 조회 → API 호출
+ - 상품 상세 페이지 이동 → 같은 상품인데 또 API 호출
+ - 뒤로가기로 홈 페이지 복귀 → 또 API 호출
+ - 관련 상품 표시 → 이미 본 상품들인데 또 API 호출
+
+ `productCache`를 만들어서 캐싱하고 있지만, 제대로 활용되지 않고 있습니다. 페이지 전환할 때마다 API를 다시 호출하는 것 같습니다.
+
+ 이것을 `productStore`로 통합 관리하면:
+
+ - 상품 목록, 상품 상세, 관련 상품을 한 곳에서 관리
+ - **중복 API 호출 방지** (이미 조회한 상품은 캐시에서 가져오기)
+ - 상품 데이터 변경 시 자동 UI 업데이트
+
+하지만 현재는 상품 데이터를 수정할 일이 없어서 굳이 필요 없어 보이기도 합니다.
+
+**질문: 읽기 전용 데이터도 store로 관리해야 할까요? 아니면 API 호출 레벨에서 캐싱 로직을 강화하는 게 나을까요?**
+
+**모든 수정 가능한 UI 데이터를 상태로 관리해야 하나요? 아니면 특정 조건(여러 곳에서 사용, 자주 변경됨 등)을 만족할 때만 상태 관리를 적용해야 하나요?**
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
new file mode 100644
index 00000000..fd2cd619
--- /dev/null
+++ b/.github/workflows/deploy.yml
@@ -0,0 +1,54 @@
+name: Deploy to GitHub Pages
+
+on:
+ push: # push trigger
+ branches:
+ - main
+ - release-* # release 브랜치도 배포
+
+permissions:
+ contents: read
+ pages: write
+ id-token: write
+
+concurrency:
+ group: "pages"
+ cancel-in-progress: true
+
+jobs:
+ deploy:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v4
+
+ - name: Install pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: 9.0.0
+
+ - name: Setup Node
+ uses: actions/setup-node@v4
+ with:
+ node-version: "20"
+ cache: "pnpm"
+
+ - name: Install dependencies
+ run: pnpm install --frozen-lockfile
+
+ - name: Build
+ run: pnpm run build
+
+ - name: Create SPA fallback
+ run: cp dist/index.html dist/404.html
+
+ - name: Setup Pages
+ uses: actions/configure-pages@v4
+
+ - name: Upload artifact
+ uses: actions/upload-pages-artifact@v3
+ with:
+ path: "./dist"
+
+ - name: Deploy to GitHub Pages
+ id: deployment
+ uses: actions/deploy-pages@v4
diff --git a/jsconfig.json b/jsconfig.json
new file mode 100644
index 00000000..461fa74a
--- /dev/null
+++ b/jsconfig.json
@@ -0,0 +1,12 @@
+{
+ "compilerOptions": {
+ "module": "ESNext",
+ "moduleResolution": "bundler",
+ "target": "ESNext",
+ "jsx": "preserve",
+ "checkJs": true,
+ "allowImportingTsExtensions": false
+ },
+ "include": ["src/**/*"],
+ "exclude": ["node_modules", "dist"]
+}
diff --git a/package.json b/package.json
index 5ec7f3f3..0d08dd38 100644
--- a/package.json
+++ b/package.json
@@ -1,9 +1,10 @@
{
- "name": "front-chapter1-1",
+ "name": "front-chapter2-1",
"private": true,
"version": "0.0.0",
"type": "module",
"scripts": {
+ "msw:init": "msw init public/",
"dev": "vite",
"dev:hash": "vite --open ./index.hash.html",
"build": "vite build",
diff --git a/src/components/cart/CartHeader.js b/src/components/cart/CartHeader.js
new file mode 100644
index 00000000..87bf82c6
--- /dev/null
+++ b/src/components/cart/CartHeader.js
@@ -0,0 +1,18 @@
+export const CartHeader = () => {
+ return /*html*/ `
+
+