앱서비스를 개발하다보면 많은 사용자의 다양한 상황에 따라 생각지도 못했던 voc 이슈들을 많이 만나게 된다. 여러 voc 이슈들 중
사용자 fault(문자가 안보내져요<-요금문제, 앱이 스토어에 안보여요<-안드로이드 4.0 디바이스... 등등) 들을 걸러내며 앱에서 개선할 수 있는 사항들을 찾아 업데이트하면서 우리 서비스의 가치를 증진시킬 때 내가 이 서비스에 제대로 기여함을 느낄 수 있었다.
1. 문제 인식
운영에서 사용자가 배송 상세화면에 들어갔을 때 특히 랙이 걸린다는 이슈를 전달받았다. 보통은 앱이 랙걸린다는 이슈가 들어오면 네트워크 환경 문제인 경우가 대부분이었지만, 이번 이슈는 특정 부분을 직접 언급했고 사용자들이 자주 진입하는 구간의 문제라 앱을 돌려보는 것과 함께 소스코드를 확인하며 시간을 투자했다.
2. 문제 분석
배송 상세 화면에 진입하면서 여러 api를 호출하는 구간을 확인했고, 그 호출이 모두 정상 응답을 받을 때까지 로딩바가 사용자 UI를 막는 방식으로 구현되어 있었다.
여기서 가장 큰 리소스를 잡아먹는 구간이 배송 필수요소 검증 api 였다.(3개의 api 한꺼번에 호출하여 모든 응답값을 받아야 완료)
배송 필수요소는 배송 상세 화면에 출력할 데이터가 아니라 다음 프로세스가 어떤 프로세스인지 미리 데이터를 호출하는 케이스였고 여러 네트워크 통신이 사용성을 저해하는 요소로 작용할 수 있음을 확인했다.
배송 오더 리스트의 상세화면으로 진입했을 경우
: 로그에서 확인할 수 있듯이 약 0.6 ~ 0.8초의 대기시간이 소요되었다. (개인적으로 더 실험해본 결과 0.5~1.4초까지 확인할 수 있었고, 네트워크 환경이 일정하지 않을수록 더 큰 편차가 있을 것이라 예상할 수 있음)
개발 시점에는 아주 안정적인 네트워크 환경에서 1초 미만의 대기 시간으로 문제 인식조차 하지 못했다. 그러나 실제 사용자의 환경에 따라 답답한 사용성을 가진 앱으로 느끼게 만드는 요소가 된 것이다.
3. 문제 해결
배송 필수 요소 검증 api 를 LoadingBar 출력 로직에서 제외했다. 배송 필수 요소 데이터 호출이 끝나지 않았을 때 해당 데이터가 필요한 경우만 다시 시도를 요청하며 사용자 편의를 중심으로 UI를 block 시키는 상황을 최대한 줄이도록 변경했다.(UX팀과 논의 후 결정함)
또한 해당 데이터가 input 되는 시점에 앱의 화면이 변경되는 경우도 안정적으로 input을 무시하는 것을 확인했다. ViewModel의 State를 변경하고 그 변경된 State를 기준으로 화면이 subscribe하고 반영하는 구조여서 당연히 해당 화면이 없으면 무시할 것이라 예상했지만, 혹시 모를 상황을 대비하여 또 검증!
로드 속도 개선 후 상세화면 진입
대략 0.2 ~ 0.4초의 대기시간으로 상세화면 진입이 완료됨을 확인할 수 있었다.
4. 결론
새로운 프로젝트를 진행하고, 새로운 기능을 추가하고, 회사의 비즈니스를 수행하기 위한 다양한 개발들을 자연스럽게 하게 된다. 이런 업무들은 당연하게 해야하는 업무이고 점점 상향평준화가 되고있다. (다들 너무 잘하셔서...) 경쟁력있는 개발자가 되기 위해 기술적으로 deep하게 파고 들어 전문성을 준비하는 것도 계속해서 노력해야겠지만, 본인이 만드는 서비스의 가치를 높이기 위한 방법을 고민하며 개발할 때, 주도적으로 일하는 개발자가 더 경쟁력있는 개발자가 되지 않을까?
이후로 상세화면 진입 이슈는 들어오지 않고 있다 ㅎㅎㅎ
