안녕하세요 리멤버 앱팀의 안드로이드 개발자 김평호 입니다.
리멤버에서 명함 관리 이외에도 채용, 커뮤니티 등 비즈니스에 도움이 되는 여러 서비스를 제공하고 있습니다. 오늘 글에서는 그중 “리멤버 나우”라는 서비스에 대해 안드로이드 위젯을 개발한 경험에 대해 공유해 보고자 합니다. 더불어 앱 팀에서는 어떤 프로세스로 개발을 진행 하는지에 대해서도 다뤄볼 예정입니다.
- 이 글에서는 다음 내용을 다루고 있습니다.
- 리멤버 나우 위젯의 개발 시작부터 배포 되는 과정
- 간단하게 위젯을 만드는 방법
리멤버 나우
위젯 개발에 대한 내용을 하기 앞서, 리멤버 나우가 어떤 서비스 인지 모를 분들을 위해 간단히 소개해 드리겠습니다. 리멤버 나우는 매일 아침 국내 최고 전문가들이 정리한 데일리 경제/경영 컨텐츠를 제공하는 서비스입니다. 리멤버 나우는 웹 사이트(https://now.rememberapp.co.kr)로 제공되고 리멤버 앱에서도 바로 접근할 수 있습니다
1. 기능 개발의 필요성
- 나우 운영팀에서 현재 진입 보다 더 빠르게 접근 할 수 있는 진입점을 만들어 보자는 의견이 나왔고 회의를 통해서 리멤버 나우 위젯을 만들기로 결정했습니다.
- 회의에서 논의된 내용을 기반으로 기획자 분이 컨플루언스에 기획서를 정리해주셨고 기획 리뷰 시간을 통해 기획서를 함께 검토했습니다. 기획 내용을 요약하면 아래와 같습니다.
- 안드로이드 나우 위젯을 개발한다.
- 최신 글 10개를 리스트로 보여 준다.
- 아이템을 클릭하면 리멤버 앱이 실행 되며 클릭한 글을 보여 준다.
- 글은 웹뷰를 통해 보여준다.
- 위젯을 통하여 webview 를 실행할 때는 해당 경로로 실행하는 사람들의 수를 확인하기 위해 특정 쿼리 파라미터를 함께 넘겨준다.
2. 개발 진행
- 안드로이드 파트 논의
- 개발에 앞서 기본적인 내용을 확인후에 개발 방법에 대한 내용을 파트원과 협의를 진행 합니다. 기존의 방법으로 개발 할때는 상관 없지만 다른 방법으로 진행 할때는 협의를 통해 결정을 하고 있습니다. 이번 협의 내용은 개발 방법에 대한 내용이었습니다. 나우 위젯 생성 작업을 진행 하려고 기존 레거시 코드를 활용해 보려고 했지만 기존의 방법보다는 앞으로 리멤버 앱 개발 방법 선택에 도움이 되도록 새로운 방법을 시도 하기로 했습니다. 기존 리멤버 앱은 클린아키텍처와 MVP의 아키텍처 방법에 비동기는 RxJava1을 이용하고 있습니다. 나우 위젯을 개발할 땐 앞으로 리멤버 앱 개발 방법 선택에 도움이 될 수 있도록 새로운 방법을 시도해보기로 했습니다. 논의 결과 데이터 소스와 View만 분리하는 아키텍처와 코루틴을 이용해보기로 결정했습니다. 설계 방법에서 기존 방법을 적용하기에 앱 위젯은 일반적인 형태가 아니었고 기존 리멤버 앱과 완전히 분리 해서 생각 해도 될거라 생각해서 약간의 변경 방법으로 개발을 진행 한다고 했습니다. 그리고 위젯 프로바이더(RemoteViewsServices.RemoteViewsFactory)가 프리젠터의 기능을 대신 할 수 있을거라 생각 했습니다. 그래서 완벽한 패턴을 지키는게 아니라 어느정도 타협한 형태로 개발을 진행 하기로 했습니다. 그리고 비동기 시스템은 Rx 가 아니라 코루틴을 선택 한 이유는 테스트 성향이 많았습니다. 현재 사용중인 Rx 는 버전 1을 사용하고 있고 이를 버전 3으로 업데이트 시킬지 코루틴을 사용할지 아니면 버전 1을 계속 사용 할지 아직 정하지 못 했습니다. 그래서 코루틴도 실 서비스에 적용해 보고 결과를 공유하면 비동기 시스템 선택 할 때 도움이 될거라 판단했습니다. 이런 내용을 팀원과 협의 해서 결정 하게 되었습니다.
- 개발에 앞서 기본적인 내용을 확인후에 개발 방법에 대한 내용을 파트원과 협의를 진행 합니다. 기존의 방법으로 개발 할때는 상관 없지만 다른 방법으로 진행 할때는 협의를 통해 결정을 하고 있습니다. 이번 협의 내용은 개발 방법에 대한 내용이었습니다. 나우 위젯 생성 작업을 진행 하려고 기존 레거시 코드를 활용해 보려고 했지만 기존의 방법보다는 앞으로 리멤버 앱 개발 방법 선택에 도움이 되도록 새로운 방법을 시도 하기로 했습니다. 기존 리멤버 앱은 클린아키텍처와 MVP의 아키텍처 방법에 비동기는 RxJava1을 이용하고 있습니다. 나우 위젯을 개발할 땐 앞으로 리멤버 앱 개발 방법 선택에 도움이 될 수 있도록 새로운 방법을 시도해보기로 했습니다. 논의 결과 데이터 소스와 View만 분리하는 아키텍처와 코루틴을 이용해보기로 결정했습니다. 설계 방법에서 기존 방법을 적용하기에 앱 위젯은 일반적인 형태가 아니었고 기존 리멤버 앱과 완전히 분리 해서 생각 해도 될거라 생각해서 약간의 변경 방법으로 개발을 진행 한다고 했습니다. 그리고 위젯 프로바이더(RemoteViewsServices.RemoteViewsFactory)가 프리젠터의 기능을 대신 할 수 있을거라 생각 했습니다. 그래서 완벽한 패턴을 지키는게 아니라 어느정도 타협한 형태로 개발을 진행 하기로 했습니다. 그리고 비동기 시스템은 Rx 가 아니라 코루틴을 선택 한 이유는 테스트 성향이 많았습니다. 현재 사용중인 Rx 는 버전 1을 사용하고 있고 이를 버전 3으로 업데이트 시킬지 코루틴을 사용할지 아니면 버전 1을 계속 사용 할지 아직 정하지 못 했습니다. 그래서 코루틴도 실 서비스에 적용해 보고 결과를 공유하면 비동기 시스템 선택 할 때 도움이 될거라 판단했습니다. 이런 내용을 팀원과 협의 해서 결정 하게 되었습니다.
- 개발 방법 선택
- 안드로이드 앱 팀에서는 개발방법 일원화를 위해서 노력 하고 있습니다. 이는 기본적인 협업 문서를 통해서 진행을 하고 있습니다. 그리고 안드로이드 스튜디오를 최대한 이용하고 있습니다. 안드로이드 위젯 개발 방법 역시 다양한 방법으로 할 수 있지만 일원화하기 가장 편한 방법으로 스튜디오 자동 생성 기능을 이용하기로 했습니다. 잠시 위젯 개발 방법에 대해서 내용을 작성해 보겠습니다.
- 안드로이드 앱 팀에서는 개발방법 일원화를 위해서 노력 하고 있습니다. 이는 기본적인 협업 문서를 통해서 진행을 하고 있습니다. 그리고 안드로이드 스튜디오를 최대한 이용하고 있습니다. 안드로이드 위젯 개발 방법 역시 다양한 방법으로 할 수 있지만 일원화하기 가장 편한 방법으로 스튜디오 자동 생성 기능을 이용하기로 했습니다. 잠시 위젯 개발 방법에 대해서 내용을 작성해 보겠습니다.
안드로이드 스튜디오를 이용한 위젯 추가 방법 입니다. 우선 프로젝트의 영역의 포커스를 아래처럼 app 이 선택 되도록 합니다
포커스를 확인후 스튜디오의 메뉴를 클릭합니다. file -> new -> Widget -> App Widget 을 선택 하면 아래와 같은 팝업이 나옵니다. 원하는 값 등을 설정하고 finish 하면 기본적인 설정이 끝납니다.
완료가 되면 아래 처럼 파일 생성되거나 필요한 곳이 수정이 됩니다.
이렇게 하면 기본적인 개발이 완료 되었습니다. 앱을 실행하고 위젯을 확인 해 보면 아래 처럼 위젯이 추가 되었습니다. 안드로이드 스튜디오를 이용하면 매우 쉽게 완료가 됩니다.
앱 위젯에 리스트 추가 및 주의 할 점
- 앱 위젯의 리스트에는 RemoteViewsService, RemoteViewsService.RemoteViewsFactory AppWidgetProvider이 필요합니다. 이런 내용들은 샘플과 함께 안드로이드 개발 문서 에 잘 나와 있습니다.
- 참고로 위젯을 개발하면서 주의 할점 RemoteViews 가 모든걸 지원 하지 않습니다. 예를 들어 ConstraintLayout 와 같은 View 는 사용할 수 일반적으로 많이 쓰는 View 가 없으니 유념해서 보셔야 합니다. 그리고 안드로이드 개발을 진행 하면서 https://developer.android.com/ 문서들을 보면서 진행 하는게 좋다고 생각하고 있습니다. 안드로이드 개발에 있어서 안드로이드 개발문서 + 안드로이드 스튜디오 는 매우 좋은 참고서라고 생각합니다.
3. 검수진행
- 개발이 완료 되면 검수를 진행 하게 됩니다. 검수는 기획, 디자인, QA 총 3개가 있습니다.
- 검수 용 apk 를 각 팀에 전달 해야 합니다. 이는 github actions 를 이용하고 있으며 해당 빌드를 만들기 위해서 TAG 만 추가해 주면 됩니다. 빌드가 완료되면 슬랙으로 아래와 같이 알림이 발생합니다. 해당 쓰레드에 담당자를 멘션 해주면 됩니다.
- 검수가 진행 되는 동안 이슈가 발생되면 Jira 에 이슈가 등록되고 개발자는 이를 확인해서 처리하는 방법으로 하고 있습니다.
4. PR 리뷰
- 너무 당연하지만 검수 끝난 버전이 develop 에 merge 하기 위해서 PR을 생성하고 다른 팀원의 코드 리뷰가 끝나야 합니다.
- 리멤버 안드로이드 파트 만의 시스템 “PR 보드” 입니다. 안드로이드 파트에서는 PR 보기 편하게 작게 만드는걸 목표로 하고 있습니다. 이는 갯수가 너무 늘어나는 단점도 있습니다. 특정 기능의 경우 PR이 10개가 넘을수도 있습니다. 여러명이 많은 PR 을 생성하다 보니 확인이 어려워 지는 경우가 많아졌습니다. 그래서 아래와 같이 github 보드를 이용해서 생성한 PR에 대해서 카드를 만들고 리뷰어에게 카드를 전달해 주면 해당 카드를 보고 자신이 해야 하는 PR 을 확인 할 수있습니다. 리뷰가 진행되어 의견이 있으면 해당 카드를 담당자에게 다시 옮겨서 확인 할 수 있도록 해주는 방법을 사용하고 있습니다.
5. 배포
- 리멤버 안에 여러 서비스가 있고 각각의 크루로 나누어져서 일을 진행 하기 때문에 배포일을 맞췄습니다. 이를 “버스” 라는 용어로 사용합니다. 화요일 릴리즈를 위해서 각자 기능 브랜치에서 개발하던 걸 QA 마치고 금요일 까지 릴리즈 브랜치에 merge 합니다. 그리고 통합 테스트를 위한 버전을 생성해서 QA팀에 전달 합니다.
- 통합 버전 테스트가 완료 되면 배포용 빌드를 시작 합니다. 배포 빌드 역시 TAG 를 추가하면 자동으로 번들과 apk 가 생성되어 Slack으로 공유 됩니다.
- 해당 빌드를 이용해서 실서버 최종 테스트 이후 QA 팀에서 출시를 합니다.
6. 배포 후 지표 확인 및 학습
- 배포가 되었다고 끝이 아닙니다. 해당 개발에 대한 데이터 지표를 확인하고 있습니다. 다른 회사 분들과 대화 할 때 성과를 측정해서 상벌을 하기 위한 내용이 아닌지 궁금해 합니다. 데이터 지표를 확인 하는 이유는 성과를 측정하는 내용은 맞습니다. 하지만 상벌을 하기 위해서가 아닙니다. 과거의 자료는 미래의 기능 선택 할 시점에 도움을 줄 수 있기 때문입니다.
- 예를 들어 리멤버 나우 위젯의 경우에도 지표의 엄청난 성장을 보여주지 못했습니다. 하지만 이는 사용자들이 안드로이드 위젯의 사용은 제한적으로 사용하는걸 알게 되었고 이를 다음 기획 할때는 데이터를 반영 합니다. 동일한 실패를 반복 하지 않게 하기 위해서 입니다.
- 위젯을 개발 하면서 코루틴을 사용했던 경험, 기존에 개발 방법이 아닌 간소화된 개발을 진행 했을때의 경험을 팀원들과 공유했습니다.
리멤버 나우 위젯 개발 후기
- 이글을 통해서 리멤버 앱팀이 기능 개발을 진행을 하는 프로세스에 대해서 알아 보았습니다. 제가 개발 프로세스에 대한 주제를 선택한 이유는 이직을 준비 하면서 가장 궁금 했기 때문 입니다. 다른 회사는 어떤 방법으로 개발 하고 어떻게 개발이 진행 되는지 이런 부분은 알수가 없어서 항상 두려움이 많았기 때문에 프로세스에 대한 내용이 있으면 도움이 것으로 생각하고 작성해 보았습니다. 처음으로 공적인 공간에 글을 작성하는 부담은 있었지만 @담형님의 도움으로 이렇게 마무리까지 할수 있었습니다.
- 드라마에서는 여러 포지션에서 채용을 진행하고 있으니 함께 개발해 보고 싶다고 생각되면 https://hello.remember.co.kr/recruit 링크를 클릭해서 지원해 주세요.
- 오랜 고민과 완벽한 전략 대신 빠르게 실행하고 학습해야 다음에는 고민을 줄어 들고 완벽한 전략을 만들수 있다고 생각하고 있습니다. 이번 리멤버 나우 위젯 개발을 통해서 빠른 실행으로 결과를 확인 했고 이는 다음번 개발에 많은 도움이 될거라 생각합니다.
- 그리고 아직 리멤버 나우를 안보시는 분들은 추가해서 유익한 뉴스레터를 받아보세요.
감사합니다.
검수 후 PR리뷰를 진행하시는데 PR리뷰를 통해 코드가 수정된다면 다시 검수하기를 진행하시나요?
안녕하세요 핫진님 감사합니다.
제가 경험 했던내용으로 답변 드리겠습니다.
– 담당자가 선택 하거나 PR을 요청한 사람이 검수 다시 진행을 요청하는 경우가 있었습니다.
– 하지만 재검수 진행 할 정도로 변화가 있는 PR은 많이 없었습니다. 개발을 시작 할 시점에 기본적인 개발 방법이 공유되고 또 새로운운 방법의 경우 협의를 통해서 결정 했기때문이라고 생각합니다.