수집 워커가 집계까지 하고 있었습니다 — 경계를 다시 그었습니다

매출 대시보드의 숫자가 화면마다 조금씩 달랐습니다. 일 매출 요약과 채널별 상세가 미묘하게 어긋났고, 어느 테이블이 진실이냐고 물으면 아무도 바로 답하지 못했습니다. 외식 프랜차이즈 ERP의 채널 매출(POS·배달) 파이프라인에서 실제로 겪은 상황입니다.

수집 워커가 집계까지 하고 있었습니다

구조를 뜯어보니 원인은 코드 버그가 아니라 파이프라인의 모양이었습니다. 외부에서 영수증·배달앱 데이터를 긁어오는 수집 워커가 raw 저장에서 멈추지 않고, POS 코드 단위(grain)의 중간 집계 테이블까지 만들고 있었습니다. 화면이 보는 표시용 테이블은 다시 그 중간 테이블을 재가공했습니다.

raw에서 중간 집계로, 중간 집계에서 표시 테이블로 이어지는 세 단계 구조였습니다. 단계가 하나 늘 때마다 정합이 어긋날 수 있는 이음새도 하나씩 늘어납니다. 중간 테이블은 갱신됐는데 표시 테이블 재가공이 늦으면 두 화면의 숫자가 갈라지고, 그 시점을 사후에 짚어내기가 어렵습니다.

더 근본적인 문제는 소유가 흐려진 점이었습니다. 외부에서 긁어오는 일은 네트워크가 불안정해 재시도가 핵심이고, raw를 표시용으로 접는 일은 정합과 재현이 핵심입니다. 실패 양상도 고치는 사람도 다른 두 일을 한 컴포넌트가 겸하니, 매출 제외 규칙 같은 집계 로직이 어디 있는지 찾는 것부터가 일이었습니다.

워커는 수집만, 집계는 백엔드 배치가

재편의 방향은 단순했습니다. 워커는 raw 수집 전용으로 되돌리고, 집계는 백엔드의 시스템 배치 태스크가 맡았습니다. 배치는 6시간 주기로 영수증·배달앱 raw에서 표시용 단일 테이블로 직접 집계합니다. 매출 제외 규칙 같은 비즈니스 로직도 이 배치 한 곳에 모았습니다.

POS 코드 grain의 중간 집계 테이블은 폐기했습니다. raw에서 표시 테이블로 한 번에 접으면 어긋날 중간 단계 자체가 사라집니다. 처음엔 정합 모니터링을 강화하는 방향도 검토했지만, 운영해보니 정합 문제는 잘 관리하는 것보다 어긋날 자리를 없애는 쪽이 유지비가 쌌습니다.

외부→DB 수집은 워커, DB→DB 정리는 백엔드

이 한 문장을 경계 규칙으로 문서에 못박았습니다. 규칙이 문서에 없으면 다음 기능을 붙이는 사람이 다시 워커에 집계를 넣게 됩니다. 코드 리뷰에서 매번 같은 논쟁을 반복하는 대신, 문서의 한 줄을 가리키면 끝나는 구조를 만든 것입니다.

컴포넌트가 자기 역할 밖의 일을 소유하기 시작하면 비슷한 문제가 반복됩니다. BFF가 도메인 데이터를 소유했을 때 겪은 문제도 같은 계열이었습니다.

잡의 종류를 타입 컬럼으로 못박았습니다

경계를 나눈 김에 잡의 종류도 데이터로 명시했습니다. 크롤(수집) 잡과 시스템(집계) 잡을 타입 컬럼으로 구분하고, 어느 실행 경로로 갈지도 이 타입이 결정하게 했습니다. 배치 관리 화면에는 타입 뱃지가 붙어, 운영자가 지금 도는 잡이 수집인지 집계인지 한눈에 구분합니다.

파이프라인의 단계를 명시적으로 가르는 접근은 이번이 처음이 아니었습니다. 임포터에서 변환과 적재를 분리했을 때도 단계를 섞지 않는 것만으로 디버깅 지점이 절반으로 줄었습니다.

옛 경로는 diff=0을 보고 나서 지웠습니다

재편에서 가장 조심한 부분은 삭제 순서입니다. 새 배치를 먼저 돌려 구 파이프라인과 신 파이프라인의 결과를 행 단위로 대조했습니다. 약 8천 행이 한 줄도 다르지 않은 것, 즉 diff=0을 확인한 뒤에야 워커의 집계 코드와 중간 테이블을 삭제했습니다.

주의할 점은 대조 단위입니다. 합계만 비교하면 서로 다른 방향의 오류가 상쇄돼 거짓 안심이 됩니다. 행 단위로 키를 맞춰 대조해야 새 경로가 옛 결과를 정확히 재현하는지 알 수 있습니다.

공짜는 아니었습니다

이 재편에도 비용은 있습니다. 도입 전에 알았다면 좋았을 트레이드오프를 정리하면 이렇습니다.

중간 테이블이 없으면 매 집계가 raw를 다시 접어야 합니다. 6시간 주기와 증분 처리로 비용 균형을 잡았습니다.

수집과 집계가 컴포넌트로 갈리면 배포·모니터링 지점이 늘어납니다. 대신 장애가 났을 때 어느 쪽 문제인지는 즉시 갈립니다.

diff 검증은 대조 단위를 잘못 잡으면 거짓 안심이 됩니다. 행 단위 키 매칭까지 내려가야 의미가 있습니다.

수집(외부→DB)과 집계(DB→DB)가 한 컴포넌트에 섞여 있지 않은가

같은 지표를 만드는 테이블이 몇 단계를 거치는가 — 단계 수만큼 어긋날 자리가 있다

raw에서 표시 테이블로 직접 접을 수 있는데 중간 grain 테이블을 유지하고 있지 않은가

파이프라인 재편 시 구/신 결과를 행 단위 diff=0으로 대조한 뒤에 옛 경로를 지우는가

잡의 종류(수집/집계)가 타입 컬럼으로 구분돼 라우팅과 운영 화면에 드러나는가

화면마다 다르던 매출 숫자는 단일 표시 테이블로 모인 뒤 하나가 됐습니다. 돌아보면 파이프라인 문제의 상당수는 로직 버그가 아니라 경계의 문제였습니다. 어느 테이블이 진실이냐는 질문에 바로 답할 수 없다면, 고칠 것은 쿼리가 아니라 구조일 가능성이 높습니다.