앱의 UI는 항상 변화합니다. 단순한 버그 픽스일 수도 있고, 주기적인 업데이트, 디자이너의 변덕, 심지어는 UI 변화를 통해서 AB 테스트를 수행하기도 합니다.
하지만 우리가 만든 변경사항이 유저에게 도착하기까지는 시간이 좀 걸립니다. 악명높은 iOS 심사 때문일 수도 있고, 사용자가 Wifi에 오래동안 연결하지 않아 자동 업데이트가 아예 실행되지 않는 경우, 변수는 많지만 모두 실제로 매우 빈번하게 일어나는 일들입니다.
실제 운영중인 서비스에서 이것들은 매우 짜증나는 경우가 많은데,
광고 집행 스케쥴이 다음 릴리즈에 맞춰져 있는 경우, 심각한 버그 픽스가 빨리 전달되어야 하는 경우, 아니면 팀이 정말 다양한것을 실험하고 싶어서 매우 빠른 주기로 UI 변화를 주는 경우가 대표적인 예시입니다.
현업에서 이러한 문제를 해결하기 위해 사용하는 가장 흔한 방법은 아무래도 웹뷰입니다.
대표적으로 Toss앱은 주요 화면(송금)을 제외한 대부분의 화면이 웹뷰로 이루어져 있습니다.
네이티브 앱에 웹뷰를 얹는 것은 다 좋지만 크게 두가지 문제가 있습니다.
* 웹뷰입니다.
웹뷰 자체가 문제일 수 있습니다.
왜 처음부터 100% 웹뷰로 만들지 않고 웹뷰를 섞어 쓰는지 생각해보세요.
웹뷰(하이브리드) 앱은 매년마다 좋아지고는 있지만 여전히 네이티브 UI와는 약간 다른 터치감이 있습니다.
하지만 이 부분은 기술적으로 해결 가능할 수 있습니다. (역시 Toss를 생각해 보세요, 처음에 로딩바가 돌아가는걸 제외하면 웹뷰와 웹뷰가 아닌 부분을 구별하실 수 있나요?)
* 앱이 완전히 분리된 두개의 환경에서 돌아갑니다.
이부분이 큰 문제일 수 있습니다.
앱 개발은 커다란 구조(아키텍쳐)를 가지고 돌아갑니다. 그런데 그런 구조가 한군데 더 생겨버립니다. 그것도 완전히 다른 프레임워크와 언어로요.
웹과 네이티브를 이어주는 브릿지(인터페이스) 또한 당연히 만들어야 합니다.
그렇다면 웹뷰를 사용하지 않는 동적 업데이트 환경을 구성해보고자 생각할 수 있습니다.
디자인 언어(혹은 포멧)을 하나 정의하고 파싱해서 렌더링하는 엔진을 만들면 되겠네요.
이 작업에 어마어마한 시간이 투입되는것은 아니지만, 위에 나열된 웹뷰의 문제점이 사소하게 보일 정도로 많은 시간을 쏟아야 하는것은 극명합니다.
또한 디자인 언어 이기 때문에 로직을 변경할 순 없습니다. 글자나 이미지 혹은 레이아웃을 변경할수는 있어도 로직을 변경하려면 재배포가 필요합니다.
이 또한 스크립트 언어를 만들고 실행기를 만들면 해결할 수 있겠지만 아무래도 그냥 웹뷰를 쓰는게 낫겠네요.
하지만 이 글에서는 조금 다른 방법을 소개해보고자 합니다.
네이티브로 돌아가면서, 동적으로 업데이트 가능하고, 로직 또한 포함시킬 수 있습니다.
여기서 네이티브는 ReactNative를 의미합니다. 제가 Javascript 개발자라서요.
저는 몇가지 목표를 설정하고, 그 목표를 만족시키는 동적 컴포넌트의 아주 간단한 구현체를 만들었습니다.
소스코드는 여기에 있고,
https://github.com/pjc0247/remote-component-testbed
프로젝트의 목표는 아래와 같습니다
- 이미지 가져오듯 URL을 통해 컴포넌트를 가져올 수 있어야 합니다. 그러니까 서버에 있는 이미지를 교체하듯 간단하게 컴포넌트를 교체할 수 있다는 뜻입니다.
- 복잡한 워크플로우가 없이 돌아야 합니다. 그러니까 업데이트 가능한 UI를 만들기 위해서 몇가지 추가적인 API를 호출하거나, 다른 방식으로 코딩하거나 하지 않아야 한다는 뜻입니다.
일반적인 ReactNative 컴포넌트와 100% 똑같이 생겼고, 추후에 특정 컴포넌트만 개별로 번들링 할 수 있습니다.
다음 글에서는 어떻게 구현하였는지 설명해보도록 하겠습니다.
