해당 글은 Server-Driven UI에 대해 아래 블로그 링크 글을 번역한 내용입니다.
https://medium.com/@dfs.techblog/server-driven-ui-concept-db07d7946e94
요약
이 아티클은 앱 개발에 보다 효율적이고 유연한 Server-Driven UI (SDUI) 방식에 대해 설명한다. SDUI는 서버가 앱의 UI를 담당하며, 이는 서버 사이드의 변화를 클라이언트가 즉시 반영한다. 이 방법은 클라이언트가 UI의 변화 및 이벤트 기능을 즉시 반영뿐만 아니라, 실시간 UI 적용 및 높은 유저 개인화 경험을 제공한다. SDUI는 별도의 앱 반영 없이 앱의 변화 및 인터페이스 변경을 적용할 수 있다. 하지만 SDUI 가 모든 설루션의 정답은 아니고 각 애플리케이션의 요구사항에 따라 달라질 수 있다고 말한다.
빠르게 변화하는 모바일 앱 생태에서 기업은 어떻게 그들의 앱을 매력적이고 최신으로 유지하는지에 대한 문제에 직면하였습니다. 기능을 추가하고 앱의 UI 를 업데이트하는 기존의 방법은 시간이 오래 걸리는 방법이다. 이는 기업이 앱을 빠르게 반영하고, 새로운 기능을 도입하거나, 이벤트별 기능을 출시해야 하는 경우 특히 그렇다. 이 방법은 개발자들에게 기능을 개발하고 다양한 기기, OS, 그리고 화면 사이즈에서 테스트하길 원하고 이는 앱의 출시 및 업데이트를 지연시킨다.
이러한 문제 속에서 새로운 SDUI 접근법은 점점 인기를 얻고 있다. SDUI 에서 앱이 보이는 것과 디스플레이는 서버 사이드에서 결정하고 이를 앱으로 보내 앱에서 그걸 따르도록 한다. 이는 비즈니스 변경으로 인한 앱의 모습, 새로운 기능 추가 및 이벤트 기능을 좀 더 빠르고 쉽게 적용하도록 그 책임을 앱에서 서버로 이관시킨다. 이를 통해 앱 출시 및 업데이트가 가속화되고 앱의 참여도와 사용자 관련성을 유지하여 기업의 시간과 노력을 절약할 수 있다.
시리즈의 첫번째로, 오늘날 앱 개발 에코시스템에서 SDUI의 콘셉트와 SDUI의 기초에 대해 설명한다.
Server-Driven Architecture
SDUI 의 주요 원칙은 서버가 앱의 UI를 그린다는 것이다. 서버는 데이터와 UI 레이아웃 지시사항을 클라이언트에 전달하고 그 정보를 바탕으로 렌더 한다. 이는 별도의 수동 앱 업데이트 없이 서버에서의 변경으로 클라이언트에 즉시 적용할 수 있도록 한다.
서버가 앱의 UI 와 워크 플로우를 컨트롤해야 한다고 말할 때, 서버가 기본적으로 앱이 만들어질 때 필요한 정보를 앱이 이해할 수 있는 방식으로 전달함을 의미한다. 대부분의 경우 이는 JSON을 통해 한다.
정리하면 서버는 앱이 필요로하는 모든 정보를 JSON으로 만들어서 모바일 앱과 그 JSON을 싱크 하면서 모듈을 렌더링 하고 그 결과 유저는 화면에서 해당 화면을 볼 수 있게 관리한다.
Component-Based Approach
SDUI 는 컴포넌트-베이스 형태를 띤다. 서버가 클라이언트에게 전체 UI 화면을 전달하기보다, 보여줄 컴포넌트의 리스트를 전달한다. 각각의 컴포넌트는 UI의 재사용성과 앱의 일관성을 위해 구조와 행동의 규칙이 미리 정의되어 있다.
Classic Client Server
만약 Client-Server 구조에 익숙하다면 클라이언트 영역에 UI 와 워크 플로우가 내장되어 있는 것이 일반적일 것이다. 그리고 서버에는 유저 인터페이스에 관련된 특정 데이터를 요청하게 된다. 서버는 해당 응답을 클라이언트에 전달하게 되고 클라이언트는 서버에서 받은 데이터를 바당으로 화면을 그리게 된다.
이와 같은 전통적인 방식의 접근에서는 클라이언트 워크플로우는 클라이언트 앱에 정의되어 클라이언트가 워크플로우를 인지하고 서버에서 응답받은 데이터를 기반으로 UI를 그리는 로직을 인지하게 된다.
이러한 방식은 우리가 급하게 워크플로우를 변경하거나 화면 요소를 변경하거나 간단한 UI를 변경하길 원하기 전까지 잘 작동한다
Run time configs
이러한 문제점을 해결하기 위해 몇몇 앱은 런타임 설정 방식을 채용한다. 런타임 설정 방식의 주요 콘셉트는 화면과 워크플로우가 앱에 존재하지만 해당 모듈이 구동되는 동시에 어떤 부분이 활성화될지 설정을 정의한다.
예를 들어, 홈화면에 배너를 보여준다고 하자. 이 배너들은 캐러셀 형태이며 각각의 매버는 그 본래의 목적이 존재한다. 결제 앱의 경우에, 한 배너는 이체화면으로 이동하고, 다른 배너는 출금 화면, 그리고 다른 배너에서는 또 다른 기능의 화면으로 이동한다고 하자. 각 기능에 따라 배너는 동적으로 정의되어야 한다.
배너는 유저 세그먼트에 따라 때때로 변경되어야 하고 배너를 동적으로 만드는것은 모듈을 좀 더 효율적으로 관리하기 위해 요구된다.
이 경우 런타임 설정 방식으로 구현한다고 해보자. 클라이언트 앱에서는 빈 캐러셀 컴포넌트를 만들고 서버에서 받은 내용을 추가하면 된다. 캐러셀 자체는 앱에 존재하고 캐러셀의 속성은 앱에서 관리되어진다. 다만 캐러셀에 보일 내용은 서버에서 데이터를 받아서 보인다.
이는 특히 화면 배치가 어떻게 되는지, 캐러셀이 어디에 위치하는지 알 때 더욱 유용하다. 클라이언트 앱에서 요소 배치가 완료되면 서버에서 데이터를 가지고 와서 그걸 바탕으로 화면에 보여주는 것이 쉬워진다.
하지만 화면 배치가 바뀌어야 하는 요구사항이 생기면 되면 문제가 발생할 수 있다. 예를 들어 기존에 하단부에 있던 캐럿셀을 화면 상단으로 옮겨야 하거나, 비즈니스 로직에 따라 캐러셀을 숨겨야 할 때이다.
유저에게 앱이 배포된 이후 이러한 변경을 수용하기 어렵고 거의 매번 앱을 리프레쉬해야 한다. 이런 모든 경우가 고려되지 않는다면 실질적으로 해당 내용을 달성하기 힘들다.
Server Driven Apps
이 경우 서버는 클라이언트의 UI를 그려주는 유일한 공급원 (source of truth: 단일 진실 공급원) 이 된다. 서버는 클라이언트에 전체 화면의 배치를 전달하며, 그 내용은 화면 요소의 구성, 워크플로우 정의, 액션 호출, 그 밖의 다양한 내용이다. 앱에서는 비즈니스 로직에 대한 내용을 알 수 없고 오로지 화면렌더링을 위한 로직과 플랫폼 관련 중요 로직만 존재하는 가벼운 상태가 된다.
server-driven 앱에서 클라이언트 앱은 서버로부터 모듈의 세트를 받게 되며, 해당 모듈은 앱에서 모듈을 구동시킬 수 있는 완성된 모듈의 정보이다. 서버로부터 전체 모듈을 받은 앱은 비즈니스 로직을 가지지 않는다. 오직 JSON을 읽고 이해해서 화면을 그리고 워크플로우를 구성하는 렌더링 엔진만 존재한다.
정리하면 런타임 설정은 화면 구성은 고정되어 있는 시나리오에 유용한 몇 가지 설정 정보만 전달한다. 그러나 앱 모듈의 더 효과적인 컨트롤과 구성을 위해서는 Server-Driven UI 가 필요하다.
Real-Time UI Adaptability
이전에 논의한 내용에서 SDUI의 두드러진 기능 중에 하나는 UI 구성이 실시간 서버 사이드 로직이라는 것이다. 이는 유저 행동, 위치, 시간, 단말기 타입, 그 밖의 요소를 포함할 수 있다. 서버는 동적으로 레이아웃과 컴포넌트를 결정해서 클라이언트에 보내서 높은 적용성과 개인화로 UI를 구성할 수 있다.
예를 들어보자. 우리는 다양한 물건을 파는 글로벌 리테일 앱을 가지고 있다고 가정하자. 기존의 UI 방식에서는 유저가 언제 어디서 접속하든, 주로 어떤 상품을 구매하든 모든 유저에게 동일한 홈 화면이 보인다.
하지만 SDUI에서는 앱 UI가 다양하고 개인화되어 구성된다.
- 유저 행동 : 서버는 유저의 과거 구매 및 상품 조회 히스토리를 트레킹 할 수 있다. 그래서 만약 유저가 스포츠 용품을 주로 구매했다면 서버는 그 고객의 홈 화면에 신상 러닝화 프로모션 내용을 보여줄 수 있다.
- 위치 : 서버는 유저의 위치가 어디인지 알 수 있다. 만약 유저가 접속한 나라가 현재 겨울이라면, 서버는 겨울 의류와 용품을 우선적으로 보여줄 것이다.
- 시간 : 만약 아침 시간이라면 서버는 아침 식사 음식 또는 커피 제품을 주요 공략할 것이다. 저녁 시간이라면 서버는 릴랙싱 할 수 있는 음악과 수면 용품을 제공할 것이다.
- 단말기 타입 : 서버는 어떤 단말기를 사용하냐에 따라 다르게 UI를 구성할 수 있다. 만약 작은 화면의 스마트폰을 사용한다면 좀 더 심플한 레이아웃과 큰 버튼의 UI 를 제공할 것이다. 만약 유저가 큰 화면의 태블릿을 이용한다면, 좀 더 디테일하게 제공하여 좀 더 몰입도 있는 쇼핑 경험을 제공할 것이다.
Server-Driven UI와 Real-Time 적용을 통해 모든 유저는 여러 요소를 통해 잠재적으로 유니크하고 개인화된 경험을 할 수 있다. 이는 유저의 참여도를 높이고 고객 만족도를 높이며, 잠재적으로 나은 매출을 이끈다.
Future-Proofing the User Interface
기술의 급작스런 발달로 모바일 앱은 잦은 업데이트를 요구한다. SDUI는 개발자가 새로운 버전의 앱을 출시하거나 업데이트하지 않고도 변화를 적용하고 확장성 있고 지속 가능성 있는 효율적인 방법을 제시하면서 미래 지향적 UI를 제공한다.
서버에서 전체 UI 내용을 전달한다는 사실은 기존의 흐름을 수정하고 새로운 기능을 추가하는 모든 것이 앱 수정이 없이 단순히 불어넣을 수 있다는 것을 말한다. 이는 계속 강조한 내용으로 클라이언트는 서버의 내용을 가지고 화면을 그릴 수 있는 기능만 가진 가벼운 형태로 만들 수 있다.
(여기서 가벼운 형태라고 해서 렌더링 모듈이 가볍다는 것이 아닌 불필요한 로직이 없는 상태를 말하는 것 같다)
이 방식은 새로운 기능이 출시되기 쉬워졌고, 기존의 기능을 수정하기 빨라졌다. 그리고 고격이 들이는 노력은 단지 보드에 해당 기능을 그리는 것이다.
하지만 한 가지 항상 명심해야 하는 것은 SDUI 가 모든 것의 해결책은 아니고 아마도 대부분 타입의 애플리케이션에서 적절할 것이라는 것이다. 그럼에도 불구하고 잦은 UI 업데이트틀 원하는 회사이거나 높은 수준의 개인화를 제공하고 싶다면 SDUI는 게임 체인저가 될 수 있을 것이다. 개발을 단순화하는 것은 잦은 클라이언트 업데이트를 줄이고 높은 수준의 적응력을 제공하여 고객이 앱에 지속적으로 머물게 하는 것이다.