포카마켓 iOS 팀의 여정 (디버깅 및 검수) - EP02

안녕하세요

포카마켓 iOS 팀에서 개발을하고 있는 WooKoo 입니다.

 

지금까지 포카마켓의 iOS 팀에서 어떤 식으로 디버깅 및 검수 QA 등을 진행하는지 이야기를 들려 드리고자합니다.

이번 포스팅에서는 디버깅이란 단순히 버그를 수정해나아가는 과정을 넘어서, 문제를 조금 더 쉽게 발견하고, 잠재적인 이슈를 트래킹 할 수 있는 방법 등을 이야기 해보고자 합니다. 

 

1. LookIn

 LookIn 이란 View 의 계층과 상태들을 요구사항과 맞는지 빠르게 확인 할 수 있는 중국산(?) 도구입니다. 개발 타겟의 앱에서 쉽게 UI 를 디자이너분들이 확인(간격, 크기 등) 할 수 있는 도구들은 없을까 고민하던 중에 발견했습니다.

https://lookin.work/

https://lookin.work/

사용 방법은 쉬운데 보통 구현 후 시뮬레이터의 뷰 계층구조나 뷰들의 간격 등은 어떻게 검수하시나요?

혹시 Xcode 의 view hierarchy 을 사용하시지 않나요?

lookin 이라는 도구는 view hierarchy 를 xcode 의 퍼즈 없이 구조를 확인 할 수 있도록 시뮬레이터에 연결하여 이를 확인 할 수 있는 도구입니다. 

view hierarchy 은 퍼즈뿐만아니라 속도 자체도 느린데 이는 사용해보시면 놀라운 경험을 해보실 것이라 추천드립니다. 

 

 

2. pulse logging

proxy 를 이용하여 앱에서 주고 받은 rest api 들의 요청과 응답을 확인 할 수 있는 도구입니다. 옛날에는 netfox 라는 도구를 사용했었는데 둘 다 사용해봤지만 pulse 가 조금 더 좋았던 것 같습니다. 이는 iOS 팀 뿐만아니라 타 팀들도 테스트 시 사용 할 수 있고, 특히 개발을 조금 아시는 기획자분이나 디자이너분들도 해당 도구에서 api 가 404로 실패 혹은 서버에서 다른 응답이 온다. 등 오류 해결에 많은 생산성을 올려주는 도구입니다. 특히 응답 보려면 코드 찾아서 브레이크 걸고 lldb 로 찍어보고 그래야하는데 한번 붙여놓으면 조직의 생산성이 확 올라가는 것을 느껴보실 수 있을 것입니다. 

 

저희 팀은 개발 타겟에서 흔들기 제스처를 붙여 둔 뒤 최상단 뷰에 Present 되도록 해두었습니다. 그러면 어떤 화면에서도 휴대폰을 살짝 흔들면 pulse 도구가 나타나게 됩니다. (시뮬레이터에서도 shake 기능을 찾아보면 할 수 있습니다.)

https://github.com/kean/Pulse

GitHub - kean/Pulse: Network logger for Apple platforms

 

 

3. 메서드 스위즐링을 이용한 메모리 누수 탐지

메모리 누수는 다양한 방법으로 나타나지만 가장 대표적인 부분이 화면이 사라져도 참조 카운트가 살아있어서, ViewController 가 deinit 되지않는 현상들 같습니다. 이를 잡기 위해서 이 또한 디버그 모드에서 viewDidAppear 시 메모리가 살아있는지를 확인해야합니다.

  public class func checkViewControllerMemoryReleased() {
    callAdditionalMethod(
      UIViewController.self,
      when: #selector(UIViewController.viewDidDisappear(_:)),
      call: #selector(UIViewController.__checkViewControllerMemoryReleased))
  }

 

@objc
  private func __checkViewControllerMemoryReleased() {
    if isMovingFromParent {
      let type = type(of: self)
      if [
        "UICompatibilityInputViewController",
        "UIPredictionViewController"
      ].contains("\(type)") {
        return
      }
      DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [weak self] in
        if self != nil {
          #if DEBUG
          debugPrint("⚠️ \(type) 메모리 해제 오류")
          #else
          Crashlytics.record(error: NSError(domain: "\(type) Memory Leak", code: -18))
          #endif
        }
      }
    }
  }

 

디버그 모드에서만 동작하고 밑에서 안내드릴 Firebase Crashtics 의 커스텀 이벤트 수집을 통해 어떤 ViewController 에서 릭이 나는지를 파악할 수 있습니다.

 

4. Firebase

파이어베이스의 crashtyics 는 앱의 크래시를 관리하는 가장 기본이다. 올라오는 크래시 이력을 보고 앱을 수정하는 일은 기본적인 일로서 논외하겠다. (물론 가장 중요한 일이다.)

안드로이드의 경우에는 자동으로 커스텀 이벤트를 수집해주는 것 같으나 iOS 는 그렇지않다. 3번에서 진행했던 메모리 누수에 커스텀 이벤트를 추가하여 유저들이 메모리 누수를 찾아주도록 작업을 해두는 방법이 있다.

 

또한 특정 에러케이스 혹은 레거시 로직이 과연 동작 할지, 제거해도 되는지 의심이 된다면 해당 기능을 활용해보면 좋다.

 

Remote Config 도 잘 활용하면 업데이트팝업이나 기능 플래그 등 다양하게 활용이 가능하다.

 

 

 

5. QA

앱을 출시하기 전에 저희 팀은 약 1~2 주 정도 QA 기간을 거치고 있습니다. 아직은 QA 팀이 있지는 않고 프로덕트팀 전체가 함께 테스트를 진행합니다. 기획자, 디자이너, PM 등 타 부서에게 QA 를 진행하기 전에 저희는 VAT 라는 빌드 수용 테스트를 개발자들이 진행합니다. 제품 출시에 큰 이상이 없는지 테스트를 진행하는 것이죠. 막무가내로 기능을 눌러보고 하는 것이 아니라 실제 QA 기간에 사용하는 TC/TS 를 기반으로 VAT 를 진행합니다. TC/TS 에는 테스트하는 퍼널 별로 유저들이 동작할 수 있는 대부분의 시나리오가 작성되어있으며 이를 기반으로 한 바퀴의 테스트를 거친 뒤 타 부서에게 QA 를 요청합니다. 이로써 타부서와 함께 QA 를 진행 할 때 기본적인 요구사항을 놓친 것은 없는지, 기본적인 오류를 왜 개발 기간에 작업하지 못했는지 등에 대한 최종 점검을 하는 체계를 만들었기 때문에 조금 더 원활하게 QA 를 진행 할 수 있습니다.

 

 

떠오르는 다섯가지 정도의 팀의 안정성을 위해 저희 팀이 진행하는 방법들을 이야기해 보았는데 도움이 되셨으면 좋겠습니다.

 

감사합니다.