3주차 회고록 S013

3주차 회고록

클린 아키텍처와 RxSwift를 이용해서 MVVM을 직접 적용하는데 생각보다 오래 걸렸고 어려웠다. 오래 걸린 이유는, DIContainer를 만들 때, 생성자를 통해 의존성을 주입시킬려 했는데, Service 프로토콜, Repository, UseCase, 클로저중 무엇을 의존성으로 해서 주입시키는 것이 적절한지 고민하는데 판단이 잘 되지 않았다. 정작 구현한 DIContainer는 팩토리 패턴에 더 가깝다는게 문제였다.

뷰모델도 마찬가지였다. 회의에서 각 화면에서 필요한 비지니스 로직을 기준으로 UseCase를 나눠서 총 14개로 나뉘어 졌고, 이중에서 겹치는 UseCase를 분류했는데, 3개만 겹쳤다. 그러다 보니, 대부분의 UseCase들이 하나의 ViewModel에만 쓰게 되는 불편함이 있다. 작동에는 문제가 없(어야 하)지만, Repository의 메서드를 호출해서 바로 비지니스 로직을 구현하면 되는 일을, 불필요하게 UseCase를 한 번 더 거쳐야 하고, 관리해야 할 파일도 늘어나게 되었다. 저번주에 멘토님께서 UseCase는 재활용이 되지 않으면 사용하지 않아도 된다는 조언을 주셨는데, 뷰 모델에서 중복되지 않는 비지니스 로직의 경우, UseCase 주입 대신 Repository를 주입해서 비지니스 로직을 구현하면 된다는 생각을 하면서 그 의미를 깨달은 것 같다.

RxSwift의 경우, 무지성으로 Behavior, Relay, Observable을 사용하지 말고, Trait인 Single, Completable을 최대한 활용해보았다. 백엔드 담당자인 병학님께서 FireBase를 활용하는 Repository 구현체의 코드를 참조해서 활용해 보았다. 멘토님께서는 BehaviorRelay는 get과 set 모두 할 수 있는 문제가 있어 ViewModel의 출력으로는 BehaviorRelay보다는 Observable로 수정해야 한다는 피드백을 받았다.

대신에 클린 아키텍처를 적용해 보니, 프로토콜을 구현한 객체를 주입하면 되었기 때문에, FireBase를 사용하는 네트워크 관련 Repository가 구현이 안되었을 때, 마냥 기다리지 말고, Dummy Repository를 만들어, 로그인을 그냥 통과하게 만들고, 로컬에 프로필, 사진을 저장해서 프로필 등록, 마이 프로필 불러오기, 프로필 수정 기능을 테스트 할 수 있었다. 다만, DIContainer의 형식이 통일되지 않아, 테스트를 위해 의존성을 주입할 때 오래 걸렸다. 가짜 기능을 구현한 Repository와 Service, UseCase를 DIContainer에 주입하고, 그 다음에는 Coordinator에 주입한 DIContainer의 메서드로 ViewController를 생성해서 navigationController에 push, present 시켰다.

클린 아키텍처와 MVVM을 통해 쉬운 테스트와 좀 더 빠른 구현을 위해서는, 처음부터 Coordinator, DIContainer, ViewModel, UseCase를 프로토콜 등을 통해 스타일을 정해둬야 한다고 느꼈다.

소통의 경우, 원래 어려움이 있어도 스스로 인터넷 검색이나, 로직 스케치 등으로 해결해왔는데, 그만큼 늦어진 태스크가 팀원들에게 영향도 미치게 된다. 그래서, 막힐 때는, (다른 태스크를 하거나) 스스로 해결을 해도, 어디서 막히고 있고, 어떻게 해결하려는 중인지를 포함해서 늦어질 것 같다는 스레드를 그룹채널에 올려보겠다는 제안을 담주 스크럼때 안건으로 올려 보는게 좋을 것 같다.

그 외에 막힌 부분은 로그인 관련한 문제였다.

로그인 시 패스워드 입력 후 넘어가지 않는 문제

시뮬레이터에서 애플 로그인 시, 패스워드를 올바르게 입력 한후, 버튼을 눌렀는데, 아무 응답이 없었다. 인증 성공은 물론, 실패시 호출되는 델리게이트 함수 모두 호출되지 않아, 원인 파악이 아예 되지 않았다. Sign In With Apple이 체크된 Profile 인증서를 Xcode에 넣지 않았을 때와 같은 일이었는데, 병학님이 주신 인증서 (프로필) 파일을 무효화 시켜서 발생한 일일 것이라고 말씀하신 것을 보면, 인증서가 유효하지 않아 생긴 일인 것 같다. 미리 병학님께 문의 드렸으면, 바로 해결되었을 문제였는데, 그러지 않은 것이 후회되었다.

회원 탈퇴 시 Apple Token Revoke 고민

Apple 문서 (https://developer.apple.com/kr/news/?id=12m75xbj)에 20220630 이후로는 Sign In With Apple을 사용하는 사이트에서 계정 삭제 시, REST API를 호출해서 Apple Token까지 Revoke 시켜야 한다고 명시 되어 있어 처리하려 했었다. 그런데 문제가 된 부분은 client_secret 부분인데, 어떤 토큰인지 처음에 이해가 되지 않아, 로그인 때 받은 idToken을 넣어 터미널에서 validate token을 하는 post 요청을 보내봤지만, 400 (invalid_client) 응답을 받았다. 좀 더 찾아보니 Apple Developer에서 Sign In With Apple 인증서를 만들 때 생성되는 비밀키(p8)이 필요하고, jwt 토큰을 만들어 post 하는 작업 까지 해야 해서 복잡하였다. 그리고, 병학님께서 2개 앱에서 revoke 과정을 구현하지 않았는데, 앱 심사에서 탈락되지 않으셨다 해서, 다른 기능 구현이 더 급해서 이 부분은 나중에 시간이 될 때 구현할 계획으로 중지했다.

다음 주 태스크

• 이미지 Crop
• 이미지 불러올 때, 이미지 권한 문제 해결
• 시스템 알림 on/off 구현
• 데모 발표 준비
• 뷰모델 RxSwift 관련 프로퍼티, 메서드 점검 및 보완