페이워치 리뉴얼 회고

안녕하세요. 도미닉입니다.

오늘은 포스팅을 두개 올리게 되었네요.

작년 말부터 페이워치 앱의 리뉴얼을 시작하였습니다.

5/15 에 드디어 배포하게 되었습니다.

그 과정들을 정리해보고 회고해보고자 합니다.

 

기술 스택 결정(2022년 11월)

iOS 앱을 만들기 전에 우선 기술 스팩을 CTO 님께 제안드렸습니다.

SwiftUI

저는 SwiftUI 로 앱을 만들어본 적은 없었는데요.

UIKit 으로 개발을 하면 개발이 완료되는 시점에 레거시가 되지 않을까 라는 걱정이 있었습니다.

페이워치에 합류하기 전에 다른 회사들의 면접을 볼 때에도 최근 1~2년 안에 만들어진 서비스들의 경우 대부분 SwiftUI로 앱이 개발되었습니다.

이러한 고민과 새로운 기술을 사용해보면서 성장하고 싶은 마음에 SwiftUI 로 개발을 제안 드렸고 CTO님께서 흔쾌히 받아주셔서 사용하게 되었습니다.

iOS Target : 15.0

SwiftUI를 사용하기로 결정한 뒤에 또 정해야 할 내용은 iOS 타겟이었습니다.

SwiftUI 는 iOS 13부터 지원하였는데요. 주변에 SwiftUI 를 이미 사용하고 있는 개발자들에게 문의하였을 때 최소 15.0 을 해야 SwiftUI 의 기능들을 사용하는데 부담없고 안정적으로 사용할 수 있다고 하더라고요.

최소 14.5 이고 권장은 15.0 으로 이야기해준 iOS 개발자 분(GREEN)도 계셨습니다.

15.0 으로 되면 좋겠다는 생각으로 CTO 분과 회의를 하였고 이렇게 결정하게 되었습니다.

아키텍처

TCA 를 많이 사용한다는 이야기를 들었습니다. 스터디하면서 사용해보고 싶었는데 개발 일정과 SwiftUI도 처음 사용하는 상황이라 TCA 까지 도입하면서 프로젝트를 진행하기는 힘들 것이라는 판단을 내렸습니다. SwiftUI 자체가 State 와 뷰가 바인딩되는 형태이므로 MVVM 과 같은 효과를 낼 수 있었고 하나의 화면에서도 뷰를 여러 개로 나눠서 구성할 수 있는 점들도 구조적으로 좋은 방식으로 개발할 수 있었습니다.

예를 들어 이전 UIKit 에서는 하나의 뷰컨트롤러에서 다른 화면으로 전환될 때 데이터를 보내줘야 하고 서로 얽혀있는 형태가 많았습니다. SwiftUI 에서는 State 와 Binding 형태로 데이터를 전달하면 안정적으로 데이터를 사용할 수 있었습니다. 이전에는 뷰컨트롤러에서 이 화면에 필요한 모든 API를 호출하는 식이었는데 SwiftUI 에서 하나의 화면에서 여러개의 뷰를 선언하고 각각의 뷰에서만 사용하는 API라면 그 뷰 안에서 호출하여 데이터를 사용할 수 있었습니다.

웹뷰, 네이티브 비율

기존에 저희 페이워치 앱은 하이브리드 앱이었고 90% 가량은 웹이었습니다. 사용성을 높이고 안정적으로 개선하기 위해 리뉴얼 버전은 네이티브로 개발을 하였는데요. 그래도 모든 화면을 네이티브로 가면 기간도 오래 걸리고 앱 업데이트 없이 바뀌어야 할 화면들의 경우에는 웹으로 가야했습니다.

이러한 비율을 결정하는데 3가지 방식이 있었습니다. 

 

- 웹뷰로 가능한 화면은 최대한 웹뷰

- 웹뷰로 이미 있는 화면은 최대한 웹뷰 사용, 새로 그려야 할 화면은 네이티브

- 네이티브로 최대한, 웹뷰로 갈 수 밖에 없는 화면만 웹뷰

 

저희는 사용성 개선이 최우선이었기 때문에 네이티브로 최대한 가는 마지막 방식으로 결정하였습니다.

 

크게 이렇게 4가지 고민하고 프로젝트를 시작하게 되었습니다.

 

기획(2022년 12월 ~ 2023년 2월)

기획 리뷰에 참여하고 의견을 낼 수 있는 점들은 좋았습니다. 다만 계속해서 기획은 바뀌었고 기획에 없는 내용은 QA 분이 자신의 입 맛대로 원하는대로 개발을 해달라고 하셨습니다. 

기획대로 개발을 했는데 QA 분이 버그라고 이야기하는 경우도 많았고 그러면 기획자와 이야기하지 않고 수정해야 했습니다.

기획에 공백이 있었고 그 부분은 기획자와 개발자가 티키타카하면서 채워나가는 방식이 좋을 거라고 생각합니다.

이 서비스를 잘 아는 QA 분이 계시지만 그 분이 중간에서 자신이 이해할 수 있는 것만 소통해주고 개발자들이 직접 기획자와 이야기하는 것은 막는 느낌을 받아서 아쉬웠습니다...

개발(2022년 12월 ~ 2023년 5월)

개발 일정이 위에서 픽스된 상태로 내려왔습니다. 처음에는 3월 말까지 개발이 내려왔는데 일정이 너무 힘든 상태였습니다. 다행히 개발팀 상황을 봐주셔서 5월 15일로 일정이 픽스되었습니다. 조금 타이트하긴 했는데 안드로이드 개발자 분이 먼저 API 정리 등을 해주셔서 조금 무리한 일정으로 완료할 수 있었습니다. 같이 일하는 개발자 분도 이야기했는데 코더가 된 느낌으로 빠르게 기능들을 찍어내서 리뉴얼을 완료할 수 있었습니다. 일정이 위에서 아래로 내려오는 식으로 진행되서 아쉬웠습니다.

 

회고

좋았던 점

기술 스택을 개발자가 원하는 대로 제안할 수 있었고 그게 받아들여진 점들은 좋았습니다. 특히 SwiftUI 는 책으로 스터디 정도만 한 상황이었는데 실무에서 사용할 수 있는 기회를 가져서 좋았습니다. SwiftUI 에 익숙해질 수 있었고 SwiftUI를 사용하며 생산성이 많이 올라가는 경험을 했습니다. 백엔드 개발자, 프론트앤드 개발자, 안드로이드 개발자 분들과 협업하여서 iOS에만 집중할 수 있었던 점도 최고였습니다.

힘들었던 점

개발 일정이 개발팀 상황은 물어보지 않고 위에서 내려오는 방식은 아쉬웠습니다. 특히 3월말까지 개발이 완료되어야 한다는 일정에서는 2월에 기획이 완료되었는데 한달만에 앱을 완성해야 하는 상황이었어서 스트레스를 받았습니다. 다행히 향 후 새로운 일정이 내려오긴 했지만 개발에 대한 관심이 없고 어떻게 개발팀이 돌아가는지 몰라서 우선 최소한의 일정을 찔러보고 두번째 또 찔러본 느낌으로 내려온 일정은 개발자 입장에서 많이 아쉬웠습니다. 또한 기획대로 개발을 하였는데 기획에 없는 내용이나 기획에 있던 내용이더라도 QA 분의 기준에 안 맞는다고 생각하는 것들은 이슈로 등록되어서 개발자가 잘못한 식으로 논의되는 점들은 최악이었습니다. 기획팀의 역량이 좋은 회사로 가고 싶다는 생각이 들었습니다.

참고

https://green1229.tistory.com/259

새로운 앱을 만들기 위한 기술스택 선정하기