[#545] SignInUseCase의 Sendable 책임을 TCA Dependency로 분리한다

[opficdev]

🔗 연관된 이슈

• closed SignInUseCase의 Sendable 책임을 TCA Dependency로 분리한다 #545

🎯 의도

• SignInUseCase 자체에 Sendable 책임을 두지 않고 로그인 feature의 TCA dependency 경계에서만 필요한 동시성 책임을 관리하기 위함
• Sendable 적합성을 무분별하게 확장하지 않고 실제로 필요한 범위만 남기도록 정리하기 위함

📝 작업 내용

📌 요약

• 공통 계층과 하위 계층에 넓게 추가됐던 Sendable 관련 선언 제거
• SignInUseCase를 plain protocol로 복구
• AuthProvider와 SignInUseCaseDependency만 로그인 feature 경계에 맞게 Sendable 적용
• LoginFeature의 dependency 접근을 key path 기반에서 key type 기반으로 변경

🔍 상세

• SignInUseCase, AuthenticationRepository, Data/Infra/Persistence/WidgetCore 일부 타입에 추가됐던 Sendable, @Sendable, @unchecked Sendable 선언 제거
• AuthProvider를 Sendable로 선언해 로그인 action payload의 값 타입 경계 명시
• SignInUseCaseDependency를 Sendable 래퍼로 두고 execute 클로저만 @Sendable로 유지
• @Dependency(\.signInUseCase)를 @Dependency(SignInUseCaseDependency.self)로 변경해 DependencyValues key path 기반 경고 제거
• LoginFeature의 Action, AlertType에 Sendable 적용
• DevLogDomain import에 @preconcurrency 적용해 로그인 경로의 모듈 경계 경고 축소

📸 영상 / 이미지 (Optional)

[gemini-code-assist]

Code Review

이번 풀이 리퀘스트는 프로젝트 전반에서 불필요하거나 잘못 설정된 Sendable 채택을 제거하고, LoginFeature 등 일부 타입에 Sendable을 추가하거나 의존성 주입 방식을 개선하는 변경 사항을 담고 있습니다. 리뷰 의견으로는 WebPageImageStoreImpl의 perform 메서드가 백그라운드 큐에서 클로저를 실행하므로, 데이터 레이스 방지와 멀티스레드 안전성을 위해 Sendable 제약을 유지해야 한다는 지적이 있었습니다.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.