• lxxjune

앱 업데이트 없이 UI를 바꾸는 시대

2026년 4월 18일

앱 업데이트 없이 UI를 바꾸는 시대

버튼 하나를 옮기는 데 앱 심사를 기다려야 한다고?

이 물음에서 SD UI는 출발했습니다.

SD UI란 무엇인가요?

SD UI, 풀네임으로 Server Driven UI는 이름 그대로입니다. UI를 누가 그리느냐를 묻는다면, 기존에는 “클라이언트(앱)”이 담당했습니다. 이제는 “서버”가 담당하는 것입니다.

좀 더 정확하게 설명하면, 전통적인 앱 개발 방식에서는 버튼의 위치, 리스트의 구성, 컴포넌트의 순서, 색상 이동 경로까지 모든 게 클라이언트 코드에 하드코딩 되어 있었습니다. 화면을 바꾸고 싶다면? 코드를 수정하고, 빌드하고, 앱스토어에 심사 요청을 넣고, 심사 통과를 기다리고, 사용자가 업데이트할 때까지 기다려야 했습니다. 길게는 몇 주가 걸리는 일이었습니다.

SD UI는 이 구조를 뒤집습니다. 서버가 UI의 구조와 동작을 JSON과 같은 포맷으로 정의해서 클라이언트에 전달하고, 클라이언트는 그 JSON을 해석해 화면을 그리는 역할만 합니다. 클라이언트는 “렌더링 엔진”이 되는 것이죠. 어떤 화면을 그릴지는 서버가 결정하고, 클라이언트는 그 지시대로 그리기만 하는 구조입니다.

예를 들어,

이런 데이터 파일을 받으면, 클라이언트는 type: CARD에 맞는 컴포넌트를 화면에 그립니다. 서버가 Type: BANNER로 바꾸면, 클라이언트는 앱 업데이트 없이 다른 UI를 그리게 됩니다.

SD UI는 프레임워크나 라이브러리가 아닙니다. 설치할 수 있는 패키지가 아니라, 팀이 합의해서 설계하는 아키텍쳐 패턴입니다. 그만큼 진입 장벽도 있고, 초기 설계에 들어가는 비용도 작지 않습니다. 하지만 한번 잘 만들어두면, 이후에 얻는 유연성은 엄청납니다.

SD UI는 왜 필요한가요?

솔직히 처음 들으면 좀 과도한 설게처럼 느껴질 수 있습니다. “그냥 코드 수정하고 배포하면 되잖아?” 하고 말이죠. 저도 그렇게 생각했던 적이 있습니다. 그런데 실제로 빠르게 성장하는 앱 서비스를 운영하다 보면, 기존 방식에서 벽이 느껴지기 시작하는 순간이 오게 됩니다.

첫 번째 벽: 앱 배포 주기

웹은 배포하면 바로 반영이 됩니다. 서버를 수정하면 사용자가 F5한 번 누르면 끝이 납니다. 그런데 네이티브 앱은 다릅니다. iOS라면 Apple의 심사 과정이 있고, Android도 Google Play의 검토를 거쳐야 합니다. 그것도 바로 통과하면 다행이고, 오류가 있으면 거절당하고 수정 후 재심사를 기다려야 합니다.

배포 후 버그를 발견했을 때에는 진짜 문제가 생깁니다. 버튼이 잘못된 위치에 있다거나, 특정 상황에서 화면이 이상하게 구성된다거나. 이미 스토어에 올라간 버전은 수정할 방법이 없습니다. 사용자가 알아서 업데이트해주기를 기다리는 수밖에 없습니다. SD UI가 있으면 서버에서 JSON만 바꾸면 됩니다. 앱 업데이트 없이 화면이 고쳐지게 되는 것이죠.

두 번째 벽: A/B Test의 어려움

좋은 제품팀일수록 실험을 많이 하는 것 같습니다. “버튼이 상단에 있을 때와 하단에 있을 때, 클릭률이 얼마나 차이날까?” “이 배너를 보여줬을 때 전환율이 올라갈까?” 같은 가설들을 빠르게 검증하고 싶은 경우,

기존 방식에서는 이 모든 실험이 클라이언트 코드 변경을 수반합니다. 디자이너가 디자인하고, 개발자가 구현하고, QA하고, 배포하고, 그다음에야 실험을 시작할 수 있습니다. 실험 하나에 몇 주가 걸리기도 하죠. SD UI에서는 서버에서 UI 구성을 바꾸는 것만으로 실험을 시작할 수 있습니다. 이를 통해 실험 속도를 크게 줄일 수 있습니다.

세 번째 벽: 크로스 플랫폼 일관성

같은 기능을 iOS, Android, Web 세 곳에 동시에 반영하는 일은 생각보다 복잡합니다. 각 플랫폼마다 구현 방식이 다르고, 배포 시점도 달라집니다. 서버에서 단일 응답으로 세 플랫폼을 동시에 제어할 수 있다면, 이 복잡성이 크게 줄어들게 됩니다.

네 번째 벽: 개인화의 한계

사용자마다 다른 화면을 보여주고 싶다면? 로그인 상태, 과거 행동 이력, 지역, 사용 기기, 시간대 등 이 모든 정보를 기반으로 맞춤 UI를 제공하고 싶다면, 클라이언트 코드에 그 로직을 다 담기는 어렵습니다. 서버에서 판단해서 각 사용자에게 맞는 UI 구성을 내려주는 게 훨씬 자연스러운 것이죠.

물론 SD UI가 만능은 아닙니다. 복잡한 드래그 앤 드롭 인터랙션이나 정교한 애니메이션이 필요한 경우, 오프라인에서 작동해야 하는 앱, 픽셀 퍼펙트 디자인이 필요한 화면에서는 적합하지 않습니다. 또한 초기 설계 비용이 크고, 서버 의존성이 높아지는 트레이드오프도 있습니다. 그래서 SD UI 도입을 고민할 때는 “우리 서비스가 지금 어떤 문제를 겪고 있는가”를 먼저 냉정하게 짚어봐야 합니다.

당근, 토스, 클래스 101, Airbnb는 SD UI를 어떻게 활용하고 있을까요?

이론보다 설득력 있는 건 실제 사례죠. 우리에게 친숙한 서비스들이 SD UI를 어떻게 구체적으로 활용하고 있는지 살펴보겠습니다.

당근

당근의 피드인프라팀은 2024년 12월, 당근 테크 블로그에 SD UI 도입기를 공개했습니다. 제목이 직관적입니다. “당근 홈 페드, Server Driven UI로 실험 이터레이션 빠르게 돌리기”.

당근 앱의 홈 화면은 중고거래, 동네생활, 모임, 알바 등 성격이 완전히 다른 콘텐츠들이 한 공간에 들어와 있습니다. 이 다양한 콘텐츠를 어떻게 배치하고, 어떤 형태로 보여줄지 실험하는 게 피드실의 핵심 업무라고 합니다.

문제는 기존 구조에서는 피드의 아이콘 하나를 바꾸거나 새로운 정보를 추가하고 싶어도 클라이언트 앱 배포를 기다려야 했다는 점입니다. 당근 블로그에서 피드실 엔지니어 Yeda는 이렇게 말합니다. "최근에는 클라이언트 의존도를 낮추고 서버에서 직접 요소를 컨트롤 할 수 있는 뷰타입을 만들었어요. 기존에는 피드에서 아이콘 하나를 바꾸거나 새로운 정보를 보여주고 싶어도 클라이언트 앱 배포를 기다려야 했는데, 서버와 클라이언트가 사전에 데이터 구조와 응답을 맞춰두고 서버가 직접 뷰타입을 컨트롤 할 수 있는 기반을 마련했어요."

당근의 접근 방식에서 흥미로운 점은, 기존 Viewtype 방식을 전면 교체하는 게 아니라 SDUI를 새로운 레이어로 추가해 점진적으로 확장하는 전략을 택했다는 것입니다. 처음부터 모든 걸 바꾸는 게 아니라, 실험이 자주 발생하는 구좌(피드 내 특정 위치)부터 SDUI로 전환하며 검증해나가는 방식이죠. Feed Infra팀은 관심피드를 ViewTemplate으로 구현하여 유저 실험을 내보냈고, UI 오류 제보가 없는 것을 확인한 후 확장을 이어가기로 했습니다.

당근 피드실은 사내에서 실험 플랫폼을 가장 많이 쓰는 조직 중 하나로, SD UI는 그 실험 속도를 더 빠르게 만드는 핵심 인프라가 되고 있는 것 같습니다.

토스

토스는 SD UI를 두 방향으로 적용하고 있습니다. 하나는 사용자가 보는 홈 화면이고, 다른 하나는 내부 운영에 쓰는 어드민 시스템입니다.

홈 화면 SD UI

토스 SLASH 23(2023년 토스 개발자 컨퍼런스)에서 "Server-driven UI로 다이나믹한 서비스 효율화하기"라는 세션이 공개됐습니다. 발표 소개에는 이렇게 쓰여 있습니다. "토스의 얼굴, 홈 화면에서의 매끄러운 사용자 경험은 어디에서 비롯되는 것일까요? 다양한 서비스 운영 효율화를 위한 토스 홈팀의 무기, Server Driven UI를 소개합니다."

토스의 홈팀은 기존 "데이터 기반 설계"의 한계를 이렇게 정리합니다. 홈 화면에 기능을 배포할 때마다 사용자는 최신 버전으로 앱을 업데이트해야 하고, 클라이언트에서 버그가 발생하면 또 앱을 업데이트해야 합니다. 게다가 클라이언트가 여러 서버로부터 데이터를 받아 취합해서 화면을 표시하기 때문에 디버깅도 어렵습니다. 토스는 이 문제를 SD UI로 풀어냅니다. 서버에서 클라이언트에게 "화면을 이렇게 표시해달라"고 전달하고, 클라이언트는 단순히 그 내용을 화면에 표시하기만 하는 방식이죠.

어드민 SD UI

SLASH 23의 또 다른 세션인 "Server-driven UI로 토스의 마지막 어드민 만들기"에서는 내부 어드민 시스템에 SD UI를 적용한 사례를 소개합니다. 토스는 DSL(도메인 특화 언어)을 기반으로 화면과 정책을 정의하는 어드민 시스템을 구축했습니다. 고객의 민감한 정보를 다루는 어드민 특성상, 권한 관리와 정책 변경이 매우 빈번하게 필요한데, 이를 SD UI 방식으로 관리함으로써 안전하고 빠른 운영이 가능해지게 되었습니다.

제가 이 사례에서 흥미롭게 본 부분은, 토스가 SD UI를 모바일 앱의 배포 지연 문제를 해결하는 것 이상으로 내부 어드민이라는 완전히 다른 도메인에도 적용했다는 점입니다. SD UI는 모바일만의 이야기가 아닌 것입니다.

클래스 101

클래스101은 GraphQL을 핵심 기술로 채택한 서비스로 잘 알려져 있습니다. 클래스101 기술 블로그의 "GraphQL 여정기"에서 이 구조를 자세히 소개하고 있는데, 클래스101의 접근은 SD UI와 GraphQL의 특성을 적극적으로 결합한 형태입니다.

클래스101에서는 Apollo Server를 BFF(Backend-For-Frontend) 서비스로 운영하고 있습니다. 이 구조에서 각 도메인별 백엔드 서비스는 자신의 영역만 책임지고, BFF 레이어가 클라이언트가 필요로 하는 형태로 데이터를 조합해 응답합니다. 클라이언트는 화면에 필요한 데이터 구조를 직접 질의할 수 있고, 불필요한 데이터를 받지 않게 됩니다.

이 구조는 SD UI와 자연스럽게 연결됩니다. 홈 화면처럼 다양한 콘텐츠(클래스, 컬렉션, 배너, 크리에이터)가 혼재하는 페이지에서, 서버가 어떤 컴포넌트를 어떤 순서로 보여줄지를 GraphQL 응답 구조로 정의하고 내려줄 수 있습니다. 클라이언트는 응답에 담긴 컴포넌트 타입을 보고 해당 UI를 렌더링하는 방식이죠.

제가 클래스101 사례에서 특히 주목한 것은, GraphQL의 Union Type 활용입니다. 홈 화면에 들어올 수 있는 다양한 콘텐츠 블록들을 Union Type으로 정의하면, 서버는 어떤 타입의 블록을 내려줄지 자유롭게 결정할 수 있고, 클라이언트는 각 타입에 맞는 컴포넌트를 렌더링하기만 하면 됩니다. 바로 SD UI의 핵심 아이디어와 같은 구조입니다..

클래스101은 GraphQL을 단순히 데이터 쿼리 도구로 쓰는 게 아니라, 화면 구성의 유연성을 확보하는 아키텍처 레이어로 활용하고 있습니다. 이것이 클래스101의 독특한 지점입니다.

Airbnb

SD UI를 이야기할 때 Airbnb를 빠뜨릴 수 없을 것 같습니다. 어떻게 보면 오늘날 업계의 SD UI 붐을 만든 장본인이기 때문입니다. 2021년 Airbnb 엔지니어링 블로그에 올라온 "A Deep Dive into Airbnb's Server-Driven UI System" 글은 지금도 가장 많이 읽히는 SD UI 관련 아티클 중 하나입니다.

Airbnb의 SD UI 시스템은 Ghost Platform(GP)이라는 이름을 가지고 있습니다. 이름의 유래가 재밌는데, Airbnb의 두 주요 사용자 그룹인 Guest(게스트)와 Host(호스트)를 합친 이름입니다. 즉, GP는 게스트와 호스트 경험 전반을 서버에서 제어하겠다는 의지를 담고 있는 것 같습니다.

GP의 구조는 이렇게 됩니다. Section, Screen, Action이라는 세 개의 핵심 개념을 중심으로 구성됩니다. Section은 독립적이고 재사용 가능한 UI 컴포넌트입니다. Screen은 Section들이 어떻게 배치될지를 정의하죠. Action은 사용자의 인터랙션(버튼 클릭, 화면 이동 등)을 처리합니다.

무엇보다 인상적인 건 단일 GraphQL 스키마로 웹, iOS, Android를 동시에 제어한다는 점입니다. Airbnb의 백엔드는 동일한 응답 하나로 세 플랫폼에서 동시에 화면 구성, 섹션 배치, 데이터 표시 방식, 사용자 인터랙션까지 모두 제어합니다. 이것은 어떤 의미냐면, 새로운 기능을 출시할 때 iOS 팀, Android 팀, Web 팀이 따로따로 구현하고 각자 배포 일정을 맞추는 대신, 서버 팀이 한 번 구현하면 세 플랫폼에 동시에 반영되는 것입니다.

Airbnb 엔지니어 Ryan Brooks는 GP를 "반복 개발을 빠르게 하고 기능을 안전하게 출시하기 위한 통합된, 의견이 담긴 SD UI 시스템"이라고 소개합니다. 현재 Ghost Platform은 Airbnb의 검색, 숙소 상세 페이지, 결제 흐름 등 가장 중요한 화면들의 대부분을 담당하고 있습니다.

Airbnb가 이 아키텍처를 구축하기까지 "수많은 시간을 들여 견고한 스키마, 클라이언트 프레임워크, 개발자 문서를 만들었다"고 솔직하게 밝히고 있었습니다. SD UI가 얼마나 무겁고 진지한 결정인지를 보여주는 대목이며, 쉽게 따라 할 수 있는 게 아니라는 것입니다.

SD UI는 기술이 아니라 철학입니다.

SD UI를 공부하면 공부할수록 느끼는 게 있습니다. 이것은 단순히 “서버에서 JSON 내려주는 기술”이 아닙니다. 근본적으로는 “누가 제품의 속도를 통제해야 하는가”에 대한 질문입니다.

기존 방식에서는 클라이언트 배포 일정이 제품 출시 속도를 결정합니다. SD UI에서는 서버가 그 속도를 쥐게 됩니다. 실험을 더 빠르게 돌릴 수 있고, 버그를 더 빠르게 수정할 수 있고, 개인화를 더 정교하게 제공할 수 있죠.

그러나 제가 강조하고 싶은 건, SD UI는 도입 비용이 결코 작지 않다는 것입니다. 서버와 클라이언트 간의 UI 스키마를 설계하고, 렌더링 엔진을 구현하고, 어드민 시스템을 만들고, 버전 관리 전략을 세우고, 예외 처리와 폴백을 꼼꼼히 다뤄야 합니다. 당근처럼 점진적으로 적용 범위를 넓히거나, Apollo GraphQL 문서에서 권고하는 것처럼 하나의 컴포넌트나 기능부터 시작하는 전략이 중요해 보입니다.

SD UI가 진가를 발휘하는 조건은 분명합니다. 자주 바뀌고, 빠른 실험이 필요하고, 여러 플랫폼에 동시에 반영해야 하는 서비스입니다. 당근의 홈 피드, 토스의 메인 화면, Airbnb의 숙소 상세 페이지 등이 그런 조건이 될 수 있을 것 같습니다.

만약, 우리 서비스가 그런 조건에 해당한다면, SD UI는 진지하게 검토해볼 만한 선택지인 것 같습니다. 그리고 아직은 아닌 것 같다면, 이 아키텍처를 이해하고 언젠가 벽에 부딪혔을 때, SD UI가 그 벽을 넘는 방법으로 활용되면 좋을 것 같습니다.


참고 자료:

의견 남기기
lxxjune