Snowflake는 어떻게 Postgres의 변경사항을 실시간으로 퍼 올릴까 — CDC 파이프라인의 속사정

서비스 데이터베이스에 쌓이는 데이터를 분석용 시스템으로 옮기는 일, 해보신 분은 아시겠지만 생각보다 훨씬 어려운 문제인데요. Snowflake가 엔지니어링 블로그를 통해 Postgres의 데이터를 Snowflake로 실시간 복제하는 기능을 어떻게 만들었는지 그 내부를 공개했어요. 제목부터 흥미로워요. 'CDC를 Postgres 안으로 밀어 넣은 방법'이거든요.

CDC가 뭐냐면

CDC는 Change Data Capture의 약자로, 데이터베이스에서 일어나는 모든 변경 — 새로 들어온 행, 수정된 행, 삭제된 행 — 을 실시간으로 잡아내서 다른 시스템으로 흘려보내는 기술이에요. 이게 없던 시절에는 어떻게 했냐면, 매일 밤 테이블 전체를 통째로 복사하는 배치 방식을 썼어요. 데이터가 커지면 복사 시간도 부하도 감당이 안 되고, 분석계에서 보는 데이터는 항상 하루 늦은 데이터였죠. CDC는 이걸 '변경된 것만, 일어나는 즉시' 보내는 방식으로 바꿔줘요.

Postgres에는 이걸 위한 좋은 재료가 이미 있어요. WAL이라고, 데이터베이스가 모든 변경사항을 순서대로 기록해두는 일지 같은 파일인데요. 원래는 장애가 났을 때 복구하려고 만든 건데, 이 일지를 논리적인 변경 단위로 해석해서(logical decoding이라고 해요) 외부에서 구독할 수 있게 열어둔 게 Postgres의 논리 복제 기능이에요. 대부분의 CDC 도구가 이 문을 통해 변경사항을 받아 가요.

그런데 왜 '안으로 밀어 넣었다'는 걸까

보통의 CDC 구조에서는 Debezium 같은 외부 커넥터가 Postgres 바깥에 따로 떠서 WAL을 읽어가요. 그런데 이 구조에는 고질적인 어려움들이 있어요. 첫째, 처음 연결할 때는 기존 데이터 전체를 복사하는 초기 스냅샷이 필요한데, 스냅샷을 뜨는 도중에도 데이터는 계속 바뀌니까 '스냅샷과 실시간 스트림을 어디서 이어 붙여야 빠짐도 중복도 없는가'가 굉장히 까다로워요. 둘째, 복제 슬롯이라는 걸 만들어두면 Postgres는 소비자가 아직 안 읽어간 WAL을 지우지 못하고 계속 쌓아두는데, 커넥터가 잠깐 죽거나 처리가 밀리면 디스크가 가득 차서 원본 DB 장애로 번질 수 있어요. 셋째, 테이블에 컬럼이 추가되는 스키마 변경까지 따라가야 하고요. Snowflake의 접근은 이런 처리를 외부 커넥터에만 떠넘기지 않고 Postgres 쪽 구성요소가 함께 감당하도록 설계해서, 스냅샷과 스트리밍의 정합성을 데이터베이스에 가까운 곳에서 맞춘다는 거예요. CDC 파이프라인의 신뢰성 문제를 소비자 애플리케이션의 숙제가 아니라 플랫폼의 책임으로 끌어안은 거죠.

업계 흐름에서 보면

이 발표의 배경에는 더 큰 그림이 있어요. Snowflake는 2025년에 Postgres 전문 회사인 Crunchy Data를 인수하면서 운영용 데이터베이스 영역으로 발을 넓혔거든요. 분석용 웨어하우스 회사가 운영용 DB까지 품고, 그 사이를 잇는 복제 배관을 직접 만드는 흐름이에요. 경쟁 구도도 비슷하게 움직이고 있어요. ClickHouse는 Postgres CDC 전문 스타트업 PeerDB를 인수했고, AWS는 Aurora에서 Redshift로 별도 파이프라인 없이 데이터가 흘러가는 zero-ETL을 밀고 있죠. 그동안 이 영역은 Debezium에 Kafka를 얹어 직접 운영하거나 Fivetran, Airbyte 같은 별도 도구를 쓰는 게 정석이었는데, 이제는 '운영 DB와 분석계 사이의 배관을 플랫폼이 기본으로 제공한다'는 방향으로 업계 전체가 이동하는 중이에요.

한국 개발자에게는

국내에서도 RDS나 Aurora의 Postgres에 서비스를 올리고 분석은 별도 웨어하우스에서 하는 구성이 흔한데요. Debezium을 직접 운영해본 팀이라면 슬롯 관리, 스냅샷 재실행, 스키마 변경 대응이 얼마나 손이 많이 가는 일인지 아실 거예요. 관리형 CDC가 좋아질수록 그 운영 부담을 비용으로 대체할 수 있게 되는 거라, 선택지를 알아둘 가치가 충분해요. 다만 어떤 도구를 쓰든 WAL, 논리 복제, 복제 슬롯 같은 Postgres의 기본 동작은 이해하고 있어야 장애가 났을 때 대응할 수 있어요. 이번 글은 그 기본기를 실전 사례로 배우기에 좋은 자료예요.

정리하면, CDC에서 가장 어려운 부분인 스냅샷 정합성, 슬롯 관리, 스키마 변경 대응을 플랫폼 안쪽으로 옮겨서 풀었다는 이야기예요. 여러분 팀은 운영 DB와 분석계 사이를 어떻게 잇고 계세요? Debezium 직접 운영파와 관리형 서비스파의 경험담이 궁금하네요.