리포트 숫자가 이상한데, 어디서부터 잘못됐는지 모른다
매출 리포트의 숫자가 갑자기 이상해졌습니다. 담당자는 원인을 찾기 위해 이 리포트가 어떤 데이터셋에서 왔는지, 그 데이터셋은 또 어디서 왔는지를 역으로 추적해야 합니다. 이걸 문서나 기억에 의존해서 찾으려 하면 며칠이 걸릴 수도 있습니다. Data Lineage는 이 추적을 실시간으로, 자동으로 해주는 기능입니다.
Data Lineage란
원본 데이터부터 최종 결과물까지의 흐름을 실시간으로 추적하는 “살아있는 데이터 지도”입니다. 파이프라인이 바뀌면 지도도 즉시 갱신됩니다.
5가지 핵심 기능
양방향 추적. “이 데이터는 어디서 왔는가”(상류)와 “이 데이터는 어디에 쓰이는가”(하류)를 모두 추적할 수 있습니다. 앞서 예로 든 매출 리포트 문제라면, 상류 추적으로 원인 데이터셋을 찾아 올라갈 수 있습니다.
컬럼 레벨 추적. 테이블 단위가 아니라 특정 컬럼 하나가 어떤 변환을 거쳐 왔는지까지 볼 수 있습니다. 문제가 테이블 전체가 아니라 특정 필드 하나에 있을 때 유용합니다.
보안 등급 자동 상속. 상류 데이터셋에 걸린 보안 마킹이 하류로 자동으로 전파됩니다. 누군가 실수로 등급을 낮추는 걸 방지하는 안전장치 역할도 합니다.
빌드 히스토리 연동. Git과 연동되어, 파이프라인 코드가 언제 어떻게 바뀌었는지를 데이터 흐름과 함께 볼 수 있습니다.
헬스체크 오버레이. 파이프라인의 상태(정상/실패/지연)를 흐름도 위에 바로 표시해줘서, 문제가 어느 지점에서 발생했는지 한눈에 파악됩니다.
실무에서 이렇게 씁니다
- 리포트 숫자 오류의 원인 데이터셋을 역추적
- 특정 데이터셋을 변경하기 전에, 영향을 받는 하류 시스템을 미리 확인
- 보안 감사 시 데이터가 거쳐온 전체 경로를 증명
흔한 실수 3가지
하류 영향을 확인하지 않고 먼저 고친다. 문제가 생긴 데이터셋을 발견하면 바로 수정하고 싶은 유혹이 크지만, 그 데이터셋을 참조하는 하류 시스템이 몇 개인지 먼저 확인해야 합니다. 확인 없이 고치면 다른 곳에서 새로운 문제가 터집니다.
보안 등급을 임의로 낮춘다. 작업 편의를 위해 등급을 낮추면, 그 등급이 하류로 그대로 상속되어 원래 보호되어야 할 데이터가 노출될 수 있습니다.
장애가 나야 lineage를 들여다본다. Lineage는 사고 대응 도구가 아니라 설계 단계부터 참고해야 할 도구입니다. 사고 후에만 보는 습관이 있다면, 설계 시점에 미리 확인하는 루틴으로 바꾸는 게 장애 예방에 더 효과적입니다.
정리하면
Data Lineage는 사고가 난 뒤에 원인을 찾는 도구로만 쓰기엔 아깝습니다. 데이터셋을 바꾸기 전에 하류 영향을 미리 확인하고, 보안 등급이 의도치 않게 낮아지지 않았는지 설계 단계에서부터 들여다보는 습관이, 애초에 사고를 줄이는 방법입니다.
파이프라인 로직 자체를 다시 살펴보려면 Foundry의 파이프라인 구축과 코드 관리를, 이 데이터가 온톨로지에 어떻게 매핑되는지 확인하려면 Ontology Manager를 다시 참고하는 것을 추천합니다.
자주 묻는 질문
Q. Lineage는 자동으로 기록되나요, 별도로 설정해야 하나요? 파이프라인을 구성하면 자동으로 기록됩니다. 별도 설정 없이도 흐름을 추적할 수 있습니다.
Q. Lineage와 감사 로그(audit log)는 같은 건가요? 다릅니다. Lineage는 데이터가 어디서 와서 어디로 가는지의 구조를 보여주고, 감사 로그는 누가 언제 무엇을 했는지의 행위 기록을 보여줍니다. 둘은 상호 보완적입니다.
Q. 파이프라인이 복잡하면 lineage 그래프도 너무 복잡해 보이지 않나요? 맞습니다. 이런 경우 특정 데이터셋이나 기간을 기준으로 필터링해서 필요한 부분만 좁혀 보는 방식을 권장합니다.