어제의 생산량 보고서를 오늘 열었더니 숫자가 달라져 있습니다. 누군가는 시스템 오류라고 생각하지만, 현장 단말이 밤새 오프라인이었다가 오늘 오전 측정값을 전송했을 수도 있습니다. 매출 승인 취소나 주문 정정도 다음 날 도착할 수 있습니다. 이때 ‘수집한 날짜’만 기준으로 집계하면 실제 업무가 일어난 날짜와 보고서 날짜가 어긋납니다.
데이터가 언제 발생했는지와 시스템이 언제 알게 됐는지는 다른 시간입니다. 늦게 도착한 데이터는 예외가 아니라 연결이 끊기는 현장, 외부 API, 수기 보정이 있는 시스템의 정상적인 운영 조건입니다.
두 개의 시계를 저장하자
event_time은 업무 사건이 실제로 발생한 시각이고 ingested_at은 우리 시스템이 수신한 시각입니다. 장비나 외부 시스템이 준 시각을 무조건 믿을 수는 없으므로 원천 시스템, 시간대, 장비 시계의 신뢰도도 고려합니다. 동일한 사건의 원본 ID와 수정 버전, 수신 경로를 기록하면 나중에 숫자가 왜 바뀌었는지 설명할 수 있습니다.
업무 지표의 기준을 명시해야 합니다. 하루 생산량은 발생 시각 기준일 수 있고, 고객지원 팀이 처리한 당일 접수량은 수신 시각 기준일 수 있습니다. 두 지표 모두 유효하지만 이름이 같으면 안 됩니다. 화면에 기준 시간대와 마지막 갱신 시각을 표시하면 ‘숫자가 바뀌었다’는 불신을 줄일 수 있습니다.
워터마크는 확정 시각이 아니다
스트리밍 처리에서 워터마크는 어느 시점까지 데이터가 대체로 도착했는지의 추정입니다. 워터마크가 지나도 늦은 데이터가 올 수 있으므로 일정한 지연 허용 범위와 정정 정책을 둡니다. Apache Beam의 지연 데이터 안내는 허용 지연과 후속 결과 방출을 설명합니다. 도구를 쓰지 않는 배치 시스템에도 ‘어제 데이터는 다음 날 오전까지 잠정치’ 같은 동일한 운영 원리가 필요합니다.
지연 허용 시간을 무한히 늘릴 수는 없습니다. 짧으면 누락이 늘고 길면 집계의 확정이 늦어집니다. 데이터 종류별 실제 지연 분포를 측정하고, 회계 마감처럼 정정 승인 절차가 필요한 데이터는 일반 실시간 집계와 별도로 다룹니다.
중복과 정정을 구분한다
같은 원본 이벤트가 재전송된 경우는 중복 제거가 필요합니다. 반면 ‘처음에는 10개로 보고했지만 검수 후 9개로 수정’은 새로운 사실입니다. 단순히 ID만 같으면 버리는 로직은 정정을 잃을 수 있습니다. 원본 ID와 버전 또는 정정 관계를 저장하고, 집계에서는 이전 기여분을 빼고 새 값을 반영합니다. 원본 레코드를 덮어써버리면 사후 설명과 재처리가 어려워집니다.
재계산 범위도 제한해야 합니다. 영향을 받은 날짜·조직·제품 구간을 찾아 다시 계산하고, 대시보드 캐시와 다운로드용 집계도 함께 갱신합니다. 정정 이벤트를 처리했는데 대시보드만 옛 값을 보여주면 데이터 파이프라인은 기술적으로 성공해도 업무상 실패입니다.
‘어제 값’에 신뢰 수준을 표시하자
최신 보고서에는 잠정, 지연 데이터 반영 중, 마감 확정 같은 상태가 유용합니다. 마지막 업데이트 시각과 정정 건수, 수정 이유를 함께 남기면 숫자의 변화를 추적할 수 있습니다. 운영 지표는 수집 지연의 p95·p99, 허용 범위 밖의 도착 건수, 중복 비율, 재계산 지연, 원천별 누락량입니다. 특히 한 원천의 전송 장애가 전체 합계에 얼마나 영향을 주는지 보아야 합니다.
작게 시작하는 구현 순서
- 원본 데이터에 발생 시각과 수신 시각을 모두 보존한다.
- 원천별 고유 ID와 수정 버전 규칙을 정한다.
- 업무 지표마다 시간 기준과 잠정·확정 기준을 명시한다.
- 지연 분포를 보고 허용 기간과 재계산 범위를 정한다.
- 정정 후 대시보드·내보내기·알림 값이 일치하는지 검증한다.
데이터가 늦게 오지 않게 만드는 것은 불가능할 수 있습니다. 중요한 것은 늦게 온 사실을 올바른 날짜와 이유에 연결하고, 바뀐 숫자를 설명할 수 있게 하는 것입니다.
#지연데이터 #이벤트시간 #워터마크 #데이터파이프라인 #증분처리 #데이터정합성 #데이터품질 #재계산 #분석시스템 #ETL
