[SWM] Server Driven UI - 개념 정리

3 분 소요

👩🏻‍💻 모바일 서비스 업데이트 시 문제점

모바일 서비스 업데이트 -> 앱 배포

이때 문제점은 바로 유저들은 쉽게 업데이트를 받아주지 않는다는 점이다! 그렇다면 앱 배포를 거치지 않고 서비스에 변화를 줄 수는 없을까??

그게 바로 Server Driven UI이다. 즉, 서버에서 화면을 컨트롤할 수 있게 되는 것이다.

🤨 강제 업데이트 하면 되지 않나요?

특정 버전 이하일 경우, 강제 업데이트를 하도록 처리한다 가정하자! 이렇게 될 경우, 사용자는 특정 목적으로 우리의 앱에 들어왔을 것이다. 하지만 업데이트 화면으로 넘어가버리기 때문에 ux를 해치는 것이다!

🤔 프론트엔드에서 화면을 컨드롤 하지 않는 방법: Feature Flag & A/B Test

-> Feature Flag?

새롭게 구현했거나, 개선시킨 기능을 특정 경우에만 열 수 있게 해주는 기능
- 배포/출시 시점 ≠ 노출 시점
- 간단히 firebase remote config를 통해 적용할 수 있다. 직접 활용 해본적은 없지만 특정 변수 값을 저장하고 firebase에 저장된 값이 변경됨에 따라 로직을 처리할 수 있게 된다.

-> A/B Test

Feature Flag를 응용하여 비즈니스의 개선 방향을 결정한다.
- 똑같은 기능이지만 배치, 모양 등이 서로 다른 방안을 준비한다.
- 이 또한 firebase remote config를 통해 적용할 수 있다. feature config로 만들어진 여러 대안을 %를 정해 특정 사용자에게만 테스트를 할 수 있게 된다.

Feature Flag & A/B Test의 장점

배포/출시 ≠ 노출
적은 노출/리스크 -> 개선 방향 결정
리스크가 감지된다면 빠른 롤백이 가능

Feature Flag & A/B Test의 단점

a/b 코드 분기로 인한 관리가 어렵고, 결정에 따라 지속적으로 a/b 코드의 clean up이 필요하다.
여러 개의 a/b가 서로 연관이 되었다면 영향도 파악이 어렵다.

🤨 Feature Flag, A/B Test - Intro API

Intro API

앱이 cold start되는 시점
서버로부터 앱 구동시 세팅되어야 하는 데이터를 내려주는 API

언제?

앱이 splash 화면이 있을 경우? api의 response가 돌아온 뒤 메인 화면으로 이동하도록 처리한다.

-> feature flag, a/b test, 강제 업데이트 안내 팝업

🤨 Server Driven UI?

위에서 Feature Flag나 A/B Test를 통해 화면 컨트롤을 클라이언트쪽에 의존하지 않는 방법에 대해 살펴봤다!

A/B Test를 할 경우, A냐 B냐에 따랴 로직을 분리해야 하므로 서버의 response는 다음과 같을 것이다!

{
  "responseData": {
      "screenName": "Intro",
      ...

      {
        "title": "...",
        "value": "A"
      },
      {
        "title": "...",
        "value": "B"
      }
  }
}

그럼 우리는 나아가 이런 생각까지 할 수 있다! ‘어? 서버쪽에서 A냐 B냐를 알려주는 것에서 나아가 어떤 뷰를 그려야 하는지를 알려줄 순 없을까?’ 그 개념이 바로 Server Driven UI이다!!

시작할 때 잠깐 언급했듯이 Server Driven UI는 서버에서 화면을 컨트롤할 수 있도록 하는 방식이다.

🤨 Server Driven UI 장단점

그렇다면 server driven ui는 장점만이 존재할까? 모든 기술에는 트레이드 오프를 고려해야 하듯이 server driven ui처럼 서버에 의존해 ui를 그리게 된다면 그에 따른 문제점도 존재한다.

단순히 server driven ui가 가지는 장단점을 다루는 것이 아니라 개발자와 클라이언트 입장에서 얻게 되는 장단점에 대해 한 번 정리해보고자 한다.

[개발자 입장: 장점]

빠른 배포

가장 먼저 위에서 설명했듯이 server driven ui를 적용한다면 앱 배포 없이 서버의 변경만을 가지고 업데이트를 빠르게 진행할 수 있다.
A/B test 용이성

server driven ui는 서버에서 넘겨주는 json에 따라 화면의 구성이 유연하게 변경된다. 따라서 이를 활용한다면 A/B 테스트를 더욱 편리하게 진행할 수 있다.

만약 정적인 화면에서 서로 다른 화면 구성에 대한 테스트를 진행하고자 한다면 구성을 변경할 때마다 앱 업데이트를 필요로 하게 된다. 하지만 server driven ui에서는 일정 비율로 서버에서 서로 다른 데이터 값을 전달해 준다면 이에 따라 ui를 구성해 테스트를 진행하면 되기 때문에 A/B test가 더욱 편리해진다.
클라이언트 맞춤형 콘텐츠 제공

유저에게 맞춤형 콘텐츠를 제공하는 것에도 server driven ui가 유용해진다. 화면의 유연한 설계가 가능하기 때문에 클라이언트 별로 서로 다른 json를 제공받는다면 그것이 바로 클라이언트 맞춤형 콘텐츠가 되는 것이다.

[개발자 입장: 단점]

그렇다면 server driven ui를 제공할 때 개발자 입장에서의 단점은 어떻게 될까?

네트워크 의존성

ui 정보를 서버에서 받아오기 때문에 ui가 네트워크 상태에 강하게 의존하게 된다. 따라서 네트워크 상에서 지연이 발생한다면 클라이언트에서는 원활한 ux를 제공받지 못한다.

따라서 네트워크 상태에 따라 에러 화면을 주거나 UNKNOWN 뷰타입을 구성하는 등 별도의 처리를 통해 이러한 문제 상황을 대처해야 한다.
성능 저하 가능성

server driven ui는 하나의 여러 뷰 타입으로 구성된 하나의 list를 통해 화면을 구성하게 된다. 따라서 item 뷰가 너무 복잡할 경우 렌더링 성능에 영향을 줄 수 있다.

뷰를 그리는 것에 성능 저하가 발생하는 것에서 나아가 하나의 화면을 그리기 위해 필요한 데이터가 많은 경우, 이 모든 데이터를 하나의 쿼리로 제공해야 하기 때문에 앱 반응성이 떨어질 가능성도 존재한다.

[클라이언트 입장: 장점]

사실 클라이언트 입장에서의 장단점 역시 개발자 입장에서의 장단점과 유사하다. 따라서 구체적인 설명이 필요한 부분만 부가 설명을 적는다.

앱 업데이트 없이 최신 UI 경험
신속한 버그 수정 및 개선
맞춤형 콘텐츠 제공

[클라이언트 입장: 단점]

네트워크 의존성
일관되지 않은 UI로 사용자 경험 저하

server에 의해 UI가 너무 빈번하게 변경될 경우, 사용자가 익숙해질 틈 없이 UI가 계속 바뀌어 혼란을 줄 수 있다.

😌 정리

다양한 앱을 사용하다 보면 업데이트를 하지 않았는데도 광고 위치가 요리조리 이동하거나 앱 구성이 바뀌는 경우가 있다. 내부적인 로직을 직접 본 경험은 없지만 이렇게 업데이트 없이 다양한 화면 구성을 제공하는 경우, server driven ui가 적용되었을 가능성이 있다.

위에서 다뤘듯이 server driven ui를 제공한다면 이점뿐만 아니라 문제점 역시 존재한다. 따라서 이러한 문제점을 인식하고 이를 해결하기 위한 노력을 기울여야 비로소 server driven ui가 가져다 주는 이점을 제대로 활용할 수 있다고 생각한다.

📃참고

SWM 모바일 특강

Twitter Facebook LinkedIn

youl