[Feat/#11] 공통 레이아웃(375x812) + Bottom Nav 뼈대 구현

[xeoxxn]

#️⃣연관된 이슈

• Closes 공통 레이아웃(375x812) + Bottom Nav 뼈대 구현 #11

🎯 해결하려는 문제가 무엇인가요?

화면마다 아이폰 프레임 크기(375×812)와 Bottom Nav를 각자 다시 구현하지 않도록, 모든 화면이 공유하는 레이아웃 뼈대가 필요했다.

❓ 왜 해결해야 하나요?

Figma에서 홈/행사/게시판/빌릴게 화면을 서로 대조해보면, 375×812 프레임 비율과 Bottom Nav 두 가지만 모든 화면에 공통이고 Top Navigation 구성·필터·리스트 등 나머지는 화면마다 다르다. 이 두 가지를 공통 컴포넌트로 미리 빼두면 이후 각 화면을 만들 때 반복 구현을 줄일 수 있다.

⭐ 어떻게 해결했나요?

• src/components/ui/ScreenLayout.tsx: header/children 슬롯을 받는 고정 크기(375×812) 레이아웃. header(화면마다 다른 Top Navigation 등)와 children(화면 본문)은 각 화면이 채우고, 레이아웃 자신은 프레임 비율 고정 + 본문 스크롤 + Bottom Nav 고정만 담당한다.
• src/components/ui/BottomNav.tsx: 홈/행사/게시판/빌릴게 4탭 Bottom Nav. WDS BottomNavigation은 iOS 반투명 배경과 document.body 스크롤 감지 로직이 있어 헤더/푸터 고정 + 내부 스크롤 구조와 안 맞아 Stream 로컬로 구현했다.
• src/index.css: WDS --semantic-* CSS 변수를 Tailwind 색상 토큰으로 별칭 연결(text-label-normal, bg-background-alternative 등) — 하드코딩 hex 없이 색을 쓴다.
• App.tsx는 라우팅 도입 전까지 ScreenLayout이 잘 동작하는지 확인하는 임시 데모만 렌더링한다.

🧩 이 PR의 한계 & 트레이드오프

• 애초에 이 브랜치/이슈로 빌릴게 대여 목록 화면(TopNavigation 구성, 카테고리 필터, RentalItemCard, 물품 목데이터)까지 같이 만들었었는데, 다른 화면과 대조해보니 그건 전부 빌릴게 전용이라 공통 레이아웃 PR 범위가 아니었다 — 그 커밋들은 이 브랜치 히스토리에 남겨두고 새 커밋으로 제외했다(강제 push 없이 진행해서 필요하면 복구 가능). 빌릴게 화면 전용 구현은 별도 이슈로 다시 진행 예정.
• ScreenLayout은 아직 실제 화면(빌릴게 등) 하나에도 적용해보지 않은 상태다 — 다음 작업에서 실제로 써보면서 슬롯 설계가 충분한지 검증 필요.

⛓️ 기존 기능에 미치는 영향

새 공용 컴포�네트 추가라 기존 코드에 미치는 영향 없음.

🔀 Edge Case & 실패 시나리오

• 본문 콘텐츠가 화면보다 짧아도 레이아웃이 깨지지 않는지, 길 때 스크롤이 자연스러운지는 실제 화면 적용 시 확인 필요.

📋 검토한 대안과 선택 이유

• Bottom Nav를 ScreenLayout 밖에서 각 화면이 직접 조립하는 방식도 검토했으나, 모든 화면에 동일하게 들어가는 요소라 레이아웃 안에 고정해서 실수로 빠뜨리는 일을 방지했다.

💬 리뷰 포인트

• [c] ScreenLayout의 header/children 슬롯 설계가 앞으로 나올 화면들(행사, 게시판 등)에도 무리 없이 맞을지

[jjunh33]

전체적으로 공통 레이아웃의 책임을 375×812 프레임 + Bottom Nav로 한정하고, 화면별 요소는 header / children으로 분리한 것 확인했습니다. WDS BottomNavigation 대신 현재 내부 스크롤 구조에 맞게 로컬 컴포넌트로 구현한 이유도 확인했습니다.

그 외 큰 수정사항은 없어 보입니다!