테이블 수준 계보는 어떤 보고서가 한 테이블을 읽고, 그 테이블은 또 다른 테이블을 읽는다는 사실을 보여 줍니다. 컬럼 수준 계보(column-level lineage)는 한 단계 더 내려갑니다. 보고서의 revenue_usd는 주문 테이블의 amount에 환율 테이블의 환율을 곱하고 변환 단계에서 반올림한 값이라는 식입니다. 잘못된 숫자에 관한 질문은 대부분 이 수준에서 답이 나옵니다.
요즘은 데이터 카탈로그와 변환 도구가 SQL과 파이프라인 코드를 파싱해 컬럼 수준 계보를 생성합니다. 다만 대개 일부만 다룹니다. 노트북, 스프레드시트, 수작업 단계에서는 빈틈이 생깁니다. 또 계보는 값이 어디서 왔는지 알려 줄 뿐, 그 값이 해당 업무에 맞았는지는 알려 주지 않습니다.
컬럼 수준 계보는 데이터 출처와 어떻게 다른가요?
- 계보는 여러 테이블과 작업에 걸친 컬럼 간 경로를 보여 주며, 코드에서 생성됩니다. 데이터 출처(data provenance)는 특정 데이터셋이나 레코드의 기원과 이력, 즉 누가 언제 어떤 프로세스로 만들었는지를 기록합니다.
- 계보는 ‘이 컬럼에는 무엇이 들어오는가’에 답합니다. 출처는 ‘이 데이터는 어디서 왔고, 그 원천을 믿을 수 있는가’에 답합니다.
- AI 업무에는 둘 다 필요합니다. 여기에 더해 어느 쪽도 단독으로는 남기지 않는 세 번째 기록, 즉 어떤 데이터 버전이 어떤 조건에서 특정 결과를 냈는지에 관한 기록도 필요합니다.
AI 업무에서 컬럼 수준 계보는 어디서 문제가 되나요?
어떤 모델에서 가장 영향력이 큰 특성은 days_since_last_contact입니다. 계보를 보면 이 특성은 CRM의 last_contact_date에서 파생됩니다. 계보가 보여 주지 않는 사실도 있습니다. CRM 팀이 6월에 이 필드를 바꿔 자동 발송 이메일도 연락으로 기록하기 시작했다는 점입니다. 계보는 그대로인데 특성의 의미가 달라졌습니다. 모델 결과는 점점 어긋나는데, 계보 그래프는 정상으로 보입니다.
계보는 어디를 봐야 할지 알려 주지만, 무엇이 바뀌었는지는 알려 주지 않습니다. 이런 변화를 잡아내려면 모델을 평가한 데이터 버전을 기준으로 각 특성의 의미와 프로파일을 기록하고, 다음 추출본에서 둘을 비교해야 합니다.
Syntitan에서는 해당 데이터의 진단 결과와 준비 결과가 프로젝트 Version과 함께 남습니다. 개발 중인 Execution Trace는 각 실행을 그때 사용한 Version 및 평가 조건과 연결할 예정입니다. 이렇게 하면 결과가 달라졌을 때 그래프만 보는 대신 그 결과의 바탕이 된 데이터와 조건까지 추적할 수 있습니다. 더 넓은 개념은 데이터 계보에서 다루며, 세 번째 기록으로 가능해지는 일은 재현성에서 설명합니다.