DIY Server Driven UI: A 4-Year Journey in Mobile App Innovation by HARRIET TAYLOR & JIMMY RAY

서버 주도 UI: 소개 및 팀 역할

섹션 개요: 이 섹션에서는 서버 주도 UI의 개념에 대해 소개하고, 팀이 수행하는 역할에 대한 간략한 설명을 제공합니다.

서버 주도 UI 아키텍처

• 네이티브 앱을 위한 아키텍처로, UI 정의를 서버에서 구축하고 클라이언트로 전송함

• 클라이언트 릴리스와 업데이트를 줄여주며, 코틀린으로 4년간 직접 구축한 경험 공유

• 안드로이드 네이티브 모바일 앱 관리 및 게이트웨이 서비스 담당

Auto Trader: 회사 소개 및 기술적 측면

섹션 개요: Auto Trader의 회사 소개와 기술적 측면에 대해 설명하며, 회사의 역사와 현재 상황을 다룬다.

Auto Trader 소개

• 영국 최대 디지털 자동차 거래 시장 운영

• 1996년 첫 웹사이트 출시 이후 많은 데이터를 기반으로 운영

• 하루에 18백만 대의 차량 검색 제공, 약 8000만 명의 방문자가 매월 발생

애플리케이션 도메인 및 문제점

섹션 개요: Auto Trader 애플리케이션 도메인과 현재 직면한 문제점에 대해 다룬다.

애플리케이션 도메인 분석

• 안드로이드와 iOS용 네이티브 앱 클라이언트 비교

• 코드 작성과 테스트가 두 번 필요하며 롤백 불가능한 환경으로 인한 지연 문제 발생

릴리스 프로세스 및 해결 방안 탐구

섹션 개요: 릴리스 프로세스의 복잡성과 지연 문제를 해결하기 위한 방안을 조사한다.

릴리스 프로세스 분석

• 사용자들에게 변경 사항 전달까지 최대 한 달까지 걸릴 수 있는 복잡성 파악

서버 주도 UI 도입 결정

섹션 개요: 이 섹션에서는 회사가 서버 주도 UI를 도입하기로 결정한 배경과 그에 따른 변화에 대해 설명합니다.

Flutter 및 웹 뷰 고려

• 앱의 완전한 재작성은 시간이 많이 소요될 것으로 판단되어 플러터(Flutter)와 웹 뷰(Web Views)를 고려함.

• 플러터는 구글의 오픈 소스 프레임워크로, 멀티플랫폼 애플리케이션을 하나의 코드 베이스로 구축할 수 있게 해줌.

서버 주도 UI의 장점

• Spotify 등의 기업들이 서버 주도 UI를 채택하며 문제 해결에 큰 도움을 받았음.

• 클라이언트 기반 UI 작업에서 발생하는 중복 작업을 줄여 유연성을 확보하고, 프로세스 간소화 및 가속화를 경험함.

Composable: 서버 주도 UI 시스템 명명

섹션 개요: Composable라는 서버 주도 UI 시스템 명칭 선택과 이에 따른 시스템 요구 사항에 대해 다룸.

Composable 시스템 명명

• Design Systems와 협력하여 Composable 시스템 명명 결정.

• Swift UI 및 Jetpack Compose 등 네이티브 플랫폼의 UI 키트 탐색 후 Android용 Jetpack Compose 선택.

요구 사항

• Design System 정의를 바탕으로 클라이언트로 전송할 컴포넌트 결정.

Java의 새로운 기능 소개

이 섹션에서는 Java의 새로운 기능에 대해 소개하고 있습니다.

Java의 기능

• 객체 지향적이고 함수형이며 타입 안전한 Java를 통해 비즈니스가 앱 제작에 참여할 수 있도록 하는 것이 핵심 아이디어입니다.

• Kotlin Multiplatform을 활용하여 Java뿐만 아니라 JavaScript 및 다른 여러 언어와 함께 사용할 수 있습니다.

릴리스 전략과 시스템 설계

릴리스 전략과 시스템 설계에 대한 논의가 진행됩니다.

릴리스 전략

• 초기에 모든 것을 완벽하게 만들려는 욕구가 프로젝트를 제약했습니다.

• Agile 방식으로 스케일을 줄여 현재 필요한 부분만 구축하기로 결정하였습니다.

시스템 아키텍처 변경

시스템 아키텍처 변경 사항에 대한 상세 내용을 다루고 있습니다.

시스템 아키텍처

• 이전 아키텍처에서 앱 클라이언트가 게이트웨이 서비스와 레거시 앱 백엔드와 통신하던 구조를 개선하여 새로운 백엔드를 추가함.

• 서버 주도 UI를 위한 새로운 백엔드 추가, 비즈니스 로직과 UI 정의 포함.

서버 주도 UI 및 기능 확장

서버 주도 UI와 기능 확장에 관한 내용을 다룹니다.

서버 주도 UI

• 새로운 백엔드를 통해 서버 주도 UI 및 비즈니스 로직 구현.

• 애플리케이션 클라이언트마다 클라이언트 라이브러리 유지하여 클라이언트 업데이트 필요성 유지.

앱 개발자 도구 및 첫 번째 반복

앱 개발자 도구와 첫 번째 반복 과정을 다루고 있습니다.

앱 개발자 도구

• 초기 버튼, 링크, 이미지, 텍스트 등 간단한 요소 추가 후 버전 관리 처리.

API 개발 및 클라이언트 버전 관리

섹션 개요: API 개발 시 새로운 구성 요소가 추가되고 이전 구성 요소가 변경되며 새로운 기능이 추가됨에 따라 클라이언트 버전 관리의 중요성에 대해 논의합니다.

API 업데이트와 클라이언트 지원

• 클라이언트는 하나의 API 버전만 지원하며, 서버에서 버전 관리를 담당함.

• 각 엔드포인트는 최소 API 버전을 지정하여 해당 버전 이상의 클라이언트에게 UI를 제공함.

• 기존 컴포넌트나 기능을 변경할 때, 클라이언트는 여전히 UI를 표시하지만 응답 구조가 다를 수 있음.

DSL(Domain Specific Language) 소개

섹션 개요: DSL의 필요성과 장점에 대해 설명하고, JSON 처리와 버전 관리에서 DSL의 역할을 강조합니다.

DSL과 JSON 처리

• DSL은 HTML처럼 특정 기능을 처리하는 언어로, JSON 처리와 버전 관리를 단순화함.

• DSL은 스타일 및 유형 안정성을 강화하며, JSON 페이로드와 상호작용하는 방식을 추상화함.

DSL과 기능 집합

섹션 개요: DSL을 통해 다른 클라이언트가 다른 컴포넌트를 처리할 수 있는 방법과 기능 집합의 중요성에 대해 탐구합니다.

DSL과 기능 집합

서버로 사용자의 응답을 보내고 받아야 했습니다.

섹션 개요: 사용자의 응답을 서버로 보내고 받기 위해 구조를 조정해야 했으며, 클라이언트에게 논리와 상태를 전달하고 실행할 수 있도록 해야 했습니다.

새로운 구조 필요

• 사용자의 응답을 서버로 보내기 위해 이전 구조를 조정해야 했음.

• Redux를 발견하여 비슷한 버전을 만들었음.

• Redux에서 UI가 저장소 내 일련의 key-value 쌍을 구독하고 액션을 디스패치하는 방식 확인.

스토어 및 UI 컴포넌트 간 동작 방식

섹션 개요: 스토어와 UI 컴포넌트 간의 동작 방식과 데이터 처리 과정 설명.

스토어 및 UI 컴포넌트 상호작용

• 각각의 UI 컴포넌트는 스토어에서 액션 실행 가능.

• 예시: 나이 입력 시, 액션을 통해 나이 필드 업데이트 가능.

액션과 유형에 대한 고찰

섹션 개요: 액션과 그 기능에 대한 탐구.

다양한 액션 유형

• 문자열 기반 액션이므로 다양한 입력 유형에 바인딩 가능.

로직 및 액션 관리

섹션 개요: 로직과 액션 관리 방법 설명.

로직 및 액션 관리

• 로직은 여러 스토어 간 공유되며, JavaScript로 상태 관리함.

상태와 데이터 처리 방식 비교

섹션 개요: 상태와 데이터 처리 방식 비교 분석.

상태와 데이터 처리

• JavaScript가 성능 면에서 우수하여 JSON 대신 선택됨.

Kotlin Multiplatform 활용법 소개

섹션 개요: Kotlin Multiplatform으로 작업 시 발생하는 이점 설명.

Kotlin Multiplatform 활용법

기반 로직 및 DSL

섹션 개요: 이 부분에서는 기반 로직과 DSL에 대해 논의합니다. JavaScript로 변환된 스토어의 백엔드에서 키-값 쌍 값과 액션만 노출되어 있었으며, DSL은 팀에 유연성을 제공했습니다.

기반 로직 및 DSL

• JavaScript로 변환된 스토어의 백엔드에서는 키-값 쌍 값과 액션이 노출되어 있었음.

• 클라이언트 내부에 노출된 것은 작은 검은 상자처럼 보였음.

• DSL은 팀에 많은 유연성을 제공하며 다른 팀이 쉽게 참여하고 프로젝트를 이해하기 쉽게 만들었음.

팀 참여와 외부 팀 유입

섹션 개요: 이 부분에서는 전체 팀 참여와 외부 팀을 프로젝트에 참여시키는 중요성에 대해 다룹니다.

팀 참여와 외부 팀 유입

• 대부분의 팀원이 구성 요소를 구축하거나 어떤 방식으로든 기여하여 전체적인 지식 공유가 이루어졌음.

• 외부 팀을 프로젝트 주변으로 모으고 웹 개발자들이 앱에 기여할 수 있도록 하는 것이 중요함.

기능 확장과 도구 다양화

섹션 개요: 이 부분에서는 다양한 기술과 도구를 도입하여 프로젝트의 성공을 위한 확장 가능성을 강조합니다.

기능 확장과 도구 다양화

• Spring Boot, Kotlin Multiplatform 등 여러 기술 및 도구가 사용되고 있으며, Docker와 같은 새로운 서비스들도 필요함.

오프라인에서의 디자인 시스템 도입

섹션 개요: 온라인과 오프라인의 연결은 불가능하며, 오프라인 상태에서는 검색이 불가능합니다. 디자인 지원에 제한이 있어 디자이너들이 제안하는 디자인을 항상 지원할 수 없습니다. 이로 인해 계속해서 발전하고 성장하며, 새로운 디자인과 트렌드에 대응해야 합니다.

온라인 및 오프라인 연결의 한계

• 디자이너들이 만든 다양한 디자인을 모두 지원하기 어려움

• 향후 계획으로 리치 레이아웃 처리, 컴포넌트 추가, 애니메이션 개선 등을 고려 중

• Cotlin Multiplatform 활용 확대 및 코드 공유 증가

미래 계획 및 감사 인사

섹션 개요: Rich layout handling, dynamic UI for tablets, advanced action handling 등의 기능 추가를 포함한 향후 계획 소개와 참여에 대한 감사 인사 전달.

향후 계획 및 감사 인사

• JM on conference 참여 안내

• 업데이트 프로세스와 관련된 규정 준수에 대한 질문과 Facebook, Airbnb, Spotify와 같은 기업 사례 언급

• 앱 접근성 요구 사항에 대한 질문과 DSL을 통한 접근성 태그 추가 설명

접근성 요구 사항 및 사용자 인증 관리

섹션 개요: 네이티브 개발자와 협력하여 앱의 접근성 요구 사항과 사용자 인증 관리 방법에 대해 논의.

접근성 요구 사항 및 사용자 인증 관리

• Force DSL을 활용하여 접근성 태그 추가

• 오프라인 모드 처리 방법 설명

• 사용자 인증은 서버에서 처리되며 보안은 중요시됨

Testing Process and Automation

이 섹션에서는 테스트 프로세스의 어려움과 자동화에 대해 논의됩니다.

테스트 프로세스 개선

• 다양한 버전을 처리해야 하는 상황에서 테스트가 더 어려워졌다.

• UI 테스트를 자동화하지 않았던 것을 개선하고, 새로운 기능 추가 시 테스터들이 관여하도록 함.

• 클라이언트에게 전달되는 모든 것이 작동해야 하며, 이를 위해 다양한 테스트 방법을 사용함.

Wrap-up and Invitation to Engage

회의를 마치고 참가자들에게 질문 및 의견을 나눌 수 있는 기회 제공.

Wrap-up 및 상호작용 초대

• 지원하는 버전을 정리하여 불필요한 걱정을 줄임.