만 2년의 개발 발자취 돌아보기

서울에 상경한 지 이제 거의 만 2년이 다 되어 갑니다.

처음 강남 사옥으로 출근해서 회사 라운지에서 커피를 마시며 강남의 야경을 감상하던 때가 엊그제 같은데, 이제는 상암 본사로 들어오고 1년이라는 시간이 지났습니다.
게다가 경산에서 아내와 아이들도 다 올라오고, 거처도 용인에서 파주로 옮겨 이제 정착이라는 단어를 쓸 수 있을만큼 저와 가족 모두 적응하게 되었네요. 돌이켜 보면 정말 짧은 시간동안 많은 변화가 있었네요.

이렇게 정신 없이 살다보니 작년에는 연말에 하던 한해 리뷰 조차 하지 못하고 넘어갔네요.
이제 2년이 다 되어가는 시점을 맞아 주요 업무들을 스스로 리뷰를 하며 피드백을 한번 해보려고 합니다.

Warming up

  2019.06 ~ 2019.10 이 때는 안드로이드 개발을 다시 시작하면서 감을 익혔던 때인 것 같다.

처음에는 VOC와 Crashlytics 오류 내역들을 분석해서 릴리즈를 주로하면서 도메인을 분석했고, 아래의 간단한 기능을 구현했다.

• Place 메뉴
  Place 메뉴는 구글 맵에 작성한 메모들을 작성위치 기반으로 보여주는 메뉴이다.
  여기에 Map 표시되어 있는 메모들을 작성일로 검색해서 marker 를 재표시하는 기능 추가.
• Timeline 메뉴
  Timeline 메뉴는 작성한 노트들을 시간 순으로 보여주는 메뉴로 Recycler View Item 을 long click 해서 삭제, 즐겨찾기 추가하는 기능 추가, long click. 시에 눌리는 듯한 애니메이션 추가
• 페이지 작성일자 변경 기능 추가
  Appbar의 Title 대신 페이지 작성일자를 변경할 수 있도록 버튼의 역할을 하는 View 를 추가하여 Appbar 를 Custom 함.
• 가로모드 및 테블릿 대응
    레거시는 세로모드 고정으로 개발되어 있었음. 이것을 가로모드 및 테블릿 해상도에 맞춰 사용성이 어느 정도는 나오도록 작업했다.
  특히, 가로/세로 화면이 회전하면서 데이터 및 콜백함수 및 listener가 복구되지 않는 문제 때문에 개고생했던 기억이 떠오른다.
    이 때 공식 가이드를 안 지키고(공식가이드에 onAttach()로 callback을 전달한다.), AAC의 ViewModel, onSaveInstanceState()의 DATA를 저장하는 메커니즘 처리가 잘 안되어 있으면 개고생한다는 걸 느끼며 최초 코드 작성자를 원망했던, 추억이 새록새록 떠오르네...
    Fragment에 콜백 및 listner 넘기면서 onAttach()가 아닌 set~() 형태로 생명 주기와 상관없이 막 set~() 으로 주입하던 레거시 코드였다.  공식 가이드를 안 지키고(공식가이드에 onAttach()로 callback을 전달한다.), AAC의 ViewModel, onSaveInstanceState()의 DATA를 저장하는 메커니즘 처리가 잘 안되어 있으면 개고생한다는 걸 느끼며 최초 코드 작성자를 원망했던...추억이 새록새록 떠오르네..

 

본격적인 활동

  이 때 함께 일하던 안드로이드 선임 분이 퇴사하면서 내가 안드로이드 메인 개발자가 되면서 본격적으로 개발을 빡세게 하게된다.
이 당시 레거시는 Activity 안에 View의 역할을 하는 코드, 도메인 로직, DB에서 Data를 읽어오는 로직 등 모든 것이 들어있었다.
이러한 기존 레거시를 막 뜯어 리펙토링을 할 수 있는 여건이 안되었기 때문에 조금이나마 개선 하고자 이 때부터 새로 추가되는 기능과 Dependecy가 생긱는 부분들에 Android Architecture 와 안드로이드 최신 개발 트렌드를 적용하기 시작했다.

• 오늘의 페이지 개발
  • MVVM 구조를 처음 적용
    dataBinding은 사용하지 않고, ViewModel에 LiveData를 만들고 Activity, Fragment 에서 Observe 하여 구현
  • ViewPager2 삽질
    양 옆의 카드 들의 일부가 보이도록 개발했어야 했는데, setPageTransformer()에서 offset을 이용하면 되는데 이를 잘 몰라서 ViewPager2를 다운 받아서 커스텀하여 완성했었다. 추후 커스텀한 ViewPage2는 모두 걷어내고 setPageTransformer()과 offset으로 구현했다.

  

• 출퇴근 발자국 홈위젯 개발
  홈위젯은 AppWidgetProvider 이용하여 위젯을 갱신하는데, 이 Provider가 BroadcastReceiver 라는 사실이 놀라웠었다. 일반 Activity에서 View를. 이벤트를 받아 갱신하는 것과 달리 BroadCast를 이용한다는 것이 신선하게 다가 왔었다.
  • MPV 구조 적용
    AppWidgetProvider 를 View 로 보고 Presenter 에는 이벤트에 따른 도메인로직을 정의하고, View로 피드백을 주는 식으로 구현을 했었던 것 같다.
• Place 통합검색 개발
  • 이 때부터 DataBinding을 enable 하고, 신규 기능은 MVVM 구조를 기본으로 적용하기 시작했다.
    그리고, 이 시점부터 RxJava 와 람다, Stream 등을 사용하기 시작했었다.

• Timeline 개선
  • 노트가 많아지면 조회 속도가 너무 느려져서 이를 개선했었다. 원인은 SqLite에서 Date를 Select 해서 변환/연산 하는 과정에서 Calendar를 잘 못 사용하고 있었다. Calendar를 이용하는 것이 이렇게 비싼 연산이었다는 것을 알았다.
  • Unit Test 적용.
    노트에 일정이나 할일 등 시간과 관련된 인라인태그가 삽입되어 있으면 이 것도 Timeline에 표시하도록 개발했는데, 이 때 사용된 도메인 로직을 Unit Test로 검증했다. 기존이라면 서버의 DATA를 가지고 하나하나 테스트 했었을텐데, MOCK 데이터로 정렬 순서나 결과 데이터를 손쉽게 검증 할 수 있었다. 이 때부터 ViewModel 에서 도메인 로직이 들어가는 부분은 유닛 테스트를 작성하려고 노력한 것 같다.

  

• Target SDK 11 대응
  • Storage Scope 적용.
    기존 DATA를 내부 저장소에 이동하는 Migration 기능을 추가했었다. 이걸 개발할 때 Module 로 빼서 개발하고, Kotlin 을 사용하기 시작했다.
  • 백그라운드에서 위치 접근 권한 제거.
    앱이 실행되지 않은 상태에서 홈위젯으로 위치를 접근, 포그라운드 서비스에서 지오펜싱 사용하는 로직 때문에 업데이트 시 계속 reject 되어 홈위젯에서 포그라운드 서비스를 실행해서 위치를 얻어오고, 지오펜싱은 대체 로직을 아예 구현해서 백그라운드 위치 접근 권한을 제거하고 업데이트를 무사히 진행했었다.

Flutter 전환 중

  올 해 i-os 담당자의 퇴사로 인해 업무 공백이 생기고, 타 부서의 네이티브 앱이 플러터로 전환하자 우리 앱도 플러터 전환을 검토하게 되었고, 결국 우리도 플러터로 전환하게 되었다. 그 덕분에 모든 UI, 디자인, 에디터 까지 싹 새롭게 개발을 하게 되었고, 지금 완전 바쁘게 개발을 하고 있다.

 

  처음에는 플러터로 전환하는 것에 대해서 반감을 가졌으나 그래도 사용을 해보니 안드로이드에 비해서 레이아웃을 그리고 애니메이션을 적용하는 것은 확실히 편하고 생산성이 높다는 것을 느낄 수 있었다.

선언적UI 의 특성인 것 같아서 개인적으로 Compose 를 기대하고 있다. ㅋㅋ

 

  그리고, flutter는 위젯과 상태관리만 잘 이해하면 어느 정도는 앱을 무난하게 만들 수 있는 것 같다.

확실히 진입장벽이 안드로이드에 비해 낮은 느낌이었다.

  단점으로는 홈위젯을 비롯한 몇몇 기능들은 Nativie 코드 만으로 개발해야 하기 때문에 결론적으로 Native와 Flutter를 모두 알아야 한다.

 

이제 Flutter로 완전 커리어를 갈아타야지 하는 건 아니지만(이제 안드로이드를 따라가기 위해서 사이드 프로젝트가 필수가 되었다. ㅠㅠ), 예전처럼 Flutter 완전 별로야 이렇게 이야기 할 수 없음은 분명하다. 빠르게 화려한 앱을 다양한 OS에서 돌아가게 해야 할 때는 Flutter가 괜찮은 선택지이다.

Markdown 에디터 개발

  본격적인 도메인 경험 중..ㅠ
에디터 개선 이야기가 항상 나왔었는데, 큰 Major변화에 맞추어 에디터도 새롭게 개선하기로 하고 개발 중에 있다.

현재 에디터 기능에 markdown 입력 기능을 추가(이에 따른 Style 추가)하고, 단축어로 인라인태그와 같은 객체를 에디터에 추가 기능이 주된 개선 기능이다.
  그리고, 현재 안드로이드 앱에 구현되어 있는 에디터는 Native로 TextEdit 를 커스텀 하여 다양한 Span으로 스타일을 적용하고 있다.
이를 웹을 비롯한 다른 기기에서도 동일하게 보이고 더 많은 Type의 DATA를 보이게 하기 위해서 Web기반으로 에디터를 개발하기로 했다.
  툴바를 비롯한 UI적인 요소까지 웹으로 만들면 Native 적인 느낌이 많이 없기 때문에 UI요소들은 Native로 만들고, webView안의 JS와 통신을 하는 구조로 에디터를 개발하고 있다.

감회와 앞으로의 과제

  이렇게 간단하게 정리하고 보니 생각보다 많은 것들을 공부하고, product 에 적용해 본 것 같다.
그래서인지 확실히 처음에 비하면 많이 성장했다는 생각이 들고 뿌듯하다.
  하지만, 5년이라는 시간을 전산실에 있으면서 제대로 된 개발 경력 및 실력을 쌓지 못한 나로써는 여기에 만족할 수 없다. 그래서 요즘 실력의 깊이가 깊어지지 않는 것 같아 조급함이 크다.

 

안드로이드, 플러터 모두 깊이있게 알고 개발하고 싶고 먼 미래에는 모바일, 웹 모두를 할 수 있는 FrontEnd 개발자로 커리어를 확장해나가며 항상 성장하는 개발자가 되고 싶다.

앞으로의 과제

• Flutter 전환, 에디터 개선 프로젝트의 성공적인 릴리즈
• 에디터를 하면서 row 하게 view를 다루고 싶다는 생각이 듬.
  • Paint > 쉐이더
  • 완전 커스텀 위젯 또는 커스텀 그래픽 라이브러리(?) 개발해보기
• 안드로이드(Kotlin), Flutter(dart)를 제대로 깊이있게 습득
  • 공식문서 재정독, 사이드 프로젝트의 진행
• 깊이 있는 CS 지식 습득
• Senior가 될 준비
  싫든 좋든 후배들은 계속 입사를 하고, 같이 일하게 된다. 어떻게 하면 이들을 성장시키고, 함께 개발을 잘해나갈 수 있을 지 고민하고 개발문화를 만들고 실천하기
  • 코드 리뷰 도입
    • 지식의 인출
    • 토론
  • 내가 주도해서 사내 스터디 진행, 안되면 스터디 한 내용 공유
• 위 언급한 상세내용과 개발하면서 공부한 것을 블로그에 틈나는대로 올리기.
  원노트에 정리를 해둔게 많은데, 단순 복사-붙여넣기는 스타일이 너무 깨져서 볼 수 가 없네요.
  정리와 깔끔한 스타일을 적용해서 틈나는 대로 올려보겠습니다.

 

https://play.google.com/store/apps/details?id=com.fasoo.digitalpage&hl=ko&gl=US 

디지털페이지 – 메모를 연결하는 메모장 - Google Play 앱