데이터 웨어하우스를 만들어주세요, 제발
데이터 엔지니어로서 일하면서 뼈저리게 느꼈던 데이터 웨어하우스의 중요성과 효과적인 구축 방법에 대해 공유합니다.
시작하며: 밑빠진 독에 물 붓기
벌써 데이터 엔지니어라는 이름으로 커리어를 시작한지 벌써 4년이 흘렀다. 지금 머물러 있는 회사에서 일한지는 거의 3년이 다 되어 간다. 처음 왔을 때는 RDS만 복제해서 데이터 프로덕트를 만들기 급급하던 구조였는데, 어느새 메달리온 아키텍처로 데이터 레이크를 안정적으로 구축하고 데이터 제품의 품질을 고민하는 위치까지 올라왔다. 이번 글에서는 2024년동안 데이터 웨어하우스를 구축하면서 데이터 품질을 높이기 위해 했던 노력들을 정리해보려고 한다.
주변에서 이야기를 들어 보면 다음과 같은 이유로 데이터 웨어하우스가 계륵같은 경우가 많았다.
- 대부분 데이터팀은 소규모로 운영되기 때문에 너무 바쁘다.
- 제대로 구성하고 사용하려면 리소스가 상당히 많이 소요된다.
- 제품에 도달하기까지 하나의 레이어가 추가되는 것이라서 상당히 번거롭다.
- 들어가는 리소스 대비 그게 왜 필요한지 아직 잘 모르겠다는 사람들도 있었다.
그래서 아예 없는 회사도 있었고, 그냥 OBT(One Big Table)로 구성하거나 자주 사용되는 테이블의 데이터 타입을 전처리 정도만 해두고 데이터 웨어하우스라고 칭하는 경우가 대부분이었다.
우리 회사도 마찬가지였다. 그 상태로 대시보드나 지표 산정을 각각의 사람들이 진행하다보니 매번 제품마다 값이 달랐고, 기술부채는 날로 쌓여갔다. 이런 환경에서 유지보수만 계속 하는 건 마치 밑빠진 독에 물 붓기였다.
데이터 웨어하우스가 필요한 이유
데이터 웨어하우스가 존재하지 않으면 생기는 문제들을 크게 정리해보면 다음과 같다.
데이터 품질 관리가 어렵다.
- 동일 지표 조건이 개발자마다 달라서 혼동이 온다.
- 백엔드팀에서의 로직 변경 사항이 전달되지 않아 구 버전 로직이 사용되는 경우도 생긴다.
- 로직이 변경되었을 때 수정해줘야 하는 범위를 확인하기 어렵다.
파이프라인 코드 관리가 어려워진다.
- 각자 자유롭게 파이프라인을 생성하다 보니, 퇴사자가 발생하면 유지보수가 불가능하다.
- 어떤 제품이 존재하는지조차 데이터팀 내에서 공유되지 않는다.
- 매번 유지보수에 지나치게 많은 시간과 비용이 소모된다.
데이터 웨어하우스는 데이터 품질 관리와 효율적인 코드 관리의 중심 역할을 한다. 예를 들어, 우리 회사의 GMV를 정의한다고 할 때 어떤 사람은pay_time을 기준으로 데이터를 추출하고 또 다른 사람은 주문의 create_time을 기준으로 추출하는 경우가 자주 발생한다. 이처럼 지표 정의가 사용자마다 달라지면 데이터의 신뢰성과 일관성이 훼손된다. 따라서 GMV 산식 기준이 정해지면 이를 바탕으로 웨어하우스에 GMV 컬럼이 추가된 테이블을 생성하고 모든 제품에서 GMV 값을 여기서 가져가도록 설계한다. 이렇게 설계하면 만약 나중에 GMV 산식이 변경되더라도 웨어하우스의 파이프라인만 변경하면 모든 지표들이 업데이트 된다.
또한 백엔드에서 주요 로직이 변경되거나 서버 장애 등으로 정합성 이슈가 발생한 경우, 웨어하우스 담당자만 해당 작업을 반영하면 빠르게 조치가 가능하다. 만약 각각의 데이터 제품이 서로 다른 파이프라인을 사용하면 수정해야 할 작업량이 기하급수적으로 늘어나고 유지보수가 불가능한 상태에 빠진다. 결국 몇 번의 퇴사와 입사를 거치면서 대규모 레거시가 쌓이며, 이는 마치 박물관의 유물처럼 트러블슈팅만을 위한 존재로 전락하게 되는 것이다. 데이터 웨어하우스는 이런 문제들을 막을 수 있는 훌륭한 수단이다.
우리 회사 또한 위와 같은 문제를 해결하기 위해, 데이터 웨어하우스를 구축하기로 결정했다.
데이터 웨어하우스 구축 방법
자 이제 데이터 웨어하우스를 만들어보자. 뭐부터 해야 할까? 처음에는 서비스 도메인들을 이해해야 한다. 우리 회사의 경우도 큰 서비스 내에 여러 개의 도메인이 분리되어 있다보니 각 도메인마다 비즈니스 로직이 달랐다. 비즈니스 로직을 이해해야 데이터 모델링 시 범주를 산정할 수 있다.
그 다음으로는 비즈니스 로직에 연결된 운영 데이터를 이해하는 것이다. 분석 데이터의 기본은 결국 서비스에서 생성되는 데이터이다. 따라서 서비스 DB 로직을 모른다면 웨어하우스를 만들 수 없다. 운영 데이터를 이해하려면 백엔드팀에 여쭤보기도 하고 히스토리 문서를 읽기도 하고 직접 스키마 확인하면서 쿼리해보는 수밖에 없다.
그렇게 어느정도 데이터에 대한 공부가 끝나면 이제 개발 단계로 나아갈 수 있다.
먼저 데이터 모델링 설계이다. 해당 작업에서는 비즈니스 로직과 데이터를 바탕으로 스타 스키마 또는 눈송이 스키마 구조를 선택하여 데이터 모델을 설계한다. 스타 스키마와 눈송이 스키마를 자세히 알고 싶다면 해당 글을 참고하길 바란다. 스키마 선택 외에도 몇 가지 알아두면 좋은 요소들은 다음과 같다.
- 공통 지표를 먼저 정의하고 그에 맞게 모델링 구성하기
- 테이블 통합 시 사용할 논리 PK를 따로 구성하기
- 데이터 정합성 라벨링하기: VALID, BAD_DATA, INVALID 등
- 데이터 모델링 시 문서를 최대한 자세히 써두기
- INSERT, UPDATE 시간을 따로 컬럼으로 추가해두기
데이터 모델링 작업이 끝나면 다음으로는 ETL/ELT 파이프라인을 설계하는 것이다. 파이프라인의 경우 모델링 결과에 따라 INSERT나 UPDATE 구조로 구성된다. 따라서 UPSERT를 지원하는 플랫폼을 사용하는게 좋다. 우리 팀에서는 Spark에 오픈소스 Delta Lake 라이브러리를 추가하여 UPSERT를 구현하고 있다. 또한 Airflow에 일배치로 구성하여 메일 최신 데이터가 업데이트 또는 추가 되도록 구성하였다. 매번 Dag를 구성하는게 귀찮을 때는 템플릿을 만들어 사용하면 편하다.
그 다음에는 웨어하우스에 있는 테이블 스키마를 정리하고 공유하는 환경을 구성해야 한다. 보통 데이터 카탈로그 플랫폼을 구성하여 공유한다. 우리 팀의 경우에는 데이터허브(datahub)를 구축하여 사용하고 있다. 처음 테이블을 모델링하고 생성할 때 바로 카탈로그에 적어두지 않으면 나중에 눈덩이처럼 불어난 일감을 만나게 될 것이다.
마지막으로는 품질 관리와 테스트 시스템을 구성하는 것이다. 웨어하우스에 있는 데이터는 품질이 보장된다는 것을 전제로 한다. 따라서 웨어하우스를 유지보수하는 엔지니어는 언제나 품질 관리와 테스트를 고민하게 될 것이다. 품질 관리에 포함되는 요소는 아래과 같다.
- 데이터 정합성 테스트
- NULL 값 체크
- 중복 데이터 제거
- 과거 데이터 변동 및 이상치 확인
사실 서비스를 운영하다보면 비즈니스 로직이나 운영 데이터 로직은 계속 변화한다. 결국 데이터 품질 관리란 이러한 변화를 사람이 인지하고 이해하여 꾸준히 반영해주는 작업이다. 이러한 이유로 데이터 웨어하우스를 구축하고 관리하는 데는 더 많은 리소스가 소요된다. 하지만 이런 여과기를 갖추지 않고 제품을 만든다면, 규모가 확장되는 어느 순간에는 되돌리기 어려운 기술부채를 쌓아가는 양산소가 될 가능성이 크다.
위 내용을 정리해보면 아래와 같다.
- 공부 단계
- 서비스 도메인 별 비즈니스 로직을 이해한다.
- 서비스 운영 데이터 DB 로직을 이해한다.
- 개발 단계
- 데이터 모델링을 설계한다.
- ETL/ELT 파이프라인 설계 및 개발한다.
- 데이터 카탈로그를 구축한다.
- 품질 관리 및 테스트 시스템을 구축한다.
결론: 데이터 웨어하우스를 만들어주세요
데이터 웨어하우스는 데이터팀의 기반을 튼튼히 다지는 플랫폼으로, 데이터 품질과 코드 유지보수를 책임지는 핵심 역할을 한다. 앞서 언급한 문제점과 목표를 해결한다면 데이터팀의 생산성과 효율성은 크게 향상될 것이다. 데이터 웨어하우스는 단순히 데이터를 쌓아두는 저장소가 아니라 데이터를 체계적으로 관리하고 신뢰할 수 있는 정보를 제공하는 데이터팀의 심장이라고도 볼 수 있다. 제품 규모가 비교적 관리가 가능할 때 미리미리 해당 인프라를 구성해두지 않는다면 그 데이터팀은 아마 유지보수 지옥이 될 가능성이 상당히 높다. 그러니 이 글의 결론은, 제발 초기 플랫폼을 구성할 때 데이터 웨어하우스를 구축해서 이런 혼란을 방지했으면 좋겠다.