오늘은 요즘 빅테크 기업들이 정말 많이 도입하고 있는 서버 드라이븐 아키텍처(Server-Driven Architecture, SDA), 흔히 말하는 **서버 드라이븐 UI(SDUI)**에 대해 이야기해볼게. 매번 앱 스토어 심사 기다리느라 지쳤거나, 기획이 바뀔 때마다 클라이언트 코드를 새로 배포해야 했던 경험이 있다면 이 개념이 아주 흥미로울 거야.
1. 서버가 화면을 그리라고 명령한다?
기존의 개발 방식은 클라이언트가 화면의 구조(UI)를 다 알고 있고, 서버에서는 오직 데이터만 받아와서 끼워 넣는 방식이었잖아. 반면에 서버 드라이븐 아키텍처는 서버가 데이터뿐만 아니라 **"어떤 컴포넌트를 어떤 순서로 배치해야 하는지"**에 대한 UI 구조(Schema)까지 결정해서 내려주는 방식이야.
예를 들어 서버가 {"type": "Banner", "imageUrl": "..."} 같은 JSON 데이터를 보내주면, 클라이언트는 미리 정의해 둔 Banner 컴포넌트를 렌더링하는 거지. 이렇게 하면 클라이언트 코드를 한 줄도 수정하지 않고, 오직 서버의 JSON 응답만 바꿔서 화면의 디자인이나 배치를 실시간으로 바꿀 수 있게 돼.
2. 실무에서 설계하는 데이터 계약서(Contract)
내가 연차가 쌓이면서 느낀 건, SDA의 핵심은 결국 **클라이언트와 서버 간의 단단한 규약(Contract)**이라는 점이야. 보통 실무에서는 화면을 크게 세 가지 요소로 나누어 설계하곤 해.
- 스크린(Screens): 전체 화면의 레이아웃 정보
- 섹션(Sections): 화면을 구성하는 독립적인 컴포넌트 단위 (배너, 리스트 등)
- 액션(Actions): 버튼을 눌렀을 때 일어날 동작 (페이지 이동, API 호출 등)
이 규약을 촘촘하게 정의해 두지 않으면, 서버 개발자가 JSON 구조를 조금만 바꿔도 클라이언트에서 바로
Crash가 날 수 있거든. 그래서 초기 설계 단계에서 스키마 버전을 관리하는 규칙을 아주 엄격하게 세워야 해.
3. 9년차 시니어가 알려주는 현실적인 도입 팁
내가 9년 동안 프론트엔드 생태계를 겪어보니까, 아무리 좋은 기술도 모든 곳에 적용하면 독이 되더라고. SDA도 마찬가지야. 화면 전체를 서버 드라이븐으로 만들려고 하면 개발 난이도가 안드로메다로 가버려. 디버깅도 엄청나게 힘들어지고 말이지.
그래서 처음에는 변경이 잦은 특정 영역에만 부분적으로 도입하는 걸 추천해. 홈 화면의 이벤트 배너 영역이나, 매주 기획이 바뀌는 추천 상품 리스트 같은 곳이 가장 좋은 시작점이야. 정적인 페이지는 기존 방식대로 유지하고, 동적인 제어가 꼭 필요한 곳에만 SDUI 구조를 녹여내는 것이 실무에서 가장 안전하게 성공하는 방법이야.
💡 핵심 정리
- 개념: 서버가 UI 구조와 데이터를 JSON 형태로 정의해 클라이언트에 내려주는 아키텍처야.
- 장점: 앱 스토어 심사 없이 화면 레이아웃과 컴포넌트를 실시간으로 업데이트할 수 있어.
- 주의점: 서버와 클라이언트 간의 엄격한 버전 관리와 스키마 규약이 필수적이고, 부분적 도입이 안전해. 새로운 기술 트렌드라고 해서 무작정 전체를 다 바꾸려고 조급해할 필요는 없어. 내가 담당하는 서비스에서 "어떤 부분이 가장 자주 바뀌고 배포 병목을 만드는지" 먼저 고민해보고, 그 부분부터 차근차근 적용해봐. 이 고민을 해보는 것 자체가 너를 한 단계 더 성장한 개발자로 만들어줄 테니까 말이야.