수집·배포·서비스가 한 DB에 묶여 수집 과정의 데이터가 고객사까지 그대로 흘러가던 구조를, 수집 DB와 배포 DB(메타·파일 2계열)로 나누고 바이너리 로그 반영 순서를 잡아 PROD 정합성을 확보한 재설계
고객사로 나갈 데이터와 만드는 중인 데이터를 같은 그릇에 두지 않는다 — 이 작업은 그 한 문장에서 출발했습니다. 수집이 실패하거나 다시 돌 때마다 그 흔적이 배포본에 묻어가면, 문제가 생겨도 어디서부터 손대야 할지 보이지 않으니까요.
지금 와서 보면 원천(raw) → 정제·배포(curated) → 서비스(serving)로 층을 나눈 메달리온 아키텍처와 같은 발상입니다. 당시에는 그 이름을 몰랐지만, 데이터가 단계를 거치며 신뢰도를 얻어야 한다는 건 운영하면서 몸으로 알게 됐습니다.
초기에는 ETL 전 과정이 하나의 DB에서 이루어졌습니다. 수집 작업과 배포용 데이터, 서비스 PROD까지 한 곳에 있다 보니 수집 과정의 중간 데이터까지 고객사로 그대로 전달되는 구조였습니다.
메타정보가 먼저 PROD에 반영된 뒤 파일 정보가 따라가도록 순서를 보장해, 파일 데이터가 존재하지 않는 메타를 참조하는 일이 없게 했습니다. 원천 → 정제 → 서비스로 층을 나눈, 지금으로 치면 메달리온 아키텍처(bronze/silver/gold)에 해당하는 구조입니다.
Data Engineer로서 영역 분리 설계와 배포 DB 2계열 분류, binlog 반영 경로 재구성을 수행했습니다. 운영 중인 서비스와 고객사 동기화에 직접 닿는 변경이라, 경계를 먼저 세운 뒤 데이터 흐름을 옮기는 순서로 진행했습니다. 이때 세운 수집/배포 DB 경계는 지금의 데이터 플랫폼에도 그대로 살아 있습니다.
이후 DB 아키텍처 인스턴스 분리(2024), 바이너리 로그 기반 동기화 고도화로 이어지는 수집/배포 분리 구조의 출발점.