Refactor(client): HASHI-158 메뉴 섹션 네이밍 정리

[yurimidaH]

📌 요약

식당 상세/메뉴 상세에서 함께 사용하는 메뉴 리스트 섹션의 네이밍을 실제 책임에 맞게 정리했습니다.

Jira: HASHI-158

Stacked PR입니다.
base: refactor/HASHI-157-restaurant-detail-common-actions
head: refactor/HASHI-158-restaurant-menu-section-naming
머지는 HASHI-157 PR이 먼저 머지된 뒤 HASHI-158 PR을 머지하는 순서로 진행합니다.

📚 작업 내용

• RestaurantMenuSection을 RestaurantMenuListSection으로 rename했습니다.
• 식당 상세 메뉴 탭과 메뉴 상세의 다른 메뉴 영역에서 사용하는 import/컴포넌트명을 갱신했습니다.
• 관련 spec.md의 컴포넌트명도 함께 갱신했습니다.

🔎 상세 설명

기존 RestaurantMenuSection은 이름만 보면 식당 상세 페이지 전용 섹션처럼 보였지만, 실제로는 식당 상세의 메뉴 탭과 메뉴 상세 페이지의 “다른 메뉴” 목록에서 함께 사용되고 있었습니다.

이번 PR에서는 컴포넌트의 실제 책임이 “메뉴 목록 렌더링”에 가깝다는 점을 드러내기 위해 RestaurantMenuListSection으로 이름을 정리했습니다. RestaurantOtherMenuSection은 기존처럼 “다른 메뉴” 제목과 카운트의 소유 책임을 유지하고, 실제 목록 렌더링은 RestaurantMenuListSection이 담당합니다.

💭 고민한 부분

고민한 문제

• 기존 이름은 식당 상세 전용 섹션인지, 메뉴 리스트 공통 섹션인지 책임이 애매했습니다.
• 메뉴 상세 페이지에서 재사용 중인 컴포넌트가 restaurantDetail feature 안에 있어 소유 책임을 어디까지 조정할지 고민했습니다.

고려한 선택지

• 컴포넌트를 page-local로 이동해서 메뉴 상세 전용 컴포넌트와 식당 상세 전용 컴포넌트를 분리
• 현재 위치는 유지하되 이름을 메뉴 리스트 책임 중심으로 변경

최종 선택과 이유

• 현재 위치는 유지하고 RestaurantMenuListSection으로 rename했습니다.
• 메뉴 상세도 식당 상세 흐름에서 파생된 메뉴 도메인을 공유하고 있어 아직 shared로 빼거나 page-local로 중복 분리하기보다는, feature 내부에서 재사용 의도가 드러나는 이름으로 정리하는 편이 적절하다고 판단했습니다.

남은 고민

• HASHI-157 브랜치가 업데이트될 경우, 이 PR 브랜치도 최신 157 기준으로 rebase해서 diff가 섞이지 않도록 관리하겠습니다.