2 분 소요

이 글은 유저 상태 스냅샷 포스트 의 후속 개요편입니다. 앞선 글을 아직 안 보셨다면 먼저 보고 오셔도 좋습니다.

지난 글에서 유저 상태 스냅샷(User State Snapshot) 모델링을 왜 쓰는지 정리했습니다. 그런데 몇몇 분들이 비슷한 질문을 주셨습니다.

  • 스냅샷이 너무 커지면 어떻게 하나요?
  • 활동하지 않은 유저까지 매일 쌓으면 너무 비싸지 않나요?
  • 모든 상태를 일별 스냅샷으로 저장해야 하나요?
  • 상태 전이만 보고 싶으면 더 가벼운 방법은 없나요?

좋은 질문입니다. 그리고 결론부터 말하면, Daily Snapshot 하나로 모든 문제를 풀 필요는 없습니다.

상태를 저장하는 방식은 하나가 아닙니다. 문제에 따라 더 작은 모델, 더 압축된 모델, 더 전이에 특화된 모델이 더 잘 맞을 수 있습니다.

이번 글은 그 개요편입니다. 아래 글들에서 각각의 모델링 방식을 하나씩 나눠서 정리해보겠습니다.

어떤 질문에 어떤 모델이 답이 될 수 있을까

아래처럼 생각하면 조금 정리가 쉽습니다.

1. First/Last 모델

이런 질문에 답이 될 수 있습니다.

  • 최근 N일 활성 여부만 빠르게 보고 싶은데 꼭 일별 스냅샷이 필요한가요?
  • AU_30, AU_90 같은 지표만 주로 보는데 더 단순한 모델은 없나요?
  • 저장량을 줄이면서 recency 중심 지표를 계산할 수 없을까요?

참조 링크:

2. Active-days-only Activation 모델

이런 질문에 답이 될 수 있습니다.

  • 활동한 날의 NEW / RETAINED / REACTIVATED 만 알고 싶다면 매일 모든 유저를 저장해야 하나요?
  • 비활동 날짜는 굳이 저장하지 않고도 Activation 분석이 가능한가요?
  • Daily Snapshot보다 가볍게 활동 상태를 관리할 수 없을까요?

참조 링크:

3. Transition Table 모델

이런 질문에 답이 될 수 있습니다.

  • 현재 상태보다 어디서 어디로 이동했는가 가 더 중요하면 어떻게 해야 하나요?
  • churn, resurrection 같은 흐름을 보고 싶다면 어떤 모델이 더 잘 맞나요?
  • 상태 변화가 일어난 순간만 저장하는 방식은 없나요?

참조 링크:

4. Interval Table 모델

이런 질문에 답이 될 수 있습니다.

  • 같은 상태가 며칠 유지됐는지 구간 단위로 보고 싶다면 어떻게 하나요?
  • inactive 기간을 매일 한 줄씩 저장하지 않고 표현할 수 있나요?
  • Daily Snapshot보다 저장량은 줄이고, 특정 날짜 상태 복원은 유지할 수 없을까요?

참조 링크:

꼭 Daily Snapshot만 고집할 필요는 없습니다

Daily Snapshot 은 이해하기 쉽고 조회도 편합니다. 다만 유저 수가 매우 많고, 비활동 유저가 대부분이라면 저장량이 꽤 빠르게 커집니다.

그래서 실무에서는 자주 이렇게 생각하게 됩니다.

  • 모든 유저를 매일 찍을 것인가
  • 변화가 생긴 날만 저장할 것인가
  • 상태가 유지된 구간으로 저장할 것인가
  • 최소한의 상태만 저장할 것인가

즉 질문은 “스냅샷이 맞냐 틀리냐”가 아니라, 지금 문제에 어떤 밀도의 상태 저장이 맞느냐 에 더 가깝습니다.

이 시리즈를 어떻게 읽으면 좋을까

추천 순서는 아래입니다.

  1. 저장량을 먼저 줄이고 싶다면 First/Last
  2. 활동한 날 중심 분석이면 Active-days-only Activation
  3. 상태 이동 분석이 중요하면 Transition Table
  4. 상태 구간 표현까지 필요하면 Interval Table

하나씩 짧게 정리해둘 생각입니다. Daily Snapshot 이후를 고민하고 있다면, 이 시리즈가 답을 찾는 데 도움이 될 수 있을 것 같습니다.

시리즈 모아보기

댓글 남기기

스팸 방지를 위해 짧은 시간에 반복 등록은 제한됩니다.

댓글 목록

관리자 보기