동적 데이터로 사용자의 흔적을 설계하다 ✦ 노코드 DB #3

안녕하세요! ARCOA 지안입니다. 👋 

 

지난 글에서 정적 데이터가 앱의 “세계관”이라는 것을 살펴보았습니다. 동적 데이터는 그 세계 안에서 사용자가 만들어가는 “스토리”입니다.

사용자가 어떤 화면을 보고, 무엇을 선택하고, 어떤 행동을 반복하는지, 이 모든 순간이 로그(Log)와 히스토리(History)로 남습니다.

디자이너가 이를 이해해야 하는 이유는 단순합니다.

 

데이터의 흐름은 곧 UX의 흐름

 

화면에서 일어난 모든 행동은 결국 ‘데이터 관계’가 됩니다. 사용자의 흔적을 어떻게 구조화하느냐에 따라 서비스의 개선 속도, 개인화 품질, 장애 대응력이 완전히 달라지는 것이죠.

 

 

 

1/ 동적 데이터란?

정적 데이터와 비교하면 차이가 명확합니다.

정적 데이터가 기준을 세운다면, 동적 데이터는 그 기준이 실제로 어떻게 사용되었는지 보여줍니다.

구분	정적 데이터 (Static Data)	동적 데이터 (Dynamic Data)
의미	변하지 않는 설정값·기준	사용자가 남기는 행동 기록
예	카테고리 목록, 점수 규칙	검색 기록, 선택 이력, 요청, 결과
갱신	운영자에 의해 수동 업데이트	사용자의 행동에 의해 자동 축적
역할	“세계관”	“스토리”

 

 

 

2/ 동적 데이터의 핵심 테이블 구조: 서비스마다 다르지만 원리는 동일

아래는 저의 서비스를 이해하기 위한 구조이지만, 어떤 앱이라도 동일한 원리로 적용됩니다.

여기서 중요한 건 이름이 아니라, 관계의 흐름입니다.

구분	동적 데이터
User	회원 정보, 가입 시점, 권한
User_xxx (사용자 커스텀 데이터)	사용자만의 설정, 즐겨찾기, 보관함
Action_log	클릭, 스크롤, 필터 변경, 조회 등의 행동 기록
History / Request / Snapshot	특정 시점의 상태 저장(추천 결과, 장바구니 상태 등)

 

 

 

 

3/ 데이터 흐름 = UX 흐름

동적 데이터 설계는 결국 “사용자 여정(User Journey)”을 테이블로 옮기는 일입니다.

 

가입(Join)

→ User 테이블 생성
→ User_meta, User_settings 기본값 입력

 

탐색(Browse)

→ 검색어 = Search_log
→ 필터 선택 = Action_log
→ 최근 본 항목 = Browse_history

 

요청(Request)

→ 특정 기능 실행 = Request_log
→ 결과 저장 = Snapshot

 

반복(Repeat)

→ 과거 기록 기반으로 개인화 = User_history 참조
→ 이전 행동 기반 추천 = Action_log 분석

즉, 사용자의 여정이 분리되지 않았다면, DB 테이블도 분리되면 안 된다.
→ 흐름대로 저장하면 분석이 쉬워지고
→ 흐름대로 연결하면 개인화가 쉬워진다.

 

 

 

 

4/ 실시간 vs 스냅샷 데이터: 왜 둘 다 필요할까?

디자이너가 앱을 만들면서 가장 자주 실수하는 부분입니다. 두 데이터를 구분하여 사용해야 합니다.

	실시간 데이터 (Real-time)	스냅샷 데이터 (Snapshot)
특징	매 순간 최신 값이 반영됨	특정 시점의 정보를 “캡처”해서 저장
데이터	지금 화면에서 보이는 값	당시의 상황을 ‘사진 찍듯’ 저장한 값
예시	현재 선택된 필터, 현재 페이지 상태	추천 결과(그날의 카드 랭킹), 주문 당시 금액, 결제 전 장바구니

 

TIP 왜 실시간과 스냅샷이 따로 필요할까?

👉 실시간 값은 계속 변하기 때문에
　 (실시간 추천 모델 → 변화하는 점수)

👉 “당시의 정확한 기록”이 필요할 때 스냅샷을 사용함
　 (사용자가 본 당시의 추천 리스트 → Snapshot 유지)

 

 

 

 

5/ UI에서 발생한 행동을 데이터로 번역하는 과정

화면의 모든 인터랙션 = 데이터의 상태 변화

• 버튼을 눌렀다 → Action_log 생성
• 리스트를 스크롤했다 → View_log
• 옵션을 변경했다 → Setting 업데이트
• 추천 결과를 저장했다 → Snapshot 생성
• 특정 페이지를 열었다 → Page_open_log

와이어프레임을 그리고 플로우를 만든 순간, 이미 그 뒤에서 데이터 관계도 함께 만들어지고 있어야 한다는 뜻입니다. 

디자인만 흐르고 데이터가 흐르지 않으면 나중에 분석·개선·개인화·A/B 테스트가 모두 불가능해져요.

 

 

 

6/ 디자이너가 동적 데이터를 잘 설계하면 생기는 변화

 동적 데이터는 ‘공감’을 정량화하는 유일한 도구

• 기능 개선 방향이 명확해짐
• 실제 사용자 행동 기반으로 UI 문제를 파악
• 반복 행동(패턴) 분석 가능
• 개인화 기능이 강해짐
• 장애 발생 시 원인 추적 쉬움
• 운영/마케팅의 의사결정이 빨라짐
• UX가 “감”이 아니라 “데이터”로 설명 가능해짐

 

 

 

7/ 맺음: 기록은 선택이 아니라 설계다

“화면은 사라져도 데이터는 남는다.”
“남는 것을 먼저 설계해야 진짜 UX다.”

 

정적 데이터가 앱의 “세계”를 세팅한다면, 동적 데이터는 그 세계에서 사용자가 만들어내는 “이야기”입니다.

 

 

 

디자이너를 위한 한 줄 요약

디자인이 흐름을 만들고, 동적 데이터는 그 흐름을 기억한다.
흔적을 설계하는 것이 곧 UX를 설계하는 일이다.

 

 

 

다음 글

✦ 비개발자를 위한 노코드 DB 설계

├ 1 ✦ DB 설계는 UX 설계의 뒷면이다 완료
├ 2 ✦ 정적 데이터는 제품의 룰북이다 완료
├ 3 ✦ 동적 데이터로 사용자의 흔적을 설계하다 완료

├ 4 ✦ Firestore 매핑으로 프로덕트 신경망 구축

└ 5 ✦ 디자이너가 데이터로 말하는 법

 

다음 글은 정적·동적 데이터를 Firestore 구조 안에서 어떻게 연결하고, 실제로 어떤 구조가 “안정적이고 확장 가능한 DB”인지 구체적으로 이야기해보겠습니다 ✦

Firestore 매핑으로 프로덕트 신경망 구축 ✦ 노코드 DB #4