Server Driven UI: SDUI

1. SDUI의 등장 배경과 정의

왜 SDUI인가?

기존의 앱 개발 방식은 UI 로직이 클라이언트(App)에 종속되어 있다.

기능을 수정하려면 [코드 수정 -> 빌드 -> 스토어 심사 -> 유저 업데이트]라는 긴 과정을 거쳐야 한다.

하지만 비즈니스는 실시간으로 변한다.

• "갑작스러운 이벤트 배너를 상단에 배치해야 한다면?"
• "A/B 테스트를 위해 특정 유저에게만 다른 레이아웃을 보여주고 싶다면?"

이런 요구사항에 즉각 대응하기 위해 등장한 것이 바로 Server-Driven UI이다.

정의

SDUI는 이름 그대로 서버가 UI의 구조와 데이터를 결정하고, 클라이언트는 이를 해석하여 화면에 그리는(Rendering) 방식을 의미한다. 서버는 "어떤 데이터를 보여줄지"뿐만 아니라 "어떤 컴포넌트를 어떤 순서로 배치할지"에 대한 정보를 JSON 형태로 전달한다.

 

2. 기존 Client-Side UI vs Server-Driven UI

비교 항목	Client-Side UI (전통적 방식)	Server-Driven UI (SDUI)
UI 결정권	클라이언트 (Hard-coded)	서버 (Dynamic Schema)
업데이트 방식	앱 스토어 배포 필수	서버 데이터 수정 즉시 반영
데이터 형식	데이터(JSON) 중심	구조 + 데이터(UI Schema) 중심
로직 복잡도	클라이언트 로직이 비대함	클라이언트는 렌더링 엔진 역할에 집중
유연성	낮음 (배포 주기에 종속)	매우 높음 (실시간 대응 가능)
초기 비용	낮음 (일반적 개발 방식)	높음 (컴포넌트 라이브러리 및 엔진 구축)

3. SDUI의 핵심 메커니즘

SDUI가 동작하기 위해서는 크게 세 가지 구성 요소가 필요하다.

a. Schema

서버와 클라이언트가 주고받을 공통 언어이다. "버튼은 이렇게 정의한다", "이미지는 이런 필드를 갖는다"라는 약속이다.

b. Component

클라이언트에 미리 구현되어 있는 재사용 가능한 UI 단위이다. 서버는 이 컴포넌트의 ID와 Data를 내려준다.

c. Renderer

서버에서 내려온 JSON 데이터를 해석하여 실제 기기의 Native View나 Web Element로 변환해주는 역할을 한다.

 

[실제 데이터 예시: JSON Schema]

서버에서 아래와 같은 데이터를 내려준다고 가정해 보자.

{
  "page_name": "Home",
  "sections": [
    {
      "type": "BANNER_COMPONENT",
      "data": {
        "image_url": "https://americanopeople.tistory.com/event.png",
        "action": "app://event/123"
      }
    },
    {
      "type": "TEXT_LIST_COMPONENT",
      "data": {
        "title": "오늘의 추천 상품",
        "items": ["맥북 프로", "아이패드 에어"]
      }
    }
  ]
}

클라이언트는 이 JSON을 읽고, BANNER_COMPONENT로 선언된 UI 클래스에 이미지 URL을 주입하여 화면 최상단에 그린다.

 

4. 실무 적용 시 주의사항

여러 기업들이 SDUI를 사용하는 이유는 명확하지만, 도입 과정이 결코 쉽지는 않다. 다음 이슈들을 반드시 고려해야 한다.

• 하위 호환성 (Version Management): 서버에서 새로운 NEW_CARD 컴포넌트를 추가했는데, 구버전 앱을 사용하는 유저에게는 해당 컴포넌트가 없을 수 있다. 이때 앱이 죽지 않도록 Fallback(대체) UI 처리가 필수이다.
• 성능 문제 (Parsing & Rendering): UI 전체를 JSON으로 정의하다 보면 응답 데이터가 커질 수 있다. 복잡한 레이아웃을 런타임에 계산하므로 렌더링 성능 최적화가 중요하다.
• 디버깅의 어려움: UI 에러가 발생했을 때, 서버의 데이터 문제인지 클라이언트의 렌더러 로직 문제인지 파악하기가 기존보다 까다롭다. 

 

5. SDUI 설계를 위한 핵심 체크리스트

SDUI 아키텍처를 직접 설계하기 전, 다음 질문을 던져보면 좋다. 

1. 변경 빈도: 우리 서비스의 특정 화면이 주 단위 혹은 일 단위로 자주 변경되는가?
2. 표준화: UI 컴포넌트들이 디자인 시스템(Design System)으로 제공되어 있는가?
3. Fallback 전략: 정의되지 않은 타입의 컴포넌트가 들어왔을 때의 예외 처리가 설계되었는가?
4. 액션 핸들링: 클릭 이벤트(Deep Link, API Call 등)를 서버에서 어떻게 정의하고 제어할 것인가?
5. 검증 도구: 서버에서 보낸 JSON이 클라이언트에서 어떻게 보일지 미리 확인할 수 있는 '어드민 프리뷰'가 가능한가?

 

참고 문서

• 카카오페이: 콘텐츠를 조립하는 결제탭 피드 서버의 코드 아키텍처
• 카카오스타일: 코드 사례로 보는 Domain-Driven 헥사고날 아키텍처
• 카카오페이: Hexagonal Architecture, 진짜 하실 건가요?
• 올리브영: SDUI의 성능 병목을 넘어 - 올리브영 로컬 캐시 기반 백엔드 최적화 성공기
• 올리브영: SDUI로 네이티브 운영 민첩성 높이기 - 배포 없이 화면을 바꾸는 SDUI 설계·도입 과정
• 오늘의집 Serving Platform을 통해 비효율성 해소하기 

 

학습 프롬프트

# [1] 배경 (Context):
나는 현재 소프트웨어 개발자로서 애플리케이션의 업데이트 유연성을 높이고, 앱 스토어 심사 없이 UI를 변경할 수 있는 'SDUI(Server-Driven UI)' 아키텍처를 학습하고자 한다. SDUI가 무엇인지, 왜 필요한지, 그리고 실제 현업(Airbnb, Toss 등)에서 어떻게 활용되는지에 대한 포괄적인 지식이 필요하다.

# [2] 목표 (Objective):
SDUI의 개념, 장단점, 핵심 구성 요소(Schema, Component, Renderer), 그리고 간단한 구현 시나리오를 포함한 'SDUI 입문 및 심화 가이드'를 작성하라. 최종적으로 내가 SDUI 아키텍처를 설계할 때 고려해야 할 핵심 체크리스트를 도출하는 것이 목표이다.

# [3] 스타일 (Style):
기술 블로그의 'Deep Dive' 포스팅 스타일로 작성하라. 
- 서론: SDUI의 등장 배경과 정의
- 본론 1: 기존 Client-Side UI와의 차이점 비교 (표 활용)
- 본론 2: SDUI의 핵심 메커니즘 (데이터 구조와 렌더링 방식)
- 본론 3: 실무 적용 시 주의사항 (버전 관리, 성능 이슈 등)
- 결론: 학습자를 위한 로드맵 제언

# [4] 어조 (Tone):
전문적이고 분석적이면서도, 새로운 개념을 접하는 학습자가 이해하기 쉽게 설명하는 '친절한 기술 멘토'의 어조를 유지하라.

# [5] 독자 (Audience):
UI/UX 아키텍처에 관심이 있는 프론트엔드, 백엔드, 또는 모바일 앱 개발자.

# [6] 출력 형식 (Response Format):
- 마크다운(Markdown) 형식을 사용하여 가독성을 높일 것.
- 핵심 용어는 볼드체로 강조하고, 비교가 필요한 부분은 표(Table)를 사용할 것.
- 이해를 돕기 위한 간단한 JSON 스키마 예시 코드를 포함할 것.