|| WORXPHEREScreen과 Section, 두 계층 구조로 유연한 화면 관리하기들어가며
안녕하세요, 저희는 잡코리아에서 통합 전시 시스템 백엔드 개발을 담당하고 있습니다. 
홈 화면에 추천 공고 섹션 하나를 추가하는 데 iOS, Android, Web 세 곳의 코드를 각각 수정하고, 스토어 심사를 기다려야 했던 경험. 아마 앱 서비스를 운영해본 분이라면 한 번쯤 겪어보셨을 겁니다.
저희도 마찬가지였습니다. 기획팀에서 “내일까지 홈 화면에 추천 공고 섹션을 추가해주세요”라는 요청이 올 때마다 돌아오는 대답은 항상 같았습니다. “앱은 스토어 심사가 있어서 최소 3일은 걸립니다.” 빠르게 변화하는 채용 시장에서 이 속도는 분명한 병목이었습니다.
웹뷰를 고려하기도 했지만, 네이티브 사용자 경험을 포기하고 싶지 않았습니다. 결국 저희가 선택한 답은 Server-Driven UI(SDUI) 였습니다. 서버가 화면의 구성을 제어하고, 클라이언트는 그 설계도를 받아 렌더링에 집중하는 방식입니다.
이 글에서는 저희가 SDUI를 왜 도입했고, 어떤 고민을 거쳐 Screen과 Section이라는 구조를 설계했는지 공유하려 합니다.
SDUI란 무엇인가?
SDUI(Server-Driven UI)는 서버가 UI의 구조와 레이아웃을 JSON 형태의 스키마로 정의하여 클라이언트에 전달하고, 클라이언트는 그 스키마를 해석해 화면을 렌더링하는 아키텍처 패턴입니다.
기존 방식에서는 UI 로직이 클라이언트에 하드코딩되어 있습니다. SDUI에서는 그 주도권이 서버로 이동합니다.
[기존방식] 클라이언트 → 서버: "데이터 줘"
서버 → 클라이언트: { data: ... }
클라이언트: UI를 직접 결정해서 렌더링
[SDUI] 클라이언트 → 서버: "이 화면 어떻게 그릴까?"
서버 → 클라이언트: { type: "CAROUSEL_CARD", data: ..., action: ... }
클라이언트: 서버가 시키는 대로 렌더링
기존 방식에서 클라이언트는 데이터를 받아 스스로 화면을 결정하지만, SDUI에서 클라이언트는 서버가 내려준 스키마대로 그리는 렌더링 엔진 역할에 집중합니다. 화면의 구성, 순서, 타입은 모두 서버가 결정합니다.
왜 SDUI인가?
채용 플랫폼을 운영하면서 저희가 반복적으로 마주한 문제들이 있었습니다.
기존 문제 → SDUI로 해결
공고 카드/UI 수정마다 앱 재배포 + 스토어 심사 → 서버 배포만으로 즉시 반영
iOS / Android / Web 각각 개발 → 단일 JSON 스키마로 전 플랫폼 통일
A/B 테스트를 위한 플랫폼별 배포 → 서버에서 스키마만 바꾸면 즉시 실험 가능
화면마다 비슷한 컴포넌트 반복 개발 → 컴포넌트 재사용으로 개발 비용 절감
Screen과 Section: 계층적 화면 구조의 핵심
통합 전시 시스템의 SDUI는 Screen(화면) 과 Section(섹션) 이라는 두 계층으로 설계되었습니다.
처음부터 이 구조가 나온 것은 아닙니다. 초기에는 화면 전체를 하나의 JSON으로 관리하는 방식도 검토했지만, 화면 수가 늘어날수록 중복이 심해지고 수정 범위가 커지는 문제가 예상되었습니다. 결국 “화면 전체”와 “화면을 구성하는 블록”을 분리하는 것이 재사용성과 유지보수 측면에서 유리하다는 결론에 도달했습니다.
Screen: 전체 화면 컨테이너
Screen은 사용자가 보는 하나의 독립적인 화면(페이지)을 정의하는 최상위 단위입니다. 클라이언트는 Screen 객체를 기반으로 어떤 Section들을 어떤 순서로 배치할지 판단하게 됩니다.
저희는 동일한 화면 타입(예: HOME)이라도 다양한 조건에 따라 다른 화면 구성을 제공할 수 있도록 Screen을 설계했습니다. 사이트별(잡코리아/알바몬), 디바이스별(모바일앱/PC/모바일웹), 사용자 세그먼트별(신입/주니어/시니어), A/B 테스트 그룹별로 각각 독립적인 Screen을 정의할 수 있습니다.
Screen
├──
홈 화면에 추천 공고 섹션 하나를 추가하는 데 iOS, Android, Web 세 곳의 코드를 각각 수정하고, 스토어 심사를 기다려야 했던 경험. 아마 앱 서비스를 운영해본 분이라면 한 번쯤 겪어보셨을 겁니다.
저희도 마찬가지였습니다. 기획팀에서 “내일까지 홈 화면에 추천 공고 섹션을 추가해주세요”라는 요청이 올 때마다 돌아오는 대답은 항상 같았습니다. “앱은 스토어 심사가 있어서 최소 3일은 걸립니다.” 빠르게 변화하는 채용 시장에서 이 속도는 분명한 병목이었습니다.
웹뷰를 고려하기도 했지만, 네이티브 사용자 경험을 포기하고 싶지 않았습니다. 결국 저희가 선택한 답은 Server-Driven UI(SDUI) 였습니다. 서버가 화면의 구성을 제어하고, 클라이언트는 그 설계도를 받아 렌더링에 집중하는 방식입니다.
이 글에서는 저희가 SDUI를 왜 도입했고, 어떤 고민을 거쳐 Screen과 Section이라는 구조를 설계했는지 공유하려 합니다.
SDUI란 무엇인가?
SDUI(Server-Driven UI)는 서버가 UI의 구조와 레이아웃을 JSON 형태의 스키마로 정의하여 클라이언트에 전달하고, 클라이언트는 그 스키마를 해석해 화면을 렌더링하는 아키텍처 패턴입니다.
기존 방식에서는 UI 로직이 클라이언트에 하드코딩되어 있습니다. SDUI에서는 그 주도권이 서버로 이동합니다.
[기존방식] 클라이언트 → 서버: "데이터 줘"
서버 → 클라이언트: { data: ... }
클라이언트: UI를 직접 결정해서 렌더링
[SDUI] 클라이언트 → 서버: "이 화면 어떻게 그릴까?"
서버 → 클라이언트: { type: "CAROUSEL_CARD", data: ..., action: ... }
클라이언트: 서버가 시키는 대로 렌더링
기존 방식에서 클라이언트는 데이터를 받아 스스로 화면을 결정하지만, SDUI에서 클라이언트는 서버가 내려준 스키마대로 그리는 렌더링 엔진 역할에 집중합니다. 화면의 구성, 순서, 타입은 모두 서버가 결정합니다.
왜 SDUI인가?
채용 플랫폼을 운영하면서 저희가 반복적으로 마주한 문제들이 있었습니다.
기존 문제 → SDUI로 해결
공고 카드/UI 수정마다 앱 재배포 + 스토어 심사 → 서버 배포만으로 즉시 반영
iOS / Android / Web 각각 개발 → 단일 JSON 스키마로 전 플랫폼 통일
A/B 테스트를 위한 플랫폼별 배포 → 서버에서 스키마만 바꾸면 즉시 실험 가능
화면마다 비슷한 컴포넌트 반복 개발 → 컴포넌트 재사용으로 개발 비용 절감
Screen과 Section: 계층적 화면 구조의 핵심
통합 전시 시스템의 SDUI는 Screen(화면) 과 Section(섹션) 이라는 두 계층으로 설계되었습니다.
처음부터 이 구조가 나온 것은 아닙니다. 초기에는 화면 전체를 하나의 JSON으로 관리하는 방식도 검토했지만, 화면 수가 늘어날수록 중복이 심해지고 수정 범위가 커지는 문제가 예상되었습니다. 결국 “화면 전체”와 “화면을 구성하는 블록”을 분리하는 것이 재사용성과 유지보수 측면에서 유리하다는 결론에 도달했습니다.
Screen: 전체 화면 컨테이너
Screen은 사용자가 보는 하나의 독립적인 화면(페이지)을 정의하는 최상위 단위입니다. 클라이언트는 Screen 객체를 기반으로 어떤 Section들을 어떤 순서로 배치할지 판단하게 됩니다.
저희는 동일한 화면 타입(예: HOME)이라도 다양한 조건에 따라 다른 화면 구성을 제공할 수 있도록 Screen을 설계했습니다. 사이트별(잡코리아/알바몬), 디바이스별(모바일앱/PC/모바일웹), 사용자 세그먼트별(신입/주니어/시니어), A/B 테스트 그룹별로 각각 독립적인 Screen을 정의할 수 있습니다.
Screen
├──