출처: https://kciter.so/posts/modeling-series-view-model/
뷰모델, 단순한 데이터 전송을 넘어: 서버-클라이언트 협업 비용을 절감하는 4가지 설계 원칙
Introduction: The Hidden Cost of Simple Data Transfer
서버와 클라이언트 개발자가 API 응답 형식을 정의할 때 흔히 겪는 소모적인 논의가 있음
"이 필드 이름은 뭘로 할까요?", "데이터는 어떤 순서로 내려주시나요?", "이 값은 어떻게 포맷해서 보여줘야 하나요?" 등 사소해 보이지만, 반복되는 질문들은 개랍 과정에서 적지 않은 커뮤니케이션 비용을 발생함
많은 경우, 이 문제의 근원은 API 응답 모델을 단순한 '데이터 전달 객체'로만 여기는 관행에 있음
하지만 뷰 모델을 서버와 클라이언트 간의 명확한 계약서로 바라본다면 어떨까?
잘 설계된 뷰모델은 단순한 데이터 덩어리릉 넘어, 화면이 어떠헥 ㅜ것ㅇ되고 동작해야하 하는ㅈ에 대한 상세한 명세가 될 수 있음
이는 개발자 간의 불필요한 소통을 극적으로 줄이고, 전체적인 생산성을 향상시키는 강력한 도구가 됨.
1. 뷰모델은 데이터가 아닌 '뷰의 추상화'이다.(A ViewModel is an 'Abstraction of the View', Not Just Data)
가장 흔한 오해 중 하나는 뷰모델을 서버에서 클라이언트로 전달되는 단순한 JSON 데이터로 취급하는 것.
사실 단순히 데이터를 JSON으로 내려주는 것도 일종의 뷰모델이라고 할 수 있음
문제는 그것이 뷰를 추강화한다는 자각 없이 데이터만을 내려주는 경우가 많다는 점.
핵심적인 패러다인 전환은 뷰모델을 뷰를 추상화하여 필요한 정보를정리한 것 으로 정의하는데서 시작됨.
이는 뷰모델이 단순히 사용자에게 보여줄 데이터 뿐만 아니라, 뷰의 배치 방식, 사용자의 상호작용데 따른 결과, 그리고 색상이나 폰트 같은 시작적 요소까지도 포함해야 한다는 의미.
이러한 관점의 변화는 뷰모델 설계의 모든 것을 바꾸는 기초가 됨.
데이터를 넘어 뷰 자체를 의시적으로 모델링하믕로써 우리는 훨씬 더 효율적이고 유지보수가 용잉한 시스템을 구축할 수 있느 첫 걸음을 떼게 됨.
2. 완벽한 뷰모델을 위한 4가지 설계 요소: 상태, 구조, 동작, 스타일
뷰를 효과적으로 추상화하기 위해ㅏ 우리는 뷰를 구성하는 핵심 요소들을 체계적으로 분해하고 모델링해야함.
포괄적인 뷰모델을 설계하기 위한 4가지 핵심 구성 요소를 제시
- 상태: 뷰에서 사용자에게 직접 보여주는 값. 예를 들어, 사용자의 이름이나 나이 같은 데이터.
- 구조: 뷰의 레이아웃, 테이블의 경우 Column과 Row, Cell로 나뉘는 것과 같은 구조적 정보를 의미.
- 동작: 사용자의 상호작용에 대한 정보. 특정 버튼을 클릭했을 때, 어떤 동작이 일어나야하는지에 대한 명세를 포함.
- 스타일: 뷰의 시각적 표현. 색상 , 폰트, 크기, 등 디자인과 관련된 정보를 말함.
이 4가지 요소를 설계의 기본 프레임워크로 삼음으로써, 개발자는 단순한 데이터 객체를 넘어 훨ㅆ니 더 견고하고 표현력이 풍부한 뷰모델을 체계적으로 만들어낼 수 있음
중요한 점은 이 4가지 요소가 서로 독립적이지 않으며, 실제 뷰모델 설계에서느 이들을 유기적으로 조합하여 사용해야 한다는 것.
3. 오해의 여지를 없애는 명시적인 계약서 만들기.
// 오해의 여지가 있는 구조
[
{ "name": "홍길동", "age": 32, "status": "ACTIVE" },
{ "name": "김영희", "age": 27, "status": "INACTIVE" }
]- 이러헥 넘긴 값은 클라이언트가 해석할 필요가 있다.
- 한 마디로 추상화 레벨이 높다. -> 다양하게 해석될 여지가 있다.
- 좋은 모델은 다양하게 재사용할 수 있으면서 오해석할 여지를 줄인다.
- 테이블 뷰모델을 설계한다면 오로지 다양한 테이블 뷰에 사용되도록 설계하는 것이 좋음
테이블 뷰는 단순히 리스트를 나열하는 것이 아니다.
- 구조
- 컬럼 정의
- 컬럼의 타입과 포맷
- 값 표시 방법
- 정렬
- 페이지네이션
- 셀 병합
- 필터링
- 선택
- 드래그 앤 드롭
- ...
많은 경우 뷰를 위한 정보는 요구사항, 디자인 단계에서 확정된다. 하지마 ㄴ백엔드 코드엔 오직 데이터만 포함되고 그 외 정보는 오직 클라이언트 코드에만 포함될 뿐이다.
하지만 백엔드에서 뷰모델을 설계하고 이에 대한 처리 로직을 구현한다면 요구사항에 맞춰서 유연하게 변경 대처할 수 있다.
{
// 컬럼
"columns": [
{ "id": "name", "label": "이름", "type": "TEXT" },
{ "id": "age", "label": "나이", "type": "NUMBER" },
{ "id": "status", "label": "상태", "type": "TEXT" }
],
// 데이터
"rows": [
{ "name": "홍길동", "age": 32, "status": "ACTIVE" },
{ "name": "김영희", "age": 27, "status": "INACTIVE" }
]
}- 위와 같이 내려주면, 클라이언트는 어떤 컬럼이 있는지
- 컬럼 순서가 어떻게 되는지,
- 필드의 타입은 무엇인지,
- 어떻게 보여줘야 하는지에 대한 정보를 모두 할 수 있다.
{
"sortable": true,
"columns": [
{ "id": "name", "label": "이름", "type": "TEXT", "align": "left", "sortable": true },
{ "id": "age", "label": "나이", "type": "NUMBER", "align": "right", "sortable": true },
{ "id": "status", "label": "상태", "type": "TEXT", "align": "center", "sortable": false }
],
"rows": [
{
"cells": [
{ "columnId": "name", "value": "홍길동" },
{ "columnId": "age", "value": 32, "displayValue": "32세" },
{ "columnId": "status", "value": "ACTIVE" }
],
"style": { "backgroundColor": "#f0f0f0" }
},
{
"cells": [
{ "columnId": "name", "value": "김영희" },
{ "columnId": "age", "value": 27, "displayValue": "27세" },
{ "columnId": "status", "value": "INACTIVE" }
],
"style": { "backgroundColor": "#ffffff" }
}
...
],
"pagination": {
"page": 1,
"totalPage": 10,
"pageSize": 20
},
}- 정리하자면 뷰모델을 설계할 때는 언제나 뷰에 어떤 정보가 있느지르 생각해야한다.
그리고 이 정보에서 필요한 것을 뽑아 어떻게 추상화할 수 있을지 고민해야한다.
하나의 뷰모델에서 여러 뷰를 만들 수 있다는 것을 기억하자.
4. 뷰모델의 궁극적인 진화: 서버 주도 UI
뷰의 상태, 구조, 동작, 스타일까지 모두 서버에서 정의하여 내려주는 상세한 뷰모델 설계 철학을 끝까지 밀어 붙이면 ㅅ버ㅓ주고 UI라는 개념에 도달하게 됨
SDUI는 이 설계 철학의 논리적 귀결점
서버가 UI 컴포너트들의 조합을 API 응답으로 내려주면, 클라이언트는 이르 해석해서 화면을 그리기만 하는 방식.
이러한 접근 방식은 Airbnb, 카카오 스타일, 오늘의 집과 같은 유수 기업에서 UI 변경 속도를 높이고, 개인화된 경험을 제공하기 위해 활발히 사용되고 있음.
- 장점: 서버 코드 배포만으로 UI를 즉시 변경할 수 있어 신속한 대응이 가능함. A/B 테스트나 사용자 맞춤형 UI를 제공하기에도 훨씬 용이
- 단점: 매우 높은 수준의 추상화가 필요하며, 엄격한 규칙과 관리가 없다면 오히려 생산성을 해칠 수 있음. 또한, 로딩 시간이나 오류 처리 등 고려해야할 기술적 과제가 많음.
결론: JSON 상하차에도 기술이 있습니다.
뷰모델 설계는 서버-클라이언트 협업의 성패를 좌우하는 정교한 계약서 작성 행위입니다.
양측의 오해를 줄이고 생산성을 극대화하기 위한 명확한 명세를 만드는 과정.
