앱 마이그레이션 프로젝트 회고 (2) - 목표, 계획

 

목표

물론 최종적인 목표는 좋은 앱을 좋은 과정을 통해 만들고, 유지보수하기 용이한 서비스를 통해 서비스 품질을 높이고 좋은 고객 반응을 이끌어내는 것이다. 이러한 결과물을 위해 몇 가지 구체적인 사항들을 정한 후 프로젝트를 진행하였다.

1. 전반적인 앱 기능의 변경 및 정리
2. 통계기반 의사결정
3. 서버와 앱 사이의 결합 줄이기
4. TDD
5. 애자일 스크럼

전반적인 앱 기능의 변경 및 정리

해당 프로젝트는 2017년 최초 출시되었으며 2019년도에 마이그레이션 되어 2023년까지 운영 중이었다. 운영을 하며 수 많은 기능들의 추가되었으나 한번 추가된 기능은 효용성과 상관없이 거의 사라지지 않았다. 구글 아날리틱스를 통해 확인한 결과 많은 기능들의 사용률이 거의 없는 수준이었으며 특정 기능은 심각한 오류가 있었으나 사용자가 없어 방치되기도 하였다. 필수적이지 않으며 사용자도 거의 없는 기능을 개발하기 위해 핵심 기능에 소홀해지거나 일정이 늦춰지는 것은 굉장히 비효율적이라고 생각하였다.

기술스택을 이전하기에 어짜피 앱은 처음부터 개발을 진행해야 한다. 이렇게 앱을 처음부터 개발할 수 있는 기회는 흔치 않으며 이런 기회를 단순히 기술이전으로 끝내는 것보다는 전반적인 개선의 기회로 살리고 싶었다. 그러기 위해 우선 기능들의 분류부터 시작했다. 기능의 중요도, 실제 사용률, 개발공수(일정 대비 난이도) 이렇게 3가지 기준을 둔 뒤 점수를 매겨 개발전략을 만들었다.

 

	중요함	중요하지 않음
많이 사용함	개선, 공수가 높으면 유지	유지, 공수가 낮으면 개선
사용자가 어느정도 있음	개선	유지, 공수가 높으면 폐기
사용하지 않음	재설계	폐기

우선 기능의 중요도를 가장 핵심적인 기준으로 둔 뒤 사용률과 개발공수를 추가하여 해당 기능에 대한 전략을 수립하였다. 기능의 중요도는 기능적인 중요도와 전략적인 중요도 이렇게 2가지의 기준을 통해 선정하였다. 기능적 중요도가 높은 기능은 로그인, 포인트 충전, 바코드 출력 등이 있으며 전략적 중요도가 높은 기능은 홍보물품 표시 영역, 특정 방식의 포인트 충전 등이 있었다.

개발공수의 경우는 프로젝트가 진행되어 가여 일부 조정이 진행되기도 하였다. 외부의 개입, 재설계 과정에서 기능추가로 인한 난이도 상승, 미처 생각하지 못한 부분까지 개발을 진행해야 하는 경우 등 공수가 변경되는 일이 생길 시 부분적으로 조정하였다. 물론 어디까지마 부분적인 조정이며 변동이 생길 가능성이 높은 경우는 변동 가능성을 일부 관리하긴 하였다.

위와 같은 기준을 통해 프로젝트의 전반적인 방향성을 수립하였다. 또한 프로젝트가 진행되며 외부적인 요인으로 인해 일정이 변경되거나 기능들이 추가되는 상황들이 발생해도 기준과 우선순위가 있으니 비교적 안정적으로 프로젝트를 이끌어나갈 수 있었다.

 

통계기반 의사결정

앱을 계획하고 개발하는데 있어 통계적인 부분들을 더 많이 반영하도록 하였다. 위에서 언급한 기능정리도 이러한 통계기반 의사결정의 하나의 예시이며 사용자들의 특성부터 시작하여 기존의 기능들을 어떤 방식으로 사용하고 있는지를 확인하였다.

몇 가지 사례를 들자면 우선 자동로그인의 유지기간이 있었다. 자동로그인 방식을 변경하며 보안을 위해 일정기간 후 자동로그인을 해제하도록 하였다. 이를 위해 사용자들의 최종 로그인 일시 정보를 확인하여 일반적인 사용자들이 어느 정도 기간 내에 다시 로그인을 하는지 확인한 후 해당 정보를 기반으로 자동로그인 토큰의 만료기간을 설정하였다. 실제로 설정된 만료기간은 다른 앱에서 설정된 만료기간과 거의 일치하였으나 해당 수치가 나온 이유를 정확하게 알 수 있게 되었으며 추후 특수한 정책이 필요한 상황에서도 확실한 근거에 의거한 값을 설정할 수 있을 것이라고 생각한다.

또한 사용자의 특성을 고려한 UI 방향성을 설정하였다. 내가 개발하는 앱은 멤버쉽에 가입한 사람들이 사용하는 앱이기에 불특정 다수가 아닌 특정한 다수의 사용자를 대상으로 하였다. 이 특정한 다수의 가장 큰 특징은 나이가 많다는 것이었다.대다수의 사용자가 50대 이상이었으며 가장 주목한 특성은 노안이었다. 이렇게 특정을 하니 이전 민원 문서를 통해 전달되는 스크린샷의 UI가 깨져있던 부분들이 생각났다. 스마트폰에서는 사용자가 기본 폰트 크기를 조정할 수 있으며 노안으로 인해 불편함을 겪는 사용자들은 기본폰트를 증가시킨다. 이러한 상황을 예상하지 못하고 설계된 UI는 예상치 못한 글자크기 증가로 인해 UI 배치가 엉키거나 텍스트가 잘려나가는 등 문제를 만들어내고 있었다. 이를 위해 우선 UI에 따라 글자크기 상한의 한계점을 설정하였다. 폰트크기 증가는 비율을 통해 증가하기 때문에 이미 큰 글자들(타이틀 영역과 같은)은 필요 이상으로 더 커지는 상황이 발생한다. 따라서 이러한 UI의 상위 특성으로 대략적인 용도를 설정한 뒤 용도 별 크기 상한 옵션을 설정하였다. 그다음으로는그리드 형태의 UI를 최소화 하였다. 폰트 크기 증가 시 좌우폭이 고정된 그리드 스타일의 UI는 깨짐 현상이 더 심했다. 따라서 그리드 영역은 글자수가 적은 사항 즉, 깨질 위험이 낮은 곳에서만 사용하고 위험이 있다면 되도록 리스트 중심의 UI를 사용하였다. 앱을 만들면서도 테스트 기기의 기본 폰트를 증가시킨 후 확인해 보며 크게 문제가 되는 부분이 있는지 확인하였다.

서버와 앱 사이의 결합 줄이기

개발을 진행하며 서버/앱 사이의 결합도를 낮추는 것에 집중하였다. 기존 앱파트 코드의 가독성이나 문서화 작업은 어느정도 정리되어 있었지만 서버와 앱 프로세스 사이의 결합도가 지나치게 높다는 문제점이 있었다. 정확히는 앱의 특정 UI와 프로세스에 딱 맞추어 서버 API가 구성되어 있어 앱/서버 어느 한쪽의 수정사항이 생길 시 양쪽 모두 수정해야 하는 일들이 발생하였으며 다른 도메인에서 유사한 기능을 개발할 때 해당 API를 재사용하기 힘든 상황이 발생하였다. 이를 위에 서버 쪽 코드를 전반적으로 리펙토링 하였으며 제공하는 API는 앱에서 사용하는 방법 집중하는 것이 아닌 해당 서비스가 일반적으로 가져야 하는 절차와 방식에 맞춰 개발하였다. 이로 인해 앱에서 해당 API를 가공하는 프로세스가 추가되었지만 더 넓은 관점에서 앱 혹은 서버의 변경사항 발생 시 해당 영역에만 집중하여 개발할 수 있도록 하며 API의 재사용성을 높이는 사항이었다.

TDD

앱을 처음부터 개발하는 기회는 흔치 않다. 특히나 해당 앱을 개발한 뒤 최소 몇년간은 해당 코드베이스를 사용하여 개발을 진행해야 할 것이기에 개발 단계에서 탄탄하게 쌓아 올리고 싶었다. 기존에 개발된 프로젝트를 TDD로 바꾸는 것은 생각보다 훨씬 어렵기에 이렇게 처음부터 개발하는 단계에서 TDD를 적용하여 완성도 높은 개발 산출물을 만들고 싶었다

우선 TDD의 진행을 위해 TDD 방법론에 대한 선행학습을 개인적으로 진행하였으며 해당 내용을 팀원들에게 설명하고 함께 학습하는 자리를 가졌다. 또한 TDD 방법론 적용에따라 기획파트에 설명하여 프로젝트 초기 개발속도가 다소 늦을 수 있음을 설명하고, 그럼에도 불구하고 이를 적용해야 하는 이유를 설명하였다. TDD는 빠른 개발속도를 보장하는 방법론이 아니며 개발완성도에 대한 시각은 직군에 따라 차이가 있을 수 있기에 사전에 협의를 해야 한다고 생각하였다.

애자일 스크럼

개발/기획자/디자이너 사이의 회의는 비정기적으로, 해당 기능을 담당하는 사람들끼리만 진행하였다. 소통비용을 줄이고 각자 업무를 진행하는 시간을 늘리기 위함이였지만 이는 오히려 소통비용의 증가로 이어졌다. 개발 담당범위가 다르다고 하여도 같은 영역의 개발을 진행하는 일들이 많이 있었으며 정확하게 담당을 정하기 힘든 기능들도 있었다. 이 경우 서로의 개발 진척사항을 구분하고 업무를 분장하기 위해 다시 시간을 내어 소통을 해야 하는 일들이 있었으며 명확한 회의시간이 없으니 각자 소통이 필요하다고 생각될 때 급하게 연락을 하고 소통하거나 회의 일정을 잡을 때가 있었다. 이런 비정기적인 소통은 업무 집중을 방해하였다.

이를 개선하고자 정해진 시간에 짧은 회의를 통해 서로의 업무계획 및 진척사항을 공유하고 추기적으로 소통이 필요하다고 생각하는 것들을 말하였다. 초기에는 월요일/금요일에 각각 30분 정도 씩 주간 계획/회고 회의를 진행하였으며 나중에는 진행상황에 따라 회의 시간을 조정하거나 2주 단위로 운영하였다.

 

 

https://bowonlee412.tistory.com/37

앱 마이그레이션 프로젝트 회고 (1) - 이유