HOxy, 프론트 개발자가 경험한 혹시 주도 개발(Feat: Server-Driven UI)

빠르게 변하는 서비스에서 Server-Driven UI가 왜 핵심이었나

HOxy(혹시) 개발을 진행하면서 가장 크게 필요했던 것은
UI 구조를 서버 정책 변화에 의존하게 만들지 않는 것,
즉 server-driven UI 기반의 확장 가능 구조였습니다.

기획 변경이 하루에도 몇 번씩 들어오는 환경에서
“앱을 다시 빌드해야만 반영되는 구조”는 더 이상 유지가 불가능했습니다.

그래서 프론트의 모든 UI 흐름을
정책 플래그, 서버 응답, 동적 레이아웃 정보로 제어할 수 있도록 만들었습니다.

아래는 실제로 활용했던 server-driven UI의 핵심 개념과 구현 방식 입니다. 간략하게 설명하고자 ~이다 체로 변경할께요 : )

Server-Driven UI가 필요한 이유

일반적인 모바일 앱에서 UI는 코드에 강하게 묶여 있다.

• 버튼 노출 조건
• 화면 이동 플로우
• 특정 상태의 예외 처리
• CTA 기능의 정책 변경
• 문구/레이아웃 변경

이 모든 것이 “코드 → 빌드 → 배포” 과정을 거쳐야 한다.

하지만 HOxy처럼 정책이 자주 바뀌는 서비스는 이 방식으로는 절대 따라갈 수 없다.
그래서 방향을 바꿨다:

‘UI는 서버가 결정하고, 앱은 렌더링만 한다’
이게 HOxy에서 적용한 server-driven UI 근간이다.

 

Server-Driven UI 구조 설계

1) Policy Layer: 정책을 하나로 묶는 중앙집중 모듈

가장 먼저 한 일은 정책·조건문·분기 로직을 모두 UI 컴포넌트에서 제거하는 것이었다.

대신 모든 정책은 아래 형태의 중앙 모듈에서 처리한다.

UI는 정책을 “실행”만 한다.

이렇게 되면:

• 정책이 바뀌면 정책 레이어만 수정
• 화면 코드 변경 없음
• 테스트 범위 명확해짐
• 서버 정책 변경 시 즉시 반영 가능

= 빌드 없는 정책 변경이 가능해진다.

 

2) Server Response 기반 UI 전략 자동화

정책 레이어가 방향을 잡아준다면,
실제 흐름은 서버 응답이 결정하게 만들었다.

예를 들어 서버 응답이 아래처럼 온다고 하자.

{
  "status": "BLOCKED",
  "nextAction": "OPEN_MODAL",
  "modalType": "VERIFICATION_REQUIRED"
}

 

앱에서는 아래처럼 자동으로 전략을 조립한다.

switch (response.status) {
  case 'BLOCKED':
    if (response.nextAction === 'OPEN_MODAL') {
      openModal(response.modalType);
    }
    break;
  case 'OK':
    navigate('Home');
}

 

 

즉,

• 어떤 모달을 띄울지
• 어떤 화면으로 이동할지
• CTA 버튼이 어떤 기능을 수행해야 하는지

전부 서버가 준 instruction대로 렌더링만 한다.

이 방식은 기획 변경이 심할수록 진가를 발휘한다.

 

이 구조가 결국 “주도 개발”을 만들어냈다

Server-Driven UI는 단순히 UI 기술이 아니라
서비스 전체 흐름을 설계하는 방식이다.

이 구조를 프론트에서 설계하면서 자연스럽게 이런 질문이 나에게 모이기 시작했다.

• 어떤 정책이 우선순위를 가져야 하는지
• API가 어느 범위까지 UI 정책을 책임져야 하는지
• 특정 사용자 상태에서 어떤 흐름이 맞는지
• 플래그 조합이 충돌할 때 어떤 전략을 띄워야 하는지

 

즉,
프론트에서 server-driven 구조를 설계하는 순간,
정책·기획·흐름·데이터 구조까지 책임지는
주도 개발의 중심에 서게 된다.

 

HOxy에서의 server-driven UI 도입은 단순히 “유연한 UI” 문제가 아니었다.

• 빠른 기획 변경 대응
• 재배포 없는 정책 수정
• UI 전략 자동화
• 예외 케이스 통일
• 모듈 단위 재사용성 증가
• 유지보수 비용 절감

그리고 무엇보다,

프론트엔드인 내가 서비스의 흐름을 정의하는 주체가 될 수 있게 만든 방식이었다.