MyPageFeature 모듈 분리

1. 모듈 독립성 확보

• Feature 간 직접 의존 제거
• Interface 기반 의존 구조로 변경
• Core / DesignSystem만 공통 의존

2. 구조 재정의

• Presentation 레이어 중심 구조 유지
• 공통 비즈니스 로직은 MLSAppFeature로 위임

3. Interface 모듈 분리

• 외부에서 접근 가능한 Factory 정의
• Feature 내부 구현 은닉
• DIContainer는 Interface 기준으로 등록

4. Testing

• Interface 기반 Mock 객체 정의
• Reactor / UseCase 테스트 지원
• 테스트 코드 재사용성 확보

5. Demo 앱

• 별도 Example 앱 제거
• Main App Target에서 Feature 확인
• Mock은 App 레벨에서 주입

6. 테스트

• Reactor 중심 테스트 작성
• 비즈니스 로직 단위 테스트 작성
• UI 테스트는 제외

UseCase

• CheckUseCaseTests.swift
• AuthUseCaseTests.swift

Reactor

• MyPageMainReactorTests.swift
• NotificationSettingReactorTests.swift
• SetCharacterReactorTests.swift
• SetProfileReactorTests.swift
• PolicyReactorTests.swift
• CustomerSupportReactorTests.swift

Repository

• MyPageRepositoryTests.swift
• AlarmRepositoryTests.swift
• NotificationPermissionRepositoryTests.swift

---

• webViewController의 위치는 어디가 적절한가?? core에서 UI 관련 코드는 완전히 걷어내고 BaseFeature 모듈을 만들어야하는지 또 다시 고민..
• core의 명확한 역할정의 필요. CompositionalLayoutBuilder, CompositionalSectionBuilder, LayoutFactory이 현재는 DesignSystem에 위치하지만 core와 DesignSystem 사이의 의존방향에 따라 위치 달라질 수 있음.. BaseFeature가 생긴다면 더더욱 core / designSystem / feature 의존성 방향 정의 필요..
• 헷갈리는점 하나있음.. 만약 authRepo가 auth모듈과 myPage모듈에서 모두 사용된다면 authRepo의 인터페이스는 어디에 위치?(현재는 auth모듈에 위치) 해당 인터페이스를 각 모듈에서 접근하여 구현체를 구현한다고 가정하면 인터페이스가 점점 비대해지는 문제가 있지않나?? repo 단위를 더 나눠야하나??
• 데모앱에 mockrepo가 아닌 실제 repo 구현체를 넣으면 안되는건가?? 실제 구현체는 각 feature에 위치하는게 아닌가??