앱 개발자가 웹 개발자로 전향한 이유 #1

프롤로그

나는 아래와 같이 개발을 시작할때부터 웹 개발자로 전향하기 전까지 앱개발만 쭉 하고 있었다.

• 솔로로 안드로이드 앱 2년 (초코플레이어 외 3건)
• 회사에서 안드로이드 앱 10개월 (반반 외 1건)
• 외주로 iOS 앱 3개월 (홍익인 외 1건)
• 회사에서 iOS 앱 3년 (웹*, 시**)

처음 제대로된 개발을 시작한 2014년 부터 스마트폰만 있으면 언제 어디서든 쓸 수 있는 앱이라는 것에 취해있었다.
그래서 안드로이드 앱, iOS 앱 개발을 둘다 개발을 할 생각이었고, 윈도우폰이나 타이젠같은 다른 OS이 활성화되었더라면 더 넓혀갈 생각이었지만, 결국 세상에는 두가지 OS만 살아남게 되어 안드로이드 앱과 iOS 앱을 개발하는 개발자가 되기로 했다.

그래서 혼자서 토이프로젝트도 여러 건 진행하고 지인지인을 건너 계약직과 외주도 하면서 경력을 쌓아 운좋게 대기업에 iOS 앱 개발자로 입사하게 되었다.

회사에 들어가서 했던 업무도 회사에 들어가기 전과 유사하게 백엔드에서 제공하는 API 를 디자이너가 준 시안 을 통해 UI 로 이쁘게 보여지도록 구현하고, 앱스토어 혹은 플레이스토어에 배포 해서 사용자가 다운받아 이용하게 하는 것은 동일했다.

추가적으로 회사에서 필요로 했던 부분은

• 코드는 현 기준에 가장 깔끔해야 되기 때문에 최신 트렌드의 코드 를 구현해 해야 한다
• 사용자가 많기 때문에 이슈가 없도록 보수적인 코드를 구현
• 앱이기 때문에 성능을 고려해야 한다
• 오프라인인 상황을 고려해 로컬 DB 를 이용
• (오래된 레거시 API를 호출해야 한다면) API가 많이 호출되지 않도록 메모리 캐싱 혹은 로컬 DB 를 이용

정도가 있었는데, 그 중 몇 가지가 결합되면서 부담감으로 여겨졌다.

• 트렌디한 코드 vs 보수적인 코드
• 트렌디한 코드 vs 로컬 DB

트렌디한 코드 vs 보수적인 코드

개발을 하다보면 항상 겪게되는 일인데, 작년의 코드는 오늘 코드보다 못 생겼다 라는 생각을 항상 하게된다. 그도 어쩔수 없는 것이 내 개발 실력도 나날이 늘고있고, 언어도 계속 버전업을 해서 좋은 기능이 생기고, 좋은 디자인패턴도 매달 나오고 있었다. 새로 구현하는 코드는 작년과 사뭇 다른 코드를 적용하게 되는 경우가 많았다.

예를들면

• 신규 버전의 언어에서 나온 기능 적용 (Swift 3 에서 optional chaning, optional binding 기능 적용)
• MVC 에서 MVVM 디자인패턴으로의 변경
• 최신 트렌드에 성능도 더 좋고 개발 효율도 좋은 신규 라이브러리 적용

위와같이 트렌드가 바뀌는 경우가 있는데, 팀원들끼리 협의하여 방향성을 다시잡는 경우가 종종 있다. 하지만 여기서 문제점이 발생한다.

새로운 코드는 협의된 대로 트렌드를 반영하여 구현하면 되는데, 이전에 구현해둔 수많은 코드들을 다 반영하기에는 주워진 개발기간도 짧고, QA 인력도 지금 나가는 피쳐를 테스트하기에도 벅차다. 그래서 구현한 시기에 따라 코드의 모양새가 달라지게 되는 것이다.

이를 위해 코드 리팩토링 일정을 따로 잡아 주기적으로 이전코드도 최신트렌드로 변경을 하는데, 운이 안좋게 테스트가 안된 환경에서 이슈가 발생하면 개발자로서 움추리게 될 수 밖에 없었다.

특히 iOS 앱은 애플 심사가 껴있어서 배포하는데 안드로이드 앱보다 길게는 일주일 더 걸리는데, 이슈가 한번 터져서 배포를 기다리는 3일동안 전전근근한 직후에는 리팩토링을 한동안 놓고있었던 적도 있었다.

회사에서 가지고 있지 않은 기기도 많고 매달 새로운 마이너 OS 가 나오는데, 모든 OS 에서 테스트할 수 있는 환경 자체가 없었다. 그래서 많이 사용하는 OS 위주로 테스트하는데, 이슈는 항상 보지못한 환경에서 터지기 마련이다. (iOS 시뮬레이터 혹은 안드로이드 에뮬레이터로 테스트가 가능하지만 이것도 커버리지에 한계가 있었다)

• 대부분의 아이폰은 64bit 운영체제인데 32bit 운영체제를 가지고있는 기기에서 Int 자릿수 이슈 (시뮬레이터에서는 재현 안됨..)
• 앱을 오래 사용한 사용자의 로컬DB 용량이 기기의 RAM 용량을 넘어서 앱 구동이 안됨
• 외국 Timezone 으로 설정되어있는 경우에 이슈
• 특정 통신사에서 네트워크 에러 발생되는 이슈
• 특정 기기의 특정 상황에서 UI 깨지는 이슈

정말 예상치 못한 곳에서 펑펑 터지는데, 이러한 상황을 개선하기 위해 시스템적으로 개선이 필요하다는 생각을 했다.

• 많은 환경에서 병렬적으로 테스트할 수 있는 환경
  • 결국 개선하지 못하고 손품으로 많은 시간을 테스트하는 걸로 커버
• 구글과 애플에서업데이트를 점진 배포 할 수 있도록 기능 지원
  • 안타깝게도 그당시 애플은 점진 배포가 되긴 하는데 취소기능은 없었음 (반쪽짜리 기능..)
• 구글과 애플에서 필요시업데이트 강제 롤백 할 수 있도록 기능 지원
  • 지금도 대부분 사용자가 직접 업데이트를 누르는 방식이기 때문에 롤백도 기대할 수 없음

개발자가 마음껏 리팩토링을 하려면 위와같은게 필요하다고 느꼈지만 앱 개발 환경에서는 불가능했고, 웹 개발 환경에서는 모두 가능했기 때문에 매력적으로 느껴졌다.

트렌디한 코드 vs 로컬 DB

대부분의 유명한 앱에서는 로컬 DB를 가지고 있다. 여러 이유가 있겠지만, 웹에 비해서 앱이 좋은 사용성을 가질 수 있는 이유가 로컬 DB의 역할이 크다고 생각한다.

• 오프라인에서도 작동하는 컨텐츠 앱
• 느린 네트워크상황에서도 이전에 저장해둔 메일을 볼 수 있는 앱
• 때로는 무거운 쿼리라면, 백엔드 서버의 부하를 줄이기 위해 데이터를 로컬에 저장하는 앱

위와같은 순작용이 많은 기능이긴 하지만, 앱의 DB는 백엔드의 DB와는 달리 마이그레이션 부분이 치명적이였다.

백엔드의 DB에서는 일반적으로 하나의 스키마만 가지고 있고, 스키마 변경시에도 바로 이전 스키마에 대한 상태만 확인해서 마이그레이션하는 것에 비해,
앱의 데이터베이스는 사용자가 앱을 업데이트를 하지 않았다면 바로 이전의 스키마가 아닌 더 옛날, 첫번째로 정의한 스키마도 갖고 있을 수 있기 때문에 제대로 마이그레이션을 테스트하려면 이전 모든 스키마로부터 현재 스키마까지의 마이그레이션을 체크해야했던 부분이다. 스키마 버전업 할때마다 구 마이그레이션 로직이 쌓여만 갔다.

나는 이를 해결할 수 없었지만, 몇 가지 방안을 떠올렸다.

주기적으로 이전 마이그레이션 로직을 버린다

예를들면 스키마 5개까지만 허용하고, 그 이전 버전에서 업데이트하는 경우에는 DB 를 새로 시작하는 방법이 있다. 레거시코드가 주기적으로 없어지는 장점이 있지만, 사용자에게 VOC 를 주기적으로 받아야되는 단점이 있을 것 같다. (유료 서비스기 때문에 시도해보지 못했다)

개인화 데이터를 백엔드에 Dual Writing

앱은 백엔드가 들고있을 필요가 없는 데이터도 가지고있다. 예를들면 컨텐츠를 마지막으로 읽은 위치, 다크모드 앱 설정 등이 있을텐데, 이를 설정이 변경되었을 때 바로 혹은 주기적으로 백엔드 API 로 쏴서 백엔드 DB 에 저장해둔다. 그리고 앱이 재설치되거나 DB 버전업이 발생할 때, DB 마이그레이션을 하지 않고 백엔드에서 가져와서 앱 DB 를 채우는 방법이 있다. (그 당시 백엔드에 여력이 없었다)

웹 환경에서는 로컬DB가 필요가 없었기 때문에 이 역시 전향하게 된 계기가 되었다. 물론 프론트에서도 백엔드 API 에 부하를 주지않게 하기 위해 캐시 레이어 (Memcache, Redis) 를 두고있는 부분은 비슷하지만, 여러 스키마에 대한 처리를 하는 부분이 거의 없다.

여기까지는 앱 개발을 하면서 힘든 것들에 대해서 얘기했지만, 그 외에 부분은 다음 글로 정리하려고 한다.