안녕하세요, 볼트업에서 데이터 엔지니어링을 담당하고 있는 제임스입니다.

이번 포스팅에서는 올해 볼트업의 분석 환경을 구축하는 데 핵심적인 역할을 한 CDC(Change Data Capture) 파이프라인에 대해 이야기하려 합니다.

1. 서비스 성장과 함께 찾아온 '운영 DB 부하'와 분리의 필요성

🫠 서비스 성장과 운영 DB의 비명

서비스가 커감에 따라 마주하는 대표적인 기술 부채 중 하나는 바로 운영 DB의 과부하입니다. 원인은 다양하지만, 설계 의도와 다른 사용 방식이 화근이 되곤 합니다. 즉, 운영용으로 설계된 DB를 분석용으로도 활용하려 할 때 발생하는 문제입니다.

데이터가 적은 초기에는 문제가 없지만, 데이터가 쌓일수록 분석 쿼리는 과도한 리소스를 점유하게 됩니다. 이는 작게는 서비스 지연(Latency)을 유발하고, 크게는 전체 장애의 원인이 되기도 합니다. 볼트업은 이 문제를 해결하기 위해 운영 환경과 분석 환경을 분리하고, 빅쿼리(BigQuery) 기반의 분석 환경을 구축했습니다.

왜 분리가 필요한가? (OLTP vs OLAP)

우리가 운영 DB라고 부르는 시스템은 대부분 OLTP 방식인 반면, 빅쿼리와 같은 데이터 웨어하우스는 OLAP 방식입니다. 이 둘은 설계 목적부터가 다릅니다.

OLTP는 강력한 정합성을 보장하지만, 한 번에 처리할 수 있는 데이터 크기가 한정적입니다. 따라서 대규모 조회가 잦은 분석 환경에서는 효율이 떨어질 수밖에 없습니다. 반면에 OLAP는 데이터 분석에 최적화된 설계를 갖습니다.

🚀 GCP의 강력한 분석 환경, 빅쿼리(BigQuery)

볼트업이 분석 환경으로 선택한 빅쿼리는 다음과 같은 확실한 이점을 제공합니다.

• 압도적인 속도: 컬럼 기반 저장 구조와 서버리스 분산 컴퓨팅으로 수억 건의 데이터도 순식간
• 운영 안정성: 인프라 관리 부담이 없으며, GCP 환경 내에서 뛰어난 통합성을 자랑합니다.
• 비용 효율성: 사용한 만큼만 지불하며, 대규모 데이터를 안정적으로 보관할 수 있습니다.
  

빅쿼리가 왜 분석에 유리한지에 대해서 더 많은 장점이 있지만, 이번 포스팅의 주제인 CDC 파이프라인에 집중하기 위해 줄이도록 하겠습니다.

중요한 점은, 운영은 운영답게, 분석은 분석답게 각자의 역할에 집중할 수 있는 환경을 만들어야 한다는 것입니다.

2. 빅쿼리 분석 환경 구축을 위한 핵심, CDC 파이프라인

분석을 위한 빅쿼리 환경이 준비되었다면, 이제 그곳에 채울 데이터를 어떻게 가져올지 고민해야 합니다. 가장 기본이 되는 데이터는 역시 서비스의 최전선인 운영 DB에 쌓이는 데이터들입니다. 하지만 운영 DB의 데이터를 옮기는 작업은 생각보다 까다로운 네 가지 제약 조건을 만족해야 합니다.

🛡️ 데이터 수집의 4대 원칙

단순히 데이터를 옮기는 것을 넘어, 엔지니어로서 다음의 기준을 충족해야 했습니다.

• 안정성 (At-least-once): 데이터가 유실되어서는 안 됩니다. 최소 1회 전달을 보장하여 분석 결과의 신뢰도를 확보해야 합니다.
• 운영 DB 저부하: 데이터 추출 작업이 서비스 운영에 지장을 주어서는 안 됩니다. (도입부에서 언급한 부하 문제를 다시 야기하면 안 되기 때문입니다.)
• 실시간성: 비즈니스 요구사항에 따라 데이터 신선도가 유지되어야 합니다.
• 보안: 전송 과정에서 데이터가 외부로 노출되지 않도록 강력한 보안 연결이 필요합니다.

이러한 제약 사항을 모두 해결할 수 있는 최적의 솔루션이 바로 CDC(Change Data Capture) 파이프라인입니다.

👀 CDC 파이프라인이란?

CDC는 말 그대로 Change Data Caputure, “데이터의 변경 사항을 캡처”한다는 의미입니다.

DB에서 발생하는 모든 INSERT, UPDATE, DELETE 이벤트를 실시간으로 감지하여 타겟 시스템(빅쿼리)에 반영하게끔 구성되어 있습니다.

잘 구성된 CDC 파이프라인은 데이터 수집의 원칙을 준수하며 데이터를 수집하고 저장할 수 있습니다.

이를 통해, 운영 환경과 분석 환경의 분리 를 이룰 수 있게 됩니다.

🏗️ 일반적인 구축 패턴 vs 볼트업의 선택

보통 CDC 파이프라인을 구축할 때 다음과 같은 구성안들을 검토합니다

• 오픈소스 기반 (Debezium + Kafka): 가장 유연하고 강력하지만, 직접 서버를 띄우고 Kafka 클러스터를 관리해야 하는 운영 리소스가 매우 큽니다. 대신 운영 리소스를 감당할 수 있다면 가장 저렴한 선택지입니다.
• 서드파티 솔루션 (Fivetran 등): 사용은 매우 편리하지만, 데이터 처리량에 따른 비용 부담이 급격히 늘어날 수 있습니다.
• 클라우드 네이티브 서비스 (GCP Datastream 등): 클라우드 환경에 최적화된 서비스입니다. GCP에서는 GCP DataStream을 제공합니다.

볼트업은 운영 공수를 최소화하면서도 GCP 생태계와의 완벽한 통합을 위해 GCP Datastream을 선택했습니다. 인프라 관리 없이 클릭 몇 번과 간단한 설정만으로 안정적인 CDC 환경을 구축할 수 있었기 때문입니다.

3. 기술 배경 : CDC 아키텍쳐와 로그 베이스의 이점

GCP Datastream은 로그 기반(Log-based) CDC 방식을 사용하여 소스 데이터베이스의 변경 사항을 실시간으로 추적합니다. 이번 파트에서는 CDC가 이루어지는 흐름과 그냥 쿼리를 통해 가져오는 것에 비해 로그 기반으로 가져오는 것이 왜 효율적인지 대해 간단히 말씀드리겠습니다.

3.1 CDC의 표준 아키텍처

일반적인 CDC 환경(예: Debezium + Kafka 조합)은 크게 세 가지 컴포넌트로 구성됩니다.

1. Capture (Log Reader): 소스 DB의 Binary Log(MySQL)나 WAL(PostgreSQL)을 실시간으로 읽어내는 엔진입니다. 오픈소스 진영에서는 Debezium이 가장 대표적인 '빈로그 리더' 역할을 수행합니다.
2. Transport (Message Bus): 캡처한 변경 이벤트를 유실 없이 전달하기 위한 통로입니다. 주로 Apache Kafka나 Google Cloud Pub/Sub 같은 메시지 큐를 사용합니다.
3. Apply (Consumer): 전달받은 이벤트를 목적지(BigQuery, Cloud Storage 등)의 규격에 맞게 변환하여 적재합니다.

GCP Datastream은 이 복잡한 파이프라인(Capture-Transport-Apply)을 Serverless 형태로 통합한 서비스입니다. 사용자가 복잡한 Kafka 클러스터를 관리할 필요 없이, 소스와 타겟만 연결하면 내부적으로 로그를 파싱하고 데이터를 실시간으로 스트리밍해 줍니다.

그렇다면 왜 쿼리 방식(Query-based)이 아닌, 이러한 '로그 기반 방식'(CDC의 주요 데이터 수집 패턴)이 운영 DB에 이로운 선택일까요? 그 핵심 이유 세 가지를 정리했습니다.

3.2 로그 기반이 운영 DB에 부담이 적은 이유

3.2.1 실행 계획(Execution Plan)과 연산의 부재

우리가 일반적인 SELECT 쿼리를 날리면 DB 엔진은 매우 바빠집니다. 인덱스를 탈지, 데이터를 어디서 읽어올지 최적의 경로를 계산(Parsing & Optimization)해야 하고, 메모리에 데이터가 없으면 디스크에서 퍼올려야 합니다. 이 과정 자체가 CPU와 메모리를 점유합니다.

반면, 로그 기반 CDC는 DB가 트랜잭션 복구를 위해 어차피 남기고 있는 일기장(MySQL의 Binlog)을 순차적으로 읽기만 합니다. 복잡한 계산 없이 이미 파일로 써진 내용을 스트리밍하는 것이라 엔진에 가해지는 계산 부하가 거의 없습니다.

3.2.2 락(Lock) 프리: 서비스 쿼리와 경쟁하지 않음

쿼리 기반 방식의 가장 큰 공포는 바로 '락(Lock)'입니다. 분석용 쿼리가 특정 테이블을 길게 점유하고 있으면, 운영 서비스의 UPDATE나 INSERT가 대기 상태에 빠지며 서비스 장애로 이어지기도 합니다.

로그 기반 방식은 데이터 페이지 자체를 점유하는 것이 아니라, 이미 커밋된 변경 사항이 기록된 별도의 '로그 파일'을 비동기적으로 읽습니다. 즉, 실제 서비스 트랜잭션과 데이터를 읽으려는 주체가 서로 충돌할 일이 물리적으로 분리되어 있습니다.

3.2.3 스캔 범위의 차이: 효율적인 증분 추출

쿼리 방식은 "마지막으로 가져온 데이터 이후에 변한 게 뭐야?"를 찾기 위해 특정 컬럼(예: updated_at)을 계속 훑어야 합니다. 데이터가 많아질수록 이 스캔 범위는 넓어지고 인덱스 부하도 커집니다.

하지만 로그 방식은 로그 파일의 포인터(LSN/Offset) 위치만 기억하고 있다가, 새로 추가된 로그 레코드만 툭툭 던져줍니다. 전체 데이터를 뒤질 필요 없이 '새로 써진 일기'만 읽으면 되니 효율적일 수밖에 없습니다

4. 실전 구축 : 소스 설정부터 빅쿼리 연동까지

Datastream의 동작 원리를 이해했다면, 이제 실제로 파이프라인을 구축할 차례입니다.

과정은 크게 [소스 프로필 설정 → 타겟 프로필 설정 → 스트림 생성]의 3단계로 나뉩니다.

1. 소스 프로필(Source Profile): 원본 데이터 정의

데이터를 가져올 원본 DB의 접속 정보를 설정하는 단계입니다. 볼트업에서 사용하는 MySQL을 기준으로 핵심 요소는 다음과 같습니다.

• 접속 정보: 호스트 이름(혹은 IP)과 포트 번호.
• 전용 사용자(User) 생성: Datastream이 사용할 별도의 계정을 만드는 것을 추천합니다. 사용할 테이블에 대한 SELECT 권한은 물론, 빈로그(Binlog) 파일을 읽고 복제할 수 있는 특수한 권한이 반드시 필요하기 때문입니다.

CREATE USER 'datastream'@'%' IDENTIFIED BY 'YOUR_PASSWORD';
GRANT REPLICATION SLAVE, SELECT, REPLICATION CLIENT ON *.* TO 'datastream'@'%';
FLUSH PRIVILEGES;

• 연결 방식: 공개 IP 기반 연결도 가능하지만, 운영 환경에서는 보안을 위해 PSC(Private Service Connect) 기반의 연결 방식을 강력히 권장합니다. GCP의 내부 네트워크를 통해 안전하게 데이터를 전송할 수 있습니다.

2. 타겟 프로필(Target Profile): 저장 위치 지정

데이터가 복제될 목적지를 설정합니다. Datastream은 크게 두 가지 선택지를 제공합니다.

• GCS(Google Cloud Storage): 데이터를 파일 형태로 적재합니다. 이후 별도의 ETL 파이프라인을 통해 암호화나 커스텀 백업 등 후처리가 필요한 경우 유리합니다.
• BigQuery: 데이터베이스의 데이터를 빅쿼리 테이블로 직접 싱크합니다. 저희는 데이터 웨어하우스와의 즉각적인 동기화가 목적이었으므로 빅쿼리를 타겟으로 구성하였습니다.

3. 스트림 구성: 백필(Backfill)과 CDC의 조화

두 프로필을 연결하면 마지막으로 스트림(Stream)을 생성합니다. 이때 복제할 테이블과 빅쿼리 데이터셋을 매핑하게 되는데, 핵심적인 동작은 다음 두 가지입니다.

• 백필(Backfill): 스트림 시작 시점에 원본 테이블에 있는 기존 데이터를 한 번에 긁어오는 작업입니다. 일종의 '초기 스냅샷'입니다. (CDC에 비해 초기 백픽은 운영 리소스를 사용합니다. 데이터의 양이 많다면 주의가 필요합니다.)
• CDC(Change Data Capture): 백필 이후 발생하는 모든 변경 사항(추가, 수정, 삭제)을 binlog 기반으로 실시간 반영합니다.

💡 구축 완료

초기 백필 한 번과 이후에 CDC를 통해 소스 DB의 데이터 변경이 빅쿼리에 실시간에 가깝게 동기화됩니다. 이제 분석가들은 운영 DB 부하 걱정 없이, 가장 최신 상태의 데이터를 빅쿼리에서 마음껏 쿼리할 수 있게 됩니다.

5. 실전에서 마주한 이슈와 해결책

Datastream은 매우 편리한 도구지만, 실제 운영 환경에 적용하다 보니 예상치 못한 시행착오들이 있었습니다. 구축 시 참고하면 좋을 세 가지 핵심 이슈를 공유합니다.

(후술할 시행착오는 Mysql 데이터베이스에서 빅쿼리로 연결했을 때 발생한 이슈입니다.)

⚠️ 1. Schema Drift: 자동화되지 않는 스키마 변경

가장 빈번하게 발생한 문제는 원본 DB의 스키마 변경(ALTER TABLE 등)이었습니다.

• 현상: 소스 DB의 스키마가 변하면 Datastream은 즉각적으로 반영하기보다 경고 알람을 띄우며 해당 테이블의 CDC를 생략하는 경우가 있었습니다.
• 해결: 빅쿼리에 이미 저장된 기존 데이터와 변경된 스키마 사이의 간극을 사용자가 직접 조정해 주어야 했습니다. Managed Service라고 해서 스키마 관리까지 완벽히 자동화될 것이라 기대하기보다는, 변경 관리 프로세스를 미리 세워두는 것이 중요합니다.

💸 2. 의미 없이 흐르는 데이터와 비용 폭발

CDC는 모든 변경 내역(Insert, Update, Delete)을 추적합니다. 여기서 간과했던 점은 '업데이트 빈도'였습니다.

• 현상: 충전기의 상태 정보가 빠르게 변화하는 테이블을 CDC 타겟으로 잡았더니 상당한 비용이 청구되었습니다. 테이블의 전체 크기는 크지 않았지만, 업데이트 이벤트가 워낙 빈번하여 처리되는 데이터 전송량이 급증했기 때문입니다.
• 해결: 해당 테이블의 실시간 상태값이 분석에 필수적이지 않다면 CDC 대상에서 제외하는 것이 맞습니다. 데이터스트림은 처리된 데이터 양에 비례해 과금되므로, 반드시 모니터링을 통해 '비용 대비 분석 가치'가 높은 테이블인지 선별해야 합니다.

💡 핵심 인사이트 "모든 데이터를 옮길 수 있다고 해서, 모든 데이터를 옮겨야 하는 것은 아니다." 데이터의 성격에 따라 CDC가 정답이 아닐 수 있음을 체감한 순간이었습니다.

6. 한계와 개선점: 비용과 효율 사이의 최적점 찾기

GCP Datastream과 같은 매니지드 서비스(Managed Service)를 도입할 때 가장 주의해야 할 점은 역시 비용 효율성입니다. 인프라 관리의 편리함과 운영 비용 사이에서 저울질하며 최적의 효율을 찾는 것이 중요하다는 것을 다시 한 번 깨달았습니다.

⚠️ CDC가 만능은 아니다

앞선 사례처럼 업데이트가 너무 잦은 테이블은 CDC에 적합하지 않을 수 있습니다. 업데이트가 잦은 테이블은 데이터의 성격과 분석의 목적에 따라 우리는 다음과 같은 전략적인 선택을 해야 합니다.

• 분석에 필요 없는 데이터: 과감히 CDC 대상에서 생략합니다.
• 데이터 양이 적은 경우: 실시간 CDC보다는 1일 1회 배치로 전체를 가져오거나 머지하는 것이 훨씬 경제적입니다.
• 업데이트 이력 자체가 중요한 정보인 경우: CDC를 통해 현재 상태를 동기화하기보다는, 애플리케이션 단에서 이벤트 로그를 직접 남겨 별도의 파이프라인으로 관리하는 것(혹은 GCS로 타겟을 지정한 뒤, 후처리 파이프라인을 구축하는 것이)이 데이터 무결성과 분석 가치 측면에서 더 나을 수 있습니다.

7. 마치며

지금까지 볼트업이 GCP Datastream을 활용해 실시간 CDC 파이프라인을 구축한 과정을 살펴보았습니다. 이번 구축을 통해 운영 환경과 분석 환경이 분리는 단순한 데이터의 이동이 아닌, 서비스의 안정성을 지키면서 동시에 비즈니스의 인사이트를 준비하는 전략적인 과정이라는 점을 배울 수 있었습니다.

앞으로도 볼트업은 효율적인 데이터 파이프라인을 통해 볼트업 구성원들의 더 빠르고 정확한 데이터 기반의 의사결정을 지원해 나갈 예정입니다. 저와 비슷한 고민을 하는 독자분들에게 이 기록이 작은 도움이 되기를 바라며 포스팅 마치겠습니다.

참고

• https://docs.cloud.google.com/datastream/docs/overview?hl=ko