복잡함에서 명확함으로: Debezium에서 Snowflake Openflow로의 전환

최근 Snowflake는 SQL Server-to-Snowflake 파이프라인에 Debezium을 광범위하게 활용해온 한 헬스케어 및 라이프사이언스 고객과 협업을 시작했습니다. 표면적으로 보면 Debezium은 합리적인 선택이었습니다. Debezium은 분산 변경 데이터 캡처(CDC)의 업계 표준이고 오픈소스이며 안정적이고, 무엇보다 라이선스 비용이 들지 않기 때문입니다.

그러나 Debezium의 '0 달러' 가격표는 ‘공짜 맥주’가 아니라 유지 비용이 계속 드는 ‘공짜 강아지’에 가까웠습니다. 초기 비용 절감 효과는 Kafka Connect 클러스터에 수반되는 운영 및 관리의 복잡성과 지속적으로 발생하는 스키마 진화 문제로 빠르게 상쇄됐습니다. 결국 시스템이 계속 돌아가게 하기 위해 필요한 엔지니어링 시간은 점점 늘어났고, 고객은 인프라는 풍부하지만 정작 활용 가능한 데이터는 부족한 상태에 놓이게 되었습니다.

고객에게는 전담 엔지니어 팀이 상시 관리하지 않아도 되는 근실시간 데이터 동기화 솔루션이 필요했습니다. 결국, 전체 아키텍처를 Snowflake Openflow로 마이그레이션하기로 결정했습니다.

목표는 아주 단순해 보였습니다. SQL Server 데이터를 근실시간으로 Snowflake에 동기화하는 것이었죠. 그러나, 1~5분이라는 지연 시간 목표는 단순한 속도 이상의 것을 요구했습니다. 탄력적이고 확장 가능하며, 무엇보다 관리가 가능한 파이프라인이 필요했습니다.

환경 개요: 규모 및 성능 요구 사항

Debezium 기반 아키텍처의 유지 관리가 감당하기 어려운 수준에 이른 이유를 이해하려면, 먼저 기존에 이동하던 데이터의 규모를 살펴볼 필요가 있습니다. 이는 단일 테이블 동기화가 아니라, 고객 분석 환경의 핵심 동맥과 같은 역할을 수행하는 시스템이었습니다.

프로젝트 규모를 수치로 정리하면 다음과 같습니다.

• 총 SQL Server 인스턴스 수: 19개
• 총 데이터베이스 수: 540개, 19개 인스턴스에 분산
• 총 테이블 수: 약 129,600개, 각 데이터베이스당 최대 240개의 테이블 포함
• 지연 시간 목표: SQL Server에 트랜잭션이 발생한 시점부터 Snowflake에서 쿼리 가능해질 때까지 1~5분 이내

이 정도 규모에서는 작은 장애 하나도 막대한 적체로 이어질 수 있습니다. 기존 방식에서는 30분만 가동 중단이 발생해도 이를 복구하고 따라잡는 데 수시간의 수동 개입이 필요했습니다. 고객은 지속적인 모니터링 없이도 이러한 볼륨을 감당할 수 있는 시스템이 필요했습니다.

레거시 아키텍처의 부담: 다중 홉(multihop) Debezium 구조

기존 아키텍처: 복잡성이 겹겹이 쌓인 7단 구조

마이그레이션 전에는 데이터가 소스 시스템에서 최종 분석 대시보드에 이르기까지 길고 복잡한 경로를 거쳐야 했습니다. 전체 워크플로우는 다음과 같았습니다.

1. 트리거 단계: Debezium이 SQL Server CDC 로그에 연결되어 행 수준의 변경 사항을 감지했습니다.
2. 중간 전달 단계: 변경 이벤트들은 직렬화되어 특정 Kafka Topics로 푸시되었습니다.
3. 브리지 단계: 별도의 Kafka Connect 클러스터가 해당 Topic을 폴링하고 데이터를 Snowflake의 스테이징 영역으로 푸시를 시도했습니다.
4. 원시 데이터 랜딩 단계: 데이터는 Snowflake에 'raw JSON' 형태로 도착했습니다. 이는 메타데이터와 중첩된 페이로드가 뒤섞인 사실상 정제되지 않은 데이터 덩어리였습니다.
5. 정제 단계: Debezium 이벤트는 복잡한 ‘봉투' 구조(전/후 상태 포함)로 감싸져 있기 때문에, 이를 처리하기 위한 사용자 지정 Snowflake 태스크를 별도로 작성하고 유지해야 했습니다.
6. 평탄화 단계: 이 태스크들은 주기적으로 트리거되어 JSON을 파싱하고 데이터를 관계형 형식으로 변환했습니다.
7. 최종 병합 단계: 이 과정을 모두 거친 뒤에야 데이터는 최종 프로덕션 테이블에 병합되어 실제 분석에 활용될 수 있었습니다.

운영 오버헤드의 원인

Figure 1의 모든 화살표는 잠재적인 장애 지점을 나타냅니다. Kafka Connect 작업 프로세스에 지연이 발생하면 데이터 적재도 함께 지연되었습니다. Snowflake 태스크가 실패하면 원시 테이블에 파싱되지 않은 데이터가 계속 쌓였습니다. 이와 같이, 단순히 데이터를 이동하는 것이 아니었습니다. 상호 의존적인 여러 서비스로 구성된 복잡한 생태계를 지속적으로 관리해야 했던 것입니다.

스택 단순화: Openflow의 직접 수집 모델

Openflow로의 진화: 스택 단순화

Figure 1이 복잡한 다단계 아키텍처를 보여준다면, Figure 2는 단순화된 직접 연결 구조를 보여줍니다. Openflow를 도입하면서 아키텍처 전반의 ‘노이즈'가 사라졌습니다. Debezium, MSK, Kafka Connect 그리고 수동으로 관리하던 Snowflake 태스크까지 포함된 다중 홉 릴레이 구조 대신, SQL Server에서 Snowflake로 직접 연결하는 방식으로 전환했습니다.

Openflow가 파이프라인을 재정의한 방식

• 네이티브 변경 추적: 기존의 CDC 방식 대신, Openflow SQL Server Connector는 네이티브 변경 추적 기능을 활용하여 트랜잭션을 정밀하게 식별합니다.
• 자동 스키마 진화: Debezium 운영에서 가장 큰 골칫거리 중 하나였던 스키마 드리프트는 더 이상 문제가 되지 않았습니다. Openflow는 소스 시스템의 변경 사항을 자동으로 감지하고, Snowflake 테이블을 실시간으로 업데이트합니다. DBA가 컬럼을 하나 추가했다고 해서 파이프라인이 깨지는 일은 더 이상 없습니다.
• Snowflake로 직접 적재: Kafka를 완전히 우회했습니다. Openflow는 중간 스토리지나 외부 컴퓨팅 클러스터 없이, 데이터를 Snowflake로 직접 적재합니다. 그 결과, 아키텍처의 복잡성이 크게 줄어들었습니다.
• 사용자 지정 태스크 제거: Openflow는 데이터를 바로 활용 가능한 형태로 제공하기 때문에 고객은 기존에 사용하던 복잡한 Snowflake JSON 평탄화 태스크와 병합 스크립트 라이브러리를 모두 제거할 수 있었습니다.

비교

고객의 실제 운영 환경에서 수집한 지표를 바탕으로, Debezium과 Openflow를 비교하면 다음과 같습니다.

다음은 Debezium과 Openflow의 실제 비용 비교입니다.

결론: 복잡한 스택에서 벗어날 시간

Debezium에서 Openflow로 전환하는 일은 단순히 도구를 변경하는 것이 아니라 엔지니어링 시간을 되찾는 일입니다. Kafka라는 ‘중간 단계'를 제거함으로써, 고객은 인프라 비용을 절감했을 뿐만 아니라, 상시 관리에 의존하지 않아도 안정적으로 확장 가능하고 더 탄력적이며 자가 복구 가능한 파이프라인을 확보했습니다.

만약 현재 팀이 ‘인프라는 풍부하지만 데이터 활용은 부족한' 상태라면 이제는 아키텍처 스택을 단순화해야 할 때일지도 모릅니다.

Snowflake 수집 파이프라인을 간소화할 준비가 되셨나요?

다음 단계로 나아가는 방법은 다음과 같습니다:

• 운영 오버헤드 점검: 현재 Debezium/Kafka 환경을 유지 관리하는 데 얼마나 많은 시간이 소요되는지 점검해 보세요. 매주 두 시간 이상을 ‘배관 정비'에 쓰고 있다면, Snowflake Openflow 도입을 검토할 이유는 충분합니다. 
• 실제 동작 확인: Snowflake 웹 사이트를 방문하여 Openflow가 SQL Server 변경 추적을 네이티브 방식으로 처리하고 Snowflake 스키마 진화를 자동화하는 방법을 확인하세요.
• 파일럿 개시: 개념 증명(PoC)을 설정하고 Openflow가 1~5분의 지연 범위를 안정적으로 유지하는지 현재 Debezium 환경과 직접 비교해 보세요.