이 게시물은 Thrive Learning의 데이터 엔지니어링 팀이 작성했습니다. 본문에 담긴 의견과 경험은 해당 팀의 견해를 바탕으로 합니다.
Snowflake를 도입하기 전, Thrive의 레거시 분석 환경은 예약된 배치 작업과, 일정에 따라 새로 고침을 트리거하는 MongoDB 변경 스트림을 조합해 운영됐습니다. 하지만 Snowflake로 전환하면서 처음부터 Dynamic Table을 기반으로 구축했습니다. 이는 지연된 배치 처리 대신 플랫폼 데이터에 변경이 발생하는 즉시 지속적으로 동기화하고 변환해야 한다는 핵심 요구 사항을 충족하기 위한 선택이었습니다.
이처럼 데이터의 최신성을 유지하는 것은 단순한 백오피스 운영상의 편의 기능이 아니라 Thrive 제품의 핵심 요소입니다. 고객이 모든 학습 데이터를 탐색할 수 있도록 지원하는 Analyse 제품군은 Thrive 플랫폼이 제공하는 핵심 기능입니다. 또한 성능 향상과 데이터 최신성이 향상될수록 고객 만족도와 영업 영업 경쟁력도 직접적으로 높아진다는 사실도 확인했습니다. 고객은 분석 기능을 별도의 제품으로 구매하지는 않지만, 분석 품질은 Thrive가 신규 고객을 유치하고 기존 고객을 유지하는 데 중요한 역할을 합니다. 최근에는 이러한 데이터와 Dynamic Table 기반이 Thrive의 첫 번째 유료 애드온 서비스인 Analyse with AI의 토대가 되었습니다. Analyse with AI는 기존 데이터 파이프라인 위에 AI 기능을 더해 제공하는 서비스입니다.
이 글에서는 새로운 사용자 지정 증분 처리 기능을 활용해 Dynamic Table의 가격 대비 성능을 어떻게 개선했는지 자세히 소개합니다. 이 프로젝트는 Thrive의 선임 데이터 엔지니어인 Rob Howe의 주도 하에 진행되었습니다. 그는 팀이 직면한 과제에 사용자 지정 증분 처리가 매우 적합하다는 점을 확인했고, 해결 방안을 설계한 뒤 테스트를 거쳐 불과 몇 주 만에 프로덕션 환경에 배포했습니다.
Thrive Learning 소개
Thrive는 영국에 본사를 둔 엔터프라이즈 학습 플랫폼(LMS/LXP)으로, 제조, 항공, 리테일 등 다양한 산업 분야에서 500개 이상의 B2B 고객사(테넌트)에 서비스를 제공하고 있습니다. Thrive의 데이터 및 AI 엔지니어링 팀은 Snowflake를 기반으로 분석 및 AI 제품을 운영하며, Dynamic Table을 적극 활용해 원시 운영 데이터를 고객 대상 리포팅과 Thrive AI 어시스턴트를 지원하는 데이터 모델로 변환하고 있습니다.
중복 제거 복잡성이 비용을 높이는 이유
Thrive의 핵심 데이터 파이프라인 중 하나인 RecordStore는 본래 Dynamic Table이 가장 잘 처리하도록 설계된 전형적인 사례였습니다. 자동으로 새로 고침되고 증분 방식으로 처리되는 단순한 Dynamic Table이었으며, 추가 비용도 거의 발생하지 않았습니다.
문제는 팀이 여기에 추가 키로 파이프라인을 보강해야 하면서 시작됐습니다. 일부 ID가 업스트림에서 안정적으로 배치되어 있지 않아, 이를 보완하려면 여러 데이터 소스(최대 5개, 이후 3개로 최적화)를 조인해야 했습니다. 그러나 이 과정에서 중복 데이터가 발생했고, 이를 제거하는 로직까지 추가되면서 쿼리의 복잡도가 크게 높아졌습니다. 이에 따라 Snowflake는 더 이상 테이블을 증분 방식으로 새로 고칠 수 없게 되었고 결국 전체 새로 고침 방식으로 돌아갈 수밖에 없었습니다.
변환 비용을 다시 낮추기 위해 팀은 데이터를 두 개의 경로로 분리했습니다. 최근 데이터는 6시간마다 새로 고치는 ‘패스트 레인’으로, 오래된 데이터는 1주 간격으로 새로 고치는 ‘슬로우 레인’으로 나눈 것입니다. 이 방식은 데이터 변환 비용을 줄이는 데는 효과가 있었지만, 두 레인을 최종적으로 UNION 하는 과정에서 자동 클러스터링 비용이 급증했습니다. 결국 하나의 비용을 줄이는 대신 다른 비용이 늘어나는 상황이 된 것입니다. 최악의 경우에는 자동 클러스터링과 데이터 변환 비용을 합쳐 하루 수백 크레딧이 소요되기도 했습니다.
모든 대응은 근본 원인이 아니라 증상만 완화하는 임시방편에 불과했습니다. 진짜 문제는 업스트림에서 Content ID가 일관성 없이 제공되는 것이었고, 이 문제가 해결되지 않는 한 팀은 근본적인 한계를 벗어날 수 없습니다.
Dynamic Table에 사용자 지정 증분 처리 적용
팀이 검토한 방식은 Snowflake 스트림과 태스크였습니다. 즉, 실제로 변경된 행만 처리한 뒤, merge 로직을 적용하는 방식입니다. Snowflake 스트림과 태스크 기반 파이프라인이라면 복잡성 급증을 효과적으로 처리할 수 있었겠지만, Thrive 엔지니어들이 지적했듯 데이터 최신성 목표를 더 높이려 할수록 전체 새로 고침 지연을 제어하기가 더 어려워졌을 것입니다.
Dynamic Table의 사용자 지정 증분 처리(REFRESH_MODE = CUSTOM_INCREMENTAL)는 이러한 트레이드오프를 완전히 제거했습니다. 팀은 CHANGES()를 대상으로 MERGE INTO SELF를 사용하는 명시적인 REFRESH USING 로직을 직접 작성해, 이 파이프라인에서 ‘증분 처리’가 정확히 무엇을 의미하는지 정의했습니다. 즉 변경된 데이터만 처리하고 이를 기존 데이터에 병합하며, 나머지 데이터는 그대로 유지하도록 구현한 것입니다. 그 결과, 팀은 원하던 스트림과 태스크 기반 실행 모델을 확보하면서도, 일정 관리, 재시도, 트랜잭션 보장, 지연 관리는 계속 Snowflake에 맡길 수 있었습니다.
이로 인해 두 가지 변화가 나타났습니다.
- 변환 작업의 전체 재처리 중단: 이제는 조인과 중복 제거로 인해 전체 새로 고침을 수행하는 대신, 매번 변경된 행만 처리합니다.
- 자동 클러스터링의 반복 작업 중단: 전체 데이터를 다시 생성하는 작업이 사라졌고, 패스트 레인과 슬로우 레인을 UNION으로 결합하는 구조도 더 이상 필요하지 않아 자동 클러스터링 작업이 거의 발생하지 않게 되었습니다.
“사용자 지정 증분 처리를 통해 원하는 실행 방식을 구현하면서도, 일정 관리와 재시도, 새로 고침 지연은 계속해서 Snowflake에 맡길 수 있었습니다. 또한 로직이 dbt DAG 안에 그대로 유지되기 때문에 파이프라인도 데이터 계보 그래프에서 기존 위치를 유지할 수 있었고, 별도의 오케스트레이션 계층을 관리할 필요도 없었습니다.”
Alex Tasioulis
데이터 변환 및 자동 클러스터링 비용 동시 절감
| 비용 요인 | 이전 | 이후 | 절감 효과 |
|---|---|---|---|
| 자동 클러스터링 | 약 150크레딧/일 | 약 2크레딧/일 | 약 99% |
| 변환 컴퓨팅 | 약 150크레딧/일 | 약 5크레딧/일 | 약 97% |
참고: 위 결과는 Thrive의 내부 프로덕션 환경에서 측정한 수치에 기반한 것입니다.
또한 이 파이프라인의 새로 고침 지연 시간(refresh latency)도 수 시간에서 수 초 수준으로 단축되었습니다. 이제는 실제로 변경된 데이터 소스만 확인하면 되기 때문입니다. 그 결과 파이프라인은 데이터의 전체 규모가 아니라 데이터의 변경률에 비례해 확장됩니다.
사용자 지정 증분 처리 덕분에 Thrive는 전환 비용과 클러스터링 비용 사이에서 절충할 필요가 없어졌습니다. 대신 새로 고침 방식을 근본적으로 개선하면서도, 직접 구축한 스트림과 태스크 기반 파이프라인을 사용할 경우 포기해야 했던 새로 고침 지연 제어 기능은 그대로 유지할 수 있었습니다. Thrive는 앞으로도 변환 로직을 단순한 증분 SELECT 쿼리만으로 표현하기 어려운 경우라면, 이와 같은 패턴을 계속 활용할 계획입니다.
dbt에서 데이터 계보 유지
Thrive가 스트림과 태스크 기반 방식 대신 사용자 지정 증분 처리를 선택한 또 다른 이유는 거버넌스였습니다. Thrive는 dbt를 사용해 데이터 변환 작업을 관리합니다. 어떤 모델이 어떤 모델의 입력으로 사용되는지 정확히 파악하는 것은 팀이 플랫폼을 이해하고 테스트하며 문서화하는 데 매우 중요한 요소입니다.
반면 스트림과 태스크는 dbt 외부에서 동작합니다. 이 로직을 직접 구축한 스트림과 태스크 기반 파이프라인으로 옮겼다면, 해당 오브젝트들이 dbt DAG에서 완전히 빠져나가 계보가 끊기고, 팀은 이를 별도의 주변 시스템처럼 관리하고 모니터링해야 했을 것입니다.
사용자 지정 증분 Dynamic Table도 본질적으로는 Dynamic Table입니다. 사용자 지정 증분 처리에 대한 dbt 네이티브 지원은 아직 제공되지 않지만, Thrive는 이를 사용자 지정 dbt 머티리얼라이제이션으로 감싸 dbt 프로젝트 내에서 일반적인 핵심 노드처럼 계속 관리할 수 있도록 했습니다. 덕분에 파이프라인은 데이터 계보 그래프에서 기존 위치를 그대로 유지하며, 별도의 오케스트레이션 계층을 관리할 필요 없이 다른 모든 요소와 동일한 워크플로우, 테스트, 문서 체계에서 관리형으로 운영됩니다.
에이전틱 AI 사용 사례 확대를 위한 비용 절감과 데이터 최신성
현재 Thrive는 유사한 조인/중복 제거 복잡성에 직면한 다른 파이프라인에도 같은 패턴을 적용하고 있으며, 이를 통해 Thrive의 전체 분석 환경에서 비용 절감과 데이터 최신성 향상이라는 비슷한 성과를 기대하고 있습니다. 직접적인 비용 절감 효과를 넘어, Thrive는 이미 이 데이터를 활용하는 에이전틱 AI를 운영하고 있습니다. 데이터 비용이 낮아지고 거의 실시간에 가까워지면 동일한 데이터로 더 많은 에이전틱 AI 사용 사례를 지원할 수 있으며, Thrive 플랫폼은 AI 역량을 한층 확장할 수 있는 유리한 위치에 서게 될 것입니다.
