[fix/#305] Watch 앱 상태 푸시 실패시 재시도한다.

[GRJeon]

🔗 연관된 이슈

• closed Watch 앱 상태 푸시 실패시 재시도한다. #305

📝 작업 내용

📌 요약

• watch 앱 상태 푸시 실패시 재시도 로직을 넣었습니다. (각 1초 후 최대 3회)
• (수정) 위 방식을 포기하고 아이폰에서 WCSession을 초기화할 때 상태를 푸시하라는 명령을 보내는 방식으로 수정

💬 리뷰 노트

• 로그가 잘 되어있어서 편했네요. 로그 굿
• (수정) 재시도 로직은 재시도 시간이 지나서 아이폰 앱이 켜지면 작동을 안 해서 방식을 변경했습니다.

📸 영상 / 이미지 (Optional)

[YunDaeHyeon]

📄 PR Code Review Report

🔍 Summary

WCSession을 통해 Watch 앱 상태를 iPhone으로 푸시하는 로직에 재시도 메커니즘이 추가되었습니다. 네트워크 불안정 등 일시적인 문제로 인한 상태 전송 실패에 대비하여 견고성이 향상되었습니다. 구현은 대체로 안전하고 올바르게 보입니다.

⚠️ Key Issues

• 이번 변경사항에서는 프로덕션 환경에서 버그나 크래시를 유발할 수 있는 치명적인 문제는 발견되지 않았습니다.

🛠 Improvement Suggestions

1. 재시도 실패 시 후속 처리 고려: 현재 최대 재시도 횟수 초과 시 로그만 남기고 상태 전송을 포기합니다. 만약 이 상태 전송이 Watch 앱의 핵심적인 기능이라면, 전송이 최종적으로 실패했을 때 사용자에게 알림을 주거나, Watch 앱 내부적으로 다른 폴백(fallback) 상태로 전환하는 등의 추가적인 실패 처리 로직을 고려해볼 수 있습니다. 예를 들어, Watch UI에 "iPhone 연결 실패" 메시지를 표시하여 사용자에게 상황을 알리는 방법 등입니다.
2. 재시도 큐 명확화: 현재 DispatchQueue.main.asyncAfter를 사용하여 재시도를 스케줄링하고 있습니다. WCSession 관련 작업은 메인 스레드에 반드시 묶일 필요가 없는 경우가 많으므로, 만약 재시도 로직이 UI 업데이트와 직접적인 관련이 없다면 별도의 백그라운드 큐에서 실행하는 것을 고려해 볼 수 있습니다. 현재 구현이 문제를 일으킬 가능성은 낮지만, 작업의 성격에 맞는 큐를 명시적으로 사용하는 것이 좋습니다.

✅ Positive Observations

1. 안전한 재시도 로직: retryCount를 활용하여 재시도 횟수를 명확하게 제한하고, DispatchQueue.main.asyncAfter를 사용하여 비동기적으로 재시도를 스케줄링한 점은 모범적인 구현입니다.
2. 메모리 관리: 재시도 클로저 내에서 [weak self]를 사용하여 강한 참조 순환(retain cycle)을 방지한 점은 매우 좋습니다.
3. 향상된 견고성: 일시적인 WCSession 오류에 대한 재시도 메커니즘 추가로 앱의 안정성과 사용자 경험이 개선될 것으로 기대됩니다.
4. 명확한 로깅: 재시도 횟수와 최종 실패 이유를 로그에 명확하게 남겨 디버깅에 큰 도움이 될 것입니다.