NotificationTab의 View 구성 요소와 렌더링 입력을 분리한다

[opficdev]

구현 순서

• 구현 흐름: View 구성 요소 분리 (4/6)
• 전체 순서: Entry의 View 구성 요소와 렌더링 입력을 분리한다 #879 → HomeTab의 View 구성 요소와 렌더링 입력을 분리한다 #880 → TodayTab의 View 구성 요소와 렌더링 입력을 분리한다 #881 → NotificationTab의 View 구성 요소와 렌더링 입력을 분리한다 #882 → ProfileTab의 View 구성 요소와 렌더링 입력을 분리한다 #883 → PresentationShared의 View 구성 요소와 렌더링 입력을 분리한다 #884
• 이전 작업: TodayTab의 View 구성 요소와 렌더링 입력을 분리한다 #881
• 다음 작업: ProfileTab의 View 구성 요소와 렌더링 입력을 분리한다 #883
• 기능상 선행 조건: 별도 차단 조건 없음; 아래 책임 구분과 기존 구현 상태 확인
• 진행 기준: 이전 작업의 완료 조건과 검증 결과 확인 후 착수; 코드 변경이 있으면 기준 브랜치 반영까지 확인
• 순서 구분: 위 순서는 실행 순서이며 기능상 선행 조건과 별도로 관리
• 요구사항 이력: struct View 분리 시 렌더링 입력을 최소화한다 #812; 구현 의존 대상으로 사용하지 않음

목적

아래 작업 범위를 하나의 구현 단위로 진행

작업 범위 및 완료 조건

• PushNotificationListView.swift의 UI 계산 속성·뷰 생성 함수를 중심으로 같은 파일의 private struct View로 분리
• 화면 표현에 필요한 값·Binding과 필요한 범위의 동작만 전달; 단순 이동을 위한 전체 StoreOf·Coordinator·저장 클로저 전달 방지
• UI 계층·modifier·순서·동작 보존; 모든 View의 Equatable 적용 강제 없이 build-only 검증
• 관련 디자인 이슈 #849와 변경 순서 조율; 실제 착수 시 모듈 전체 대상 재점검

책임 구분 및 선행 작업

• 기능·디자인 변경과 근거 없는 성능 향상 주장 제외; 성능 효과를 주장할 경우 동일 시나리오 Instruments 전후 측정

제외 범위

• 원본 요구사항을 넘어서는 기능·정책 및 구조 변경

검증

• 변경 파일 SwiftLint 및 해당 target build-only
• UI 동작 보존 확인; 실행 검증은 별도 실행 허용 후 수행
• 성능 효과를 주장할 경우 Instruments 동일 시나리오 전후 측정

참조

• 요구사항 이력 및 디자인 참조: struct View 분리 시 렌더링 입력을 최소화한다 #812

현재 탐색 구조 보존

• 최소 지원 버전 iOS 18과 현재 화면의 Store·탐색 경로 소유권 유지
• 제거된 화면 Coordinator와 넓은 화면 전용 상세 컨테이너 복원 제외