1. 배경 지식

2022년까지는 지표, ad-hoc 데이터 추출, 리포트 등에서 각자의 목적에 맞게 정의한 user를 rds에서 추출하였다(이때는 Data Platform이 구축되지 않았다). 그러다보니 데이터를 추출할 때마다 요청자가 명확하게 정의하지 않으면 이전에 뽑은 데이터와 새로 뽑은 데이터의 수치가 달라지는 문제가 발생했다.

• 요청하시는 분들이 변화하는 백엔드 구현에 맞춰서 user를 명확하게 정의할 수 없는 문제도 있었다.

• 이 문제는 user를 어떻게 정의하겠다는 서비스 스펙이 부재했기 때문에 발생한 문제다.

  e.g. 활성 유저의 데이터를 주세요.

  → 활성 유저의 정의는 무엇인가요? kyc 완료만 활성이면 kyc 재이행 만료는 빠지게 되는데 이를 의도한 것이 맞나요? 등

2023년에는 Data 팀에서 과거 경험을 바탕으로 user를 정의하고 구축한 Data Platform을 활용하여 user 한방 쿼리를 만들자는 의견이 나왔다. 그러나 쿼리가 너무 길어지면 리뷰하기 힘들다는 이유와 정의가 불명확하다는 의견이 나와서 보류되었다. 그래서 Data 팀에서 정의한 user를 Data Lake, Data Warehouse에서 추출하였다. 그러다보니 마지막 layer 쿼리(ad-hoc 쿼리, 지표, 리포트 등)에서 사용하는 쿼리들이 매우 길어졌다. 또한 사소한 버그 데이터들을 마지막 layer 쿼리에서 보정해주기위해 사람이 모든 케이스를 기억하는 것은 무리였다.

• 백엔드 시스템의 버그로 특정 값이 누락된 데이터가 존재했다. 사이드 이펙트를 정확하게 예측하지 못하여 백엔드에서는 수정할 수 없다는 결론이 나서 데이터팀에서 보정해서 사용해야 했다.
  • e.g. 알 수 없는 이유로 특정 테이블에만 특정 값이 누락된 경우가 있었다. 다른 테이블(*_archived)에는 해당 데이터가 존재해서 해당 데이터로 보정을 해줘야 했다.
• 데이터팀의 모든 인원들이 위 케이스를 기억해야 했고 신규 입사자도 기억해야 해서 온보딩의 허들이 높아졌다.

2024년에는 과거 경험을 바탕으로 user의 상태를 적재하는 user_master 테이블을 모델링하게 되었다. 이를 통해 과거 발생한 여러 문제들이 해결될 것이라 기대했다.

2. 요구사항

• 누가 언제 추출하더라도 정의만 똑같으면 일관된 user가 추출된다.
  • e.g. kyc 완료, 활성, 동결 조건을 만족하는 유저만 추출하는 경우 user_master에 정의된 dimension만 동일하면 동일한 유저가 추출된다.
    • kyc 만료 상태를 kyc 만료 시각으로 자를 것인지? kyc 만료 일자로 자를 것인지?를 고민하지 않고 kyc 상태(kyc 최초 미이행, kyc 완료, kyc 재이행 주기 도래, kyc 재이행 미이행 등) dimension만 확인하면 된다.
• 버그를 발견한 경우 user_master 쿼리만 수정하여 적재하고 마지막 layer 쿼리(ad-hoc 쿼리, 지표, 리포트 등)에서는 신경쓰지 않는다.
• user_master 쿼리를 최대한 깔끔하게 작성(리뷰하기 편하게, 가독성 있게)한다.

AS-IS

TO-BE

3. 해결 과정

A. user_master는 어떻게 설계해야 할까?

• user의 현실 세계에서의 속성(만 나이, 성별, 법인 or 개인 등)과 gopax 서비스에서 정의되는 속성(동결, kyc 재이행 주기 도래, kyc 재이행 수행 등)을 분리하여 생각한다.
• 적재하는 데이터와 적재할 필요가 없는 데이터를 구분한다.
  • 단순 판단만 하는 경우 적재하지 않아도 된다.
    • e.g. 특정 enum 컬럼을 문자열로 치환하는 경우에는 View에서 처리한다.
  • 단순 판단이더라도 기준을 고정하고 싶은 경우 또는 조회 시점마다 변경될 수 있는 경우에는 적재한다. (사람에 따라 기준을 다르게 생각할 수 있는 dimension은 고정해둔다.)

    • e.g. user_master 테이블에는 enum을 문자열로 치환하여 사용자가 불필요한 정보를 몰라도 되게 한다.

    • e.g. 만 나이는 (현재 일자 - 유저가 태어난 일자) / 365.25로 계산식을 고정한다.

    • e.g. kyc 만료는 시각이 아닌 일자를 기준으로 하고 kyc 만료 당일에는 kyc 만료 상태로 생각한다.