안녕하세요! ARCOA 지안입니다. 👋
지난 글에서 ‘DB 설계는 UX 설계의 뒷면’이라는 이야기를 나눴다면, 오늘은 그 뒷면 중에서도 앱 세계를 떠받치는 뼈대—정적 데이터(Static Data)를 살펴보려고 합니다.
UI만 다루던 디자이너가 실제로 앱을 만들기 시작하면 가장 먼저 맞닥뜨리는 질문이 있어요.
화면보다, 데이터부터 만든다고?
맞습니다.
특히 정적 데이터는 ‘화면’보다 앞서 존재해야 하는 앱의 룰북(Rulebook)입니다.
1/ 정적 데이터란?
정적 데이터는 앱의 ‘설정값’, ‘기준표’, ‘변하지 않는 규칙’을 담고 있는 기본 세계관입니다.
- 동적 데이터: 매일 바뀌는 데이터
(회원 정보, 기록, 로그, 검색 요청 등) - 정적 데이터: 앱의 로직과 기준을 정의하는 데이터
(카테고리 구조, 옵션 목록, 점수 기준표, 멤버십 조건 등)
디자이너에게 익숙한 용어로 표현하면,
정적 데이터 = 디자인 시스템에서 ‘토큰 + 규칙’에 해당하는 개념
동적 데이터 = 사용자가 실제로 생성하는 컴포넌트들
정적 데이터를 먼저 설계해야 화면·로직·액션이 흔들리지 않는 이유예요.
2/ 정적 데이터 설계의 시작: “쪼개기”
디자이너는 보통 화면에 있는 텍스트부터 생각합니다. 하지만 노코드 개발에서는 ‘데이터를 먼저 쪼개야’ 안정적인 화면이 만들어집니다. 예를 들어 전형적인 카테고리 기반 앱이라면 다음과 같이 나눌 수 있습니다.
- Category – 대/중/소 카테고리
- Options / Attributes – 정렬 옵션, 필터 옵션
- Score Rules – 점수 산정 기준
- Master Data – 카드 정보, 브랜드 정보, 서비스 정의
TIP 여기서 중요한 점
✔️ 하드코딩된 텍스트 = 나중에 100% 후회
“쇼핑”, “푸드”, “뷰티” 같은 텍스트를 화면에 직접 넣으면, 카테고리 변경이 있을 때 모든 화면을 뒤집어엎어야 함
✔️ 참조 가능한 Static 데이터 = 유지보수 비용 1/10
Category 테이블에서 이름만 바꾸면, 앱 전체 화면이 자동으로 바뀜
3/ 데이터 간 관계 설계하기: 앱 자동화의 핵심
“정적 데이터는 사람이 판단해야 할 일을 시스템이 대신 판단하게 만든다.”
정적 데이터에서 가장 중요한 작업은 ‘관계(Reference)’를 정의하는 과정입니다.
예를 들어:
- Category(대분류) → SubCategory(중/소분류)
- Category → Score Rule 매칭
- Card → Benefit 매칭
이렇게 관계가 정의되어 있으면 운영자가 실수할 여지가 거의 없습니다.
정확한 구조를 만들어두면 운영자가 “어떤 로직을 적용해야 하지?”를 고민할 필요가 없어요.
업데이트는 데이터만 건드리면 되고, 로직은 자동으로 흘러갑니다.
4/ Naming & Type: 디자이너 감각 그대로 DB에 적용하기
디자인 시스템에서 component/Button/Primary/Large 같은 규칙을 정리하듯, DB에서도 같은 원칙을 적용해야 합니다.
Naming Rule:
- category_name을 썼다면
- product_name, brand_name처럼 _name 규칙 유지
- CamelCase, snake_case 중 하나를 반드시 통일
Type Rule: 가장 많이 실수하는 부분!
- 숫자는 Number
- true/false는 Boolean
- 날짜는 Timestamp
- 복합 정보는 JSON
- 외부 참조는 DocumentReference
타입을 잘못 잡으면 나중에 불가능한 로직이 생기고, “왜 계산이 이상하게 나오지?” 같은 버그 지옥에 빠지게 됩니다.
5/ 맺음: 정적 데이터는 변하지 않는 약속
“정적 데이터는 앱이 약속하는 정의(Definition)다.”
“정적 데이터가 탄탄하면 사용자의 동적 데이터는 흐름만 따라가면 된다.”
정적 데이터는 ‘세계관’, 동적 데이터는 그 안에서 사용자가 만들어가는 ‘스토리’입니다.
그리고 좋은 앱은 세계관이 먼저 완성된 앱입니다.
디자이너를 위한 한 줄 요약
디자인 시스템이 UI의 규칙을 만들듯,
정적 데이터는 서비스 로직의 규칙을 만든다.
다음 글
✦ 비개발자를 위한 노코드 DB 설계
├ 1 ✦ DB 설계는 UX 설계의 뒷면이다 완료
├ 2 ✦ 정적 데이터는 제품의 룰북이다 완료
├ 3 ✦ 동적 데이터로 사용자의 흔적을 설계하다
├ 4 ✦ Firestore 매핑으로 프로덕트 신경망 구축
└ 5 ✦ 디자이너가 데이터로 말하는 법
다음 글은 사용자의 행동이 어떻게 데이터로 남고, 로그·히스토리·상태 관리가 어떤 구조로 구축되는지 실제 사례를 중심으로 풀어보겠습니다 ✦
동적 데이터로 사용자의 흔적을 설계하다 ✦ 노코드 DB #3
안녕하세요! ARCOA 지안입니다. 👋 지난 글에서 정적 데이터가 앱의 “세계관”이라는 것을 살펴보았습니다. 동적 데이터는 그 세계 안에서 사용자가 만들어가는 “스토리”입니다.사용자가 어
dev.arcoa.kr
'No-Code Log' 카테고리의 다른 글
| Firestore 매핑으로 프로덕트 신경망 구축 ✦ 노코드 DB #4 (0) | 2025.11.28 |
|---|---|
| 동적 데이터로 사용자의 흔적을 설계하다 ✦ 노코드 DB #3 (0) | 2025.11.27 |
| DB 설계는 UX 설계의 뒷면이다 ✦ 노코드 DB #1 (0) | 2025.11.26 |
| 비개발자를 위한 노코드 DB 설계 ✦ 총 5편 (0) | 2025.11.24 |
| 디자이너의 노코드 앱개발 일기 ✦ (0) | 2025.11.13 |