iOS 위젯 개발기
안녕하세요. 왓챠 iOS 개발자 달리아입니다. 저는 유저의 유입을 담당하는 User Acquisition 스쿼드(UA 스쿼드)에서 일하고 있습니다. 스쿼드는 다양한 분야의 사람들이 모여 일하는 크로스 펑셔널 팀입니다. UA 스쿼드는 왓챠에 더 많은 유저를 유입시키고 구독자를 늘리는 것을 목표로 하고 있습니다.
적용한지 시간이 많이 지나긴 했지만 iOS 위젯 개발 과정이 왓챠의 개발 문화를 잘 보여줄 수 있을 것 같아 약간의 개발팁과 함께 공유해보려 합니다.
짬데이를 통한 프로토타입 개발
WWDC 2020을 보면서 iOS에 새로 추가된 위젯이 인상 깊었습니다. 왓챠 앱에 들어와서 바로 “이어보기” 탭에 있는 컨텐츠를 볼 때가 많아서 이어서 볼 컨텐츠를 노출해주는 위젯이 있다면 유용할 것 같았거든요. 또한 보고싶어 할 컨텐츠를 바로 노출해줌으로서 유저의 유입도 증가할 것이라는 기대가 있었습니다. 기존에 있는 이어보기 탭의 컨텐츠 API와 컨텐츠를 바로 재생하는 링크를 활용하면 쉽게 개발도 가능했구요.
하지만 위젯은 기존 UI 방식인 UIKit과 다른 SwiftUI로만 개발해야 하기 때문에 SwiftUI에 대한 공부가 필요했습니다. 또한 다른 업무들도 많다보니 이런 아이디어들을 실제 개발로 이어나가기가 어려울 때가 많은데요. 왓챠에는 월요일마다 업무와 관련된 공부를 할 수 있는 “짬데이”가 있습니다. 이 시간을 활용해 SwiftUI를 공부하고 위젯을 개발해보기 시작했습니다. 짬데이를 통해 프로토타입 개발을 마치고 UA 스쿼드에 프로토타입 영상과 함께 위젯을 추가해보는게 어떨지 의견을 남겼습니다.
- 참고로 SwiftUI 스터디에는 애플의 SwiftUI 튜토리얼과 스탠포드 Developing Applications for iOS using SwiftUI를 활용했습니다. 쉽게 잘 설명되어 있어서 SwiftUI 입문하는데 추천드립니다🙌
커뮤니케이션을 통한 스펙 꾸리기
스쿼드에 프로토타입과 함께 아이디어를 말씀드리고나서 2주 후쯤 디자이너가 시안을 잡아서 전달해 주셨어요. 그 후 팀원들과 커뮤니케이션을 통해 기능을 개발해나갔습니다. 돌이켜 생각해보니 위젯 개발을 하면서 한 번도 회의를 하지 않았더라구요. 메신저를 통해서 “이런 걸 넣어보면 어떨까요?”하는 질문을 던지고 다양한 관점에서 더 나은 방향을 제시하고 빠르게 의사소통이 되어서 회의가 필요하지 않았던 것 같습니다. 실제로 어떤 커뮤니케이션이 있었는지 두 가지 케이스를 공유해 드리려고 합니다.
1. 플레이스홀더 적용
SwiftUI에는 플레이스홀더라는 유용한 기능이 있습니다. 기존 UIKit을 사용할 때는 데이터가 없는 케이스의 뷰를 따로 작업했어야 했는데, SwiftUI에서는 플레이스홀더를 이용하면 쉽게 이런 케이스의 뷰를 보여줄 수 있게 되었습니다. 이 기능을 디자이너에게 제안해서 데이터가 없는 케이스를 위한 작업량을 줄이면서도 좋은 UI를 만들어 볼 수 있었습니다. 워터폴 방식으로 정해진 것을 개발해나가는게 아니라 함께 더 좋은 방법을 찾아 개발해나가는 과정이 즐거웠습니다.
2. 이어보기 이미지 개선
왓챠에는 “참여하고 영향을 끼치는”이라는 문화상이 있는데요. 스쿼드에서 진행하는 업무더라도 누구든지 참여할 수 있는 공개된 공간에서 대화가 이루어집니다. 벤은 디자인 리더시고 UA 스쿼드 구성원은 아니시지만, 위젯에서 “이어보기”라는 점을 어떻게 더 어필할지 고민하는 대화를 보시고 논의에 참여해주셨습니다. 벤은 이어보기 위젯에 뜨는 이미지가 일반적인 스틸컷이 아니라 재생시점이 고려된 이미지를 보여주면 좋을 것이라는 의견과 이와 관련된 작업이 서버팀에서 이뤄졌었다는 얘기도 공유해 주셨어요. 이를 바탕으로 서버팀에 문의드렸고 에피소드인 경우에 한해 재생시점이 고려된 이미지를 적용해주셨습니다.
소소한 개발팁
추가로 소소한 개발팁 세 가지를 공유할게요.
1. 앱 타겟 간의 쿠키, 코드 공유
작업하면서 특히 어려움을 겪었던 건 sharedCookieStorage가 완벽히 실시간으로 싱크되지는 않는다는 것이었어요. 앱 타겟에는 쿠키가 없는데 위젯 타겟에는 쿠키가 있다던지 또는 그 반대로 앱 타겟에는 쿠키가 생겼는데 위젯 타겟에는 없어서 이어 볼 영상을 싱크 맞춰서 보여주는 데에 문제가 있었습니다. 그래서 이 부분은 로컬 저장소에 쿠키를 따로 저장해서 해결했습니다. 그리고 쿠키 변경은 빈번하게 발생하지만 유저가 실제로 위젯을 보게 될 때는 앱이 백그라운드로 간 후이기 때문에 applicationDidEnterBackground 시점에만 쿠키를 저장하고 위젯을 리프레시하도록 했습니다.
위젯을 추가하면서 쿠키 공유를 위해 app group capability를 추가해서 인증서나 프로필을 업데이트해야 했는데요. 기존에 셋팅되어 있던 fastlane match를 통해서 쉽게 작업할 수 있었습니다. 프로필 업데이트는 다른 개발자분들에게도 영향이 가기 때문에 망설여지는 부분인데 자동화가 되어 있어 이런 부담을 줄일 수 있었어요.
위젯에서 앱 타겟의 코드가 필요할 때는 파일에서 그 부분만 분리해서 앱과 위젯 타겟에 모두 포함되도록 적용했습니다.
2. 에러 처리
프로토타입은 이어보기가 있는 해피 케이스에 대해서만 작업을 했다면, 제품의 기능으로서는 이어보기할 컨텐츠가 없는 경우, 로그인이 안 된 경우 등 다양한 케이스들을 대비하는 작업을 했습니다. 다양한 에러 케이스를 WatchingError의 case로 정의하고 API 응답을 파싱할 때 error를 담아 completionHandler를 호출하도록 작업했습니다.
3. 플레이스홀더 뷰의 커스텀이 필요한 경우
에러가 있는 경우에는 대부분의 뷰들이 기본 플레이스홀더로 대체 가능했지만 추가적으로 문구를 노출해서 정확한 에러의 원인을 유저에게 전달할 필요가 있었습니다. Swift By Sundell 블로그글을 참고해서 플레이스홀더인 케이스에 특정 뷰는 직접 만든 뷰로 대체하는 함수를 만들어서 적용했습니다.
마치며
짬데이를 통해 새로운 기술을 공부해서 적용해가는 과정이 보람 있었습니다. 그리고 입사한지 두 달 밖에 안 된 시점이었지만 의견을 제시하는 것이 자유로웠고, 다양한 역할의 팀원들이 모두 더 좋은 방향을 찾아 자유롭게 협력해가는 모습이 인상적이었어요. 제품에 대한 애정이 많고 적극적인 왓챠 팀원들과 함께였기 때문에 즐겁게 위젯을 개발할 수 있었습니다.
