데이터 엔지니어라면 한 번쯤 이런 상황을 겪어봤을 것이다.
파이프라인은 돌아가고 있다. 로그도 정상이다. 그런데 분석가가 쓰는 대시보드의 숫자가 이상하다. 원인을 찾기 위해 소스부터 역추적한다. 변환 로직을 뜯어보고, 조인 조건을 다시 확인하고, 스케줄러 로그를 열어본다. 두 시간 뒤에야 원인을 찾는다. 업스트림 테이블 스키마가 조용히 바뀌어 있었다.
아무도 공지하지 않았다.
이건 특정 팀의 문제가 아니다. 데이터가 여러 시스템을 거쳐 흐르는 구조라면, 어디서나 일어나는 일이다.
흐름이 끊기는 지점은 세 곳이다
데이터가 의사결정에 닿기까지의 경로를 단순화하면 이렇다.
수집 → 저장 → 변환 → 서빙
각 단계마다 끊길 수 있는 지점이 있다. 경험상 문제가 집중되는 구간은 세 곳이다.
1. 소스와 수집 사이
API 스펙이 바뀐다. 필드명이 달라지거나 타입이 바뀐다. 소스 시스템이 예고 없이 응답 구조를 변경한다. 수집 레이어에 방어 로직이 없으면 이건 그대로 다운스트림으로 흘러간다. 나쁜 데이터는 오류보다 무섭다. 오류는 파이프라인을 멈추지만, 나쁜 데이터는 조용히 통과한다.
2. 변환 로직 내부
SQL이든 dbt든 Spark든, 변환 로직은 시간이 지날수록 복잡해진다. 처음엔 단순했던 쿼리가 조건이 쌓이고 조인이 늘어나면서 누구도 전체를 파악하지 못하는 상태가 된다. 이 상태에서 요구사항이 바뀌면, 수정의 영향 범위를 추적하기 어려워진다. 테스트가 없으면 더 그렇다.
3. 서빙과 소비 사이
분석가가 보는 테이블이 언제 갱신됐는지 명확하지 않다. freshness가 보장되지 않는다. 메트릭 정의가 팀마다 다르다. 같은 “전환율”인데 마케팅 팀과 프로덕트 팀의 숫자가 다르다. 이건 기술 문제가 아니라 정의 문제다. 하지만 결국 데이터 팀이 해결해야 한다.
왜 이 문제가 반복되는가
도구가 없어서가 아니다. 지금은 도구가 넘친다. 오케스트레이션, 카탈로그, 품질 모니터링, 계보 추적. 스택은 갖춰져 있는데 문제는 계속된다.
이유는 하나다. 흐름 전체를 보는 시각이 없다.
파이프라인을 만드는 사람과, 데이터를 쓰는 사람과, 소스를 관리하는 사람이 각자의 구간만 본다. 연결 지점에서 발생하는 문제는 누구의 책임도 아닌 상태로 방치된다. 모니터링을 해도 알람이 울리는 건 이미 문제가 터진 이후다.
흐름을 설계한다는 건 각 단계를 잘 만드는 것만이 아니다. 연결 지점을 명시적으로 정의하고, 문제가 생겼을 때 어디서 왜 생겼는지 추적할 수 있게 만드는 것이다.
실무에서 바로 적용할 수 있는 세 가지
복잡한 이야기를 했지만, 지금 당장 할 수 있는 것부터 시작하는 게 낫다.
스키마 변경 감지를 자동화한다
소스 테이블의 스키마를 주기적으로 스냅샷 찍어 비교하는 로직을 넣는다. dbt의 source freshness와 schema tests를 조합하면 기본적인 감지는 된다. Great Expectations나 Soda를 쓴다면 컬럼 타입, null 비율, 값의 범위를 임계값 기반으로 모니터링할 수 있다. 완벽하지 않아도 된다. 아무것도 없는 것보다 낫다.
변환 로직에 lineage를 남긴다
어떤 테이블이 어떤 소스에서 어떻게 만들어졌는지 추적 가능하게 만든다. dbt를 쓴다면 이미 lineage graph가 있다. 없다면 최소한 주요 테이블의 upstream을 문서화한다. 변경이 생겼을 때 영향 범위를 파악하는 데 걸리는 시간이 줄어든다.
메트릭 정의를 한 곳에서 관리한다
팀마다 다른 정의를 쓰는 문제는 semantic layer로 해결한다. dbt Semantic Layer, Looker의 LookML, MetricFlow 등을 쓰면 메트릭을 코드로 정의하고 단일 소스로 관리할 수 있다. 도구 도입이 어렵다면, 최소한 메트릭 정의서를 공유 문서로 만들고 팀 간 합의를 거치는 것부터 시작한다.
글을 마치며
데이터 플로우는 파이프라인을 잘 만드는 것만이 아니다. 데이터가 생성되는 시점부터 누군가의 결정에 영향을 미치는 시점까지, 그 전체 흐름이 끊기지 않게 설계하는 것이다.
끊기는 지점을 알면, 고칠 수 있다.
Grojkon Apex · Data Flow #DataEngineering #DataPipeline #dbt #DataQuality #Analytics