재처리 비용은 배치냐 스트리밍이냐가 아니라 "무엇을 다시 태우느냐"에서 갈린다. CDC 히스토리를 스트리밍 경로로 그대로 흘리면 비압축 바이트 과금이 청구서에 그대로 얹히고, 변경분만 배치·마이크로배치로 처리하면 비용이 90% 넘게 줄기도 한다. 이번 리포트에서는 재처리 작업을 스트리밍 경로에 묶어뒀다가 비용이 튄 사례를 재구성해 뜯어봤다.

재처리 비용 급증, 정말 스트리밍 탓이었나?

결론부터: 아니다. 비용이 튄 이유는 스트리밍 자체가 아니라 백필(backfill) 작업을 스트리밍 API 경로로 그대로 태운 설계였다. 변경분만 흐르던 파이프라인에 30일치 히스토리가 얹히자, 비압축 바이트 기준 과금이 고스란히 청구됐다. 스트리밍이냐 배치냐는 결과일 뿐, 원인은 재처리 범위 설정이었다.

  • 재처리 비용은 "얼마나 자주 넣느냐"가 아니라 "얼마나 많은 히스토리를 다시 태우느냐"로 결정된다.
  • Snowflake·BigQuery 계열 스트리밍 적재는 행 수가 아니라 비압축 GB 기준 과금이라 버스트 워크로드에 취약하다(Snowpipe Streaming 개요).
  • 마이크로배치는 1~15분 지연을 감수하는 대신 스트리밍 API 비용을 거의 0으로 낮춘다.
  • 재처리 가능한 보관을 오브젝트 스토리지에 두면 Kafka 디스크 방식 대비 최대 92%까지 비용을 줄인 실측 사례가 있다(Ursa, VLDB 2025).
  • CDC를 어디까지 실시간으로 끌고 갈지가 비용과 신선도의 실제 분기점이다.

증상: 2월 초, 스키마 변경으로 다운스트림 테이블을 재구축해야 했다. 팀은 CDC 토픽을 처음 오프셋부터 재생(replay)해 기존 스트리밍 적재 경로(Kafka → Snowpipe Streaming)로 그대로 흘려보냈다. 재생에는 약 6시간이 걸렸고, 평소 하루치 증분(수 GB)만 흐르던 경로에 30일치 히스토리(수백 GB)가 몰렸다. 다음 날 비용 대시보드에서 스트리밍 적재 항목이 전월 대비 몇 배로 뛴 게 확인됐다. 행 수 지표는 평소와 크게 다르지 않았는데 청구서만 튀었다.

이벤트 건수가 늘어서 비용이 튄 걸까?

아니다. row count 모니터링 지표는 평소 범위 안에 있었다. Snowflake·BigQuery 계열 스트리밍 적재는 행 수가 아니라 비압축 데이터 용량 기준으로 과금되기 때문에, 건수가 안정적이어도 페이로드 자체가 크면(스키마 변경으로 컬럼이 늘어난 상태) 바이트 총량은 얼마든지 튈 수 있다. 이번 케이스도 마찬가지였다 — 건수는 그대로였고, 재생 구간(30일)만큼 총 바이트가 곱해졌다.

스트리밍 API 단가 자체가 원래 배치보다 비싼가?

정상적인 증분 트래픽에서는 아니다. 평상시 하루치 CDC 증분만 흘릴 때는 마이크로배치 대비 API 호출 비용 차이가 크지 않았다. 스트리밍이 원천적으로 비싼 게 아니라, 무엇을 스트리밍시키느냐가 비용을 결정한다는 관점이 여기서 맞아떨어진다 — compute는 히스토리가 아니라 변화량에 비례해야 한다는 원칙이다.

파티션·트리거 설정 튜닝 문제였을까?

아니었다. trigger interval이나 batch 크기를 조절해 이벤트를 모아 쓰는 최적화는 작은 파일 문제(small-file overhead)를 줄이는 데는 유효하지만, 이번 청구서 급증은 처리 대상 데이터의 절대량 문제였다. 튜닝으로 흡수할 수 있는 폭이 아니었다.

그래서 실제 원인은 무엇이었나?

재처리(backfill) 작업과 실시간 증분 적재가 같은 경로를 공유한 것이 원인이었다. CDC를 event queue로 직접 읽으면 스트리밍 경로가 되고, cloud storage에 먼저 쌓아두고 읽으면 배치 경로가 되는 구분이 문서상으로도 명확한데(Databricks CDC ingestion 문서), 이 파이프라인은 그 구분 없이 재생 작업까지 스트리밍 경로 하나로 처리했다. 결과적으로 히스토리 전체가 실시간 과금 체계를 그대로 통과했다.

재발 방지로 무엇을 바꿨나?

재처리(backfill/replay)와 증분 적재의 경로를 물리적으로 분리했다. CDC 토픽 재생은 오브젝트 스토리지에 먼저 내려받아 배치로 재구성하는 경로로 옮기고, 스트리밍 API는 당일 증분만 태우도록 제한했다. 히스토리 데이터는 레이크하우스 계층으로 tiering해 저렴하게 보관하고, 필요할 때만 재처리 대상으로 꺼내 쓰도록 했다. hot data는 스트리밍 계층에, cold data는 Iceberg로 넘기는 패턴이 2026년 기준 여러 스트리밍 엔진의 릴리스 문서에서 공통으로 다뤄지는 방향이기도 하다.

배치와 스트리밍 중 뭘 고를지보다 먼저 봐야 할 것은 무엇인가?

재처리 범위를 "변경분"과 "히스토리"로 먼저 나누는 것이 우선이다. 변경분은 스트리밍이나 마이크로배치로 흘리고, 히스토리 재처리는 저렴한 오브젝트 스토리지 기반 배치 경로로 격리하면 신선도를 포기하지 않고도 재처리 비용의 상한을 걸 수 있다. 이 원칙은 특정 벤더 스택과 무관하게 적용된다. 재처리 총비용을 좌우하는 건 대개 읽기가 아니라 적재와 준비 단계이기 때문에, 그 두 단계에서 재생 범위를 좁히는 설계가 결과적으로 배치·스트리밍 선택 자체보다 비용에 더 크게 작용한다.

핵심 정리

  • 재처리 비용은 배치/스트리밍이라는 선택보다 "재생 범위"(변경분 vs 히스토리)에 더 크게 좌우된다.
  • Snowflake·BigQuery류 스트리밍 적재는 비압축 GB 과금이라 히스토리 재생 시 버스트 비용이 급증할 수 있다.
  • 오브젝트 스토리지 기반 재처리 보관은 Kafka 디스크 방식 대비 최대 92%까지 비용을 낮춘 실측 사례가 있다.
  • CDC 재처리와 실시간 증분 적재는 경로를 분리해야 한다 — 같은 경로를 쓰면 히스토리가 실시간 과금 체계를 그대로 통과한다.
  • 히스토리는 레이크하우스 계층으로 tiering하고, 스트리밍은 신선도가 필요한 증분에만 남기는 것이 재발 방지의 핵심이다.

더 알아보기

데이터 파이프라인 아키텍처: 배치·스트리밍·신선도의 설계 축 — 이 주제의 종합 가이드