월별 통계 데이터를 미리 적재하는 이유

데이터와 리포트 설계 시리즈 6/8

운영 콘솔에는 통계 화면이 자주 등장한다.

월별 매출, 주문 수, 사용자 수, 처리 건수, 리포트 합계 같은 지표를 보여준다.

처음에는 화면이 열릴 때마다 원천 데이터를 조회해서 실시간 집계하면 된다고 생각할 수 있다.

하지만 운영 통계는 매번 실시간으로 계산하는 것이 항상 좋은 선택은 아니다.

반복 조회되는 통계는 미리 계산해두는 편이 더 안정적일 수 있다.

문제 상황

운영자는 대시보드에서 월별 통계를 자주 확인한다.

통계는 여러 원천 데이터를 조합해서 계산해야 한다.

데이터 범위가 넓거나 쿼리가 복잡하면 매번 화면 조회 시 집계하는 방식은 부담이 된다.

특히 다음 문제가 생길 수 있다.

• 대시보드 로딩이 느려진다.
• DB에 반복적인 집계 부하가 생긴다.
• 같은 월 통계를 여러 사용자가 반복 조회한다.
• 과거 월 데이터는 자주 바뀌지 않는데 매번 다시 계산한다.
• 기준 시점이 애매해진다.

이럴 때 월별 통계 데이터를 미리 적재하는 방식을 검토한다.

실시간 집계의 장점과 한계

실시간 집계는 단순하다.

항상 원천 데이터 기준 최신 값을 보여준다.

하지만 한계가 있다.

• 쿼리가 무거워질 수 있다.
• 화면 응답 시간이 길어진다.
• 원천 DB에 부하를 준다.
• 집계 기준이 코드에 숨기 쉽다.
• 반복 조회에 비효율적이다.

실시간성이 정말 필요하다면 이 비용을 감수할 수 있다.

하지만 월별 통계처럼 몇 분 또는 몇 시간 단위 지연이 허용되는 데이터라면 매번 실시간 계산할 필요가 없을 수 있다.

미리 적재한다는 것

미리 적재한다는 것은 원천 데이터를 읽어 통계 결과를 별도 테이블이나 파일에 저장해두는 것이다.

예를 들어:

monthly_statistics

또는:

statistics/monthly-YYYY-MM.json

대시보드는 이 결과를 빠르게 읽는다.

원천 데이터
-> 집계 쿼리
-> 월별 통계 저장
-> 대시보드 조회

집계 비용은 적재 시점에 발생하고, 조회는 가벼워진다.

기준 시점이 생긴다

통계는 기준 시점이 중요하다.

예를 들어 월별 통계를 볼 때 "지금 이 값이 언제 기준인가"가 필요하다.

미리 적재하면 다음 정보를 남길 수 있다.

• 통계 대상 월
• 집계 실행 시각
• 원천 데이터 기준 시각
• 집계 버전
• 생성자 또는 실행 주체

이 정보가 있으면 운영자가 숫자를 더 신뢰할 수 있다.

실시간 집계는 항상 최신처럼 보이지만, 오히려 기준 시점을 설명하기 어려울 수 있다.

대시보드와 리포트의 요구사항은 다르다

대시보드는 빠른 조회가 중요하다.

리포트는 정확성과 재현 가능성이 중요하다.

월별 통계 적재는 이 둘 사이를 연결한다.

대시보드는 미리 계산된 값을 빠르게 보여주고, 리포트는 필요한 경우 같은 기준의 데이터를 파일로 생성한다.

중요한 것은 통계 계산 기준을 한 곳에 모으는 것이다.

대시보드 쿼리와 리포트 쿼리가 서로 다르면 숫자가 달라질 수 있다.

적재 주기 정하기

월별 통계라고 해서 반드시 한 달에 한 번만 적재하는 것은 아니다.

운영 요구에 따라 주기를 정한다.

• 매일 새벽
• 매시간
• 수동 실행
• 월말 확정 후 실행
• 데이터 변경 이벤트 후 실행

과거 월 데이터는 거의 바뀌지 않을 수 있지만, 현재 월 데이터는 계속 바뀐다.

따라서 현재 월과 과거 월의 적재 전략을 다르게 둘 수도 있다.

적재 쿼리도 운영 로직이다

통계 적재 쿼리는 단순 SQL이 아니다.

운영 지표의 정의가 들어 있다.

예를 들어:

• 어떤 상태를 포함할 것인가
• 취소 데이터는 제외할 것인가
• 날짜 기준은 생성일인가 확정일인가
• 금액은 세전인가 세후인가
• 중복 데이터는 어떻게 처리할 것인가

이 기준이 쿼리에만 숨어 있으면 위험하다.

문서로 남겨야 한다.

통계 숫자는 운영 의사결정에 쓰이기 때문이다.

실패 처리

통계 적재도 실패할 수 있다.

• 원천 쿼리 timeout
• DB 연결 실패
• 중간 데이터 불일치
• 저장 실패
• 중복 실행

따라서 적재 작업에도 상태와 로그가 필요하다.

작은 시스템에서는 수동 실행과 로그 확인만으로 충분할 수 있다.

하지만 운영 지표가 중요해지면 적재 이력 테이블이나 batch log를 둘 수 있다.

언제 미리 적재할까

다음 조건이면 미리 적재를 검토한다.

• 같은 통계를 반복 조회한다.
• 집계 쿼리가 느리다.
• 원천 DB 부하를 줄이고 싶다.
• 기준 시점이 중요하다.
• 대시보드 로딩 속도가 중요하다.
• 리포트와 화면의 숫자를 맞추고 싶다.

반대로 데이터가 작고 쿼리가 충분히 빠르다면 실시간 집계로 시작해도 된다.

정리

월별 통계 데이터를 미리 적재하는 이유는 단순히 속도 때문이다.

물론 조회 속도도 중요하다.

하지만 더 중요한 것은 기준 시점, 재현 가능성, 원천 DB 부하 분산, 지표 정의의 문서화다.

운영 콘솔에서 통계는 화면 장식이 아니다.

업무 판단의 기준이다.

반복 조회되고 기준이 중요한 통계라면, 매번 실시간 계산하기보다 미리 적재하는 구조를 검토할 만하다.

함께 볼 GitHub 저장소

• report-job-worker-demo